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

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

Hello Loa,

Thank you for the input. Yes I understand that I'm doing this very late in the draft stage. I will honor WG consensus, but I do want to point out couple of things.

1. I'm not arguing against path TLV, I see there's still use for that. I was hoping that we can further discuss another method which is simpler and mutually exclusive with path TLV.
2. I'm not sure that we want to specify BFD in this draft, since path TLV really cannot be used for BFD w/o further considerations.

Regards,
Nobo

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: Thursday, August 15, 2013 8:12 AM
> To: Nobo Akiya (nobo)
> Cc: Mach Chen; draft-ietf-mpls-return-path-specified-lsp-
> [e-mail]; [e-mail]
> Subject: Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-
> ping-12.txt
> 
> Nobo,
> 
> not that it matters too much but since we done a wg last call and request for
> publication what is in the document is the wg consensus.
> 
> This wa more than a year ago, it was the LSP Ping TLV and sub-TLV registry
> that hanged the draft. It should be OK now and our AD should be preparing
> the document for IETF last call and IESG review.
> 
> It is of course possible to have comments, but I see it there is nothing in
> what you suggest that can't go into a new document.
> 
> /Loa
> 
> On 2013-08-15 13:00, Nobo Akiya (nobo) wrote:
> > 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
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> 
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]