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

[<[e-mail]>]

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