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

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 14 Aug 2013 22:09:53 +0000

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?

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.

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.

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

---

From: Mach Chen <[email-masked]>
Date: Thu, 15 Aug 2013 06:12:42 +0000

Hi Nobo,

Many thanks for your comments!

Please see my reply inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nobo Akiya (nobo)
> Sent: Thursday, August 15, 2013 6:10 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mpls] Comments on
> draft-ietf-mpls-return-path-specified-lsp-ping-12.txt
> 
> 
> 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. 

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

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

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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 15 Aug 2013 11:00:07 +0000

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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 15 Aug 2013 14:11:37 +0200

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 15 Aug 2013 13:09:45 +0000

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

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, August 15, 2013 8:12 AM
> To: Nobo Akiya (nobo)
> Cc: Mach Chen; draft-ietf-mpls-return-path-specified-lsp-
> [email-masked]; [email-masked]
> 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
> 
> >>> 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
> >> 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.
> >>>
> >> 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.
> >
> >>
> >>>
> >>> via application level control channel Reply mode 6: Reply via
> >>> reverse LSP (assume this exists)
> >>>
> >>> Let's say there existed:
> >>>
> >>> 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.
> >
> > 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
> >>>

---

From: Mach Chen <[email-masked]>
Date: Fri, 16 Aug 2013 01:24:04 +0000

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

> From: Nobo Akiya (nobo) [mailto:[email-masked]]
> Sent: Thursday, August 15, 2013 7:00 PM
> To: Mach Chen; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls] Comments on
> 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?
> 
> >
> 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).
> 
> >
> > >
> 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.
> 
> >
> > >
> 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.
> 
> 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.
> 
> 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
> >
> > >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 17 Aug 2013 01:24:53 +0000

Hello Mach,

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

Perhaps that will be the best approach.

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

> > To: Mach Chen;
> > [email-masked]
> > Cc: [email-masked]
> > > > 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
> > 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?
> >
> > >
> > 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).
> >
> > >
> > > >
> > > > 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 used can be encoded in the reply mode field of echo
> > > > rely so initiator knows which was used.
> > >
> > not, responder just needs to judge whether reverse "path" is available
> > for use, and that's not difficult.
> >
> > preference" reply mode also exists ... since transit nodes or FRR path
> > may not have reverse LSP. But "default reply mode" selection by
> > 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:
> > > > (majority) of cases. Was something like above considered as part
> > > > of this
> > > draft?
> > > >
> > > > Regards,
> > > > Nobo
> > > >