Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD911A8AAF for ; Tue, 24 Mar 2015 12:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPzKjxvagcT8 for ; Tue, 24 Mar 2015 12:28:01 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEC21A8A9A for ; Tue, 24 Mar 2015 12:28:00 -0700 (PDT) Received: by wixw10 with SMTP id w10so58608351wix.0 for ; Tue, 24 Mar 2015 12:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=lLbEOPHuB2Qf3XyowIyE+PGRLIHbh1LZ3z6Hmp703fQ=; b=F1Fq1pxwSlukO3w72908+VrzPeCUaBZzPuVWLJlsjqVr/r1Mwdzi4pGRFU7IVLB+Fr VJa4qgVe8386jsCgX+nf795u08kueSjgRmRYPjGXuifML4pWJPuTr3yXz6QdDaxtxoFO t1KmmkUzLPmIp/uDoHoWQJwLLjGV3RwjXjlnBYUQQUNsbFBs0w8o9FBRhZ9rTtCgVqxz 3/S+8dmBwUYUFHaqorwm7kPdJ/Jpew6J3KJrbpt5xrez2vfoKHa4M7IW5Rb/t4xYrAai 0FWY79imLzT6dfK3plqtcv9AH7BkwaIu7Mc7+crXx0YoJdxANa+UHNvPTb5BOzTyK/jR +rkQ== X-Received: by 10.180.84.3 with SMTP id u3mr31488141wiy.38.1427225279202; Tue, 24 Mar 2015 12:27:59 -0700 (PDT) Received: from NoboAkiyaPC ([2001:67c:370:176:f5b3:3e99:edf4:6951]) by mx.google.com with ESMTPSA id u18sm17240551wib.1.2015.03.24.12.27.55 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Mar 2015 12:27:58 -0700 (PDT) From: "Nobo Akiya" To: , "'draft-ietf-mpls-lsp-ping-relay-reply'" References: <000001d06429$a7dc6520$f7952f60$@gmail.com>, <2015032323480587170245@gmail.com>, <03b401d065b1$55620b90$002622b0$@gmail.com> <2015032500083960732722@gmail.com> In-Reply-To: <2015032500083960732722@gmail.com> Date: Tue, 24 Mar 2015 14:27:51 -0500 Message-ID: <00dd01d06668$a0281e00$e0785a00$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DE_01D0663E.B7615840" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQImcS1x66r+WNsCfP2ChJgjlc8vmgL6b2HDAjiJ+uoCbbolVZxC5XdQ Content-Language: en-ca Archived-At: Cc: 'mpls' Subject: Re: [mpls] Review of draft-ietf-mpls-lsp-ping-relay-reply-07 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 19:28:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DE_01D0663E.B7615840 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Lizhong, =20 From: lizho.jin@gmail.com [mailto:lizho.jin@gmail.com]=20 Sent: March-24-15 11:09 AM To: Nobo Akiya; draft-ietf-mpls-lsp-ping-relay-reply Cc: mpls; loa Subject: RE: Review of draft-ietf-mpls-lsp-ping-relay-reply-07 =20 Hi Nobo, See inline below. Thanks again for the review. =20 _____ =20 Regards Lizhong =20 From: Nobo Akiya Date: 2015-03-24 05:35 To: lizho.jin@gmail.com; = = 'draft-ietf-mpls-lsp-ping-relay-reply' CC: 'mpls'; 'loa' Subject: RE: Review of draft-ietf-mpls-lsp-ping-relay-reply-07 Hi Lizhong, =20 Few more follow-up comments in-line with [NOBO]. =20 From: lizho.jin@gmail.com [ = mailto:lizho.jin@gmail.com]=20 Sent: March-23-15 10:48 AM To: Nobo Akiya; draft-ietf-mpls-lsp-ping-relay-reply Cc: mpls; loa Subject: Re: Review of draft-ietf-mpls-lsp-ping-relay-reply-07 =20 Hi Nobo, Thank you for the detail review again. See the reply inline below. =20 to authors, Please also check, thanks. =20 _____ =20 Regards Lizhong =20 From: Nobo Akiya Date: 2015-03-22 06:52 To: = draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org CC: mpls@ietf.org; 'Loa = Andersson' Subject: Review of draft-ietf-mpls-lsp-ping-relay-reply-07 Hi Authors, =20 I was asked to provide a review of the following document: =20 = http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-07=20 =20 The document is well written and addresses a real problem. I do have a number of (mostly minor and some moderate) comments which I'd like to = see addressed before progressing the document. =20 Section 2 -------------- =20 Figure 1 demonstrates a case where one LSP is set up between PE1 and PE2. If PE1's IP address is not distributed to AS2, a traceroute from PE1 directed to PE2 could fail if the fault exists somewhere between ASBR2 and PE2. =20 Above is not entirely accurate. The Traceroute from PE1 to PE2 can fail = even if there is no fault. It would be good to clarify this by saying "If = PE1's IP address is not distributed to AS2, a traceroute from PE1 directed = towards PE2 can result in a failure because an LSR in AS2 may not be able to = send the Echo Reply message". [Lizhong] accepted. =20 Note that throughout the document, routable address means that it is possible to route an IP packet to this address using the normal information exchanged by the IGP operating in the AS =20 Missing '.' (period) at the end of the paragraph. [Lizhong] accepted. =20 When tracing an LSP from one AN to the remote AN, the LSR1/LSR2 node could not make a response to the Echo Request either, like the P2 node in the inter-AS scenario in Figure 1. =20 "... could not make a response to the Echo Request either ..." can = perhaps be rephrased as "... cannot send the Echo Reply either ...", to be a bit more clear. Yeah it's really a nitpick, but _making_ the response packet = and _sending_ the response packet are two different operations in a code. [Lizhong] accepted. =20 Figure 3 -------------- =20 Typically, the numbers at the top (i.e., bit positions 0, 1, 2, ...) are aligned with columns with '-' character instead of '+' character. In = other words, let's shift the bit positions to the right by one space. [Lizhong] good catch, thanks. =20 Section 3.3 -------------- =20 s/the Reply/the Echo Reply/ [Lizhong] accepted. =20 Section 4.1 -------------- =20 When the Echo Request is first sent by the initiator included a Relay Node Address Stack TLV, the TLV MUST contain the initiator address as the only entry of the stack of relayed addresses, =20 I'd like to suggest rephrasing the first half of above sentence as = follows. =20 When the initiator sends the first Echo Request for the Traceroute operation, with a Relay Node Address Stack TLV, the TLV MUST contain ... [Lizhong] I'd like to remove "Traceroute" as below. Because in "Ping" = mode, the Relayed Echo Reply mechanism could still work. When the initiator sends the first Echo Request with a Relay Node = Address=20 Stack TLV, the TLV MUST contain ... =20 [NOBO] So perhaps what we want to say here is that the first address of = the Relay Node Address Stack TLV in the MPLS Echo Request sent must be = the same as the source IP address used in the sending packet. In other = words, we should not have any text that restricts that there must only = be one entry in the Relay Node Address Stack TLV. Then we can follow = that up with texts like, when operating in the Traceroute mode, then the = first Echo Request sent will have the Relay Node Address Stack TLV = containing one local address. [Lizhong]: right, not necessary to say "only", but the traceroute = related words seem to be included already. So rephrase as below. When the initiator sends the first Echo Request with a Relay Node = Address Stack TLV, the TLV MUST contain the initiator address as the = first entry of the stack of relayed addresses, the destination address = pointer set to this entry, and the source address of the replying router = set to null.=20 =20 [NOBO2] Ok. =20 Section 4.2 -------------- =20 Those address entries with K bit set to 1 MUST be kept in the stack. The receiver MUST check the addresses of the stack in sequence from bottom to top to find the last address in the stack with the K bit set (or the top of the stack if no K bit was found). =20 Shouldn't above "find the last address in the stack with the K bit set" instead say "find the last non-Null address in the stack with the K bit set"? Otherwise the procedure will cause relay LSRs to always refer to = this Null address with K bit set, preventing the first initiator address to = be ever reached when searching for the next relay address. On a related = topic, what is the purpose of allowing a Null address entry with K bit set? [Lizhong]: please refer to the following in section 4.2. If a node spans two addressing domains (with respect to this message) where nodes on either side may not be able to nodes in the other domain, then the final address added MUST set the K bit. K bit applies in the case of a NULL address, to serve as a warning to the initiator that further Echo Request messages may not result in receiving Echo Reply messages. But I believe we need to update section 4.6 as below: OLD: Each time the TTL is increased, the initiator MUST copy the Relay Node Address Stack TLV received in the previous Echo Reply to the next Echo Request. NEW: Each time the TTL is increased, the initiator could copy the Relay Node Address Stack TLV in the previous Echo Reply to the next Echo Request. Some modifications could also be made to the = stack TLV, e.g., delete the NIL entry. =20 [NOBO] That=E2=80=99s a reasonable approach to address this, as long as = the document states that the initiator MUST delete the NIL entry in = subsequent Echo Requests. Otherwise, you will have a case where last = entry with K bit set in the TLV is NIL, and described procedures will = never reach the top (initiator) address. [Lizhong] Will add the following: The NIL entry with K bit set MUST be deleted, otherwise the Echo Reply = message will never be returned. =20 [NOBO2] Ok. =20 If a node spans two addressing domains (with respect to this message) where nodes on either side may not be able to nodes in the other domain, =20 s/may not be able to nodes/may not be able to reach nodes/ [Lizhong] accepted =20 If a node spans two addressing domains (with respect to this message) where nodes on either side may not be able to nodes in the other domain, then the final address added MUST set the K bit. =20 Above procedures defines a strict operation (i.e., MUST) for the K bit usage. However, how an LSR determines "If a node spans two addressing domains where nodes on either side may not be ..." is very vague. It = might be possible that we can end up with different implementations of the K = bit setting because of this vagueness. What's your thoughts? [Lizhong] this is the principle of the implementation. How to know the=20 address information is implementation specific. If fail to get the = information, then it is possible to fail for the echo reply. Maybe "SHOULD" is better = here. =20 [NOBO] Yes I would be more comfortable with SHOULD than MUST. [Lizhong] great. =20 =20 If the full reply message would exceed the MTU size, the Relay Node Address Stack TLV MUST be returned back in the Echo Reply message. Some other TLV(s) MUST be dropped. =20 Well, it's possible that the Relay Node Address Stack TLV has grown so = big and that is the only optional TLV to be included in the Echo Reply. In = that case, the Relay Node Address Stack TLV cannot be included despite the "MUST". I believe what you are trying to imply here is that the Relay = Node Address Stack TLV takes precedence over other optional TLVs, when determining which optional TLVs to keep in the Echo Reply. In that case, perhaps it is better to say "If the full reply message would exceed the = MTU size, the Relay Node Address Stack TLV SHOULD be included in the Echo = Reply message (i.e., other optional TLVs are excluded)." [Lizhong] agreed. =20 Section 4.3 -------------- =20 The Destination Address determined in section 4.2 is used as the next relay node address. =20 Section 4.2 only describes how to update the Relay Node Address Stack = TLV. It also specifies how to update the Destination Address Pointer field. However, nowhere in section 4.2 talk about how the Destination Address = is determined. I'm assuming "the Destination Address determined ..." is referring to this address which the Destination Address Pointer is = pointing to. Perhaps it'll be a good idea, somewhere in section 4.2, to say "... _this_ address is determined to be the Destination Address". [Lizhong] good catch. See changes below: OLD in section 4.2: The Destination Address Pointer MUST be set to this entry.=20 NEW The Destination Address Pointer MUST be set to this entry which is also = the Destination Address. =20 Section 4.4 -------------- =20 Upon receiving an Relayed Echo Reply message with its own address as the destination address in the IP header, the relay node MUST determine the next relay node address as described in section 4.3, with the modification that the location of the received Destination Address is used instead of the bottom of stack in the algorithm. =20 In above, I think you meant section 4.2 instead of section 4.3. [Lizhong] accepted =20 The destination address in Relay Node Address Stack TLV will be updated with the next relay node address. =20 By "destination address" above, do you mean the Destination Address = Pointer field? If so, a bit of clarification is required. Otherwise, I'm not = sure what you mean by "destination address" above. [Lizhong] yes, changed as below: The Destination Address Pointer in Relay Node Address Stack TLV will be = set to the next relay node address.=20 =20 The document is not very clear on how these two fields are used. - Source IP address field of the IP header - Source Address of Replying Router field of the Relay Node Address = Stack TLV =20 I'd imagine you'd want one field to be set by the egress LSR and = unmodified by every upstream relay LSRs, and one field to be updated by the egress = LSR and every upstream relay LSR. This is sort of clarified in section 4.7, = but really should be part of the procedures. [Lizhong] in section 4.2, it says as below: Upon receiving a Relay Node Address Stack TLV in an Echo Request message, the receiver updates the "Source Address of Replying Router". The address MUST be same as the source IP address of Relay Echo Reply (section 4.3) or Echo Reply message (section 4.5) being sent. How to set Source IP address field of the IP header is a standard = behavior, and not speicified in this document. =20 [NOBO] Yes but when receiving an Relayed Echo Reply, how are those two = fields updated? I=E2=80=99m guessing that the Source Address of Replying = Router field is unmodified, and Source IP address field of the IP header = is set to an address of the relay node? Clarifying this point will be = beneficial. [Lizhong] your understanding is right. Add the following to section 4.3, = 4.4 and 4.5. The Source Address of Replying Router field is kept unmodified, and = Source IP address field of the IP header is set to an address of the = sending node.=20 [NOBO2] Thanks. =20 Section 4.6 -------------- =20 During a traceroute operation, multiple Echo Request messages are sent. Each time the TTL is increased, the initiator MUST copy the Relay Node Address Stack TLV received in the previous Echo Reply to the next Echo Request. =20 True but don't we want the initiator to "reset" some fields such as = Reply Add Type, Source Address of Replying Router and Destination Address = Pointer? [Lizhong] these fields will be reset by the reply node. But this section = should still be updated as described in previous comments. =20 [NOBO] I simply assumed that we want to clear: - the Source Address of Replying Router field (along with reply = Add Type) - Destination Address Pointer Since value of those fields are meaningless to the subsequent Echo = Request. Is there any reason why you want to preserve those values for = the subsequent Echo Request? [Lizhong] Whether reseting the two fields will not affect the protocol = function. Reseting two fields seems to be redundant. But if you like, we = could say: Reply Add Type, Source Address of Replying Router and Destination = Address Pointer MAY be reset to 0. =20 [NOBO2] That implies that those fields are meaningless when a node = receives an MPLS Echo Request, so it=E2=80=99s better. However, perhaps = the two aspects that the document should cover is: - Those fields may be preserved or may be reset for subsequent = MPLS Echo Request. - Those fields are to be ignored in received MPLS Echo Request. =20 Thanks! =20 -Nobo =20 Thanks, Nobo =20 =20 Section 6 -------------- =20 As an added security, a receiver of an MPLS Echo Request should verify = that the first address in the Relay Node Address Stack TLV is the same = address as the source IP address field of the received IP header. [Lizhong] accepted, thanks. =20 Thanks! =20 -Nobo =20 =20 ------=_NextPart_000_00DE_01D0663E.B7615840 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

 

From:<= /b> = lizho.jin@gmail.com [mailto:lizho.jin@gmail.com]
Sent: = March-24-15 11:09 AM
To: Nobo Akiya; = draft-ietf-mpls-lsp-ping-relay-reply
Cc: mpls; = loa
Subject: RE: Review of = draft-ietf-mpls-lsp-ping-relay-reply-07

=

 

Hi = Nobo,

See inline below. Thanks again = for the review.

 

=

R= egards

L= izhong

 

=

Hi Lizhong,

 

Few more follow-up comments in-line with [NOBO].

 

F= rom: = lizho.jin@gma= il.com = [mailto:lizho.= jin@gmail.com]=
Sent: March-23-15 10:48 AM
To: Nobo Akiya; = draft-ietf-mpls-lsp-ping-relay-reply
Cc: mpls; = loa
Subject: Re: Review of = draft-ietf-mpls-lsp-ping-relay-reply-07

 

Hi = Nobo,

Thank you = for the detail review again. See the reply inline below.

 

to = authors,

Please = also check, thanks.

 

R= egards

L= izhong

 

Fro= m:&nb= sp;Nobo = Akiya

Dat= e:&nb= sp;2015-03-22 06:52

Sub= ject:&nb= sp;Review of draft-ietf-mpls-lsp-ping-relay-reply-07

<= p class=3DMsoNormal>Hi = Authors,

 

I was = asked to provide a review of the following document:

 

 

The = document is well written and addresses a real problem. I do have = a

number of = (mostly minor and some moderate) comments which I'd like to = see

addressed = before progressing the document.

 

Section = 2

--------------

 

   Figure 1 = demonstrates a case where one LSP is set up between PE1 and

   PE2.  If PE1's = IP address is not distributed to AS2, a traceroute

   from PE1 directed to = PE2 could fail if the fault exists somewhere

   between ASBR2 and = PE2.

 

Above is = not entirely accurate. The Traceroute from PE1 to PE2 can fail = even

if there = is no fault. It would be good to clarify this by saying "If = PE1's

IP = address is not distributed to AS2, a traceroute from PE1 directed = towards

PE2 can = result in a failure because an LSR in AS2 may not be able to = send

the Echo = Reply message".

[Lizhong] = accepted.

 

   Note that throughout = the document, routable address means that it is

   possible to route an = IP packet to this address using the normal

   information = exchanged by the IGP operating in the AS

 

Missing = '.' (period) at the end of the paragraph.

[Lizhong] = accepted.

 

   When tracing an LSP = from one AN to the remote AN,

   the LSR1/LSR2 node = could not make a response to the Echo Request

   either, like the P2 = node in the inter-AS scenario in Figure 1.

 

"... = could not make a response to the Echo Request either ..." can = perhaps

be = rephrased as "... cannot send the Echo Reply either ...", to = be a bit

more = clear. Yeah it's really a nitpick, but _making_ the response packet = and

_sending_ = the response packet are two different operations in a code.

[Lizhong] = accepted.

 

Figure = 3

--------------

 

Typically, the numbers at the top = (i.e., bit positions 0, 1, 2, ...) are

aligned = with columns with '-' character instead of '+' character. In = other

words, = let's shift the bit positions to the right by one space.

[Lizhong] = good catch, thanks.

 

Section = 3.3

--------------

 

s/the = Reply/the Echo Reply/

[Lizhong] = accepted.

 

Section = 4.1

--------------

 

   When the Echo = Request is first sent by the initiator included a Relay

   Node Address Stack = TLV, the TLV MUST contain the initiator address as

   the only entry of = the stack of relayed addresses,

 

I'd like = to suggest rephrasing the first half of above sentence as = follows.

 

When the = initiator sends the first Echo Request for the Traceroute

operation, with a Relay Node = Address Stack TLV, the TLV MUST contain ...

[Lizhong] = I'd like to remove "Traceroute" as below. Because in = "Ping" mode,

the Relayed Echo = Reply mechanism could still work.

When the = initiator sends the first Echo Request with a Relay Node = Address 

Stack TLV, the = TLV MUST contain ...

 

[NOBO] So perhaps what we want to say here is that the first address of = the Relay Node Address Stack TLV in the MPLS Echo Request sent must be = the same as the source IP address used in the sending packet. In other = words, we should not have any text that restricts that there must only = be one entry in the Relay Node Address Stack TLV. Then we can follow = that up with texts like, when operating in the Traceroute mode, then the = first Echo Request sent will have the Relay Node Address Stack TLV = containing one local address.

[Lizhong]: right, not necessary to say "only", but the = traceroute related words seem to be included already. So rephrase as = below.

When the initiator sends the first Echo = Request with a Relay Node Address Stack TLV, the TLV MUST contain the = initiator address as the first entry of the stack of relayed addresses, = the destination address pointer set to this entry, and the source = address of the replying router set to null. 

 

[NOBO2] Ok.

&= nbsp;

Section = 4.2

--------------

 

   Those address = entries with K bit set to 1 MUST be kept in the stack.

   The receiver MUST = check the addresses of the stack in sequence from

   bottom to top to = find the last address in the stack with the K bit

   set (or the top of = the stack if no K bit was found).

 

Shouldn't = above "find the last address in the stack with the K bit = set"

instead = say "find the last non-Null address in the stack with the K = bit

set"? Otherwise the = procedure will cause relay LSRs to always refer to this

Null = address with K bit set, preventing the first initiator address to = be

ever = reached when searching for the next relay address. On a related = topic,

what is = the purpose of allowing a Null address entry with K bit set?

[Lizhong]: please refer to the = following in section 4.2.

&= nbsp;  If a node spans two addressing domains (with respect to this = message)

&= nbsp;  where nodes on either side may not be able to nodes in the = other

&= nbsp;  domain, then the final address added MUST set the K = bit.  K bit

&= nbsp;  applies in the case of a NULL address, to serve as a warning = to the

&= nbsp;  initiator that further Echo Request messages may not result = in

&= nbsp;  receiving Echo Reply messages.

B= ut I believe we need to update section 4.6 as below:

O= LD:

E= ach time the TTL is increased, the initiator MUST copy the

&= nbsp;  Relay Node Address Stack TLV received in the previous Echo = Reply to

&= nbsp;  the next Echo Request.

N= EW:

E= ach time the TTL is increased, the initiator could copy the

&= nbsp;  Relay Node Address Stack TLV in the previous Echo Reply = to

&= nbsp;  the next Echo Request. Some modifications could also be made to the stack TLV, = e.g., delete the NIL entry.

 

[NOBO] That=E2=80=99s a reasonable approach to address this, as long as = the document states that the initiator MUST delete the NIL entry in = subsequent Echo Requests. Otherwise, you will have a case where last = entry with K bit set in the TLV is NIL, and described procedures will = never reach the top (initiator) address.

[Lizhong] Will add the following:

The NIL entry with K bit set MUST be deleted, = otherwise the Echo Reply message will never be returned.

&= nbsp;

[NOBO2] Ok.

&= nbsp;

   If a node spans two = addressing domains (with respect to this message)

   where nodes on = either side may not be able to nodes in the other

   domain,

 

s/may not = be able to nodes/may not be able to reach nodes/

[Lizhong] = accepted

 

   If a node spans two = addressing domains (with respect to this message)

   where nodes on = either side may not be able to nodes in the other

   domain, then the = final address added MUST set the K bit.

 

Above = procedures defines a strict operation (i.e., MUST) for the K = bit

usage. = However, how an LSR determines "If a node spans two = addressing

domains = where nodes on either side may not be ..." is very vague. It = might

be = possible that we can end up with different implementations of the K = bit

setting = because of this vagueness. What's your thoughts?

[Lizhong] = this is the principle of the implementation. How to know the 

address = information is implementation specific. If fail to get the = information,

then it is = possible to fail for the echo reply. Maybe "SHOULD" is better = here.

&= nbsp;

[NOBO] Yes I would be more comfortable with SHOULD than = MUST.

[Lizhong] great.

&= nbsp;

 

   If the full reply = message would exceed the MTU size, the Relay Node

   Address Stack TLV = MUST be returned back in the Echo Reply message.

   Some other TLV(s) = MUST be dropped.

 

Well, = it's possible that the Relay Node Address Stack TLV has grown so = big

and that = is the only optional TLV to be included in the Echo Reply. In = that

case, the = Relay Node Address Stack TLV cannot be included despite the

"MUST". I believe what = you are trying to imply here is that the Relay Node

Address = Stack TLV takes precedence over other optional TLVs, when

determining which optional TLVs = to keep in the Echo Reply. In that case,

perhaps = it is better to say "If the full reply message would exceed the = MTU

size, the = Relay Node Address Stack TLV SHOULD be included in the Echo = Reply

message = (i.e., other optional TLVs are excluded)."

[Lizhong] = agreed.

 

Section = 4.3

--------------

 

   The Destination = Address determined in section 4.2 is used as the next

   relay node = address.

 

Section = 4.2 only describes how to update the Relay Node Address Stack = TLV.

It also = specifies how to update the Destination Address Pointer = field.

However, = nowhere in section 4.2 talk about how the Destination Address = is

determined. I'm assuming = "the Destination Address determined ..." is

referring = to this address which the Destination Address Pointer is = pointing

to. = Perhaps it'll be a good idea, somewhere in section 4.2, to say = "...

_this_ = address is determined to be the Destination Address".

[Lizhong] = good catch. See changes below:

OLD in = section 4.2:

T= he Destination Address Pointer MUST be set to this = entry. 

N= EW

T= he Destination Address Pointer MUST be set to this entry = which is also the Destination = Address.

 

Section = 4.4

--------------

 

   Upon receiving an = Relayed Echo Reply message with its own address as

   the destination = address in the IP header, the relay node MUST

   determine the next = relay node address as described in section 4.3,

   with the = modification that the location of the received Destination

   Address is used = instead of the bottom of stack in the algorithm.

 

In above, = I think you meant section 4.2 instead of section 4.3.

[Lizhong] = accepted

 

   The

   destination address = in Relay Node Address Stack TLV will be updated

   with the next relay = node address.

 

By = "destination address" above, do you mean the Destination = Address Pointer

field? If = so, a bit of clarification is required. Otherwise, I'm not = sure

what you = mean by "destination address" above.

[Lizhong] = yes, changed as below:

T= he Destination = Address Pointer in Relay Node Address Stack TLV will be set = to

   the next relay node = address. 

 

The = document is not very clear on how these two fields are used.

- Source = IP address field of the IP header

- Source = Address of Replying Router field of the Relay Node Address = Stack

TLV

 

I'd = imagine you'd want one field to be set by the egress LSR and = unmodified

by every = upstream relay LSRs, and one field to be updated by the egress = LSR

and every = upstream relay LSR. This is sort of clarified in section 4.7, = but

really = should be part of the procedures.

[Lizhong] = in section 4.2, it says as below:

&= nbsp;  Upon receiving a Relay Node Address Stack TLV in an Echo = Request

&= nbsp;  message, the receiver updates the "Source Address of = Replying

&= nbsp;  Router".  The address MUST be same as the source = IP address of Relay

&= nbsp;  Echo Reply (section 4.3) or Echo Reply message (section 4.5) = being

&= nbsp;  sent.

How to set Source IP address = field of the IP header is a standard behavior, and

not speicified in this = document.

 

[NOBO] Yes but when receiving an Relayed Echo Reply, how are those two = fields updated? I=E2=80=99m guessing that the Source Address of Replying = Router field is unmodified, and Source IP address field of the IP header = is set to an address of the relay node? Clarifying this point will  = be beneficial.

[Lizhong] your understanding is right. Add the following to section = 4.3, 4.4 and 4.5.

The Source Address of Replying Router field is kept = unmodified, and Source IP address field of the IP header is set to = an address of the sending node. 



[NOBO2] Thanks.



 

Section = 4.6

--------------

 

   During a traceroute = operation, multiple Echo Request messages are

   sent.  Each = time the TTL is increased, the initiator MUST copy the

   Relay Node Address = Stack TLV received in the previous Echo Reply to

   the next Echo = Request.

 

True but = don't we want the initiator to "reset" some fields such as = Reply

Add Type, = Source Address of Replying Router and Destination Address = Pointer?

[Lizhong] these fields will be reset by the reply node. = But this section should still

be updated as = described in previous comments.

&= nbsp;

[NOBO] I simply assumed that we want to clear:

-     &nb= sp;  the Source Address of Replying Router field (along with reply Add = Type)

-     &nb= sp;  Destination Address Pointer

Since value of those fields are meaningless to the subsequent Echo = Request. Is there any reason why you want to preserve those values for = the subsequent Echo Request?

[Lizhong] Whether reseting the two fields will not affect the protocol = function. Reseting two fields seems to be redundant. But if you like, we = could say:

Reply Add Type, Source Address of Replying Router = and Destination Address Pointer MAY be reset to 0.

 <= o:p>

[NOBO2] That implies that those fields are meaningless when a node = receives an MPLS Echo Request, so it=E2=80=99s better. However, perhaps = the two aspects that the document should cover = is:

-        = Those fields may be preserved or may be reset for subsequent MPLS Echo = Request.

-        = Those fields are to be ignored in received MPLS Echo = Request.

 

Thanks!

 

-Nobo

 

Thanks,

Nobo

&= nbsp;

 

Section = 6

--------------

 

As an = added security, a receiver of an MPLS Echo Request should verify = that

the first = address in the Relay Node Address Stack TLV is the same address = as

the = source IP address field of the received IP header.

[Lizhong] = accepted, thanks.

 

Thanks!

 

-Nobo

 

 

------=_NextPart_000_00DE_01D0663E.B7615840--