Re: WGLC for draft-ietf-bfd-large-packets

[Greg Mirsky]

Dear Authors et al.,
thank you for delivering a well-written and useful specification. I support
the publication of the draft. One minor note on wording used in Section
4.3. I interpret "both sides of an interface", "each side of the interface"
as reference to a BFD peer. If that is the case, perhaps a minor editorial
update to the common terminology would be helpful.

Regards,
Greg

On Thu, May 9, 2024 at 1:18 PM Reshad Rahman  wrote:

> 
>
> BFD WG,
>
> This email (re)starts a 2 week Working Group Last Call for "BFD
> encapsulated in large packets":
> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/
>
>
> Please take the time to review the document and provide comments by May
> 24th. Feedback such as "I believe the document is ready to advance" is also
> welcome.
>
> FYI we did WGLC a few years ago, see previous discussions at
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/rjyxii23qp8-EQSZQ7d8631kMwY/
>
> There is no known IPR for this document:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/jaAjdrkePSocqvvcxt4ffx0NDg8/
>
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/0yfGFB-ywYQMQWledrRRLXhrVYY/
>
>
> Regards,
> Reshad (co-chair).
>
>
>
>
>
>

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

[Greg Mirsky]

Many thanks, Jeff. That was the last ask, I promise.

Regards,
Greg

On Wed, Jan 17, 2024 at 2:28 PM Jeffrey Haas  wrote:

> Greg,
>
>
> On Jan 17, 2024, at 4:43 PM, Greg Mirsky  wrote:
>
> Hi, Jeff et al.,
> upon more consideration of this draft, the write-up, and the related to
> the draft BBF liaison
> <https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/>,
> I would propose to include the reference to the liaison in the write-up.
> Perhaps the following update is acceptable:
> OLD TEXT:
> 5. In discussion over the document's intended status, Greg has expressed
> an opinion
> that the document should be Experimental rather than Proposed Standard.
> As noted
> in the IETF webpage, "Choosing between Informational and Experimental
> Status", it is
> the Shepherd's opinion that Experimental is inappropriate.  "The
> "Experimental"
> designation typically denotes a specification that is part of some
> research or
> development effort".  In this case, implementations are commercially
> available
> utilizing mechanisms largely similar to those being codified in this
> Internet-Draft.
> NEW TEXT:
> 5. In the discussion over the document's intended status, Greg has noted
> that the Broadband Forum,
> in its liaison For Information TR-146 and draft-ietf-bfd-unaffiliated-echo
> (https://datatracker.ietf.org/liaison/1775/)
> informed the IETF and BFD WG that "In our [Broadband Forum's] opinion, no
> future standardization
> is required to support TR-146." Greg also expressed an opinion
> that the document should be Experimental rather than Proposed Standard.
> As noted
> in the IETF webpage, "Choosing between Informational and Experimental
> Status", it is
> Shepherd's opinion is that Experimental is inappropriate.  "The
> "Experimental"
> designation typically denotes a specification that is part of some
> research or
> development effort".  In this case, implementations are commercially
> available
> utilizing mechanisms largely similar to those being codified in this
> Internet-Draft.
>
>
> The BBF liaison is referenced at the mail at the top of the shepherd's
> report.
> That said, I have no issue with the update you suggest and have
> implemented it in the shepherd's report.
>
> Thanks!
>
> -- Jeff
>
>

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

[Greg Mirsky]

Hi, Jeff et al.,
upon more consideration of this draft, the write-up, and the related to the
draft BBF liaison
<https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/>,
I would propose to include the reference to the liaison in the write-up.
Perhaps the following update is acceptable:
OLD TEXT:
5. In discussion over the document's intended status, Greg has expressed an
opinion
that the document should be Experimental rather than Proposed Standard.  As
noted
in the IETF webpage, "Choosing between Informational and Experimental
Status", it is
the Shepherd's opinion that Experimental is inappropriate.  "The
"Experimental"
designation typically denotes a specification that is part of some research
or
development effort".  In this case, implementations are commercially
available
utilizing mechanisms largely similar to those being codified in this
Internet-Draft.
NEW TEXT:
5. In the discussion over the document's intended status, Greg has noted
that the Broadband Forum,
in its liaison For Information TR-146 and draft-ietf-bfd-unaffiliated-echo (
https://datatracker.ietf.org/liaison/1775/)
informed the IETF and BFD WG that "In our [Broadband Forum's] opinion, no
future standardization
is required to support TR-146." Greg also expressed an opinion
that the document should be Experimental rather than Proposed Standard.  As
noted
in the IETF webpage, "Choosing between Informational and Experimental
Status", it is
Shepherd's opinion is that Experimental is inappropriate.  "The
"Experimental"
designation typically denotes a specification that is part of some research
or
development effort".  In this case, implementations are commercially
available
utilizing mechanisms largely similar to those being codified in this
Internet-Draft.

Regards,
Greg

On Mon, Jan 15, 2024 at 3:18 PM Greg Mirsky  wrote:

> Hi Jeff,
> thank you for your quick response to my comments. I appreciate the update
> you added to the Write-up.
>
> Regards,
> Greg
>
> On Mon, Jan 15, 2024 at 2:47 PM Jeffrey Haas  wrote:
>
>> Greg,
>>
>>
>> On Jan 15, 2024, at 5:15 PM, Greg Mirsky  wrote:
>>
>>- For several years I've actively participated in the work at BBF,
>>including the Working Area that published TR-146. I cannot recall that any
>>member company reported TR-146 implementation. Were there any on the BFD
>>mailing list that led to the following summary in the write-up:
>>
>> There are multiple implementations that claim some deployment of BBF
>> TR-146 implementation behavior.
>>
>>
>> If you're reading this as "claiming conformance to tr-146", that's not
>> what is written here.  Mostly because tr-146 was missing enough detail to
>> make it difficult for a BFD implementation to claim actual conformance.
>> That's to a great extent what the authors are attempting to rectify.
>>
>> In terms of the "BFD talking to itself over Echo", which is the
>> implementation behavior in question, we can publicly say that the Broadcom
>> implementation is certainly in the same family.  Juniper's BFD-Lite feature
>> is also in the same family.
>>
>> Having not asked for a conformance report vs. this document, I'm not
>> pointing out other vendors who have similar behaviors.  Certainly I'd
>> encourage others with information on their implementations to respond to
>> this thread.
>>
>>
>>- In the course of discussing this draft, I commented many times that
>>the proposed mechanism doesn't require any action from a BFD system 
>> outside
>>of a node that transmits and processes a probe. I suggested that, if
>>there's interest in publishing this draft, it be published as Experimental
>>or Informational, but not a Standard track document. I don't find that
>>point of the discussion reflected in the Shepherd write-up, or
>>affecting the intended status.
>>
>>
>> I've added the following point to the shepherds report.  Hopefully this
>> addresses your concern:
>>
>> 5. In discussion over the document's intended status, Greg has expressed an 
>> opinion
>> that the document should be Experimental rather than Proposed Standard.  As 
>> noted
>> in the IETF webpage, "Choosing between Informational and Experimental 
>> Status", it is
>> the Shepherd's opinion that Experimental is inappropriate.  "The 
>> "Experimental"
>> designation typically denotes a specification that is part of some research 
>> or
>> development effort".  In this case, implementations are commercially 
>> available
>> utilizing mechanisms largely sim

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

[Greg Mirsky]

Hi Jeff,
thank you for your quick response to my comments. I appreciate the update
you added to the Write-up.

Regards,
Greg

On Mon, Jan 15, 2024 at 2:47 PM Jeffrey Haas  wrote:

> Greg,
>
>
> On Jan 15, 2024, at 5:15 PM, Greg Mirsky  wrote:
>
>- For several years I've actively participated in the work at BBF,
>including the Working Area that published TR-146. I cannot recall that any
>member company reported TR-146 implementation. Were there any on the BFD
>mailing list that led to the following summary in the write-up:
>
> There are multiple implementations that claim some deployment of BBF
> TR-146 implementation behavior.
>
>
> If you're reading this as "claiming conformance to tr-146", that's not
> what is written here.  Mostly because tr-146 was missing enough detail to
> make it difficult for a BFD implementation to claim actual conformance.
> That's to a great extent what the authors are attempting to rectify.
>
> In terms of the "BFD talking to itself over Echo", which is the
> implementation behavior in question, we can publicly say that the Broadcom
> implementation is certainly in the same family.  Juniper's BFD-Lite feature
> is also in the same family.
>
> Having not asked for a conformance report vs. this document, I'm not
> pointing out other vendors who have similar behaviors.  Certainly I'd
> encourage others with information on their implementations to respond to
> this thread.
>
>
>- In the course of discussing this draft, I commented many times that
>the proposed mechanism doesn't require any action from a BFD system outside
>of a node that transmits and processes a probe. I suggested that, if
>there's interest in publishing this draft, it be published as Experimental
>or Informational, but not a Standard track document. I don't find that
>point of the discussion reflected in the Shepherd write-up, or
>affecting the intended status.
>
>
> I've added the following point to the shepherds report.  Hopefully this
> addresses your concern:
>
> 5. In discussion over the document's intended status, Greg has expressed an 
> opinion
> that the document should be Experimental rather than Proposed Standard.  As 
> noted
> in the IETF webpage, "Choosing between Informational and Experimental 
> Status", it is
> the Shepherd's opinion that Experimental is inappropriate.  "The 
> "Experimental"
> designation typically denotes a specification that is part of some research or
> development effort".  In this case, implementations are commercially available
> utilizing mechanisms largely similar to those being codified in this 
> Internet-Draft.
>
> While the procedures in this draft are purely local (the implementation 
> "talks to itself"),
> the behavior requires a violation of RFC 5880 
> <https://datatracker.ietf.org/doc/rfc5880/> with regard to Echo procedures 
> only
> being available after the Up state has been achieved in Asynchronous mode.
> It is thus the Chairs' opinion that the text permitting the relaxation of that
> requirement is appropriate to standardize for this document, and thus an 
> appropriate
> change of status requiring an update to RFC 5880 
> <https://datatracker.ietf.org/doc/rfc5880/>.
>
>
> -- Jeff
>
>

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

[Greg Mirsky]

Hi Jeff,
thank you for your kind words. I've read the write-up, and I have several
comments:

   - For several years I've actively participated in the work at BBF,
   including the Working Area that published TR-146. I cannot recall that any
   member company reported TR-146 implementation. Were there any on the BFD
   mailing list that led to the following summary in the write-up:

There are multiple implementations that claim some deployment of BBF TR-146
implementation behavior.


   - In the course of discussing this draft, I commented many times that
   the proposed mechanism doesn't require any action from a BFD system outside
   of a node that transmits and processes a probe. I suggested that, if
   there's interest in publishing this draft, it be published as Experimental
   or Informational, but not a Standard track document. I don't find that
   point of the discussion reflected in the Shepherd write-up, or
   affecting the intended status.

Regards,
Greg

On Mon, Jan 15, 2024 at 12:57 PM Jeffrey Haas  wrote:

> With deep apologies to the members of the Working Group for my tardiness,
> I've submitted this draft to the IESG.  This is after spending the
> afternoon
> reviewing the discussion to date and verifying the previously raised points
> have been addressed.
>
> Thank you in particular to Greg for your careful review on the draft.  The
> text benefited greatly from your attention.
>
> -- Jeff
>
>
> On Mon, Jan 15, 2024 at 12:54:45PM -0800, Jeffrey Haas via Datatracker
> wrote:
> > -UID: 254690
> >
> > Jeffrey Haas has requested publication of
> draft-ietf-bfd-unaffiliated-echo-10 as Proposed Standard on behalf of the
> BFD working group.
> >
> > Please verify the document's state at http
>
>

Fwd: I-D Action: draft-mirsky-bfd-mpls-demand-15.txt

[Greg Mirsky]

Dear All,
I believe that in this updated version I address the recent comments from
Jeff Haas. Also, cleaned the idnits.
Welcome your comments and questions.
The draft reflects the use of the BFD Demand mode over p2p MPLS LSP and, as
such, complements RFC 5884. Appreciate the consideration of the WG AP.

Regards,
Greg

-- Forwarded message -
From: 
Date: Thu, Nov 9, 2023 at 1:19 PM
Subject: I-D Action: draft-mirsky-bfd-mpls-demand-15.txt
To: 
Cc: 


Internet-Draft draft-mirsky-bfd-mpls-demand-15.txt is now available. It is a
work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF.

   Title:   BFD in Demand Mode over a Point-to-Point MPLS LSP
   Author:  Greg Mirsky
   Name:draft-mirsky-bfd-mpls-demand-15.txt
   Pages:   5
   Dates:   2023-11-09

Abstract:

   This document describes procedures for using Bidirectional Forwarding
   Detection (BFD) in Demand mode to detect data plane failures in
   Multiprotocol Label Switching (MPLS) point-to-point Label Switched
   Paths.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-15.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-mirsky-bfd-mpls-demand-15

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

Re: Comments on draft-ietf-bfd-unaffiliated-echo-08

[Greg Mirsky]

Hi Xiao Min and Ketan,
thank you for your thoughtful consideration of my note; much appreciated.
Both proposed updates are acceptable to me. If the Authors accept the text
suggested by Ketan, then we can close this issue.

Regards,
Greg

On Thu, Sep 28, 2023 at 12:17 AM Ketan Talaulikar 
wrote:

> I would like to make a suggestion to the authors:
>
> OLD:
> Note that this method monitors the liveness of a node not including the
> availability of a specific IP address at that node.
>
> NEW:
> Note that this method monitors the connectivity to a system over a
> specific interface and does not verify the availability of a specific IP
> address at that system.
>
> My originally suggested text was not using the terminologies from RFC5880.
> Greg, I hope this revised text addresses your concern?
>
> Thanks,
> Ketan
>
>
> On Thu, Sep 28, 2023 at 2:43 AM Greg Mirsky  wrote:
>
>> Hi Xiao Min,
>> thank you for your expedient response. Please find my notes below tagged
>> GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Tue, Sep 26, 2023 at 6:37 PM  wrote:
>>
>>> Hi Greg,
>>>
>>>
>>> Please see inline.
>>> Original
>>> *From: *GregMirsky 
>>> *To: *Ketan Talaulikar ;
>>> *Cc: *肖敏10093570;rtg-bfd WG ;
>>> draft-ietf-bfd-unaffiliated-e...@ietf.org <
>>> draft-ietf-bfd-unaffiliated-e...@ietf.org>;
>>> *Date: *2023年09月27日 02:21
>>> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08*
>>> Hi Ketan,
>>> Thank you for sharing your interpretation of the introduced text. I
>>> agree that your view is in line with how the scope of BFD is defined in RFC
>>> 5880:
>>>
>>>  protocol intended to detect faults in thebidirectional path between 
>>> two forwarding engines, includinginterfaces, data link(s), and to the 
>>> extent possible the forwardingengines themselves
>>>
>>> But it is not clear to me how "liveness of a node" is retated to the 
>>> definition above. I hope thr Authors will clarify that for me.
>>> [XM]>>> In my understanding it's the liveness of the forwarding engine.
>>> Do you expect s/the liveness of a node/the liveness of a node over the 
>>> specific interface as Ketan clarified?
>>>
>>> GIM>>  I think that the Unaffiliated BFD and BFD, in general, do not
>> detect defects on the nodal level. Thus, the "liveness of a node" seems
>> inaccurate, overstretching the scope of BFD as defined in RFC 5880. I
>> suggest referring to the definition of the BFD from RFC 5880 or providing
>> an explanation of how the Unaffiliated BFD extends the defect detection
>> domain up to the nodal scope.
>>
>> Regards,
>> Greg
>>
>>>
>>> Best Regards,
>>> Xiao Min
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>> On Tue, Sep 26, 2023, 09:56 Ketan Talaulikar 
>>> wrote:
>>>
>>>> Hi Greg,
>>>> I would read it as " ... the liveness of a node over the specific
>>>> interface ..." i.e, the node is reachable and responding over that
>>>> interface.
>>>>
>>>> Thanks,
>>>> Ketan
>>>>
>>>>
>>>> On Tue, Sep 26, 2023 at 7:16 PM Greg Mirsky 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> as I understand it, the update assigns to the Unaffiliated BFD a new
>>>>> functionality, monitoring "the liveness of a node not including the
>>>>> availability of a specific IP address at that node". In my opinion, that
>>>>> raises some questions:
>>>>>
>>>>>-
>>>>>
>>>>>What is "the liveness of a node"?
>>>>>-
>>>>>
>>>>>When referring to the liveness of a node, does it applicable to
>>>>>a single-box system or also to a virtual, distributed, e.g., the one 
>>>>> using
>>>>>the CUPS paradigm?
>>>>>-
>>>>>
>>>>>How the liveness of a node is derived from the functionality of a
>>>>>single interface? Is it equally applicable regardless the interface is
>>>>>physical or virtual?
>>>>>
>>>>> Thank you for your consideration.
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Tue, Sep 2

Re: Comments on draft-ietf-bfd-unaffiliated-echo-08

[Greg Mirsky]

Hi Xiao Min,
thank you for your expedient response. Please find my notes below tagged
GIM>>.

Regards,
Greg

On Tue, Sep 26, 2023 at 6:37 PM  wrote:

> Hi Greg,
>
>
> Please see inline.
> Original
> *From: *GregMirsky 
> *To: *Ketan Talaulikar ;
> *Cc: *肖敏10093570;rtg-bfd WG ;
> draft-ietf-bfd-unaffiliated-e...@ietf.org <
> draft-ietf-bfd-unaffiliated-e...@ietf.org>;
> *Date: *2023年09月27日 02:21
> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08*
> Hi Ketan,
> Thank you for sharing your interpretation of the introduced text. I agree
> that your view is in line with how the scope of BFD is defined in RFC 5880:
>
>  protocol intended to detect faults in thebidirectional path between two 
> forwarding engines, includinginterfaces, data link(s), and to the extent 
> possible the forwardingengines themselves
>
> But it is not clear to me how "liveness of a node" is retated to the 
> definition above. I hope thr Authors will clarify that for me.
> [XM]>>> In my understanding it's the liveness of the forwarding engine.
> Do you expect s/the liveness of a node/the liveness of a node over the 
> specific interface as Ketan clarified?
>
> GIM>>  I think that the Unaffiliated BFD and BFD, in general, do not
detect defects on the nodal level. Thus, the "liveness of a node" seems
inaccurate, overstretching the scope of BFD as defined in RFC 5880. I
suggest referring to the definition of the BFD from RFC 5880 or providing
an explanation of how the Unaffiliated BFD extends the defect detection
domain up to the nodal scope.

Regards,
Greg

>
> Best Regards,
> Xiao Min
>
>
> Regards,
>
> Greg
>
>
> On Tue, Sep 26, 2023, 09:56 Ketan Talaulikar 
> wrote:
>
>> Hi Greg,
>> I would read it as " ... the liveness of a node over the specific
>> interface ..." i.e, the node is reachable and responding over that
>> interface.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Tue, Sep 26, 2023 at 7:16 PM Greg Mirsky 
>> wrote:
>>
>>> Hi,
>>> as I understand it, the update assigns to the Unaffiliated BFD a new
>>> functionality, monitoring "the liveness of a node not including the
>>> availability of a specific IP address at that node". In my opinion, that
>>> raises some questions:
>>>
>>>-
>>>
>>>What is "the liveness of a node"?
>>>-
>>>
>>>When referring to the liveness of a node, does it applicable to
>>>a single-box system or also to a virtual, distributed, e.g., the one 
>>> using
>>>the CUPS paradigm?
>>>-
>>>
>>>How the liveness of a node is derived from the functionality of a
>>>single interface? Is it equally applicable regardless the interface is
>>>physical or virtual?
>>>
>>> Thank you for your consideration.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Tue, Sep 26, 2023 at 5:38 AM Ketan Talaulikar 
>>> wrote:
>>>
>>>> Thanks Xiao Min - the update looks good and addresses my comments.
>>>> Thanks,
>>>> Ketan
>>>>
>>>> On Tue, Sep 26, 2023 at 12:58 PM  wrote:
>>>>
>>>>> Hi Ketan,
>>>>>
>>>>>
>>>>> Thank you for the suggested text, very helpful.
>>>>>
>>>>> I've just posted a new revision that incorporates all your comments.
>>>>> Link as below.
>>>>>
>>>>>
>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09>
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09
>>>>>
>>>>>
>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09>Please
>>>>> see inline with [XM-2]>>>.
>>>>> Original
>>>>> *From: *KetanTalaulikar 
>>>>> *To: *肖敏10093570;
>>>>> *Cc: *draft-ietf-bfd-unaffiliated-e...@ietf.org <
>>>>> draft-ietf-bfd-unaffiliated-e...@ietf.org>;rtg-bfd@ietf.org <
>>>>> rtg-bfd@ietf.org>;jh...@pfrc.org ;
>>>>> *Date: *2023年09月25日 15:37
>>>>> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08*
>>>>> Hi Xiao Min,
>>>>> Thanks for your response. Please check inline below for further
>>>>> suggestions.
>>>>>
>>>>> On Mon, Sep 25, 2023 at 11:41 AM  wrote:
>&

Re: Comments on draft-ietf-bfd-unaffiliated-echo-08

[Greg Mirsky]

Hi Ketan,
Thank you for sharing your interpretation of the introduced text. I agree
that your view is in line with how the scope of BFD is defined in RFC 5880:

 protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves

But it is not clear to me how "liveness of a node" is retated to the
definition above. I hope thr Authors will clarify that for me.


Regards,

Greg


On Tue, Sep 26, 2023, 09:56 Ketan Talaulikar  wrote:

> Hi Greg,
>
> I would read it as " ... the liveness of a node over the specific
> interface ..." i.e, the node is reachable and responding over that
> interface.
>
> Thanks,
> Ketan
>
>
> On Tue, Sep 26, 2023 at 7:16 PM Greg Mirsky  wrote:
>
>> Hi,
>> as I understand it, the update assigns to the Unaffiliated BFD a new
>> functionality, monitoring "the liveness of a node not including the
>> availability of a specific IP address at that node". In my opinion, that
>> raises some questions:
>>
>>- What is "the liveness of a node"?
>>- When referring to the liveness of a node, does it applicable to
>>a single-box system or also to a virtual, distributed, e.g., the one using
>>the CUPS paradigm?
>>- How the liveness of a node is derived from the functionality of a
>>single interface? Is it equally applicable regardless the interface is
>>physical or virtual?
>>
>> Thank you for your consideration.
>>
>> Regards,
>> Greg
>>
>> On Tue, Sep 26, 2023 at 5:38 AM Ketan Talaulikar 
>> wrote:
>>
>>> Thanks Xiao Min - the update looks good and addresses my comments.
>>>
>>> Thanks,
>>> Ketan
>>>
>>> On Tue, Sep 26, 2023 at 12:58 PM  wrote:
>>>
>>>> Hi Ketan,
>>>>
>>>>
>>>> Thank you for the suggested text, very helpful.
>>>>
>>>> I've just posted a new revision that incorporates all your comments.
>>>> Link as below.
>>>>
>>>>
>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09>
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09
>>>>
>>>>
>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09>Please
>>>> see inline with [XM-2]>>>.
>>>> Original
>>>> *From: *KetanTalaulikar 
>>>> *To: *肖敏10093570;
>>>> *Cc: *draft-ietf-bfd-unaffiliated-e...@ietf.org <
>>>> draft-ietf-bfd-unaffiliated-e...@ietf.org>;rtg-bfd@ietf.org <
>>>> rtg-bfd@ietf.org>;jh...@pfrc.org ;
>>>> *Date: *2023年09月25日 15:37
>>>> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08*
>>>> Hi Xiao Min,
>>>> Thanks for your response. Please check inline below for further
>>>> suggestions.
>>>>
>>>> On Mon, Sep 25, 2023 at 11:41 AM  wrote:
>>>>
>>>>> Dear Ketan,
>>>>>
>>>>>
>>>>> Thanks for your review and thoughtful comments.
>>>>> Please see inline.
>>>>> Original
>>>>> *From: *KetanTalaulikar 
>>>>> *To: *draft-ietf-bfd-unaffiliated-e...@ietf.org <
>>>>> draft-ietf-bfd-unaffiliated-e...@ietf.org>;
>>>>> *Cc: *rtg-bfd@ietf.org ;Jeffrey Haas >>>> >;
>>>>> *Date: *2023年09月22日 22:55
>>>>> *Subject: **Comments on draft-ietf-bfd-unaffiliated-echo-08*
>>>>> Hello Authors,
>>>>>
>>>>> Looks like I've missed the WGLC on this document, but nevertheless
>>>>> would like to share the following comments:
>>>>>
>>>>> Sec 1 of the document says:
>>>>>
>>>>> Section 5 of [RFC5880
>>>>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5880>
>>>>> ] indicates that the payload of an affiliated BFD Echo packet is a
>>>>> local matter and hence its contents are outside the scope of that
>>>>> specification. This document, on the other hand, specifies the contents of
>>>>> the Unaffiliated BFD Echo packet and what to do with them.
>>>>>
>>>>> However, when I go through the procedures in Section 2, there is no
>>>>> description of the actual construction of the IP packet that A sends out 
>>>

Re: Comments on draft-ietf-bfd-unaffiliated-echo-08

[Greg Mirsky]

Hi,
as I understand it, the update assigns to the Unaffiliated BFD a new
functionality, monitoring "the liveness of a node not including the
availability of a specific IP address at that node". In my opinion, that
raises some questions:

   - What is "the liveness of a node"?
   - When referring to the liveness of a node, does it applicable to
   a single-box system or also to a virtual, distributed, e.g., the one using
   the CUPS paradigm?
   - How the liveness of a node is derived from the functionality of a
   single interface? Is it equally applicable regardless the interface is
   physical or virtual?

Thank you for your consideration.

Regards,
Greg

On Tue, Sep 26, 2023 at 5:38 AM Ketan Talaulikar 
wrote:

> Thanks Xiao Min - the update looks good and addresses my comments.
>
> Thanks,
> Ketan
>
> On Tue, Sep 26, 2023 at 12:58 PM  wrote:
>
>> Hi Ketan,
>>
>>
>> Thank you for the suggested text, very helpful.
>>
>> I've just posted a new revision that incorporates all your comments. Link
>> as below.
>>
>>
>> 
>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09
>>
>>
>> Please
>> see inline with [XM-2]>>>.
>> Original
>> *From: *KetanTalaulikar 
>> *To: *肖敏10093570;
>> *Cc: *draft-ietf-bfd-unaffiliated-e...@ietf.org <
>> draft-ietf-bfd-unaffiliated-e...@ietf.org>;rtg-bfd@ietf.org <
>> rtg-bfd@ietf.org>;jh...@pfrc.org ;
>> *Date: *2023年09月25日 15:37
>> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08*
>> Hi Xiao Min,
>> Thanks for your response. Please check inline below for further
>> suggestions.
>>
>> On Mon, Sep 25, 2023 at 11:41 AM  wrote:
>>
>>> Dear Ketan,
>>>
>>>
>>> Thanks for your review and thoughtful comments.
>>> Please see inline.
>>> Original
>>> *From: *KetanTalaulikar 
>>> *To: *draft-ietf-bfd-unaffiliated-e...@ietf.org <
>>> draft-ietf-bfd-unaffiliated-e...@ietf.org>;
>>> *Cc: *rtg-bfd@ietf.org ;Jeffrey Haas ;
>>> *Date: *2023年09月22日 22:55
>>> *Subject: **Comments on draft-ietf-bfd-unaffiliated-echo-08*
>>> Hello Authors,
>>>
>>> Looks like I've missed the WGLC on this document, but nevertheless would
>>> like to share the following comments:
>>>
>>> Sec 1 of the document says:
>>>
>>> Section 5 of [RFC5880
>>> 
>>> ] indicates that the payload of an affiliated BFD Echo packet is a
>>> local matter and hence its contents are outside the scope of that
>>> specification. This document, on the other hand, specifies the contents of
>>> the Unaffiliated BFD Echo packet and what to do with them.
>>>
>>> However, when I go through the procedures in Section 2, there is no
>>> description of the actual construction of the IP packet that A sends out to
>>> B - what is the source and destination IP - or MAC addresses for that
>>> matter? How is it that B would loop it back? I believe it is important for
>>> the document to specify this.
>>>
>>> [XM]>>> This document does specify the source and destination IP,
>>> through reference to RFC 5881. In section 2 it says
>>>
>>> "Regarding the selection of IP address, the rules stated in Section 4
>>> of [RFC5881 ] are applicable
>>> to the encapsulation of an Unaffiliated BFD Echo packet."
>>>
>>> In -07 version the rules of RFC 5881 were restated, however in -08
>>> version they're removed by following the suggestion from Greg.
>>>
>> KT> I missed that conversation. One small suggestion so it covers not
>> just IP address but also MAC.
>>
>> OLD: Regarding the selection of IP address, the rules stated in Section
>> 4 of [RFC5881
>> 
>> ] are applicable to the encapsulation of an Unaffiliated BFD Echo
>> packet.
>>
>> NEW: An Unaffiliated BFD Echo packet follows the same encapsulation rules
>> as for a BFD Echo packet as specified in Section 4 of [RFC5881
>> 
>> ].
>>
>> [XM-2]>>> Accepted.
>>
>>
>>
>>> Another important part is that normally BFD verifies the bidirectional
>>> path, the liveness of the other endpoint, but also validates the presence
>>> of a specific IP at that endpoint. Is that still the case when operating in
>>> this mode? This question arises since the document talks about liveness to
>>> servers - so is it monitoring liveness to the server host or a specific
>>> server IP?
>>>
>>> [XM]>>> It's monitoring liveness to the server host, not a specific
>>> server IP. Also note that the Unaffiliated BFD Echo can be used for
>>> multiple use cases, in section 1 it says
>>>
>>> "Section 6.2.2 of [BBF-TR-146
>>> ] describes
>>> one use case of the Unaffiliated BFD Echo. Section 2 of [
>>> 

Re: [spring] Discussion on [draft-lin-bfd-path-consistency-over-sr]

[Greg Mirsky]

Hi Changwang,
thank you for your prompt response to my comments at the IETF-117. I think
that this draft is also relevant for the work of the BFD WG and I have
invited its experts to the discussion. I agree with the base premise of the
draft that it is essential to control the reverse path of an x-BFD session.
But I also believe that such control is easier to realize for BFD sessions
in Asynchronous mode, as defined in RFC 5880. Please find my notes below
tagged GIM>>.

Regards,
Greg

On Mon, Jul 31, 2023 at 7:30 AM linchangwang 
wrote:

>
>
> Hello Greg,
>
>
>
> From minutes-117-spring/:
>
> 10:15 S-BFD Path Consistency over SRv6 (10 mins)
>
> Presenter: Changwang Lin
> draft-lin-sbfd-path-consistency-over-srv6
> <https://datatracker.ietf.org/doc/draft-lin-sbfd-path-consistency-over-srv6/>
>
> Greg Mirsky: Current version of the WG draft about the U-BFD, U-BFD is
> only applicable to single hop.
>
> Not sure it is applicable to your scenario which has more than
> single link.
>
> How this mapping between Segment List1 and Segment List2 occurs on a
> system (reflector or echo-reflector) that receives a BFD packet?
>
> All the processing is in the forwarding plane, so in fact the BFD is not
> involved.
>
> Joel: More details, complicated, so we need to take it to the mailing list.
>
>
>
> Thank you for your comments ，here is my response：
>
> 1.  Regarding question 1: It is true that the current version of the
> [ietf-bfd-unaffiliated-echo] draft only specifies the single hop scenario.
>
> However, it is worth noting that U-BFD can support multiple hops, for
> example, by setting the TTL to 64. Therefore, U-BFD can also be used to
> detect the seglist path in an SR policy.
>
GIM>> Let me quote from Section 2 of draft-ietf-bfd-unaffiliated-echo
<https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/>:
   All
   Unaffiliated BFD Echo packets for the session MUST be sent with a
   Time to Live (TTL) or Hop Limit value of 255, and received with a TTL
   or Hop Limit value of 254, otherwise the received packets MUST be
   dropped [RFC5082].
I don't see how, as you suggest, a conformant U-BFD implementation can set
TTL/Hop Limit to any value other than 255 or not drop the received packet
if the value of its TTL/Hop Limit field is anything but 254. Or, perhaps
you are planning to update the current U-BFD specification?

>
>
> 2.  Regarding question 2:
>
>  [draft-ietf-idr-sr-policy-path-segment] extends BGP SR Policy to
> distribute SR policies with carrying Path Segment and bidirectional path
>
> information. Through this extension, when distributing SR policy to the
> headend, reverse path information and path segment of segment list could be
> carried
>
> together.
>
> For example：
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Using path segment and reverse path segment to establish a mapping table.
>
> Using the mapping table to get segment list by reverse Path segment.
>
>
>
> 1) Regarding SBFD, at the reflection end, the reverse seglist can be
> obtained through the path-segment mechanism.
>
GIM>> As I understand RFC 7880, its goal is not to create any state related
to SBFDReflector. On the other hand, mapping between a particular Path
Segment SID and the Reverse Path Segment List does create such state and,
as a result, defeats the idea of RFC 7880. At the same time, binding the
reverse path of a BFD session in the Asynchronous mode in SR-MPLS can be
easily achieved using, for example, MPLS LSP Ping extensions defined in
draft-ietf-mpls-bfd-directed
<https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/> and
draft-ietf-spring-bfd
<https://datatracker.ietf.org/doc/draft-ietf-spring-bfd/>.

> 2) For U-BFD, the complete reverse segment list can be distributed to the
> head node along with the segment list.
>
> This reverse segment list can be used to specify the return path for
> U-BFD. Consequently, the return path can be encapsulated at the head end.
>
GIM>> As I've noted earlier, I believe that U-BFD, as it is defined at this
time, cannot be used in SRv6 as suggested
in draft-lin-sbfd-path-consistency-over-srv6.

>
>
>
>
> 3.  Regarding question 3：
>
> By utilizing the extension for SR Policy defined in 【
> draft-ietf-idr-sr-policy-path-segment】:
>
> 1)  By using Path Segment and Segment-Based Forwarding (SBFD) to
> encapsulate and forward packets along a forward path, the path-segment is
> included in the encapsulation.At the reflector node, this path-segment
> information is used to lookup the reverse path-segment, which helps to
>

Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt

[Greg Mirsky]

Hi Xiao Min,
thank you for your constructive consideration of my comments. I am glad
that we have converged on technical issues. Minor remaining, in my opinion,
can remain in the "let's agree to disagree" category. I have added
two notes below, tagged GIM4>>.
In conclusion, I think that if the document is switched to Experimental
(which seems like the most logical to me) or Informational, then perhaps it
then doesn't need to update RFC 5880 altogether but define a new,
standalone Unaffiated BFD function, using some of the mechanisms defined in
RFC 5880.

Regards,
Greg

On Thu, May 18, 2023 at 10:55 AM  wrote:

> Hi Greg,
>
>
> Thank you for the comprehensive and detailed discussion, which improves
> this document in many aspects.
>
> I'll post a new version draft after we reach agreement on the last few
> points.
>
> Please see inline [XM-4]>>>.
> Original
> *From: *GregMirsky 
> *To: *肖敏10093570;
> *Cc: *rtg-bfd@ietf.org ;
> *Date: *2023年05月18日 12:22
> *Subject: **Re: Fw: New Version Notification for
> draft-ietf-bfd-unaffiliated-echo-07.txt*
> Hi Xiao Min,
> thank you for your thoughtful consideration of my notes. I greatly
> appreciate it and our discussion that helps us to come to resolutions.
> Please find my follow-up notes tagged GIM3>>.
>
> Best regards,
> Greg
>
> On Sun, May 14, 2023 at 11:47 PM  wrote:
>
>> Hi Greg,
>>
>>
>> The points we have converged are trimmed, because I received a notice
>> from rtg-bfd-ow...@ietf.org that "Message body is too big".
>>
>> Please see inline [XM-3]>>>.
>>
>>> Original

-

It is stated in the Abstract:

BFD Async procedures can be executed over the BFD

Echo port where the neighboring system only loops packets back to the

local system.

 Is this conclusion differs from the definition of the BFD Echo function
 in RFC 5880? If it is not, what is the value of such a re-statement? If it
 is, it seems like an explicit attribution of this conclusion to this
 document would be helpful.
 [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over
 the BFD Echo port because it classifies BFD Echo as an affiliated function.
 Would you please suggest some text you think helpful?

 GIM>> I am a bit confused by the "BFD Async procedures" term. In your
>>> opinion, what are these procedures defined in RFC 5880? BFD state machine?
>>> BFD state changes? I believe it would help me if you could give an example,
>>> and add more details to the interpretation of that term.
>>>
>>> [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his
>>> comments on -05 version of this draft [1]. My understanding to the term is
>>> that the BFD Control packet and the procedure on demultiplexing it, as well
>>> as the BFD state machine and the procedure on changing the state are mostly
>>> reused.
>>>
>>> [1]
>>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/
>>>
>> GIM2>> I imagine that we expect a reader of this document to be familiar
>> with RFCs 5880 and 5881. AFAIK, neither of these RFCs uses the term "BFD
>> Async procedures". If that is correct, then any new term must be explained
>> or defined in this document. Would you agree?
>>
>> [XM-3]>>> Is s/BFD Async procedures/BFD Control packet and its processing
>> procedures more clear?
>>
> GIM3>> Yes, that would address my concern.
>
> [XM-4]>>> OK. Will make the change.
>
>>

-

Is the following a requirement or an observation:

a network device must be able to quickly detect

faults in communication with adjacent devices.

 If the former, please capitalize the normative language. If the latter,
 then it appears as an arguable view. Indeed, in some cases, local
 protection is a viable option, while in other environments, e2e path
 protection might be preferable.
 [XM]>>> At the beginning of the sentence "in some cases" can be added,
 is that acceptable to you?

 GIM>> I think that the capability to faster detection of a network
>>> failure is always desirable. Thus, the statement can be presented as a
>>> general node requirement. On the other hand, it can be worded as an
>>> observation. Using normative keywords in a lowercase form might confuse
>>> readers.
>>>
>>> [XM-2]>>> I'd like to try again. Please see the proposed changes as
>>> below.
>>>
>>> OLD
>>>
>>>To minimize the impact of device/link faults on services and improve
>>> network availability, a network device must be able to quickly detect
>>> faults in communication with adjacent devices.
>>>
>>> NEW
>>>
>>>To minimize the impact of device/link faults on services and improve
>>> network availability, in some cases a network device needs to be able to 
>>> quickly detectfaults in communication with adjacent devices.
>>>
>>> GIM2>> In your opinion, how important to the document and this text is
>> it to say "in 

Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt

[Greg Mirsky]

Hi Xiao Min,
thank you for your thoughtful consideration of my notes. I greatly
appreciate it and our discussion that helps us to come to resolutions.
Please find my follow-up notes tagged GIM3>>.

Best regards,
Greg

On Sun, May 14, 2023 at 11:47 PM  wrote:

> Hi Greg,
>
>
> The points we have converged are trimmed, because I received a notice from
> rtg-bfd-ow...@ietf.org that "Message body is too big".
>
> Please see inline [XM-3]>>>.
>
>> Original
>>>
>>>-
>>>
>>>It is stated in the Abstract:
>>>
>>>BFD Async procedures can be executed over the BFD
>>>
>>>Echo port where the neighboring system only loops packets back to the
>>>
>>>local system.
>>>
>>> Is this conclusion differs from the definition of the BFD Echo function
>>> in RFC 5880? If it is not, what is the value of such a re-statement? If it
>>> is, it seems like an explicit attribution of this conclusion to this
>>> document would be helpful.
>>> [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over
>>> the BFD Echo port because it classifies BFD Echo as an affiliated function.
>>> Would you please suggest some text you think helpful?
>>>
>>> GIM>> I am a bit confused by the "BFD Async procedures" term. In your
>> opinion, what are these procedures defined in RFC 5880? BFD state machine?
>> BFD state changes? I believe it would help me if you could give an example,
>> and add more details to the interpretation of that term.
>>
>> [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his
>> comments on -05 version of this draft [1]. My understanding to the term is
>> that the BFD Control packet and the procedure on demultiplexing it, as well
>> as the BFD state machine and the procedure on changing the state are mostly
>> reused.
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/
>>
> GIM2>> I imagine that we expect a reader of this document to be familiar
> with RFCs 5880 and 5881. AFAIK, neither of these RFCs uses the term "BFD
> Async procedures". If that is correct, then any new term must be explained
> or defined in this document. Would you agree?
>
> [XM-3]>>> Is s/BFD Async procedures/BFD Control packet and its processing
> procedures more clear?
>
GIM3>> Yes, that would address my concern.

>
>>>
>>>-
>>>
>>>Is the following a requirement or an observation:
>>>
>>>a network device must be able to quickly detect
>>>
>>>faults in communication with adjacent devices.
>>>
>>> If the former, please capitalize the normative language. If the latter,
>>> then it appears as an arguable view. Indeed, in some cases, local
>>> protection is a viable option, while in other environments, e2e path
>>> protection might be preferable.
>>> [XM]>>> At the beginning of the sentence "in some cases" can be added,
>>> is that acceptable to you?
>>>
>>> GIM>> I think that the capability to faster detection of a network
>> failure is always desirable. Thus, the statement can be presented as a
>> general node requirement. On the other hand, it can be worded as an
>> observation. Using normative keywords in a lowercase form might confuse
>> readers.
>>
>> [XM-2]>>> I'd like to try again. Please see the proposed changes as below.
>>
>> OLD
>>
>>To minimize the impact of device/link faults on services and improve
>> network availability, a network device must be able to quickly detect
>> faults in communication with adjacent devices.
>>
>> NEW
>>
>>To minimize the impact of device/link faults on services and improve
>> network availability, in some cases a network device needs to be able to 
>> quickly detectfaults in communication with adjacent devices.
>>
>> GIM2>> In your opinion, how important to the document and this text is it
> to say "in some cases"? Personally, I think that the ability to quickly
> detect a network failure is a generic requirement, essential in all
> scenarios.
>
> [XM-3]>>> Please note that "in some cases" is derived from your comments
> "Indeed, in some cases, local protection is a viable option, while in other
> environments, e2e path protection might be preferable". The text focuses on
> the communication with adjacent devices, so "in some cases" is used, does
> that make sense to you?
>
GIM3>> It seems like my note confused you. I was pointing out that in some
cases operator may use local protection; in others - e2e. And, in some
cases, both protection methods thus effectively creating a multi-layer OAM
environment. But the ability to quickly detect network failure is critical
in all cases. I hope that clarifies my views.

>
>>>
>>>-
>>>
>>>Further, in Introduction, I read:
>>>
>>>Section 5 of
>>>[RFC5880] indicates that the payload of a BFD Echo packet is a local
>>>matter and hence its contents are outside the scope of that
>>>specification.  This document, on the other hand, specifies the
>>>contents of the Echo packets and what to do with them.
>>>
>>> It seems to me that 

Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt

[Greg Mirsky]

Hi Xiao Min,
thank you for your consideration of my comments. I have added follow-up
notes under the GIM2>> tag below.

Regards,
Greg

On Tue, May 9, 2023 at 8:54 PM  wrote:

> Hi Greg,
>
>
> Please see inline...
> Original
> *From: *GregMirsky 
> *To: *肖敏10093570;
> *Cc: *rtg-bfd@ietf.org ;
> *Date: *2023年05月10日 00:02
> *Subject: **Re: Fw: New Version Notification for
> draft-ietf-bfd-unaffiliated-echo-07.txt*
> Hi Xiao Min,
> thank you for your expedient response. Please find my follow-up notes
> below tagged GIM>>.
>
> Regards,
> Greg
>
> On Thu, May 4, 2023 at 12:28 AM  wrote:
>
>> Hi Greg,
>>
>>
>> Thank you for the detailed review and comments, although I don't think
>> your comments justify your conclusion.
>>
>> Please see inline...
>> Original
>> *From: *GregMirsky 
>> *To: *肖敏10093570;
>> *Cc: *rtg-bfd@ietf.org ;
>> *Date: *2023年04月29日 03:42
>> *Subject: **Re: Fw: New Version Notification for
>> draft-ietf-bfd-unaffiliated-echo-07.txt*
>> Hi Xiao Min,
>> thank you for sharing updates. I've read the new version and have several
>> questions and comments.
>>
>>-
>>
>>It is stated in the Abstract:
>>
>>BFD Async procedures can be executed over the BFD
>>
>>Echo port where the neighboring system only loops packets back to the
>>
>>local system.
>>
>> Is this conclusion differs from the definition of the BFD Echo function
>> in RFC 5880? If it is not, what is the value of such a re-statement? If it
>> is, it seems like an explicit attribution of this conclusion to this
>> document would be helpful.
>> [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over
>> the BFD Echo port because it classifies BFD Echo as an affiliated function.
>> Would you please suggest some text you think helpful?
>>
>> GIM>> I am a bit confused by the "BFD Async procedures" term. In your
> opinion, what are these procedures defined in RFC 5880? BFD state machine?
> BFD state changes? I believe it would help me if you could give an example,
> and add more details to the interpretation of that term.
>
> [XM-2]>>> The "BFD Async procedures" term was introduced by Jeff in his
> comments on -05 version of this draft [1]. My understanding to the term is
> that the BFD Control packet and the procedure on demultiplexing it, as well
> as the BFD state machine and the procedure on changing the state are mostly
> reused.
>
> [1]
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/JN4DpQjiudBGUJn8beapEwuhlH0/
>
GIM2>> I imagine that we expect a reader of this document to be familiar
with RFCs 5880 and 5881. AFAIK, neither of these RFCs uses the term "BFD
Async procedures". If that is correct, then any new term must be explained
or defined in this document. Would you agree?

>
>>
>>-
>>
>>Is the following a requirement or an observation:
>>
>>a network device must be able to quickly detect
>>
>>faults in communication with adjacent devices.
>>
>> If the former, please capitalize the normative language. If the latter,
>> then it appears as an arguable view. Indeed, in some cases, local
>> protection is a viable option, while in other environments, e2e path
>> protection might be preferable.
>> [XM]>>> At the beginning of the sentence "in some cases" can be added, is
>> that acceptable to you?
>>
>> GIM>> I think that the capability to faster detection of a network
> failure is always desirable. Thus, the statement can be presented as a
> general node requirement. On the other hand, it can be worded as an
> observation. Using normative keywords in a lowercase form might confuse
> readers.
>
> [XM-2]>>> I'd like to try again. Please see the proposed changes as below.
>
> OLD
>
>To minimize the impact of device/link faults on services and improve
>network availability, a network device must be able to quickly detect
>faults in communication with adjacent devices.
>
> NEW
>
>To minimize the impact of device/link faults on services and improve
>network availability, in some cases a network device needs to be able to 
> quickly detect
>faults in communication with adjacent devices.
>
> GIM2>> In your opinion, how important to the document and this text is it
to say "in some cases"? Personally, I think that the ability to quickly
detect a network failure is a generic requirement, essential in all
scenarios.

>
>>
>>-
>>
>>Further, in Introduction, I read:
>>
>>Section 5 of
>>[RFC5880] indicates that the payload of a BFD Echo packet is a local
>>matter and hence its contents are outside the scope of that
>>specification.  This document, on the other hand, specifies the
>>contents of the Echo packets and what to do with them.
>>
>> It seems to me that this draft is positioned as the definition of the
>> content of an Echo message and the processing of it, whether as an
>> unaffiliated or affiliated (RTC5880-style) function. Is that correct?
>> [XM]>>> That's incorrect. This document specifies only Unaffiliated BFD
>> Echo, and  it doesn't touch 

Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt

[Greg Mirsky]

Hi Xiao Min,
thank you for your expedient response. Please find my follow-up notes below
tagged GIM>>.

Regards,
Greg

On Thu, May 4, 2023 at 12:28 AM  wrote:

> Hi Greg,
>
>
> Thank you for the detailed review and comments, although I don't think
> your comments justify your conclusion.
>
> Please see inline...
> Original
> *From: *GregMirsky 
> *To: *肖敏10093570;
> *Cc: *rtg-bfd@ietf.org ;
> *Date: *2023年04月29日 03:42
> *Subject: **Re: Fw: New Version Notification for
> draft-ietf-bfd-unaffiliated-echo-07.txt*
> Hi Xiao Min,
> thank you for sharing updates. I've read the new version and have several
> questions and comments.
>
>-
>
>It is stated in the Abstract:
>
>BFD Async procedures can be executed over the BFD
>
>Echo port where the neighboring system only loops packets back to the
>
>local system.
>
> Is this conclusion differs from the definition of the BFD Echo function in
> RFC 5880? If it is not, what is the value of such a re-statement? If it is,
> it seems like an explicit attribution of this conclusion to this document
> would be helpful.
> [XM]>>> RFC 5880 doesn't say BFD Async procedures can be executed over the
> BFD Echo port because it classifies BFD Echo as an affiliated function.
> Would you please suggest some text you think helpful?
>
> GIM>> I am a bit confused by the "BFD Async procedures" term. In your
opinion, what are these procedures defined in RFC 5880? BFD state machine?
BFD state changes? I believe it would help me if you could give an example,
and add more details to the interpretation of that term.

>
>
>-
>
>Is the following a requirement or an observation:
>
>a network device must be able to quickly detect
>
>faults in communication with adjacent devices.
>
> If the former, please capitalize the normative language. If the latter,
> then it appears as an arguable view. Indeed, in some cases, local
> protection is a viable option, while in other environments, e2e path
> protection might be preferable.
> [XM]>>> At the beginning of the sentence "in some cases" can be added, is
> that acceptable to you?
>
> GIM>> I think that the capability to faster detection of a network failure
is always desirable. Thus, the statement can be presented as a general node
requirement. On the other hand, it can be worded as an observation. Using
normative keywords in a lowercase form might confuse readers.

>
>
>-
>
>Further, in Introduction, I read:
>
>Section 5 of
>[RFC5880] indicates that the payload of a BFD Echo packet is a local
>matter and hence its contents are outside the scope of that
>specification.  This document, on the other hand, specifies the
>contents of the Echo packets and what to do with them.
>
> It seems to me that this draft is positioned as the definition of the
> content of an Echo message and the processing of it, whether as an
> unaffiliated or affiliated (RTC5880-style) function. Is that correct?
> [XM]>>> That's incorrect. This document specifies only Unaffiliated BFD
> Echo, and  it doesn't touch affiliated BFD Echo.
>
> GIM>> Thank you for the clarification. I feel that the current text and
its location are unclear. Reiterating the scope of the proposed solution
will certainly make it clearer.

>
>
>-
>
>I hope you can help me understand the demultiplexing of Unaffiliated
>BFD sessions:
>
>Device A performs its
>initial demultiplexing of a Unaffiliated BFD Echo session using the
>source IP address or UDP source port, once the remote system echoes
>back the local discriminator, all further received packets are
>demultiplexed based on the "Your Discriminator" field only, which is
>conformed to the procedure specified in Section 6.3 of [RFC5880].
>
>
>-
>
>Does "initial demultiplexing" refers to the first BFD Control message
>transmitted in the Unaffiliated BFD Echo mode?
>
>[XM]>>> Not exactly. Actually "initial demultiplexing" is applied to
>the received BFD Control packet(s) whose "Your Discriminator" is zero.
>
> GIM>> Perhaps that can be added to the document as "In the case when the
value of Your Discriminator in the received packet is zero, demultiplexing
is done based on ..."?

>
>-
>
>Considering that "device B would not intercept any received
>Unaffiliated BFD Echo packet", how "the remote system echoes back the local
>discriminator"?
>
>[XM]>>> Here "echoes back" means "loops back", is "loops back" more
>clear?
>
> GIM>> I think it is better, thank you.

>
>-
>
>
>
>
>-
>
>A lengthy copy of a text from Section 4 of RFC 5881 seems like
>unnecessary:
>
>the destination address MUST be chosen in such a way as to
>cause the remote system to forward the packet back to the local
>system.  The source address MUST be chosen in such a way as to
>preclude the remote system from generating ICMP or Neighbor Discovery
>Redirect messages.  In particular, the source address SHOULD NOT be
>

Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt

[Greg Mirsky]

Hi Xiao Min,
thank you for sharing updates. I've read the new version and have several
questions and comments.

   - It is stated in the Abstract:

   BFD Async procedures can be executed over the BFD

   Echo port where the neighboring system only loops packets back to the

   local system.

Is this conclusion differs from the definition of the BFD Echo function in
RFC 5880? If it is not, what is the value of such a re-statement? If it is,
it seems like an explicit attribution of this conclusion to this document
would be helpful.


   - Is the following a requirement or an observation:

   a network device must be able to quickly detect

   faults in communication with adjacent devices.

If the former, please capitalize the normative language. If the latter,
then it appears as an arguable view. Indeed, in some cases, local
protection is a viable option, while in other environments, e2e path
protection might be preferable.


   - Further, in Introduction, I read:

   Section 5 of
   [RFC5880] indicates that the payload of a BFD Echo packet is a local
   matter and hence its contents are outside the scope of that
   specification.  This document, on the other hand, specifies the
   contents of the Echo packets and what to do with them.

It seems to me that this draft is positioned as the definition of the
content of an Echo message and the processing of it, whether as an
unaffiliated or affiliated (RTC5880-style) function. Is that correct?


   - I hope you can help me understand the demultiplexing of Unaffiliated
   BFD sessions:

   Device A performs its
   initial demultiplexing of a Unaffiliated BFD Echo session using the
   source IP address or UDP source port, once the remote system echoes
   back the local discriminator, all further received packets are
   demultiplexed based on the "Your Discriminator" field only, which is
   conformed to the procedure specified in Section 6.3 of [RFC5880].


   - Does "initial demultiplexing" refers to the first BFD Control message
   transmitted in the Unaffiliated BFD Echo mode?
   - Considering that "device B would not intercept any received
   Unaffiliated BFD Echo packet", how "the remote system echoes back the local
   discriminator"?


   - A lengthy copy of a text from Section 4 of RFC 5881 seems like
   unnecessary:

   the destination address MUST be chosen in such a way as to
   cause the remote system to forward the packet back to the local
   system.  The source address MUST be chosen in such a way as to
   preclude the remote system from generating ICMP or Neighbor Discovery
   Redirect messages.  In particular, the source address SHOULD NOT be
   part of the subnet bound to the interface over which the BFD Echo
   packet is being transmitted, and it SHOULD NOT be an IPv6 link-local
   address, unless it is known by other means that the remote system
   will not send Redirects.

It seems that a reference to that section and something like "rules stated
in Section 4 [RFC5881] are applicable to the encapsulation of an
Unaffiliated BFD Echo Control message" could be sufficient.


   - What is the interpretation of "expected value"? It appears that none
   of these values are used, but are ignored. Right?
   - A zero value of the Required Min Echo RX Interval field per RFC 5880
   is interpreted as no support for the Echo function. But it is the
   recommended value. Although it is ignored. Thus, what is the benefit of
   initializing the field after all?
   - In the description

   Afterwards, the
   provisioned transmission interval is used.

What is the event that triggers the "afterward" transition?


   - With the high number of "this value MUST be ignored on receipt", "the
   Unaffiliated BFD Echo packet reuses the format of the BFD Control packet
   defined in [RFC5880]" seems like a severe overstatement.
   - Which event triggers the transition in

   *  Your Discriminator MUST be set to 0 initially, and then MUST be
  set to the same as My Discriminator echoed back.


   - What happens if Desired Min TX Interval, Required Min RX Interval,
   or Required Min Echo is not set to "the expected value"?

In conclusion. As we learned from the BBF Liason, the Broadband Forum is
not seeking standardization of the mechanism described in TR-146. Also, I
learned about the implementation of the mechanism described in
BBF's TR-146, and the authors are not interested in standardization either,
as, in their opinion, there's no externally noticeable behavior that
requires specification. So, I still don't see any value in standardizing
what is described in the document.

Regards,
Greg

On Sun, Apr 23, 2023 at 7:16 PM  wrote:

> Dear BFD WG,
>
>
> A -07 revision of draft-ietf-bfd-unaffiliated-echo has been posted,
> attempting to address all the WGLC comments.
>
> The main updates are as below.
>
> * add a sentence to clarify that this document doesn't change the
> affiliated BFD Echo function.
>
> * change the order of section 2 "Updates to RFC 5880" and 

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Greg Mirsky]

Hi Jeff,
I am not trying to stop this work but understand what is being standardized
by this document. So far, I don't see that there's anything that goes
outside of the BFD system that transmits self-addressed IP/UDP packets. The
fact that there are implementations using self-addressed IP/UDP packets
seems like a weak argument for standardization, especially since there's no
interoperability among network systems to be defined. Of course, that is my
personal opinion.
Also, a note in-line below under the GIM>> tag.

Regards,
Greg

On Fri, Apr 14, 2023 at 3:31 PM Jeffrey Haas  wrote:

> Greg,
>
>
> > On Apr 14, 2023, at 6:23 PM, Greg Mirsky  wrote:
> >
> > Hi Jeff,
> > thank you for your kind consideration of the proposal. Indeed, leaving a
> chunk of memory unchanged is a privacy issue. As I understand the proposal,
> none of the fields defined in RFC 5880 for the BFD Control message is used
> for demultiplexing BFD sessions and/or packet validation. Is that correct?
>
> The Discriminator field is used for demux.  Authentication is utilized, if
> present.
>
GIM>> My understanding of the draft in regard to the use of the
Discriminator (I assume My Discriminator) field is different. Although the
draft refers to the Discriminators as "demultiplexing fields":
   Once a BFD Unaffiliated Echo session is created on device A, it
   starts sending BFD Unaffiliated Echo packets, which MUST include BFD
   Unaffiliated Echo session demultiplexing fields, such as BFD "Your
   Discriminator" and/or "My Discriminator" defined in [RFC5880].
it later states that demultiplexing is done based on IP and UDP
encapsulation:
   Device A performs its initial demultiplexing of a BFD Unaffiliated
   Echo session using the source IP address or UDP source port.
Am I missing something?

>
>
> > If that is the case, what is the need to use the BFD Control message
> altogether? And one more step, What is the benefit of using a well-known
> BFD Echo UDP port number? I believe that using a well-known port increases
> the security risk rather than bringing any benefits. From what I understand
> in the application of the mechanism, the sender can use a UDP port number
> assigned from the dynamic/private range of port numbers. And the payload
> can be anything, i.e., filled with bit pattern randomly chosen by the
> Sender. Am I missing something?
>
> Please note you're trying to fight up the slope of the mountain.  This
> feature exists and has long been shipping in various forms already.  Our
> goal here is to try to take the less precise descriptions of the feature
> and apply some IETF rigor to it.  Thanks for helping with that effort.
>
> Recall that the point is that using the BFD echo port in packet loopback
> mode and sending BFD Async packets within it is largely "talking to
> yourself".  The device running this proposal is still running BFD, using as
> much of the BFD Async machinery as makes sense in the mode.  The time
> fields are, as you note, useless.  However, the authentication,
> discriminator fields let an implementation still do demux and
> authentication without having to write new code.
>
> BFD Echo mode was intentionally underspecified to allow implementations to
> decide what they're going to put in the packets.  Implementation
> considerations of BFD Echo have always had the concerns for:
> - Is this packet actually sourced by the implementation
> - Is spoofing happening
> - How do you handle demux when there might be multiple sessions?
>
> The fact that this information is part of the BFD control messages has
> clearly been a convenience to multiple implementations of Echo.
>
> This document simply formalizes one flavor of it.
>
> -- Jeff
>
>

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Greg Mirsky]

Hi Jeff,
thank you for your kind consideration of the proposal. Indeed, leaving a
chunk of memory unchanged is a privacy issue. As I understand the proposal,
none of the fields defined in RFC 5880 for the BFD Control message is used
for demultiplexing BFD sessions and/or packet validation. Is that correct?
If that is the case, what is the need to use the BFD Control message
altogether? And one more step, What is the benefit of using a well-known
BFD Echo UDP port number? I believe that using a well-known port increases
the security risk rather than bringing any benefits. From what I understand
in the application of the mechanism, the sender can use a UDP port number
assigned from the dynamic/private range of port numbers. And the payload
can be anything, i.e., filled with bit pattern randomly chosen by the
Sender. Am I missing something?

Regards,
Greg

On Thu, Apr 13, 2023 at 1:13 PM Jeffrey Haas  wrote:

> Greg,
>
> In general, I think your clarifications are helpful.
> The one point I have minor disagreement is "SHOULD be
> populated/initialized" ... to what?
> One option is "an expected value".
> Personally, I'd find "an expected value. A suggested value is ..." and use
> the defaults below.
>
> That said,  I don't have a strong opinion that we must use some magic
> value.  My desire is that we avoid unset values being a potential vector
> for disclosure of uninitialized memory.
>
> -- Jeff
>
> On Apr 12, 2023, at 4:10 PM, Greg Mirsky  wrote:
>
> Hi Jeff,
> thank you for your response. It seems to me that the values of these
> fields are implementation specific and don't impact interoperability. If
> that is correct, then I propose the following updates:
> OLD TEXT:
>Within the BFD Unaffiliated Echo packet, the "Desired Min TX
>Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD
>be populated with a value of 1 second (1,000,000 microseconds).
>These values, however, are ignored and not used to calculate the
>Detection Time.
> NEW TEXT:
>Within the BFD Unaffiliated Echo packet, the "Desired Min TX
>Interval" and "Required Min RX Interval" defined in [RFC5880], SHOULD
>be initialized before the transmission and MUST be ignored on receipt.
>Furthermore, these values MUST NOT be used to calculate the
>Detection Time.
>
> OLD TEXT:
>The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set
>to zero.
> NEW TEXT:
>The "Required Min Echo RX Interval" defined in [RFC5880] SHOULD be set
>before the transmission and MUST be ignored upon receipt.
>
> Regards,
> Greg
>
>
> On Wed, Apr 12, 2023 at 8:00 AM Jeffrey Haas  wrote:
>
>> Greg,
>>
>> Flipping the question around somewhat:
>>
>> These portions of the PDU will be serialized onto the wire.
>> An implementation could choose values locally to help its own
>> procedures.  Perhaps for heuristic tuning of the session.  So, there's
>> argument for "these values are left to the implementation" - or as you note
>> "this value is ignored".
>>
>> What text would YOU want to see present in this draft?
>>
>> In the absence of an implementation having an opinion about the behavior
>> for its own purposes, I believe we want some boring "expected" value
>> minimally as implementation advice.  IMO, that's one step nicer than
>> whatever memory noise is left from your allocated buffer that might
>> disclose something unexpected from your implementation internals.  (See
>> various virtualized host environment bugs relating to memory ownership.)
>>
>> -- Jeff
>>
>>
>>
>>
>> On Apr 12, 2023, at 10:22 AM, Greg Mirsky  wrote:
>>
>> Dear, Authors and all,
>> my apologies for the belated comments. I greatly appreciate your
>> consideration of the notes below:
>>
>>- Given that it is stated that the values of "Desired Min TX
>>Interval" and "Required Min RX Interval" in an Unaffiliated BFD Echo
>>message are ignored, what do you see as the value of using the normative
>>language in:
>>
>>Within the BFD Unaffiliated Echo packet, the "Desired Min TX
>>Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD
>>be populated with a value of 1 second (1,000,000 microseconds).
>>
>>
>>- As I understand it, the "Required Min Echo RX Interval" value is
>>not used in the Unaffiliated BFD Echo. If that is the case, what do you 
>> see
>>as the value of requiring it to be zeroed:
>>
>>

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Greg Mirsky]

Hi Jeff,
thank you for your response. It seems to me that the values of these fields
are implementation specific and don't impact interoperability. If that is
correct, then I propose the following updates:
OLD TEXT:
   Within the BFD Unaffiliated Echo packet, the "Desired Min TX
   Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD
   be populated with a value of 1 second (1,000,000 microseconds).
   These values, however, are ignored and not used to calculate the
   Detection Time.
NEW TEXT:
   Within the BFD Unaffiliated Echo packet, the "Desired Min TX
   Interval" and "Required Min RX Interval" defined in [RFC5880], SHOULD
   be initialized before the transmission and MUST be ignored on receipt.
   Furthermore, these values MUST NOT be used to calculate the
   Detection Time.

OLD TEXT:
   The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set
   to zero.
NEW TEXT:
   The "Required Min Echo RX Interval" defined in [RFC5880] SHOULD be set
   before the transmission and MUST be ignored upon receipt.

Regards,
Greg


On Wed, Apr 12, 2023 at 8:00 AM Jeffrey Haas  wrote:

> Greg,
>
> Flipping the question around somewhat:
>
> These portions of the PDU will be serialized onto the wire.
> An implementation could choose values locally to help its own procedures.
> Perhaps for heuristic tuning of the session.  So, there's argument for
> "these values are left to the implementation" - or as you note "this value
> is ignored".
>
> What text would YOU want to see present in this draft?
>
> In the absence of an implementation having an opinion about the behavior
> for its own purposes, I believe we want some boring "expected" value
> minimally as implementation advice.  IMO, that's one step nicer than
> whatever memory noise is left from your allocated buffer that might
> disclose something unexpected from your implementation internals.  (See
> various virtualized host environment bugs relating to memory ownership.)
>
> -- Jeff
>
>
>
>
> On Apr 12, 2023, at 10:22 AM, Greg Mirsky  wrote:
>
> Dear, Authors and all,
> my apologies for the belated comments. I greatly appreciate your
> consideration of the notes below:
>
>- Given that it is stated that the values of "Desired Min TX Interval"
>and "Required Min RX Interval" in an Unaffiliated BFD Echo message are
>ignored, what do you see as the value of using the normative language in:
>
>Within the BFD Unaffiliated Echo packet, the "Desired Min TX
>Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD
>be populated with a value of 1 second (1,000,000 microseconds).
>
>
>- As I understand it, the "Required Min Echo RX Interval" value is not
>used in the Unaffiliated BFD Echo. If that is the case, what do you see as
>the value of requiring it to be zeroed:
>
>The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set
>
>to zero.
>
> Perhaps stating that the "Required Min Echo RX Interval" value is ignored
> in the Unaffiliated BFD Echo is sufficient. WDYT?
>
>
> Regards,
> Greg
>
> On Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas  wrote:
>
>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
>>
>> Working Group,
>>
>> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has
>> completed.  My judgment is that it has weak, but positive support to
>> proceed to publication.  This isn't atypical of BFD work at this point in
>> the BFD Working Group's life.
>>
>> The next steps for the document:
>>
>> 1. Please continue to iterate through the issues raised during last
>> call.  I will be summarizing them in the original WGLC thread.  I suspect
>> we can reach conclusion for them shortly.
>>
>> 2. Each of the authors needs to make an attestation as to whether they're
>> aware of any additional IPR applicable to this document.  The rest of the
>> Working Group, as per BCP 78/79[1] should also disclose of any applicable
>> IPR if they're aware of it.
>>
>> One thing that makes this document particularly interesting is that this
>> work is covered partially under work done in BBF in TR-146.  This will be
>> noted in the shepherd writeup.
>>
>>
>> -- Jeff
>>
>> [1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1
>>
>>
>>
>

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Greg Mirsky]

Dear All,
after reading the document once more, I've realized that I need help with a
paragraph in Section 3. Please find my notes in-lined in the original text
below under the GIM>> tag:
   Once a BFD Unaffiliated Echo session is created on device A, it
   starts sending BFD Unaffiliated Echo packets, which MUST include BFD
   Unaffiliated Echo session demultiplexing fields, such as BFD "Your
   Discriminator" and/or "My Discriminator" defined in [RFC5880].
GIM>> It seems like the requirement is not clear on which fields must be
initialized by the device A - Your Discriminator, My  Discriminator, or
both. Furthermore, these fields are characterized as demultiplexing,
although the next sentence states that demultiplexing is based on the
source IP address or UDP source port number. If that is the case, what is
the role of discriminators in demultiplexing BFD Unaffiliated Echo sessions?
   Device A performs its initial demultiplexing of a BFD Unaffiliated
   Echo session using the source IP address or UDP source port.
GIM>> Does the source IP address sufficient to demultiplex BFD Unaffiliated
Echo sessions? Consider the case that Interface 1 is connected to a
broadcast link. Can there be multiple BFD Unaffiliated sessions off
Interface 1?
   Device
   A would send BFD Unaffiliated Echo packets with IP destination
   address destined for itself, such as the IP address of interface 1 of
   device A.
GIM>> Is "such as" in the sentence above used as "for example" or "that is"?
GIM>> And a general observation on the terminology. It seems like "device
A" is used as a short version of "BFD system hosted on device A". If that
is correct, perhaps that can be explained in the Terminology section
(although it is missing in the current version of the draft).

Regards,
Greg

On Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas  wrote:

> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
>
> Working Group,
>
> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has
> completed.  My judgment is that it has weak, but positive support to
> proceed to publication.  This isn't atypical of BFD work at this point in
> the BFD Working Group's life.
>
> The next steps for the document:
>
> 1. Please continue to iterate through the issues raised during last call.
> I will be summarizing them in the original WGLC thread.  I suspect we can
> reach conclusion for them shortly.
>
> 2. Each of the authors needs to make an attestation as to whether they're
> aware of any additional IPR applicable to this document.  The rest of the
> Working Group, as per BCP 78/79[1] should also disclose of any applicable
> IPR if they're aware of it.
>
> One thing that makes this document particularly interesting is that this
> work is covered partially under work done in BBF in TR-146.  This will be
> noted in the shepherd writeup.
>
>
> -- Jeff
>
> [1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1
>
>
>

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Greg Mirsky]

Dear, Authors and all,
my apologies for the belated comments. I greatly appreciate your
consideration of the notes below:

   - Given that it is stated that the values of "Desired Min TX Interval"
   and "Required Min RX Interval" in an Unaffiliated BFD Echo message are
   ignored, what do you see as the value of using the normative language in:

   Within the BFD Unaffiliated Echo packet, the "Desired Min TX
   Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD
   be populated with a value of 1 second (1,000,000 microseconds).


   - As I understand it, the "Required Min Echo RX Interval" value is not
   used in the Unaffiliated BFD Echo. If that is the case, what do you see as
   the value of requiring it to be zeroed:

   The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set

   to zero.

Perhaps stating that the "Required Min Echo RX Interval" value is ignored
in the Unaffiliated BFD Echo is sufficient. WDYT?


Regards,
Greg

On Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas  wrote:

> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
>
> Working Group,
>
> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has
> completed.  My judgment is that it has weak, but positive support to
> proceed to publication.  This isn't atypical of BFD work at this point in
> the BFD Working Group's life.
>
> The next steps for the document:
>
> 1. Please continue to iterate through the issues raised during last call.
> I will be summarizing them in the original WGLC thread.  I suspect we can
> reach conclusion for them shortly.
>
> 2. Each of the authors needs to make an attestation as to whether they're
> aware of any additional IPR applicable to this document.  The rest of the
> Working Group, as per BCP 78/79[1] should also disclose of any applicable
> IPR if they're aware of it.
>
> One thing that makes this document particularly interesting is that this
> work is covered partially under work done in BBF in TR-146.  This will be
> noted in the shepherd writeup.
>
>
> -- Jeff
>
> [1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1
>
>
>

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Greg Mirsky]

Hi Jeff,
I got confused by the "any additional IPR applicable to this document" in
the announcement. AFAIK, there is no IPR disclosure for the
draft-cw-bfd-unaffiliated-echo
, nor for
the draft-ietf-bfd-unaffiliated-echo
. Have
I missed something?

Regards,
Greg

On Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas  wrote:

> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
>
> Working Group,
>
> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has
> completed.  My judgment is that it has weak, but positive support to
> proceed to publication.  This isn't atypical of BFD work at this point in
> the BFD Working Group's life.
>
> The next steps for the document:
>
> 1. Please continue to iterate through the issues raised during last call.
> I will be summarizing them in the original WGLC thread.  I suspect we can
> reach conclusion for them shortly.
>
> 2. Each of the authors needs to make an attestation as to whether they're
> aware of any additional IPR applicable to this document.  The rest of the
> Working Group, as per BCP 78/79[1] should also disclose of any applicable
> IPR if they're aware of it.
>
> One thing that makes this document particularly interesting is that this
> work is covered partially under work done in BBF in TR-146.  This will be
> noted in the shepherd writeup.
>
>
> -- Jeff
>
> [1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1
>
>
>

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Greg Mirsky]

Hi Jeff,
thank you for your thoughtful response. Please find my notes below under
the GIM>> tag.

Regards,
Greg


On Thu, Apr 6, 2023 at 7:36 AM Jeffrey Haas  wrote:

> Greg,
>
>
> On Mar 27, 2023, at 1:40 AM, Greg Mirsky  wrote:
>
> Dear Authors,
> I read the latest version of the draft. I appreciate your work on
> improving its readability. I have several concerns and appreciate your
> consideration:
>
>- It appears like the document defines the format of the Echo message.
>As I understand the RFC 5880, the format of the Echo message is not
>specified in the RFC 5880. It seems like by defining the format in this
>document, you affect RFC 5880 compliance of implementations that do support
>RFC 5880 as it exists today.
>
> One way to alternatively view this is we're documenting what one
> implementation puts in its Echo packets.  This draft does not try to
> require that all BFD Echo implementations use these procedures.
>
GIM>> That is an interesting perspective. If that is the purpose of this
specification, then the amount of updates it requires seems excessive. On
the other hand, if the group agrees to reflect such intention in the draft,
it will alleviate my concern. Furthermore, if that is the position
explicitly communicated in the draft, making it Experimental seems like the
next logical step.

>
>
>- The draft, in my opinion, significantly changes the architecture of
>the BFD, as it is defined in RFC 5880. I believe that characterizing Echo
>as a function stresses its dependency from a BFD mode, Asynchronous and
>Demand. The changes proposed in this draft are very extensive and severely
>affect the existing architecture of BFD by setting the Echo function on
>par, unrelated with the BFD modes.
>
>
> Interesting.  My view has been that this mechanism leverages existing BFD
> Async procedures to avoid trying to completely invent new mechanisms for
> the unafilliated case.  Where I might have some level of agreement with
> your point is this "mode" needs to be clearly defined from a configuration
> standpoint.  For example, how would it manifest in YANG?
>
GIM>> It seems that we have different views. I consider the limitation of
using the Echo function, specified in RFC 5880, only after the session
reaches the Up state as a part of the BFD security mechanism. Personally, I
would encourage not to use a well-known UDP port for the type of operation
described in the draft. I think it would be more secure to use a port
number from the dynamic range. Defining that function as a new optional BFD
function without severely updating RFC 5880, in my opinion, is a safer path.

>
>
>- Also, I think that the normative language in the last paragraph of
>the Secrity Considerations sections are too soft. Currently used
>recommendation level, in my opinion, is insufficient and should be brought
>to the requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD
>NOT/SHALL NOT/
>
>
> I'd recommend that you show the explicit sections you want updated.
>
GIM>> Thank you for pointing that out for me. Below are the proposed
updates:
OLD TEXT:
   In order to mitigate the potential reflector attack by the remote
   attackers, or infinite loop of the BFD Unaffiliated Echo packets,
   it's RECOMMENDED to put two requirements, also known as Generalized
   TTL Security Mechanism (GTSM) [RFC5082], on the device looping BFD
   Unaffiliated Echo packets, the first one is that a packet SHOULD NOT
   be looped unless it has a TTL or Hop Limit value of 255, and the
   second one is that a packet being looped MUST NOT reset the TTL or
   Hop Limit value to 255, and MUST use a TTL or Hop Limit value of 254.
NEW TEXT:
   In order to mitigate the potential reflector attack by the remote
   attackers, or infinite loop of the BFD Unaffiliated Echo packets,
   this specification puts two requirements, also known as Generalized
   TTL Security Mechanism (GTSM) [RFC5082], on the device looping BFD
   Unaffiliated Echo packets, the first one is that a packet MUST NOT
   be looped unless it has a TTL or Hop Limit value of 255, and the
   second one is that a packet being looped MUST NOT reset the TTL or
   Hop Limit value to 255, and MUST use a TTL or Hop Limit value of 254.


 Using version -06:
> - I would not personally suggest that the RECOMMENDED for authentication
> turn into a MUST.  BFD Authentication simply isn't used in enough
> circumstances to try to turn this into the default case, especially when
> the intent of this feature is to deal with systems that don't have a
> matching BFD on the opposite side.
> - I not super supportive of the SHOULD NOT for the TTL 255 loop being
> upgraded to SHALL NOT.  This will likely make a number of existing
> deployments of this feature non-conformant.
>
> Please note that I expect to have a repeat of this conversation with the
> security AD during review.  So, your comments are apropos.
>
> -- Jeff
>
>

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Greg Mirsky]

Hi Jeff,
I hope you will agree with my using your response to continue the
discussion. Please find my notes below under the GIM2>> tag. I will respond
to other discussion topics in another follow-up mail.

Regards,
Greg

On Thu, Apr 6, 2023 at 7:28 AM Jeffrey Haas  wrote:

> Xiao Min,
>
> Thanks for addressing Greg's comments.  I some additional comment on
> Greg's points:
>
GIM2>> I greatly appreciate the attention Xiao Min extended to my comments.

>
>
> On Apr 6, 2023, at 3:35 AM,  
> wrote:
>
>-
>
>The draft describes how the destination IP address of the Echo packet
>is set. Are there any special considerations for selecting IPv6 destination
>address?
>
>[XM]>>> The draft currently says "Device A would send BFD Unaffiliated
>Echo packets with IP destination address destined for itself, such as the
>IP address of interface 1 of device A". No any special considerations.
>
>
> One of the considerations may be whether a IPv6 link local address is
> preferable to a global address.
>
> The only consideration for the draft as it is written is that the address
> used as the destination may be looped back by the unaffiliated device.
> Link local helps address the security considerations that impact this
> feature, and it might be worth noting that when link local can be used for
> the use case that it assists in this point.
>

>
>-
>
>Also, are there any special considerations for selecting the source IP
>address for IPv4 and/or IPv6 network?
>
>[XM]>>> No. If you have any suggestions, please let me know. :)
>
>
> Since the feature is intended to be used for single-hop, the source
> address SHOULD be an address on the shared subnet with the interface of the
> device that is looping the packets back.  Perhaps it might even be
> reasonable to require that the source and destination addresses are
> identical when possible?
>
GIM2>> As I understand RFC 5881 ,
Section 4 recommends not to use an address on the same network as the
destination IP address, nor use a link-local IPv6 address as the source IP
address for an Echo message:
   In particular, the source address SHOULD NOT be part of the subnet
   bound to the interface over which the BFD Echo packet is being
   transmitted, and it SHOULD NOT be an IPv6 link-local address, unless
   it is known by other means that the remote system will not send
   Redirects.
Do you think that the normative part of Section 4 is applicable to
draft-ietf-bfd-unaffiliated-echo?

>
> Where this may complicate procedure is the initial demultiplexing step
> when the session is Down.  Once the session is Up, the Discriminators can
> be used for this purpose.
>
> -- Jeff
>
>

Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

[Greg Mirsky]

Thank you, Jeff, for pointing me in the right direction.

Regards,
Greg

On Thu, Apr 6, 2023 at 7:03 AM Jeffrey Haas  wrote:

> Greg,
>
> You may find the official liaison response here in the archives:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/
>
> The contents of that response are:
>
> From: Dave Sinicrope  
> <david.sinicr...@gmail.com>
> To: Jeffrey Haas ,Reshad <jh...@pfrc.org,Reshad> 
> Rahman  <res...@yahoo.com>
> Cc: Alvaro Retana ,John 
> <aretana.i...@gmail.com,John> Scudder ,Martin 
> <j...@juniper.net,Martin> Vigoureux ,Dave 
> <martin.vigour...@nokia.com,Dave> Sinicrope 
> ,Jeffrey 
> <david.sinicr...@gmail.com,Jeffrey> Haas ,Reshad 
> <jh...@pfrc.org,Reshad> Rahman ,Bidirectional 
> <res...@yahoo.com,Bidirectional> Forwarding Detection Discussion List 
>  <rtg-bfd@ietf.org>
> Response Contacts:
> Technical Contacts:
> Purpose: For information
>
> Body: The BBF thanks the IETF BFD WG for informing us of important work on 
> the BFD Echo.
>
> We wanted to clarify the "overlapping use case with TR-146". TR-146 leverages 
> BFD Echo as a connectivity check mechanism. It does so in a manner where the 
> peer does not need a full BFD implementation to echo the packet received. In 
> our opinion, no future standardization is required to support TR-146. There 
> is no current interest in revising TR-146 to leverage the enhancement of the 
> BFD protocol.
> We noted in the BBF community that those interested in participating should 
> do so in the IETF BFD WG.
>
> Sincerely,
>
> Lincoln Lavoie,
> Broadband Forum Technical Committee Chair
>
>
>
> On Apr 5, 2023, at 7:36 PM, Greg Mirsky  wrote:
>
> Hi, Dave, Jeff, et al.,
> I was looking for the BFD WG liaison to BBF and its response. I appreciate
> it if you help me to find out what was the BBF response, as the
> draft-ietf-bfd-unaffiliated-echo is in the WG LC.
>
> Thank you in advance.
>
> Regards,
> Greg
>
> On Thu, Nov 18, 2021 at 10:05 AM David Sinicrope <
> david.sinicr...@gmail.com> wrote:
>
>> Hi Jeff, (Sorry for bouncing around email addresses on you… IT challenges
>> this week)
>>
>> Thanks for clarifying the assertion concerning BBF interest.  Still,
>> given the statement in the adoption call and the clear references to TR-146
>> in the draft, it would be a good idea to liaise to BBF, even if brief, and
>> let them know of the draft and its relation to TR-146.  It certainly
>> couldn’t hurt to have open communication with them on the subject.
>>
>> Regarding your check with the IESG on the liaison - please proceed as you
>> deem appropriate.  I will say, (and apologies if I’m stating well known
>> details) that typically liaisons don’t need IESG approval.  They are
>> normally crafted/drafted by the WG Chairs, and have some level of review
>> and approval by the WG(s) in question or impacted.
>>
>> I hope this helps find the most expeditious and effective way to proceed.
>> Thanks,
>> Dave
>>
>> On Thu, Nov 18, 2021 at 12:38 Jeffrey Haas  wrote:
>>
>>> David,
>>>
>>> On Thu, Nov 18, 2021 at 05:18:38PM +, David Sinicrope wrote:
>>> > Sorry, I don't recall our discussion, but then it would have been as
>>> long ago as Singapore in Nov 2019 or before.
>>> > (Is it possible you spoke with Dave Allan?)
>>>
>>> That's possible!  As I noted in the thread, my notes from that lunch are
>>> missing.  (I have strong words for Microsoft about their support for Mac
>>> mail, but that's a different story.)  Whomever I had a conversation with
>>> it
>>> was in a subterranean warren of lunch venues.  Perhaps that will jar
>>> someone's memory of the venue.
>>>
>>> If you have contact info for Dave Allen I can certainly followup with
>>> him.
>>>
>>> > I can say as the BBF Liaison Manager there have been many past claims
>>> of
>>> > BBF interest in IETF work without substantiation.  As a result, it has
>>> > been key to ensure that any statement of BBF interest in IETF work,
>>> > especially if made to encourage action in the IETF, be formally
>>> supported
>>> > via a liaison.Searching the Liaison Statements in
>>> > Datatracker<https://datatracker.ietf.org/liaison/>, I don't see a
>>> liaison
>>> > from either the BBF or IETF related to this work.
>>>
>>> Please note that I don't believe we're asserting that BBF is interested
>>> in
&

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Greg Mirsky]

Hi Xiao Min,
thank you for sharing your views. I have several technical questions:

   - As this specification replaces the Echo function defined in RFC 5880,
   I expect it will describe the applicability of the new Echo functionality
   when the link in Figure 1 is a tunnel or a member link of a LAG.
   - The draft describes how the destination IP address of the Echo packet
   is set. Are there any special considerations for selecting IPv6 destination
   address?
   - Also, are there any special considerations for selecting the source IP
   address for IPv4 and/or IPv6 network?

Furthermore, please find my notes below under the GIM>> tag.

Regards,
Greg

On Sun, Apr 2, 2023 at 6:51 PM  wrote:

> Dear Greg,
>
>
> Thanks for sharing your thoughts, even if they're concerns.
>
> Please see inline...
> Original
> *From: *GregMirsky 
> *To: *Jeffrey Haas ;
> *Cc: *rtg-bfd@ietf.org ;
> *Date: *2023年03月27日 13:40
> *Subject: **Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7
> April, 2023)*
> Dear Authors,
> I read the latest version of the draft. I appreciate your work on
> improving its readability. I have several concerns and appreciate your
> consideration:
>
>-
>
>It appears like the document defines the format of the Echo message.
>As I understand the RFC 5880, the format of the Echo message is not
>specified in the RFC 5880. It seems like by defining the format in this
>document, you affect RFC 5880 compliance of implementations that do support
>RFC 5880 as it exists today.
>
>[XM]>>> As far as I can tell, several vendors have implemented this
>feature and nobody reports the problem.
>
> GIM>>I think that it would be beneficial to reflect information about
existing implementation in the Implementation State section as described in RFC
7942 . At the same time, your
update about deployed implementations doesn't resolve my concern about the
impact of the proposal on earlier implementations of the Echo function as
it is defined in RFC 5880.

>
>-
>
>
>-
>
>The draft, in my opinion, significantly changes the architecture of
>the BFD, as it is defined in RFC 5880. I believe that characterizing Echo
>as a function stresses its dependency from a BFD mode, Asynchronous and
>Demand. The changes proposed in this draft are very extensive and severely
>affect the existing architecture of BFD by setting the Echo function on
>par, unrelated with the BFD modes.
>
>[XM]>>> Please see above.
>
> GIM>> My question is about the impact on implementations that support the
Echo function as currently defined in RFC 5880. Perhaps you have verified
that there's no adverse impact? Please, if you have it, share information
about any interoperability between a system using the RFC5880-style Echo
function and a system with the unaffiliated Echo.

>
>-
>
>
>-
>
>Also, I think that the normative language in the last paragraph of the
>Secrity Considerations sections are too soft. Currently used recommendation
>level, in my opinion, is insufficient and should be brought to the
>requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD
>NOT/SHALL NOT/
>
>[XM]>>> I agree we can strengthen the requirements for security. I'll
>incorporate the changes you proposed if no objection from others.
>
>
>
> In conclusion, I am very much concerned with the amount of changes to the
> BFD architecture proposed in the document. I am also concerned with the
> affect on the protocol conformance standing of the established BFD
> implementations, SH BFD in particular. Hence, I propose changing this draft
> to the Experimental track.
>
> [XM]>>> As said, I have different opinion on the implication of this
> feature. As to the Standards Track vs Experimental Track, I'm open to it, I
> personally prefer the former.
>
>
> Cheers,
>
> Xiao Min
>
>
> Regards,
> Greg
>
> On Tue, Mar 21, 2023 at 11:02 AM Jeffrey Haas  wrote:
>
>> Working Group,
>>
>> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
>>
>> The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
>>
>> The draft, in my opinion, is in fairly good shape.  However, since it
>> functions via looping packets back to itself and trying to exercise the
>> normal RFC 5880 state machine behaviors to a large extent, the draft could
>> use very high scrutiny for several matters:
>>
>> - Does the state machine behave appropriately at all stages?
>> - Are the descriptions of the values of the BFD fields clear in all cases?
>>
>> Please supply the authors and the Working Group with your feedback.
>>
>> The intended finish date for this WGLC is 7 April, 2023.  This is one week
>> after the end of IETF 116.
>>
>> Note that Reshad is an author on the draft, so I'll be handling the full
>> set
>> of review and shepherding work.
>>
>> -- Jeff
>>
>>
>>
>

Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

[Greg Mirsky]

Hi, Dave, Jeff, et al.,
I was looking for the BFD WG liaison to BBF and its response. I appreciate
it if you help me to find out what was the BBF response, as the
draft-ietf-bfd-unaffiliated-echo is in the WG LC.

Thank you in advance.

Regards,
Greg

On Thu, Nov 18, 2021 at 10:05 AM David Sinicrope 
wrote:

> Hi Jeff, (Sorry for bouncing around email addresses on you… IT challenges
> this week)
>
> Thanks for clarifying the assertion concerning BBF interest.  Still, given
> the statement in the adoption call and the clear references to TR-146 in
> the draft, it would be a good idea to liaise to BBF, even if brief, and let
> them know of the draft and its relation to TR-146.  It certainly couldn’t
> hurt to have open communication with them on the subject.
>
> Regarding your check with the IESG on the liaison - please proceed as you
> deem appropriate.  I will say, (and apologies if I’m stating well known
> details) that typically liaisons don’t need IESG approval.  They are
> normally crafted/drafted by the WG Chairs, and have some level of review
> and approval by the WG(s) in question or impacted.
>
> I hope this helps find the most expeditious and effective way to proceed.
> Thanks,
> Dave
>
> On Thu, Nov 18, 2021 at 12:38 Jeffrey Haas  wrote:
>
>> David,
>>
>> On Thu, Nov 18, 2021 at 05:18:38PM +, David Sinicrope wrote:
>> > Sorry, I don't recall our discussion, but then it would have been as
>> long ago as Singapore in Nov 2019 or before.
>> > (Is it possible you spoke with Dave Allan?)
>>
>> That's possible!  As I noted in the thread, my notes from that lunch are
>> missing.  (I have strong words for Microsoft about their support for Mac
>> mail, but that's a different story.)  Whomever I had a conversation with
>> it
>> was in a subterranean warren of lunch venues.  Perhaps that will jar
>> someone's memory of the venue.
>>
>> If you have contact info for Dave Allen I can certainly followup with him.
>>
>> > I can say as the BBF Liaison Manager there have been many past claims of
>> > BBF interest in IETF work without substantiation.  As a result, it has
>> > been key to ensure that any statement of BBF interest in IETF work,
>> > especially if made to encourage action in the IETF, be formally
>> supported
>> > via a liaison.Searching the Liaison Statements in
>> > Datatracker, I don't see a
>> liaison
>> > from either the BBF or IETF related to this work.
>>
>> Please note that I don't believe we're asserting that BBF is interested in
>> IETF in doing this work for BBF.  And perhaps the easiest answer we'll
>> converge to is "remove all mention of BBF".
>>
>> That said, throughout the discussion that lead to this draft, it was
>> pointed
>> out to the original authors that they were largely covering the TR-146 use
>> case.  Minimally, making sure we have a BBF statement regarding the IETF
>> work may make sense.
>>
>> > Also, to the best of my knowledge, the issues that this draft addresses
>> > have not been raised in BBF. E.g., a proposal for revision to TR-146 or
>> > related documents.
>>
>> I am not a participant in BBF and have no knowledge of any such
>> communications one way or the other.  Informally, the discussions I have
>> been involved in both with the BFD draft in question and in prior contexts
>> at my employer have mostly been that the BBF procedures are somewhat
>> inspecific and cleaner documented procedures for the use case are desired.
>>
>> > Given the stated overlap and application of the draft to TR-146 (in the
>> adoption call),
>> [...]
>> > I would suggest that a liaison be crafted and sent to the BBF formally
>> > notifying them of this work and inquiring as to the interest in the
>> > content of the draft.  Fortunately, the next BBF meeting where such a
>> > liaison would be addressed and responded to is 29 Nov - 3 Dec 2021.  The
>> > sooner the liaison is sent, the more likely a timely response coming out
>> > of this upcoming meeting.
>>
>> I think we could make such a deadline.  I'll start discussion with our AD
>> to
>> see what the IESG will want for the liaison statement.
>>
>> Meanwhile, I'll see if I can contact Dave Allen to try to get
>> clarification
>> of what we discussed over lunch - if it was him.
>>
>> -- Jeff
>>
> --
> David Sinicrope
> david.sinicr...@gmail.com
>

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Greg Mirsky]

Dear Authors,
I read the latest version of the draft. I appreciate your work on improving
its readability. I have several concerns and appreciate your consideration:

   - It appears like the document defines the format of the Echo message.
   As I understand the RFC 5880, the format of the Echo message is not
   specified in the RFC 5880. It seems like by defining the format in this
   document, you affect RFC 5880 compliance of implementations that do support
   RFC 5880 as it exists today.
   - The draft, in my opinion, significantly changes the architecture of
   the BFD, as it is defined in RFC 5880. I believe that characterizing Echo
   as a function stresses its dependency from a BFD mode, Asynchronous and
   Demand. The changes proposed in this draft are very extensive and severely
   affect the existing architecture of BFD by setting the Echo function on
   par, unrelated with the BFD modes.
   - Also, I think that the normative language in the last paragraph of the
   Secrity Considerations sections are too soft. Currently used recommendation
   level, in my opinion, is insufficient and should be brought to the
   requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD
   NOT/SHALL NOT/

In conclusion, I am very much concerned with the amount of changes to the
BFD architecture proposed in the document. I am also concerned with the
affect on the protocol conformance standing of the established BFD
implementations, SH BFD in particular. Hence, I propose changing this draft
to the Experimental track.

Regards,
Greg

On Tue, Mar 21, 2023 at 11:02 AM Jeffrey Haas  wrote:

> Working Group,
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
>
> The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
>
> The draft, in my opinion, is in fairly good shape.  However, since it
> functions via looping packets back to itself and trying to exercise the
> normal RFC 5880 state machine behaviors to a large extent, the draft could
> use very high scrutiny for several matters:
>
> - Does the state machine behave appropriately at all stages?
> - Are the descriptions of the values of the BFD fields clear in all cases?
>
> Please supply the authors and the Working Group with your feedback.
>
> The intended finish date for this WGLC is 7 April, 2023.  This is one week
> after the end of IETF 116.
>
> Note that Reshad is an author on the draft, so I'll be handling the full
> set
> of review and shepherding work.
>
> -- Jeff
>
>

Re: Can a BFD session change its source port to facilitate auto recovery

[Greg Mirsky]

Hi Abhinav,
although BFD is not expected to detect network performance issues like
congestion, some might be reflected as a network failure if an aggressive
Detection Time is used on the particular BFD session. On the other hand,
using aggressive detection intervals on an MH BFD session may not be the
best operational practice. Instead, as was suggested, SH and LAG BFD
sessions can be run with more aggressive detection intervals, while the MH
BFD session is set with intervals that meet the operator's expectations and
are more relaxed. In fact, such an arrangement can be viewed as a case of a
multi-layer OAM in a domain. And yes, selecting interval values for that
case is, in part, "black magic".

Regards,
Greg

On Thu, Mar 23, 2023 at 7:18 AM Abhinav Srivastava 
wrote:

> The case I had in mind is where multi hop BFD is being used to monitor
> availability of remote servers.  there are many equal cost paths to reach
> them especially in a DC.  BFD detecting network issues is only incidental
> there. And even if it recovers it can leave monitoring/alerting trail . If
> it's happening often would/should not be ignored.
>
> I take your point about most applications only experiencing latency
> without dropping tcp connection. I guess BFD in that case is helping them
> get disconnected (eg directly associated protocols like BGP or causing a
> load balancer in path to direct packet to wrong server). Though continuous
> flapping is the flip side.
>
> Thanks
> Abhinav
>
>
> On Wed, 22 Mar, 2023, 11:27 pm Jeff Tantsura, 
> wrote:
>
>> Abhinav,
>>
>> Let’s clarify a couple of points.
>> What you are trying to do is to change entropy to change local hashing
>> outcome, however for hashing to even be relevant there has to he either
>> ECMP or LAG in the path to the destination otherwise shortest path will be
>> he used regardless, so statistically, some of the flows between a given
>> pair of end points (5 tuple) will be traversing the (partially)broken link,
>> would you really like BFD to “pretend“ that everything is just fine?
>> Moreover, by far, in case of congestion  - most applications won’t change
>> their ports but have their TX rate reduced.
>> There’s work done by Tom Herbert for IPv6/TCP (kernel patch upstreamed a
>> few years ago)  - had beeb presented in RTGWG pre-Covid, that on RTO
>> changes flow label value (that some might or might not include in hashing),
>> which is strongly not recommended to be used outside of a tightly
>> controlled homogenous  environment (think within DC).
>> Outside of what BFD spec tells us (don’t), the above should provide
>> enough motivation not to do this.
>>
>> Cheers,
>> Jeff
>>
>> On Mar 23, 2023, at 05:44, Abhinav Srivastava  wrote:
>>
>> 
>> Multi-hop BFD would be the mechanism that detects the failure on the path
>> it happens to be using for the session. I wasn't thinking of another
>> mechanism.  Detection timer expiry would be the trigger for recovery which
>> could be augmented with few other possible criteria like how long session
>> hasn't been able to come back up or prolonged flapping.
>>
>> Thanks
>> Abhinav
>>
>> On Wed, 22 Mar, 2023, 3:05 pm Greg Mirsky,  wrote:
>>
>>> Hi Abhinav,
>>> thank you for presenting an interesting scenario for a discussion. I
>>> have several questions to better understand it:
>>>
>>>- How the network failure that triggers the recovery process is
>>>detected?
>>>- If the failure detection mechanism is not multi-hop BFD, what is
>>>the relationship between the detection intervals of heat mechanism and 
>>> the
>>>multi-hop BFD session?
>>>
>>> Regards,
>>> Greg
>>>
>>> On Wed, Mar 22, 2023 at 4:36 PM Abhinav Srivastava 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I needed clarification around whether source port can be changed for a
>>>> BFD session in case of multi hop BFD.   The ability to change BFD source
>>>> port when BFD session goes down helps BFD session to recover if its stuck
>>>> on a network path where there is some intermittent but significant packet
>>>> loss.
>>>>
>>>>
>>>>
>>>> In such cases, normally without BFD, end to end application traffic
>>>> would eventually settle down on a good path as applications typically
>>>> change source port after experiencing disconnection or failures.  But if
>>>> BFD is being used to monitor some part of a path which is experiencing

Re: Can a BFD session change its source port to facilitate auto recovery

[Greg Mirsky]

Hi Abhinav,
thank you for presenting an interesting scenario for a discussion. I have
several questions to better understand it:

   - How the network failure that triggers the recovery process is detected?
   - If the failure detection mechanism is not multi-hop BFD, what is the
   relationship between the detection intervals of heat mechanism and the
   multi-hop BFD session?

Regards,
Greg

On Wed, Mar 22, 2023 at 4:36 PM Abhinav Srivastava 
wrote:

> Hi all,
>
>
>
> I needed clarification around whether source port can be changed for a BFD
> session in case of multi hop BFD.   The ability to change BFD source port
> when BFD session goes down helps BFD session to recover if its stuck on a
> network path where there is some intermittent but significant packet loss.
>
>
>
> In such cases, normally without BFD, end to end application traffic would
> eventually settle down on a good path as applications typically change
> source port after experiencing disconnection or failures.  But if BFD is
> being used to monitor some part of a path which is experiencing significant
> but not 100% packet loss, it will start causing next hop list of associated
> static route or the associated BGP sessions to start flapping forever, as
> BFD packets would be stuck to that partial lossy path forever (until BFD
> session is deleted and recreated by admin action).  This may also hinder
> the typical application recovery strategy of changing source port on
> failure.
>
>
>
> Ability to dynamically change BFD source port can help BFD recover in such
> cases.  Is this something that is allowed as per RFC?  The RFC5881, section
> 4 (for single hop) case states that –
>
> *“The source port MUST be in the range 49152 through 65535. The same UDP
> source port number MUST be used for all BFD Control packets associated with
> a particular session”*
>
>
>
> Thanks
>
> Abhinav
>

Re: [Technical Errata Reported] RFC5880 (7240)

[Greg Mirsky]

Hi, Reshad et al.,
I've reached out to my colleagues. I was informed that one of the deployed
implementations of BFD upon the state transition from Down to Up,
bfd.DiagLocal is set to 0. I expect the report on the behavior of the other
implementation shortly.

Regards,
Greg

On Fri, Feb 24, 2023 at 12:02 AM  wrote:

> Reshad,
>
>
> I consulted my colleague implementing BFD in ZTE, and I confirm the LocalDiag
> would be reset once the session returns to Up.
>
> Besides, at least two proprietary usages of Diag have ever been
> implemented, one for bidirectional path consistency, another for OAM
> mapping.
>
> Hope that helps.
>
>
> Best Regards,
>
> Xiao Min
> Original
> *From: *ReshadRahman 
> *To: *Dave Katz ;John Scudder ;
> *Cc: *Jeff Haas ;James Guichard <
> james.n.guich...@futurewei.com>;Dave Ward ;Andrew
> Alston ;BFD WG ;
> *Date: *2023年02月23日 22:15
> *Subject: **Re: [Technical Errata Reported] RFC5880 (7240)*
> Great. I was worried the next step was a document update for this.
>
> I wish we'd hear from more implementations how they ended up doing this.
>
> Regards,
> Reshad.
>
> On Wednesday, February 22, 2023, 02:30:31 PM EST, John Scudder <
> j...@juniper.net> wrote:
>
>
> Further to what I just sent,
>
> "is it possible to simply log a permanent erratum that explains the
> ambiguity and encourages people not to worry about it?”
>
> Yep. That's basically what I had in mind with "note it in a ‘hold for
> document update’ erratum”. I don’t really expect anyone to write an
> Internet Draft to formally update RFC 5880, although I wouldn’t object to
> someone doing so if they wanted to do the work, the doc itself would
> probably just be a few pages (the email thread discussing it would
> inevitably be longer). But an erratum to at least say “some people do it
> one way, some do it another, that’s life” is worth having and I will gladly
> verify one.
>
> —John
>
> > On Feb 22, 2023, at 2:12 PM, Dave Katz  wrote:
> >
> > I guess the reality is that the diag field is a weak and ambiguous
> feature that I spent five minutes thinking about, and is ultimately (and
> happily) not subject to normative verification because it is write-only.
> >
> > The received value is edge-triggerable if you grab the value during the
> next session establishment phase (you get at least one packet from the
> other guy prior to the session coming Up), so I suppose one could change
> the language to zero the local value on the Up transition as suggested
> without losing the (mis)feature altogether.  If that’s the case, I would
> add a sentence in the field description saying that the received diag value
> refers to the previous session when received in a packet bearing a state
> other than Up.  Of course this means that the value received with Up is
> ambiguous, because it could be referring to the previous session or the
> current one, depending on how it was implemented, but that’s already the
> case.
> >
> > Or is it possible to simply log a permanent erratum that explains the
> ambiguity and encourages people not to worry about it?  It’s already taken
> up more time than it is worth, considering that it cannot affect
> interoperability (and so I suppose never should have been normative, but
> we’d probably still be discussing it anyhow).
> >
> > Thanks,
> >
> > —Dave
> >
> >
> >> On Feb 22, 2023, at 8:14 AM, Jeffrey Haas  wrote:
> >>
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> Dave,
> >>
> >> Just as a reminder, the context for why this errata is being discussed
> is this inquiry:
> >>
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/YIeCo-nQicI_OIcVncYaJM5Zz6c/
> >>
> >> More below:
> >>
> >>
> >>> On Feb 17, 2023, at 12:04 PM, Dave Katz  40juniper@dmarc.ietf.org> wrote:
>  On Feb 17, 2023, at 8:47 AM, Reshad Rahman  wrote:
>  Having the diag field as breadcrumb has been extremely useful indeed.
> But both ends can store last diag field sent/received, we don't have to
> keep sending the diag field after the failure has cleared. It seems odd to
> be sending a diag field which happened e.g. a year ago.
> >>>
> >>> That property helped me when debugging my implementation, as it
> survives the restart/reboot of the far end.
> >>>
> >>> There is also no timeout that would make sense;  “forever, for small
> values of ‘forever'” is semantically consistent and the only thing that
> makes sense (to me, at least).
> >>>
> >>> Resetting it to zero only deletes information (albeit a tiny amount of
> it) and doesn’t help anything;  you know that the session is up, so the
> diagnostic for its most recent transition to non-upness is disambiguated.
> >>>
> >>> Debugging broken things is a scramble for bits of data;  leaving a
> breadcrumb is a polite gift.
> >>
> >> From my perspective, the breadcrumb is useful to note during the
> transitions, and not simply the transitions for the state.  Examples have
> been given where the diag is updated as part of a state transition
> (governed by normative text in 

Re: [Technical Errata Reported] RFC5880 (7240)

[Greg Mirsky]

Hi Jeff,
I've looked through several active BFD-related drafts and the only one that
might be relevant to the discussion is draft-mirsky-bfd-mpls-demand
. Although,
updating bfd.LocalDiag is not explicitly discussed there.

Regards,
Greg

On Wed, Feb 22, 2023 at 2:30 PM Jeffrey Haas  wrote:

> "Hold for update" was the expected outcome for my filing of the errata.
>
> At best, we're telling new implementors that there's an issue here of note
> in the protocol.  The mail discussion will note that there are multiple
> existing implementations that have historically set the value to 0 when
> transitioning to Up.
>
> It'll also log some of what your thinking was at the time.  Since RFC 5880
> already talks about cases where the value is of interest (concatenated
> path, etc.) implementors already know to pay attention to the value even
> when state transitions aren't happening.
>
> Part of my own motivation to have the behavior clear has been other
> proposals we've seen come and go trying to use Diag as a much more rigorous
> mechanism to trigger behaviors.  I had thought I could find a draft I saw
> during the mpls session at IETF 115 along these lines, but I appear to be
> mistaken.  In any case, people keep wanting to use Diag for Clever Things
> and it'll bite them in unpleasant places if they do so.
>
> Greg may have recollection of the proposal I'm thinking about.
>
> -- Jeff
>
>
>
>
> > On Feb 22, 2023, at 2:34 PM, Dave Katz  wrote:
> >
> > Thanks for the background.
> >
> > I guess the fact of the matter is that, since the issue cannot affect
> interoperability, it’s hard to imagine getting the WG to go through a bunch
> of machinations to go out of its way to fix something that is entirely
> pedantic.  In that case I think holding the erratum for update is the right
> choice.  The erratum can describe the ambiguity and the WG can decide what
> to do about it if they find another reason to update the spec...
> >
> > —Dave
> >
> >
> >> On Feb 22, 2023, at 11:29 AM, John Scudder  wrote:
> >>
> >> Hi All,
> >>
> >> Regarding Jeff’s "Given the maturity of the feature, I'd suggest
> sticking to the reality on the ground”, I want to step in and remind folks
> about what our guidelines are for processing errata [1]. They are fairly
> narrow, by design. One of the high-order bits of the guidelines is, "Errata
> are meant to fix "bugs" in the specification and should not be used to
> change what the community meant when it approved the RFC.”  What I take
> this to mean in the current context is, if the behavior specified in the
> RFC has been found to be ‘wrong’ (for whatever definition of ‘wrong’ you
> choose to apply), an erratum is definitively not the way to correct that.
> An erratum is to clarify or correct whatever the intent of the RFC was at
> time of publication. Of course, many RFCs (this one included, it seems)
> didn’t receive detailed scrutiny of every crevice of the spec before being
> declared ready for publication, and so it’s not always possible to really
> say that the consensus was firmly one way or the other. In such cases, I
> think we have to err on the side of what the words in the spec say.
> >>
> >> About the furthest I’d go in documenting that (part of) the WG now
> thinks the specified behavior is undesirable, is to note it in a ‘hold for
> document update’ erratum. That seems reasonable in this case — it can lay
> out the pros and cons and at least creates an artifact for future
> implementors to notice.
> >>
> >> The bottom line is that changes to specified behavior require WG and
> IETF consensus, and that means they require an RFC to update or obsolete
> the old behavior. This is one of the pointy bits of our process, that RFCs
> document the consensus at a moment in time, not the evolving consensus.
> >>
> >> Thanks,
> >>
> >> —John
> >>
> >> [1]
> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/
> >>
> >>> On Feb 22, 2023, at 11:14 AM, Jeffrey Haas  wrote:
> >>>
> >>>
> >>> Dave,
> >>>
> >>> Just as a reminder, the context for why this errata is being discussed
> is this inquiry:
> >>>
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/YIeCo-nQicI_OIcVncYaJM5Zz6c/
> >>>
> >>> More below:
> >>>
> >>>
>  On Feb 17, 2023, at 12:04 PM, Dave Katz  40juniper@dmarc.ietf.org> wrote:
> > On Feb 17, 2023, at 8:47 AM, Reshad Rahman  wrote:
> > Having the diag field as breadcrumb has been extremely useful
> indeed. But both ends can store last diag field sent/received, we don't
> have to keep sending the diag field after the failure has cleared. It seems
> odd to be sending a diag field which happened e.g. a year ago.
> 
>  That property helped me when debugging my implementation, as it
> survives the restart/reboot of the far end.
> 
>  There is also no timeout that would make sense;  “forever, for small
> values of ‘forever'” is semantically consistent and the 

Discussion of issues related to RFC 5884

[Greg Mirsky]

Dear All,
I've started a list of issues
 for the
discussion of issues related to bootstrapping a BFD session over an MPLS
LSP and IP/UDP encapsulation of a BFD control message. Welcome your
thoughts, comments, and questions.

Happy Holidays to All!

Regards,
Greg

Re: [Detnet] Fwd: New Version Notification for draft-mmm-rtgwg-integrated-oam-02.txt

[Greg Mirsky]

Hi Tianran,
I think that we can discuss and find out how the Integrated OAM can support
the use cases considered in the RDI draft.
WDYT?

Regards,
Greg

On Fri, Nov 11, 2022 at 10:23 AM Tianran Zhou 
wrote:

> Hi Greg,
>
>
>
> I am sorry I am lazy.
>
> What’s the update wrt to draft-huang-detnet-rdi
> <https://datatracker.ietf.org/doc/draft-huang-detnet-rdi/>?
>
>
>
> Best,
>
> Tianran
>
>
>
> *发件人:* detnet [mailto:detnet-boun...@ietf.org] *代表 *Greg Mirsky
> *发送时间:* 2022年11月11日 1:58
> *收件人:* RTGWG ; DetNet WG ; p...@ietf.org;
> MPLS Working Group 
> *抄送:* rtg-bfd WG 
> *主题:* [Detnet] Fwd: New Version Notification for
> draft-mmm-rtgwg-integrated-oam-02.txt
>
>
>
>
> Dear All,
>
> we've updated the Integrated OAM draft that Jeff Haas referred to (thank
> you, Jeff) at the PALS+DetNet+MPLS session on Wednesday in the discussion
> of draft-huang-detnet-rdi
> <https://datatracker.ietf.org/doc/draft-huang-detnet-rdi/>. The authors
> welcome your comments, questions, and suggestions. We are always open to
> cooperation.
>
>
>
> Kind regards,
>
> Greg (on behalf of the authors)
>
>
>
> -- Forwarded message -
> From: 
> Date: Thu, Nov 10, 2022 at 5:50 PM
> Subject: New Version Notification for draft-mmm-rtgwg-integrated-oam-02.txt
> To: Greg Mirsky , Gyan Mishra <
> gyan.s.mis...@verizon.com>, Xiao Min 
>
>
>
>
> A new version of I-D, draft-mmm-rtgwg-integrated-oam-02.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:   draft-mmm-rtgwg-integrated-oam
> Revision:   02
> Title:  Integrated Operation, Administration, and Maintenance
> Document date:  2022-11-10
> Group:  Individual Submission
> Pages:  20
> URL:
> https://www.ietf.org/archive/id/draft-mmm-rtgwg-integrated-oam-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mmm-rtgwg-integrated-oam/
> Html:
> https://www.ietf.org/archive/id/draft-mmm-rtgwg-integrated-oam-02.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mmm-rtgwg-integrated-oam
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-mmm-rtgwg-integrated-oam-02
>
> Abstract:
>This document describes the Integrated Operation, Administration, and
>Maintenance (IntOAM) protocol.  IntOAM is based on the lightweight
>capabilities of Bidirectional Forwarding Detection defined in RFC
>5880 Bidirectional Forwarding Detection, and the RFC 6374 Packet Loss
>and Delay Measurement for MPLS Networks to measure performance
>metrics like packet loss and packet delay.  Also, a method to perform
>lightweight on-demand authentication is defined in this
>specification.
>
>
>
>
> The IETF Secretariat
>
>

Fwd: New Version Notification for draft-mmm-rtgwg-integrated-oam-02.txt

[Greg Mirsky]

Dear All,
we've updated the Integrated OAM draft that Jeff Haas referred to (thank
you, Jeff) at the PALS+DetNet+MPLS session on Wednesday in the discussion
of draft-huang-detnet-rdi
<https://datatracker.ietf.org/doc/draft-huang-detnet-rdi/>. The authors
welcome your comments, questions, and suggestions. We are always open to
cooperation.

Kind regards,
Greg (on behalf of the authors)

-- Forwarded message -
From: 
Date: Thu, Nov 10, 2022 at 5:50 PM
Subject: New Version Notification for draft-mmm-rtgwg-integrated-oam-02.txt
To: Greg Mirsky , Gyan Mishra <
gyan.s.mis...@verizon.com>, Xiao Min 



A new version of I-D, draft-mmm-rtgwg-integrated-oam-02.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-mmm-rtgwg-integrated-oam
Revision:   02
Title:  Integrated Operation, Administration, and Maintenance
Document date:  2022-11-10
Group:  Individual Submission
Pages:  20
URL:
https://www.ietf.org/archive/id/draft-mmm-rtgwg-integrated-oam-02.txt
Status:
https://datatracker.ietf.org/doc/draft-mmm-rtgwg-integrated-oam/
Html:
https://www.ietf.org/archive/id/draft-mmm-rtgwg-integrated-oam-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-mmm-rtgwg-integrated-oam
Diff:
https://www.ietf.org/rfcdiff?url2=draft-mmm-rtgwg-integrated-oam-02

Abstract:
   This document describes the Integrated Operation, Administration, and
   Maintenance (IntOAM) protocol.  IntOAM is based on the lightweight
   capabilities of Bidirectional Forwarding Detection defined in RFC
   5880 Bidirectional Forwarding Detection, and the RFC 6374 Packet Loss
   and Delay Measurement for MPLS Networks to measure performance
   metrics like packet loss and packet delay.  Also, a method to perform
   lightweight on-demand authentication is defined in this
   specification.




The IETF Secretariat

A question about Encapsulation of BFD for SRv6 Policy

[Greg Mirsky]

Dear All,
as suggested by the SPRING WG Chairs, I'm bringing the discussion to the
mailing list. I think that it is also relevant and might be of interest to
the BFD WG community. My questions at the mic were:

   - What is unique in the encapsulations of a BFD Control message
   described in the draft from encapsulations of user data in the respective
   scenarios?
   - And if encapsulation of a BFD Control message is different from the
   encapsulation of a data flow (SRv6 Policy) that is monitored by the BFD
   session, what mechanism ensures that BFD and data packets traverse the same
   set of nodes and links?

Regards,
Greg

Re: Regarding resetting bfd.LocalDiag back to No Diagnostic (RFC 5880)

[Greg Mirsky]

Hi Glebs,
thank you for bringing this to the discussion. I think that the intended
behavior is clear, but the text can be further improved by appending it
with "every time when the session reaches the Up state", or something along
the line.

Regards,
Greg

On Fri, Sep 23, 2022, 15:07 Gļebs Ivanovskis  wrote:

> Hi,
>
> I have a question regarding bfd.LocalDiag State Variable. In section
> 6.8.1. State Variables
>  it says:
>
>bfd.LocalDiag
>
>   The diagnostic code specifying the reason for the most recent
>   change in the local session state.  This MUST be initialized to
>   zero (No Diagnostic).
>
> Then in many places throughout the text it is said that bfd.LocalDiag
> needs to be set to other values in response to different failures. But
> nowhere it is said that bfd.LocalDiag needs to be reset to "No Diagnostic".
> Only the text I quoted above mentions bfd.LocalDiag together with "No
> Diagnostic", but it talks only about BFD session initialization.
>
> So, if implementation rigorously follows the letter of RFC, then it leads
> to a peculiar situation when a session goes back Up after, say, "Control
> Detection Time Expired", but the Diag field of the packet keep holding the
> diagnostic from the time session was Down. Or am I missing something?
>
> Best regards,
> Glebs
>
>

Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-12.txt

[Greg Mirsky]

Dear All,
minor editorial updates to the draft that describes (yes, it is
Informational) the use of the BFD Demand mode over a p2p MPLS LSP. Two
scenarios are considered:

   - switching to the Demand mode after a BFD session established according
   to RFC 5884 procedures;
   - application of RFC 8563 with Unsolicited Notifications to p2p MPLS LSP.

Welcome your questions and comments.
Appreciate BFD WG consideration of adopting this draft as Informational
document.

Regards,
Greg

-- Forwarded message -
From: 
Date: Tue, Sep 6, 2022 at 3:37 PM
Subject: New Version Notification for draft-mirsky-bfd-mpls-demand-12.txt
To: Greg Mirsky 



A new version of I-D, draft-mirsky-bfd-mpls-demand-12.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-mirsky-bfd-mpls-demand
Revision:   12
Title:  BFD in Demand Mode over a Point-to-Point MPLS LSP
Document date:  2022-09-06
Group:  bfd
Pages:  5
URL:
https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-12.txt
Status:
https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/
Html:
https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-12.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-demand
Diff:
https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-mpls-demand-12

Abstract:
   This document describes procedures for using Bidirectional Forwarding
   Detection (BFD) in Demand mode to detect data plane failures in
   Multiprotocol Label Switching (MPLS) point-to-point Label Switched
   Paths.




The IETF Secretariat

Re: Regarding keyed MD5/SHA1 authentication for BFD (RFC 5880)

[Greg Mirsky]

Hi Alan,
you've suggested

It would be good to say that packets which fail authentication MUST NOT
affect the BFD state.

I think that a BFD Control message that failed validation, and I consider
authentication is a part of the validation process, MUST be discarded. If
the number of consecutively discarded packets causes the associated with
the BFD session Detection Timer expiration, then the state of this BFD
session MUST be changed to Down. Thus, I think that packets that failed
authentication affect the BFD state in the same manner as packets that
failed any other step of the validation process.

Regards,
Greg

On Wed, Apr 27, 2022 at 12:14 PM Alan DeKok 
wrote:

> On Apr 25, 2022, at 6:23 AM, Gļebs Ivanovskis  wrote:
> > I have a question regarding the order of operations during receipt of
> BFD control packet using keyed MD5/SHA1 authentication. Both Section 6.7.3.
> "Keyed MD5 and Meticulous Keyed MD5 Authentication" and Section 6.7.4.
> "Keyed SHA1 and Meticulous Keyed SHA1 Authentication" (in parts "Receipt
> Using Keyed MD5 and Meticulous Keyed MD5 Authentication" and "Receipt Using
> Keyed SHA1 and Meticulous Keyed SHA1 Authentication" respectively) suggest
> that Sequence Number field of incoming control packet is examined prior to
> calculating any digest/hash. I have discovered that the order was the other
> way round in early drafts, but then was changed between versions 8 and 9,
> presumably followed by this comment:
> >
> > If we check the sequence number after doing a MD5 digest verification,
> even if we get replayed packets, we will be doing the costly hash
> operations, thus wasting a lot of CPU and exposing ourselves to simple CPU
> exhaustion attacks.
>
>   From a security point of view, the usual process is to verify packets
> first, and then use the contents of the packets.  This can be expensive
> from a CPU point of view, but it's the cost of being secure.
>
> > Unfortunately, I couldn't find any discussion following this suggestion.
> I understand the motivation of making a "cheaper" Sequence Number check
> before doing more "expensive" digest/hash calculation, but the reordering
> of stages does not seem to be thought through very well. The text of RFC
> 5880 mandates implementations to act on received Sequence Number before
> validating digest/hash:
> >
> > Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1,
> and bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number
> field.
> >
> > and
> >
> > Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1,
> bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number
> field, and the received packet MUST be accepted.
> >
> > This leaves the opportunity for unauthorized control packet to mess up
> session state variables, potentially leading to subsequent valid packets
> being dropped due to Sequence Number outside of expected range and BFD
> session being erroneously diagnosed as Down. Note that "and the received
> packet MUST be accepted" clause has been removed from MD5 part, but not
> from SHA1 part, requesting implementations to skip hash verification
> altogether if bfd.AuthSeqKnown is 0.
>
>   It would be good to say that packets which fail authentication MUST NOT
> affect the BFD state.
>
> > Is the sequence of operations described in Sections 6.7.3. and 6.7.4.
> correct?
> >
> > In my opinion, as a minimum, the following changes need to be made:
> >
> >   • The "and the received packet MUST be accepted" clause needs to
> be removed from Section 6.7.4.
> >   • Sections 6.7.3. and 6.7.4. need to split examining incoming
> packet's Sequence Number (which can be done before digest/hash
> verification) and acting upon it (which has to happen after verification).
>
>   That seems reasonable.
>
> > Furthermore, I would like to suggest going back to original ordering
> with digest/hash verification being done before examining Sequence Number,
> because it simplifies the algorithm. I don't think that checking Sequence
> Number first provides much protection against CPU exhaustion attacks,
> because Sequence Numbers are transmitted in clear text and it wouldn't be
> that difficult for an attacker to come up with a valid Sequence Number to
> pass "cheap" check.
>
>   Yes.
>
>   The "secure sequence numbers" draft attempts to address these issues.
>
>   Alan DeKok.
>
>

Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-11.txt

[Greg Mirsky]

Dear All,
following the in-depth discussion, I've decided that the Informational
track seems more appropriate for this work. I believe that there's a
significant value in collecting and organizing the information about the
BFD Demand mode in a dedicated document. I greatly appreciate your
comments, questions, and suggestions.

Regards,
Greg
-- Forwarded message -
From: 
Date: Mon, Mar 7, 2022 at 6:29 AM
Subject: New Version Notification for draft-mirsky-bfd-mpls-demand-11.txt
To: Greg Mirsky 



A new version of I-D, draft-mirsky-bfd-mpls-demand-11.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-mirsky-bfd-mpls-demand
Revision:   11
Title:  BFD in Demand Mode over Point-to-Point MPLS LSP
Document date:  2022-03-07
Group:  bfd
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-11.txt
Status:
https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/
Html:
https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-11.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-demand
Diff:
https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-mpls-demand-11

Abstract:
   This document describes procedures for using Bidirectional Forwarding
   Detection (BFD) in Demand mode to detect data plane failures in
   Multiprotocol Label Switching (MPLS) point-to-point Label Switched
   Paths.




The IETF Secretariat

Re: A question about the draft-wang-bess-sbfd-discriminator

[Greg Mirsky]

Hi Haibo,
thank you for the clarification. I may suggest a text for Section 3:

In some EVPN deployments, for example, when it spans over multiple domains,
only one of a pair of interconnected PEs benefits from monitoring the
status of the connection. In such a case, using S-BFD [RFC7880] is
advantageous as it reduces the load on one of the PEs while providing the
benefit of faster convergence. The following sections provide examples of
EVPNs that would benefit from using S-BFD.

What are your thoughts?

Regards,
Greg

On Tue, Mar 15, 2022 at 7:18 PM Wanghaibo (Rainsword) <
rainsword.w...@huawei.com> wrote:

> Hi Greg,
>
>Thanks for you comments.
>
> Yes, the resources will save at PE1 and PE2 as figure 1. This is a typical
> 3PE scenario.
>
>The service is like this:
>
> +-++-++-+
>
> | UCE1|| APE1||SPE1 |,
>
> +-++-+`  /+-+ `.
>
>`,  .'   `.+-+
>
>..\/   | SCE1|
>
>  /\  `+-+
>
> `  `.  ,'
>
> +-++-+,' .+-+ `
>
> | uCEn|| APEn||SPE2 |`
>
> +-++-++-+
>
>There may be many Access PEs，used to access User CE. And they all
> multi-homed to a couple Servicc PE, SPE1 and SPE2.
>
>(shown as the PE1 and PE2 as figure 1)
>
> Access PE needs to detect Service PE’s reachability. Access PE
> creates SBFD session as an initiator, SPE as the reflector. This will save
> Service PEs’ resources.
>
>
>
> Regards,
>
> Haibo
>
>
>
> *From:* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Sent:* Tuesday, March 15, 2022 11:12 PM
> *To:* Wanghaibo (Rainsword) 
> *Cc:* draft-wang-bess-sbfd-discrimina...@ietf.org; BESS ;
> rtg-bfd WG 
> *Subject:* Re: A question about the draft-wang-bess-sbfd-discriminator
>
>
>
> Hi Haibo,
>
> thank you for your expedient response. If I understand the scenario you're
> addressing, it is where a single PE with moderate resources is connected to
> a PE that acts as the edge device for the access network. To improve the
> quality of user experience, customer's PE is connected to a secondary PE
> that is used as a backup. You are concerned that maintaining two BFD
> sessions on the customer's PE might overload the resource-limited PE. But
> isn't that the PE that initiates S-BFD sessions toward two access
> network edge PEs in your draft? I think that the savings are on the side of
> these two PEs, not the subscriber's PE. Would you agree?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Mar 15, 2022 at 7:20 AM Wanghaibo (Rainsword) <
> rainsword.w...@huawei.com> wrote:
>
> Hi Greg,
>
>Thanks for your comments.
>
>The scenario you pointed out is a 4PE scenario, but in our
> solution, a large number of scenarios are based on 3PE.
>
> In a 3PE scenario, deploying BFD wastes resources. A large number of
> single-homed PEs may be connected to the dual-homed PEs. The dual-homed PEs
> may not have enough resources to create BFD sessions.
>
>
>
> Regards,
>
> Haibo
>
>
>
> *From:* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Sent:* Tuesday, March 15, 2022 12:44 AM
> *To:* Wanghaibo (Rainsword) ;
> draft-wang-bess-sbfd-discrimina...@ietf.org; BESS ;
> rtg-bfd WG 
> *Subject:* A question about the draft-wang-bess-sbfd-discriminator
>
>
>
> Hi Haibo and the Authors,
>
> thank you for updating the draft. I've read the new version and have a
> question about the use case presented in the document. There are three PEs
> with two of them providing redundant access to a CE. It appears that a more
> general case would be if both CEs use redundant connections to the EVPN.
> Asume, PE4 is added and connected to CE2. In that case, it seems reasonable
> that each PE is monitoring remote PEs, i.e., PE1 monitors PE3 and PE4, PE2
> - PE3 and PE4, PE3 - PE1 and PE2, and PE4 - PE1 and PE2. So, now there are
> pairs of S-BFD sessions between PEs connected to CE1 and CE2 respectively.
> That seems like too many sessions and that number can be reduced if one
> uses BFD instead of S-BFD. Would you agree? To simplify operations, it
> might be helpful to use the technique described in
> draft-ietf-bfd-unsolicited
> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-09>. In
> the recent discussion of the draft on the BFD WG ML, the authors noted that
> they are working on extending the scope to include the multi-hop BFD.
>
> Greatly appreciate your thoughts about the number of S-BFD sessions.
>
>
>
> Regards,
>
> Greg
>
>

Re: A question about the draft-wang-bess-sbfd-discriminator

[Greg Mirsky]

Hi Haibo,
thank you for your expedient response. If I understand the scenario you're
addressing, it is where a single PE with moderate resources is connected to
a PE that acts as the edge device for the access network. To improve the
quality of user experience, customer's PE is connected to a secondary PE
that is used as a backup. You are concerned that maintaining two BFD
sessions on the customer's PE might overload the resource-limited PE. But
isn't that the PE that initiates S-BFD sessions toward two access
network edge PEs in your draft? I think that the savings are on the side of
these two PEs, not the subscriber's PE. Would you agree?

Regards,
Greg

On Tue, Mar 15, 2022 at 7:20 AM Wanghaibo (Rainsword) <
rainsword.w...@huawei.com> wrote:

> Hi Greg,
>
>Thanks for your comments.
>
>The scenario you pointed out is a 4PE scenario, but in our
> solution, a large number of scenarios are based on 3PE.
>
> In a 3PE scenario, deploying BFD wastes resources. A large number of
> single-homed PEs may be connected to the dual-homed PEs. The dual-homed PEs
> may not have enough resources to create BFD sessions.
>
>
>
> Regards,
>
> Haibo
>
>
>
> *From:* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Sent:* Tuesday, March 15, 2022 12:44 AM
> *To:* Wanghaibo (Rainsword) ;
> draft-wang-bess-sbfd-discrimina...@ietf.org; BESS ;
> rtg-bfd WG 
> *Subject:* A question about the draft-wang-bess-sbfd-discriminator
>
>
>
> Hi Haibo and the Authors,
>
> thank you for updating the draft. I've read the new version and have a
> question about the use case presented in the document. There are three PEs
> with two of them providing redundant access to a CE. It appears that a more
> general case would be if both CEs use redundant connections to the EVPN.
> Asume, PE4 is added and connected to CE2. In that case, it seems reasonable
> that each PE is monitoring remote PEs, i.e., PE1 monitors PE3 and PE4, PE2
> - PE3 and PE4, PE3 - PE1 and PE2, and PE4 - PE1 and PE2. So, now there are
> pairs of S-BFD sessions between PEs connected to CE1 and CE2 respectively.
> That seems like too many sessions and that number can be reduced if one
> uses BFD instead of S-BFD. Would you agree? To simplify operations, it
> might be helpful to use the technique described in
> draft-ietf-bfd-unsolicited
> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-09>. In
> the recent discussion of the draft on the BFD WG ML, the authors noted that
> they are working on extending the scope to include the multi-hop BFD.
>
> Greatly appreciate your thoughts about the number of S-BFD sessions.
>
>
>
> Regards,
>
> Greg
>

Re: A question about the draft-wang-bess-sbfd-discriminator

[Greg Mirsky]

Hi Reshad,
I agree with you that if in all the deployment scenarios there's always
only one node in a pair of nodes that needs to be aware of the path
continuity to the remote system, then S-BFD has an advantage compared to
"classic" RFC 5880-style BFD. I think that the use case presented in the
document is not generic. In the more general case, as I imagine, PEs
connected to CE1 and CE2 would benefit from monitoring the undelay network
continuity between them. Hence, my suggestion to use RFC 5880-style BFD
rather than S-BFD.

Regards,
Greg

On Mon, Mar 14, 2022 at 7:36 PM Reshad Rahman  wrote:

> Hi Greg, authors,
>
>
> Greg, is your point is that instead of having a pair of S-BFD sessions
> between 2 PEs, we can have 1 (traditional) BFD session between 2 PEs? In
> general I agree that S-BFD is better suited when only 1 side needs to
> perform continuity tests.
>
> Authors, in section 3.1 3rd paragraph, last sentence, I'm not sure I fully
> understand. Instead of having 2 S-BFD sessions on PE3 (as initiator) to PE1
> and PE2 (the responders), how are you merging this into 1 single session?
>
> Also, I think the document would be clearer if the terms initiator and
> responder (as per RFC7880) are used in the document.
>
> Regards,
> Reshad.
>
>
> On Monday, March 14, 2022, 12:44:55 PM EDT, Greg Mirsky <
> gregimir...@gmail.com> wrote:
>
>
> Hi Haibo and the Authors,
> thank you for updating the draft. I've read the new version and have a
> question about the use case presented in the document. There are three PEs
> with two of them providing redundant access to a CE. It appears that a more
> general case would be if both CEs use redundant connections to the EVPN.
> Asume, PE4 is added and connected to CE2. In that case, it seems reasonable
> that each PE is monitoring remote PEs, i.e., PE1 monitors PE3 and PE4, PE2
> - PE3 and PE4, PE3 - PE1 and PE2, and PE4 - PE1 and PE2. So, now there are
> pairs of S-BFD sessions between PEs connected to CE1 and CE2 respectively.
> That seems like too many sessions and that number can be reduced if one
> uses BFD instead of S-BFD. Would you agree? To simplify operations, it
> might be helpful to use the technique described in
> draft-ietf-bfd-unsolicited
> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-09>. In
> the recent discussion of the draft on the BFD WG ML, the authors noted that
> they are working on extending the scope to include the multi-hop BFD.
> Greatly appreciate your thoughts about the number of S-BFD sessions.
>
> Regards,
> Greg
>

A question about the draft-wang-bess-sbfd-discriminator

[Greg Mirsky]

Hi Haibo and the Authors,
thank you for updating the draft. I've read the new version and have a
question about the use case presented in the document. There are three PEs
with two of them providing redundant access to a CE. It appears that a more
general case would be if both CEs use redundant connections to the EVPN.
Asume, PE4 is added and connected to CE2. In that case, it seems reasonable
that each PE is monitoring remote PEs, i.e., PE1 monitors PE3 and PE4, PE2
- PE3 and PE4, PE3 - PE1 and PE2, and PE4 - PE1 and PE2. So, now there are
pairs of S-BFD sessions between PEs connected to CE1 and CE2 respectively.
That seems like too many sessions and that number can be reduced if one
uses BFD instead of S-BFD. Would you agree? To simplify operations, it
might be helpful to use the technique described in
draft-ietf-bfd-unsolicited
. In
the recent discussion of the draft on the BFD WG ML, the authors noted that
they are working on extending the scope to include the multi-hop BFD.
Greatly appreciate your thoughts about the number of S-BFD sessions.

Regards,
Greg

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

[Greg Mirsky]

Hi Jeff,
thank you for the clarification. Top-posting:

In the unsolicited draft:
- The passive side is not sending packets.
- It is waiting for an incoming session.

In my understanding, that is already defined in Section 6.1 RFC 5880:
   A system taking the
   Passive role MUST NOT begin sending BFD packets for a particular
   session until it has received a BFD packet for that session, and thus
   has learned the remote system's discriminator value.
If my understanding of RFC 5880 and the draft is correct, it appears that
the draft does not define any new local behavior but re-tells what already
has been defined in Section 6.1. Or the new behavior is that the passive
role might be not only for the specified BFD session ("particular BFD
session" in RFC 5880) but any yet unlearned BFD session? But that, in my
opinion, would require Security Considerations stepping up from
recommendations to requirements, especially when the draft includes the
multi-hop BFD scenario.

Regards,
Greg

On Tue, Mar 1, 2022 at 4:38 AM Jeffrey Haas  wrote:

> Greg,
>
> On Mon, Feb 28, 2022 at 09:34:19AM -0800, Greg Mirsky wrote:
> > it is also my impression that the concept described in the draft is
> > different from the Passive role as defined in RFC 5880. I think that
> needs
> > to be clearly explained in the draft and, it seems to be helpful to even
> > use another term to avoid any possible confusion.
>
> I spent some time reviewing the text of the draft and I don't think I agree
> with this statement.
>
> Section 2, Procuedures for Unsolicited BFD, has the following as its first
> paragraph:
>
> :   With "unsolicited BFD", one side takes the "Active role" and the
> :   other side takes only the "Passive role" as described in [RFC5880].
> :   On the passive side, the "unsolicited BFD" SHOULD be explicitly
> :   configured on an interface or globally (apply to all interfaces).
> :   The BFD parameters can be either per-interface or per-router based.
> :   It MAY also choose to use the parameters that the active side uses in
> :   its BFD Control packets.  The "My Discriminator", however, MUST be
> :   chosen to allow multiple unsolicited BFD sessions.
>
> Passive is covered in RFC 5880 section 6.1:
>
> :   A system may take either an Active role or a Passive role in session
> :   initialization.  A system taking the Active role MUST send BFD
> :   Control packets for a particular session, regardless of whether it
> :   has received any BFD packets for that session.  A system taking the
> :   Passive role MUST NOT begin sending BFD packets for a particular
> :   session until it has received a BFD packet for that session, and thus
> :   has learned the remote system's discriminator value.  At least one
> :   system MUST take the Active role (possibly both).  The role that a
> :   system takes is specific to the application of BFD, and is outside
> :   the scope of this specification.
>
> In the unsolicited draft:
> - The passive side is not sending packets.
> - It is waiting for an incoming session.
>
> I don't see a mismatch of expected behaviors.
>
> -- Jeff
>

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

[Greg Mirsky]

Hi Jeff,
it is also my impression that the concept described in the draft is
different from the Passive role as defined in RFC 5880. I think that needs
to be clearly explained in the draft and, it seems to be helpful to even
use another term to avoid any possible confusion.

Regards,
Greg

On Mon, Feb 28, 2022 at 8:35 AM Jeffrey Haas  wrote:

> Greg,
>
> Not speaking for the authors here, but:
>
> On Feb 28, 2022, at 10:34 AM, Greg Mirsky  wrote:
>
> GIM>> Thinking of what might had confused me, I feel that it may be the
> use of "passive role" that was already described in Section 6.1 RFC 5880.
> What do you see as the distinction between the Passive role behavior as
> described in RFC 5880 and the passive role described in the draft?
>
>
> The primary distinction of this proposal is whether or not a session is
> PROVISIONED at the passive side or not.
>
> It's possible to be provisioned, and passive.
>
> This draft makes the passive side at best loosely provisioned.  "I am
> willing to accept incoming BFD sessions without having one configured".
>
> -- Jeff
>
>

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

[Greg Mirsky]

Hi Reshad,
thank you for clarifying things for me, much appreciated. I have several
follow-up notes logged in-line below under the GIM>> tag.

Regards,
Greg

On Sun, Feb 27, 2022 at 8:24 AM Reshad Rahman  wrote:

> Hi Greg,
>
> Thanks for the review and comments. Please see inline.
>
> On Sunday, February 20, 2022, 05:09:22 PM EST, Greg Mirsky <
> gregimir...@gmail.com> wrote:
>
>
> Dear Authors,
> I've read the current version of the draft and have several questions.
> Greatly appreciate your consideration and feedback.
>
>- The document uses the normative language and is on the Standard
>track. At the same time, the behavior of the passive BFD system is entirely
>local and has no impact on the active BFD system. It appears like the use
>of normative language describing the implementation of the passive BFD
>system is unnecessary. It appears that the Informational track is more
>appropriate for this specification.
>
>  This was debated extensively ~15 months ago. I'll defer to Jeff H and
> John S, but the last email I have on this is the following:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_MHHti-4ImOjQ/#
>
>- It appears that the YANG data model allows the BFD unsolicited only
>for the single-hop BFD. What, in your opinion, prevents allowing it for
>multi-hop BFD?
>
>  As per reply to Gyan, we will extend the document + YANG to support
> multi-hop.
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/567Ey36geGC427ulnAqcWFag3xc/
>
GIM>> Thank you, will read and follow up on that thread.

>
>
>
>- In the following text:
>
>The "Passive role" may change to the "Active role" when a local
>
>client registers for the same BFD session, and from the "Active role
>
>" to the "Passive role " when there is no longer any locally
>
>registered client for the BFD session.
>
> it is not clear to me as to which BFD session is the reference "for the
> same BFD session". Is that for the session that is already in the Up state?
> Or something else?
>
>  It is for the already created session. So a session is created in
> "passive" state via BFD unsolicited procedure (no local client or config
> for it). After that a local client wants the same session (e.g. because BFD
> was enabled under a client), the BFD session becomes "active". We'll see if
> we can make this clearer.
>
> GIM>> Thinking of what might had confused me, I feel that it may be the
use of "passive role" that was already described in Section 6.1 RFC 5880
<http://The state of New Hampshire removes ALL Russian liquor brands from
the state-owned (yes, alcohol is a state monopoly in NH) stores.>. What do
you see as the distinction between the Passive role behavior as described
in RFC 5880 and the passive role described in the draft?

>
>
>- Two recommendations in the Security Considerations section:
>
>o  Apply "access control" to allow BFD packets only from certain
>   subnets or hosts.
> ...
>o  Use BFD authentication.
>
> leave some serious doubts that the proposed model does bring any
> operational simplification compared to explicitly configuring BFD on both
> systems (especially to use authentication).
>
>  Good point. I think it depends. e.g. if BFD authentication is already
> in use, this is not an issue.
>
> GIM>> And a thought on the Security Considerations.  All remedial steps
related to the security of BFD protocol are recommendations. What if an
implementation does not support any of them? Would it be reasonable to have
some as requirements?

>
> Regards,
> Reshad.
>
>
> Regards,
> Greg
>

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

[Greg Mirsky]

Thank you, Jeff. Let ADs discuss it when the document comes to the IESG.

Regards,
Greg

On Mon, Feb 28, 2022 at 3:39 AM Jeffrey Haas  wrote:

> Greg,
>
> On Feb 27, 2022, at 7:54 PM, Greg Mirsky  wrote:
>
> Hi Jeff,
> of course, the WG can send the document IESG on its current track. What is
> not clear to me is what is being standardized by the document. It appears
> that everything described is a local behavior that does not affect any
> other BFD system. Is my understanding correct? Or I'm missing something?
> I also have some follow-up notes to share with the authors.
>
>
> See the cited message from the OPS AD.
>
> I suggest not spending energy fighting this point in the Working Group.
> Feel free to direct your questions directly to Rob.
>
> -- Jeff
>
>
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_MHHti-4ImOjQ/#
>>
>
>

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

[Greg Mirsky]

Hi Jeff,
of course, the WG can send the document IESG on its current track. What is
not clear to me is what is being standardized by the document. It appears
that everything described is a local behavior that does not affect any
other BFD system. Is my understanding correct? Or I'm missing something?
I also have some follow-up notes to share with the authors.

Regards,
Greg

On Sun, Feb 27, 2022 at 2:53 PM Jeffrey Haas  wrote:

> On Sun, Feb 27, 2022 at 04:24:35PM +, Reshad Rahman wrote:
> > > On Sunday, February 20, 2022, 05:09:22 PM EST, Greg Mirsky <
> gregimir...@gmail.com> wrote:
> > >- The document uses the normative language and is on the Standard
> track. At the same time, the behavior of the passive BFD system is entirely
> local and has no impact on the active BFD system. It appears like the use
> of normative language describing the implementation of the passive BFD
> system is unnecessary. It appears that the Informational track is more
> appropriate for this specification.
> >  This was debated extensively ~15 months ago. I'll defer to Jeff H
> and John S, but the last email I have on this is the following:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_MHHti-4ImOjQ/#
>
> We'll stick with Proposed Standard for the time being based on conversation
> to date.  I expect that we'll get similar discussion yet again once this
> hits IESG review.  End of the day, we'll take whatever gets the document
> published. :-)
>
> -- Jeff
>

Some comments to the authors of draft-ietf-bfd-unsolicited

[Greg Mirsky]

Dear Authors,
I've read the current version of the draft and have several questions.
Greatly appreciate your consideration and feedback.

   - The document uses the normative language and is on the Standard track.
   At the same time, the behavior of the passive BFD system is entirely local
   and has no impact on the active BFD system. It appears like the use of
   normative language describing the implementation of the passive BFD system
   is unnecessary. It appears that the Informational track is more appropriate
   for this specification.
   - It appears that the YANG data model allows the BFD unsolicited only
   for the single-hop BFD. What, in your opinion, prevents allowing it for
   multi-hop BFD?
   - In the following text:

   The "Passive role" may change to the "Active role" when a local

   client registers for the same BFD session, and from the "Active role

   " to the "Passive role " when there is no longer any locally

   registered client for the BFD session.

it is not clear to me as to which BFD session is the reference "for the
same BFD session". Is that for the session that is already in the Up state?
Or something else?


   - Two recommendations in the Security Considerations section:

   o  Apply "access control" to allow BFD packets only from certain
  subnets or hosts.
...
   o  Use BFD authentication.

leave some serious doubts that the proposed model does bring any
operational simplification compared to explicitly configuring BFD on both
systems (especially to use authentication).


Regards,
Greg

Re: Working Group Last Call on BFD YANG model - round 2, RFC 9127-bis ending 14 January, 2022

[Greg Mirsky]

I support the publication of the updated BFD YANG data model (as the
co-author).

Regards,
Greg

On Wed, Jan 5, 2022 at 11:17 AM Jeffrey Haas  wrote:

> Working Group,
>
> This begins a second round of Working Group Last Call on the RFC 9127-bis
> work.
>
> As a reminder, this is primarily to address making the YANG grouping for
> client-cfg-parms have its timers made conditional on a feature supporting
> them.  This avoids implementors of importing models from needing to
> deviate those leaves out of existence if their implementation doesn't
> support them.
>
> The prior round of comments was mostly driven by what method we would
> deliver the necessary changes.  The intent to simply re-issue the prior
> version of the RFC was primarily complicated by the presence of the
> iana-bfd-types module originally published in RFC 9127.  We don't get to
> publish that again.
>
> The YANG doctors were consulted about the proposed next version that is up
> for your review.  The primary feedback was that while it is possible to do
> much less work by publishing only the changed modules, that it's
> procedurally okay for us to do this republish of the content.
>
> Please let us know if you think this document is ready for publication.
>
> -- Jeff and Reshad
>
>
> - Forwarded message from internet-dra...@ietf.org -
>
> Date: Tue, 04 Jan 2022 10:33:51 -0800
> From: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
> Cc: rtg-bfd@ietf.org
> Subject: I-D Action: draft-ietf-bfd-rfc9127-bis-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Bidirectional Forwarding Detection WG of
> the IETF.
>
> Title   : YANG Data Model for Bidirectional Forwarding
> Detection (BFD)
> Authors : Mahesh Jethanandani
>   Reshad Rahman
>   Lianshu Zheng
>   Santosh Pallagatti
>   Greg Mirsky
> Filename: draft-ietf-bfd-rfc9127-bis-01.txt
> Pages   : 68
> Date: 2022-01-04
>
> Abstract:
>This document defines a YANG data model that can be used to configure
>and manage Bidirectional Forwarding Detection (BFD).
>
>The YANG modules in this document conform to the Network Management
>Datastore Architecture (NMDA) (RFC 8342).  This document updates YANG
>Data Model for Bidirectional Forwarding Detection (BFD) (RFC 9127).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc9127-bis/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-rfc9127-bis-01
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> - End forwarded message -
>
>

Re: MPLS wg aoption poll on on draft-mirsky-mpls-p2mp-bfd

[Greg Mirsky]

Yes/support the adoption (as co-author).

Regards,
Greg

On Mon, Dec 13, 2021 at 2:53 PM Loa Andersson  wrote:

> BFD Working Group ,
>
> The MPLS working group has started an working group adopton poll on
> draft-mirsky-mpls-p2mp-bfd. Support/non-support and comments should be
> sent to the mpls mailing list (m...@ietf.org).
>
> /Loa
> --
> Loa Anderssonemail: l...@pi.nu
> Senior MPLS Expert  loa.pi...@gmail.com
> Bronze Dragon Consulting phone: +46 739 81 21 64
>
>

Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

[Greg Mirsky]

Hi Jeff,
I agree that S-BFD may provide a more suitable architectural framework for
the Unaffiliated Echo (would that then be referred to as Unaffiliated S-BFD
Echo?). Though, reading the S-BFD Echo Function section in RFC 7880, I find
that the specification allows using standalone S-BFD Echo without
periodically transmitted S-BFD Control packets. It seems precisely what is
the Unaffiliated Echo.

Regards,
Greg

On Tue, Nov 23, 2021 at 11:43 AM Jeffrey Haas  wrote:

> Greg,
>
> On Tue, Nov 23, 2021 at 09:21:42AM -0800, Greg Mirsky wrote:
> > On Mon, Nov 22, 2021 at 2:10 PM Jeffrey Haas  wrote:
> > > The desired behavior is "obvious".  If you support BFD Echo, you'd
> like to
> > > turn on that code to the remote system and do so without letting Echo
> be
> > > initiated using the Async procedures.  However, since Echo is
> intentionally
> > > under-documented in the BFD RFCs and is expected to have a paired async
> > > session, this leaves the proposal missing quite a bit.
> > >
> > GIM>> I've proposed to consider using RFCs 8562/8563 as a starting
> point. A
> > MultipointHead operates in the Demand mode, does not use the three-way
> > handshake, and the BFD state machine is Up with the first transmitted BFD
> > Control packet. True, the use of the BFD Echo function is not described
> in
> > RFCs 8562/8563 but I don't expect it would present a serious problem to
> the
> > group. The advantage of making the unaffiliated BFD Echo an extension of
> > RFCs 8562/8563, in my opinion, is that the transmitted by MultipointHead
> > BFD Control packets, though go unprocessed, would nolt affect anything.
> The
> > rate of transmission can be one in an hour, one a day. And the BFD Echo
> > function is not required to bring the BFD session state Up but can be
> used
> > to detect the failure.
>
> A place where I consider the multipoint functionality to be an awkward fit
> is that there's expected to be two participant roles: the head and the
> tail.
> For an echo solution, the local system is BOTH head and tail.
>
> This is contrasted vs. S-BFD where the Initiator expects to hear its own
> stuff back from the reflector.
>
> Valid points of comparison include that with multipoint the packets are not
> expected to be changed, but S-BFD procedure requires that the Reflector
> flip
> the discriminators.
>
> It can be observed that the state machines for S-BFD and multipoint are
> largely the same, with a slight simplification for S-BFD not having to deal
> with the Down state.  IMO, the S-BFD state machine is closer to what we're
> looking for.
>
> Observations flipping through RFC 7880 with regard to what would likely
> need
> to change to be the basis for bfd-unaffiliated pdus:
>
> The roles of Initiator and Reflector are still clear - although reflector
> is
> more literal.
>
> You'd still want to have network-wide discriminator pools to help reduce
> diagnostic headache if an Initiator get someone else's packet
> inappropriately.
>
> We'd want a new SessionType
>
> We'd still want to set demand mode.
>
> The demultiplexing critieria would need to map to a session based on the
> transmitted discriminators.  HOWEVER, some normative text would be required
> on something we don't standardize - BFD Echo format in 5880, etc.  In
> particular, the Initiator has to make sure you can distinguish received
> Echo packets as being associated with a BFD unaffiliated session perhaps
> distinctly from other Echo packets.
>
> The responder/reflector procedure is largely eliminated - this is BFD Echo
> as per RFC 5880.
>
> Many of the initiator procedures need mild tweaks because we are talking to
> ourselves rather than an active reflector.
>
> The S-bfd echo function section provides some wisdom on the security issues
> with bfd unaffiliated.
>
> -- Jeff
>

Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

[Greg Mirsky]

Hi Jeff,
thank you for the continued technical discussion. I've added my notes below
in-line under the GIM>> tag.

Regards,
Greg

On Mon, Nov 22, 2021 at 2:10 PM Jeffrey Haas  wrote:

> Greg, Xiao Min,
>
> Picking one small section of the replies as the basis of my own reply:
>
> On Wed, Nov 17, 2021 at 07:48:34AM -0800, Greg Mirsky wrote:
> > > The last sentence in the next proposed update to the RFC 5880 concerns
> me:
> > > The Echo function may also be used independently, with neither
> > > Asynchronous nor Demand mode.
> > > It appears that, if accepted, the BFD Echo function is transformed
> into an
> > > additional BFD mode. If that is the case, then this specification, in
> my
> > > opinion, is not updating the RFC 5880 but is defining a new protocol.
> > > XM>>> I tend to agree that the Unaffiliated BFD Echo can be seen as a
> new
> > > BFD mode, however I don't think it's defining a new protocol, it's
> > > definitely based on BFD protocol.
> > >
> > GIM>> If the BFD Echo is a new BFD mode then that seems to be in conflict
> > with "adjunct to both modes is the Echo function". I think that the
> > proponents of this document must decide and clarify their position in
> > regard to the status of the BFD Echo Is it a mode or function in BFD
> > protocol? Then, resulting from the answer to that question, it will be
> > clear whether the proposal is complying with RFC 5880 or not.
>
> The original versions of the document changes were primarily targeted
> toward
> updating text that forbade echo mode from running when a session was not in
> the Up state.
>
> The point that you're making, Greg, is a fair one: This draft is attempting
> to have portions of a BFD state machine signaled through the Echo port but
> is missing normative procedure.
>
> The desired behavior is "obvious".  If you support BFD Echo, you'd like to
> turn on that code to the remote system and do so without letting Echo be
> initiated using the Async procedures.  However, since Echo is intentionally
> under-documented in the BFD RFCs and is expected to have a paired async
> session, this leaves the proposal missing quite a bit.
>
GIM>> I've proposed to consider using RFCs 8562/8563 as a starting point. A
MultipointHead operates in the Demand mode, does not use the three-way
handshake, and the BFD state machine is Up with the first transmitted BFD
Control packet. True, the use of the BFD Echo function is not described in
RFCs 8562/8563 but I don't expect it would present a serious problem to the
group. The advantage of making the unaffiliated BFD Echo an extension of
RFCs 8562/8563, in my opinion, is that the transmitted by MultipointHead
BFD Control packets, though go unprocessed, would nolt affect anything. The
rate of transmission can be one in an hour, one a day. And the BFD Echo
function is not required to bring the BFD session state Up but can be used
to detect the failure.

>
> As an example, the three states of the RFC 5880 state machine assume the
> ability to transition states based on hearing one's own discriminator
> echoed
> in the Your Discriminator field.  This Discriminator swapping would not
> happen for Echo.  This is where even a more closely analogous S-BFD (RFC
> 7880)
> procedure would break down.


>
> That said, S-BFD provides probably a closer experience to what is the
> desired behavior.
>
> The question the authors have is effectively, "given the presence of an IP
> stack capable of supporting BFD Echo packet looping, how do I specify the
> least procedure to have enough of BFD for my client stack to use and change
> the least code possible?
>
> -- Jeff
>

Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

[Greg Mirsky]

Adding BBF Liaison officer David Sinicrope to the discussion.

I have a question regarding the BBF's interest in this work.
Had IETF and the BFD WG received an official liaison from BBF regarding its
interest in standardizing the mechanism mentioned in TR-146? If not, how
the BFD WG has concluded that BBF has any interest in that work?

Regards,
Greg

On Thu, Nov 18, 2021 at 6:29 AM Jeffrey Haas  wrote:

> I owe the commenters in this thread a detailed response in the near future.
> However, I did want to highlight the underlying motivation the Working
> Group
> had to pick up this work.
>
>
> On Wed, Nov 17, 2021 at 05:00:09PM +0800, xiao.m...@zte.com.cn wrote:
> > As you may have known or not, before this draft was posted, we ever tried
> > to submit an errata instead of an I-D. However, under the direction of
> the
> > responsible AD and WG chairs, we realized that an informational draft
> > might be the proper way to record our implementation and deployment. And
> > then, during the adoption poll of this draft, there was rough consensus
> > that this draft should be adopted as standards track document, so we
> > changed the intended status from informational to standards track.
>
> A core motivation for this work is to provide an IETF standardized profile
> of what is typically shipped as Broadband Forum (BBF) TR-146.  That
> mechanism, effectively running a BFD-aware system with a system that does
> NOT implement BFD but able to provide BFD Echo loopback mode.  Arguably,
> this is one step better than running ping and significantly better from a
> monitoring standpoint since BFD machinery can be leveraged on the side that
> supports it for creating events.
>
> TR-146 wasn't as clearly specified as we tend to like in IETF BFD work, so
> we're doing a flavor of that here.
>
> Prior discussion with our AD of the time suggested that this is targeted
> toward Standards Track.  But like all IETF work, once we've completed the
> draft, we may consider whether that classification remains correct.
>
> -- Jeff
>

Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

[Greg Mirsky]

Hi Xiao Min,
thank you for your quick response to my questions and comments. Please find
my follow-up notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Nov 17, 2021 at 1:00 AM  wrote:

> Hi Greg,
>
> Thanks for your thorough review and insightful questions.
> I hold the pen for draft-ietf-bfd-unaffiliated-echo, so I'd like to give
> my reply first.
> As you may have known or not, before this draft was posted, we ever tried
> to submit an errata instead of an I-D. However, under the direction of the
> responsible AD and WG chairs, we realized that an informational draft might
> be the proper way to record our implementation and deployment. And then,
> during the adoption poll of this draft, there was rough consensus that this
> draft should be adopted as standards track document, so we changed the
> intended status from informational to standards track.
> Please see inline for more responses with XM>>>.
>
> Best Regards,
> Xiao Min
> --原始邮件--
> 发件人：GregMirsky
> 收件人：draft-ietf-bfd-unaffiliated-e...@ietf.org;rtg-bfd WG;
> 日 期 ：2021年11月17日 01:40
> 主 题 ：Several questions about the draft-ietf-bfd-unaffiliated-echo
> Dear Authors,I've read the latest version and I have several questions. I
> greatly appreciate your insights and clarifications:
> Firstly, what is being standardized by this specification? I couldn't find
> that the described process requires any cooperation, action from a remote
> BFD peer. As I can see, only the sender of BFD Echo packets is acting and
> thus every action, e.g., construction of the test probe, a method to
> demultiplex incoming test packets, etc., is internal to the sender. Hence,
> it appears that there is nothing to be standardized as all of it is
> internal processing that does not impact any other BFD system.
> XM>>> The intention is to record a popular use of the BFD Echo function
> that doesn't comply with RFC 5880, at the same time this document does some
> clean-ups to RFC 5880.
>
GIM>> In my opinion, if something doesn't comply with the protocol, then it
must be re-worked, not the protocol. If that is not possible, then,
probably, that is not really a part of the protocol.

>
> The first update to RFC 5880 seems to suggest that the Echo function is an
> essential part of both Asynchronous and Demand modes of BFD. The original
> text of RFC 5880 characterizes the Echo function as an adjunct, i.e., a
> supplemental, function. The proposed new text - as a function that
> completes both BFD modes, makes them perfect, i.e., is an essential,
> necessary component. I think that that is not really the case and the BFD
> Echo function is not an essential, optional function of the BFD protocol.
> XM>>> Does s/complement/supplement work for you?
>
GIM>> That is better but "adjunct" has the same meaning as "complement". I
propose removing "complement" altogether and, as the result, leaving the
text in RFC 5880 unchanged.

>
> The last sentence in the next proposed update to the RFC 5880 concerns me:
> The Echo function may also be used independently, with neither
> Asynchronous nor Demand mode.
> It appears that, if accepted, the BFD Echo function is transformed into an
> additional BFD mode. If that is the case, then this specification, in my
> opinion, is not updating the RFC 5880 but is defining a new protocol.
> XM>>> I tend to agree that the Unaffiliated BFD Echo can be seen as a new
> BFD mode, however I don't think it's defining a new protocol, it's
> definitely based on BFD protocol.
>
GIM>> If the BFD Echo is a new BFD mode then that seems to be in conflict
with "adjunct to both modes is the Echo function". I think that the
proponents of this document must decide and clarify their position in
regard to the status of the BFD Echo Is it a mode or function in BFD
protocol? Then, resulting from the answer to that question, it will be
clear whether the proposal is complying with RFC 5880 or not.

>
> For all the proposed updates to the RFC 5880, it is not clear why in some
> proposed texts, both modes, Asynchronous, and Demand, are referenced but in
> some only the Asynchronous. For example, updates to Section 6.1, Section
> 6.4, and Section 6.8.3 refer only to the Asynchronous mode, while updates
> to Section 6.8 and Section 6.8.9 - refer to both BFD modes.
> XM>>> As I recall it, the reason is that some updated text applies to
> Asynchronous mode only, and some others applies to both modes.
>
GIM>> As I understand it, BFD Echo applies to both BFD modes - Asynchronous
and Demand. The text in RFC 5880 is clear about that in the following "An
adjunct to both modes is the Echo function." I think that these updates of
RFC 5880 are more confusing and not necessary. I propose removing them
altogether.

>
> In the second paragraph of Section 3 of the draft, the specification
> recommends that an implementation supporting this draft follows the BFD
> state machine, as defined in RFC 5880. Why is it a recommendation and not a
> 

Several questions about the draft-ietf-bfd-unaffiliated-echo

[Greg Mirsky]

Dear Authors,
I've read the latest version and I have several questions. I greatly
appreciate your insights and clarifications:

   - Firstly, what is being standardized by this specification? I couldn't
   find that the described process requires any cooperation, action from a
   remote BFD peer. As I can see, only the sender of BFD Echo packets is
   acting and thus every action, e.g., construction of the test probe, a
   method to demultiplex incoming test packets, etc., is internal to the
   sender. Hence, it appears that there is nothing to be standardized as
   all of it is internal processing that does not impact any other BFD system.
   - The first update to RFC 5880 seems to suggest that the Echo function
   is an essential part of both Asynchronous and Demand modes of BFD. The
   original text of RFC 5880 characterizes the Echo function as an adjunct,
   i.e., a supplemental, function. The proposed new text - as a function that
   completes both BFD modes, makes them perfect, i.e., is an essential,
   necessary component. I think that that is not really the case and the BFD
   Echo function is not an essential, optional function of the BFD protocol.
   - The last sentence in the next proposed update to the RFC 5880 concerns
   me:

The Echo function may also be used independently, with neither Asynchronous
nor Demand mode.

It appears that, if accepted, the BFD Echo function is transformed into an
additional BFD mode. If that is the case, then this specification, in my
opinion, is not updating the RFC 5880 but is defining a new protocol.


   - For all the proposed updates to the RFC 5880, it is not clear why
   in some proposed texts, both modes, Asynchronous, and Demand, are
   referenced but in some only the Asynchronous. For example, updates to
   Section 6.1, Section 6.4, and Section 6.8.3 refer only to the Asynchronous
   mode, while updates to Section 6.8 and Section 6.8.9 - refer to both BFD
   modes.
   - In the second paragraph of Section 3 of the draft, the specification
   recommends that an implementation supporting this draft follows the BFD
   state machine, as defined in RFC 5880. Why is it a recommendation and not a
   requirement? And further, if an implementation does not follow the BFD
   state machine, is it still BFD?
   - Further, in the third paragraph of Section 3, it appears that the BFD
   Echo function on device A starts transmitting BFD control packets once the
   session is created. What is the state of the created BFD Echo session? As I
   understand it, the BFD state machine starts from the Init. Isn't that the
   case for this document as well?
   - In the same first sentence of the third paragraph in Section 3,
   another recommendation reads as "SHOULD include a BFD Echo session
   demultiplexing field". I have questions similar to the recommendation in
   the second paragraph of Section 3:
  - Why is it a recommendation and not a requirement?
  - What happens if an implementation does not include that particular
  field in the transmitted packets? Is it still a BFD Echo? How
then sessions
  are demultiplexed?

I greatly appreciate your consideration and help in clarifying these
aspects of the draft.

Now, I may have an alternative proposal that can produce the desired result
and not require any update to RFC 5880. Please consider the following:

   - RFC 8562 introduced a new type of the BFD session - MultipointHead. A
   system acting as the MultipointHead periodically transmits BFD Control
   packets in Demand mode, doesn't have the Init state, and starts in the Up
   state (no three-way handshake).
   - Considering the above, a system that uses the Unaffiliated BFD Echo
   starts as MultipointHead with bfd.DesiredMinTxInterval set to the maximum
   value (or any sanely large enough). The exact construction of the periodic
   BFD Control packets transmitted by the MultipointHead needs some detailed
   analysis (I haven't spent enough time on that).
   - In the meantime, because the BFD session for the MultipointHead
   started in the Up state, it can transmit BFD Echo packets according to RFC
   5880 and RFC 8562.

I think that if this proposal works, it may be moved as Informational since
it describes the use of well-known BFD principles and mechanisms in an
innovative and useful manner.
What are your thoughts, questions?

Regards,
Greg

Re: Progressing BFD unsolicited

[Greg Mirsky]

Hi Robert and the Authors,
thank you for your kind consideration of my comments and for addressing
them so thoughtfully. I have two editorial suggestions that can be used, if
you decide so, at a later date:

   - as the text refers to the format of a BFD control message, then it
   seems appropriate to s/"Discriminator"/"My Discriminator"
   - Minor re-wording:

OLD TEXT:
When on the passive side Unsolicited BFD sessions goes down an
implementation MAY keep such session state for a configurable amount
of time.  Temporarily keeping such local state may permit retrieving
additional operational information of such session which went down.
NEW TEXT:
When a session goes down on the passive side of an Unsolicited BFD,
an implementation MAY keep such a state for a configurable amount of
time. Temporarily keeping such a local state may permit retrieving
additional operational information of such session which went down.

Regards,
Greg

On Mon, Oct 18, 2021 at 12:39 PM Robert Raszuk  wrote:

> Hi Jeff & Greg,
>
> I have just submitted -04 version. I believe together with co-authors we
> have addressed all the comments received so far.
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
>
> Hope that we can move forward with this work.
>
> Kind regards,
> Robert
>
>
>
> On Fri, Oct 15, 2021 at 9:18 PM Jeffrey Haas  wrote:
>
>> Working Group,
>>
>> Now that the BFD YANG work is getting ready to pop out of the RFC Editor's
>> queue, it's an appropriate time to finish the last minor details for the
>> BFD Unsolicited draft.
>>
>> Previously, the draft had exited Working Group Last Call with minor things
>> to be resolved, and a process question about where this draft should be
>> with
>> regards to the standard process.  Our conversation with our Area Director
>> at
>> that time and other associated IESG members suggested that Proposed
>> Standard
>> status was appropriate.
>>
>> Greg Mirsky had made a number of comments, several which have been at
>> least
>> partially addressed in the current version of the draft.  Note that the
>> top
>> of the thread corresponds to the Working Group feedback during WGLC.
>>
>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/naYc-qtNmf8ZH2sRF8S76DqzgYc/
>>
>> I encourage the Working Group to review the draft and the comments to
>> date.
>> After resolving them, I believe we're ready to have a shepherd writeup and
>> send this to the IESG.
>>
>> -
>>
>> Addressing points Greg has raised:
>> - "Does this document update RFC 5881?"
>>
>>   In my opinion, we're introducing no procedural changes vs. RFC
>> 5880/5881.
>>   The passive mode documented in RFC 5880 is being leveraged.  We're
>> simply
>>   not explicitly provisioning the session.  Others in the WGLC thread
>>   support not marking this as an update.
>>
>> - "node-wise configuration"
>>
>>   I believe that has been addressed in the current version of the draft.
>>
>> - Greg writes: "The fourth paragraph in Section 2 explains the handling of
>>   the first BFD control packet with Your Discriminator == 0, i.e., "it
>> does
>>   not find an existing session with the same source address". What happens
>>   if the matching BFD session has been found?"
>>
>>   This case could use a small amount of normative text.  For reference,
>> here
>>   is the text from RFC 5880, §6.8.6:
>>
>>   :   If the Your Discriminator field is zero, the session MUST be
>>   :   selected based on some combination of other fields, possibly
>>   :   including source addressing information, the My Discriminator
>>   :   field, and the interface over which the packet was received.  The
>>   :   exact method of selection is application specific and is thus
>>   :   outside the scope of this specification.  If a matching session is
>>   :   not found, a new session MAY be created, or the packet MAY be
>>   :   discarded.  This choice is outside the scope of this
>>   :   specification.
>>
>>   One easy possibility is that there is an existing session, or one that
>> may
>>   be failing shortly.  Discarding the received packets in this
>> circumstance
>>   until there is no existing session might be an appropriate response.
>>
>> - Greg write: "Does that mean that there will be only one session
>>   with the same source address despite different destination addresses
>>   listed?"
>>
>>   One point of comparison is that the single-hop BFD YANG module is
>> indexed
>>   on 

Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-10.txt

[Greg Mirsky]

Dear All,
the update in this version describes the benefits of using BFD for
multipoint networks (RFCs 8562 and 8563) over p2p MPLS LSP. Because RFC
8562 updated the BFD state machine, actors avoid the Init state and do not
use the three-way handshake to advance the BFD session to the Up state.
Thus, the value of My Discriminator, used by MultipointTail do demultiplex
BFD sessions, must be provisioned by other means, e.g., using an extension
to an IGP protocol. An unsolicited notification from a MultipointTail that
detected failure of the BFD session to the MultipointHead can be used as
described in the draft.

Your comments, questions, and suggestions are welcome.
I ask for consideration of adopting this document. It describes a new
mechanism (complementary to RFC 5884) that can be used to detect failures
in MPLS and SR-MPLS networks.

Regards,
Greg

-- Forwarded message -
From: 
Date: Fri, Oct 1, 2021 at 4:44 PM
Subject: New Version Notification for draft-mirsky-bfd-mpls-demand-10.txt
To: Greg Mirsky 



A new version of I-D, draft-mirsky-bfd-mpls-demand-10.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-mirsky-bfd-mpls-demand
Revision:   10
Title:  BFD in Demand Mode over Point-to-Point MPLS LSP
Document date:  2021-10-01
Group:  bfd
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-10.txt
Status:
https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/
Html:
https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-10.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-demand
Diff:
https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-mpls-demand-10

Abstract:
   This document describes procedures for using Bidirectional Forwarding
   Detection (BFD) in Demand mode to detect data plane failures in
   Multiprotocol Label Switching (MPLS) point-to-point Label Switched
   Paths.




The IETF Secretariat

Fwd: Expiration impending:

[Greg Mirsky]

Dear All,
this reminder has prompted a question What the WG decides to do with the
draft? The draft presents the collected view of several discussion threads
we had over quite some time. In these discussions, a number of
clarification points for RFC 5884 have been identified. These are
documented in the draft. I believe that the information improves
interoperability of implementations of RFC 5884.
I greatly appreciate the WG consideration and suggestions on the next
steps. Is the WG interested in adapting this work or should it fall into
the abyss?

Regards,
Greg

-- Forwarded message -
From: IETF Secretariat 
Date: Sun, Sep 19, 2021 at 12:00 AM
Subject: Expiration impending:

To: 


The following draft will expire soon:

Name: draft-mirsky-mpls-bfd-bootstrap-clarify
Title:Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP
State:I-D Exists
Expires:  2021-10-01 (in 1 week, 4 days)

Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky]

Hi Med,
thank you for your thoughtful consideration of my comments. I have another
question about the significance of the local-multiplier (formerly
detection-multiplier). The description seems not changed and it states:
"The detection interval for the BFD session
 is calculated by multiplying the value of
 the negotiated transmission interval by
 the detection multiplier value.";
I will note that the detection multiplier value used by a BFD system to
calculate the Detection Time is not its local Detection Multiplier but the
value of the Detect Mult field in the received BFD control packet. In other
words, that is the local-multiplier of the remote BFD peer. Section 6.8.4
in RFC 5880 <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.4>
describes how the Detection Time is calculated for "classic" p2p BFD. Note,
the Detection Time for a MultipointTail in p2mp session is calculated
differently, according to Section 5.11 RFC 8562.

Regards,
Greg

On Fri, Sep 3, 2021 at 12:35 AM  wrote:

> Hi Greg,
>
>
>
> FWIW, the agreed changes are now implemented in the module. You can track
> them at:
>
>
> https://github.com/IETF-OPSAWG-WG/lxnm/commit/9b97016743a355f2b7737288dfaedebcdc47c9b8
>
>
>
> Also, made the companion changes to the I-D:
> https://tinyurl.com/l3nm-latest
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Envoyé :* mercredi 1 septembre 2021 15:25
> *À :* BOUCADAIR Mohamed INNOV/NET 
> *Cc :* Jeffrey Haas ; draft-ietf-opsawg-l3sm-l...@ietf.org;
> opsawg ; rtg-bfd WG 
> *Objet :* Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
>
>
>
> Hi Med,
>
> thank you for your thoughtful consideration of my late comments.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Sep 1, 2021 at 6:21 AM  wrote:
>
> Re-,
>
> The IETF LC was actually closed since 2021-08-06.
>
> Even if the IETF LC is closed, the current BFD comments will be part of
> the comments we will be addressing in the next iteration. For your record,
> we have already recorded the name alignment fix, the missing default
> clause, holdtime explanation, and session type indication.
>
> If there are any other comments, please let us know.
>
> Thank you.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Jeffrey Haas [mailto:jh...@pfrc.org]
> > Envoyé : mercredi 1 septembre 2021 14:38
> > À : BOUCADAIR Mohamed INNOV/NET 
> > Cc : Greg Mirsky ; draft-ietf-opsawg-l3sm-
> > l...@ietf.org; opsawg ; rtg-bfd WG  > b...@ietf.org>
> > Objet : Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
> >
> > Med,
> >
> > On Wed, Sep 01, 2021 at 06:48:43AM +,
> > mohamed.boucad...@orange.com wrote:
> > > Hi Jeff,
> > >
> > > Actually, except local-multiplier that we call detection-
> > multiplier,
> > > the same names are used in both drafts. We can fix that one.
> >
> > Certainly a start.
> >
> > > Please note that we are not using the interval-config-type choice
> > > given that the single case can be covered by setting
> > > desired-min-tx-interval and required-min-rx-interval to the same
> > value.
> >
> > This is true.  It's also true that that style entered the BFD YANG
> > model because a unified-only mechanism is what some vendors have
> > implemented.  If their implementations don't cover the split mode
> > you're requiring them to create a deviation.
> >
> > > It is then straightforward to
> > > map it the device module depending whether single-minimum-interval
> > > feature is supported or not. We don't want to complicate the
> > network
> > > view of the service with such device-level features.
> >
> > There is always a tension between service models and the needs of
> > the underlying device model.
> >
> > That said, you're losing the benefits of work already done.  As an
> > example, you're missing the default detection multiplier because
> > you're doing the work yourself rather than leveraging other work.
> > This means you're requiring the model users to always provision a
> > paramter that is usually left as a default.
> >
> > Clearly the BFD Working Group can't force you to use our work in
> > your model, especially if there are features that aren't a clean
> > fit.  That said, when it comes IETF review time, the choice to go-
> > it-alone will be noted so that the YANG doctors can do an
> > appropriately thorough audit.
> >
> > T

Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky]

Hi Med,
thank you for your thoughtful consideration of my late comments.

Regards,
Greg

On Wed, Sep 1, 2021 at 6:21 AM  wrote:

> Re-,
>
> The IETF LC was actually closed since 2021-08-06.
>
> Even if the IETF LC is closed, the current BFD comments will be part of
> the comments we will be addressing in the next iteration. For your record,
> we have already recorded the name alignment fix, the missing default
> clause, holdtime explanation, and session type indication.
>
> If there are any other comments, please let us know.
>
> Thank you.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Jeffrey Haas [mailto:jh...@pfrc.org]
> > Envoyé : mercredi 1 septembre 2021 14:38
> > À : BOUCADAIR Mohamed INNOV/NET 
> > Cc : Greg Mirsky ; draft-ietf-opsawg-l3sm-
> > l...@ietf.org; opsawg ; rtg-bfd WG  > b...@ietf.org>
> > Objet : Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
> >
> > Med,
> >
> > On Wed, Sep 01, 2021 at 06:48:43AM +,
> > mohamed.boucad...@orange.com wrote:
> > > Hi Jeff,
> > >
> > > Actually, except local-multiplier that we call detection-
> > multiplier,
> > > the same names are used in both drafts. We can fix that one.
> >
> > Certainly a start.
> >
> > > Please note that we are not using the interval-config-type choice
> > > given that the single case can be covered by setting
> > > desired-min-tx-interval and required-min-rx-interval to the same
> > value.
> >
> > This is true.  It's also true that that style entered the BFD YANG
> > model because a unified-only mechanism is what some vendors have
> > implemented.  If their implementations don't cover the split mode
> > you're requiring them to create a deviation.
> >
> > > It is then straightforward to
> > > map it the device module depending whether single-minimum-interval
> > > feature is supported or not. We don't want to complicate the
> > network
> > > view of the service with such device-level features.
> >
> > There is always a tension between service models and the needs of
> > the underlying device model.
> >
> > That said, you're losing the benefits of work already done.  As an
> > example, you're missing the default detection multiplier because
> > you're doing the work yourself rather than leveraging other work.
> > This means you're requiring the model users to always provision a
> > paramter that is usually left as a default.
> >
> > Clearly the BFD Working Group can't force you to use our work in
> > your model, especially if there are features that aren't a clean
> > fit.  That said, when it comes IETF review time, the choice to go-
> > it-alone will be noted so that the YANG doctors can do an
> > appropriately thorough audit.
> >
> > The BFD Working Group is also happy to help with review once it's
> > time.
> >
> > -- Jeff
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>

Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky]

Hi Med,
thank you for your detailed feedback; much appreciated. I think that I now
understand better the philosophy of the model. But I will note that RFC
5880 does not cover RFC 7880 and 8562 (both have updated RFC 5880). It
seems that adding bfd-session-type could be a very useful enhancement to
the OAM container. Values for the new parameter should reflect values
defined for bfd.SessionType in RFCs 7880, 8562, and 8563:

   - SBFDInitiator;
   - SBFDReflector;
   - PointToPoint;
   - MultipointHead;
   - MultipointTail;
   - MultipointClient

And my apologies for my late comments.

Regards,
Greg

On Mon, Aug 30, 2021 at 5:19 AM  wrote:

> Hi Greg,
>
>
>
> Thank you for checking the OAM part and for sharing this comment.
>
>
>
> As you can read in both sections 4 and 5, this model is ** not a device
> configuration model **. The focus is on aspects that can be triggered by
> service requests and managed by the network controller. This network view
> of the service will be then enriched (with other sources such as local
> templates/profiles/defaults) to derive the exhaustive configuration that
> will be enforced in involved devices to deliver the requested service.
>
>
>
> With that rationale in mind, you can understand why we don’t import device
> models but point to the authoritative RFCs for aspects that we think make
> sense to be tweaked at the network-level.
>
>
>
> Thanks.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Envoyé :* samedi 28 août 2021 04:56
> *À :* draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg ;
> rtg-bfd WG 
> *Objet :* A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
>
>
>
> Dear Authors,
>
> thank you for your work on this document. I've read the draft and have a
> question, and a suggestion. Section 7.6.4
> <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm#section-7.6.4>
>  describes
> how BFD is controlled in vpn-common. I've noticed that you use references
> to RFC 5880. While that is the basis for all subsequent BFD documents, for
> BFD YANG data model draft-ietf-bfd-yang
> <https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/> may be more
> useful. Perhaps the container oam can re-use grouping base-cfg-parms.
>
> What are your thoughts?
>
>
>
> Regards,
>
> Greg
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>

A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky]

Dear Authors,
thank you for your work on this document. I've read the draft and have a
question, and a suggestion. Section 7.6.4

describes
how BFD is controlled in vpn-common. I've noticed that you use references
to RFC 5880. While that is the basis for all subsequent BFD documents, for
BFD YANG data model draft-ietf-bfd-yang
 may be more useful.
Perhaps the container oam can re-use grouping base-cfg-parms.
What are your thoughts?

Regards,
Greg

Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110

[Greg Mirsky]

Hi Reshad, et al,
I support the proposal to split the BFD YANG data model and move the TE
part of the model into a separate new document (working group or
individual, s suggested by WG Chairs).

Regards,
Greg

On Mon, Mar 22, 2021 at 2:34 AM tom petch  wrote:

>
>
> From: Rtg-bfd  on behalf of Reshad Rahman
> 
> Sent: 19 March 2021 18:58
> To: rtg-bfd@ietf. org
> Subject: Draft minutes for BFD @ IETF110
>
> BFD WG,
>
> Draft minutes have been posted @
> https://datatracker.ietf.org/doc/minutes-110-bfd/
>
> Please provide comments to the list by April 2nd.
> 
>
> I support Acee's suggestion that the TE part should be split from the BFD
> YANG draft so that the other three WG, who have been held up for years, can
> progress.
>
> Tom Petch
>
> Copying the LSR WG.
>
>
> Meeting recording is @ https://www.youtube.com/watch?v=vSqfJJ3gOc0
>
> Regards,
> Reshad.
>
> ___
> Lsr mailing list
> l...@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>

Re: I-D Action: draft-ietf-bfd-yang-17.txt

[Greg Mirsky]

Hi Reshad,
I've got them. I will re-send several from the RFC Editor shortly.

Regards,
Greg

On Sat, Dec 19, 2020 at 7:08 AM Reshad Rahman  wrote:

> Hi,
>
> We have had discussions recently with the RFC Editor wrt changes needed in
> draft-ietf-bfd-yang. Unfortunately I don't have access to those emails
> anymore. I don't know whether we can access the latest text in the draft.
>
> Regards,
> Reshad.
>
> On 2020-12-19, 8:04 AM, "Rtg-bfd on behalf of tom petch" <
> rtg-bfd-boun...@ietf.org on behalf of ie...@btconnect.com> wrote:
>
> From: Rtg-bfd  on behalf of tom petch <
> ie...@btconnect.com>
> Sent: 06 November 2020 12:58
>
> From: Reshad Rahman (rrahman) 
> Sent: 21 August 2020 12:31
>
> On 2020-08-21, 5:57 AM, "tom petch"  wrote:
>
> From: Reshad Rahman (rrahman) 
> Sent: 20 August 2020 18:42
>
> I had noticed the lsps vs lsps-state, mentioned it at last BFD WG
> meeting and have been in touch with the teas-yang authors.
>
> I hadn't noticed that mpls:enabled had been removed. I'll have to
> go through all MPLS-related items in the BFD yang.
>
> 
> mpls-base has been approved by the IESG and is wending its way through
> the system and that is a Normative dependency for bfd-yang so the there
> might be progress on bfd-yang.  I had a look at the tools pages and MISSREF
> but do not understand what it is telling me:-(
>
> 
>
> mpls-base is now RFC8960.  As yet I do not see any consequential
> changes in the I-D in the RFC Editor Q but I am not sure what I should be
> looking for so I shall keep looking :-)
>
> Tom Petch
>
>
> 
> Yes please; enabled is still there but in a different place; I
> have not gone back to mpls-base-yang-03 to see if the semantics are the
> same.
>
> Note my third rather indecisive comment that mpls-base-yang now
> models mpls in a different way, splitting IP routes with some MPLS, from
> MPLS only routes, with no IP, as described in mpls-base-yang-15; I have not
> got my head around this and do not know how it fits with bfd but suspect
> that it needs some thinking about.
>  I don't think it has an impact because BFD uses an IP-prefix as
> MPLS-FEC. But I will take a look.
>
> I read the meeting minutes but your significant (for me)
> contribution appears to have passed the minute taker by:-)
>   It was mentioned in the chairs slides though.
>
> Regards,
> Reshad.
>
> Tom Petch
>
>
>
> Regards,
> Reshad.
>
> On 2020-08-20, 12:33 PM, "t petch"  wrote:
>
> Yes bfd-yang.  Sometimes I would like to be wrong.
>
> When I look at this I-D, I see that it references
>
>  /rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:enabled
> In 2018, the MPLS WG removed that /config from the
> mpls-base-yang so
> this would seem to be no longer valid. What needs changing to
> rectify
> this I have not explored.
>
> The I-D has
>   augment "/te:te/te:lsps-state/te:lsp"
> which I no longer see in  draft-ietf-teas-yang-te - the -state
> has gone.
> Again, I have not explored the ramifications of this.
>
> MPLS WG has a new base-yang out this week which differentiates
> between
> an IP route with a MPLS next hop and a MPLS route with no IP,
> the latter
> forming a new, mpls Address Family.  I would think that the
> latter is
> not catered for by BFD but it would be nice to be wrong
>
> Tom Petch
>
>
>
>
>
>
>
>

Fwd: New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-01.txt

[Greg Mirsky]

Dear All,
We welcome a new co-author, Gyan.
There are no technical changes but several editorial nits.
I recall that following the presentation of this draft a couple of years
ago it was suggested that there might be an interest to start 5884bis.
Welcome your comments, suggestions on the technical aspects of the draft
and possible next steps to progress this work.

Regards,
Greg

-- Forwarded message -
From: 
Date: Tue, Dec 8, 2020 at 4:28 PM
Subject: New Version Notification for
draft-mirsky-mpls-bfd-bootstrap-clarify-01.txt
To: Gyan Mishra , Yanhua Zhao <
zhao.yanh...@zte.com.cn>, Greg Mirsky 



A new version of I-D, draft-mirsky-mpls-bfd-bootstrap-clarify-01.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-mirsky-mpls-bfd-bootstrap-clarify
Revision:   01
Title:  Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP
Document date:  2020-12-08
Group:  Individual Submission
Pages:  4
URL:
https://www.ietf.org/archive/id/draft-mirsky-mpls-bfd-bootstrap-clarify-01.txt
Status:
https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-bootstrap-clarify/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-mirsky-mpls-bfd-bootstrap-clarify
Htmlized:
https://tools.ietf.org/html/draft-mirsky-mpls-bfd-bootstrap-clarify-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-mirsky-mpls-bfd-bootstrap-clarify-01

Abstract:
   This document, if approved, updates RFC 5884 by clarifying procedures
   for using MPLS LSP ping to bootstrap Bidirectional Forwarding
   Detection (BFD) over MPLS Label Switch Path.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Re: Robert Wilton's No Objection on draft-ietf-bfd-vxlan-15: (with COMMENT)

[Greg Mirsky]

Hi Rob,
thank you for your comments and apologies for the delay. I've uploaded the
new version with the updates to address your comments:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bfd-vxlan-16
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-16


Please let me know if you have any questions.

Best regards,
Greg

On Fri, Oct 2, 2020 at 11:42 AM Greg Mirsky  wrote:

> Hi Rob,
> thank you for your review and helpful comments. Please find my notes
> in-line below tagged GIM>>.
> I've attached the diff highlighting the changes applied and the new
> working version of the draft.
>
> Kind regards,
> Greg
>
> On Fri, Oct 2, 2020 at 5:59 AM Robert Wilton via Datatracker <
> nore...@ietf.org> wrote:
>
>> Robert Wilton has entered the following ballot position for
>> draft-ietf-bfd-vxlan-15: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Hi,
>>
>> This document seems pretty straight forward to me.  A few, non blocking,
>> comments:
>>
>> Assigning a single unicast MAC address seems slightly odd in that it isn't
>> globally unique, but I can't think of any good alternative.
>>
>>At the same time, a service layer BFD session may be used between the
>>tenants of VTEPs IP1 and IP2 to provide end-to-end fault management
>>(this use case is outside the scope of this document).  In such a
>>case, for VTEPs BFD Control packets of that session are
>>indistinguishable from data packets.
>>
>> "for VTEPs BFD Control" => "for VTEPS, the BFD Control"
>>
> GIM>> Thank you. Accepted.
>
>>
>>  Ethernet Header:
>>
>>  Destination MAC: A Management VNI, which does not have any
>>  tenants, will have no dedicated MAC address for decapsulated
>>  traffic.  The value (TBD1) SHOULD be used in this field.
>>
>>  Source MAC: MAC address associated with the originating VTEP.
>>
>> Should the TypeOrLen field in the Ethernet header also be specified
>> (presumably
>> set to IPv4 or IPv6)?
>>
> GIM>> Thank you for the suggestion. I've added the following:
> NEW TEXT:
>  Ethertype: is set to 0x0800 if the inner IP header is IPv4, and
>  is set to 0x86DD if the inner IP header is IPv6.
>
>>
>> Regards,
>> Rob
>>
>>
>>
>>

Fwd: I-D Action: draft-ietf-bfd-vxlan-15.txt

[Greg Mirsky]

Dear All,
this version includes ALL updates resulting from the IESG reviews. All
DISCUSSes have been addressed.

Kind regards,
Greg (for the authors)

-- Forwarded message -
From: 
Date: Thu, Oct 1, 2020 at 3:45 PM
Subject: I-D Action: draft-ietf-bfd-vxlan-15.txt
To: 
Cc: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Bidirectional Forwarding Detection WG of
the IETF.

Title   : BFD for VXLAN
Authors : Santosh Pallagatti
  Greg Mirsky
  Sudarsan Paragiri
  Vengada Prasad Govindan
  Mallik Mudigonda
Filename: draft-ietf-bfd-vxlan-15.txt
Pages   : 11
Date: 2020-10-01

Abstract:
   This document describes the use of the Bidirectional Forwarding
   Detection (BFD) protocol in point-to-point Virtual eXtensible Local
   Area Network (VXLAN) tunnels used to form an overlay network.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bfd-vxlan-15
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Re: Benjamin Kaduk's No Objection on draft-ietf-bfd-vxlan-14: (with COMMENT)

[Greg Mirsky]

Hi Ben,
many thanks for your comments, suggestions and the discussions. These
helped a lot in making the better document. Please find my notes in
response to your comments below under the GIM>> tag.

Regards,
Greg

On Tue, Sep 29, 2020 at 1:31 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bfd-vxlan-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the discussions around my discuss point, and the ensuing
> changes
> resulting from the discussions!  My apologies that I was tardy in
> re-reviewing after
> the updates were made.
>
> I think the core issues have been resolved, but do have a couple comments
> on the -14:
>
> Section 3 says:
>
>   Separate BFD sessions can be established between the
>VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100
>and 200).  Using a BFD session to monitor a set of VXLAN VNIs between
>the same pair of VTEPs might help to detect and localize problems
>caused by misconfiguration.  An implementation that supports this
>specification MUST be able to control the number of BFD sessions that
>can be created between the same pair of VTEPs.  [...]
>
> While the first two sentences are probably true, they are arguably out
> of scope for this document, since Section 6 says that BFD control
> packets on non-management VNI is outside the scope of this
> specification.

GIM>> Yes, the document describes applicability of BFD over the Management
VNI. Procedures described in the document might work for non-managemnt VNIs
but the document doesn't make any assumption about that. And that is why a
case of non-management VNI was set outside the scope of the specification.

> The third sentence is quite surprising in the context of
> this document only defining BFD for the management VNI, since multiple
> BFD sessions on the same VNI seem redundant.
>
GIM>> True. The intention was to suggest that if an implementation may be
used on non-management VNIs, then the number of concurrent BFD sessions
must be controlled. I think that it is unlikely that there will be a
document that will define BFD over VXLAN for non-managemet VNIs and
developers may appreciate some guidance this document provides.

>
> Section 5
>
>  Destination MAC: A Management VNI, which does not have any
>  tenants, will have no dedicated MAC address for decapsulated
>  traffic.  The value [TBD1] SHOULD be used in this field.
>
> While this normative language seems like the appropriate level of
> stringency, I do find myself wondering what other value might be used
> and why.  (This, of course, need not be answered in the document, though
> it could be if the answer is known and useful.)
>
GIM>> There are early implementations that have been deployed that use
other MAC values. We might disagree with their choice but wanted to allow
thier conformance to this specification.

Fwd: I-D Action: draft-mirsky-bfd-mpls-demand-08.txt

[Greg Mirsky]

Dear All,
the updates in this version intended to address comments received from WG
Chairs and WG's AD.
Your questions, comments, and suggestions are always welcome and greatly
appreciated.

Regards,
Greg

-- Forwarded message -
From: 
Date: Wed, Sep 9, 2020 at 1:54 PM
Subject: I-D Action: draft-mirsky-bfd-mpls-demand-08.txt
To: 
Cc: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Bidirectional Forwarding Detection WG of
the IETF.

Title   : BFD in Demand Mode over Point-to-Point MPLS LSP
Author  : Greg Mirsky
Filename: draft-mirsky-bfd-mpls-demand-08.txt
Pages   : 5
Date: 2020-09-09

Abstract:
   This document describes procedures for using Bidirectional Forwarding
   Detection (BFD) in Demand mode to detect data plane failures in
   Multiprotocol Label Switching (MPLS) point-to-point Label Switched
   Paths.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-08
https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-demand-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-mpls-demand-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Re: Conclusion of the discussion on draft-mirsky-bfd-mpls-demand?

[Greg Mirsky]

Hi Jeff, et al.,
thank you for your thorough review and the most detailed comments, all is
greatly appreciated. Please find my notes in-lined and tagged by GIM>>.
I've updated the draft and you can review the updates in the attached diff.
I much appreciate comments on the updates.

Regards,
Greg

On Tue, Aug 18, 2020 at 11:03 AM Jeffrey Haas  wrote:

> Greg,
>
> Thank you for your patience.
>
> On Thu, Jul 30, 2020 at 09:00:38AM -0700, Greg Mirsky wrote:
> > Dear All,
> > I much appreciate it if you can share the conclusion of the discussion of
> > the draft-mirsky-bfd-mpls-demand.
> >
> > Regards,
> > Greg
>
> The BFD Working Group chairs and Area Director have reviewed
> draft-mirsky-bfd-mpls-demand.  The chairs had originally issued a working
> group
> adoption call without having read the document.  Upon review, it was
> determined that the majority of the text in the draft mostly restated
> existing BFD Demand mode procedure.
>
> The chairs apologize for not having done sufficient vetting prior to
> starting the adoption process and causing the confusion that followed.
>
> The majority of the draft covers a re-statement of existing BFD procedure
> and obscures the potential request for normative protocol changes.  This
> response is split into two sections: The first portion covers procedure
> that
> is a restatement of RFC 5880 Demand behaviors with a few possible
> non-intended variances.  The second portion covers a potential change to
> BFD Demand behavior and may be reason to continue working group discussion.
>
> It's noted that a likely motivation for this draft comes from the following
> statement in RFC 5884, §6 "Session Establishment":
>
> #   A BFD session is bootstrapped using LSP Ping.  This specification
> #   describes procedures only for BFD asynchronous mode.  BFD demand
> mode
> #   is outside the scope of this specification.
>
> While "outside the scope", the procedures for exercising Demand mode are
> covered largely in detail in RFC 5880.
>
GIM>> I agree that the Demand mode is defined in RFC 5880.
draft-mirsky-bfd-mpls-demand is intended to discuss the applicability of
BFD in Demand over the MPLS LSP. The updates to the draft are to remove
unnecessary re-statements of RFC 5880 by providing references to,
primarily, Section 6.6 of RFC 5880.

>
> --
>
> In the following response, ':' blockquotes are from
> draft-mirsky-bfd-mpls-demand and '#' blockquotes are from the cited RFC.
>
> The text of the document and the matching procedures from RFC 5880 follow:
>
> : 3.  Use of the BFD Demand Mode
> :
> :[RFC5880] defines that the Demand mode MAY be:
> :
> :o  asymmetric, i.e. used in one direction of a BFD session;
> :
> :o  switched to and from without bringing BFD session to Down state
> :   through using a Poll Sequence.
>
> RFC 5880 §6 "Demand Mode" reads:
> #   Demand mode MAY be enabled or disabled at any time, independently
> in
> #   each direction, by setting or clearing the Demand (D) bit in the
> BFD
> #   Control packet, without affecting the BFD session state.  Note that
> #   the Demand bit MUST NOT be set unless both systems perceive the
> #   session to be Up (the local system thinks the session is Up, and
> the
> #   remote system last reported Up state in the State (Sta) field of
> the
> #   BFD Control packet).
> #
> #   When the transmitted value of the Demand (D) bit is to be changed,
> #   the transmitting system MUST initiate a Poll Sequence in
> conjunction
> #   with changing the bit in order to ensure that both systems are
> aware
> #   of the change.
>
> The poll sequence is defined in RFC 5880 §5 "The Poll Sequence":
> #   A Poll Sequence consists of a system sending periodic BFD Control
> #   packets with the Poll (P) bit set.  When the other system receives
> a
> #   Poll, it immediately transmits a BFD Control packet with the Final
> #   (F) bit set, independent of any periodic BFD Control packets it may
> #   be sending (see section 6.8.7).  When the system sending the Poll
> #   sequence receives a packet with Final, the Poll Sequence is
> #   terminated, and any subsequent BFD Control packets are sent with
> the
> #   Poll bit cleared.  A BFD Control packet MUST NOT have both the Poll
> #   (P) and Final (F) bits set.
>
> :For the case of BFD over MPLS LSP, ingress Label switching Edge
> :Router (LER) usually acts as Active BFD peer and egress LER acts as
> :Passive BFD peer.  The Active peer bootstraps the BFD ses

Re: BFD for vxlan Destination MAC field (was Re: draft-ietf-bfd-vxlan IESG status)

[Greg Mirsky]

Hi Donald,
many thanks for your clarification. Will wait for the IESG review of the
current version.

Regards,
Greg

On Mon, Aug 10, 2020 at 1:52 PM Donald Eastlake  wrote:

> Hi Greg,
>
> You shouldn't put a specific MAC address in the draft until it is
> assigned in the IANA registry.
>
> Requests that only appear in drafts don't take effect until the draft
> is approved but if assignment policy for the registry does not require
> IESG approval of a draft (for example, First Come First Served or
> Expert Review) you can send a request to IANA (see template in
> Appendix A.1 of RFC 7042) and then, after IANA has assigned a value,
> put it into a draft. Assignment of one or a small block of 48-bit MAC
> addresses is a slight variation on Expert Review (see Section 2.1.3 of
> RFC 7042).
>
> However, this document seems far enough along in the process that I'm
> not sure a separate request for the assignment (which would probably
> be referred to me and I would approve) would be worth it.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
> On Mon, Aug 10, 2020 at 3:38 PM Greg Mirsky  wrote:
> >
> > Hi Jeff,
> > to update the IANA considerations section by replacing TBD1 with the
> actual MAC address? I see two small allocation ranges for in the Unicast
> MAC addresses:
> > 00-52-02 to 00-52-12 Unassigned (small allocations)
> > 
> > 00-52-14 to 00-52-FF Unassigned (small allocations)
> >
> > Also, can we change the wording in the Reference column from "BFD over
> VXLAN" to "Control channel in NVO3"? That would be helpful to the work on
> OAM in Geneve.
> >
> > Regards,
> > Greg
> >
> > On Mon, Aug 10, 2020 at 12:14 PM Jeffrey Haas  wrote:
> >>
> >> Thank you, Donald.
> >>
> >> Greg, would you bump the draft with this assignment?
> >>
> >> -- Jeff
> >>
> >>
> >> > On Aug 10, 2020, at 1:08 PM, Donald Eastlake 
> wrote:
> >> >
> >> > Hi,
> >> >
> >> > My apologies for not responding earlier in this thread.
> >> >
> >> > IANA originally contacted me as a Designated Expert for MAC addresses
> >> > under the IANA OUI last year in connection with version -07. At that
> >> > time, I approved an assignment for this draft. I'm fine with any
> >> > reasonable usage description the WG comes up with for this MAC address
> >> > whether more or less generic. (Usage of a MAC address reserved for
> >> > documentation would not be appropriate)
> >> >
> >> > Thanks,
> >> > Donald
> >> > ===
> >> > Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >> > 2386 Panoramic Circle, Apopka, FL 32703 USA
> >> > d3e...@gmail.com
> >> >
> >> > On Thu, Jul 30, 2020 at 7:55 PM Greg Mirsky 
> wrote:
> >> >>
> >> >> Hi Jeff,
> >> >> do you think that the record in the Usage filed for the requested
> MAC address instead of "BFD over VXLAN" be more generic, e.g., "Active OAM
> over NVO3"?
> >> >> What do you think?
> >> >>
> >> >> Regards,
> >> >> Greg
> >> >>
> >> >> On Mon, Jul 20, 2020 at 2:26 PM Jeffrey Haas  wrote:
> >> >>>
> >> >>> On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeffrey Haas wrote:
> >> >>>>>> Proposed solution: A MAC value should be chosen that is well
> known and the
> >> >>>>>> text would become:
> >> >>>>>>
> >> >>>>>> "Destination MAC: A Management VNI, which does not have any
> tenants, will
> >> >>>>>> have no dedicated MAC address for decapsulated traffic.  The
> value
> >> >>>>>> X:X:X:X:X
> >> >>>>>> SHOULD be used in this field."
> >> >>>>>>
> >> >>>>>> SHOULD might need to be MUST.  Since a partial motivation for
> permitting
> >> >>>>>> the
> >> >>>>>> flexibility in the specification to NOT use the management VNI
> is desired=
> >> >>>>> ,
> >> >>>>>> MUST might be inappropriate.
> >> >>>>>>
> >> >>>>> GIM>> Accepted the suggest

Re: BFD for vxlan Destination MAC field (was Re: draft-ietf-bfd-vxlan IESG status)

[Greg Mirsky]

Hi Jeff,
to update the IANA considerations section by replacing TBD1 with the actual
MAC address? I see two small allocation ranges for in the Unicast MAC
addresses:
00-52-02 to 00-52-12 Unassigned (small allocations)
.
00-52-14 to 00-52-FF Unassigned (small allocations)

Also, can we change the wording in the Reference column from "BFD over
VXLAN" to "Control channel in NVO3"? That would be helpful to the work on
OAM in Geneve.

Regards,
Greg

On Mon, Aug 10, 2020 at 12:14 PM Jeffrey Haas  wrote:

> Thank you, Donald.
>
> Greg, would you bump the draft with this assignment?
>
> -- Jeff
>
>
> > On Aug 10, 2020, at 1:08 PM, Donald Eastlake  wrote:
> >
> > Hi,
> >
> > My apologies for not responding earlier in this thread.
> >
> > IANA originally contacted me as a Designated Expert for MAC addresses
> > under the IANA OUI last year in connection with version -07. At that
> > time, I approved an assignment for this draft. I'm fine with any
> > reasonable usage description the WG comes up with for this MAC address
> > whether more or less generic. (Usage of a MAC address reserved for
> > documentation would not be appropriate)
> >
> > Thanks,
> > Donald
> > ===
> > Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> > 2386 Panoramic Circle, Apopka, FL 32703 USA
> > d3e...@gmail.com
> >
> > On Thu, Jul 30, 2020 at 7:55 PM Greg Mirsky 
> wrote:
> >>
> >> Hi Jeff,
> >> do you think that the record in the Usage filed for the requested MAC
> address instead of "BFD over VXLAN" be more generic, e.g., "Active OAM over
> NVO3"?
> >> What do you think?
> >>
> >> Regards,
> >> Greg
> >>
> >> On Mon, Jul 20, 2020 at 2:26 PM Jeffrey Haas  wrote:
> >>>
> >>> On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeffrey Haas wrote:
> >>>>>> Proposed solution: A MAC value should be chosen that is well known
> and the
> >>>>>> text would become:
> >>>>>>
> >>>>>> "Destination MAC: A Management VNI, which does not have any
> tenants, will
> >>>>>> have no dedicated MAC address for decapsulated traffic.  The value
> >>>>>> X:X:X:X:X
> >>>>>> SHOULD be used in this field."
> >>>>>>
> >>>>>> SHOULD might need to be MUST.  Since a partial motivation for
> permitting
> >>>>>> the
> >>>>>> flexibility in the specification to NOT use the management VNI is
> desired=
> >>>>> ,
> >>>>>> MUST might be inappropriate.
> >>>>>>
> >>>>> GIM>> Accepted the suggested text. I agree that the flexibility to
> not use
> >>>>> the Management VNI is permitted in the specification and thus SHOULD
> in the
> >>>>> text is consistent with that scenario. How would we pick the MAC
> address?
> >>>>
> >>>> I am out of my area of expertise and I was hoping someone in the IESG
> can offer a fix. :-)  I am copying Donald Eastlake since he's the
> designated expert for the IANA MAC address block.
> >>>>
> >>>> Donald, review of the thread may be useful, but tersely the need is
> to have a well known MAC address that can be placed in this vxlan PDU that
> is literally a placeholder of "not to be used for forwarding".  The packet
> arrives at the endpoint and, if not immediately accepted, would be dropped.
> >>>>
> >>>> If there is no well known MAC that could be used for such a behavior,
> perhaps an address from the IANA block may be used?
> >>>>
> >>>> While I suspect the IANA mac documentation range could be used, IANA
> may not appreciate that.
> >>>
> >>> Donald is not responding to emails.  Considering I've been similarly
> bad
> >>> about responding, that's forgivable.  However, in the interest of
> advancing
> >>> the document, I'd like to make a proposal.
> >>>
> >>>
> https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml
> >>>
> >>> Proposed text:
> >>>
> >>> : Destination MAC: A Management VNI, which does not have any tenants,
> will
> >>> : have no dedicated MAC address for decapsulated traffic.  The value
> >>> : [TBD1] SHOULD be used in this field.
> >>> :
> >>> : IANA Considerations:
> >>> :
> >>> : IANA is requested to assign a single MAC address to the value TBD1
> from the
> >>> : "IANA Unicast 48-bit MAC Address" registry from the "Unassigned
> (small
> >>> : allocations)" block.  The Usage field will be "BFD for vxlan" with a
> >>> : Reference field of this document.
> >>>
> >>>
> >>>
> >>> -- Jeff
>
>

Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)

[Greg Mirsky]

Dear Authors,
thank you for the well-written document. I have several questions and
comments that are listed below:

   - An Introduction, states that

   it is not clear whether the devices
   using echo function need to support the full BFD procotol, including
   maintaining the state machine of BFD session as described in
   [RFC5880] and [RFC5881].

I think that Section 6.8.9 in RFC 5880 explicitly states:
   BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
   Up.  BFD Echo packets MUST NOT be transmitted unless the last BFD
   Control packet received from the remote system contains a nonzero
   value in Required Min Echo RX Interval.

Could you point to a statement in RFC 5880 or RFC 5881 that updates the
requirements above?


   - Based on my understanding of the BFD Echo function definition in RFC
   5880, the use case described in section 6.2.2 TR-146 is not based on the
   standard use of the BFD Echo function.
   - Section 2 describes the behavior of a BFD system in the Unaffiliated
   Echo mode. Would there be a BFD session created? If yes, which BFD state
   variables must be set?
   - Regarding the encapsulation of the BFD Echo in unaffiliated mode
   section 2 states

   device will send the BFD echo packets with the IP
   address destined for itself

Which address will be used in IPv4 and IPv6? Which address will be used as
the source IP address? And as we are discussing the IP encapsulation, which
value be set in the TTL/HL field?


   - in the second paragraph, Section 2 stated that

   the device that does not support
   BFD protocol immediately loops back the packet by normal IP
   forwarding, implementing quick link failure detection
It appears that the quick link failure detection is on the side of the
system that does not support the BFD protocol. Is that right?


   - Further, you describe that system A (Fig.1) "rapidly detect a
   connectivity loss to device B". How in the unaffiliated BFD Echo mode is
   controlled the rate of transition for the BFD Echo packets? RFC 5880 allows
   the remote system to use Required Min Echo RX Interval for that. Which
   mechanism would you recommend in the unaffiliated BFD Echo mode?
   - Additionally, how does system A detects a failure? RFC 5880 in Section
   6.8.5 gives a hint:

   a sufficient number of Echo
   packets have not arrived as they should, the session has gone down
but the mechanism to determine when an Echo packet should arrive and by
that when it is lost, as I understand the text in the section, is outside
the scope of RFC 5880. Do you have a recommendation on how system A
determines that a packet is lost?


   - nits:

s/BFD procotol/BFD protocol/3
s/capablity/capability/

Regards,
Greg


On Tue, Aug 4, 2020 at 6:04 AM Jeffrey Haas  wrote:

> Working Group,
>
> https://datatracker.ietf.org/doc/draft-cw-bfd-unaffiliated-echo/
>
> At the virtual IETF 108, Unaffiliated BFD Echo Function was presented.
> This
> is a followup of a presentation given at IETF 106.
>
> The authors have indicated they would like to have this work adopted by the
> BFD WG.  This begins the adoption call ending August 16.  Please respond to
> the mailing list with your thoughts on this adoption.
>
> It should be noted that this document overlaps work in the Broadband Forum
> (BBF) document TR-146.  As noted in the presentation, the BBF document
> lacks
> some clarity and also doesn't discuss interactions with BFD
> implementations.
> This draft has good clarifications with regard to implementations of this
> mechanism when the a BFD Echo-capable implementation is used.
>
> This raises two points to consider as part of adoption:
> - This document with its current goals would Update RFC 5880.
> - The status of this document would need to be Proposed Standard.
>
> -- Jeff
>
>

Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

[Greg Mirsky]

Dear Authors, et al.,
thank you for this well-written document. The mechanism described in the
draft is, in my opinion, useful and will save considerable efforts of the
operator. I have several questions and comments listed below:

   - Would the introduction of Unsolicited mode make this draft updating
   RFC 5881?
   - I didn't find any new values of BFD parameters that distinguish an
   unsolicited BFD session from the "classic single-hop" session. Do you think
   such a distinction could be useful to an operator?
   - In Section 2 stated

   On the passive side, the "unsolicited BFD" SHOULD be configured
   explicitly on an interface.

Does that imply that it MAY be configured node-wide? I think it would be
helpful to explicitly list the alternative option.


   - The fourth paragraph in Section 2 explains the handling of the first
   BFD control packet with Your Discriminator == 0, i.e., "it does not find an
   existing session with the same source address". What happens if the
   matching BFD session has been found?
   - A BFD session then created "based on the source address and
   destination address". Does that mean that there will be only one session
   with the same source address despite different destination addresses
   listed? If that is the case, could the BFD session be associated only with
   the source IP address of the received BFD control packet?
   - Between creating the BFD session (above) and

   It would
   then start sending the BFD Control packets and perform necessary
   procedure for bringing up, maintaining and tearing down the BFD
   session.

the local BFD system assigns My Discriminator to the session. Though it is
standard (RFC 5880) step, it might be useful to mention it.


   - Does "an established BFD session goes down" mean the state is Down and
   only Down or it also includes AdminDown state?
   - Furter stated

   the
   passive side would stop sending BFD Control packets and delete the
   BFD session created until the BFD Control packets is initiated by the
   active side again.

Probably some normative language be helpful to replace "would". And is the
stop applied immediately or after some grace period? The same question
about the deletion of BFD parameters and the FSM (probably this is left to
the implementation).


   - I'd admit got confused by the last paragraph in Section 2:

  The "Passive role" may change to the "Active role" when a local
   client registers for the same BFD session ...

Is it normative MAY? Does that mean that the unsolicited BFD cannot be in
passive role if it has a local client registered? But what I wonder is how
these transitions affect the operation. What happens if both BFD systems
are passive after changes in the clients registered? Or both are active?


   - Section 5.1 appears to only RECOMMEND setting TTL to 255 while RFC
   5881 says that TTL MUST be set to 255. What could be the case for not
   setting TTL to 255?
   - Nits:
  - s/"Discriminator"/"My Discriminator"
  - s/does not initiates/does not initiate/
  - s/"remote-discriminator"/"Your Discriminator"/

Regards,
Greg

On Tue, Aug 4, 2020 at 6:10 AM Jeffrey Haas  wrote:

> Working Group,
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
>
> With apologies to the authors of BFD unsolicited, this document is past due
> for Working Group Last Call.  The primary holdup on the document had been
> last minute interaction with the RFC Editor with regard to its impact on
> the
> BFD Yang model.  That work had completed some time ago.  (The Yang model,
> however, is still lingering in MISREF state.)
>
> This begins a last call period ending on 16 August.
>
> Please send your comments to the mailing list whether you think this work
> is
> ready to advance to the IESG or not.
>
> -- Jeff & Reshad
>
>

Re: IETF 108 candidate minutes

[Greg Mirsky]

Hi Jeff,
I have nothing to change/add in the candidate minutes. Thank you!

Regards,
Greg

On Thu, Jul 30, 2020 at 9:12 AM Jeffrey Haas  wrote:

> https://datatracker.ietf.org/doc/minutes-108-bfd/
>
> The following are the candidate minutes for the IETF 108 BFD session.
> Please provide feedback to the mailing list.
>
> -- Jeff and Reshad
>
> # BFD IETF 108 - July 30, 2020 - 13:00-13:50 UTC
> Chairs: Jeffrey Haas, Reshad Rahman
>
> # Agenda:
>
> ## Chairs update:
>   10 mins - Jeff Haas & Reshad Rahman
>
> **Greg Mirsky** asks about bfd 2.0.
> **Jeff Haas** answers we're likely rechartering to tighten our charter to
> the core continuity check (CC) case.  We're likely to try to spin off the
> other inter-system protocol machinery for other state to another WG or BoF
> depending on interest.  IESG was luke-warm about this option, at best.  WG
> would happily help in such a spin-off.
>
>
> 
>
> ## BFD for VxLAN:
>   5 minutes - Greg Mirsky
>
> **Matthew Bocci** asks about BFD in Geneve.  Question about testing to
> individual VNIs.  Also questions about issues related to ECMP.
> **Greg Mirsky** notes that we're focusing on management VNI case.
> **Reshad Rahman** asks about MAC assignments for non-management cases.
> **Jeff Haas** WG had discussed the more general case for testing to VNI.
> Decided to leave it out of scope based on IESG discussions on security
> issues.  However, the packet format is likely general enough for the test
> to the VNI case, but is out of scope for our document. These issues also
> applies to BFD for Geneve
>
> Greg and Xiao are working on Geneve, so the Geneve document will pick up
> the relevant changes from WGLC discussion for vxlan document.
>
> 
>
>
> ## BFD padding alteration (draft-xiao-bfd-padding-alteration):
>   10 minutes - Xiao Min
>
> **Santosh Pallagati**: How does poll and final interact with timers.  How
> long do we do poll/final sequence?
> **Xiao Min**: Should be very quick.
> **Santosh Pallagati**: This is just for negotiating large packets on.
> **Reshad Rahman**: Followup - scheduled packet, large packet sent in next
> interval, verify that you get f-bit back.  Some implementations have
> policers; 1 packet ever X ms, we may see more.  We may see drops of BFD
> packets?  Having reviewed BFD instability draft, this may show up as
> instability.
> **Xiao Min**: Extra padding poll can be sent more than once.
> **Jeff Haas**: Poll continues until the the poller decides it is done.
> **Greg Mirsky**: Poll is one packet per second?
> **Jeff Haas**: Poll actually for the rate that the session is currently
> running. pps is limiting factor for most bfd implementations.  bfd large
> changes bps as well.  That may interact poorly with policers?
> **Reshad Rahman**: Have you considered instead of on top of small packet
> doing poll on just large packet?
> **Xiao Min**: Intent is to keep bfd running when trying to toggle mode.
> **Reshad Rahman**: You could replace a regular packet with a padded
> packet. Concern that it could cause a BFD session to fail?
> **Jeff Haas** (speaking as BFD large packet author): Would you (Xiao)
> consider merging into bfd large?
> **Xiao Min**: Yes.
> **Jeff Haas**: Need to discuss requirements for operators that need the
> large packet feature always on vs. negotiated.
>
> 
>
> ## BFD unaffiliated echo (draft-cw-bfd-unaffiliated-echo):
>   10 minutes  - Weiqiang Cheng
>
> **Weiqiang Cheng**: Procedural text in BBF document is unclear.
> **Rakesh Gandhi**: We are doing similar things with TWAMP for
> responder/reflector.  Does this means we'll update 5880?
> **Weiqiang Cheng**: Is aware of TWAMP.  Don't have to change BFD solution.
> Don't need to change remote implementation.  It's just configuration.
> **Jeff Haas**: This is different from BBF in that we're talking about a
> BFD implementation on the receiver. This would update 5880 if so.
> **Greg Mirsky**: Clarify on multiplexing on sessions for sender/receiver.
> System assigns discriminator to the session - and it goes into the packet.
> **Jaganbabu Rajamanickam** (Cisco): Is this same as S-BFD?
> **Greg Mirsky**: Reflector (learned via IGP, etc.) has an active role in
> BFD.  This proposal uses transport layer looping.
> **Jaganbabu Rajamanickam**: Could be loopback in data path.
> **Greg Mirsky**: And therefore it's echo mode.
> **Xiao Min**: The BFD echo is actually a control packet.
> **Greg Mirsky**: If you're running multiple sessions, you'll want to demux
> them.  The contents of the packet matters then.
>
> **Jeff Haas**: Hum for adoption. Hum was panissimo - will take this
> further to the mailing list.
>
> -
>
> ## Actions for after IETF:
> - Sub

Re: BFD for vxlan Destination MAC field (was Re: draft-ietf-bfd-vxlan IESG status)

[Greg Mirsky]

Hi Jeff,
do you think that the record in the Usage filed for the requested MAC
address instead of "BFD over VXLAN" be more generic, e.g., "Active OAM over
NVO3"?
What do you think?

Regards,
Greg

On Mon, Jul 20, 2020 at 2:26 PM Jeffrey Haas  wrote:

> On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeffrey Haas wrote:
> > >> Proposed solution: A MAC value should be chosen that is well known
> and the
> > >> text would become:
> > >>
> > >> "Destination MAC: A Management VNI, which does not have any tenants,
> will
> > >> have no dedicated MAC address for decapsulated traffic.  The value
> > >> X:X:X:X:X
> > >> SHOULD be used in this field."
> > >>
> > >> SHOULD might need to be MUST.  Since a partial motivation for
> permitting
> > >> the
> > >> flexibility in the specification to NOT use the management VNI is
> desired=
> > > ,
> > >> MUST might be inappropriate.
> > >>
> > > GIM>> Accepted the suggested text. I agree that the flexibility to not
> use
> > > the Management VNI is permitted in the specification and thus SHOULD
> in the
> > > text is consistent with that scenario. How would we pick the MAC
> address?
> >
> > I am out of my area of expertise and I was hoping someone in the IESG
> can offer a fix. :-)  I am copying Donald Eastlake since he's the
> designated expert for the IANA MAC address block.
> >
> > Donald, review of the thread may be useful, but tersely the need is to
> have a well known MAC address that can be placed in this vxlan PDU that is
> literally a placeholder of "not to be used for forwarding".  The packet
> arrives at the endpoint and, if not immediately accepted, would be dropped.
> >
> > If there is no well known MAC that could be used for such a behavior,
> perhaps an address from the IANA block may be used?
> >
> > While I suspect the IANA mac documentation range could be used, IANA may
> not appreciate that.
>
> Donald is not responding to emails.  Considering I've been similarly bad
> about responding, that's forgivable.  However, in the interest of advancing
> the document, I'd like to make a proposal.
>
> https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml
>
> Proposed text:
>
> : Destination MAC: A Management VNI, which does not have any tenants, will
> : have no dedicated MAC address for decapsulated traffic.  The value
> : [TBD1] SHOULD be used in this field.
> :
> : IANA Considerations:
> :
> : IANA is requested to assign a single MAC address to the value TBD1 from
> the
> : "IANA Unicast 48-bit MAC Address" registry from the "Unassigned (small
> : allocations)" block.  The Usage field will be "BFD for vxlan" with a
> : Reference field of this document.
>
>
>
> -- Jeff
>

Fwd: New Version Notification for draft-ietf-bfd-vxlan-14.txt

[Greg Mirsky]

Dear All,
this version includes updates that address comments received over the
course of the IESG review of the draft.

Regards,
Greg

-- Forwarded message -
From: 
Date: Tue, Jul 28, 2020 at 11:26 AM
Subject: New Version Notification for draft-ietf-bfd-vxlan-14.txt
To: Vengada Prasad Govindan , Greg Mirsky <
gregimir...@gmail.com>, Mallik Mudigonda , Sudarsan
Paragiri , Santosh Pallagatti <
santosh.pallaga...@gmail.com>



A new version of I-D, draft-ietf-bfd-vxlan-14.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-ietf-bfd-vxlan
Revision:   14
Title:  BFD for VXLAN
Document date:  2020-07-28
Group:  bfd
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-14.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Htmlized:   https://tools.ietf.org/html/draft-ietf-bfd-vxlan-14
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-14

Abstract:
   This document describes the use of the Bidirectional Forwarding
   Detection (BFD) protocol in point-to-point Virtual eXtensible Local
   Area Network (VXLAN) tunnels used to form an overlay network.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Re: BFD for vxlan Destination MAC field (was Re: draft-ietf-bfd-vxlan IESG status)

[Greg Mirsky]

9.  Security Considerations

   Security issues discussed in [RFC5880], [RFC5881], and [RFC7348]
   apply to this document.

   This document recommends using an address from the Internal host
   loopback addresses 127/8 range for IPv4 or an IP4-mapped IPv4
   loopback address from :::127.0.0.0/104 range for IPv6 as the
   destination IP address in the inner IP header.  Using such an address
   prevents the forwarding of the encapsulated BFD control message by a
   transient node in case the VXLAN tunnel is broken as according to
   [RFC1812]:

  A router SHOULD NOT forward, except over a loopback interface, any
  packet that has a destination address on network 127.  A router
  MAY have a switch that allows the network manager to disable these
  checks.  If such a switch is provided, it MUST default to
  performing the checks.

   If the implementation supports establishing multiple BFD sessions
   between the same pair of VTEPs, there SHOULD be a mechanism to
   control the maximum number of such sessions that can be active at the
   same time.

10.  Contributors


   Reshad Rahman
   rrah...@cisco.com
   Cisco


11.  Acknowledgments

   Authors would like to thank Jeff Haas of Juniper Networks for his
   reviews and feedback on this material.

   Authors would also like to thank Nobo Akiya, Marc Binderberger,
   Shahram Davari, Donald E.  Eastlake 3rd, Anoop Ghanwani, Dinesh Dutt,
   Joel Halpern, and Carlos Pignataro for the extensive reviews and the
   most detailed and constructive comments.

12.  References








Pallagatti, et al.  Expires January 21, 2021[Page 9]

Internet-DraftBFD for VXLANJuly 2020


12.1.  Normative References

   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
  RFC 1812, DOI 10.17487/RFC1812, June 1995,
  <https://www.rfc-editor.org/info/rfc1812>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  Requirement Levels", BCP 14, RFC 2119,
  DOI 10.17487/RFC2119, March 1997,
  <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
  (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
  <https://www.rfc-editor.org/info/rfc5880>.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
  (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
  DOI 10.17487/RFC5881, June 2010,
  <https://www.rfc-editor.org/info/rfc5881>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
  L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
  eXtensible Local Area Network (VXLAN): A Framework for
  Overlaying Virtualized Layer 2 Networks over Layer 3
  Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
  <https://www.rfc-editor.org/info/rfc7348>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
  2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
  May 2017, <https://www.rfc-editor.org/info/rfc8174>.

12.2.  Informational References

   [RFC8293]  Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R.
  Krishnan, "A Framework for Multicast in Network
  Virtualization over Layer 3", RFC 8293,
  DOI 10.17487/RFC8293, January 2018,
  <https://www.rfc-editor.org/info/rfc8293>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
  Uttaro, J., and W. Henderickx, "A Network Virtualization
  Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
  DOI 10.17487/RFC8365, March 2018,
  <https://www.rfc-editor.org/info/rfc8365>.







Pallagatti, et al.  Expires January 21, 2021   [Page 10]

Internet-DraftBFD for VXLANJuly 2020


Authors' Addresses

   Santosh Pallagatti (editor)
   VMware

   Email: santosh.pallaga...@gmail.com


   Sudarsan Paragiri
   Individual Contributor

   Email: sudarsan@gmail.com


   Vengada Prasad Govindan
   Cisco

   Email: vengg...@cisco.com


   Mallik Mudigonda
   Cisco

   Email: mmudi...@cisco.com


   Greg Mirsky
   ZTE Corp.

   Email: gregimir...@gmail.com





















Pallagatti, et al.  Expires January 21, 2021   [Page 11]
<<< text/html; charset="UTF-8";  name="Diff_ draft-ietf-bfd-vxlan-13.txt - draft-ietf-bfd-vxlan-14.txt.html": Unrecognized >>>

Re: BFD for vxlan Destination MAC field (was Re: draft-ietf-bfd-vxlan IESG status)

[Greg Mirsky]

Hi Jeff,
thank you for the proposed text. I'll include it in the working version
with capitalizing VXLAN in the IANA section).

Regards,
Greg

On Mon, Jul 20, 2020 at 2:26 PM Jeffrey Haas  wrote:

> On Wed, Jun 17, 2020 at 03:52:14PM -0400, Jeffrey Haas wrote:
> > >> Proposed solution: A MAC value should be chosen that is well known
> and the
> > >> text would become:
> > >>
> > >> "Destination MAC: A Management VNI, which does not have any tenants,
> will
> > >> have no dedicated MAC address for decapsulated traffic.  The value
> > >> X:X:X:X:X
> > >> SHOULD be used in this field."
> > >>
> > >> SHOULD might need to be MUST.  Since a partial motivation for
> permitting
> > >> the
> > >> flexibility in the specification to NOT use the management VNI is
> desired=
> > > ,
> > >> MUST might be inappropriate.
> > >>
> > > GIM>> Accepted the suggested text. I agree that the flexibility to not
> use
> > > the Management VNI is permitted in the specification and thus SHOULD
> in the
> > > text is consistent with that scenario. How would we pick the MAC
> address?
> >
> > I am out of my area of expertise and I was hoping someone in the IESG
> can offer a fix. :-)  I am copying Donald Eastlake since he's the
> designated expert for the IANA MAC address block.
> >
> > Donald, review of the thread may be useful, but tersely the need is to
> have a well known MAC address that can be placed in this vxlan PDU that is
> literally a placeholder of "not to be used for forwarding".  The packet
> arrives at the endpoint and, if not immediately accepted, would be dropped.
> >
> > If there is no well known MAC that could be used for such a behavior,
> perhaps an address from the IANA block may be used?
> >
> > While I suspect the IANA mac documentation range could be used, IANA may
> not appreciate that.
>
> Donald is not responding to emails.  Considering I've been similarly bad
> about responding, that's forgivable.  However, in the interest of advancing
> the document, I'd like to make a proposal.
>
> https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml
>
> Proposed text:
>
> : Destination MAC: A Management VNI, which does not have any tenants, will
> : have no dedicated MAC address for decapsulated traffic.  The value
> : [TBD1] SHOULD be used in this field.
> :
> : IANA Considerations:
> :
> : IANA is requested to assign a single MAC address to the value TBD1 from
> the
> : "IANA Unicast 48-bit MAC Address" registry from the "Unassigned (small
> : allocations)" block.  The Usage field will be "BFD for vxlan" with a
> : Reference field of this document.
>
>
>
> -- Jeff
>

Fwd: I-D Action: draft-ietf-bfd-vxlan-13.txt

[Greg Mirsky]

Dear All,
updates in this version address comments received during the IESG review.
Your questions, comments, and suggestions are always welcome and greatly
appreciated.

Regards,
Greg

-- Forwarded message -
From: 
Date: Mon, Jul 6, 2020 at 8:24 AM
Subject: I-D Action: draft-ietf-bfd-vxlan-13.txt
To: 
Cc: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Bidirectional Forwarding Detection WG of
the IETF.

Title   : BFD for VXLAN
Authors : Santosh Pallagatti
  Sudarsan Paragiri
  Vengada Prasad Govindan
  Mallik Mudigonda
  Greg Mirsky
Filename: draft-ietf-bfd-vxlan-13.txt
Pages   : 11
Date: 2020-07-06

Abstract:
   This document describes the use of the Bidirectional Forwarding
   Detection (BFD) protocol in point-to-point Virtual eXtensible Local
   Area Network (VXLAN) tunnels used to form an overlay network.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bfd-vxlan-13
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Re: draft-ietf-bfd-vxlan IESG status

[Greg Mirsky]

Hi Jeff,
thank you for the additional details. I've top-posted the discussion thread
regarding a firewall, VTEP, and drop rules. I recall that the relevant text
was suggested based on deployment experience. I will try to update it along
the suggested lines:

I think the rewording would include some phrasing like "RECOMMENDED that
the only firewall exception to allow incoming traffic with destination
address from the loopback range is when [...]", and of course, mention
the need to have BFD configured.

Would the following update make it clearer:
OLD TEXT:
  There could be a
   firewall configured on VTEP to block loopback addresses if set as the
   destination IP in the inner IP header.  It is RECOMMENDED to allow
   addresses from the loopback range through a firewall only if they are
   used as the destination IP addresses in the inner IP header and the
   destination UDP port is set to 3784 [RFC5881].
NEW TEXT:
  If a firewall
   configured on VTEP packets with their destination IP addresses in the
   inner IP header set to one of the loopback addresses listed above will be
   dropped.  To allow BFD work as described in this specification, it is
   RECOMMENDED to use an exception rule to allow addresses from the
   loopback range through a firewall only if they are used as the
   destination IP addresses in the inner IP header and the destination
   UDP port is set to 3784 [RFC5881].
Also, would splitting this text into a paragraph help to keep clear?

If the proposed update is not better than the current text, let's remove it
altogether.

Regards,
Greg

On Wed, Jun 17, 2020 at 12:52 PM Jeffrey Haas  wrote:

> Greg,
>
>
> > On Jun 16, 2020, at 9:05 PM, Greg Mirsky  wrote:
> > thank you for providing continued support and guidance. Please find my
> > notes in-lined under tag GIM>>. Attached are the new working version and
> > its diff to -12. There are two remaining Open Issues - 7 and 9. I much
> > appreciate your considerations and suggestions.
>
> [...]
>
> >>> Open Issue 7: ":::7F00:0/104 IPv6 range" (COMMENT via Benjamin K.)
> >>>
> >>> Proposed Action: I believe this issue's fate is similarly tied to Open
> >> Issue 3.
> >>> If the proposal is limited solely to management VNI, this text is not
> >>> relevant and may be deleted.
> >>
> >> This action is still pending.
> >>
> > GIM>> There are two references to this IPv6 range. I think that the
> > document should give a recommendation on what address to use as the
> > destination IP address. As we've discussed with  Adam Roach, only :::
> > 127.0.0.1/128 has host loopback meaning in IPv6. I propose to change
> > throughout the text from "one of the addresses from IPv6 range" to
> ":::
> > 127.0.0.1/128 for IPv6".
>
> Sorry, the issue is from the IESG ballot at
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ballot/:
>
> >0:0:0:0:0::7F00:0/104 range for IPv6).  There could be a firewall
> >configured on VTEP to block loopback addresses if set as the
> >destination IP in the inner IP header.  It is RECOMMENDED to allow
> >addresses from the loopback range through a firewall only if it is
> >used as the destination IP address in the inner IP header, and the
> >destination UDP port is set to 3784 [RFC5881].
> >
> > I think we should reword this to make it clear that the default behavior
> > is still "block all incoming traffic with loopback destination" and that
> > the exception is tightly scoped to the encapsulated VXLAN traffic
> > discussed in this document and the specific destination port *and when
> > BFD has been configured for the VTEP*.
>
> So, the question is what should be done about packet drop or firewalls?
>
> My opinion is one possible action for this is to drop the text.  For this
> feature to work, traffic will be arriving with packets destined to these
> well known ranges.  If you want the feature to work, they must be permitted
> to come through.  Rather than mention "if you have it", the related actions
> are implied by things necessary to implement it.
>
>
>
> >
> >>>
> >>> Open Issue 9: "Destination MAC: This MUST NOT be of one of tenant's MAC
> >>> addresses." (COMMENT via Benjamin K.)
> >>>
> >>> Proposed Action: I believe this issue's fate is similarly tied to Open
> >> Issue 3.
> >>> If the proposal is limited solely to management VNI, this text is not
> >>> relevant and may be deleted.
> >>
> >> In -12, we now have the following text:
> >> "Destination MAC: s

Re: draft-ietf-bfd-vxlan IESG status

[Greg Mirsky]

Hi Alvaro,
thank you for the clarification. I will update the reference by using the
text you've suggested.

Regards,
Greg

On Wed, Jun 17, 2020 at 12:59 PM Alvaro Retana 
wrote:

> Greg:
>
> Rfc5881 already specifies using GTSM…this document depends on rfc5881, so
> the reference should be the BFD behavior.
>
> Alvaro.
>
> On June 17, 2020 at 2:40:52 PM, Greg Mirsky (gregimir...@gmail.com) wrote:
>
> Hi Alvaro,
> thank you for the suggestion. I have a question. The current version
> references RFC 5082:
>  TTL or Hop Limit: MUST be set to 255 in accordance with the
>  Generalized TTL Security Mechanism [RFC5082].
> RFC 5881, while stating the requirement for the TTL or Hop Limit value,
> refers to RFC 5082 as the text that explains the benefits of using 255 on a
> single IP link. In both documents, RFC 5082 is listed as a normative
> reference. Would using RFC 5082 be acceptable or you suggest changing it to
> RFC 5881?
>
> Regards,
> Greg
>
> On Wed, Jun 17, 2020 at 9:37 AM Alvaro Retana 
> wrote:
>
>> On June 16, 2020 at 5:01:57 PM, Jeffrey Haas wrote:
>>
>>
>> Hi!
>>
>>
>> ...
>> > > Open Issue 1: Discussion on TTL/Hop Limit = 1
>> > >
>> > > Proposed Action: Greg has proposed text he will send to the working
>> group
>> > > suggesting GTSM procedures be utilized. The expected concern is how
>> this
>> > > impacts existing implementations.
>> >
>> > This issue is resolved.
>>
>> As I had mentioned before [1], the use of 255 should reference
>> rfc5881: the requirement is one from the base spec, not a new one
>> here.
>>
>> Suggestion>
>>
>>TTL or Hop Limit: MUST be set to 255 in accordance with [RFC5881].
>>
>>
>> I am clearing my DISCUSS.
>>
>>
>> Thanks!!
>>
>> Alvaro.
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/aiJW3KjYevY83wEDwVj488FSVl0/
>>
>

Re: draft-ietf-bfd-vxlan IESG status

[Greg Mirsky]

AY be set to VTEP's
 IP address.

 Source IP: IP address of the originating VTEP.

 TTL or Hop Limit: MUST be set to 255 in accordance with the
 Generalized TTL Security Mechanism [RFC5082].

  The fields of the UDP header and the BFD Control packet are
  encoded as specified in [RFC5881].

6.  Reception of BFD Packet from VXLAN Tunnel

   Once a packet is received, the VTEP MUST validate the packet.  If the
   packet is received on the management VNI and is identified as BFD
   control packet addressed to the VTEP, and then the packet can be
   processed further.  Processing of BFD control packets received on
   non-management VNI is outside the scope of this specification.

   The received packet's inner IP payload is then validated according to
   Sections 4 and 5 in [RFC5881].

7.  Echo BFD

   Support for echo BFD is outside the scope of this document.

8.  IANA Considerations

   This specification has no IANA action requested.  This section may be
   deleted before the publication.

9.  Security Considerations

   Security issues discussed in [RFC5880], [RFC5881], and [RFC7348]
   apply to this document.





Pallagatti, et al.  Expires December 18, 2020   [Page 8]

Internet-DraftBFD for VXLANJune 2020


   This document recommends using an address from the Internal host
   loopback addresses 127/8 range for IPv4 or an IP4-mapped IPv4
   loopback address from :::127.0.0.0/104 range for IPv6 as the
   destination IP address in the inner IP header.  Using such an address
   prevents the forwarding of the encapsulated BFD control message by a
   transient node in case the VXLAN tunnel is broken as according to
   [RFC1812]:

  A router SHOULD NOT forward, except over a loopback interface, any
  packet that has a destination address on network 127.  A router
  MAY have a switch that allows the network manager to disable these
  checks.  If such a switch is provided, it MUST default to
  performing the checks.

   If the implementation supports establishing multiple BFD sessions
   between the same pair of VTEPs, there SHOULD be a mechanism to
   control the maximum number of such sessions that can be active at the
   same time.

10.  Contributors


   Reshad Rahman
   rrah...@cisco.com
   Cisco


11.  Acknowledgments

   Authors would like to thank Jeff Haas of Juniper Networks for his
   reviews and feedback on this material.

   Authors would also like to thank Nobo Akiya, Marc Binderberger,
   Shahram Davari, Donald E.  Eastlake 3rd, Anoop Ghanwani, Dinesh Dutt,
   Joel Halpern, and Carlos Pignataro for the extensive reviews and the
   most detailed and constructive comments.

12.  References

12.1.  Normative References

   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
  RFC 1812, DOI 10.17487/RFC1812, June 1995,
  <https://www.rfc-editor.org/info/rfc1812>.







Pallagatti, et al.  Expires December 18, 2020   [Page 9]

Internet-DraftBFD for VXLANJune 2020


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  Requirement Levels", BCP 14, RFC 2119,
  DOI 10.17487/RFC2119, March 1997,
  <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
  Pignataro, "The Generalized TTL Security Mechanism
  (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
  <https://www.rfc-editor.org/info/rfc5082>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
  (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
  <https://www.rfc-editor.org/info/rfc5880>.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
  (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
  DOI 10.17487/RFC5881, June 2010,
  <https://www.rfc-editor.org/info/rfc5881>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
  L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
  eXtensible Local Area Network (VXLAN): A Framework for
  Overlaying Virtualized Layer 2 Networks over Layer 3
  Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
  <https://www.rfc-editor.org/info/rfc7348>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
  2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
  May 2017, <https://www.rfc-editor.org/info/rfc8174>.

12.2.  Informational References

   [RFC8293]  Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R.
  Krishnan, "A Framework for Multicast in Network
  Virtualization over Layer 3", RFC 8293,
  DOI 10.17487/RFC8293, January 2018,
  <https://www.rfc-editor.org/info/rfc8293>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
  Uttaro, J., and W. Henderickx, "A Network Virtualization
  Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
  DOI 10.17487/RFC8365, March 2018,
  <https://www.rfc-editor.org/info/rfc8365>.








Pallagatti, et al.  Expires December 18, 2020  [Page 10]

Internet-DraftBFD for VXLANJune 2020


Authors' Addresses

   Santosh Pallagatti (editor)
   VMware

   Email: santosh.pallaga...@gmail.com


   Sudarsan Paragiri
   Individual Contributor

   Email: sudarsan@gmail.com


   Vengada Prasad Govindan
   Cisco

   Email: vengg...@cisco.com


   Mallik Mudigonda
   Cisco

   Email: mmudi...@cisco.com


   Greg Mirsky
   ZTE Corp.

   Email: gregimir...@gmail.com





















Pallagatti, et al.  Expires December 18, 2020  [Page 11]
<<< text/html; charset="UTF-8";  name="Diff_ draft-ietf-bfd-vxlan-12.txt - draft-ietf-bfd-vxlan-13.txt.html": Unrecognized >>>

Re: New Version Notification for draft-ietf-bfd-vxlan-12.txt

[Greg Mirsky]

Dear Carlos,
thank you for the suggested update. I agree that it improves the text. Will
include in the working version of the draft for now.

Regards,
Greg

On Mon, May 25, 2020 at 6:15 PM Carlos Pignataro (cpignata) <
cpign...@cisco.com> wrote:

> Thank you, Greg.
>
> I only looked at the update to the last paragraph of Section 6.
>
> Reading through the last paragraph of Section 6, the text is not fully
> clear. There are a few nits, including a missing article, /as long as/as
> well as/, /is/are/, and missing preposition which results in an incorrect
> pointer.
>
> I’d suggest, for your consideration:
>
> OLD:
>Validation of TTL / Hop Limit of the inner IP packet, as long as the
>related considerations for BFD control packet demultiplexing and
>authentication, is performed as described in Section 5 [RFC5881].
>
>
> OLD:
>Validation of the TTL / Hop Limit field of the inner IP packet, as
>well as the related considerations for BFD control packet
>demultiplexing and authentication, are performed as described in
>Section 5 of [RFC5881].
>
> Best,
>
> Carlos.
>
> 2020/05/25 午後6:11、Greg Mirsky のメール:
>
> Dear Carlos,
> thank you for your comments and suggestions. I hope that the updated
> version of the draft addresses your comments. Please let me know whether
> I've captured them all correctly.
>
> Dear Jeff and Reshad,
> I believe that all action points from the IESG reviews and discussions are
> reflected in the current version. I much appreciate your consideration and
> suggestion on the next steps to progress this document.
>
> Regards,
> Greg
>
> -- Forwarded message -
> From: 
> Date: Mon, May 25, 2020 at 3:00 PM
> Subject: New Version Notification for draft-ietf-bfd-vxlan-12.txt
> To: Sudarsan Paragiri , Mallik Mudigonda <
> mmudi...@cisco.com>, Greg Mirsky , Vengada Prasad
> Govindan , Santosh Pallagatti <
> santosh.pallaga...@gmail.com>
>
>
>
> A new version of I-D, draft-ietf-bfd-vxlan-12.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:   draft-ietf-bfd-vxlan
> Revision:   12
> Title:  BFD for VXLAN
> Document date:  2020-05-25
> Group:  bfd
> Pages:  11
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-12.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-bfd-vxlan-12
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-12
>
> Abstract:
>This document describes the use of the Bidirectional Forwarding
>Detection (BFD) protocol in point-to-point Virtual eXtensible Local
>Area Network (VXLAN) tunnels used to form an overlay network.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>

Fwd: New Version Notification for draft-ietf-bfd-vxlan-12.txt

[Greg Mirsky]

Dear Carlos,
thank you for your comments and suggestions. I hope that the updated
version of the draft addresses your comments. Please let me know whether
I've captured them all correctly.

Dear Jeff and Reshad,
I believe that all action points from the IESG reviews and discussions are
reflected in the current version. I much appreciate your consideration and
suggestion on the next steps to progress this document.

Regards,
Greg

-- Forwarded message -
From: 
Date: Mon, May 25, 2020 at 3:00 PM
Subject: New Version Notification for draft-ietf-bfd-vxlan-12.txt
To: Sudarsan Paragiri , Mallik Mudigonda <
mmudi...@cisco.com>, Greg Mirsky , Vengada Prasad
Govindan , Santosh Pallagatti <
santosh.pallaga...@gmail.com>



A new version of I-D, draft-ietf-bfd-vxlan-12.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-ietf-bfd-vxlan
Revision:   12
Title:  BFD for VXLAN
Document date:  2020-05-25
Group:  bfd
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-12.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Htmlized:   https://tools.ietf.org/html/draft-ietf-bfd-vxlan-12
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-12

Abstract:
   This document describes the use of the Bidirectional Forwarding
   Detection (BFD) protocol in point-to-point Virtual eXtensible Local
   Area Network (VXLAN) tunnels used to form an overlay network.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Re: New Version Notification for draft-ietf-bfd-vxlan-11.txt

[Greg Mirsky]

Dear Carlos,
thank you for the suggestions. Attached are the working version and the
diff. My notes in-line below under GIM>> tag.

Regards,
Greg

On Tue, May 5, 2020 at 6:11 PM Carlos Pignataro (cpignata) <
cpign...@cisco.com> wrote:

> Hi, Greg,
>
> Thanks for the quick reply, please see inline.
>
> —
> Carlos Pignataro, car...@cisco.com
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
> 2020/05/05 午後8:10、Greg Mirsky のメール:
>
> Dear Carlos,
> I'll do top-posting to highlight the remaining points of discussion.
> Please correct me if my understanding is not correct:
>
>- the reference to Section 5 RFC 5881 in the following sentence:
>
>Validation of TTL or Hop Limit of the inner IP packet is performed as
> described in Section 5 [RFC5881].
>
>
>
> “Validation of TTL / Hop Limit of the inner IP packet, as long as the
> related considerations for BFD control packet demultiplexing and
> authentication, is performed as described in Section 5 [RFC5881].”
>
GIM>> Thank you, accepted.

>
>
> I expect that a reader of BFD over VXLAN document is able to find the
> relevant information in Section 5 of RFC 5881. Do you think that the
> reference to Section 5 RFC 5881 might be confusing to the reader? Would you
> suggest to use another reference without replicating the text from RFC 5881
> in this document?
>
>
>- Security Considerations section
>
> You've suggested:
> Currently the security considerations does not say “security
> considerations of 5881 apply here”, nor does it say “the ttl/hl protection
> isn’t useful in foobar “
>
> I think it should say both.
>
> This draft discusses the use of BFD over VXLAN. Do you mean that 'foobar'
> is BFD over VXLAN? Since security considerations in RFC 7348 are applicable
> in this draft, I don't think that GTSM is not useful in the case of BFD
> over VXLAN. Or I misinterpreted 'foobar'? Could you please clarify it?
>
>  Would the following update is acceptable:
> OLD TEXT:
>Other than requiring control of the number of BFD sessions between
>the same pair of VTEPs, this specification does not raise any
>additional security issues beyond those discussed in [RFC5880],
>[RFC5881], and [RFC7348].
> NEW TEXT:
>Other than requiring control of the number of BFD sessions between
>the same pair of VTEPs, this specification does not raise any
>additional security issues beyond those discussed in [RFC5880],
>[RFC5881], and [RFC7348] that apply to this document.
>
>
> I am sorry, as I read this I do not fully understand the first part. What
> is to “require _control_ of the number of sessions”?
>
> I would split that long sentence into two.
>
GIM>> I agree, the sentence is too convoluted. Would removing it altogether
and adding the following at the top of the section make it clearer:
   Security issues discussed in [RFC5880], [RFC5881], and [RFC7348]
   apply to this document.

>
>
>
>- Acknowledgments
>
> Thank you. I'll thoroughly look through all the relevant discussion
> threads in the mail archive.
>
>
> Sounds good.
>
> Thanks,
>
> Carlos.
>
>
>
> Regards,
> Greg
>
>
> On Mon, May 4, 2020 at 7:52 PM Carlos Pignataro (cpignata) <
> cpign...@cisco.com> wrote:
>
>> Dear Greg,
>>
>> As I said, I did *not* review the updated version (or the changes)
>> thoroughly (or superficially for that matter)
>>
>> Please do not count this as a review of the new revision, and instead
>> consider the context that I laid for my reply.
>>
>> I only checked the changes for one comment I had made.
>>
>> Please see inline.
>>
>> Thumb typed by Carlos Pignataro.
>> Excuze typofraphicak errows
>>
>> 2020/05/04 午後10:15、Greg Mirsky のメール:
>>
>> Dear Carlos,
>> thank you for your thorough review of the updated version,
>>
>>
>> I didn’t. This is what I had said:
>>
>> I have not checked the diff and the new text regarding the Eth MAC and
>> mgmt VNI.
>>
>> Assuming that was clear...
>>
>> helpful and
>> constructive suggestions.
>>
>>
>> Thanks. That was the intent, but only for the TTL/HL change.
>>
>> Please find my answers in-line tagged GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Mon, May 4, 2020 at 5:49 PM Carlos Pignataro (cpignata)
>>  wrote:
>>
>>
>> Dear Greg,
>>
>>
>> I have not checked the diff and the new text regarding the Eth MAC and
>> mgmt VNI.
>>
>>
>> However, these diffs al

Re: New Version Notification for draft-ietf-bfd-vxlan-11.txt

[Greg Mirsky]

Dear Carlos,
I'll do top-posting to highlight the remaining points of discussion. Please
correct me if my understanding is not correct:

   - the reference to Section 5 RFC 5881 in the following sentence:

   Validation of TTL or Hop Limit of the inner IP packet is performed as
described in Section 5 [RFC5881].

I expect that a reader of BFD over VXLAN document is able to find the
relevant information in Section 5 of RFC 5881. Do you think that the
reference to Section 5 RFC 5881 might be confusing to the reader? Would you
suggest to use another reference without replicating the text from RFC 5881
in this document?


   - Security Considerations section

You've suggested:
Currently the security considerations does not say “security considerations
of 5881 apply here”, nor does it say “the ttl/hl protection isn’t useful in
foobar “

I think it should say both.

This draft discusses the use of BFD over VXLAN. Do you mean that 'foobar'
is BFD over VXLAN? Since security considerations in RFC 7348 are applicable
in this draft, I don't think that GTSM is not useful in the case of BFD
over VXLAN. Or I misinterpreted 'foobar'? Could you please clarify it?

 Would the following update is acceptable:
OLD TEXT:
   Other than requiring control of the number of BFD sessions between
   the same pair of VTEPs, this specification does not raise any
   additional security issues beyond those discussed in [RFC5880],
   [RFC5881], and [RFC7348].
NEW TEXT:
   Other than requiring control of the number of BFD sessions between
   the same pair of VTEPs, this specification does not raise any
   additional security issues beyond those discussed in [RFC5880],
   [RFC5881], and [RFC7348] that apply to this document.


   - Acknowledgments

Thank you. I'll thoroughly look through all the relevant discussion threads
in the mail archive.


Regards,
Greg


On Mon, May 4, 2020 at 7:52 PM Carlos Pignataro (cpignata) <
cpign...@cisco.com> wrote:

> Dear Greg,
>
> As I said, I did *not* review the updated version (or the changes)
> thoroughly (or superficially for that matter)
>
> Please do not count this as a review of the new revision, and instead
> consider the context that I laid for my reply.
>
> I only checked the changes for one comment I had made.
>
> Please see inline.
>
> Thumb typed by Carlos Pignataro.
> Excuze typofraphicak errows
>
> 2020/05/04 午後10:15、Greg Mirsky のメール:
>
> Dear Carlos,
> thank you for your thorough review of the updated version,
>
>
> I didn’t. This is what I had said:
>
> I have not checked the diff and the new text regarding the Eth MAC and
> mgmt VNI.
>
> Assuming that was clear...
>
> helpful and
> constructive suggestions.
>
>
> Thanks. That was the intent, but only for the TTL/HL change.
>
> Please find my answers in-line tagged GIM>>.
>
> Regards,
> Greg
>
> On Mon, May 4, 2020 at 5:49 PM Carlos Pignataro (cpignata)
>  wrote:
>
>
> Dear Greg,
>
>
> I have not checked the diff and the new text regarding the Eth MAC and
> mgmt VNI.
>
>
> However, these diffs also include a change that you did not mention: TTL /
> Hop Limit handling, which is one of the comments I had made.
>
>
> In that context, thank you very much! since this update partially
> (although largely) addresses my comment.
>
>
> Still missing:
>
>
> TTL or Hop Limit: MUST be set to 255 in accordance with the
>
> Generalized TTL Security Mechanism [RFC5881].
>
>
> CMP: this is an incorrect citation. The GTSM is RFC 5082, not RFC 5881. I
> recommend adding a Reference to RFC 5082 (as I’d suggested before).
>
> GIM>> Agreed, will change the reference to RFC 5082
>
>
> Thanks.
>
>
>   Validation of TTL or Hop Limit of the inner IP packet is performed as
>
>   described in Section 5 [RFC5881].
>
>
> CMP: This is an oversimplification. S5 of RFC 5881 explains not only how
> to validate TTL/HL, but also about demultiplexing tulles in presence of
> auth and various header fields.
>
> GIM>> I've compared Section 3 of RFC 5082 and Section 5 of RFC 5881
> and still believe that for this document the reference to Section 5 of
> RFC 5881 is more helpful to a reader and an implementor.
>
>
> Yes, I agree with this. I did not say “change this reference to 5082” —
> that was the previous comment on a different passage.
>
> Section 5
> provides an explicit specification on handling TTL/HC != 255 by a
> receiving BFD system. I think that it is important to reference
> Section 5, as the handling of TTL/HC != 255 is different depending on
> whether the BFD session is in unauthenticated or authenticated mode.
> Would you agree?
>
>
> Yes, but that’s orthogonal to my comment.
>
> My point is that the relevan

Re: New Version Notification for draft-ietf-bfd-vxlan-11.txt

[Greg Mirsky]

Dear Carlos,
thank you for your thorough review of the updated version, helpful and
constructive suggestions. Please find my answers in-line tagged GIM>>.

Regards,
Greg

On Mon, May 4, 2020 at 5:49 PM Carlos Pignataro (cpignata)
 wrote:
>
> Dear Greg,
>
> I have not checked the diff and the new text regarding the Eth MAC and mgmt 
> VNI.
>
> However, these diffs also include a change that you did not mention: TTL / 
> Hop Limit handling, which is one of the comments I had made.
>
> In that context, thank you very much! since this update partially (although 
> largely) addresses my comment.
>
> Still missing:
>
>  TTL or Hop Limit: MUST be set to 255 in accordance with the
>  Generalized TTL Security Mechanism [RFC5881].
>
> CMP: this is an incorrect citation. The GTSM is RFC 5082, not RFC 5881. I 
> recommend adding a Reference to RFC 5082 (as I’d suggested before)..
GIM>> Agreed, will change the reference to RFC 5082
>
>Validation of TTL or Hop Limit of the inner IP packet is performed as
>described in Section 5 [RFC5881].
>
> CMP: This is an oversimplification. S5 of RFC 5881 explains not only how to 
> validate TTL/HL, but also about demultiplexing tulles in presence of auth and 
> various header fields.
GIM>> I've compared Section 3 of RFC 5082 and Section 5 of RFC 5881
and still believe that for this document the reference to Section 5 of
RFC 5881 is more helpful to a reader and an implementor. Section 5
provides an explicit specification on handling TTL/HC != 255 by a
receiving BFD system. I think that it is important to reference
Section 5, as the handling of TTL/HC != 255 is different depending on
whether the BFD session is in unauthenticated or authenticated mode.
Would you agree?
>
> 9.  Security Considerations
>
> CMP: A discussion on the positive impact of using GTSM would help here.
GIM>> The Security Consideration section in RFC 5881 provides the
excellent text on the benefit of using GTSM in both, unauthenticated
and authenticated, modes. the last para in the Security Consideration
section of this document mentioned the discussion in several RFCs,
including in RFC 5881. Do you think that an additional text about the
use of GTSM in single-hop BFD should be added in this document? Could
you suggest some text?
>
> 11.  Acknowledgments
>
> CMP: Both professional courtesy as well as proper record and provenance 
> tracking suggest keeping an updated Acknowledgements section.
GIM>> My apologies, I've updated the working version accordingly.
>
> Best,
>
> —
> Carlos Pignataro, car...@cisco.com
>
> “Sometimes I use big words that I do not fully understand, to make myself 
> sound more photosynthesis."
>
> 2020/05/04 午後6:58、Greg Mirsky のメール:
>
> Dear All,
> my apologies for holding off this upload. The update is to address a
> set of comments related to the use of destination Ethernet MAC in the
> inner Ethernet frame that encapsulates a BFD control message. A new
> section on the use of the Management VNI has been added and the
> document now considers only the case of using the Management VNI to
> transmitted receive BFD control messages.
> Always welcome your questions and comments.
>
> Regards,
> Greg
>
> -- Forwarded message -
> From: 
> Date: Mon, May 4, 2020 at 3:50 PM
> Subject: New Version Notification for draft-ietf-bfd-vxlan-11.txt
> To: Mallik Mudigonda , Sudarsan Paragiri
> , Greg Mirsky , Santosh
> Pallagatti , Vengada Prasad Govindan
> 
>
>
>
> A new version of I-D, draft-ietf-bfd-vxlan-11.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:   draft-ietf-bfd-vxlan
> Revision:   11
> Title:  BFD for VXLAN
> Document date:  2020-05-04
> Group:  bfd
> Pages:  11
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-11.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-bfd-vxlan-11
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-11
>
> Abstract:
>   This document describes the use of the Bidirectional Forwarding
>   Detection (BFD) protocol in point-to-point Virtual eXtensible Local
>   Area Network (VXLAN) tunnels used to form an overlay network.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>

Fwd: New Version Notification for draft-ietf-bfd-vxlan-11.txt

[Greg Mirsky]

Dear All,
my apologies for holding off this upload. The update is to address a
set of comments related to the use of destination Ethernet MAC in the
inner Ethernet frame that encapsulates a BFD control message. A new
section on the use of the Management VNI has been added and the
document now considers only the case of using the Management VNI to
transmitted receive BFD control messages.
Always welcome your questions and comments.

Regards,
Greg

-- Forwarded message -
From: 
Date: Mon, May 4, 2020 at 3:50 PM
Subject: New Version Notification for draft-ietf-bfd-vxlan-11.txt
To: Mallik Mudigonda , Sudarsan Paragiri
, Greg Mirsky , Santosh
Pallagatti , Vengada Prasad Govindan




A new version of I-D, draft-ietf-bfd-vxlan-11.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-ietf-bfd-vxlan
Revision:   11
Title:  BFD for VXLAN
Document date:  2020-05-04
Group:  bfd
Pages:  11
URL:https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-11.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Htmlized:   https://tools.ietf.org/html/draft-ietf-bfd-vxlan-11
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-11

Abstract:
   This document describes the use of the Bidirectional Forwarding
   Detection (BFD) protocol in point-to-point Virtual eXtensible Local
   Area Network (VXLAN) tunnels used to form an overlay network.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Re: draft-ietf-bfd-vxlan IESG status

[Greg Mirsky]

Dear All,
I've looked at:
Open Issue 4: "multicast service node" text (COMMENT via Benjamin K.)

Proposed Action: Incorporate suggested text from Benjamin K. to clarify text
in -10.
Below is the COMMENT by Benjamin Kaduk:
Section 1

   In the case where a Multicast Service Node (MSN) (as described in
   Section 3.3 of [RFC8293]) resides behind a Network Virtualization
   Endpoint (NVE), the mechanisms described in this document apply and
   can, therefore, be used to test the connectivity from the source NVE
   to the MSN.

I'm not sure that I'm parsing "resides behind" properly.  Is the idea
that the multicast traffic starts off at a tenant-system source, hits a
NVE gateway to enter the VXLAN, traverses the VXLAN a bit before getting
to the MSN, and is replicated from the MSN to various NVE termini?  I
think I'd be less confused if this was described as "participates in the
VXLAN" or "is part of the virtualized environment", as the current
"behind" wording makes me think of a firewall-like topology where the
NVE behind which the MSN resides will be decapsulating traffic.

I propose to use the first option, i.e., "participates in the VXLAN". Below
is what is changed:
OLD TEXT:
   In the case where a Multicast Service Node (MSN) (as described in
   Section 3.3 of [RFC8293]) resides behind a Network Virtualization
   Endpoint (NVE) ...
NEW TEXT:
   In the case where a Multicast Service Node (MSN) (as described in
   Section 3.3 of [RFC8293]) participates in VXLAN ...

Regards,
Greg

On Mon, Jan 27, 2020 at 2:11 PM Jeffrey Haas  wrote:

> Much like the BFD Working Group discussion on the BFD for vxlan feature,
> the
> IESG review for the draft has reached a stage where it is difficult to
> determine what the related actions are.  (IESG take note for tools
> discussion!)
>
> This email is an attempt to kick the conversation back into gear.
>
> My notes here are based on the current status of the document tracked here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ballot/
>
> My comments on the draft are based on the -10 version of the draft as
> currently published.
>
> ---
>
> Open Issue 1: Discussion on TTL/Hop Limit = 1
>
> Proposed Action: Greg has proposed text he will send to the working group
> suggesting GTSM procedures be utilized.  The expected concern is how this
> impacts existing implementations.
>
> ---
>
> Open Issue 2: Document Status should be Informational rather than Proposed
> Standard.
>
> Proposed Action: Greg should make the document Informational.  Prior WG
> discussion suggested that we don't really care what level it should be at,
> and had actually requested IESG guidance long ago via our AD.
>
> ---
>
> Open Issue 3: dst IP/MAC assignment procedures for inner VXLAN headers.
> (DISCUSS via Benjamin K.)  Specifically per-VNI form rather than strictly
> VTEP-to-VTEP mode.
>
> Issue Comment 1 (Benjamin K.): This is "a namespace grab in what is
> essentially the tenant's namespace".
>
> Issue Comment 2 (Jeff H.): Joel Halpern flagged this repeatedly as well as
> part of directorate review.
>
> Issue Comment 3 (Benjamin K.): "management VNI does not suffer from this
> namespacing issue".
>
> Issue Comment 4 (Jeff H./Benjamin K.): The concept of a "management VNI" is
> not supported by existing standards work, but is accepted as a common
> implementation behavior.
>
> Issue Comment 5: A significant exploration of this set of issues is
> documented in the following thread:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/SfXfu3pCh9BxaRFrXbEOgGt6xjE/
>
> Proposed Action: Limit the Internet-Draft's applicability to verifying
> connectivity to the management VNI.  "All other uses of the specification
> to
> test toward other vxlan endpoints are out of scope."
>
> In reviewing the thread, my reading of the comments from Santosh, Anoop,
> and
> Dinesh are effectively "don't break existing implementations".  There is
> acknowledge among those in the discusssion that numbering space collisions
> between the protocol codepoints chosen to run as endpoints for the BFD for
> vxlan session and the tenant space are undesirable.  It is generally agreed
> in the thread (IMO) that for the "management VNI" case that this is not
> problematic, although the details of provisioning are still specific to the
> implementation.
>
> By setting the case aside where a test to a specific VTEP may have tenant
> namespace collisions, the document can be cleaned of a lot of unnecessary
> edge cases that are difficult to generally resolve.  Implementations that
> may choose to permit sessions to non-management VNIs will have need to
> resolve how to deal with collisions.
>
> ---
>
> Open Issue 4: "multicast service node" text (COMMENT via Benjamin K.)
>
> Proposed Action: Incorporate suggested text from Benjamin K. to clarify
> text
> in -10.
>
> ---
>
> Open Issue 5: Comma parsing issue (COMMENT via Benjamin K.)
>
> Proposed Action: Accept Benjamin's suggested changes.  (RFC Editor will win
> the day here 

Re: draft-ietf-bfd-vxlan IESG status

[Greg Mirsky]

urity Considerations

   This document recommends using an address from the Internal host
   loopback addresses 127/8 range for IPv4 or an IP4-mapped IPv4
   loopback address from :::127.0.0.0/104 range for IPv6 as the
   destination IP address in the inner IP header.  Using such an address
   prevents the forwarding of the encapsulated BFD control message by a
   transient node in case the VXLAN tunnel is broken as according to
   [RFC1812]:

  A router SHOULD NOT forward, except over a loopback interface, any
  packet that has a destination address on network 127.  A router
  MAY have a switch that allows the network manager to disable these
  checks.  If such a switch is provided, it MUST default to
  performing the checks.

   If the implementation supports establishing multiple BFD sessions
   between the same pair of VTEPs, there SHOULD be a mechanism to



Pallagatti, et al.Expires July 25, 2020 [Page 9]

Internet-DraftBFD for VXLAN January 2020


   control the maximum number of such sessions that can be active at the
   same time.

   Other than requiring control of the number of BFD sessions between
   the same pair of VTEPs, this specification does not raise any
   additional security issues beyond those discussed in [RFC5880],
   [RFC5881], and [RFC7348].

10.  Contributors


   Reshad Rahman
   rrah...@cisco.com
   Cisco


11.  Acknowledgments

   Authors would like to thank Jeff Haas of Juniper Networks for his
   reviews and feedback on this material.

   Authors would also like to thank Nobo Akiya, Marc Binderberger,
   Shahram Davari, Donald E.  Eastlake 3rd, and Anoop Ghanwani for the
   extensive reviews and the most detailed and helpful comments.

12.  References

12.1.  Normative References

   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
  RFC 1812, DOI 10.17487/RFC1812, June 1995,
  <https://www.rfc-editor.org/info/rfc1812>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  Requirement Levels", BCP 14, RFC 2119,
  DOI 10.17487/RFC2119, March 1997,
  <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
  Pignataro, "The Generalized TTL Security Mechanism
  (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
  <https://www.rfc-editor.org/info/rfc5082>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
  (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
  <https://www.rfc-editor.org/info/rfc5880>.





Pallagatti, et al.Expires July 25, 2020[Page 10]

Internet-DraftBFD for VXLAN January 2020


   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
  (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
  DOI 10.17487/RFC5881, June 2010,
  <https://www.rfc-editor.org/info/rfc5881>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
  L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
  eXtensible Local Area Network (VXLAN): A Framework for
  Overlaying Virtualized Layer 2 Networks over Layer 3
  Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
  <https://www.rfc-editor.org/info/rfc7348>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
  2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
  May 2017, <https://www.rfc-editor.org/info/rfc8174>.

12.2.  Informational References

   [RFC8293]  Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R.
  Krishnan, "A Framework for Multicast in Network
  Virtualization over Layer 3", RFC 8293,
  DOI 10.17487/RFC8293, January 2018,
  <https://www.rfc-editor.org/info/rfc8293>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
  Uttaro, J., and W. Henderickx, "A Network Virtualization
  Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
  DOI 10.17487/RFC8365, March 2018,
  <https://www.rfc-editor.org/info/rfc8365>.

Authors' Addresses

   Santosh Pallagatti (editor)
   VMware

   Email: santosh.pallaga...@gmail.com


   Sudarsan Paragiri
   Individual Contributor

   Email: sudarsan@gmail.com


   Vengada Prasad Govindan
   Cisco

   Email: vengg...@cisco.com



Pallagatti, et al.Expires July 25, 2020[Page 11]

Internet-DraftBFD for VXLAN January 2020


   Mallik Mudigonda
   Cisco

   Email: mmudi...@cisco.com


   Greg Mirsky
   ZTE Corp.

   Email: gregimir...@gmail.com









































Pallagatti, et al.Expires July 25, 2020[Page 12]
<<< text/html; charset="UTF-8";  name="Diff_ draft-ietf-bfd-vxlan-10.txt - draft-ietf-bfd-vxlan-11.txt.html": Unrecognized >>>

Re: Alvaro Retana's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

[Greg Mirsky]

Hi Alvaro,
thank you for your thorough review, detailed questions, and helpful
suggestions. Please find answers in-line below under GIM>> tag.
Also, attached is the diff to highlight all the updates in the current
working version of the draft.

Regards,
Greg

On Tue, Dec 17, 2019 at 9:57 AM Alvaro Retana via Datatracker <
nore...@ietf.org> wrote:

> Alvaro Retana has entered the following ballot position for
> draft-ietf-bfd-vxlan-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>
>
>
> --
> DISCUSS:
> --
>
> I support Eric's DISCUSS point about the TTL, but I want to go a step
> further
> because this document contradicts rfc5881, which is clear about the TTL
> setting
> (from §5):
>
>If BFD authentication is not in use on a session, all BFD Control
>packets for the session MUST be sent with a Time to Live (TTL) or Hop
>Limit value of 255.  All received BFD Control packets that are
>demultiplexed to the session MUST be discarded if the received TTL or
>Hop Limit is not equal to 255.  A discussion of this mechanism can be
>found in [GTSM].
>
>If BFD authentication is in use on a session, all BFD Control packets
>MUST be sent with a TTL or Hop Limit value of 255.  All received BFD
>Control packets that are demultiplexed to the session MAY be
>discarded if the received TTL or Hop Limit is not equal to 255.  If
>the TTL/Hop Limit check is made, it MAY be done before any
>cryptographic authentication takes place if this will avoid
>unnecessary calculation that would be detrimental to the receiving
>system.
>
> OTOH, Section 4 of this document specifies:
>
>  TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
>  packet is not routed within the Layer 3 underlay network.  This
>  addresses the scenario when the inner IP destination address is
>  of VXLAN gateway and there is a router in underlay which
>  removes the VXLAN header, then it is possible to route the
>  packet as VXLAN  gateway address is routable address.
>
> Not wanting the packet to be routed in the underlay sounds like a
> reasonable
> justification -- but I couldn't find the specification in rfc7348 about "a
> router in underlay which removes the VXLAN header".  Maybe I missed it...
>
GIM>> You're right, RFC 7348 does not describe what may be referred to as
Penultimate VXLAN termination. We've received the information about the
scenario described in Section 4 (the quote above) from one of the experts
well-familiar with VXLAN deployments and an existing BFD over VXLAN
implementation that sets IP TTL to 1 for BFD control packets.

>
> Independent of VXLAN, the conflict with rfc5881 remains -- given the text
> above, it seems to me that it would be ok if the TTL was set to 1 if
> authentication is is use, but this document doesn't talk about requiring
> authentication.
>
GIM>> You're right, BFD authentication is not dicussed in this document. In
VXLAN's Security Considerations section has been noted that a traditional
security mechanism, e.g., IPsec, may be used to authenticate and/or encrypt
VXLAN traffic. Perhaps the same should be said about BFD over VXLAN. For
example, text below may be added to Section 9:

A BFD over VXLAN session MAY be secured by using a traditional
security mechanism, e.g. IPsec, that authenticates and/or encrypts
VXLAN traffic.


>
> --
> COMMENT:
> --
>
> I also support Ben's DISCUSS.
>
> Non-blocking comments:
>
> (1) §3: "...a service layer BFD session may be used between the tenants of
> VTEPs IP1 and IP2..."   Just to be clear, the use of BFD in a "service
> layer
> session" is out of scope of this document, right?  It might be nice to say
> so.
>
GIM>> Agree. Will the following update be acceptable:
OLD TEXT:
   At the same time, a service layer BFD session may be used between the
   tenants of VTEPs IP1 and IP2 to provide end-to-end fault management.
NEW TEXT:
   At the same time, a service layer BFD session may be used between the
   tenants of VTEPs IP1 and IP2 to provide end-to-end fault management
   (this use case is outside the scope of this document).

>
> (2) §3: "As per Section 4, the inner destination IP address SHOULD be..."
> If
> the specification is already in Section 4, then there doesn't seem to be a
> need
> to repeat it.  It might 

Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

[Greg Mirsky]

Hi Eric,
thank you for your review, comments, and suggestions. Please find my
answers below under GIM>> tag. Also, attached is the diff to the working
version of the document that includes updates that Adam has suggested.

Best regards,
Greg


On Tue, Dec 17, 2019 at 12:51 AM Éric Vyncke via Datatracker <
nore...@ietf.org> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-bfd-vxlan-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>
>
>
> --
> DISCUSS:
> --
>
>
> Thank you for the work put into this document.
>
> I fully second Adam's COMMENT that should be fixed before publication (IMHO
> this is a DISCUSS).
>
GIM>> I've applied changes suggested by Adam to the working version of the
document.

>
> Answers to my COMMENTs below will be welcome, even if those COMMENTs are
> not
> blocking.
>
> As usual, an answer to the DISCUSS is required to clear my DISCUSS though..
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == DISCUSS ==
>
> May be I am not familiar enough with BFD, but, RFC 5881 (the one defining
> BFD)
> specifies the use of TTL = Hop Limit = 255.. Why this document uses a
> value of
> 1 ?
>
GIM>> Jeff and Carlos are in a very detailed and insightful discussion.
I'll wait for its conclusion and follow on their agreement.


> -- Section 3 --
> IPv4-mapped IPv6 addresses are only to be used inside a host and should
> never
> be transmitted in real packets (including packets inside a tunnel) see
> section
> 4.2 of RFC 4038 (even if informational). As other IESG reviewers, I wonder
> why
> ::1/128 is not used?
>
GIM>> The mechanism of using an address from the loopback address range or
IPv4-mapped addresses of that range may be used to create entropy and
monitor ECMP paths in an IP/MPLS network (RFC 8029 and RFC 5884). This
specification uses the same mechanism for ECMP environment in the underlay
network.

>
> -- Section 8 --
> The document specifies no IANA actions while the shepherd write-up talks
> about
> a IANA action.
>
GIM>> RtgDir review from Joel Halpern and the extensive discussion on BFD
WG list lead to this change. As a result, the request to allocate a MAC
address to be used as the destination MAC address in the inner Ethernet
header was withdrawn and removed from the specification.

>
> -- Section 9 --
> This section is only about IPv4 (TTL and RFC 1812). Please address IPv6 as
> well.
>
GIM>> Added "or Hop Limit". Please let me know if you agree. As for a IPv6
relevant reference equivalent to RFC 1812, Adam Roach has noted that RFC
8504 does not have anything of the kind. At the same time, the use of
IPv4-mapped loopback address range has been mandated in RFC 8029 and RFC
5884.

>
>
> --
> COMMENT:
> --
>
> == COMMENTS ==
>
> RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer
> that
> this document is only required to address the Ethernet encapsulation ? I.e.
> specifying the Ethernet MAC addresses?
>
GIM>> There were several threads on encapsulation of BFD Control packet
over VXLAN that, in my estimation, gathered 150+ messages. As you've
noticed from the Shepherd write-up, the use of the dedicated MAC address
was proposed, discussed, and documented. But later the WG decided not to
use the dedicated MAC as the destination MAC in the inner Ethernet frame.
Similarly, we had an extended discussion, including valuable input from
implementors of BFD over VXLAN, on the selection of the destination IP
address in the inner IP header. And another set of issues was discovered
related to the selection of VXLAN VNI value when encapsulating  BFD control
packet. I hope we've analyzed all encapsulation issues and documented them
sufficiently for the benefit of future implementations.

>
> -- Section 3 --
> At first sight, I was surprized by having a BFD session per VXLAN VNI as it
> will create some scalability issue, but, I assume that this is to detect
> misconfiguration as well. If so, perhaps worth mentionnig the reasoning
> behind?
>
GIM>> I agree, detecting misconfiguration might be one of the reasons to
run BFD over some VXLAN VNIs. Would the following text be acceptable:

NEW TEXT:
   Using a BFD session to monitor a set of VXLAN VNIs between
   the same pair of VTEPs might help to detect and localize problems
   caused by 

Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

[Greg Mirsky]

Hi Carlos, Jeff, et al.,
thank you for a very insightful discussion.
Based on the input from the experts familiar with VXLAN deployment scenario
the following text was added to justify the requirement to set TTL or Hop
Limit to 1:
 TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
 packet is not routed within the Layer 3 underlay network.  This
 addresses the scenario when the inner IP destination address is
 of VXLAN gateway and there is a router in underlay which
 removes the VXLAN header, then it is possible to route the
 packet as VXLAN  gateway address is routable address.

Best regards,
Greg

On Wed, Dec 18, 2019 at 1:36 PM Jeffrey Haas  wrote:

> Carlos,
>
> On Wed, Dec 18, 2019 at 09:28:30PM +, Carlos Pignataro (cpignata)
> wrote:
> > The TTL of 1 recommended for RFC 4379 / RFC 8029 S4.3 is because if the
> MPLS packet is mis-routed, or there's a forwarding mis-programming, then an
> MPLS LSE pop would expose the BFD packet and so that the BFD is not further
> mis-forwarded.
> >
> > In the VXLAN case an intermediate router would not remove the VXLAN
> encap because the outer encap is IP (with a destination address, not an
> MPLS Label that can be mis-interpreted in context) and a mid-point router
> would not understand VXLAN.
>
> Explained, that now seems obvious.  Thanks. :-)
>
> But given that point, what precisely is the objection to the inner IP
> header
> of the BFD for vxlan having a TTL of 1?
>
> I think this is partially a matter of attack spaces varying depending on
> whether we're targeting the management VNI vs. a tenant.  In the case of
> the
> management VNI, we (should) have very strong control over what BFD traffic
> is getting encapsulated.
>
> However, for tenant VNI mode, is the argument that depending on what the
> other vxlan PDU parameters look like, tenant sourced BFD PDUs may be
> indistinguishable from ones sourced by the management infrastructure?  And
> if so, how would GTSM help us here?
>
> -- Jeff
>
>

Re: Barry Leiba's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)

[Greg Mirsky]

Hi Barry,
thank you for your review, comments, and suggestions. Please find my
answers in-line below under GIM>> tag.
Attached, please find the diff attached (apologies that it includes also
updates to several other reviews).

Best regards,
Greg

On Mon, Dec 16, 2019 at 9:39 PM Barry Leiba via Datatracker <
nore...@ietf.org> wrote:

> Barry Leiba has entered the following ballot position for
> draft-ietf-bfd-vxlan-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>
>
>
> --
> COMMENT:
> --
>
> I support Ben’s DISCUSS.  In addition, I have a number of editorial
> comments.
>
> General: there are a lot of missing or incorrect articles, making the
> document
> harder to read than it should be.  It would be good to fix that.  If you
> let
> the RFC Editor fix it, it will require careful review during AUTH48 to make
> sure it’s correct.
>
> — Abstract —
> The phrase “forming up” is odd; I suggest just “forming”.
>
GIM>> It was suggested to s/forming up/used to form/. Do you think it reads
better?

>
> — Section 3 —
>
>BFD packets intended for a VTEP MUST
>NOT be forwarded to a VM as a VM may drop BFD packets leading to a
>false negative.
>
> This needs two commas: one before “as” and one before “leading”.  And what
> does
> “leading to a false negative” mean here?  I don’t understand.
>
GIM>> Thank you for your suggestion to improve the text. If BFD Control
packets are not processed at the egress BFD system, even though the VXLAN
tunnel is operational, the state of the session will be changed to Down
once the Detection timer expires. We consider that such failure
notification is "false" as it does not indicate a failure of the monitored
VXLAN tunnel but something else, perhaps misconfiguration or an
implementation problem.

>
>It is RECOMMENDED to allow
>addresses from the loopback range through a firewall only if it is
>used as the destination IP address in the inner IP header, and the
>destination UDP port is set to 3784 [RFC5881].
>
> I THINK the antecedent for “it” is meant to be “addresses from the loopback
> range”, though because of the number mismatch it looks like the antecedent
> is
> “a firewall”.  One fix is to change “addresses” to “an address”,
> correcting the
> number error, but that leaves the ambiguity.  Maybe betterto make it “only
> if
> they are used as destination IP addresses”.  Also, remove the comma.


> That fixes the sentence as written, but I also agree with Ben’s comment
> that
> this might need more significant rewording.
>
GIM>> Thank you for your thorough consideration of the text and your
thoughtful suggestion. I've followed the second of your suggested changes.
Will work on improving the text with Ben.

>
> — Section 4 —
>
>BFD packet MUST be encapsulated and sent to a remote VTEP as
>explained in this section.
>
> This needs to be either “A BFD packet” or “BFD packets” and “VTEPs”.
>
GIM>>  I've followed the second option as the next sentence uses the plural
form.

>
>  The MAC address MAY be
>  configured, or it MAY be learned via a control plane protocol.
>
> Are those the only two choices?  As both “MAY” are optional, as written it
> allows for others.  I suggest not using BCP 14 key words here, and instead
> saying, “The MAC address is either configured or learned via a control
> plane
> protocol.”
>
GIM>> I agree.

>
>  This
>  addresses the scenario when the inner IP destination address is
>  of VXLAN gateway and there is a router in underlay which
>  removes the VXLAN header, then it is possible to route the
>  packet as VXLAN  gateway address is routable address.
>
> This sentence is too fractured for me to make any sense of it, so I can’t
> suggest a fix.  Please fix it.  It looks like Ben made more sense of it
> than I
> could, so maybe his suggestion will work.
>
GIM>> I agree. I'll update the passage while discussing Ben's comments.

>
> — Section 5 —
>
>received VXLAN packet MUST follow the procedures described in
>Section 4.1 [RFC7348].
>
> This needs to say “Section 4.1 of [RFC7348].”
>
GIM>> Accepted, done.
<<< text/html; charset="UTF-8";  name="Diff_ draft-ietf-bfd-vxlan-09.txt - draft-ietf-bfd-vxlan-10.txt.html": Unrecognized >>>

Re: Roman Danyliw's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)

[Greg Mirsky]

Hi Roman,
thank you for your review, detailed questions, and helpful suggestions. All
editorial changes applied to the working version of the document. Please
find my answers in-line below tagged GIM>>.

Best regards,
Greg

On Mon, Dec 16, 2019 at 6:01 PM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-bfd-vxlan-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>
>
>
> --
> COMMENT:
> --
>
> I support Ben Kaduk’s DISCUSS position.
>
> * Section 9. Per “The document requires setting the inner IP TTL to 1,
> which
> could be used as a DDoS attack vector”, could you please clarify what
> part(s)
> of the notional architecture would be impacted (e.g., physical, virtual;
> and
> how)?
>
GIM>> The scenario we've considered is when a VXLAN tunnel is broken. A
packet that is not using an address from the loopback range (or from
IPv4-mapped addresses for that range for IPv6) may be routed and TTL or Hop
count will be zeroed on the next node. The impact likely to be noticed on
the control plane. Would you agree?

>
> * Section 9. Per:
>Thus the implementation MUST have
>throttling in place to control the rate of BFD Control packets sent
>to the control plane.  On the other hand, over-aggressive throttling
>of BFD Control packets may become the cause of the inability to form
>and maintain BFD session at scale.  Hence, throttling of BFD Control
>packets SHOULD be adjusted to permit BFD to work according to its
>procedures.
>
> I’m having difficulty parsing the guidance above – it points out the need
> to
> throttle and the ramifications of doing so.  Per the last sentence, could
> you
> please clarify how the throttling should be calibrated.
>
GIM>> I think that it is very much implementation-specific. For example, an
implementation may throttle control packets per BFD session or use a more
aggregate approach. On the other hand, intervals at which BFD Control
packets being transmitted and received play some role in selecting the
throttling limits.

>
> * Section 9.  Per “this specification does not raise any additional
> security
> issues beyond those of the specifications referred to in the list of
> normative
> references”, I recommend being clearer which references you mean (i.e., I’m
> assuming you don’t mean RFC2119, RFC8174, etc.)
>
GIM>> Thank you for pointing to this ambiguity. The updated text:
   Other than inner IP TTL set to 1 and limit the number of BFD sessions
   between the same pair of VTEPs, this specification does not raise any
   additional security issues beyond those discussed in [RFC5880],
   [RFC5881], and [RFC7348].
Would it address your concern?

>
> * Editorial Nits:
> - Abstract. s/forming up/used to form/
>
> - Section 9. s/such address/such an address/
>
>
>

Re: Warren Kumari's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)

[Greg Mirsky]

Hi Warren,
thank you for the review. I've updated the representation of IPv6 addresses
to follow RFC 5952 and the reference to IPv4-mapped IPv4 loopback addresses
range per recommendations from Adam Roach. Attached, please find the diff
that highlights the updates made in the working version of the draft.
As to the suggestion made by Jurgen in his first review, would changing the
title of the section to Acronyms and Abbreviations make the scope of that
section more clear?

Regards,
Greg

On Tue, Dec 17, 2019 at 6:39 AM Warren Kumari via Datatracker <
nore...@ietf.org> wrote:

> Warren Kumari has entered the following ballot position for
> draft-ietf-bfd-vxlan-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>
>
>
> --
> COMMENT:
> --
>
> I support Benjamin and Eric's DISCUSSES - I considered holding a DISCUSS
> on the
> "loopback address" terminology and formatting (which was also noted in the
> excellent OpsDir review by Jürgen Schönwälder), but think that Eric can
> carry
> it.
>
> In addition, like Jurgen, I think it would be helpful to have pointers to
> where
> terms are defined - the "Terminology" section isn't really terminology, but
> rather just an acronym expansion section.
>
>
>
<<< text/html; charset="UTF-8";  name="Diff_ draft-ietf-bfd-vxlan-09.txt - draft-ietf-bfd-vxlan-10.txt.html": Unrecognized >>>

Re: Adam Roach's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)

[Greg Mirsky]

Hi Adam,
thank you for your review and the very clear suggestions, all is the most
helpful. I've followed your recommendations and applied changes to the
working version of the draft. Attached, please find the diff that
highlights updates. Also, please find my notes in-line tagged GIM>>.

Best regards,
Greg

On Mon, Dec 16, 2019 at 11:11 PM Adam Roach via Datatracker <
nore...@ietf.org> wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-bfd-vxlan-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for the work that everyone has put into this document. I have
> a couple of relatively important, related comments that should be
> taken into account prior to publication.
>
> ---
>
> §3:
>
> >  As per Section 4, the inner destination IP address SHOULD be set to
> >  one of the loopback addresses (127/8 range for IPv4 and
> >  0:0:0:0:0::7F00:0/104 range for IPv6).
>
> Please consider reformatting this IPv6 address according to the
> recommendations
> of RFC 5952 (paying particular attention to sections 4.2.1, 4.3, and 5):
>
> :::127.0.0.0/104
>
> It's also worth noting that, as a practical matter, modern operating
> systems do
> not seem to bind to anything in the IPv4-mapped range assigned to IPv4
> loopback:
>
> Linux:
>
>   ~$ ping6 :::127.0.0.1
>   PING :::127.0.0.1(:::127.0.0.1) 56 data bytes
>   ^C
>   --- :::127.0.0.1 ping statistics ---
>   14 packets transmitted, 0 received, 100% packet loss, time 13316ms
>
> MacOS:
>
>   ~$ ping6 :::127.0.0.1
>   PING6(56=40+8+8 bytes) :::127.0.0.1 --> :::127.0.0.1
>   ping6: sendmsg: Invalid argument
>   ping6: wrote :::127.0.0.1 16 chars, ret=-1
>
>
> It is not clear to me whether this poses an issue for your intended usage..
>
GIM>> Thank you for sharing very interesting facts on the handling of these
addresses. I don't think that implementation on the egress BFD node would
listen on the particular address, more likely it would be on the value of
the well-known UDP port. The goal of using one of the addresses from this
range is to prevent leaking packets from a broken VXLAN tunnel (as was the
original goal in RFC 4379/8029 and RFC 5884).

>
> In any case, please do not refer to :::127.0.0.0/104 as "loopback
> addresses": IPv6 has only one loopback address defined (::1). The range
> you cite is best described as "IPv4-mapped IPv4 loopback addresses."
> Alternately -- and this is probably better -- use "::1/128" instead of
> ":::127.0.0.0/104" for the inner IP header destination address.
>
> As an aside, I share Benjamin's unease around the use of loopback addresses
> in this fashion. It may be worth noting that IETF protocols can reserve
> addresses in the 192.0.0.0/24 and 2001::/23 blocks if necessary, and such
> reserved addresses won't ever correspond to a valid destination.
>
> (There is corresponding text in section 4 that all of the preceding
> pertains
> to as well)
>
> ---
>
> §9:
>
> >  This document recommends using an address from the Internal host
> >  loopback addresses (127/8 range for IPv4 and
> >  0:0:0:0:0::7F00:0/104 range for IPv6) as the destination IP
> >  address in the inner IP header.  Using such address prevents the
> >  forwarding of the encapsulated BFD control message by a transient
> >  node in case the VXLAN tunnel is broken as according to [RFC1812]:
> >
> > A router SHOULD NOT forward, except over a loopback interface, any
> > packet that has a destination address on network 127.  A router
> > MAY have a switch that allows the network manager to disable these
> > checks.  If such a switch is provided, it MUST default to
> > performing the checks.
>
> In addition to the comments above about IPv6 address formatting, the
> improper use of "loopback" terminology as it applies to IPv6, and
> concerns about using localhost: it's worth noting that this text in
> RFC 1812 refers to IPv4 routers -- RFC 8504 has no equivalent language,
> and so the use of :::127.0.0.0/104 implies no special router handling..
> ::1 *probably* does, at least as a practical matter.
>
GIM>> As noted above, the reason of using addresses from this range was to
prevent packets from being routed in case a tunnel is broken. Do you think