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

[Ryan Zheng<[e-mail]>]

Hi Thomas,

Thank you for the detailed review and valuable comments. Please see my 
answers below.

Best Regards,
Ryan

<[e-mail]> wrote on 2012-11-02 19:07:45:

> Hi Loa,
> 
> Here is my feedback on draft-zjns-mpls-lsp-ping-relay-reply.
> 
> Short answer: yes, it seems to me that the document is coherent, useful, 

> technically sound, and ready to be considered for WG adoption.
> 
> Beyond this, here are a few other comments (which I think can be 
> addressed after eventual adoption if they are not before):
> 
> - the name of the document and message sounds quite weird to my ears: 
> "Echo Relay Reply" looks like meaning "a reply to an echo relay"; why 
> not naming it "Relayed Echo Reply", making it clearer that it's just 
> like an Echo Reply, but Relayed...?
<Ryan>I personally agree. Would like to know the WG preference.

> - maybe the document should be marked as "Updates RFC4379" (sections 4.1 

> and 4.5)
<Ryan>Accepted.

> - about how to populate the "Relay Node Address Stack" (section 4.1):
> 
> "When the echo request is first sent by initiator, a  TLV with the 
> initiator address in the stack and its source port MUST be included." 
> --> shouldn't the text be more explicit on how the stack is initially 
> populated (at least give an example) ?  Making it clearer in the 
> introduction that the scheme is designed to work in context where the 
> initiator knows how to populate a the stack.
<Ryan>I am not sure I catch your question. The TLV is used for LSP Ping 
traceroute mode. When the echo request is first sent by initiator, i.e., 
an echo request with outer label TTL equals to 1, the initiator address 
would be carried in the stack, and also the only address in the stack. The 
initiator MUST know how to populate the stack, i.e., support the Relay 
Node Address Stack TLV extension in this draft.

> - still about how to populate the "Relay Node Address Stack" (section 
> 4.1): by the way, I can see how is the initiator can guess the IP of the 

> first ASBR (BGP next-hop), but not how it's supposed to guess how to 
> populate the stack in, for instance, an inter-AS case where there is 
> more than two ASes ; that would deserve being explained, IMHO
<Ryan>Similar answer with above. The TLV is used for LSP Ping traceroute 
mode. The relayed node address would be collected in the stack during the 
traceroute process. The initiator does not have a prior knowledge of 
relayed node addresses before traceroute process.
 
> - the security section is probably worth being worked on more:
>    * addressing DoS risks by adding a rate limiter:
>      (a) seems to be a poor solution: the rate limiter may reduce DoS 
> risk on the router control plane, but creates a risk of DoS on the LSP 
> Ping service itself.
>      (b) is already what is suggested by RFC4379 anyways, so the draft 
> could as well just point to RFC4379 security section
<Ryan>OK. Will do.

>    * MPLS LSP Ping create an increased risk of DoS, by putting the IP of 

> a victim router in the Relay Node Address Stack of multiple messages 
> sent to many routers; this ability to multiply the DoS effect without 
> having to spoof IP source address looks new to me
<Ryan>Will add more descriptions in Security Consideration section 
accordingly.

> - editorial nits:
>    * message names are sometimes capitalized, sometimes not; better to 
> capitalize them always ?
<Ryan>OK.

>    * section 4.3: "encapsulation processing" -> why not just 
"processing"
<Ryan>OK.

>    * section 4.5: s/echo relay reply/echo reply/ in the first sentence ?
<Ryan>should be Echo Reply. Will correct it.

>    * section 4.5, bullet 1 : why adding the sentence "the processing of
>                              ... is the same as..." ?
<Ryan>Since the initiator address is routable to the replying LSR, no 
reply relayed process is needed for this case. And the replying LSR would 
reply to the initiator directly . Now I see the "same" word is not 
suitable here, because the Relay Node Address Stack TLV would be carried 
in the Echo Reply as a addition to RFC4379. The sentence will be removed.

>    * "UDP port is set to 3503." is said in many places; why not factor 
> that out and say that UDP ports are set just like in RFC4379 ?
<Ryan>The well-known port 3503 has been allocated for LSP Ping message. 
The Echo Relay Reply messsage inherit this in this draft. Explicit 
statement will be added in section 3.1 to make it clear.

> 
> -Thomas Morin
> 
> 
> 
> 
> 2012-10-12, Loa Andersson:
> >
> >
> > 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]
> 
> 
_________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
> avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a
> ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender 
> and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for 
> messages that have been modified, changed or falsified.
> Thank you.
>