Re: [mpls] 答复: MPLS-RT review of draft-zjns-mpls-lsp-ping-relay-reply

[Ryan Zheng<[e-mail]>]

Hi Mach,

Sorry for the late reply.

Thanks for your detailed review. Please see my response inline.

Best Regards,
Ryan

Mach Chen <[e-mail]> wrote on 2012-10-27 11:17:00:

> Hi,
> 
> I have done my MPLS-RT review, here are my comments.
> 
> Is this draft useful?
> 
> Yes, I think this draft is useful.
> 
> Is the document coherent?
> 
> I think the draft needs more work, especially on the "K bit" related
> design and process. 
> 
> Is the document ready to be considered for WG adoption.
> 
> It is close to, better after solving the following comments with 
> clarification or a new revision. 
> 
> 
> Comments:
> 
> 1. From the motivation, it seems that draft intends to solve the 
> traceroute problem in inter-as/area scenarios, if it's true, this 
> should be explicitly stated in the Introduction and/or Abstract section.
<Ryan>Correct. Will do. 

> 2. Section 3.2,
> a. the Relay Node Address Stack TLV should be an optional TLV, it's 
> better to state this in the draft, and need to specify to which 
> reply modes (all the five or particular modes ) this TLV could apply.
<Ryan>Yes, the Relay Node Address Stack TLV is an optional TLV. More 
descriptions of the node behavior will be added, and a Backward 
Compatibility section will help to make it much clearer. This TLV could 
apply to all the five reply modes. However, IMHO, for most use cases, this 
TLV would apply to reply mode 2(Reply via an IPv4/IPv6 UDP packet).

> b. it defines two types the relay address (IPv4, IPv6), does it 
> allow the combination of the two types (e.g., IPv4-IPv4-IPv6-IPv4) 
> in a single stack, if not, it should explicitly spell out. And if a 
> node support dual stacks, how does it decide which type should be used?
<Ryan>The combination of IPv4 and IPv6 is allowed, that is why each 
relayed address in the stack has its own Address Type, either IPv4 or 
IPv6. Which type should be used depends on local configuration. Whatever 
IPv4 or IPv6, a routable address for other nodes is required here.

> c. the K bit, the draft said: "The K bit may be set by ASBRs which 
> address would be kept in the stack if necessary." How and when does 
> an ASBR know it should set the K bit? Can an non-ASBR set the K bit? 
<Ryan>It is under administrator control policy. It is recommended for the 
ASBR to set the K bit, but other node could also set the K bit.
 
> 3. Section 4.1, should initiator address entry set the K bit, if 
> not, according to the compress process in section 4.2, the initiator
> address will be deleted when an intermediate node compressed the 
> stack. Therefore, when do relay reply, since source and destination 
> addresses are not be the initiator address anymore, the intermediate
> node may not where to send to reply. Is my understanding right? 
> IMHO, the initiator address MUST always be kept in the stack as the 
> first entry. I have feeling that there is no need to define the K 
> bit, makes the procedures more complex and brings less value.
<Ryan>Initiator does not need to set the K bit. Initiator address would be 
the first one added in the stack, and also always the first address be 
checked in the compress process in section 4.2. According to the compress 
process, initiator address would never be deleted, and would be always in 
the stack for the last relay node to send echo reply to. The initial 
thought for the K bit is for possible AS loop check to collect and report 
the ASBRs along the path of the LSP.

> 4. Section 4.2, "the receiver would check the addresses of the stack
> in sequence from top to bottom", I am not sure the concept of top 
> and bottom is same as the normal stack (e.g., first in last out, aka
> the first will be the bottom and the last will be the top), if yes, 
> IMHO, from the bottom to top should be more efficient, it will 
> eliminate unnecessary relay processes. 
<Ryan>Just the opposite. The first will be the top and the last will be 
the bottom. That means the first address in the stack will be the first 
one to be checked, i.e., initiator address. I believe we need more 
descriptions here to avoid misunderstandings. 

> 5. Setion 4.3  "...When the replying LSR received an echo request 
> with the initiator
>    IP address in the Relay Node Address Stack TLV is IP unroutable, the
>    replying LSR would send an echo relay reply message to the first
>    routable intermediate node." This confirm my assumption that the 
> initiator MUST be in the stack and MUST be the first entry.
<Ryan>Correct.

> 
> Best regards,
> Mach
> 
> > -----邮件原件-----
> > 发件人: Loa Andersson [mailto:[e-mail]]
> > 发送时间: 2012年10月13日 0:32
> > 收件人: Mach Chen; Dan King; Thomas Morin
> > 抄送: [e-mail];
> > [e-mail]; Martin Vigoureux
> > 主题: MPLS-RT review of draft-zjns-mpls-lsp-ping-relay-reply
> > 
> > Mach, Daniel and Thomas,
> > 
> > 
> > You have been selected as an MPLS Review team reviewers for
> > draft-zjns-mpls-lsp-ping-relay-reply.
> > 
> > Note to authors: You have been CC’d on this email so that you can 
know
> > that this review is going on. However, please do not review your own
> > document.
> > 
> > Reviews should comment on whether the document is coherent,
> > is it useful (ie, is it likely to be actually useful in operational
> > networks), and is the document technically sound?  We are interested 
in
> > knowing whether the document is ready to be considered for WG adoption
> > (ie, it doesn’t have to be perfect at this point, but should be a 
good
> > start).
> > 
> > Reviews should be sent to the document authors, WG co-chairs and
> > secretary, and CC’d to the MPLS WG email list. If necessary, comments
> > may be sent privately to only the WG chairs.
> > 
> > Are you able to review this draft by Oct 30, 2012?
> > 
> > Thanks, Loa
> > (as MPLS WG chair)
> > 
> > --
> > 
> > 
> > Loa Andersson                         email:
> > [e-mail]
> > Sr Strategy and Standards Manager            [e-mail]
> > Ericsson Inc                          phone: [phone]
> >                                               [phone]