Subject: Re: [mpls] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04

From: Mach Chen <[email-masked]>
Date: Wed, 30 Nov 2011 03:15:21 +0000

Hi Sri,

Please see inline.
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sriganesh Kini
> Sent: Wednesday, November 30, 2011 3:30 AM
> To: Mach Chen
> Cc: Sriganesh Kini; [email-masked]; 
> [email-masked]
> Subject: Re: Comment on 
> draft-ietf-mpls-return-path-specified-lsp-ping-04
> 
> Mach, see inline.
> 
> On Tuesday, November 29, 2011, Mach Chen <[email-masked]>
> wrote:
> > Hi Sri,
> >
> > Many thanks for your comments!
> >
> > Please see my reply inline...
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Sriganesh Kini
> >> Sent: Tuesday, November 29, 2011 7:35 AM
> >> To: [email-masked];
> [email-masked]
> >> Subject: [mpls] Comment on
> draft-ietf-mpls-return-path-specified-lsp-ping-04
> >>
> >> Hi,
> >>
> >> Some comments -
> >>
> >> First of all I don't buy this argument that it "MAY" be applicable 
> >> to MPLS-TP (as stated by Mach in another email thread). Either it 
> >> is, or it is not, it should be stated clearly. I don't see a strong 
> >> reason why this should not be applicable.
> >
> > The draft is originally designed for IP/MPLS network, and 
> > theoretically, as you
> said, the idea can apply to MPLS-TP as well, but some extensions and 
> updates are needed to cover MPLS-TP scenarios. That's the main reason 
> why I said "MAY".
> 
> IMO it must include TP since lsp ping is a tool used in TP.

I am OK with that.

> 
> >
> > I am OK to extend the draft to cover MPLS-TP if there is no 
> > objection from the
> WG.
> >
> >> sec 3.3 - What if tunnel is static and not signaled ?
> >
> > Then the sub-TLVs defined in RFC6426 will be used, which are 
> > designed for
> static LSP and PW.
> 
> Pls update the draft. When will static pw sub TLV be used ?

Actually, the current draft has already included this, the RP TLV can carry any sub-TLV (including the static case) defined for the Target FEC stack TLV.

Regarding to static PW, in theory, there is no difference between static and dynamic, or between LSP and PW, if you want to specify the reply path, it could be used.

> 
> >
> >> sec 3.3.1, 3.3.2 - I would suggest that we derive the RP tunnel ID 
> >> from the Tunnel ID as defined in RFC 6370. That should handle the 
> >> static case as well.
> >
> > If MPLS-TP is in scope, then it should be as you suggested.
> 
> Ok.
> 
> >
> >> sec 3.3.3 - Is RP TC sub-TLV applicable when RP TLV is not present 
> >> but echo-response is being sent over a LSP (i.e. an LSP chosen by 
> >> egress but not explicitly requested by ingress).
> >
> > RP TC sub-TLV is carried in RP TLV, and if the "reply via specified 
> > path" mode is
> used, RP TLV must be carried in either echo request or echo reply.
> > If the RP TLV is not present, there will be no RP TC sub-TLV, so the 
> > RP TC
> sub-TLV can not apply to the scenario your described.
> 
> My point was whether RP TC sub TLV should be made a TLV instead. It's 
> value seems to be useful whenever the reply path is a LSP independent 
> of whether the ping originator has requested the reply via a specific tunnel.

Seems a good idea, we will consider it more and then decide how to deal with it.

> 
> >
> >> sec 4.2 - What does a LSR do when it sees the new reply-mode (and 
> >> understands it) but is not the egress of the LSP. Does it reply 
> >> with an error code ? Or does it silently drop the packet ?
> >
> > This should be a typical CV error, and there will be an error 
> > code(e.g., return
> code 3 - Replying router is an egress for the FEC at stack-depth 
> <RSC>) returned if there is a return path, the related procedures 
> defined in RFC4379 will be inherited here. If there is no return path, it should drop the packet.
> 
> Thinking some more on this is it really necessary to special case this 
> ? If the trace route mode of rfc 4379 is used as-is and the RP TLV 
> applies to the node at which TTL expired shouldn't it work ?

This draft is only intended to ping mode, trace mode is out of scope, which is explicitly stated in Section 4.

> 
> >
> >> sec 4.3 - If a routable IP network is not present how is source 
> >> address
> chosen ?
> >
> > This is also related to MPLS-TP scenario, the current text does not cover this.
> And also, if MPLS-TP is in scope, some Non-IP-based encapsulation 
> should be defined.
> >
> >> sec 4.3 - Value to be set for MPLS TTL must be specified.
> >
> > Why does it need to specify the TLL? Could you please elaborate the
> scenario?
> 
> We don't want implementations to guess the value of TTL. It should be 
> 255 but the draft should explicitly state it. Similar to rfc 4379 
> specifying IP TTL value when using IP for echo reply.

OK, will state this in the revision. 

> 
> >
> >> sec 5 - The security attack by "proxying" still seems possible when 
> >> the label on the last hop is NULL. Verifying return path solely 
> >> using an address would not avoid all possible attacks. Strict 
> >> authentication would still be needed.
> >
> > Yes, there are also some other comments about the security 
> > consideration,
> the authors will think over the comments and improve it in the next 
> revision
> >
> >> sec 6.2.1 - Is explicitly identifying the setup protocol RSVP 
> >> required ? If we remove that, the static case could be wrapped in.
> >
> > Yes, if MPLS-TP is in scope.
> 
> Independent of whether TP is in scope this should be addressed.

OK.

> 
> >
> >> Generic comment - What if tunnel is P2MP ?
> >
> > The P2MP is out of scope :-)
> >
> 
> P2MP lsp ping is an RFC. Why would that be out of scope ?

For P2MP, it is more complicate that P2P case, there are more things need to be considered. For example, how to specify the return paths? Just specify one for a leaf, or specify all the return paths for all leaves (may not scale). In addition, if the return path is also a P2MP tunnel, the echo reply will reach to the nodes that are not the originator of the echo request, this may cause some potential problems. 

So, the current draft is scoped to P2P scenario and leave the P2MP case for future study. 

Best regards,
Mach
> 
> >>
> >> Editorial nits -
> >> sec 6.2.2 - "from the" is repeated twice
> >
> > Good catch! Will fix it in next revision.
> >
> > Many thanks,
> > Mach
> >
> >>
> >> --
> >> - Sri
> >> _______________________________________________
> >> mpls mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> 
> --
> Sriganesh Kini (Sri)