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

[Mach Chen <[e-mail]>]

Hi Nobo,

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

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

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