[Technical Errata Reported] RFC5884 (5085)

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Technical Errata Reported] RFC5884 (5085)

rfc-editor
The following errata report has been submitted for RFC5884,
"Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5085

--------------------------------------
Type: Technical
Reported by: Balaji Rajagopalan <[hidden email]>

Section: 6

Original Text
-------------
The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
the BFD session.

Corrected Text
--------------
The egress LSR MUST respond with an LSP Ping Echo reply message that
MAY carry the local discriminator assigned by it for the BFD session.


Notes
-----
It is not clear from the original text which of the following is optional:
  -  The egress MUST send a reply, but the discriminator in the reply is optional
  -  The reply itself is optional
 
Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.

The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5884 (draft-ietf-bfd-mpls-07)
--------------------------------------
Title               : Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)
Publication Date    : June 2010
Author(s)           : R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow
Category            : PROPOSED STANDARD
Source              : Bidirectional Forwarding Detection
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Jeffrey Haas-2
[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:

> Section: 6
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
> Corrected Text
> --------------
> The egress LSR MUST respond with an LSP Ping Echo reply message that
> MAY carry the local discriminator assigned by it for the BFD session.
>
>
> Notes
> -----
> It is not clear from the original text which of the following is optional:
>   -  The egress MUST send a reply, but the discriminator in the reply is optional
>   -  The reply itself is optional
>  
> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
>
> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.  

-- Jeff

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Greg Mirsky-2
Re-sending to the corrected list (apologies for duplicates).

Dear All,
I suggest to reject this proposal. The current text is clear and the mechanics of bootstrapping BFD session over MPLS LSP is well understood - remote peer MUST start sending BFD control packets first and BFD peer MAY send Echo Reply with its Local Discriminator as value in BFD Discriminator TLV.

Regards,
Greg

On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <[hidden email]> wrote:
[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> Section: 6
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
> Corrected Text
> --------------
> The egress LSR MUST respond with an LSP Ping Echo reply message that
> MAY carry the local discriminator assigned by it for the BFD session.
>
>
> Notes
> -----
> It is not clear from the original text which of the following is optional:
>   -  The egress MUST send a reply, but the discriminator in the reply is optional
>   -  The reply itself is optional
>
> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
>
> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.

-- Jeff


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Carlos Pignataro (cpignata)
In reply to this post by Jeffrey Haas-2
Jeff, WG,

I believe there is one additional consideration — please see inline.

On Aug 11, 2017, at 1:39 PM, Jeffrey Haas <[hidden email]> wrote:

[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
Section: 6

Original Text
-------------
The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
the BFD session.

Corrected Text
--------------
The egress LSR MUST respond with an LSP Ping Echo reply message that
MAY carry the local discriminator assigned by it for the BFD session.


Notes
-----
It is not clear from the original text which of the following is optional:
 -  The egress MUST send a reply, but the discriminator in the reply is optional
 -  The reply itself is optional

Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.

This is correct — but even more so, technically, it is not up to RFC 5884 to define when an LSP-Ping reply is optional or not.


Lacking a Reply Mode set to "Do not reply" (https://tools.ietf.org/html/rfc8029#page-12) the RFC 8029 procedures dictate a response be sent, independent of whether the RFC 5884 procedures use that information or not.

More below.


The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

Yes, especially because the first sentence says that the egress sending a BFD Control packet implies FEC validation passed. However, https://tools.ietf.org/html/rfc8029#section-4.4 does more than FEC validation.


The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.  


My individual opinion is that, as written, RFC 5884 cannot mean any other thing that “ The egress LSR MUST respond with an LSP Ping Echo reply message that
MAY carry the local discriminator assigned by it for the BFD session”.

In other words, I support this errata.

This is because RFC 5884 did not update RFC 4379’s procedures. And thus a response is needed based on 8029 irregardless of whether 5884 uses it.

That said, it is debatable whether that LSP Ping response is useful or not. If it is not sent, it does not comply to 8029. But if the WG wants for it to be not send, a new spec is needed.

Thanks,

-- Jeff


Carlos Pignataro, [hidden email]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Carlos Pignataro (cpignata)
In reply to this post by Greg Mirsky-2
Greg,

> On Aug 11, 2017, at 2:12 PM, Greg Mirsky <[hidden email]> wrote:
>
> Re-sending to the corrected list (apologies for duplicates).
>
> Dear All,
> I suggest to reject this proposal. The current text is clear and the mechanics of bootstrapping BFD session over MPLS LSP is well understood - remote peer MUST start sending BFD control packets first and BFD peer MAY send Echo Reply with its Local Discriminator as value in BFD Discriminator TLV.
>

This seems to repeat the text in 5884 without explaining why you feel a particular interpretation is the correct technical one.

The text you include:
        “MAY send Echo Reply with its Local Discriminator as value in BFD Discriminator TLV”

suffers from the ambiguity that this Errata is trying to clarify. Which one is it?
* (MAY send Echo Reply with its Local Disc)
* (MAY send Echo Reply), with its Local Disc.

The actual text is:
   The egress LSR MAY respond with an LSP Ping Echo
!  reply message that carries the local discriminator assigned by it for
   the BFD session.

And NOT:
   The egress LSR MAY respond with an LSP Ping Echo
!  reply message, which carries the local discriminator assigned by it for
   the BFD session.


Based on restrictive versus non-restrictive clause, I feel it is correct to accept the errata.


And by the way, RFC 5884 is not say what happens if the LSP Ping Reply has a different discriminator value!

Thanks,

Carlos.

> Regards,
> Greg
>
>
> On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <[hidden email]> wrote:
> [Note that I have adjusted the addresses in the headers to try to catch the
> RFC authors' current accounts.]
>
>
> The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
> provides us with a good place to start technical discussion.
>
> Please note I also spent some time off-list discussing this errata with
> Balaji.
>
>
> On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> > Section: 6
> >
> > Original Text
> > -------------
> > The egress LSR MAY respond with an LSP Ping Echo
> > reply message that carries the local discriminator assigned by it for
> > the BFD session.
> >
> > Corrected Text
> > --------------
> > The egress LSR MUST respond with an LSP Ping Echo reply message that
> > MAY carry the local discriminator assigned by it for the BFD session.
> >
> >
> > Notes
> > -----
> > It is not clear from the original text which of the following is optional:
> >   -  The egress MUST send a reply, but the discriminator in the reply is optional
> >   -  The reply itself is optional
> >
> > Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
> >
> > The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.
>
> My opinion follows:
>
> In section 6 -
>
> :    On receipt of the LSP Ping Echo request message, the egress LSR MUST
> :    send a BFD Control packet to the ingress LSR, if the validation of
> :    the FEC in the LSP Ping Echo request message succeeds.  This BFD
> :    Control packet MUST set the Your Discriminator field to the
> :    discriminator received from the ingress LSR in the LSP Ping Echo
> :    request message.  The egress LSR MAY respond with an LSP Ping Echo
> :    reply message that carries the local discriminator assigned by it for
> :    the BFD session.  The local discriminator assigned by the egress LSR
> :    MUST be used as the My Discriminator field in the BFD session packets
> :    sent by the egress LSR.
>
> In the text above, I consider it quite clear that the receipt of the BFD
> packet contains sufficient state to bring up the BFD session.  The receipt
> of the same Discriminator in the LSP Ping Echo Reply is optional.
>
> This makes sense partially because the reply may be dropped and we want the
> BFD session to come up as fast as possible.
>
> The point of contention appears to be what to do if we *never* get such
> replies.  It's worth pointing out additional text in RFC 5884, section 3.2.
>
> :    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
> :    detection:
> :
> :       i) LSP Ping is used for bootstrapping the BFD session as described
> :          later in this document.
> :
> :      ii) BFD is used to exchange fault detection (i.e., BFD session)
> :          packets at the required detection interval.
> :
> :     iii) LSP Ping is used to periodically verify the control plane
> :          against the data plane by ensuring that the LSP is mapped to
> :          the same FEC, at the egress, as the ingress.
>
> iii above reminds us that the LSP may be torn down because LSP Ping fails.
> Thus, it seems problematic that we do not get a reply ever.
>
> However, with the BFD session in the Up state, we have information proving
> that the LSP is up.  Thus we have contradictory intent.
>
> ---
>
> My opinion is that the MAY in the RFC 5884 procedures is intended to have
> the BFD session come up by the most expedient means.  I do not believe the
> likely intent was to say "don't send Echo Reply".  Among other things, that
> seems contrary to the intent of the general LSP Ping procedures.
>
> Having given my personal observations, we now get to the business of the
> Working Group: Debating intent and related text.
>
> -- Jeff
>
>


Carlos Pignataro, [hidden email]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Greg Mirsky-2
In reply to this post by Jeffrey Haas-2
Hi Jeff, et al,
greatly appreciate the most detailed analysis that explains the reasoning of the filed Errata. Please consider my in-lined and tagged with GIM>> notes. And since in the center of this discussion is LSP Ping, I've added MPLS WG.

Best regards,
Greg

On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <[hidden email]> wrote:
[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> Section: 6
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
> Corrected Text
> --------------
> The egress LSR MUST respond with an LSP Ping Echo reply message that
> MAY carry the local discriminator assigned by it for the BFD session.
>
GIM>> I'll list quotes from RFC 4379 that, in my view, indicate that the echo reply is optional:
  • "... and returned unchanged by the receiver in the echo reply (if any)"
  • "When an MPLS echo request is received, the receiver is expected to verify that the control plane and data plane are both healthy (for the FEC Stack being pinged) and that the two planes are in sync."
  • " An LSR X that receives an MPLS echo request then processes it as follows."
In my interpretation of these quotes, not only echo reply is optional (first quote) but even action by the echo request receiver (second). And the third, from section 4.4, that leads to '7. Send Reply Packet:' does not use normative language and thus we can interpret the whole section 4.4 as an example, recomendation to implementer.

>
> Notes
> -----
> It is not clear from the original text which of the following is optional:
>   -  The egress MUST send a reply, but the discriminator in the reply is optional
>   -  The reply itself is optional
>
> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
GIM>> The purpose of the LSP Ping with BFD Discriminator TLV is to bootstrap BFD session, not to verify consistency of the control plane and the  data plane. That is why, I believe, RFC 5884 explicitly mandates egress LSR to send BFD control packet first, before optionally sending echo reply.
>
> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.
GIM>> I believe that the suggested periodic LSP Ping SHOULD NOT include BFD Discriminator TLV and thus their processing would not follow the RFC 5884. As for the bootstrapping Echo requests, if the BFD control packets from egress LSR never arrive to the ingress, then the ingress will continue periodically send LSP ping with BFD Discriminator TLV for pre-defined time. 

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.
GIM>> I'd expect BFD session to go down if the LSP gets torn. If the data plane remains in tact even though LSP expected to be removed, then the suggested periodic verification of consistency between the control plane and the data plane should help. 

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.
GIM>> RFC 5884 is clear in giving priority to BFD process not only by stating "the egress LSR MUST send a BFD Control packet to the ingress LSR" but by referring to this before mentioning Echo reply. And I agree with the first part of your conclusion. But, as stated earlier in the thread, my interpretation of the reference to Echo reply
"The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for  the BFD session" 
is different. In my understanding, sending of Echo reply is optional but if the egress LSR sends Echo reply, it MUST include BFD Discriminator TLV with value set to the local discriminator. Which is redundant and unnecessary for the ingress LSR.

 

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.

-- Jeff


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Greg Mirsky-2
In reply to this post by Carlos Pignataro (cpignata)
Hi Carlos,
thank you for sharing your view on how LSP Echo request with BFD Discriminator used to bootstrap a BFD session over MPLS LSP. I'm surprised that you refer to RFC 8029 as normative reference when commenting on RFC 5884. But even if we look into RFC 8029, it still has the same texts I've quoted in the previous note that suggest that echo reply is optional. Consider one of them "The Sender's Handle is filled in by the sender and returned unchanged by the receiver in the echo reply (if any)." Though English is my third language, I interpret "if any" in that sentence as clear indication that the echo reply may not be sent ever.

Regards,
Greg

On Fri, Aug 11, 2017 at 7:45 PM, Carlos Pignataro (cpignata) <[hidden email]> wrote:
Jeff, WG,

I believe there is one additional consideration — please see inline.

On Aug 11, 2017, at 1:39 PM, Jeffrey Haas <[hidden email]> wrote:

[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
Section: 6

Original Text
-------------
The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
the BFD session.

Corrected Text
--------------
The egress LSR MUST respond with an LSP Ping Echo reply message that
MAY carry the local discriminator assigned by it for the BFD session.


Notes
-----
It is not clear from the original text which of the following is optional:
 -  The egress MUST send a reply, but the discriminator in the reply is optional
 -  The reply itself is optional

Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.

This is correct — but even more so, technically, it is not up to RFC 5884 to define when an LSP-Ping reply is optional or not.


Lacking a Reply Mode set to "Do not reply" (https://tools.ietf.org/html/rfc8029#page-12) the RFC 8029 procedures dictate a response be sent, independent of whether the RFC 5884 procedures use that information or not.

More below.


The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

Yes, especially because the first sentence says that the egress sending a BFD Control packet implies FEC validation passed. However, https://tools.ietf.org/html/rfc8029#section-4.4 does more than FEC validation.


The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.  


My individual opinion is that, as written, RFC 5884 cannot mean any other thing that “ The egress LSR MUST respond with an LSP Ping Echo reply message that
MAY carry the local discriminator assigned by it for the BFD session”.

In other words, I support this errata.

This is because RFC 5884 did not update RFC 4379’s procedures. And thus a response is needed based on 8029 irregardless of whether 5884 uses it.

That said, it is debatable whether that LSP Ping response is useful or not. If it is not sent, it does not comply to 8029. But if the WG wants for it to be not send, a new spec is needed.

Thanks,

-- Jeff


Carlos Pignataro, [hidden email]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Carlos Pignataro (cpignata)
Greg,

This is my final email on this topic, since the arguments are now just silly and not technically constructive. 

1. It's not about understanding English. It's about understanding specs! The "(if any)" that you quote means there are situations in which there's no echo reply. As I already explained to you, that's for example the case with Reply-mode: No-reply. However, the "(if any)" does not mean an Echo Reply is OPTIONAL. !! Or that you choose when a reply is not sent!!
2. RFC 8029 obsoleted 4379. But to my recollection, nothing changed relevant to this Errata. 

BFD for MPLS could have updated LSP ping behavior -- it just didn't. 

Sent from my iPad

On Aug 14, 2017, at 2:12 PM, Greg Mirsky <[hidden email]> wrote:

Hi Carlos,
thank you for sharing your view on how LSP Echo request with BFD Discriminator used to bootstrap a BFD session over MPLS LSP. I'm surprised that you refer to RFC 8029 as normative reference when commenting on RFC 5884. But even if we look into RFC 8029, it still has the same texts I've quoted in the previous note that suggest that echo reply is optional. Consider one of them "The Sender's Handle is filled in by the sender and returned unchanged by the receiver in the echo reply (if any)." Though English is my third language, I interpret "if any" in that sentence as clear indication that the echo reply may not be sent ever.

Regards,
Greg

On Fri, Aug 11, 2017 at 7:45 PM, Carlos Pignataro (cpignata) <[hidden email]> wrote:
Jeff, WG,

I believe there is one additional consideration — please see inline.

On Aug 11, 2017, at 1:39 PM, Jeffrey Haas <[hidden email]> wrote:

[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
Section: 6

Original Text
-------------
The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
the BFD session.

Corrected Text
--------------
The egress LSR MUST respond with an LSP Ping Echo reply message that
MAY carry the local discriminator assigned by it for the BFD session.


Notes
-----
It is not clear from the original text which of the following is optional:
 -  The egress MUST send a reply, but the discriminator in the reply is optional
 -  The reply itself is optional

Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.

This is correct — but even more so, technically, it is not up to RFC 5884 to define when an LSP-Ping reply is optional or not.


Lacking a Reply Mode set to "Do not reply" (https://tools.ietf.org/html/rfc8029#page-12) the RFC 8029 procedures dictate a response be sent, independent of whether the RFC 5884 procedures use that information or not.

More below.


The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

Yes, especially because the first sentence says that the egress sending a BFD Control packet implies FEC validation passed. However, https://tools.ietf.org/html/rfc8029#section-4.4 does more than FEC validation.


The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.  


My individual opinion is that, as written, RFC 5884 cannot mean any other thing that “ The egress LSR MUST respond with an LSP Ping Echo reply message that
MAY carry the local discriminator assigned by it for the BFD session”.

In other words, I support this errata.

This is because RFC 5884 did not update RFC 4379’s procedures. And thus a response is needed based on 8029 irregardless of whether 5884 uses it.

That said, it is debatable whether that LSP Ping response is useful or not. If it is not sent, it does not comply to 8029. But if the WG wants for it to be not send, a new spec is needed.

Thanks,

-- Jeff


Carlos Pignataro, [hidden email]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Kireeti Kompella
In reply to this post by Jeffrey Haas-2
As a co-author, I can say that the intent was that the LSP ping reply be sent, but the BFD discriminator be optional.  Not sending an LSP ping reply could lead to the LSP being torn down.

The basic idea here is to use LSP ping to bootstrap a bfd session.  But the semantics of LSP ping don't change; not sending a reply indicates that the LSP is down.

Kireeti

> On Aug 11, 2017, at 10:39, Jeffrey Haas <[hidden email]> wrote:
>
> [Note that I have adjusted the addresses in the headers to try to catch the
> RFC authors' current accounts.]
>
>
> The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
> provides us with a good place to start technical discussion.
>
> Please note I also spent some time off-list discussing this errata with
> Balaji.
>
>
>> On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
>> Section: 6
>>
>> Original Text
>> -------------
>> The egress LSR MAY respond with an LSP Ping Echo
>> reply message that carries the local discriminator assigned by it for
>> the BFD session.
>>
>> Corrected Text
>> --------------
>> The egress LSR MUST respond with an LSP Ping Echo reply message that
>> MAY carry the local discriminator assigned by it for the BFD session.
>>
>>
>> Notes
>> -----
>> It is not clear from the original text which of the following is optional:
>>  -  The egress MUST send a reply, but the discriminator in the reply is optional
>>  -  The reply itself is optional
>>
>> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
>>
>> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.
>
> My opinion follows:
>
> In section 6 -
>
> :    On receipt of the LSP Ping Echo request message, the egress LSR MUST
> :    send a BFD Control packet to the ingress LSR, if the validation of
> :    the FEC in the LSP Ping Echo request message succeeds.  This BFD
> :    Control packet MUST set the Your Discriminator field to the
> :    discriminator received from the ingress LSR in the LSP Ping Echo
> :    request message.  The egress LSR MAY respond with an LSP Ping Echo
> :    reply message that carries the local discriminator assigned by it for
> :    the BFD session.  The local discriminator assigned by the egress LSR
> :    MUST be used as the My Discriminator field in the BFD session packets
> :    sent by the egress LSR.
>
> In the text above, I consider it quite clear that the receipt of the BFD
> packet contains sufficient state to bring up the BFD session.  The receipt
> of the same Discriminator in the LSP Ping Echo Reply is optional.
>
> This makes sense partially because the reply may be dropped and we want the
> BFD session to come up as fast as possible.
>
> The point of contention appears to be what to do if we *never* get such
> replies.  It's worth pointing out additional text in RFC 5884, section 3.2.
>
> :    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
> :    detection:
> :
> :       i) LSP Ping is used for bootstrapping the BFD session as described
> :          later in this document.
> :
> :      ii) BFD is used to exchange fault detection (i.e., BFD session)
> :          packets at the required detection interval.
> :
> :     iii) LSP Ping is used to periodically verify the control plane
> :          against the data plane by ensuring that the LSP is mapped to
> :          the same FEC, at the egress, as the ingress.
>
> iii above reminds us that the LSP may be torn down because LSP Ping fails.
> Thus, it seems problematic that we do not get a reply ever.
>
> However, with the BFD session in the Up state, we have information proving
> that the LSP is up.  Thus we have contradictory intent.
>
> ---
>
> My opinion is that the MAY in the RFC 5884 procedures is intended to have
> the BFD session come up by the most expedient means.  I do not believe the
> likely intent was to say "don't send Echo Reply".  Among other things, that
> seems contrary to the intent of the general LSP Ping procedures.
>
> Having given my personal observations, we now get to the business of the
> Working Group: Debating intent and related text.  
>
> -- Jeff

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

thomas nadeau

> On Aug 15, 2017:11:20 AM, at 11:20 AM, Kireeti Kompella <[hidden email]> wrote:
>
> As a co-author, I can say that the intent was that the LSP ping reply be sent, but the BFD discriminator be optional.  Not sending an LSP ping reply could lead to the LSP being torn down.
>
> The basic idea here is to use LSP ping to bootstrap a bfd session.  But the semantics of LSP ping don't change; not sending a reply indicates that the LSP is down.
>
> Kireeti

        That is exactly my recollection of how we designed (and implemented) this too.

        —Tom


>
>> On Aug 11, 2017, at 10:39, Jeffrey Haas <[hidden email]> wrote:
>>
>> [Note that I have adjusted the addresses in the headers to try to catch the
>> RFC authors' current accounts.]
>>
>>
>> The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
>> provides us with a good place to start technical discussion.
>>
>> Please note I also spent some time off-list discussing this errata with
>> Balaji.
>>
>>
>>> On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
>>> Section: 6
>>>
>>> Original Text
>>> -------------
>>> The egress LSR MAY respond with an LSP Ping Echo
>>> reply message that carries the local discriminator assigned by it for
>>> the BFD session.
>>>
>>> Corrected Text
>>> --------------
>>> The egress LSR MUST respond with an LSP Ping Echo reply message that
>>> MAY carry the local discriminator assigned by it for the BFD session.
>>>
>>>
>>> Notes
>>> -----
>>> It is not clear from the original text which of the following is optional:
>>> -  The egress MUST send a reply, but the discriminator in the reply is optional
>>> -  The reply itself is optional
>>>
>>> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
>>>
>>> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.
>>
>> My opinion follows:
>>
>> In section 6 -
>>
>> :    On receipt of the LSP Ping Echo request message, the egress LSR MUST
>> :    send a BFD Control packet to the ingress LSR, if the validation of
>> :    the FEC in the LSP Ping Echo request message succeeds.  This BFD
>> :    Control packet MUST set the Your Discriminator field to the
>> :    discriminator received from the ingress LSR in the LSP Ping Echo
>> :    request message.  The egress LSR MAY respond with an LSP Ping Echo
>> :    reply message that carries the local discriminator assigned by it for
>> :    the BFD session.  The local discriminator assigned by the egress LSR
>> :    MUST be used as the My Discriminator field in the BFD session packets
>> :    sent by the egress LSR.
>>
>> In the text above, I consider it quite clear that the receipt of the BFD
>> packet contains sufficient state to bring up the BFD session.  The receipt
>> of the same Discriminator in the LSP Ping Echo Reply is optional.
>>
>> This makes sense partially because the reply may be dropped and we want the
>> BFD session to come up as fast as possible.
>>
>> The point of contention appears to be what to do if we *never* get such
>> replies.  It's worth pointing out additional text in RFC 5884, section 3.2.
>>
>> :    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
>> :    detection:
>> :
>> :       i) LSP Ping is used for bootstrapping the BFD session as described
>> :          later in this document.
>> :
>> :      ii) BFD is used to exchange fault detection (i.e., BFD session)
>> :          packets at the required detection interval.
>> :
>> :     iii) LSP Ping is used to periodically verify the control plane
>> :          against the data plane by ensuring that the LSP is mapped to
>> :          the same FEC, at the egress, as the ingress.
>>
>> iii above reminds us that the LSP may be torn down because LSP Ping fails.
>> Thus, it seems problematic that we do not get a reply ever.
>>
>> However, with the BFD session in the Up state, we have information proving
>> that the LSP is up.  Thus we have contradictory intent.
>>
>> ---
>>
>> My opinion is that the MAY in the RFC 5884 procedures is intended to have
>> the BFD session come up by the most expedient means.  I do not believe the
>> likely intent was to say "don't send Echo Reply".  Among other things, that
>> seems contrary to the intent of the general LSP Ping procedures.
>>
>> Having given my personal observations, we now get to the business of the
>> Working Group: Debating intent and related text.  
>>
>> -- Jeff

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Balaji Rajagopalan
In reply to this post by Greg Mirsky-2

I’m aware of three different behaviours from three different vendors that I came across in the course of inter-op:

-         Always respond to an LSP-Ping request carrying a BFD disc

-         Never send a response to an LSP-Ping request carrying a BFD disc

-         Don’t respond to the first LSP-Ping request carrying a BFD disc, but respond to the subsequent ones

 

This experience leads me to believe that this procedure is NOT well-understood.  So, publication of errata on this issue is necessary.

 

As some of the co-authors have clarified in further emails, inclusion of BFD discriminator in the LSP-Ping request does not change LSP-Ping’s basic function. So, the egress must send a reply. This is what the erratum clarifies.

 

--

Balaji Rajagopalan

 

 

 

From: Rtg-bfd <[hidden email]> on behalf of Greg Mirsky <[hidden email]>
Date: Friday, 11 August 2017 at 11:42 PM
To: Jeffrey Haas <[hidden email]>
Cc: Kireeti Kompella <[hidden email]>, Thomas Nadeau <[hidden email]>, "[hidden email]" <[hidden email]>, "Reshad Rahman (rrahman)" <[hidden email]>, Alia Atlas <[hidden email]>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

 

Re-sending to the corrected list (apologies for duplicates).

 

Dear All,

I suggest to reject this proposal. The current text is clear and the mechanics of bootstrapping BFD session over MPLS LSP is well understood - remote peer MUST start sending BFD control packets first and BFD peer MAY send Echo Reply with its Local Discriminator as value in BFD Discriminator TLV.

 

Regards,

Greg

 

On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <[hidden email]> wrote:

[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> Section: 6
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
> Corrected Text
> --------------
> The egress LSR MUST respond with an LSP Ping Echo reply message that
> MAY carry the local discriminator assigned by it for the BFD session.
>
>
> Notes
> -----
> It is not clear from the original text which of the following is optional:
>   -  The egress MUST send a reply, but the discriminator in the reply is optional
>   -  The reply itself is optional
>
> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
>
> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.

-- Jeff

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Carlos Pignataro (cpignata)

This sounds like a good summary of the tactical fix.

 

(Although, like Les wrote down, saying “MUST follow [LSP-Ping]” is better than “MUST Send a Reply”)

 

As an aside -- When it comes to Interop, I remember also issues around the UDP Port on the egress BFD Control packet, depending on whether the response is IP-based vs. over an MPLS LSP.  Tracking this down, this was identified at https://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00447.html (comments on Sections 6 and 7), and it seems, we may have the right bug but a wrong fix.

 

Thanks,

 

-- Carlos.

 

From: Rtg-bfd <[hidden email]> on behalf of Balaji Rajagopalan <[hidden email]>
Date: Wednesday, August 16, 2017 at 1:23 AM
To: Greg Mirsky <[hidden email]>, Jeff Haas <[hidden email]>
Cc: Kireeti Kompella <[hidden email]>, Tom Nadeau <[hidden email]>, "[hidden email]" <[hidden email]>, "Reshad Rahman (rrahman)" <[hidden email]>, Alia Atlas <[hidden email]>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

 

I’m aware of three different behaviours from three different vendors that I came across in the course of inter-op:

  • Always respond to an LSP-Ping request carrying a BFD disc
  • Never send a response to an LSP-Ping request carrying a BFD disc
  • Don’t respond to the first LSP-Ping request carrying a BFD disc, but respond to the subsequent ones

 

This experience leads me to believe that this procedure is NOT well-understood.  So, publication of errata on this issue is necessary.

 

As some of the co-authors have clarified in further emails, inclusion of BFD discriminator in the LSP-Ping request does not change LSP-Ping’s basic function. So, the egress must send a reply. This is what the erratum clarifies.

 

--

Balaji Rajagopalan

 

 

 

From: Rtg-bfd <[hidden email]> on behalf of Greg Mirsky <[hidden email]>
Date: Friday, 11 August 2017 at 11:42 PM
To: Jeffrey Haas <[hidden email]>
Cc: Kireeti Kompella <[hidden email]>, Thomas Nadeau <[hidden email]>, "[hidden email]" <[hidden email]>, "Reshad Rahman (rrahman)" <[hidden email]>, Alia Atlas <[hidden email]>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

 

Re-sending to the corrected list (apologies for duplicates).

 

Dear All,

I suggest to reject this proposal. The current text is clear and the mechanics of bootstrapping BFD session over MPLS LSP is well understood - remote peer MUST start sending BFD control packets first and BFD peer MAY send Echo Reply with its Local Discriminator as value in BFD Discriminator TLV.

 

Regards,

Greg

 

On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <[hidden email]> wrote:

[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> Section: 6
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
> Corrected Text
> --------------
> The egress LSR MUST respond with an LSP Ping Echo reply message that
> MAY carry the local discriminator assigned by it for the BFD session.
>
>
> Notes
> -----
> It is not clear from the original text which of the following is optional:
>   -  The egress MUST send a reply, but the discriminator in the reply is optional
>   -  The reply itself is optional
>
> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
>
> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.

-- Jeff

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Technical Errata Reported] RFC5884 (5085)

Greg Mirsky-2
In reply to this post by Balaji Rajagopalan
Hi Balaji,
thank you for sharing your experience with the issue. Had you captured what are the values of the Return Mode field in Echo request packets in each case? Perhaps these would explain the behavior of the egress LSR.

Regards,
Greg

On Tue, Aug 15, 2017 at 10:23 PM, Balaji Rajagopalan <[hidden email]> wrote:

I’m aware of three different behaviours from three different vendors that I came across in the course of inter-op:

-         Always respond to an LSP-Ping request carrying a BFD disc

-         Never send a response to an LSP-Ping request carrying a BFD disc

-         Don’t respond to the first LSP-Ping request carrying a BFD disc, but respond to the subsequent ones

 

This experience leads me to believe that this procedure is NOT well-understood.  So, publication of errata on this issue is necessary.

 

As some of the co-authors have clarified in further emails, inclusion of BFD discriminator in the LSP-Ping request does not change LSP-Ping’s basic function. So, the egress must send a reply. This is what the erratum clarifies.

 

--

Balaji Rajagopalan

 

 

 

From: Rtg-bfd <[hidden email]> on behalf of Greg Mirsky <[hidden email]>
Date: Friday, 11 August 2017 at 11:42 PM
To: Jeffrey Haas <[hidden email]>
Cc: Kireeti Kompella <[hidden email]>, Thomas Nadeau <[hidden email]>, "[hidden email]" <[hidden email]>, "Reshad Rahman (rrahman)" <[hidden email]>, Alia Atlas <[hidden email]>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

 

Re-sending to the corrected list (apologies for duplicates).

 

Dear All,

I suggest to reject this proposal. The current text is clear and the mechanics of bootstrapping BFD session over MPLS LSP is well understood - remote peer MUST start sending BFD control packets first and BFD peer MAY send Echo Reply with its Local Discriminator as value in BFD Discriminator TLV.

 

Regards,

Greg

 

On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <[hidden email]> wrote:

[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> Section: 6
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
> Corrected Text
> --------------
> The egress LSR MUST respond with an LSP Ping Echo reply message that
> MAY carry the local discriminator assigned by it for the BFD session.
>
>
> Notes
> -----
> It is not clear from the original text which of the following is optional:
>   -  The egress MUST send a reply, but the discriminator in the reply is optional
>   -  The reply itself is optional
>
> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
>
> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.

-- Jeff

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [Technical Errata Reported] RFC5884 (5085)

Mach Chen-2
In reply to this post by Carlos Pignataro (cpignata)

Indeed, I also like Les’s suggestion!

 

Best regards,

Mach

 

From: Rtg-bfd [mailto:[hidden email]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Wednesday, August 16, 2017 10:20 PM
To: Balaji Rajagopalan <[hidden email]>; Greg Mirsky <[hidden email]>; Jeffrey Haas <[hidden email]>
Cc: Kireeti Kompella <[hidden email]>; Thomas Nadeau <[hidden email]>; [hidden email]; Reshad Rahman (rrahman) <[hidden email]>; Alia Atlas <[hidden email]>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

 

This sounds like a good summary of the tactical fix.

 

(Although, like Les wrote down, saying “MUST follow [LSP-Ping]” is better than “MUST Send a Reply”)

 

As an aside -- When it comes to Interop, I remember also issues around the UDP Port on the egress BFD Control packet, depending on whether the response is IP-based vs. over an MPLS LSP.  Tracking this down, this was identified at https://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00447.html (comments on Sections 6 and 7), and it seems, we may have the right bug but a wrong fix.

 

Thanks,

 

-- Carlos.

 

From: Rtg-bfd <[hidden email]> on behalf of Balaji Rajagopalan <[hidden email]>
Date: Wednesday, August 16, 2017 at 1:23 AM
To: Greg Mirsky <[hidden email]>, Jeff Haas <[hidden email]>
Cc: Kireeti Kompella <[hidden email]>, Tom Nadeau <[hidden email]>, "[hidden email]" <[hidden email]>, "Reshad Rahman (rrahman)" <[hidden email]>, Alia Atlas <[hidden email]>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

 

I’m aware of three different behaviours from three different vendors that I came across in the course of inter-op:

-         Always respond to an LSP-Ping request carrying a BFD disc

-         Never send a response to an LSP-Ping request carrying a BFD disc

-         Don’t respond to the first LSP-Ping request carrying a BFD disc, but respond to the subsequent ones

 

This experience leads me to believe that this procedure is NOT well-understood.  So, publication of errata on this issue is necessary.

 

As some of the co-authors have clarified in further emails, inclusion of BFD discriminator in the LSP-Ping request does not change LSP-Ping’s basic function. So, the egress must send a reply. This is what the erratum clarifies.

 

--

Balaji Rajagopalan

 

 

 

From: Rtg-bfd <[hidden email]> on behalf of Greg Mirsky <[hidden email]>
Date: Friday, 11 August 2017 at 11:42 PM
To: Jeffrey Haas <[hidden email]>
Cc: Kireeti Kompella <[hidden email]>, Thomas Nadeau <[hidden email]>, "[hidden email]" <[hidden email]>, "Reshad Rahman (rrahman)" <[hidden email]>, Alia Atlas <[hidden email]>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

 

Re-sending to the corrected list (apologies for duplicates).

 

Dear All,

I suggest to reject this proposal. The current text is clear and the mechanics of bootstrapping BFD session over MPLS LSP is well understood - remote peer MUST start sending BFD control packets first and BFD peer MAY send Echo Reply with its Local Discriminator as value in BFD Discriminator TLV.

 

Regards,

Greg

 

On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <[hidden email]> wrote:

[Note that I have adjusted the addresses in the headers to try to catch the
RFC authors' current accounts.]


The 5884 interop issue keeps bubbling up.  Balaji submitted an errata, which
provides us with a good place to start technical discussion.

Please note I also spent some time off-list discussing this errata with
Balaji.


On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> Section: 6
>
> Original Text
> -------------
> The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
> the BFD session.
>
> Corrected Text
> --------------
> The egress LSR MUST respond with an LSP Ping Echo reply message that
> MAY carry the local discriminator assigned by it for the BFD session.
>
>
> Notes
> -----
> It is not clear from the original text which of the following is optional:
>   -  The egress MUST send a reply, but the discriminator in the reply is optional
>   -  The reply itself is optional
>
> Technically, the reply cannot be optional, because the egress needs to report LSP-Ping verification status to the ingress.
>
> The proposed text recommends to include BFD discriminator in the reply. This was the intent of the original text.

My opinion follows:

In section 6 -

:    On receipt of the LSP Ping Echo request message, the egress LSR MUST
:    send a BFD Control packet to the ingress LSR, if the validation of
:    the FEC in the LSP Ping Echo request message succeeds.  This BFD
:    Control packet MUST set the Your Discriminator field to the
:    discriminator received from the ingress LSR in the LSP Ping Echo
:    request message.  The egress LSR MAY respond with an LSP Ping Echo
:    reply message that carries the local discriminator assigned by it for
:    the BFD session.  The local discriminator assigned by the egress LSR
:    MUST be used as the My Discriminator field in the BFD session packets
:    sent by the egress LSR.

In the text above, I consider it quite clear that the receipt of the BFD
packet contains sufficient state to bring up the BFD session.  The receipt
of the same Discriminator in the LSP Ping Echo Reply is optional.

This makes sense partially because the reply may be dropped and we want the
BFD session to come up as fast as possible.

The point of contention appears to be what to do if we *never* get such
replies.  It's worth pointing out additional text in RFC 5884, section 3.2.

:    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
:    detection:
:
:       i) LSP Ping is used for bootstrapping the BFD session as described
:          later in this document.
:
:      ii) BFD is used to exchange fault detection (i.e., BFD session)
:          packets at the required detection interval.
:
:     iii) LSP Ping is used to periodically verify the control plane
:          against the data plane by ensuring that the LSP is mapped to
:          the same FEC, at the egress, as the ingress.

iii above reminds us that the LSP may be torn down because LSP Ping fails.
Thus, it seems problematic that we do not get a reply ever.

However, with the BFD session in the Up state, we have information proving
that the LSP is up.  Thus we have contradictory intent.

---

My opinion is that the MAY in the RFC 5884 procedures is intended to have
the BFD session come up by the most expedient means.  I do not believe the
likely intent was to say "don't send Echo Reply".  Among other things, that
seems contrary to the intent of the general LSP Ping procedures.

Having given my personal observations, we now get to the business of the
Working Group: Debating intent and related text.

-- Jeff

 

Loading...