From: Greg Mirsky <gregimir...@gmail.com <mailto:gregimir...@gmail.com>>
Date: Wednesday, October 4, 2017 at 7:26 PM
To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>
Cc: Kireeti Kompella <kire...@juniper.net <mailto:kire...@juniper.net>>,
Mach Chen <mach.c...@huawei.com <mailto:mach.c...@huawei.com>>, "Carlos
Pignataro (cpignata)" <cpign...@cisco.com <mailto:cpign...@cisco.com>>,
Tom Nadeau <tnad...@lucidvision.com <mailto:tnad...@lucidvision.com>>,
"m...@ietf.org <mailto:m...@ietf.org>" <m...@ietf.org
<mailto:m...@ietf.org>>, Alia Atlas <akat...@gmail.com
<mailto:akat...@gmail.com>>, Reshad <rrah...@cisco.com
<mailto:rrah...@cisco.com>>, "rtg-bfd@ietf.org
<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)
Hi Kireeti, Les, et. al,
I agree and support the proposed changes, including the most recent
proposed by Kireeti.
If errata report can be used to record the changes - absolutely great.
I hope that the errata report that triggered this discussion will be
processed and marked accordingly.
Regards,
Greg
On Wed, Oct 4, 2017 at 12:47 PM, Les Ginsberg (ginsberg)
<ginsb...@cisco.com <mailto:ginsb...@cisco.com>> wrote:
Kireeti –____
__ __
The text I proposed below (3 paragraph’s worth) is intended to
“replace current paragraphs 2 and 3 of Section 6”.____
__ __
I am fine with changing ____
__ __
“The egress LSR follows the procedures defined in [RFC 8029]…”____
__ __
To ____
__ __
“The egress LSR MUST follow the procedures defined in [RFC
8029]…”____
__ __
Mach and Greg should speak for themselves – but I had the impression
that Mach was agreeable – but Greg I am not so sure about.____
__ __
Les____
__ __
__ __
*From:*Kireeti Kompella [mailto:kire...@juniper.net
<mailto:kire...@juniper.net>]
*Sent:* Wednesday, October 04, 2017 12:06 PM
*To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>; Mach Chen <mach.c...@huawei.com
<mailto:mach.c...@huawei.com>>; Carlos Pignataro (cpignata)
<cpign...@cisco.com <mailto:cpign...@cisco.com>>; Greg Mirsky
<gregimir...@gmail.com <mailto:gregimir...@gmail.com>>
*Cc:* Tom Nadeau <tnad...@lucidvision.com
<mailto:tnad...@lucidvision.com>>; m...@ietf.org
<mailto:m...@ietf.org>; Alia Atlas <akat...@gmail.com
<mailto:akat...@gmail.com>>; Reshad Rahman (rrahman)
<rrah...@cisco.com <mailto:rrah...@cisco.com>>; rtg-bfd@ietf. org
<rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>>; Kireeti Kompella
<kire...@juniper.net <mailto:kire...@juniper.net>>
*Subject:* Re: [Technical Errata Reported] RFC5884 (5085)____
__ __
Hi Les,____
__ __
Just to be sure, you’re suggesting____
__a)__Change the sentence “The egress LSR MAY respond … BFD
session.” to “The egress LSR follows the procedures … reply
message.” (or better yet, “The egress LSR MUST follow the
procedures ….”)____
__b)__Move this sentence to after the BFD stuff.____
__c)__Remove the redundant comma (sigh! Thought I knew commas.)____
__ __
I am fine with all three suggestions. I think that the main point
(the source of interop issues) is (a); the other changes definitely
improve readability, but are not showstoppers (imo).____
__ __
I gather from Greg’s latest email (2017/09/08) and Mach’s email
below that they’re both fine with these changes. Greg, Mach: speak
up if not.____
__ __
As for “new interop issues”, the current situation is pretty bad, so
let’s fix it.____
__ __
As to how to implement these changes, I don’t personally care. It
seems heavyweight to issue a bis for this, rather than just errata,
but I’m happy to leave that to the WG chairs to decide.____
__ __
Kireeti.____
__ __
*From: *"Les Ginsberg (ginsberg)" <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>
*Date: *Tuesday, August 15, 2017 at 05:16
*To: *Mach Chen <mach.c...@huawei.com
<mailto:mach.c...@huawei.com>>, "Carlos Pignataro (cpignata)"
<cpign...@cisco.com <mailto:cpign...@cisco.com>>, Greg Mirsky
<gregimir...@gmail.com <mailto:gregimir...@gmail.com>>
*Cc: *Tom Nadeau <tnad...@lucidvision.com
<mailto:tnad...@lucidvision.com>>, "m...@ietf.org
<mailto:m...@ietf.org>" <m...@ietf.org <mailto:m...@ietf.org>>,
Kireeti Kompella <kire...@juniper.net <mailto:kire...@juniper.net>>,
Alia Atlas <akat...@gmail.com <mailto:akat...@gmail.com>>, "Reshad
Rahman (rrahman)" <rrah...@cisco.com <mailto:rrah...@cisco.com>>,
"rtg-bfd@ietf. org <mailto:rtg-bfd@ietf.%20org>" <rtg-bfd@ietf.org
<mailto:rtg-bfd@ietf.org>>
*Subject: *RE: [Technical Errata Reported] RFC5884 (5085)____
__ __
I tend to agree with Mach – and I think what Mach states is also
reinforcing the point that Carlos has made – which is that echo
reply procedures are defined by RFC 8029 – not by RFC 5884.____
____
However, the current text suffers from much more than the ambiguity
regarding Echo Reply.____
____
1)Second paragraph of Section 6 goes back and forth between
discussing BFD Control packets, then Echo Reply, then BFD Control
Packets____
____
2)Third paragraph of Section 6 has an inappropriate use of “,” in
the sentence: ____
____
“The BFD Control packets from the____
ingress to the egress LSR MUST set the local discriminator of
the____
egress *LSR, in *the Your Discriminator field.”____
____
3)Section 6.1 defines when the BFD Discriminator TLV MUST be sent
and when it is optional in LSP ping. There is actually no need for
Section 6 to say anything in this regard.____
____
I propose revised text below – which is much more extensive in its
changes than what has been proposed thus far, but I think it is
necessary to eliminate all ambiguity.____
That said, there is no question that the current text is subject to
multiple interpretations – so any change in text runs the risk of
introducing new interoperability issues. On balance it is probably
necessary to take this risk as there is no guarantee that
implementations are interoperable today, but the WG should still
consider this point carefully.____
____
The text below replaces current paragraphs 2 and 3 of Section 6.____
____
/<new text start>/____
/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 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./____
//____
/ The ingress LSR follows the procedures in [BFD] to send BFD
Control/____
/ packets to the egress LSR in response to the BFD Control
packets/____
/ received from the egress LSR. The BFD Control packets from the/____
/ ingress to the egress LSR MUST set the local discriminator of
the/____
/ egress LSR in the Your Discriminator field. The egress LSR/____
/ demultiplexes the BFD session based on the received Your/____
/ Discriminator field. As mentioned above, the egress LSR MUST
send/____
/ Control packets to the ingress LSR with the Your Discriminator
field/____
/ set to the local discriminator of the ingress LSR. The ingress
LSR/____
/ uses this to demultiplex the BFD session./____
//____
/ The egress LSR follows the procedures defined in [RFC 8029] to
determine when to respond with an LSP Ping Echo reply message./____
/<new text end>/____
____
Les____
____
____
*From:*Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org
<mailto:rtg-bfd-boun...@ietf.org>] *On Behalf Of *Mach Chen
*Sent:* Tuesday, August 15, 2017 12:56 AM
*To:* Carlos Pignataro (cpignata); Greg Mirsky
*Cc:* Tom Nadeau; m...@ietf.org <mailto:m...@ietf.org>; Kireeti
Kompella (kire...@juniper.net <mailto:kire...@juniper.net>); Alia
Atlas; Reshad Rahman (rrahman); rtg-bfd@ietf. org
*Subject:* RE: [Technical Errata Reported] RFC5884 (5085)____
____
Hi all,____
____
IMHO, the point is not about whether the Echo Reply is optional for
a normal LSP Ping, where the echo reply is totally controlled by the
reply mode. ____
____
For RFC5884, since the reply mode is not specified, based on the
current text, it can be interpreted as the following two ways:____
1)it implies a new “mode” introduced, it’s actually a “special” LSP
Ping, the process is just as what is currently described in the
RFC: an Echo Reply is OPTINAL, whether and when to send Echo Reply
is up to the egress LSR, and the Ingress LSR should not assume an
Echo reply will be returned;____
2)the echo reply is still controlled by the reply mode, and given
that there is a “Do not reply” mode, the current text seems right,
but not that clear. ____
____
I incline to think way (2) is more nature, if so, the proposed
“Corrected Text” may not work if the Sender set the reply mode to
“Do not reply”.____
____
I’d suggest:____
____
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.____
____
NEW:____
The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
the BFD session. Whether to send an LSP Ping Echo reply message is ____
determined by the reply mode carried the received Echo request
message. ____
____
Best regards,____
Mach____
____
*From:*Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org
<mailto:rtg-bfd-boun...@ietf.org>] *On Behalf Of *Carlos Pignataro
(cpignata)
*Sent:* Tuesday, August 15, 2017 8:17 AM
*To:* Greg Mirsky <gregimir...@gmail.com <mailto:gregimir...@gmail.com>>
*Cc:* Tom Nadeau <tnad...@lucidvision.com
<mailto:tnad...@lucidvision.com>>; m...@ietf.org
<mailto:m...@ietf.org>; Kireeti Kompella (kire...@juniper.net
<mailto:kire...@juniper.net>) <kire...@juniper.net
<mailto:kire...@juniper.net>>; Alia Atlas <akat...@gmail.com
<mailto:akat...@gmail.com>>; Reshad Rahman (rrahman)
<rrah...@cisco.com <mailto:rrah...@cisco.com>>; rtg-bfd@ietf. org
<rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>>
*Subject:* Re: [Technical Errata Reported] RFC5884 (5085)____
____
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 <gregimir...@gmail.com
<mailto:gregimir...@gmail.com>> 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)
<cpign...@cisco.com <mailto:cpign...@cisco.com>> wrote:____
Jeff, WG, ____
____
I believe there is one additional consideration — please see
inline.____
____
On Aug 11, 2017, at 1:39 PM, Jeffrey Haas
<jh...@pfrc.org <mailto:jh...@pfrc.org>> 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.____
____
That’s’ up to
https://tools.ietf.org/html/rfc8029#section-4.4
<https://tools.ietf.org/html/rfc8029#section-4.4>____
____
Lacking a Reply Mode set to "Do not reply"
(https://tools.ietf.org/html/rfc8029#page-12
<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
<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, car...@cisco.com <mailto:car...@cisco.com>
/“Sometimes I use big words that I do not fully understand,
to make myself sound more photosynthesis."/____
____
____
