draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

[Thomas Nadeau <tnadeau@lucidvision.com>]

	I have some questions/comments about this draft.
	
	0) The draft needs to be organized a bit better so that it is
		clear what you are trying to achieve.  For example,
		some of the introductory text is unclear as to whether
		or not you are verifying the control or data planes (or
		both). At least to my reading.

	1) This solution seems tightly coupled between RFCs 4204 and 4379.
		Is it reasonable to assume that all implementations
		will support 4204?  This also seems to beg the question
		of "are there too many moving parts here?" for this
		to ultimately work and interoperate between 2 vendors.

	2) Which packet formats are to be used in this approach? All I see
		are statements like "send Test messages", but no details of
		that.

	3) Can this approach guarantee that the data plane is checked
		completely, and if not, what percentage of coverage is
		given?

	4) In section 2.2, you stipulate:

	To limit the scope of LSP Verification to a
        particular LSP, LSP-id is used in LOCAL_LINK_ID or
        REMOTE_LINK_ID fields of the LMP message exchanges during
        verification.

	Something similar has been proposed as an addition to lsp ping for
	the multi-cast case. Please check into this to see if this is
	similar enough to reuse that object.

	5) Is the link verification actually sent over the LMP control  
channel or
		the actual data path? Your text is unclear on this:

		        To initiate the link verification procedure, the Ingress
        (Egress) node MUST send a BeginVerify message over a control
        channel with IP address of the destination (source) node of
        the LSP.  To limit the scope of LSP Verification to a
        particular LSP, LSP-id is used in LOCAL_LINK_ID or
        REMOTE_LINK_ID fields of the LMP message exchanges during
        verification. If the LINK_ID field is zero, the verification
        can span multiple LSPs between the set of Ingress/Egress nodes
        involved in the verification process. The rest of the details
        for LSP verification follow the LMP link verification
        procedure [RFC4204].

	RFC4204 states that the link verify messages are NOT to be sent
	over the control channel, and since you want to verify the
	data plane you should follow its rules for this:

	12.5.6.  Test Message (Msg Type = 10)

	   The Test message is transmitted over the data link and is used to
	   verify its physical connectivity.  Unless explicitly stated, these
	   messages MUST be transmitted over UDP like all other LMP messages.
	   The format of the Test messages is as follows:

	   <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>

	   The above transmission order SHOULD be followed.

	   Note that this message is sent over a data link and NOT over the
 	  control channel.  The transport mechanism for the Test message is
 	  negotiated using the Verify Transport Mechanism field of the
 	  BEGIN_VERIFY object and the Verify Transport Response field of the
 	  BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).


	6) I suggest passing this document by the MPLS WG and the LSP ping co- 
authors
		to ensure that your desire to reuse that protocol will indeed
		work, and that if this is eventually adopted as a CCAMP work item
		that it not pass WG last call until the MPLS WG has reviewed it.