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

["Zafar Ali (zali)" <zali@cisco.com>]

Hi Tom- 

Thanks for your review; please see comments in-line.  

Thanks

Regards... Zafar 

> -----Original Message-----
> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] 
> Sent: Tuesday, December 04, 2007 8:43 AM
> To: ccamp@ops.ietf.org
> Cc: Otani Tomohiro; Zafar Ali (zali)
> Subject: draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt 
> 
> 
> 	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.  

Sure we will spend efforts to clarify the text further. 

> For example,
> 		some of the introductory text is unclear as to whether
> 		or not you are verifying the control or data planes (or
> 		both). 

Data plane. 

> 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?  

Yes, LMP is already widely implemented (for GMPLS) and already provides
lots of GMPLS OAM solutions. I don't see any reason not to reuse it. 

> 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.
> 

No, I don't think so. Reusing existing protocol/ tool further helps this
cause. 

> 	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.
> 

All encoding methods for TEST message that are defined in LMP
specification are assumed to be permissible. We can add a more elaborate
text to state the same. 

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

Yes, it does guarantee data plane connectivity. We can chat more
off-line on this. 

> 	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.
> 

Sure, we will look into this. 

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

Control messages to setup link/ LSP verification, e.g., BeginVerify,
etc. are sent via control channel and "Test" message is sent in-band of
LSP. Think of LSP as a TE link. 

> 		        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, 

You meant "Test" message is not sent over the control channel, right.
Yes, this is also the case of this draft. 

> 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.
> 

Most certainly. We will send a private email to LSP Ping co-authors and
MPLS WG Chairs (w/ CCAMP WG Chair cc'ed). 

> 	
> 
>