[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: [mpls] =?utf-8?b?562U5aSNOiBSZTogIFtUZWNobmljYWwgRXJyYXRhIFJlcG9y?= =?utf-8?q?ted=5D_RFC5884_=285085
From: <hu.fangwei () zte ! com ! cn>
Date: 2017-08-15 6:51:13
Message-ID: 201708151451136152764 () zte ! com ! cn
[Download RAW message or body]
[Attachment #2 (multipart/related)]
[Attachment #4 (multipart/alternative)]
[Attachment #6 (text/plain)]
Hi, I agree with Greg.
When egress LSR receices the LSP ping echo from ingress LSR, it will send the BFD \
control packet to establish the BFD session, which could be used to confirm the \
receving of LSP ping echo request. So It is not necessary for the LSP ping echo reply \
to report the verification. I think it is reasonable that the LSP ping echo reply is \
optional.
In addition, it is 7 years since the RFC 5884 was published in 2010. Vendors may \
implement the product based on RFC5884. If we changes the spec, it may bring the \
compatibility issues.
Regards.
Fangwei.
原始邮件
发件人： <cpignata@cisco.com>
收件人： <gregimirsky@gmail.com>
抄送人： <tnadeau@lucidvision.com> <mpls@ietf.org> <kireeti@juniper.net> \
<rrahman@cisco.com> <rtg-bfd@ietf.org> 日 期 ：2017年08月15日 08:18
主 题 ：Re: [mpls] [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 <gregimirsky@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) <cpignata@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 <jhaas@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
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, carlos@cisco.com
"Sometimes I use big words that I do not fully understand, to make myself sound more \
photosynthesis."
[Attachment #7 (text/html)]
<div class="zcontentRow"> <p>Hi, I agree with Greg. </p><p>When egress LSR \
receices the LSP ping echo from ingress LSR, it will send the BFD control packet to \
establish the BFD session, which could be used to confirm the receving of LSP ping \
echo request. So It is not necessary for the LSP ping echo reply to report the \
verification. <span style="line-height: 21px;">I think it is reasonable that \
the LSP ping echo reply is optional. </span></p><p>In addition, it is 7 \
years since the RFC 5884 was published in 2010. Vendors may implement the \
product based on RFC5884. If we changes the spec, it may bring \
the compatibility issues.</p><p>Regards.</p><p>Fangwei.</p><p><br></p><div><div \
class="zhistoryRow" style="display:block"><div class="zhistoryDes" style="width: \
100%; height: 28px; line-height: 28px; background-color: #E0E5E9; color: #1388FF; \
text-align: center;" language-data="HistoryOrgTxt">原始邮件</div><div \
id="zwriteHistoryContainer"><div class="control-group zhistoryPanel"><div \
class="zhistoryHeader" style="padding: 8px; background-color: #F5F6F8;"><div><strong \
language-data="HistorySenderTxt">发件人：</strong><span class="zreadUserName"> \
<cpignata@cisco.com>;</span></div><div><strong \
language-data="HistoryTOTxt">收件人：</strong><span class="zreadUserName" \
style="display: inline;"> <gregimirsky@gmail.com>;</span></div><div><strong \
language-data="HistoryCCTxt">抄送人：</strong><span class="zreadUserName" \
style="display: inline;"> <tnadeau@lucidvision.com>;</span><span \
class="zreadUserName" style="display: inline;"> <mpls@ietf.org>;</span><span \
class="zreadUserName" style="display: inline;"> \
<kireeti@juniper.net>;</span><span class="zreadUserName" style="display: \
inline;"> <rrahman@cisco.com>;</span><span class="zreadUserName" \
style="display: inline;"> <rtg-bfd@ietf.org>;</span></div><div><strong \
language-data="HistoryDateTxt">日 期 ：</strong><span class="">2017年08月15日 \
08:18</span></div><div><strong language-data="HistorySubjectTxt">主 题 \
：</strong><span class="zreadTitle"><strong>Re: [mpls] [Technical Errata Reported] \
RFC5884 (5085)</strong></span></div></div><p \
class="zhistoryContent"><br></p><div><meta http-equiv="Content-Type" \
content="text/html; charset=Windows-1252"><div>Greg,</div><br> <div \
id="AppleMailSignature">This is my final email on this topic, since the arguments are \
now just silly and not technically constructive. </div><br> <div \
id="AppleMailSignature">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!!</div><div \
id="AppleMailSignature">2. RFC 8029 obsoleted 4379. But to my recollection, nothing \
changed relevant to this Errata. </div><br> <div id="AppleMailSignature">BFD for \
MPLS could have updated LSP ping behavior -- it just didn't. </div><div \
id="AppleMailSignature"><br> Sent from my iPad</div><div><br> On Aug 14, 2017, at \
2:12 PM, Greg Mirsky <<a href="mailto:gregimirsky@gmail.com" \
target="_blank">gregimirsky@gmail.com</a>> wrote:<br> <br> </div><blockquote \
type="cite"><div><div dir="ltr">Hi Carlos,<div>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 "<span style="color:rgb(0,0,0);font-size:13.3333px">The Sender's Handle \
is filled in by the sender and returned unchanged </span><span \
style="color:rgb(0,0,0);font-size:13.3333px">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.</span></div><span \
style="color:rgb(0,0,0);font-size:13.3333px"><br> </span><div><span \
style="color:rgb(0,0,0);font-size:13.3333px">Regards,</span></div><div><span \
style="color:rgb(0,0,0);font-size:13.3333px">Greg</span></div><div \
class="gmail_extra"><br> <div class="gmail_quote">On Fri, Aug 11, 2017 at 7:45 PM, \
Carlos Pignataro (cpignata) <span dir="ltr"><<a href="mailto:cpignata@cisco.com" \
target="_blank">cpignata@cisco.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Jeff, WG,<br> \
<div>I believe there is one additional consideration — please see \
inline.</div><div><br> <div><span class="gmail-"> <blockquote type="cite"><div>On Aug \
11, 2017, at 1:39 PM, Jeffrey Haas <<a href="mailto:jhaas@pfrc.org" \
target="_blank">jhaas@pfrc.org</a>> wrote:</div><br \
class="gmail-m_1103480460771123016Apple-interchange-newline"> <div><div>[Note that I \
have adjusted the addresses in the headers to try to catch the<br> RFC authors' \
current accounts.]<br> <br> <br> The 5884 interop issue keeps bubbling up. \
Balaji submitted an errata, which<br> provides us with a good place to start \
technical discussion.<br> <br> Please note I also spent some time off-list discussing \
this errata with<br> Balaji.<br> <br> <br> On Thu, Aug 10, 2017 at 10:35:50PM -0700, \
RFC Errata System wrote:<br> <blockquote type="cite">Section: 6<br> <br> Original \
Text<br> -------------<br> The egress LSR MAY respond with an LSP Ping Echo<br> reply \
message that carries the local discriminator assigned by it for<br> the BFD \
session.<br> <br> Corrected Text<br> --------------<br> The egress LSR MUST respond \
with an LSP Ping Echo reply message that<br> MAY carry the local discriminator \
assigned by it for the BFD session.<br> <br> <br> Notes<br> -----<br> It is not clear \
from the original text which of the following is optional:<br> - The \
egress MUST send a reply, but the discriminator in the reply is optional<br> - \
The reply itself is optional<br> <br> Technically, the reply cannot be \
optional, because the egress needs to report LSP-Ping verification status to the \
ingress.<br> </blockquote></div></div></blockquote><br> </span> <div>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.</div><br> <div>That's' up to <a \
href="https://tools.ietf.org/html/rfc8029#section-4.4" \
target="_blank">https://tools.ietf.org/<wbr>html/rfc8029#section-4.4</a></div><br> \
<div>Lacking a Reply Mode set to "Do not reply" (<a \
href="https://tools.ietf.org/html/rfc8029#page-12" \
target="_blank">https://tools.ietf.org/html/<wbr>rfc8029#page-12</a>) the RFC 8029 \
procedures dictate a response be sent, independent of whether the RFC 5884 \
procedures use that information or not.</div><br> <div>More below.</div><span \
class="gmail-"><br> <blockquote type="cite"><div><div><blockquote type="cite"><br> \
The proposed text recommends to include BFD discriminator in the reply. This was the \
intent of the original text.<br> </blockquote><br> My opinion follows:<br> <br> In \
section 6 - <br> <br> : On receipt of the LSP Ping Echo request \
message, the egress LSR MUST<br> : send a BFD Control packet to the \
ingress LSR, if the validation of<br> : the FEC in the LSP Ping \
Echo request message succeeds. This BFD<br> : Control packet \
MUST set the Your Discriminator field to the<br> : discriminator \
received from the ingress LSR in the LSP Ping Echo<br> : request \
message. The egress LSR MAY respond with an LSP Ping Echo<br> : \
reply message that carries the local discriminator assigned by it \
for<br> : the BFD session. The local discriminator assigned \
by the egress LSR<br> : MUST be used as the My Discriminator field \
in the BFD session packets<br> : sent by the egress LSR.<br> <br> \
In the text above, I consider it quite clear that the receipt of the BFD<br> packet \
contains sufficient state to bring up the BFD session. The receipt<br> of the \
same Discriminator in the LSP Ping Echo Reply is optional.<br> <br> This makes sense \
partially because the reply may be dropped and we want the<br> BFD session to come up \
as fast as possible.<br> </div></div></blockquote><br> </span> <div>Yes, especially \
because the first sentence says that the egress sending a BFD Control packet implies \
FEC validation passed. However, <a \
href="https://tools.ietf.org/html/rfc8029#section-4.4" \
target="_blank">https://tools.ietf.<wbr>org/html/rfc8029#section-4.4</a> <wbr>does \
more than FEC validation.</div><span class="gmail-"><br> <blockquote \
type="cite"><div><div><br> The point of contention appears to be what to do if we \
*never* get such<br> replies. It's worth pointing out additional text in RFC \
5884, section 3.2.<br> <br> : Hence, BFD is used in conjunction \
with LSP Ping for MPLS LSP fault<br> : detection:<br> : <br> : \
i) LSP Ping is used for bootstrapping the BFD \
session as described<br> : \
later in this document.<br> : \
<br> : ii) BFD is used to exchange fault detection \
(i.e., BFD session)<br> : \
packets at the required \
detection interval.<br> : <br> : iii) LSP Ping is used to \
periodically verify the control plane<br> : \
against the data plane by \
ensuring that the LSP is mapped to<br> : \
the same FEC, at the egress, as \
the ingress.<br> <br> iii above reminds us that the LSP may be torn down because LSP \
Ping fails.<br> Thus, it seems problematic that we do not get a reply ever.<br> <br> \
However, with the BFD session in the Up state, we have information proving<br> that \
the LSP is up. Thus we have contradictory intent.<br> <br> ---<br> <br> My \
opinion is that the MAY in the RFC 5884 procedures is intended to have<br> the BFD \
session come up by the most expedient means. I do not believe the<br> likely \
intent was to say "don't send Echo Reply". Among other things, that<br> seems \
contrary to the intent of the general LSP Ping procedures.<br> <br> Having given my \
personal observations, we now get to the business of the<br> Working Group: Debating \
intent and related text. <br> <br> </div></div></blockquote><br> </span> \
<div>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</div><div>MAY carry the local discriminator assigned by it for the BFD \
session".</div><br> <div>In other words, I support this errata.</div><br> <div>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..</div><br> <div>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.</div><br> <div>Thanks,</div><br> <blockquote type="cite"><div><div>-- \
Jeff<br> <br> </div></div></blockquote></div><br> <div><div \
style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div \
style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div \
style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-tr \
ansform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">—</div><div \
style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">Carlos \
Pignataro, <a href="mailto:carlos@cisco.com" \
target="_blank">carlos@cisco.com</a><br> <br> <em>"Sometimes I use big words that I \
do not fully understand, to make myself sound more photosynthesis."</em><br> \
</div></div></div></div><br> </div></div></blockquote></div><br> \
</div></div></div></blockquote></div><p><br></p></div></div></div></div><p><br></p> \
</div>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic