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

From: <[email-masked]>
Date: Fri, 2 Nov 2012 11:07:45 +0000

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

- maybe the document should be marked as "Updates RFC4379" (sections 4.1 
and 4.5)

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

- 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

- 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
   * 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

- editorial nits:
   * message names are sometimes capitalized, sometimes not; better to 
capitalize them always ?
   * section 4.3: "encapsulation processing" -> why not just "processing"
   * section 4.5: s/echo relay reply/echo reply/ in the first sentence ?
   * section 4.5, bullet 1 : why adding the sentence "the processing of
                             ... is the same as..." ?
   * "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 ?

-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: [email-masked]
> Sr Strategy and Standards Manager            [email-masked]
> Ericsson Inc                          phone: +46 10 717 52 13
>                                               +46 767 72 92 13

_________________________________________________________________________________________________________________________

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.

---

From: Ryan Zheng<[email-masked]>
Date: Wed, 14 Nov 2012 16:24:06 +0800

Hi Thomas,

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

Best Regards,
Ryan

> like an Echo Reply, but Relayed...?
<Ryan>I personally agree. Would like to know the WG preference.

> and 4.5)
<Ryan>Accepted.

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

> 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.
 
> could as well just point to RFC4379 security section
<Ryan>OK. Will do.

> having to spoof IP source address looks new to me
<Ryan>Will add more descriptions in Security Consideration section 
accordingly.

>    * message names are sometimes capitalized, sometimes not; better to 
<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
<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.

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

> 
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> 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.
>