[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Dec 5, 2007, at 5:33 AM, Zafar Ali (zali) wrote:


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.
Can you explain in the document how this works? That, how do intermediate nodes use LMP to check the data plane along the path. It seems to me for instance, that since you are using LMP, you are testing each "segment" of the optical path. This is certainly not end2end testing, so please be clear on this. Also the procedures for how this works need to be clear. Take a look at RFC4379 for examples of how they (we) specified this. The clearest form IMHO is to use pseudo-code/ algorithmic descriptions of all the steps. This way everyone can clearly see what is going on 
here.


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.


	See below.


	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.
Cool. I think the document needs far more details for others to implement/understand 
it for sure.


	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.


	OK.



	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.

	
	This gets to my point about "too many moving parts". What concerns me
about this is not the re-use of LMP per se; thats a good idea in the sense of code/protocol re-use; however, what worries me is one protocol stimulating actions in another like this. There are security implications here that need to be addressed. Also, how certain are you that the implementations of LMP out there will all behave the same way once you initiate the generation of these messages? 


	        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.


	This needs to be clarified.


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


	Thanks.

	--Tom