Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt

["Nobo Akiya (nobo)" <[e-mail]>]

Hello Mach,

> As Loa said, regarding the new modes, maybe we could write a new draft to
> cover that.

Perhaps that will be the best approach.

> 
> > I have another question. Draft mentions BFD. I understand the motive
> > behind wanting to control the reverse BFD path on uni-directional LSP.
> > But I don't quite see the entire picture by making use of path TLV.
> > Let's say we bootstrap BFD with LSP ping with path TLV with specific
> > RSVP FEC, so that reverse BFD packets are riding on specified RSVP FEC.
> That RSVP FEC can become invalid at any time (ex:
> > re-optimization takes place and LSP ID changes). What happens then?
> 
> Regarding the BFD part, actually there is a company draft
> (http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-01 ) that was
> submitted to BFD WG couple years ago. Some of the content may need
> update.
> 
> In section 4.2 of the draft, it describes how reply path TLV (particular the
> Tunnel sub-TLVs) is used to bootstrap BFD session hence to control the
> reverse BFD path. Specifically, it uses Tunnel ID other than particular LSP ID
> to specify the return path of the BFD session, therefore, the BFD session is
> transparent to the changes of particular LSP ID.

I see what you described is documented in 3.3.1 of path TLV draft, sorry I missed that part earlier.

Regards,
Nobo

> 
> Best regards,
> Mach
> 
> > -----Original Message-----
> > From: Nobo Akiya (nobo) [mailto:[e-mail]]
> > Sent: Thursday, August 15, 2013 7:00 PM
> > To: Mach Chen;
> > [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [mpls] Comments on
> > draft-ietf-mpls-return-path-specified-lsp-ping-12.txt
> >
> > Hello Mach,
> >
> > Many thanks for quick response. Please see further comments inline.
> >
> > > > Dear Authors, et al,
> > > >
> > > > Draft adds new reply mode (5 - Reply via Specified Path) which
> > > > looks to provide initiator great control on return path. Draft
> > > > considers bidirectional LSP, and allows specifying of reverse LSP
> > > > in a new TLV, but ... for bidirectional LSP ping, having reply
> > > > mode to indicate reverse LSP would appear to take care of large
> > > > majority of use, and there'll be no need to encode/decode
> > > > additional TLV. Is there any reason
> > > why reply mode to specify reverse LSP is not added?
> > >
> > > The draft uses the "reply mode 5 + B bit" to achieve this, using a
> > > reply mode to indicate the reverse LSP is an alternate way, we
> > > considered this and it also works. The reason not using dedicated
> > > reply mode is that we don't want to define too many reply modes,
> > > indicating reverse LSP is kind of specifying reply path and using the same
> reply mode seems reasonable.
> >
> > We have 8 bits of reply mode, draft is proposing to take value 5/255.
> > I don't think we are crunched to conserve numbers, and reasonable to
> > add another if it make sense. In this case, I think it make sense to
> > add one for "reverse LSP". Regarding "we don't want to define too many
> > reply modes", was that WG rough consensus or was that consensus
> amongst authors of this draft?
> >
> > >
> > > From the implementation point of view, IMHO, the two ways have not
> > > too much differences, from the operation point of view, there should
> > > be no difference.
> >
> > New value in 8 bit field is certainly much more easier to implement
> > than (new value in 8 bit field + new TLV + logic to handle new TLV).
> >
> > >
> > > >
> > > > And reply path TLV allows for initiator to specify a particular
> > > > return path, but allows responder to choose different path if
> > > > initiator specified one cannot be accommodated. This aspect is very
> interesting.
> > > > Reason being that specifying of the "right" reply mode in echo
> > > > request seems to be getting more and more complicated these days.
> > > >
> > > > For example, bidirectional LSP with some transit nodes non-co-routed:
> > > >     - ping:
> > > >         * IP reply mode works
> > > >         * Reverse LSP reply mode works
> > > >     - ping with TTL terminating on mid:
> > > >         * IP reply mode works
> > > >         * Reverse LSP reply mode may or may not work
> > > >     - traceroute:
> > > >         * IP reply mode works
> > > >         * Reverse LSP reply mode may or may not work
> > > >
> > > > In above cases, what I would like to specify in most cases is to
> > > > say "take reverse LSP as return path if available, otherwise take
> > > > IP return path". Yes reply path TLV allows this, but I'm thinking
> > > > if this can be
> > > done in a simpler way.
> > >
> > > As you said, the reply path TLV allows this. In addition, to
> > > localize the failure point, sometime it may need to specify an
> > > explicit reply path other than the reverse path and IP return path,
> > > that is the main reason why we introduce the reply path TLV.
> >
> > Yes, for specific use like fault isolation, I think path TLV adds
> > value. It can be another technique in addition to traceroute. For most
> > ping/trace though, path TLV really isn't necessary. I'd like to see
> > things kept simple for most cases, but allow a mechanism for that tricky
> few percent of cases.
> >
> > >
> > > >
> > > > Reply mode 2: Reply via an IPv4/IPv6 UDP packet Reply mode 4:
> > > > Reply via application level control channel Reply mode 6: Reply
> > > > via reverse LSP (assume this exists)
> > > >
> > > > Let's say there existed:
> > > >
> > > > Reply mode 7: Reply via pre-defined preference
> > > >
> > > > When responder receives reply mode 7, then return path is chosen
> > > > from pre-defined preference list (ex: control-channel > reverse LSP >
> IP).
> > > > Reply mode used can be encoded in the reply mode field of echo
> > > > rely so initiator knows which was used.
> > >
> > > The difficulty is that the responder may not have the ability to
> > > judge whether the control-channel, reverse LSP and IP is workable or
> > > not. For example, when it thinks that the control-channel is
> > > workable, it will always choose it but the control-channel may not
> > > workable (e.g., a failure in the middle of the channel) .
> >
> > Responder does not need to judge whether reverse "path" is workable or
> > not, responder just needs to judge whether reverse "path" is available
> > for use, and that's not difficult.
> >
> > Reverse LSP reply mode only make sense if something like "pre-defined
> > preference" reply mode also exists ... since transit nodes or FRR path
> > may not have reverse LSP. But "default reply mode" selection by
> > implementations or operators will be simplified if we had something like
> this.
> >
> > All this to say, can we discuss a simpler solution via adding couple
> > of new reply modes? :)
> >
> > I have another question. Draft mentions BFD. I understand the motive
> > behind wanting to control the reverse BFD path on uni-directional LSP.
> > But I don't quite see the entire picture by making use of path TLV.
> > Let's say we bootstrap BFD with LSP ping with path TLV with specific
> > RSVP FEC, so that reverse BFD packets are riding on specified RSVP FEC.
> That RSVP FEC can become invalid at any time (ex:
> > re-optimization takes place and LSP ID changes). What happens then?
> >
> > Regards,
> > Nobo
> >
> > >
> > > Best regards,
> > > Mach
> > >
> > > >
> > > > I see the new TLV useful for specific scenarios, but I've been
> > > > trying to see how things (implementations and operations) can be
> > > > simplified for those non-specific
> > > > (majority) of cases. Was something like above considered as part
> > > > of this
> > > draft?
> > > >
> > > > Regards,
> > > > Nobo
> > > >
> > > > _______________________________________________
> > > > mpls mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/mpls