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

[Mach Chen <[e-mail]>]

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.

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

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.

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. 

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.


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]