Re: BFD WG adoption for draft-haas-bfd-large-packets

[xiao.min2]

Yes/Support. This draft provides a concise and practical way to perform path 
mtu detection and verification.






Best Regards,


Xiao Min





原始邮件



发件人：ReshadRahman(rrahman) 
收件人：rtg-bfd@ietf.org ;
日 期 ：2018年10月18日 09:06
主 题 ：BFD WG adoption for draft-haas-bfd-large-packets




Hello BFD WG,


 


We have received an adoption request for “BFD encapsulated in large packets”.


 


https://datatracker.ietf.org/doc/draft-haas-bfd-large-packets/


 


The adoption call will end on Friday Nov 9th.


 


Please send email to the list indicating “yes/support”  or “no/do not support”. 
If you do not support adoption, please state your reasons.


 


Regards,


Reshad & Jeff.

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[xiao.min2]

I support WG adoption of this draft. Use of the demand mode for p2p LSP 
monitoring is feasible and required.






Best Regards,


Xiao Min










原始邮件



发件人：JeffreyHaas 
收件人：rtg-bfd@ietf.org ;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand


Working Group,

The BFD chairs have received an adoption request for 
"BFD in Demand Mode over Point-to-Point MPLS LSP"
(draft-mirsky-bfd-mpls-demand).

https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/

The adoption call will end on the Friday after IETF 103, November 9.

Note that there is are existing IPR statements on this draft:
https://datatracker.ietf.org/ipr/3301/
https://datatracker.ietf.org/ipr/3104/

Please indicate to the mailing list whether you support adoption of this
draft.

-- Jeff & Reshad

Re: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[xiao.min2]

Hi Carlos,






My answers to your two questions are as follow:


In section 6.6 of RFC5880, just after the text you quoted, it says "One 
possible mechanism is the receipt of traffic from the remote system; another is 
the use of the Echo function." So I'm not sure what's your real concern.


In the abstract of this draft it says "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." If you don't like the expression form of the text quoted by 
you, pls feel free to propose some text.






Best Regards,


Xiao Min



原始邮件



发件人：CarlosPignataro(cpignata) 
收件人：肖敏10093570;
抄送人：Jeff Haas ;rtg-bfd@ietf.org ;
日 期 ：2018年10月26日 12:04
主 题 ：Re: WG Adoption request for draft-mirsky-bfd-mpls-demand


Xiao, 
Scanning through the draft, two questions:
 
1. What is the underlying mechanism to check liveness such that Demand can be 
used?
 
https://tools.ietf.org/html/rfc5880#section-6.6
 

   Demand mode requires that some other mechanism is used to imply

   continuing connectivity between the two systems.  The mechanism used
 

2. Is this draft testing liveness of a path or a node?
 
https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03#section-3
 

   In this state BFD peers MAY remain as long as the egress LER is in Up

   state.  The ingress LER MAY check liveness of the egress LER by

   setting the Poll flag.  The egress LER will respond by transmitting
 

 


Thanks,
 
— Carlos Pignataro


 
On Oct 19, 2018, at 9:59 PM, xiao.m...@zte.com.cn wrote:
 


I support WG adoption of this draft. Use of the demand mode for p2p LSP 
monitoring is feasible and required.


 


Best Regards,


Xiao Min


 




 






发件人：JeffreyHaas 

收件人：rtg-bfd@ietf.org ;

日 期 ：2018年10月18日 06:24

主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand



Working Group, The BFD chairs have received an adoption request for  "BFD in 
Demand Mode over Point-to-Point MPLS LSP" (draft-mirsky-bfd-mpls-demand). 
https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/ The adoption 
call will end on the Friday after IETF 103, November 9. Note that there is are 
existing IPR statements on this draft: https://datatracker.ietf.org/ipr/3301/ 
https://datatracker.ietf.org/ipr/3104/ Please indicate to the mailing list 
whether you support adoption of this draft. -- Jeff & Reshad

Re:IETF 104 - BFD agenda posted

[xiao.min2]

Hi Jeff & Reshad,






On Feb 18th I've already requested a small time slot to present 
draft-xiao-bfd-geneve-00, you may miss it, could you pls add it to the agenda?


BFD for Geneve (draft-xiao-bfd-geneve)   Presenter: Xiao Min   Duration: about 
5 min







Thanks,


Xiao Min



原始邮件



发件人：JeffreyHaas 
收件人：rtg-bfd@ietf.org ;
日 期 ：2019年03月12日 20:56
主 题 ：IETF 104 - BFD agenda posted


Working Group,

We have a two hour session scheduled the Wednesday of IETF week.

A tentative agenda has been posted based on existing requests.
We have room for more presentations or discussion topics.

https://datatracker.ietf.org/doc/agenda-104-bfd/


-- Jeff & Reshad

Re:IETF 104 - BFD agenda posted

[xiao.min2]

Hi Jeff,






Thank you for the arrangement.


I'll follow your guidance on preparing the slides.






Thanks,


Xiao Min










原始邮件



发件人：JeffreyHaas 
收件人：肖敏10093570;
抄送人：rtg-bfd@ietf.org ;
日 期 ：2019年03月13日 23:22
主 题 ：Re: IETF 104 - BFD agenda posted


Xiao Min,


I've added you to the agenda.



A personal request: Have at least one slide explaining Geneve.  There will be 
working group members that don't follow that work.



-- Jeff
On Mar 13, 2019, at 12:54 AM,   
wrote:



Hi Jeff & Reshad,





On Feb 18th I've already requested a small time slot to present 
draft-xiao-bfd-geneve-00, you may miss it, could you pls add it to the agenda?


BFD for Geneve (draft-xiao-bfd-geneve)   Presenter: Xiao Min   Duration: about 
5 min





Thanks,


Xiao Min
















发件人：JeffreyHaas 

收件人：rtg-bfd@ietf.org ;

日 期 ：2019年03月12日 20:56

主 题 ：IETF 104 - BFD agenda posted



Working Group,We have a two hour session scheduled the Wednesday of IETF week.A 
tentative agenda has been posted based on existing requests.We have room for 
more presentations or discussion 
topics.https://datatracker.ietf.org/doc/agenda-104-bfd/-- Jeff & Reshad

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

[xiao.min2]

Hi Reshad,







I support this draft to be published, it provides a simple and elegant 
extension for BFD to verify path MTU.


By the way, if further we'd like to achieve a fine-grained process control 
while using BFD to verfiy or detect path MTU, with the cost of a more complex 
extention to BFD, then draft-mirmin-bfd-extended potentially can provide such a 
solution.






Best Regards,


Xiao Min



原始邮件



发件人：ReshadRahman(rrahman) 
收件人：rtg-bfd@ietf.org ;
日 期 ：2019年09月09日 23:14
主 题 ：Re: WGLC for draft-ietf-bfd-large-packets




BFD WG, reminder that WGLC is ongoing for this document.


 


Regards,


Reshad.


 



From: Rtg-bfd  on behalf of "Reshad Rahman (rrahman)" 

Date: Tuesday, August 27, 2019 at 12:34 PM
To: "rtg-bfd@ietf.org" 
Subject: WGLC for draft-ietf-bfd-large-packets



 


BFD WG,


 


As was mentioned at IETF105, this document is stable and there was an interop 
test done between FRR and Junos VMX.


 


Please provide comments/feedback on the document. The deadline for last call is 
September 13th.


 


Regards,


Reshad & Jeff.

Re:BFD Echo mode coverage in BFD for VXLAN

[xiao.min2]

Hi Jeff and Reshad,






From my personal perspective, I don't think we should require BFD for VxLAN to 
support Echo mode, because as I know, although the final standard is still on 
the way, many vendors including my company have already implemented BFD for 
VxLAN, and it seems that works fine, there is no request from them on Echo 
mode, which in my view is a lightweight BFD tool used to substitute a 
relatively more complex BFD implementation.






Best Regards,


Xiao Min



原始邮件



发件人：JeffreyHaas 
收件人：rtg-bfd@ietf.org ;
日 期 ：2019年09月11日 01:49
主 题 ：Re: BFD Echo mode coverage in BFD for VXLAN


[trimming headers]

Working Group,

While we're suspecting everyone is finishing up holidays, please take until
the end of this week to answer Reshad's question:  Should we require BFD for
vxlan to support Echo mode?

-- Jeff

On Thu, Aug 15, 2019 at 10:41:46PM +, Reshad Rahman (rrahman) wrote:
> Hi all,
> 
> It is up to the WG to decide whether echo support is desired for BFD over 
> VxLAN (any other BFD use-cases also).  Since this hasn’t been brought up in 
> the WG before, my take is that the WG isn’t interested in having echo for BFD 
> over VxLAN. So if anybody feels that we need echo support, please speak up 
> asap. Because it’s holiday season, let’s take 3 weeks instead of the usual 2, 
> so please respond by September 5th.
> 
> Regards,
> Reshad (co-chair hat).
> 
> From: Greg Mirsky 
> Date: Thursday, August 8, 2019 at 8:04 PM
> To: "Carlos Pignataro (cpignata)" 
> Cc: "rtg-bfd@ietf.org" , "bfd-cha...@ietf.org" 
> , Martin Vigoureux 
> Subject: Re: BFD Echo mode coverage in BFD for VXLAN
> Resent-From: 
> Resent-To: Jeffrey Haas , 
> Resent-Date: Thursday, August 8, 2019 at 8:04 PM
> 
> Dear All,
> I was pointed out that my previous e-mail asking for WG help to progress BFD 
> over VXLAN document by sharing opinions regarding coverage of the BFD Echo 
> mode may be overstepping the bounds of an Editor. I apologize, that was not 
> my intention. I'm asking WG Chairs to help to arrive at the conclusion of 
> this question in a reasonable time.
> 
> Regards,
> Greg
> 
> On Thu, Aug 8, 2019 at 4:06 PM Greg Mirsky 
> mailto:gregimir...@gmail.com>> wrote:
> Dear All,
> I have not set the when this poll closes. I hope that two weeks would be 
> sufficient time for the WG community to express their thoughts.
> 
> Dear Carlos,
> thank you for sharing your opinion on the scope of the document in regard to 
> BFD Echo mode. You've expressed support for exploring the applicability of 
> the BFD Echo mode. Would you support that effort by contributing some text, 
> if WG decides that documenting the applicability of the Echo mode in BFD over 
> VXLAN is useful?
> 
> Regards,
> Greg
> 
> 
> On Wed, Aug 7, 2019 at 6:18 PM Carlos Pignataro (cpignata) 
> mailto:cpign...@cisco.com>> wrote:
> Dear Greg,
> 
> The option of replacing the existing text for something more ambiguous and 
> implicit does not seem like progress in my humble opinion. The spec ends up 
> with the same capabilities, but the text is more obscure. I do not support 
> that option.
> 
> My recommendation for your consideration would be:
> 
>   1.  Explore if it is possible to run BFD Echo as a single-hop.
>   2.  If yes, add text supporting it.
>   3.  If no, add text explaining why not on technical grounds.
> 
> A less desirable option would be if the WG does not care about BFD Echo, to 
> explicitly keep it out of scope (not on technical grounds).
> 
> Best,
> 
> Carlos.
> 
> 
> On Aug 5, 2019, at 6:16 PM, Greg Mirsky 
> mailto:gregimir...@gmail.com>> wrote:
> 
> Dear All,
> in course of reviews of the draft, several times a question was asked about 
> the rationale for excluding BFD Echo from the scope of this document:
> 
> 7.  Echo BFD
> 
>Support for echo BFD is outside the scope of this document.
> Much appreciate your consideration of the following options:
> 
>   *   describe the applicability of BFD Echo in VXLAN environment in the 
> document;
>   *   remove Section 7 and clarify in the Introduction
> NEW TEXT:
> This specification describes procedures only for BFD Asynchronous mode.
> 
>   *   make no changes at all.
> Regards,
> Greg
>

Re:Working Group Last Call on BFD Authentication Documents (expiresSeptember 13, 2019)

[xiao.min2]

Hi all,







I support all the three drafts to be published. They're useful enhancements to 
base BFD protocol, short and well-written.






BRs,


Xiao Min










原始邮件



发件人：SantoshPK 
收件人：Ashesh Mishra ;
抄送人：rtg-bfd@ietf.org ;
日 期 ：2019年09月13日 01:10
主 题 ：Re: Working Group Last Call on BFD Authentication Documents 
(expiresSeptember 13, 2019)





I support all three documents. 



On Wed, Sep 11, 2019 at 9:22 AM Ashesh Mishra  wrote:





As author, I support all three drafts. 


On Sep 10, 2019, at 7:13 PM, Manav Bhatia  wrote:




I support all 3 documents.



On Tue, Aug 27, 2019 at 8:45 PM Jeffrey Haas  wrote:

Working Group,

As we discussed in Montreal at IETF-105, the last hang up on progressing the
authentication documents (thread copied below) was concerns on the IPR
against them.

The holder of the IPR believes their discloures are consistent with prior
IPR posted against the BFD suite of published RFCs.o

We are thus proceeding with the Working Group Last Call for these documents
You are encouraged to provide technical feedback for the contents of the
documents, which addresses providing stronger authentication on the BFD
protocol.  

Please indicate whether you believe these documents should be advanced to
the IESG for publication as RFCs.

-- Jeff and Reshad


On Tue, Jul 02, 2019 at 02:37:15PM -0400, Jeffrey Haas wrote:
> Working Group,
> 
> A followup on this item.
> 
> Currently, the status is identical to that which was last posted.  Mahesh
> did make contact with Ciena IPR holders regarding the state of the license.
> It is their belief that their disclosure is consistent with similar IPR
> filed against BFD.  Citing two similar ones:
> 
> https://datatracker.ietf.org/ipr/516/
> https://datatracker.ietf.org/ipr/1419/
> 
> It also appears to be their belief that the current wording doesn't require
> that a license fee is due.  However, this is private commentary.
> 
> At this point, my recommendation to the working group is we decide if we'll
> proceed with the publication process.  Let's use this time prior to IETF 105
> to discuss any pending issues on these documents.
> 
> -- Jeff
> 
> On Sat, Feb 16, 2019 at 12:07:40PM -0500, Jeffrey Haas wrote:
> > Working Group,
> > 
> > On March 28, 2018, we started Working Group Last Call on the following 
> > document
> > bundle:
> > 
> >   draft-ietf-bfd-secure-sequence-numbers
> >   draft-ietf-bfd-optimizing-authentication
> >   draft-ietf-bfd-stability
> > 
> > The same day, Mahesh Jethanandani acknowledged there was pending IPR
> > declarations against these drafts.  An IPR declaration was finally posted on
> > November 1, 2018.  In particular, it notes a patent.  The licenseing is
> > RAND.  
> > 
> > https://datatracker.ietf.org/ipr/3328/
> > 
> > In the time since the WGLC was requested, there were a number of technical
> > comments made on these drafts.  It's my belief that all substantial
> > technical comments had been addressed in the last posted version of these
> > documents.  Note that there was one lingering comment about Yang
> > considerations for the BFD module with regard to enabling this optimized
> > authentication mode which can be dealt with separably.
> > 
> > The chairs did not carry out a further consensus call to ensure that there
> > are no further outstanding technical issues.
> > 
> > On November 21, Greg Mirsky indicated an objection to progressing the
> > document due to late disclosure.
> > 
> > https://mailarchive.ietf.org/arch/msg/rtg-bfd/u8rvWwvDWRKI3jseGHecAB9WtDo
> > 
> > Since we are a little over a month prior to the upcoming IETF 104, this
> > seems a good time to try to decide how the Working Group shall finish this
> > work.  Since we are meeting in Prague, this may progress to microphone
> > conversation.
> > 
> > For the moment, the chairs' perceived status of the documents are:
> > - No pending technical issues with the documents with one known issue.
> > - Concerns over late disclosure of IPR.
> > - No solid consensus from the Working Group that we're ready to proceed.
> >   This part may be covered by a future consensus call, but let's hear list
> >   discussion first.
> > 
> > -- Jeff

Re:BFD Echo mode coverage in BFD for VXLAN

[xiao.min2]

Hi Jeff,






I talked to implementor of my company, and I got the feedback that the 
provision of peer ip address is necessary, that means different ip address can 
be provisioned to different BFD session. As to VNI, there is no restriction on 
which VNI to choose. I guess this behavior is compiant with the current version 
of the draft.






Best Regards,


Xiao Min





原始邮件



发件人：JeffreyHaas 
收件人：肖敏10093570;
抄送人：rtg-bfd@ietf.org ;
日 期 ：2019年09月12日 00:52
主 题 ：Re: BFD Echo mode coverage in BFD for VXLAN




Xiam Min,

On Wed, Sep 11, 2019 at 12:01:11PM +0800, xiao.m...@zte.com.cn wrote:
> From my personal perspective, I don't think we should require BFD for
> VxLAN to support Echo mode, because as I know, although the final standard
> is still on the way, many vendors including my company have already
> implemented BFD for VxLAN, and it seems that works fine, there is no
> request from them on Echo mode, which in my view is a lightweight BFD tool
> used to substitute a relatively more complex BFD implementation.

Thanks for your commentary.

Also, as an implementor, does your implementation's bootstrapping for BFD
sessions follow the text that is in the current version of the
internet-draft?  There is some continuing debate holding up last call
comments on this point.

-- Jeff

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Thanks for your comments.


Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over 
Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame over 
Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?






Best Regards,


Xiao Min










原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 08:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




___
nvo3 mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



>>>

Some people may argue that all Tenant Systems connecting to the same Virtual 
Network MUST share one VAP, if that's true, then VAP1 and VAP3 should merge 
into one VAP and my explanation doesn't work. Copying to NVO3 WG to involve 
more experts, hope for your clarifications and comments.  


>>>



I would be one of those that would argue that they MUST share on VAP if they 
connect to the same Virtual Network.  IMO, the NVO3 arch doc should have been 
clearer about this.


Thanks,
Anoop




On Tue, Sep 24, 2019 at 7:40 PM  wrote:



Hi Santosh,






With regard to the question whether we should allow multiple BFD sessions for 
the same VNI or not, IMHO we should allow it, more explanation as follows...


Below is a figure derived from figure 2 of RFC8014 (An Architecture for 
Data-Center Network Virtualization over Layer 3 (NVO3)).




 | Data Center Network (IP) |
 | |
 +-+
 | |
 | Tunnel Overlay |
 ++-+ +-++
 | +--+---+ | | +---+--+ |
 | | Overlay Module | | | | Overlay Module | |
 | +-++ | | +-++ |
 | | | | | |
 NVE1 | | | | | | NVE2
 | ++---+ | | ++---+ |
 | |VNI1 VNI2 VNI1 | | | | VNI1 VNI2 VNI1 | |
 | +-+-++---+ | | +-+-+-+--+ |
 |VAP1| VAP2| | VAP3 | |VAP1| VAP2| | VAP3|
 ++-++--+ ++-+-+-+
 | | | | | |
 | | | | | |
 | | | | | |
 ---+-++---+-+-+---
 | | | Tenant | | |
 TSI1 | TSI2| | TSI3 TSI1| TSI2| |TSI3
 +---+ +---+ +---+ +---+ +---+ +---+
 |TS1| |TS2| |TS3| |TS4| |TS5| |TS6|
 +---+ +---+ +---+ +---+ +---+ +---+
To my understanding, the BFD sessions between NVE1 and NVE2 are actually 
initiated and terminated at VAP of NVE.


If the network operator want to set up one BFD session between VAP1 of NVE1 and 
VAP1of NVE2, at the same time another BFD session between VAP3 of NVE1 and VAP3 
of NVE2, although the two BFD sessions are for the same VNI1, I believe it's 
reasonable, so that's why I think we should allow it.






Of course, in RFC8014 it also says:

"Note that two different Tenant Systems (and TSIs) attached to a common NVE can 
share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect to the same 
Virtual Network."
Some people may argue that all Tenant Systems connecting to the same Virtual 
Network MUST share one VAP, if that's true, then VAP1 and VAP3 should merge 
into one VAP and my explanation doesn't work. Copying to NVO3 WG to involve 
more experts, hope for your clarifications and comments.






Best Regards,


Xiao Min

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Joel,






Thanks for your comments.


I don't think the VNI could own IP address and MAC address, if the BFD messages 
are originated and terminated at the VNI, then what addresses would be used by 
the BFD messages?


As to the VAP, RFC8014 defines it as below:


"On the NVE side, a VAP is a logical network port (virtual or physical) into a 
specific virtual network."
I interpret this definition as that the VAP could own IP address and MAC 
address, so I tend to believe the BFD messages are originated and terminated at 
the VAP.






p.s. I trimmed this mail to meet the size limit, my last mail is too big, which 
results in a warning from rtg-bfd-ow...@ietf.org.






Best Regards,



Xiao Min



原始邮件



发件人：JoelM.Halpern 
收件人：肖敏10093570;
抄送人：rtg-bfd@ietf.org ;n...@ietf.org 
;tsrid...@vmware.com ;bfd-cha...@ietf.org 
;
日 期 ：2019年09月25日 11:00
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


As far as I can tell, the current document we have in front of us is 
explicit that the messages are originated and terminated at the VNI.  If 
you want some other behavior, then we need a document that describes 
that behaviors.

Yours,
Joel

On 9/24/2019 10:39 PM, xiao.m...@zte.com.cn wrote:
> Hi Santosh,
> 
> 
> With regard to the question whether we should allow multiple BFD 
> sessions for the same VNI or not, IMHO we should allow it, more 
> explanation as follows.
> 
> Below is a figure derived from figure 2 of RFC8014 (An Architecture for 
> Data-Center Network Virtualization over Layer 3 (NVO3)).
> 
>  | Data Center Network (IP)|
>  | |
>  +-+
>   |   |
>   |   Tunnel Overlay  |
>  ++-+   +-++
>  | +--+---+ |   | +---+--+ |
>  | |  Overlay Module  | |   | |  Overlay Module  | |
>  | +-++ |   | +-++ |
>  |   |  |   |   |  |
>   NVE1   |   |  |   |   |  | NVE2
>  |  ++---+  |   |  ++---+  |
>  |  |VNI1 VNI2  VNI1 |  |   |  | VNI1 VNI2 VNI1 |  |
>  |  +-+-++---+  |   |  +-+-+-+--+  |
>  |VAP1| VAP2|| VAP3 |   |VAP1| VAP2| | VAP3|
>  ++-++--+   ++-+-+-+
>   | ||   | | |
>   | ||   | | |
>   | ||   | | |
>---+-++---+-+-+---
>   | || Tenant| | |
>  TSI1 | TSI2|| TSI3  TSI1| TSI2| |TSI3
>  +---+ +---+ +---+ +---+ +---+   +---+
>  |TS1| |TS2| |TS3| |TS4| |TS5|   |TS6|
>  +---+ +---+ +---+ +---+ +---+   +---+
> 
> To my understanding, the BFD sessions between NVE1 and NVE2 are actually 
> initiated and terminated at VAP of NVE.
> 
> If the network operator want to set up one BFD session between VAP1 of 
> NVE1 and VAP1of NVE2, at the same time another BFD session between VAP3 
> of NVE1 and VAP3 of NVE2, although the two BFD sessions are for the same 
> VNI1, I believe it's reasonable, so that's why I think we should allow it.
> 
> 
> Of course, in RFC8014 it also says:
> 
> "Note that two different Tenant Systems (and TSIs) attached to a common NVE 
> can share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect to 
> the same Virtual Network."
> 
> Some people may argue that all Tenant Systems connecting to the same 
> Virtual Network MUST share one VAP, if that's true, then VAP1 and VAP3 
> should merge into one VAP and my explanation doesn't work. Copying to 
> NVO3 WG to involve more experts, hope for your clarifications and comments.
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> 原始邮件
> *发件人：*SantoshPK 
> *收件人：*Greg Mirsky ;
> *抄送人：*draft-ietf-bfd-vx...@ietf.org 
> ;Dinesh Dutt ;rtg-bfd 
> WG ;Joel M. Halpern ;T. Sridhar 
> ;bfd-cha...@ietf.org ;
> *日 期 ：*2019年09月23日 05:39
> *主 题 ：**Re: BFD over VXLAN: Trapping BFD Control packet at VTEP*
> Greg,
>  Please see inline reply tagged [SPK]. I have added text requested.
> 
> Thanks
> Santosh P K
> 
> On Fri, Aug 16, 2019 at 4:59 AM Greg Mirsky  > wrote:
> 
> Hi Santosh,
> thank you for your comments. Please find my notes in-lined and
> tagged GIM>>.
> 
> Regards,
> Greg
> 
> On Tue, Aug 13, 2019 at 10:24 PM Santosh P K
> mailto:santosh.pallaga...@gmail.com>>
> wrote:
> 
> Greg,
>  

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ MPLS Label Stack ~ M
 | | P
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
 | | S
 | |
 ~ Payload ~ P
 | | K
 | | T
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | FCS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Note that in NVO3 working group Greg and I have submitted an individual draft 
draft-xiao-nvo3-bfd-geneve, which is used to address BFD over Geneve.

The intention is to make the two drafts draft-ietf-bfd-vxlan and 
draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the 
identical mechanism for the common part of BFD over VxLAN Tunnel and BFD over 
Geneve Tunnel. For the common part, draft-xiao-nvo3-bfd-geneve would reference 
to draft-ietf-bfd-vxlan, and for the other part specific to Geneve, we'll 
define the specific mechanism in draft-xiao-nvo3-bfd-geneve.




Hope that clarifies.




Best Regards,

Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 23:16
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
I think we would need more detail around the use case below.  What does the 
MPLS packet over Tunnel look like?

Thanks,
Anoop




On Wed, Sep 25, 2019 at 11:37 PM  wrote:



Hi Anoop,






Thanks for your comments.


Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over 
Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame over 
Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?






Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 08:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


___
nvo3 mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



>>>

Some people may argue that all Tenant Systems connecting to the same Virtual 
Network MUST share one VAP, if that's true, then VAP1 and VAP3 should merge 
into one VAP and my explanation doesn't work. Copying to NVO3 WG to involve 
more experts, hope for your clarifications and comments.  


>>>

I would be one of those that would argue that they MUST share on VAP if they 
connect to the same Virtual Network.  IMO, the NVO3 arch doc should have been 
clearer about this.

Thanks,
Anoop



On Tue, Sep 24, 2019 at 7:40 PM  wrote:



Hi Santosh,






With regard to the question whether we should allow multiple BFD sessions for 
the same VNI or not, IMHO we should allow it, more explanation as follows...


Below is a figure derived from figure 2 of RFC8014 (An Architecture for 
Data-Center Network Virtualization over Layer 3 (NVO3)).




 | Data Center Network (IP) |
 | |
 +-+
 | |
 | Tunnel Overlay |
 ++-+ +-++
 | +--+---+ | | +---+--+ |
 | | Overlay Module | | | | Overlay Module | |
 | +-++ | | +-++ |
 | | | | | |
 NVE1 | | | | | | NVE2
 | ++---+ | | ++---+ |
 | |VNI1 VNI2 VNI1 | | | | VNI1 VNI2 VNI1 | |
 | +-+-++---+ | | +-+-+-+--+ |
 |VAP1| VAP2| | VAP3 | |VAP1| VAP2| | VAP3|
 ++-++--+ ++-+-+-+
 | | | | | |
 | | | | | |
 | | | | | |
 ---+-++---+-+-+---
 | | | Tenant | | |
 TSI1 | TSI2| | TSI3 TSI1| TSI2| |TSI3
 +---+ +---+ +---+ +---+ +---+ +---+
 |TS1| |TS2| |TS3| |TS4| |TS5| |TS6|
 +---+ +---+ +---+ +---+ +---+ +---+
To my understanding, the BFD sessions between NVE1 and NVE2 are actually 
initiated and terminated at VAP of NVE.


If the network operator want to set up one BFD session between VAP1 of NVE1 and 
VAP1of NVE2, at the same time another BFD session between VAP3 of NVE1 and VAP3 
of NVE2, although the two BFD sessions are for the same VNI1, I believe it's 

Re:IETF-106 agenda?

[xiao.min2]

Hi Jeff,






I could be one minutes taker if no others experienced volunteered.







Best Regards,


Xiao Min









原始邮件



发件人：JeffreyHaas 
收件人：rtg-bfd@ietf.org ;
抄送人：Reshad Rahman (rrahman) ;
日 期 ：2019年11月10日 03:28
主 题 ：Re: IETF-106 agenda?




Working Group,

We will be attempting to meet at IETF-106.  There's just enough business to
discuss to warrant using our time slot.

Note as below: We do not currently have a minutes taker.  If we do not have
one (ideally volunteering ahead of time) by meeting start time, we will
suspend without a meeting.

The authors of BFD for vxlan are requested to prepare slides covering
changes since the last IETF and a summary of the rather energetic discussion
we've had since that meeting.  Additionally, please summarize the open
issues since we have a few still being discussed on the list.

Please recall that BFD is meeting on Tuesday.  Please send me your slides by
Sunday.

-

Current targeted agenda:

Chairs update:
  5 mins - Jeff Haas

BFD for vxlan: 
  15 minutes - TBD

BFD for Large Packets:
  5 minutes - Jeff

BFD Demand Mode:
  10 minutes - Greg

Using One-Arm BFD in Cloud Network:
  10 minutes


-- Jeff


On Fri, Nov 01, 2019 at 02:15:35PM -0400, Jeffrey Haas wrote:
> Working Group,
> 
> A session request had gone in for IETF 106 to accommodate the need for a
> possible session.  The agenda, to this point, had been left as an open
> question primarily to accommodate need to close on lingering questions in
> active work.  In particular, this was for two items:
> 
> - BFD for vxlan
> - BFD for Large Packets
> 
> (For transparency, I am an author on BFD for large packets)
> 
> As of this afternoon, we seem to have drafts submitted that cover the known
> open issues on both of these drafts.  In particular, the work to get us to
> the latest draft for the vxlan document took over 150 messages.
> 
> If BFD meets, agenda time was primarily reserved to reconcile open issues on
> these documents.
> 
> Discussion on BFDv2 is currently deferred for next IETF to focus the Working
> Group's limited attention on closing open work.
> 
> That said, if we have other topics to consider, please submit them for
> consideration.  If we have no such topics, and the discussion on the above
> two drafts seems likely to conclude well over e-mail, we may consider
> canceling the session.
> 
> As a final note, since Reshad is unable to make it to IETF-106, if we do
> decide to continue with our meeting, we will require the commitment for a
> minutes taker.  Reshad and I often will cover that for each other over the
> course of a session, but I won't be able to sustain that on my own.
> 
> -- Jeff, for the chairs.

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Yes, what I discussed with Anoop was on Greg's option #3.


Respecting BFD over VxLAN, option #2 and #3 both are ok to me, I have no 
preference.


Respecting BFD over Geneve, option #2 and #3 both are ok to me, although I 
personally prefer #3.







Best Regards,


Xiao Min










原始邮件



发件人：AnoopGhanwani 
收件人：Greg Mirsky ;
抄送人：Joel M. Halpern ;Jeffrey Haas 
;Santosh P K ;NVO3 
;draft-ietf-bfd-vx...@ietf.org 
;Dinesh Dutt ;rtg-bfd WG 
;T. Sridhar ;肖敏10093570;Yes
日 期 ：2019年10月23日 07:05
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP





Greg,

I think the draft is fine as is.


I discussion with Xiao Min was about #3 and I see that as unnecessary until we 
have a draft that explains why that is needed in the context of the NVO3 
architecture.


Anoop




On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky  wrote:


Hi Anoop, et al.,I agree with your understanding of what is being defined in 
the current version of the BFD over VxLAN specification. But, as I understand, 
the WG is discussing the scope before the WGLC is closed. I believe there are 
three options:
single BFD session between two VTEPs

single BFD session per VNI between two VTEPs

multiple BFD sessions per VNI between two VTEPs

The current text reflects #2. Is WG accepts this scope? If not, which option WG 
would accept?



Regards,
Greg




On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani  wrote:



I concur with Joel's assessment with the following clarifications.

The current document is already capable of monitoring multiple VNIs between 
VTEPs.


The issue under discussion was how do we use BFD to monitor multiple VAPs that 
use the same VNI between a pair of VTEPs.  The use case for this is not clear 
to me, as from my understanding, we cannot have a situation with multiple VAPs 
using the same VNI--there is 1:1 mapping between VAP and VNI.


Anoop




On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern  wrote:

 From what I can tell, there are two separate problems.
The document we have is a VTEP-VTEP monitoring document.  There is no 
need for that document to handle the multiple VNI case.
If folks want a protocol for doing BFD monitoring of things behind the 
VTEPs (multiple VNIs), then do that as a separate document.   The 
encoding will be a tenant encoding, and thus sesparate from what is 
defined in this document.

Yours,
Joel

On 10/21/2019 5:07 PM, Jeffrey Haas wrote:
> Santosh and others,
> 
> On Thu, Oct 03, 2019 at 07:50:20PM +0530, Santosh P K wrote:
>> Thanks for your explanation. This helps a lot. I would wait for more
>> comments from others to see if this what we need in this draft to be
>> supported based on that we can provide appropriate sections in the draft.
> 
> The threads on the list have spidered to the point where it is challenging
> to follow what the current status of the draft is, or should be.  :-)
> 
> However, if I've followed things properly, the question below is really the
> hinge point on what our encapsulation for BFD over vxlan should look like.
> Correct?
> 
> Essentially, do we or do we not require the ability to permit multiple BFD
> sessions between distinct VAPs?
> 
> If this is so, do we have a sense as to how we should proceed?
> 
> -- Jeff
> 
> [context preserved below...]
> 
>> Santosh P K
>>
>> On Wed, Sep 25, 2019 at 8:10 AM  wrote:
>>
>>> Hi Santosh,
>>>
>>>
>>> With regard to the question whether we should allow multiple BFD sessions
>>> for the same VNI or not, IMHO we should allow it, more explanation as
>>> follows.
>>>
>>> Below is a figure derived from figure 2 of RFC8014 (An Architecture for
>>> Data-Center Network Virtualization over Layer 3 (NVO3)).
>>>
>>>  | Data Center Network (IP)|
>>>  | |
>>>  +-+
>>>   |   |
>>>   |   Tunnel Overlay  |
>>>  ++-+   +-++
>>>  | +--+---+ |   | +---+--+ |
>>>  | |  Overlay Module  | |   | |  Overlay Module  | |
>>>  | +-++ |   | +-++ |
>>>  |   |  |   |   |  |
>>>   NVE1   |   |  |   |   |  | NVE2
>>>  |  ++---+  |   |  ++---+  |
>>>  |  |VNI1 VNI2  VNI1 |  |   |  | VNI1 VNI2 VNI1 |  |
>>>  |  +-+-++---+  |   |  +-+-+-+--+  |
>>>  |VAP1| VAP2|| VAP3 |   |VAP1| VAP2| | VAP3|
>>>  ++-++--+   ++-+-+-+
>>>   | ||   | | |
>>>   | ||   | | |
>>>   | ||   | |  

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I illustrated 
would be used.






Best Regards,


Xiao Min










原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年09月28日 05:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP






Hi Xiao Min,

Thanks for the details about the encap but the use case is not clear.  It might 
help if you explain why its necessary to map a physical Ethernet port and/or 
802.1Q VLAN to the same VNI as an MPLS packet without an L2 header.


Thanks,
Anoop




On Thu, Sep 26, 2019 at 7:50 PM  wrote:



Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ MPLS Label Stack ~ M
 | | P
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
 | | S
 | |
 ~ Payload ~ P
 | | K
 | | T
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | FCS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Note that in NVO3 working group Greg and I have submitted an individual draft 
draft-xiao-nvo3-bfd-geneve, which is used to address BFD over Geneve.

The intention is to make the two drafts draft-ietf-bfd-vxlan and 
draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the 
identical mechanism for the common part of BFD over VxLAN Tunnel and BFD over 
Geneve Tunnel. For the common part, draft-xiao-nvo3-bfd-geneve would reference 
to draft-ietf-bfd-vxlan, and for the other part specific to Geneve, we'll 
define the specific mechanism in draft-xiao-nvo3-bfd-geneve.




Hope that clarifies.




Best Regards,

Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 23:16
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
I think we would need more detail around the use case below.  What does the 
MPLS packet over Tunnel look like?

Thanks,
Anoop




On Wed, Sep 25, 2019 at 11:37 PM  wrote:



Hi Anoop,






Thanks for your comments.


Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over 
Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame over 
Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?






Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 08:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


___
nvo3 mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3



>>>

Some people may argue that all Tenant Systems connecting to the same Virtual 
Network MUST share one VAP, if that's true, then VAP1 and VAP3 should merge 
into one VAP and my explanation doesn't work. Copying to NVO3 WG to involve 
more experts, hope for your clarifications and comments.  


>>>

I would be one of those that would argue that they MUST share on VAP if they 
connect to the same Virtual Network.  IMO, the NVO3 arch doc should have been 
clearer about this.

Thanks,
Anoop



On Tue, Sep 24, 2019 at 7:40 PM  wrote:



Hi Santosh,






With regard to the question whether we should allow multiple BFD sessions for 
the same VNI or not, IMHO we should allow it, more explanation as follows...


Below is a figure derived from figure 2 of RFC8014 (An Architecture for 
Data-Center Network Virtualization over Layer 3 (NVO3)).




 | Data Center Network (IP) |
 | |
 +-+
 | |
 | Tunnel Overlay |
 ++-+ 

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Normally, it is. While Tenant Systems connect to NVE through IP routing network 
or MPLS forwarding network, it is not.






Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++




Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月08日 12:15
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Is there a draft that describes MPLS over Geneve?  It sounds like the NVE is an 
MPLS router in this case and if you're using the same VNI as you switch MPLS, 
then it's a one-armed router.  That doesn't change how BFD needs to be run 
between NVEs.

Anoop




On Mon, Oct 7, 2019 at 7:28 PM  wrote:


Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I illustrated 
would be used.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年09月28日 05:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Thanks for the details about the encap but the use case is not clear.  It might 
help if you explain why its necessary to map a physical Ethernet port and/or 
802.1Q VLAN to the same VNI as an MPLS packet without an L2 header.

Thanks,
Anoop




On Thu, Sep 26, 2019 at 7:50 PM  wrote:


Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ 

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






Please see my response inline with [XM].



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 15:47
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


___
nvo3 mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


Hi Xiao Min,
In those cases, the term "VN" is used to talk about multiple IP interfaces in a 
VRF.  The different interfaces would have to be different VNIs.

[XM] To be clear, I interpret VNI as Virtual Network Identifier that should be 
present within VxLAN/Geneve header. Do you mean in the case multiple Tenant 
Systems connect to multiple NVEs through IP routing network, different NVEs 
must encapsulate different Virtual Network Identifiers?


In the mixed case (with MPLS and L2 hitting the NVE at different VAPs), I'm not 
sure how it would work in the same VNI.  If you think it's important, I think 
it may be worth writing it up.  If there's enough merit in the use case, we can 
figure out how to run multiple BFD sessions on the same VNI.

[XM] As to the mixed case, I don't know whether there's enough merit, I just 
raise it for discussion because it seems not being prohibited from the NVO3 
architecture point of view.




Anoop







Best Regards,


Xiao Min






On Wed, Oct 9, 2019 at 11:06 PM  wrote:


Hi Anoop,






Normally, it is. While Tenant Systems connect to NVE through IP routing network 
or MPLS forwarding network, it is not.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh...pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++




Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail...com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月08日 12:15
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Is there a draft that describes MPLS over Geneve?  It sounds like the NVE is an 
MPLS router in this case and if you're using the same VNI as you switch MPLS, 
then it's a one-armed router.  That doesn't change how BFD needs to be run 
between NVEs.

Anoop




On Mon, Oct 7, 2019 at 7:28 PM  wrote:


Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I 

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++




Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月08日 12:15
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Is there a draft that describes MPLS over Geneve?  It sounds like the NVE is an 
MPLS router in this case and if you're using the same VNI as you switch MPLS, 
then it's a one-armed router.  That doesn't change how BFD needs to be run 
between NVEs.

Anoop




On Mon, Oct 7, 2019 at 7:28 PM  wrote:


Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I illustrated 
would be used.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年09月28日 05:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Thanks for the details about the encap but the use case is not clear.  It might 
help if you explain why its necessary to map a physical Ethernet port and/or 
802.1Q VLAN to the same VNI as an MPLS packet without an L2 header.

Thanks,
Anoop




On Thu, Sep 26, 2019 at 7:50 PM  wrote:


Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ MPLS Label Stack ~ M
 | | P
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
 | | S
 | |
 ~ Payload ~ P
 | | K
 | | T
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | FCS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Note that in NVO3 working group Greg and I have submitted an individual draft 
draft-xiao-nvo3-bfd-geneve, which is used to address BFD over Geneve.

The intention is to make the two drafts draft-ietf-bfd-vxlan and 
draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the 
identical mechanism for 

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Joel,






I fully agree to your analysis.


One major difference between VxLAN and Geneve (or VxLAN-GPE) is that VxLAN 
doesn't support multi-protocol payload, and VxLAN only supports payload of 
Ethernet frame. Although VxLAN specification was developed outside NVO3 WG, I 
believe VxLAN may also fall within the NVO3 architecture, and we try to align 
"BFD for VxLAN" and "BFD for Geneve".







Best Regards,


Xiao Min










原始邮件



发件人：JoelM.Halpern 
收件人：Anoop Ghanwani ;肖敏10093570;
抄送人：n...@ietf.org ;draft-ietf-bfd-vx...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月09日 06:31
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




I will add that from the point of view of VxLAN 9which is the topic), I 
would expect the MPLS packet to arrive in an Ethernet frame, and for 
VxLAN to forward that Ethernet frame.  The VTEP would not seem to even 
need to be aware that the content is MPLS.

Yours,
Joel

On 10/8/2019 6:28 PM, Anoop Ghanwani wrote:
> Hi Xiao Min,
> 
> The picture doesn't have enough information to explain why they are in 
> the same VNI, and exactly how forwarding happens between the MPLS and 
> non-MPLS parts.
> 
> Anoop
> 
> On Tue, Oct 8, 2019 at 12:31 AM  > wrote:
> 
> Hi Anoop,
> 
> 
> I don't know such a draft that describes MPLS over Geneve, but I
> believe the following figure derived from figure 1 of RFC8014 would
> help, in the following figure Tenant System1, Tenant System2, Tenant
> System3 and Tenant System4 are assumed belonging to the same VNI, so
> two BFD sessions for the same VNI need to be run between NVE1 and NVE2.
> 
>  ++
> +| Tenant |
>   ( ' )  | System1|
>     ( MPLS ) ++
>  .  .  +--+-+ ( _ )
>  .  .--|NVE1|---+
>  .  .  ||
>  .  .  +--+-+
>  .  . |
>  .  L3 Overlay  .   ( ' )
>  .Network   . (Ethernet)
>  .  .   ( _ )
>  .  . |
>  ++
> || Tenant |
>   ++ | System2|
>   |NVE2| ++
>   ||+
>   ++|
> |   |
>   ( ' )   ( ' )
> ( MPLS )(Ethernet)
>   ( _ )   ( _ )
> |   |
> ++  ++
> | Tenant |  | Tenant |
> | System3|  | System4|
> ++  ++
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> 原始邮件
> *发件人：*AnoopGhanwani  >
> *收件人：*肖敏10093570;
> *抄送人：*Greg Mirsky  >;did...@gmail.com
>   >;draft-ietf-bfd-vx...@ietf.org
> 
>  >;n...@ietf.org
>   >;santosh.pallaga...@gmail.com
>   >;rtg-bfd WG  >;Joel M. Halpern  >;tsrid...@vmware.com
>   >;
> *日 期 ：*2019年10月08日 12:15
> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at
> VTEP*
> Hi Xiao Min,
> Is there a draft that describes MPLS over Geneve?  It sounds like
> the NVE is an MPLS router in this case and if you're using the same
> VNI as you switch MPLS, then it's a one-armed router.  That doesn't
> change how BFD needs to be run between NVEs.
> 
> Anoop
> 
> On Mon, Oct 7, 2019 at 7:28 PM  > wrote:
> 
> Hi Anoop,
> 
> 
> Sorry for the late response, I just come back from vacation.
> 
> The use case is that the network between the VM and the NVE is
> an MPLS network, within which the packet is forwarded basing on
> MPLS label, but not Ethernet MAC address and/or 802.1Q VLAN.
> When two such kind of MPLS networks need to communicate with
> each other, through a Geneve tunnel, the encap I illustrated
> would be used.
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> 原始邮件
> *发件人：*AnoopGhanwani  >
> *收件人：*肖敏10093570;
> *抄送人：*Greg Mirsky  >;did...@gmail.com
>    

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++




Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月08日 12:15
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
Is there a draft that describes MPLS over Geneve?  It sounds like the NVE is an 
MPLS router in this case and if you're using the same VNI as you switch MPLS, 
then it's a one-armed router.  That doesn't change how BFD needs to be run 
between NVEs.

Anoop




On Mon, Oct 7, 2019 at 7:28 PM  wrote:


Hi Anoop,






Sorry for the late response, I just come back from vacation.


The use case is that the network between the VM and the NVE is an MPLS network, 
within which the packet is forwarded basing on MPLS label, but not Ethernet MAC 
address and/or 802.1Q VLAN. When two such kind of MPLS networks need to 
communicate with each other, through a Geneve tunnel, the encap I illustrated 
would be used.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年09月28日 05:36
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Thanks for the details about the encap but the use case is not clear.  It might 
help if you explain why its necessary to map a physical Ethernet port and/or 
802.1Q VLAN to the same VNI as an MPLS packet without an L2 header.

Thanks,
Anoop




On Thu, Sep 26, 2019 at 7:50 PM  wrote:


Hi Anoop,






Due to the fact that a variety of Tunnels could be used under the NVO3 
architecture, as an example, below figure illustrates the format of MPLS packet 
over Geneve Tunnel.




 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer Ethernet Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer IPvX Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Outer UDP Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 ~ Geneve Header ~
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | | |
 ~ MPLS Label Stack ~ M
 | | P
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
 | | S
 | |
 ~ Payload ~ P
 | | K
 | | T
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
 | FCS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Note that in NVO3 working group Greg and I have submitted an individual draft 
draft-xiao-nvo3-bfd-geneve, which is used to address BFD over Geneve.

The intention is to make the two drafts draft-ietf-bfd-vxlan and 
draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the 
identical mechanism for the common part of BFD over VxLAN Tunnel and BFD over 
Geneve Tunnel. For the common part, draft-xiao-nvo3-bfd-geneve would reference 
to draft-ietf-bfd-vxlan, and for the other part specific to Geneve, we'll 
define the specific mechanism in draft-xiao-nvo3-bfd-geneve.




Hope that clarifies.




Best Regards,

Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh.pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com 
;bfd-cha...@ietf.org ;
日 期 ：2019年09月26日 23:16
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
I think we would need more detail around the use case below.  What does the 
MPLS packet over Tunnel look like?

Thanks,
Anoop




On Wed, Sep 25, 2019 at 11:37 PM  wrote:


Hi Anoop,






Thanks for your comments.


Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet over 
Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e. MAC-Frame over 
Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share one VAP?






Best 

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,






In the use case illustrated in below figure, do you think Tenant System1 and 
Tenant System2 can be within the same VN? do you think NVE1 and NVE2 can 
encapsulate the same VNI in the packets sent from Tenant System1 and Tenant 
System2?


 
 . . +--+-+
 . .--|NVE1|
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network .(IP Routing)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System1|
 |NVE2| ++
 | |
 ++
 |
 ( ' )
 (IP Routing)
 ( _ )
 |
 ++
 | Tenant |
 | System2|
 ++




Best Regards,


Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月11日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP




Hi Xiao Min,
Can you provide more detail on your scenario?  I'm having trouble figuring it 
out from the description below.  I need to know what subnets the tenants are in.

Anoop




On Thu, Oct 10, 2019 at 5:00 AM  wrote:


Hi Anoop,






Please see my response inline with [XM].



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 15:47
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

___
nvo3 mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


Hi Xiao Min,
In those cases, the term "VN" is used to talk about multiple IP interfaces in a 
VRF.  The different interfaces would have to be different VNIs.

[XM] To be clear, I interpret VNI as Virtual Network Identifier that should be 
present within VxLAN/Geneve header. Do you mean in the case multiple Tenant 
Systems connect to multiple NVEs through IP routing network, different NVEs 
must encapsulate different Virtual Network Identifiers?


In the mixed case (with MPLS and L2 hitting the NVE at different VAPs), I'm not 
sure how it would work in the same VNI.  If you think it's important, I think 
it may be worth writing it up.  If there's enough merit in the use case, we can 
figure out how to run multiple BFD sessions on the same VNI.

[XM] As to the mixed case, I don't know whether there's enough merit, I just 
raise it for discussion because it seems not being prohibited from the NVO3 
architecture point of view.




Anoop







Best Regards,


Xiao Min






On Wed, Oct 9, 2019 at 11:06 PM  wrote:


Hi Anoop,






Normally, it is. While Tenant Systems connect to NVE through IP routing network 
or MPLS forwarding network, it is not.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh...pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, Tenant System2, Tenant System3 and Tenant System4 are 
assumed belonging to the same VNI, so two BFD sessions for the same VNI need to 
be run between NVE1 and NVE2.

 ++
 +| Tenant |
 ( ' ) | System1|
  ( MPLS ) ++
 . . +--+-+ ( _ )
 . .--|NVE1|---+
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network . (Ethernet)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System2|
 |NVE2| ++
 | |+
 ++ |
 | |
 ( ' ) ( ' )
 ( MPLS ) (Ethernet)
 ( _ ) ( _ )
 | |
 ++ ++
 | Tenant | | Tenant |
 | System3| | System4|
 ++ ++

Re:[nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

[xiao.min2]

Hi Anoop,




Thanks for your reply to my question.

It's clear that we have different views on this case, could you please direct 
me to the text(if any) of RFC/draft that supports your statement?

Any thoughts from others?




Best Regards,

Xiao Min



原始邮件



发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月12日 00:00
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Unless they are in the same broadcast domain (which does not appear to the 
case) they would not be in the same VNI.

Anoop




On Fri, Oct 11, 2019 at 2:18 AM  wrote:


Hi Anoop,






In the use case illustrated in below figure, do you think Tenant System1 and 
Tenant System2 can be within the same VN? do you think NVE1 and NVE2 can 
encapsulate the same VNI in the packets sent from Tenant System1 and Tenant 
System2?


 
 . . +--+-+
 . .--|NVE1|
 . . | |
 . . +--+-+
 . . |
 . L3 Overlay . ( ' )
 . Network .(IP Routing)
 . . ( _ )
 . . |
  ++
 | | Tenant |
 ++ | System1|
 |NVE2| ++
 | |
 ++
 |
 ( ' )
 (IP Routing)
 ( _ )
 |
 ++
 | Tenant |
 | System2|
 ++




Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月11日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Can you provide more detail on your scenario?  I'm having trouble figuring it 
out from the description below.  I need to know what subnets the tenants are in.

Anoop




On Thu, Oct 10, 2019 at 5:00 AM  wrote:


Hi Anoop,






Please see my response inline with [XM].



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 15:47
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

___
nvo3 mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


Hi Xiao Min,
In those cases, the term "VN" is used to talk about multiple IP interfaces in a 
VRF.  The different interfaces would have to be different VNIs.

[XM] To be clear, I interpret VNI as Virtual Network Identifier that should be 
present within VxLAN/Geneve header. Do you mean in the case multiple Tenant 
Systems connect to multiple NVEs through IP routing network, different NVEs 
must encapsulate different Virtual Network Identifiers?


In the mixed case (with MPLS and L2 hitting the NVE at different VAPs), I'm not 
sure how it would work in the same VNI.  If you think it's important, I think 
it may be worth writing it up.  If there's enough merit in the use case, we can 
figure out how to run multiple BFD sessions on the same VNI.

[XM] As to the mixed case, I don't know whether there's enough merit, I just 
raise it for discussion because it seems not being prohibited from the NVO3 
architecture point of view.




Anoop







Best Regards,


Xiao Min






On Wed, Oct 9, 2019 at 11:06 PM  wrote:


Hi Anoop,






Normally, it is. While Tenant Systems connect to NVE through IP routing network 
or MPLS forwarding network, it is not.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-vx...@ietf.org ;n...@ietf.org 
;rtg-bfd WG ;
日 期 ：2019年10月10日 05:33
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP



Hi Xiao Min,
Normally, I think of a VNI as a broadcast domain.  The only way I can make 
sense of the picture below is to have a separate VNI for each MPLS interface on 
the NVE.

Anoop




On Tue, Oct 8, 2019 at 11:09 PM  wrote:


Hi Anoop,







In this use case there is no forwarding happens between the MPLS and non-MPLS 
parts, would this use case be prohibited?


If the answer is yes, then I agree that all Tenant Systems attached to a common 
NVE MUST share a VAP so long as they connect to the same VN, although in 
RFC8014 it uses "can" but not "MUST". As a result, we should not allow multiple 
BFD sessions for the same VNI between two NVEs.


If the answer is no, then we should allow multiple BFD sessions for the same 
VNI between two NVEs. I personally lean to this answer.






Best Regards,


Xiao Min



原始邮件


发件人：AnoopGhanwani 
收件人：肖敏10093570;
抄送人：Greg Mirsky ;did...@gmail.com 
;draft-ietf-bfd-vx...@ietf.org 
;n...@ietf.org 
;santosh...pallaga...@gmail.com 
;rtg-bfd WG ;Joel M. Halpern 
;tsrid...@vmware.com ;
日 期 ：2019年10月09日 06:28
主 题 ：Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP


Hi Xiao Min,
The picture doesn't have enough information to explain why they are in the same 
VNI, and exactly how forwarding happens between the MPLS and non-MPLS parts.

Anoop




On Tue, Oct 8, 2019 at 12:31 AM  wrote:


Hi Anoop,







I don't know such a draft that describes MPLS over Geneve, but I believe the 
following figure derived from figure 1 of RFC8014 would help, in the following 
figure Tenant System1, 

Request comments on draft-xiao-bfd-padding-alteration-00

[xiao.min2]

Hi BFD WG,






A new BFD individual draft has been submitted recently, link as below.



https://tools.ietf.org/html/draft-xiao-bfd-padding-alteration-00 


This short draft proposes the Padding Poll Sequence, to keep the BFD session up 
when BFD padding alters.






Your review and comments are much appreciated.






Best Regards,


Xiao Min

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

[xiao.min2]

Hi all,






I support WG adoption of this draft (as co-author).


At the same time, I support to change its status to Proposed Standard, and add 
tag of "Updates RFC5880".






Best Regards,


Xiao Min




原始邮件



发件人：JeffreyHaas 
收件人：rtg-bfd@ietf.org ;
日 期 ：2020年08月04日 21:04
主 题 ：Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August,2020)


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:IETF 108 candidate minutes

[xiao.min2]

Hi Jeff,






I think the candidate minutes reflect the discussion during the BFD session 
very well, and I have no suggestion for revision on it.


Just a comment w.r.t BFD for Geneve to test non-management VNI, we have been 
attempting to address the issues found by IESG discussion on BFD for VXLAN.


The latest draft can be found with below link.


https://tools.ietf.org/html/draft-xiao-nvo3-bfd-geneve-03 


Let's discuss it in more detail on NVO3 mailing list :-)






Best Regards,


Xiao Min



原始邮件



发件人：JeffreyHaas 
收件人：rtg-bfd@ietf.org ;
日 期 ：2020年07月31日 00:12
主 题 ：IETF 108 candidate minutes


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.

-

Fw:I-D Action: draft-ietf-bfd-unaffiliated-echo-02.txt

[xiao.min2]

BFD WG,

We've uploaded a new revision to address comments from Jeff.
Some editorial changes are incorporated too.
Looking forward to your further review and comments.

Best Regards,
Xiao Min

--原始邮件--
发件人：internet-dra...@ietf.org
收件人：i-d-annou...@ietf.org ;
抄送人：rtg-bfd@ietf.org;
日 期 ：2021年06月23日 10:38
主 题 ：I-D Action: draft-ietf-bfd-unaffiliated-echo-02.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   : Unaffiliated BFD Echo Function
Authors : Weiqiang Cheng
Ruixue Wang
Xiao Min
Reshad Rahman
Raj Chetan Boddireddy
Filename: draft-ietf-bfd-unaffiliated-echo-02.txt
Pages   : 10
Date: 2021-06-22
Abstract:
Bidirectional Forwarding Detection (BFD) is a fault detection
protocol that can quickly determine a communication failure between
two forwarding engines.  This document proposes a use of the BFD Echo
function where the local system supports BFD but the neighboring
system does not support BFD.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-02
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-unaffiliated-echo-02
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[xiao.min2]

Jeff,

I agree to your analysis.
In the current draft, I've tried to make the desired behavior clear, at the 
same time, reuse the already defined BFD procedure as much as possible.
As always, I'm open to any suggestions and comments. Although I disagree to a 
specific suggestion sometimes, the process of discussion is necessary and 
valuable.

Best Regards,
Xiao Min
--原始邮件--
发件人：JeffreyHaas
收件人：Greg Mirsky;
抄送人：肖敏10093570;rtg-bfd WG;draft-ietf-bfd-unaffiliated-e...@ietf.org;
日 期 ：2021年11月23日 06:10
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
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.
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

[xiao.min2]

Greg, Jeff,

It looks that you converge on comparison between S-BFD Echo and Unaffiliated 
Echo.
What I want to point out is, allowing using standalone BFD/S-BFD Echo without 
periodically transmitted BFD/S-BFD Control packets, doesn't mean it's 
Unaffiliated Echo.
In RFC 5880 section 3.2 the 4th paragraph, it says
"Since the Echo function is handling the task of detection, the rate of 
periodic transmission of Control packets may be reduced (in the case of 
Asynchronous mode) or eliminated completely (in the case of Demand mode)."

Best Regards,
Xiao Min
--原始邮件--
发件人：GregMirsky
收件人：Jeffrey Haas;
抄送人：肖敏10093570;rtg-bfd WG;draft-ietf-bfd-unaffiliated-e...@ietf.org;
日 期 ：2021年11月24日 05:17
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
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

[xiao.min2]

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.

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?

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.

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.

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?
XM>>> Make sense. I think we can make it a requirement instead of 
recommendation.

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?
XM>>> No change to the BFD state machine. As I understand it, it's DOWN state.

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.
XM>>> Is that possible an implementation uses IP five tuples to demultiplex the 
loopbacked packets? If not, I agree to change from SHOULD to MUST.

Now, I may have an alternative proposal that can produce the desired result and 
not require any update to RFC 

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

[xiao.min2]

Thank you Jeff! A very clear description on the core motivation and current 
situation.
>From the author's perspective, I'd like to remove the reference to BBF TR-146 
>if it's becoming a blocking issue instead of a supporting argument.

Best Regards,
Xiao Min
--原始邮件--
发件人：JeffreyHaas
收件人：肖敏10093570;
抄送人：gregimir...@gmail.com;rtg-bfd@ietf.org;draft-ietf-bfd-unaffiliated-e...@ietf.org;
日 期 ：2021年11月18日 22:29
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
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

[xiao.min2]

Jeff,

I have no objection to the comparison, please go on.
One thing I want to emphasize is that, whether DC use case (brought up by 
draft-wang-bfd-one-arm-use-case) or broadband access use case (brought up by 
BBF TR-146), the key requirement is that the peer system is totally 
BFD-Unaware, in other words, the peer system would never send or parse any BFD 
Control packets, from the very beginning.
Another thing is that the Unaffiliated BFD Echo can only work between the local 
system and its one-hop-away peer system.

Best Regards,
Xiao Min
--原始邮件--
发件人：JeffreyHaas
收件人：肖敏10093570;
抄送人：Greg Mirsky;rtg-bfd WG;draft-ietf-bfd-unaffiliated-e...@ietf.org;
日 期 ：2021年11月24日 20:32
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
Xiao Min,
BFD Echo, completely underspecified in RFC 5880, is fine with that lack of 
detail when it is paired with an Async session.
For the unaffiliated case and no Async session to help provide correlating 
activities, some of the work of Async will need to be done in the Echo stream 
itself.  These things would include:
- Security - why do I believe this is for my session?
- Session demultiplexing - why do I believe this is an Echo packet for one 
session instead of another?
The only option you have for Echo is "I can hear myself".  The question becomes 
what data you encode in there that covers at least those properties.
It's likely that some existing BFD Echo implementations already achieve this 
through proprietary means.  Some implementors may have chosen to simply encode 
a BFD Async packet in the Echo stream since they already have code that can 
deal with such packets.
If so, the question that needs answered is procedure for dealing with those 
packets.  We have several extensions to BFD that discusses ways that can be 
done.  This is the reason for comparison vs. existing mechanisms.
-- Jeff
> On Nov 23, 2021, at 10:36 PM,   
> wrote:
>
> Greg, Jeff,
>
> It looks that you converge on comparison between S-BFD Echo and Unaffiliated 
> Echo.
> What I want to point out is, allowing using standalone BFD/S-BFD Echo without 
> periodically transmitted BFD/S-BFD Control packets, doesn't mean it's 
> Unaffiliated Echo.
> In RFC 5880 section 3.2 the 4th paragraph, it says
> "Since the Echo function is handling the task of detection, the rate of 
> periodic transmission of Control packets may be reduced (in the case of 
> Asynchronous mode) or eliminated completely (in the case of Demand mode)."
>
> Best Regards,
> Xiao Min
> --原始邮件--
> 发件人：GregMirsky
> 收件人：Jeffrey Haas;
> 抄送人：肖敏10093570;rtg-bfd WG;draft-ietf-bfd-unaffiliated-e...@ietf.org;
> 日 期 ：2021年11月24日 05:17
> 主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
> 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 

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

[xiao.min2]

Jeff,

That's OK. I'll hold on for your further judgement.
Just to clarify, when this document's predecessor 
(draft-wang-bfd-one-arm-use-case-00) was brought up to IETF, the proponents 
didn't know any of BBF related prior art, that means their original work was 
not inspired by BBF TR-146. At that time, the proposed deployment scenario was 
DC network but not broadband access network, more specifically, BFD Echo 
running between DC-GW and VM.

Best Regards,
Xiao Min
--原始邮件--
发件人：JeffreyHaas
收件人：肖敏10093570;
抄送人：gregimir...@gmail.com;rtg-bfd@ietf.org;draft-ietf-bfd-unaffiliated-e...@ietf.org;
日 期 ：2021年11月19日 21:23
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
Xiao Min,
On Fri, Nov 19, 2021 at 10:15:08AM +0800, xiao.m...@zte.com.cn wrote:
> Thank you Jeff! A very clear description on the core motivation and current 
> situation.
> From the author's perspective, I'd like to remove the reference to BBF TR-146 
> if it's becoming a blocking issue instead of a supporting argument..
My recommendation is we leave that text alone for the time being.  Since the
feature is inspired by it, we'll likely want to discuss it in the document
long term - even if to contrast how it's both similar and different.
BBF as an organization may request us to remove the text, or perhaps offer
other positions on the document's fate.  We'll be sending a liaison
statement to BBF probably next week.  Thanks to Greg and Joel for motivating
this past-due bit of followup.
-- Jeff
>
> Best Regards,
> Xiao Min
> --原始邮件--
> 发件人：JeffreyHaas
> 收件人：肖敏10093570;
> 抄送人：gregimir...@gmail.com;rtg-bfd@ietf.org;draft-ietf-bfd-unaffiliated-e...@ietf.org;
> 日 期 ：2021年11月18日 22:29
> 主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
> 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

[xiao.min2]

Hi Greg,

Please see inline with [XM].

Best Regards,
Xiao Min
--原始邮件--
发件人：GregMirsky
收件人：肖敏10093570;
抄送人：draft-ietf-bfd-unaffiliated-e...@ietf.org;rtg-bfd WG;
日 期 ：2021年11月17日 23:48
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
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.
[XM] I don't think so. RFC 5880 has been updated by RFC 7419, RFC 7880 and RFC 
8562. Any IETF RFC can be updated or even obsoleted.

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.
[XM] To my understanding, "adjunct" implies BFD Echo is dependent, however 
Unaffiliated BFD Echo is independent, so this update is needed.

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.
[XM] As I said above, "adjunct" needs to be updated. In addition, I tend to 
agree it's a new BFD mode, however a new BFD mode looks a bit heavy to be 
documented, my proposal is to call it just "Unaffiliated BFD Echo", remove 
"function" from its name.

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 

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

[xiao.min2]

Jeff,

So, that's not new to everyone, great!
At this time, my proposal is to proceed with draft-ietf-bfd-unaffiliated-echo, 
publish it as planned.

Best Regards,
Xiao Min
--原始邮件--
发件人：JeffreyHaas
收件人：肖敏10093570;
抄送人：gregimir...@gmail.com;rtg-bfd@ietf.org;draft-ietf-bfd-unaffiliated-e...@ietf.org;
日 期 ：2021年11月25日 20:37
主 题 ：Re: Several questions about the draft-ietf-bfd-unaffiliated-echo
On Thu, Nov 25, 2021 at 11:03:16AM +0800, xiao.m...@zte.com.cn wrote:
> I have no objection to the comparison, please go on.
> One thing I want to emphasize is that, whether DC use case (brought up by 
> draft-wang-bfd-one-arm-use-case) or broadband access use case (brought up by 
> BBF TR-146), the key requirement is that the peer system is totally 
> BFD-Unaware, in other words, the peer system would never send or parse any 
> BFD Control packets, from the very beginning.
This has been consistent with everything I've seen over the last several
years and will be a fine requirement.
(I had been asked about a similar mechanism almost two years before someone
showed me the BBF document.)
> Another thing is that the Unaffiliated BFD Echo can only work between the 
> local system and its one-hop-away peer system.
For IPv4/IPv6 unicast, that's consistent with BFD Echo procedures.
-- Jeff

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

[xiao.min2]

Dear Ketan,

Thanks for your review and thoughtful comments.
Please see inline.

Original


From: KetanTalaulikar 
To: 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.

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 [I-D.wang-bfd-one-arm-use-case] describes another use case 
of the Unaffiliated BFD Echo."

Finally, is it normal or natural to expect server hosts to be able to "loop 
them back by normal IP forwarding"? Or does it require some additional/special 
capabilities to be turned ON those hosts as hosts don't do forwarding by 
default.
[XM]>>> As I know of a deployment, there is no need to turn ON those hosts. At 
the same time, it's feasible to have such a knob. Propose to add some text as 
below.
OLD
The method for provisioning device B to loop back BFD Unaffiliated Echo packets 
is outside the scope of this document.
NEW
There may be a knob to turn on/off the loopback of Unaffiliated BFD Echo 
packets at device B. The method for provisioning device B to loop back 
Unaffiliated BFD Echo packets is outside the scope of this document.


Best Regards,
Xiao Min

It would help if these aspects are clarified in the document.

Thanks,
Ketan



On Thu, Jul 6, 2023 at 7:50 AM  wrote:


 A New Internet-Draft is available from the on-line Internet-Drafts
 directories. This Internet-Draft is a work item of the Bidirectional
 Forwarding Detection (BFD) WG of the IETF.
 
Title   : Unaffiliated BFD Echo
Authors : Weiqiang Cheng
  Ruixue Wang
  Xiao Min
  Reshad Rahman
  Raj Chetan Boddireddy
Filename: draft-ietf-bfd-unaffiliated-echo-08.txt
Pages   : 12
Date: 2023-07-05
 
 Abstract:
Bidirectional Forwarding Detection (BFD) is a fault detection
protocol that can quickly determine a communication failure between
two forwarding engines.  This document proposes a use of the BFD Echo
where the local system supports BFD but the neighboring system does
not support BFD.  BFD Control packet and its processing procedures
can be executed over the BFD Echo port where the neighboring system
only loops packets back to the local system.
 
This document updates RFC 5880.
 
 The IETF datatracker status page for this Internet-Draft is:
 https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
 
 There is also an htmlized version available at:
 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-08
 
 A diff from the previous version is available at:
 https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-08
 
 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

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

[xiao.min2]

Hi Greg, Ketan,

Many thanks for the productive discussion.
Thank you Ketan for the newly suggested text, which looks good to me.
I've incorporated Ketan's new text into the -10 version just posted. Link as 
below.
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-10 

Cheers,
Xiao Min

Original


From: GregMirsky 
To: Ketan Talaulikar ;
Cc: 肖敏10093570;rtg-bfd@ietf.org 
;draft-ietf-bfd-unaffiliated-e...@ietf.org 
;
Date: 2023年09月29日 00:04
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-08


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 
;
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 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.
[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
 Please see inline with [XM-2]>>>.

Original

From: KetanTalaulikar 
To: 肖敏10093570;
Cc: draft-ietf-bfd-unaffiliated-e...@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 
;
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, 

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

[xiao.min2]

Hi Greg,

Thank you for the reply.
Please see inline with [XM-2]>>>.

Original


From: GregMirsky 
To: 肖敏10093570;
Cc: ketant.i...@gmail.com ;rtg-bfd@ietf.org 
;draft-ietf-bfd-unaffiliated-e...@ietf.org 
;
Date: 2023年09月28日 05:13
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-08



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 
;
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 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.
[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.
[XM-2]>>> I personally don't think the "liveness of a node" has any technical 
problem. At the same time, as I understand your comment, you think the liveness 
of a node is a bigger concept than what can be detected by the BFD Echo or BFD, 
which also makes sense to me in some extent. To avoid the potential confusion, 
I propose to change the text as below.
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 what this method monitors does not include the availability of a 
specific IP address at the neighboring device.

Cheers,
Xiao Min
¶
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
 Please see inline with [XM-2]>>>.

Original

From: KetanTalaulikar 
To: 肖敏10093570;
Cc: draft-ietf-bfd-unaffiliated-e...@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 
;
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 

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

[xiao.min2]

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 
;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 
;
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 [I-D.wang-bfd-one-arm-use-case] describes another use case 
of the Unaffiliated BFD Echo."







KT> This is OK. I was looking for some text (perhaps in Section 1) that says 
something on the lines of ... "The Unaffiliated BFD Echo functionality only 
monitors liveness of the node and does not monitor the availability of a 
specific IP address at that node." - I believe this is an important distinction 
from normal BFD operations that needs to be called out. Would you agree?
[XM-2]>>> Some text as you want was added to section 1.





Finally, is it normal or natural to expect server hosts to be able to "loop 
them back by normal IP forwarding"? Or does it require some additional/special 
capabilities to be turned ON those hosts as hosts don't do forwarding by 
default.
[XM]>>> As I know of a deployment, there is no need to turn ON those hosts. At 
the same time, it's feasible to have such a knob. Propose to add some text as 
below.
OLD
The method for provisioning device B to loop back BFD Unaffiliated Echo packets 
is outside the scope of this document.
NEW
There may be a knob to turn on/off the loopback of Unaffiliated BFD Echo 
packets at device B. The method for provisioning device B to loop back 
Unaffiliated BFD Echo packets is outside the scope of this document.









KT> This is not quite where I was going. Perhaps something on the following 
lines?
NEW:
BFD Unaffiliated Echo feature depends on device B performing IP forwarding 
(actually IP redirect) functionality. While such functionality may normally be 
expected to be supported on a router, it may not be enabled on a host by 
default. The method for provisioning device B to loop back BFD Unaffiliated 
Echo packets is outside the scope of this document.
[XM-2]>>> Accepted. 

Best Regards,
Xiao Min

Thanks,
Ketan






Best 

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

[xiao.min2]

Hi Greg,

Please see inline.

Original


From: GregMirsky 
To: Ketan Talaulikar ;
Cc: 肖敏10093570;rtg-bfd WG 
;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 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.
[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?

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
 Please see inline with [XM-2]>>>.

Original

From: KetanTalaulikar 
To: 肖敏10093570;
Cc: draft-ietf-bfd-unaffiliated-e...@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 
;
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 

Re: A missing read/write attribute in RFC 9314?

[xiao.min2]

Jeff,






Please see inline...






Best Regards,


Xiao Min



Original



From: JeffreyHaas 
To: Reshad Rahman ;
Cc: BFD WG ;Alexander Vainshtein 
;Nitsan Dolev ;Shell 
Nakash ;James Lian ;
Date: 2022年10月20日 20:52
Subject: Re: A missing read/write attribute in RFC 9314?



On Oct 19, 2022, at 3:24 PM, Jeffrey Haas  wrote:

I think what this work looks like is:1. Survey of implementations to see 
whether they do this behavior, and whattheir knob is, if so.


I have confirmed that Juniper's implementation does not support the behavior 
described in this thread.  When in the Up state, Juniper's BFD on LAG uses the 
discovered unicast MAC address.
Xiao Min reports that ZTE's implementation behaves similarly.

[XM]>>> I see the similarity is that there is no any knob, at the same time, it 
seems different destination MAC is selected. In ZTE's implementation, the 
dedicated multicast MAC is used, while in Juniper's implementation, the 
discovered unicast MAC is used. Then, my question is, would it be recognizable 
for Juniper node when receiving BFD control packet with dedicated multicast MAC 
from ZTE node?


It'd be good to get responses from Cisco, Huawei, and Nokia.

-- Jeff

Re: [EXTERNAL] Re: A missing read/write attribute in RFC 9314?

[xiao.min2]

Jeff, Sasha, Reshad, et al.,






Please see inline...






Best Regards,


Xiao Min



Original



From: JeffreyHaas 
To: Alexander Vainshtein ;
Cc: Reshad Rahman ;BFD WG ;Nitsan Dolev 
;Shell Nakash ;James Lian 
;
Date: 2022年10月20日 04:17
Subject: Re: [EXTERNAL] Re: A missing read/write attribute in RFC 9314?




Sasha,
 
On Wed, Oct 19, 2022 at 08:07:06PM +, Alexander Vainshtein wrote:
> And I have not encountered implementations by other vendors that support this 
> option (with or without the knob in question). My guess (FWIW) is that this 
> would make an implementation much more complicated while the benefits would 
> be minimal.
 
BFD on LAG was a contentious and fussy bit of RFC work.  Much of the earlier
headache about whether multicast or unicast MACs were to be involved had to
do with chip details.  However, I suspect as time has passed and it's become
a more common feature across the vendors, things may have stabilized.
 
> So I think that we indeed need a survey you have proposed.
 
I've internally enquired about this at Juniper.
 
A brief survey of some other implementations' manuals doesn't seem to
suggest any knob for this behavior.  It'd be good to get more formal
statement of compliance from these vendors.

[XM]>>> I've consulted my colleagues having implemented BFD on LAG at ZTE, only 
the dedicated multicast MAC is used and there is no any knob (also not 
suggested).


> If there are no implementations exercising optional behavior, deprecating it 
> in 7130 could be considered as well.
 
Absolutely.  That would be an appropriate errata response once we have some
data.

[XM]>>> Yes, it seems more appropriate to take action on RFC 7130 rather than 
9314.


-- Jeff

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

[xiao.min2]

Hi BFD WG,

A new version of draft-ietf-bfd-unaffiliated-echo has been submitted to keep it 
from expired.
The current draft has addressed all received comments, please review it and 
provide your further comments.

Thanks,
Xiao Min
--Original--
From: internet-dra...@ietf.org 
To: Raj Boddireddy ;Raj Chetan Boddireddy 
;Reshad Rahman ;Ruixue Wang 
;Weiqiang Cheng 
;肖敏10093570;
Date: 2022年08月01日 16:27
Subject: New Version Notification for draft-ietf-bfd-unaffiliated-echo-05.txt

A new version of I-D, draft-ietf-bfd-unaffiliated-echo-05.txt
has been successfully submitted by Xiao Min and posted to the
IETF repository.
Name:draft-ietf-bfd-unaffiliated-echo
Revision:05
Title:Unaffiliated BFD Echo
Document date:2022-08-01
Group:bfd
Pages:11
URL:
https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-unaffiliated-echo-05
Abstract:
Bidirectional Forwarding Detection (BFD) is a fault detection
protocol that can quickly determine a communication failure between
two forwarding engines.  This document proposes a use of the BFD Echo
where the local system supports BFD but the neighboring system does
not support BFD.
This document updates RFC 5880.
The IETF Secretariat

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Hi Matthew,






Thank you for concluding the extended WG last call.


I've posted the -08 revision to address all the agreed WG last call comments. 
Link as below.


https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-08






Best Regards,


Xiao Min



Original



From: MatthewBocci(Nokia) 
To: NVO3 ;rtg-bfd@ietf.org ;
Date: 2022年11月17日 17:49
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




This email concludes the extended WG last call.


 


Authors: Please update the draft as per the  agreed WG last call comments so 
that we can progress to the next steps.


 


Regards


 


Matthew


 



From: Bocci, Matthew (Nokia - GB) 
 Date: Friday, 21 October 2022 at 10:37
 To: NVO3 , rtg-bfd@ietf.org 
 Subject: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks



NVO3 and BFD working groups,


 


To give more time to review and comment on this draft in the light of the draft 
submission deadline of 24th October, I am extending this WG last call to Friday 
4th November 2022.


 


Please review and post any comments to the NVO3 list (including whether you 
support publication as an RFC).


 


Thanks


 


Matthew

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Hi Matthew,






Would you please conclude the extended WG LC for draft-ietf-nvo3-bfd-geneve?






Best Regards,


Xiao Min









Original



From: 肖敏10093570
To: ReshadRahman ;
Cc: n...@ietf.org ;rtg-bfd@ietf.org 
;matthew.bo...@nokia.com ;
Date: 2022年11月09日 10:24
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Hi Reshad,







Thank you for the quick reply.


Please see inline [XM-2]...

















From: ReshadRahman 
To: 肖敏10093570;
Cc: n...@ietf.org ;rtg-bfd@ietf.org 
;matthew.bo...@nokia.com ;
Date: 2022年11月09日 04:12
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks







Hi Xiao Min,




Thanks for the prompt response. Inline .






On Monday, November 7, 2022, 02:14:05 AM EST, xiao.m...@zte.com.cn 
 wrote:









Hi Reshad,






Thank you for the thorough review and thoughtful comments.


Please see inline...





Best Regards,


Xiao Min



Original



From: ReshadRahman 
To: NVO3 ;rtg-bfd@ietf.org ;Bocci, Matthew 
(Nokia - GB) ;
Date: 2022年11月07日 00:06
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Hi,


- The abstract mentions point-to-point Geneve tunnels. Might be good to add 
"unicast"?


[XM]>>> OK. Will add it in the next revision.


- I don't see it being spelled out that this is single-hop BFD, except the 
reference to RFC 5881 and setting TTL to 255. Might be good to be explicit. 
FWIW RFC 8971 isn't very explicit either...

[XM]>>> OK. Will make it explicit in the next revision.




- RFC 8926 mentions that a Geneve tunnel is unidirectional. Can demand mode be 
used?


[XM]>>> Yes, I think so. Considering both RFC 8971 and RFC 5881 don't mention 
Demand mode, do you see a need to mention it in this document?




 I should have phrased my question better. If a Geneve tunnel is indeed 
unidirectional, was any consideration given to using demand mode so that the 
"receiver" isn't actively sending BFD control packets out of band (since the 
tunnel is unidirectional) to the "sender". But since this is unicast, I think 
you can ignore that.

[XM-2]>>> OK.



 

- Section 4.1 "and use the same way to encapsulate data packets.". So a VAP is 
either IP or ethernet and both VAPs have to use same encaps. What if 1 is v4 
and the other is v6? May need more details on this, either in section 1 or 
section 3.


[XM]>>> Section 4.1 also says "a BFD session can only be established between 
two VAPs that are mapped to the same VNI". I don't believe the case you 
described exists in one VNI, what do you think?




 Ack.


- Section 5: "Virtual Network Identifier (VNI) field SHOULD be set to the VNI 
number that the originating VAP is mapped to.". OOC, why is this a SHOULD and 
not a MUST? Specifically, why would it not be set to the VNI of the originating 
VAP? Section 4.1 mentions same VNI being used between the 2 VAPs.

[XM]>>> The reason is that the originating VAP could also choose to use 
Management VNI. 




 Ah right. I think you may get the same question later in the IETF process, 
so adding this in the document would help. 

[XM-2]>>> OK. Will add this in the document.



- If there is a YANG model for VAPs (not covered in draft-ietf-nvo3-yang-cfg 
which has expired), I would like to see YANG for BFD over Geneve. Not sure 
whether new config is needed, but there will be new operational state (in 
Geneve and in BFD). Whether it's in the same doc or in a separate parallel doc 
is above my pay grade.

[XM]>>> I see. As an author of draft-ietf-nvo3-bfd-geneve, I think the 
potential YANG should be outside the scope.



 Generally/ideally I would prefer to see YANG being done in the same doc. 
But in this case, I think that's not possible.

[XM-2]>>> Thank you for your understanding. If you're interested to write a 
YANG module for this feature, I would like to help. :-)




Best Regards,

Xiao Min





Regards,

Reshad.





Regards,

Reshad.




On Friday, October 21, 2022, 05:37:22 AM EDT, Bocci, Matthew (Nokia - GB) 
 wrote:





NVO3 and BFD working groups,


 


To give more time to review and comment on this draft in the light of the draft 
submission deadline of 24th October, I am extending this WG last call to Friday 
4th November 2022.


 


Please review and post any comments to the NVO3 list (including whether you 
support publication as an RFC).


 


Thanks


 


Matthew

Re: A missing read/write attribute in RFC 9314?

[xiao.min2]

Jeff,






Thank you for the quick reply.


Please see inline...



Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: Reshad Rahman ;BFD WG ;Alexander 
Vainshtein ;Nitsan Dolev 
;Shell Nakash 
;james.l...@rbbn.com ;
Date: 2022年11月04日 19:22
Subject: Re: A missing read/write attribute in RFC 9314?


Thank you for the correction and apologies for my error in copying, Xiao 
Min.[XM]>>> That's all right. :-)





It would seem that Juniper is unique in using the learned MAC address for the 
session. :-)
[XM]>>> Yes, it looks so. Actually I'm curious what's the behavior of Juniper's 
node if it receives a BFD control packet with the dedicated multicast MAC.




Best Regards,

Xiao Min





However, none of the implementations permit dynamic use of both. We have 
compliant implementations that do not need additional YANG configuration.

-- Jeff


On Nov 3, 2022, at 9:09 PM,   wrote:



Jeff,





To clarify ZTE's implementation, please see inline...











From: JeffreyHaas 

To: Reshad Rahman ;

Cc: BFD WG ;Alexander Vainshtein 
;Nitsan Dolev ;Shell 
Nakash ;James Lian ;

Date: 2022年11月04日 07:17

Subject: Re: A missing read/write attribute in RFC 9314?



[In an attempt to close this thread, replying to my older message...]On Wed, 
Oct 19, 2022 at 03:24:57PM -0400, Jeffrey Haas wrote:> On Mon, Oct 17, 2022 at 
06:01:05PM +, Reshad Rahman wrote:> >  Hi Sasha,> > Apologies for the 
delay.> > Yes this config knob is not present in RFC9314. I don't think it's 
something we did not add on purpose, afair it's something we missed. >  > I'm 
going to offer a contrary view.  Given that it may save us some work,> that 
might be appreciated. :-)>  > Repeating the relevant bit of text:>  > >   All 
implementations MUST be able to send and receive BFD packets in> >   Up state 
using the dedicated MAC address.  Implementations supporting> >   both, sending 
BFD Up packets with the dedicated and the received MAC,> >   need to offer 
means to control the behavior.>  > We have a mandatory mode, and an OPTIONAL 
mode.  The BFD YANG module is> supporting, effectively, the mandatory.>  > 
Modeling-wise, what we'd be looking for is adding this knob protected under> 
the appropriate new if-feature for it.>  > I think what this work looks like 
is:> 1. Survey of implementations to see whether they do this behavior, and 
what> their knob is, if so.> 2a. If no implementations have such a knob, it's 
quite reasonable to just let> the vendor do their own augmentation module for 
it.> 2b. If multiple vendors implement it, we need an update.> 3. If we need an 
update, one path is to -bis RFC 9314, the other is to> simply do a trivial 
augmentation RFC.  (Mahesh notes this point in his> reply.)What we have seen in 
a partial vendor implementation survey:- Arrcus only uses the dedicated 
multicast MAC for the Up session (mjethanandani)- Huawei only uses the 
dedicated multicast MAC for the Up session (mach.chen)- Juniper will use the 
discovered unicast MAC for the Up session. (jhaas)
- ZTE will use the discovered unicast MAC for the Up session. (xiao.min)


[XM]>>> That's NOT what I replied to the survey [1]. The correct one is as 
below.


- ZTE only uses the dedicated multicast MAC for the Up session. (xiao.min)


[1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/_Ie2xUP5UskH3M2yE4V-JVO8g_g/





Best Regards,


Xiao Min

None of these implementations support a knob to choose the behavior.  Theypick 
a mode and stick with it.My conclusion is that we likely do not need an IETF 
update to the BFD YANGmodule here.  If an implementation comes into being that 
makes thisselectable, YANG permits vendor augmentation to address the 
additionalconfiguration state.If it becomes the case that multiple vendors 
implement such a knob, IETFshould consider the trivial augmentation module to 
standardize the knob toprovide for ease of interop.To say that I'm relieved 
that we don't need a further update to BFD YANG atthis time is an 
understatement. :-)-- Jeff

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Jeff,






Thank you for the quick reply.


Please see inline...




Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: Bocci, Matthew (Nokia - GB) ;n...@ietf.org 
;rtg-bfd@ietf.org ;
Date: 2022年11月04日 19:20
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Xiao Min,


On Nov 3, 2022, at 10:52 PM,   
wrote:








: If the BFD packet is received with Your Discriminator equals to 0, the BFD: 
session MUST be identified using the VNI number, and the inner: Ethernet/IP/UDP 
Header, i.e., the source MAC, the source IP, the destination: MAC, the 
destination IP, and the source UDP port number present in the inner: 
Ethernet/IP/UDP header.Not being familiar with Geneve configuration at all, 
I'll presume that withthere is a motivation for using the MAC addresses within 
a given VNI contextin addition to the IP addresses.  If this is clear from 
typical Geneveprocedures, it might be worth a nod to the appropriate section.  
I'll notethat this point of procedure doesn't seem to have a parallel in BFD 
for vxlan.
[XM]>>> Would you please elaborate a bit on the possible nod? As I understand 
it, the reason why there is no a parallel in RFC 8971 is that only one BFD 
session using the management VNI is needed between a pair of VTEPs, so there is 
no demultiplexing procedure needed in RFC 8971.










To restate my question, on a given device receiving, for a given VNI, will 
there ever be multiple sets of the same IP addresses?

If yes, the addition of the MAC addresses for initial multiplexing makes sense. 
 Otherwise, perhaps they are unneeded?
[XM-2]>>> The answer to your first question is Yes. In section 4.1 of this 
document it says In BFD over Geneve, a BFD session is originated and terminated 
at
 VAP, usually one NVE owns multiple VAPs, so multiple BFD sessions may
 be running between two NVEs, there needs to be a mechanism for
 demultiplexing received BFD packets to the proper session.
 Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping
 between VAP and VNI at one NVE, multiple BFD sessions between two
 NVEs for the same VNI are allowed.






What I'm far more puzzled by is the source port demultiplexing step.  Thisisn't 
normal for RFC 5881.  Why is there a desire to add this to initial 
demultiplexing?
[XM]>>> In section 4 of RFC 5881 it says 

An implementation MAY use
 the UDP port source number to aid in demultiplexing incoming BFD
 Control packets, but ultimately the mechanisms in [BFD] MUST be used
 to demultiplex incoming packets to the proper session.
It seems adding the UDP source port is helpful, what do you think?








It actually can make configuration more difficult.  You must then have 
provisioning for the UDP ports for your sessions on each side of things.  

If you don't need to explicitly control more than one session between the same 
VNI, for the same IP address pairs, on the same device, you can simply 
demultiplex based on the UDP destination port for BFD single hop as per RFC 
5881 procedures.

If you have need for such explicit control, such additional procedure is fine.


[XM-2]>>> Yes, I believe there is such a need. Furthermore, the provision for 
source UDP port is optional even if it's included in the demultiplexing fields, 
because the source UDP port is not the only field for demultiplexing. In other 
words, if an implementation selects not to configure the source UDP port, but 
just use the default one, this implementation can still comply with this 
specification.






Best Regards,


Xiao Min






-- Jeff

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Hi Reshad,







Thank you for the quick reply.


Please see inline [XM-2]...









Original



From: ReshadRahman 
To: 肖敏10093570;
Cc: n...@ietf.org ;rtg-bfd@ietf.org 
;matthew.bo...@nokia.com ;
Date: 2022年11月09日 04:12
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks







Hi Xiao Min,




Thanks for the prompt response. Inline .






On Monday, November 7, 2022, 02:14:05 AM EST, xiao.m...@zte.com.cn 
 wrote:









Hi Reshad,






Thank you for the thorough review and thoughtful comments.


Please see inline...





Best Regards,


Xiao Min



Original



From: ReshadRahman 
To: NVO3 ;rtg-bfd@ietf.org ;Bocci, Matthew 
(Nokia - GB) ;
Date: 2022年11月07日 00:06
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Hi,


- The abstract mentions point-to-point Geneve tunnels. Might be good to add 
"unicast"?


[XM]>>> OK. Will add it in the next revision.


- I don't see it being spelled out that this is single-hop BFD, except the 
reference to RFC 5881 and setting TTL to 255. Might be good to be explicit. 
FWIW RFC 8971 isn't very explicit either...

[XM]>>> OK. Will make it explicit in the next revision.




- RFC 8926 mentions that a Geneve tunnel is unidirectional. Can demand mode be 
used?


[XM]>>> Yes, I think so. Considering both RFC 8971 and RFC 5881 don't mention 
Demand mode, do you see a need to mention it in this document?




 I should have phrased my question better. If a Geneve tunnel is indeed 
unidirectional, was any consideration given to using demand mode so that the 
"receiver" isn't actively sending BFD control packets out of band (since the 
tunnel is unidirectional) to the "sender". But since this is unicast, I think 
you can ignore that.

[XM-2]>>> OK.



 

- Section 4.1 "and use the same way to encapsulate data packets.". So a VAP is 
either IP or ethernet and both VAPs have to use same encaps. What if 1 is v4 
and the other is v6? May need more details on this, either in section 1 or 
section 3.


[XM]>>> Section 4.1 also says "a BFD session can only be established between 
two VAPs that are mapped to the same VNI". I don't believe the case you 
described exists in one VNI, what do you think?




 Ack.


- Section 5: "Virtual Network Identifier (VNI) field SHOULD be set to the VNI 
number that the originating VAP is mapped to.". OOC, why is this a SHOULD and 
not a MUST? Specifically, why would it not be set to the VNI of the originating 
VAP? Section 4.1 mentions same VNI being used between the 2 VAPs.

[XM]>>> The reason is that the originating VAP could also choose to use 
Management VNI. 




 Ah right. I think you may get the same question later in the IETF process, 
so adding this in the document would help. 

[XM-2]>>> OK. Will add this in the document.



- If there is a YANG model for VAPs (not covered in draft-ietf-nvo3-yang-cfg 
which has expired), I would like to see YANG for BFD over Geneve. Not sure 
whether new config is needed, but there will be new operational state (in 
Geneve and in BFD). Whether it's in the same doc or in a separate parallel doc 
is above my pay grade.

[XM]>>> I see. As an author of draft-ietf-nvo3-bfd-geneve, I think the 
potential YANG should be outside the scope.



 Generally/ideally I would prefer to see YANG being done in the same doc. 
But in this case, I think that's not possible.

[XM-2]>>> Thank you for your understanding. If you're interested to write a 
YANG module for this feature, I would like to help. :-)




Best Regards,

Xiao Min





Regards,

Reshad.





Regards,

Reshad.




On Friday, October 21, 2022, 05:37:22 AM EDT, Bocci, Matthew (Nokia - GB) 
 wrote:





NVO3 and BFD working groups,


 


To give more time to review and comment on this draft in the light of the draft 
submission deadline of 24th October, I am extending this WG last call to Friday 
4th November 2022.


 


Please review and post any comments to the NVO3 list (including whether you 
support publication as an RFC).


 


Thanks


 


Matthew

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Hi Reshad,






Thank you for the thorough review and thoughtful comments.


Please see inline...





Best Regards,


Xiao Min



Original



From: ReshadRahman 
To: NVO3 ;rtg-bfd@ietf.org ;Bocci, Matthew 
(Nokia - GB) ;
Date: 2022年11月07日 00:06
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks




Hi,

- The abstract mentions point-to-point Geneve tunnels. Might be good to add 
"unicast"?

[XM]>>> OK. Will add it in the next revision.


- I don't see it being spelled out that this is single-hop BFD, except the 
reference to RFC 5881 and setting TTL to 255. Might be good to be explicit. 
FWIW RFC 8971 isn't very explicit either...

[XM]>>> OK. Will make it explicit in the next revision.



- RFC 8926 mentions that a Geneve tunnel is unidirectional. Can demand mode be 
used?

[XM]>>> Yes, I think so. Considering both RFC 8971 and RFC 5881 don't mention 
Demand mode, do you see a need to mention it in this document?


- Section 4.1 "and use the same way to encapsulate data packets.". So a VAP is 
either IP or ethernet and both VAPs have to use same encaps. What if 1 is v4 
and the other is v6? May need more details on this, either in section 1 or 
section 3.

[XM]>>> Section 4.1 also says "a BFD session can only be established between 
two VAPs that are mapped to the same VNI". I don't believe the case you 
described exists in one VNI, what do you think?


- Section 5: "Virtual Network Identifier (VNI) field SHOULD be set to the VNI 
number that the originating VAP is mapped to.". OOC, why is this a SHOULD and 
not a MUST? Specifically, why would it not be set to the VNI of the originating 
VAP? Section 4.1 mentions same VNI being used between the 2 VAPs.

[XM]>>> The reason is that the originating VAP could also choose to use 
Management VNI. 


- If there is a YANG model for VAPs (not covered in draft-ietf-nvo3-yang-cfg 
which has expired), I would like to see YANG for BFD over Geneve. Not sure 
whether new config is needed, but there will be new operational state (in 
Geneve and in BFD). Whether it's in the same doc or in a separate parallel doc 
is above my pay grade.

[XM]>>> I see. As an author of draft-ietf-nvo3-bfd-geneve, I think the 
potential YANG should be outside the scope.





Regards,

Reshad.




On Friday, October 21, 2022, 05:37:22 AM EDT, Bocci, Matthew (Nokia - GB) 
 wrote:





NVO3 and BFD working groups,


 


To give more time to review and comment on this draft in the light of the draft 
submission deadline of 24th October, I am extending this WG last call to Friday 
4th November 2022.


 


Please review and post any comments to the NVO3 list (including whether you 
support publication as an RFC).


 


Thanks


 


Matthew

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[xiao.min2]

Jeff,






Thank you for the thorough review and thoughtful comments.


Please see inline...






Best Regards,


Xiao Min



Original



From: JeffreyHaas 
To: Bocci, Matthew (Nokia - GB) ;
Cc: NVO3 ;rtg-bfd@ietf.org ;
Date: 2022年11月04日 08:11
Subject: Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks


Matthew,
 
On Fri, Oct 21, 2022 at 09:37:13AM +, Bocci, Matthew (Nokia - GB) wrote:
> NVO3 and BFD working groups,
>  
> To give more time to review and comment on this draft in the light of the 
> draft submission deadline of 24th October, I am extending this WG last call 
> to Friday 4th November 2022.
>  
> Please review and post any comments to the NVO3 list (including whether you 
> support publication as an RFC).
 
Thanks for your patience.  I have reviewed the BFD for geneve draft.  My
comments are below.
 
Section 4:
: Destination IP: IP address of a VAP of the terminating NVE. If the VAP of
: the terminating NVE has no IP address, then the IP address 127.0.0.1 for
: IPv4 or ::1/128 for IPv6 MUST be used.
 
The procedure here is clear.  I suspect that those who have been exposed to
other prior tunnel endpoint destination IP address discussions may note that
more of the "loopback range" has been used.  In particular, the comparable
BFD for vxlan - RFC 8971, Section 3.
 
While I'm not suggesting that the draft change its behavior, the Working
Group may wish to be aware that this may come up as a point of discussion.
 
That said, the IESG has collective amnesia about this point when it shows up
in other proposals so I think you're fine. :-)

[XM]>>> Good observation. You're right that "loopback range" is used in RFC 
8971 while a dedicated loopback address is used in this document. That's an 
intended change. In -00 wg draft, the "loopback range" as RFC 8971 was used, 
and after discussion among the authors, it's realized that a dedicated loopback 
address would facilitate the implementation, so this change. Hope the IESG 
would not object it. :-)




: In BFD over Geneve, a BFD session is originated and terminated at VAP,
: usually one NVE owns multiple VAPs, so multiple BFD sessions may be running
: between two NVEs, there needs to be a mechanism for demultiplexing received
: BFD packets to the proper session
 
The above is a bit of a run-on sentence.  Suggest minor punctuation changes:
 
"In BFD over Geneve, a BFD session is originated and terminated at VAP,
usually one NVE owns multiple VAPs. Since multiple BFD sessions may be running
between two NVEs, there needs to be a mechanism for demultiplexing received
BFD packets to the proper session."

[XM]>>> The changes you suggested look good to me. Will use your text in the 
next revision.


: If the BFD packet is received with Your Discriminator equals to 0, the BFD
: session MUST be identified using the VNI number, and the inner
: Ethernet/IP/UDP Header, i.e., the source MAC, the source IP, the destination
: MAC, the destination IP, and the source UDP port number present in the inner
: Ethernet/IP/UDP header.
 
Not being familiar with Geneve configuration at all, I'll presume that with
there is a motivation for using the MAC addresses within a given VNI context
in addition to the IP addresses.  If this is clear from typical Geneve
procedures, it might be worth a nod to the appropriate section.  I'll note
that this point of procedure doesn't seem to have a parallel in BFD for
vxlan.

[XM]>>> Would you please elaborate a bit on the possible nod? As I understand 
it, the reason why there is no a parallel in RFC 8971 is that only one BFD 
session using the management VNI is needed between a pair of VTEPs, so there is 
no demultiplexing procedure needed in RFC 8971.


What I'm far more puzzled by is the source port demultiplexing step.  This
isn't normal for RFC 5881.  Why is there a desire to add this to initial
demultiplexing?

[XM]>>> In section 4 of RFC 5881 it says 

An implementation MAY use
 the UDP port source number to aid in demultiplexing incoming BFD
 Control packets, but ultimately the mechanisms in [BFD] MUST be used
 to demultiplex incoming packets to the proper session. It seems adding the UDP 
source port is helpful, what do you think?




The same comment on UDP port number holds for section 5.1 for IP
encapsulation.

[XM]>>> OK. I'll take care of section 5.1 too.


-- Jeff

Re: A missing read/write attribute in RFC 9314?

[xiao.min2]

Jeff,






To clarify ZTE's implementation, please see inline...



Original



From: JeffreyHaas 
To: Reshad Rahman ;
Cc: BFD WG ;Alexander Vainshtein 
;Nitsan Dolev ;Shell 
Nakash ;James Lian ;
Date: 2022年11月04日 07:17
Subject: Re: A missing read/write attribute in RFC 9314?


[In an attempt to close this thread, replying to my older message...]
 
On Wed, Oct 19, 2022 at 03:24:57PM -0400, Jeffrey Haas wrote:
> On Mon, Oct 17, 2022 at 06:01:05PM +, Reshad Rahman wrote:
> >  Hi Sasha,
> > Apologies for the delay.
> > Yes this config knob is not present in RFC9314. I don't think it's 
> > something we did not add on purpose, afair it's something we missed. 
>  
> I'm going to offer a contrary view.  Given that it may save us some work,
> that might be appreciated. :-)
>  
> Repeating the relevant bit of text:
>  
> >   All implementations MUST be able to send and receive BFD packets in
> >   Up state using the dedicated MAC address.  Implementations supporting
> >   both, sending BFD Up packets with the dedicated and the received MAC,
> >   need to offer means to control the behavior.
>  
> We have a mandatory mode, and an OPTIONAL mode.  The BFD YANG module is
> supporting, effectively, the mandatory.
>  
> Modeling-wise, what we'd be looking for is adding this knob protected under
> the appropriate new if-feature for it.
>  
> I think what this work looks like is:
> 1. Survey of implementations to see whether they do this behavior, and what
> their knob is, if so.
> 2a. If no implementations have such a knob, it's quite reasonable to just let
> the vendor do their own augmentation module for it.
> 2b. If multiple vendors implement it, we need an update.
> 3. If we need an update, one path is to -bis RFC 9314, the other is to
> simply do a trivial augmentation RFC.  (Mahesh notes this point in his
> reply.)
 
What we have seen in a partial vendor implementation survey:
- Arrcus only uses the dedicated multicast MAC for the Up session 
(mjethanandani)
- Huawei only uses the dedicated multicast MAC for the Up session (mach.chen)
- Juniper will use the discovered unicast MAC for the Up session. (jhaas)
- ZTE will use the discovered unicast MAC for the Up session. (xiao.min)

[XM]>>> That's NOT what I replied to the survey [1]. The correct one is as 
below.

- ZTE only uses the dedicated multicast MAC for the Up session. (xiao.min)

[1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/_Ie2xUP5UskH3M2yE4V-JVO8g_g/ 




Best Regards,

Xiao Min


None of these implementations support a knob to choose the behavior.  They
pick a mode and stick with it.
 
My conclusion is that we likely do not need an IETF update to the BFD YANG
module here.  If an implementation comes into being that makes this
selectable, YANG permits vendor augmentation to address the additional
configuration state.
 
If it becomes the case that multiple vendors implement such a knob, IETF
should consider the trivial augmentation module to standardize the knob to
provide for ease of interop.
 
To say that I'm relieved that we don't need a further update to BFD YANG at
this time is an understatement. :-)
 
-- Jeff

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

[xiao.min2]

Hi Abhinav,






When I come across your problem, the first idea coming into my mind is not 
trying to change the source port for a BFD session, but to run multiple BFD 
sessions between the two peers, using each BFD session to monitor a respective 
ECMP path, and then the application would not be declared in failure unless all 
the BFD sessions go down.






Best Regards,


Xiao Min









Original



From: AbhinavSrivastava 
To: Alexander Vainshtein ;
Cc: rtg-bfd@ietf.org ;
Date: 2023年03月23日 22:27
Subject: Re: [EXTERNAL] Re: Can a BFD session change its source port to 
facilitate auto recovery





Agree that deletion and recreation (possibly automatically) by associated 
protocol is a good alternative, instead of inbuilt BFD recovery. 




Thanks

Abhinav





On Thu, 23 Mar, 2023, 3:08 am Alexander Vainshtein, 
 wrote:




Abhinav, Jeff and all,


FWIW I concur with Jeff.


 


In my experience, MH IP BFD sessions are typically used to monitor peering 
between iBGP neighbors, and when the MH IP BFD session goes down, BGP treats 
this as if its session has gone – and deletes the MH IP BFD session in question.


 


I.e., fast recovery of such a session will not happen until BGP would not 
re-create it.


 


Regards,


Sasha



 



From: Rtg-bfd  On Behalf Of Jeff Tantsura
 Sent: Thursday, March 23, 2023 8:27 AM
 To: Abhinav Srivastava 
 Cc: rtg-bfd@ietf.org
 Subject: [EXTERNAL] Re: Can a BFD session change its source port to facilitate 
auto recovery




 


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









 Notice: This e-mail together 

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

[xiao.min2]

Jeff,






Please see inline...









Original



From: JeffTantsura 
To: 肖敏10093570;
Cc: absri...@gmail.com ;alexander.vainsht...@rbbn.com 
;rtg-bfd@ietf.org ;
Date: 2023年03月24日 16:48
Subject: Re: [EXTERNAL] Re: Can a BFD session change its source port to 
facilitate auto recovery




That’s not going to fly, number of ECMP paths in today’s networks could be 
anywhere between 2 and 500+, how many of these would you exercise, how would 
you know that you have covered all of them?

[XM]>>> The number of links/LAGs seems much higher than the number of ECMP 
paths. If otherwise I have to run SH BFD on each link/LAG, why not try to run 
MH BFD on each ECMP path? :-) As to the coverage, BFD+IOAM may help, because 
IOAM can tell you the path BFD packet really takes.

The role of MH BFD is to verify reachability between 2 non directly connected 
IP end-points, not to monitor every path available.

[XM]>>> IMHO BFD for SR Policy does care about the path, and some SP's networks 
require bidirectional path consistency while employing BFD.




Best Regards,

Xiao Min




As a viable solution, run SH BFD on each link/LAG, MH BFD end2end and make sure 
your timers are aligned and not interact with each other in funny ways.


Cheers,
Jeff



On Mar 24, 2023, at 09:26, xiao.m...@zte.com.cn wrote:





Hi Abhinav,






When I come across your problem, the first idea coming into my mind is not 
trying to change the source port for a BFD session, but to run multiple BFD 
sessions between the two peers, using each BFD session to monitor a respective 
ECMP path, and then the application would not be declared in failure unless all 
the BFD sessions go down.






Best Regards,


Xiao Min




















From: AbhinavSrivastava 
To: Alexander Vainshtein ;
Cc: rtg-bfd@ietf.org ;
Date: 2023年03月23日 22:27
Subject: Re: [EXTERNAL] Re: Can a BFD session change its source port to 
facilitate auto recovery





Agree that deletion and recreation (possibly automatically) by associated 
protocol is a good alternative, instead of inbuilt BFD recovery. 




Thanks

Abhinav





On Thu, 23 Mar, 2023, 3:08 am Alexander Vainshtein, 
 wrote:




Abhinav, Jeff and all,


FWIW I concur with Jeff.


 


In my experience, MH IP BFD sessions are typically used to monitor peering 
between iBGP neighbors, and when the MH IP BFD session goes down, BGP treats 
this as if its session has gone – and deletes the MH IP BFD session in question.


 


I.e., fast recovery of such a session will not happen until BGP would not 
re-create it.


 


Regards,


Sasha



 



From: Rtg-bfd  On Behalf Of Jeff Tantsura
 Sent: Thursday, March 23, 2023 8:27 AM
 To: Abhinav Srivastava 
 Cc: rtg-bfd@ietf.org
 Subject: [EXTERNAL] Re: Can a BFD session change its source port to facilitate 
auto recovery




 


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 

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

[xiao.min2]

Jeff,






Thank you very much for the insightful and detailed review and comments, 
especially the proposed text, very helpful.


A new -06 revision to address your comments has just been posted: 
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-06.


Please see inline for details...




Original



From: JeffreyHaas 
To: draft-ietf-bfd-unaffiliated-e...@ietf.org 
;rtg-bfd@ietf.org ;
Date: 2023年03月22日 01:04
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-05


[resend with correct draft address]
 
Authors,
 
Some comments on version -05:
 
16Abstract
 
18   Bidirectional Forwarding Detection (BFD) is a fault detection
19   protocol that can quickly determine a communication failure between
20   two forwarding engines.  This document proposes a use of the BFD Echo
21   where the local system supports BFD but the neighboring system does
22   not support BFD.
 
It would be good in the abstract to discuss the core idea of this mechanism:
BFD Async procedures can be executed over the BFD Echo port where the remote
system only loops packets back to the local system.
 
The procedures discussed below cover this, but it takes some time to understand
what the intent is.
 [XM]>>> OK.
 
731.  Introduction
[...]
 
86   BFD defines Asynchronous and Demand modes to satisfy various
87   deployment scenarios.  It also supports an Echo function to reduce
88   the device requirement for BFD.  When the Echo function is activated,
89   the local system sends BFD Echo packets and the remote system loops
90   back the received Echo packets through the forwarding path.  If
91   several consecutive BFD Echo packets are not received by the local
92   system, then the BFD session is declared to be Down.
 
It would be appropriate to reference RFC 5880, section 5 here.  "The payload of
a BFD Echo packet is a local matter".  This draft, on the other hand, specifies
the contents of the Echo packets and what to do with them.
 [XM]>>> OK.




94   When using BFD Echo function, there are two typical scenarios as
95   below:
 
97   *  Full BFD protocol capability with affiliated Echo function.  This
98  scenario requires both the local device and the neighboring device
99  to support the full BFD protocol.
 
101   *  BFD Echo-Only method without full BFD protocol capability.  This
102  scenario requires only the local device to support sending and
103  demultiplexing BFD Control packets.
 
The bullet point above is a good place to discuss that the BFD Control packets
are sent over the BFD Echo port, but that the BFD Async procedures are used with
the modifications described in this document.
 [XM]>>> OK.
 
2663.  Unaffiliated BFD Echo Procedures
 
[...]
 
288   To rapidly detect any IP forwarding faults between device A and
289   device B, a BFD Echo session MUST be created at device A, and the BFD
 
I would remove the "To rapidly detect" clause before the comma and replace it
with "For unaffiliated echo,".  The current wording seems to suggest this
procedure is the only way to detect forwarding faults.
 
Perhaps also change "session MUST be created" with "session is created".   
 [XM]>>> OK.




290   Echo session MUST follow the BFD state machine defined in Section 6.2
291   of [RFC5880], except that the received state is not sent but echoed
292   from the remote system, and AdminDown state is ruled out because
293   AdminDown effectively means removal of BFD Echo session.  In this
 
Perhaps:
"from the remote system.  BFD Unaffiliated Echo does not use the AdminDown
state." 
 [XM]>>> OK.




293   In this
294   case, although BFD Echo packets are transmitted with destination UDP
295   port 3785 as defined in [RFC5881], the BFD Echo packets sent by
296   device A are BFD Control packets too,
 
Perhaps:
"BFD Control packets are transmitted and received as BFD Echo packets using
destination UDP port 3785, as defined in [RFC5881]." 
 [XM]>>> OK.




296   the looped BFD Echo packets
297   back from device B would drive BFD state change at device A,
298   substituting the BFD Control packets sent from the BFD peer.  Also
299   note that when device A receives looped BFD Control packets, the
300   validation procedures of [RFC5880] are used.
 
Perhaps:
"The procedures for BFD Async sessions are executed for the looped BFD Control
packets as per [RFC5880], including validation and authentication." 
 [XM]>>> OK.




302   Once a BFD Echo session is created at device A, it starts sending BFD
303   Echo packets, which MUST include BFD Echo session demultiplexing
304   fields, such as BFD "Your Discriminator" defined in [RFC5880] (BFD
305   "My Discriminator" can be set to 0 to avoid confusion), except for
 
Why would My Discriminator be 0?  A local value should be chosen to distinguish
individual sessions.  This is for a few reasons:

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

[xiao.min2]

Hi Jeff,






Please see inline...









Original



From: JeffTantsura 
To: 肖敏10093570;
Cc: Abhinav Srivastava ;alexander.vainsht...@rbbn.com 
;rtg-bfd@ietf.org ;
Date: 2023年03月27日 00:28
Subject: Re: [EXTERNAL] Can a BFD session change its source port to facilitate 
auto recovery




Hi Xiao,

please see inline

On Mar 24, 2023, at 5:43 PM,   
wrote:


Jeff,






Please see inline...










[jeff] the number of p2p connections between 2 directly attached IP end-points 
is rarely larger than 32 (either LAG or ECMP), SH BFD sessions are distributed 
across the path traversed and coherency between IP connectivity matrix and BFD 
sessions between any given pair of directly connected IP end-points can easily 
be guaranteed, end2end (MH BFD) is between non directly attached end-points and 
is subject to network topology and routing, and has to be re-evaluated on any 
change.
INT doesn’t really help here, hashing decisions are local, any changes (local 
or global) might change the hashing results, unless you build a full mesh of 
source routed paths… but then, why BFD at all, you could use INT only instead, 
take a look at HPCC draft 

[XM]>>> I think it depends. I know that in some networks the hashing algo is 
common on all network nodes, so the hashing results are predictable.





[jeff] how did we get to SR here? If you have got a strict source routed path, 
you only need to validate that path, if it is loose however, same issues

[XM]>>> Jump thinking, sorry about that. :) Just to argue that MH BFD can be 
used beyond reachability.




Best Regards,

Xiao Min








From: JeffTantsura 
To: 肖敏10093570;
Cc: absri...@gmail.com ;alexander.vainsht...@rbbn.com 
;rtg-bfd@ietf.org ;
Date: 2023年03月24日 16:48
Subject: Re: [EXTERNAL] Re: Can a BFD session change its source port to 
facilitate auto recovery




That’s not going to fly, number of ECMP paths in today’s networks could be 
anywhere between 2 and 500+, how many of these would you exercise, how would 
you know that you have covered all of them?

[XM]>>> The number of links/LAGs seems much higher than the number of ECMP 
paths. If otherwise I have to run SH BFD on each link/LAG, why not try to run 
MH BFD on each ECMP path? :-) As to the coverage, BFD+IOAM may help, because 
IOAM can tell you the path BFD packet really takes.

Re: [Technical Errata Reported] RFC5880 (7240)

[xiao.min2]

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 
;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 
 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 
>>>  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 5880), or transitions that may happen while the session 
>> remains up (e.g. concatenated path down, echo, etc.).  The RFC isn't great 
>> about saying how you clear such things when the state is still Up; 
>> intuitively it's to return to "No Diagnostic".


>> 


>> However, your own leaning, Dave, is "leave it set forever".  Using the above 
>> examples for diag 

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

[xiao.min2]

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 section 3 
"Unaffiliated BFD Echo Procedures".

* add a summary on the Unaffiliated BFD Echo packet fields setting into the end 
of section "Unaffiliated BFD Echo Procedures".

* change the text on IP address setting to the same as specified in section 4 
of RFC 5881.

* some editorial changes, e.g., s/BFD Unaffiliated Echo packet/Unaffiliated BFD 
Echo packet/g.






Best Regards,


Xiao Min



Original



From: internet-dra...@ietf.org 
To: Raj Boddireddy ;Raj Chetan Boddireddy 
;Reshad Rahman ;Ruixue Wang 
;Weiqiang Cheng 
;肖敏10093570;
Date: 2023年04月24日 10:09
Subject: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt



A new version of I-D, draft-ietf-bfd-unaffiliated-echo-07.txt
has been successfully submitted by Xiao Min and posted to the
IETF repository.
 
Name:draft-ietf-bfd-unaffiliated-echo
Revision:07
Title:Unaffiliated BFD Echo
Document date:2023-04-23
Group:bfd
Pages:12
URL:
https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-07.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-07
 
Abstract:
   Bidirectional Forwarding Detection (BFD) is a fault detection
   protocol that can quickly determine a communication failure between
   two forwarding engines.  This document proposes a use of the BFD Echo
   where the local system supports BFD but the neighboring system does
   not support BFD.  BFD Async procedures can be executed over the BFD
   Echo port where the neighboring system only loops packets back to the
   local system.
 
   This document updates RFC 5880.
 

   
 
 
The IETF Secretariat

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

[xiao.min2]

Jeff, Aijun,






Thank you for the comments.


Please see inline...



Original



From: JeffreyHaas 
To: Aijun Wang ;
Cc: rtg-bfd@ietf.org ;
Date: 2023年04月07日 23:27
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Aijun,
 
 
> On Apr 6, 2023, at 8:53 PM, Aijun Wang  wrote:
>> Providing additional detail to help illustrate the mechanism would be
>> in-scope and perhaps helpful.  Did you have any explicit recommendations for
>> the text?
> [WAJ] How about to refer the style of
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-00#secti
> on-8?
 
That seems reasonable.  Let's see what the authors say.
 [XM]>>> I propose to add a summary using the style suggested by Aijun into the 
end 
of section 3, highlighting how to set the fields of the BFD Unaffiliated Echo 
packets. In 
addition, I'll switch the order of section 2 and section 3 as you suggested.




Best Regards,

Xiao Min




>>> Is there any other better style to point out the update to RFC5880?
>>  
>> Unfortunately, this is a common problem for internet-drafts that impact
>> protocol state machinery.  We have either the option of trying to issue a
>> "patch" on the draft, as we're doing here, or do a -bis of the base RFC to
>> more cleanly integrate the changes.
> [WAJ] How about to give the RFC also the version attribute like the draft?
> That is to say, for such "patch" or verbose text update, once the proposed
> draft is published, the updated contents will be incorporated into the base
> RFC automatically(no need to the overall long procedures for the bis
> document), but give its one new version number?  The bit RFC document can be
> labelled with the source that the updates are coming from.
> Maybe this should be discussed in more general scope?
> The final bis RFC document will be more easily referred and readable.
 
Using IEEE documents as an example, if there is an update to the base document, 
all of the changes are included in it.  If we ever do a RFC 5880-bis, or 
potentially do work to advance BFD to Internet Standard, this might be 
reasonable to do.
 
For now, the document is consistent with procedures we see in other working 
groups.
 
-- Jeff

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

[xiao.min2]

Jeff,






Please see inline...



Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: gregimir...@gmail.com ;rtg-bfd@ietf.org 
;
Date: 2023年04月07日 23:32
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Xiao Min,

On Apr 7, 2023, at 3:15 AM, xiao.m...@zte.com.cn wrote:
That's an interesting deficiency.  I will ask Juniper BFD developers if there's 
any similar consideration for our current implementation.
"could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" is 
more appropriate?
[XM-2]>>> If we would like to use normative term for SA, then that can also 
apply to DA, suggest s/would/MUST. As Greg pointed out, there may be implicit 
conflict with RFC 5881 section 4 that says "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".




Best Regards,

Xiao Min




-- Jeff









On Apr 6, 2023, at 3:35 AM,   wrote:

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.

[XM]>>> I checked this with the implementer of this feature, and I'm told 
setting the DA to a IPv6 link local address doesn't work, because the link 
local address can't be looped back by the neighboring device.

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

[xiao.min2]

Jeff,






Please see inline...









Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: Greg Mirsky ;rtg-bfd@ietf.org ;
Date: 2023年04月11日 01:34
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)




Xiao Min,

On Apr 9, 2023, at 10:42 PM,   
wrote:







After further thought, I think copying the RFC 5881 advice is perhaps best 
answer.  It provides wisdom that attempts to avoid redirect messages.  However, 
since it's SHOULD NOT rather than MUST NOT, it doesn't make any existing 
implementations non-conformance; e.g. Broadcom.
[XM]>>> Got it. I'll copy the RFC 5881 advice.




Best Regards,

Xiao Min




-- Jeff







From: JeffreyHaas 







"could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" is 
more appropriate?

[XM-2]>>> If we would like to use normative term for SA, then that can also 
apply to DA, suggest s/would/MUST. As Greg pointed out, there may be implicit 
conflict with RFC 5881 section 4 that says "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".

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

[xiao.min2]

I am not aware of any IPR applicable to this document.






Best Regards,


Xiao Min



Original



From: JeffreyHaas 
To: draft-ietf-bfd-unaffiliated-e...@ietf.org 
;
Cc: rtg-bfd WG ;
Date: 2023年04月10日 23:27
Subject: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check


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)

[xiao.min2]

Jeff,






Thank you for the comments.


Please see inline...




Original



From: JeffreyHaas 
To: 肖敏10093570;
Cc: gregimir...@gmail.com ;rtg-bfd@ietf.org 
;
Date: 2023年04月06日 22:28
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Xiao Min,
Thanks for addressing Greg's comments.  I some additional comment on Greg's 
points:


On Apr 6, 2023, at 3:35 AM,   wrote:
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.
[XM]>>> I checked this with the implementer of this feature, and I'm told 
setting the DA to a IPv6 link local address doesn't work, because the link 
local address can't be looped back by the neighboring device.




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?

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.

[XM]>>> I propose the text change as below.


OLD

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

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. The IP source address of the BFD Unaffiliated Echo packets
 could be identical to the IP destination address or other address provisioned
 on device A.


Regards,

Xiao Min




-- Jeff












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.

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

[xiao.min2]

Hi Sasha,






Please see inline...



Original



From: AlexanderVainshtein 
To: Jeff Tantsura ;肖敏10093570;
Cc: Abhinav Srivastava ;rtg-bfd@ietf.org ;
Date: 2023年03月27日 08:55
Subject: RE: [EXTERNAL] Can a BFD session change its source port to facilitate 
auto recovery




Jeff, Xiao and all,


FWIW I concur with Jeff.


[XM]>>> Thank you for the feedback. I might be wrong, just to make things more 
clear by discussing.






It is not clear to me what exactly the reference to BFD for SR Policies means.


E.g., if Seamless BFD (RFC 7880 and RFC 7881) is used, the reflected packets 
are sent as native IPv4 or IPv6 packets and can encounter problems that are not 
related to the state of the monitored candidate path of the SR Policy.


[XM]>>> Please refer to 
https://datatracker.ietf.org/doc/draft-liu-spring-bfd-srv6-policy-encap/. 






Best Regards,


Xiao Min






My 2c,


Sasha



 



From: Jeff Tantsura  
 Sent: Monday, March 27, 2023 1:29 AM
 To: Xiao Min 
 Cc: Abhinav Srivastava ; Alexander Vainshtein 
; rtg-bfd@ietf.org
 Subject: Re: [EXTERNAL] Can a BFD session change its source port to facilitate 
auto recovery




 


Hi Xiao,


 


please see inline



 
 


On Mar 24, 2023, at 5:43 PM,   
wrote:



 


Jeff,


 


Please see inline...


Original



From: JeffTantsura 



To: 肖敏10093570;



Cc: absri...@gmail.com ;alexander.vainsht...@rbbn.com 
;rtg-bfd@ietf.org ;



Date: 2023年03月24日 16:48



Subject: Re: [EXTERNAL] Re: Can a BFD session change its source port to 
facilitate auto recovery




That’s not going to fly, number of ECMP paths in today’s networks could be 
anywhere between 2 and 500+, how many of these would you exercise, how would 
you know that you have covered all of them?


[XM]>>> The number of links/LAGs seems much higher than the number of ECMP 
paths. If otherwise I have to run SH BFD on each link/LAG, why not try to run 
MH BFD on each ECMP path? :-) As to the coverage, BFD+IOAM may help, because 
IOAM can tell you the path BFD packet really takes.









[jeff] the number of p2p connections between 2 directly attached IP end-points 
is rarely larger than 32 (either LAG or ECMP), SH BFD sessions are distributed 
across the path traversed and coherency between IP connectivity matrix and BFD 
sessions between any given pair of directly connected IP end-points can easily 
be guaranteed, end2end (MH BFD) is between non directly attached end-points and 
is subject to network topology and routing, and has to be re-evaluated on any 
change.



INT doesn’t really help here, hashing decisions are local, any changes (local 
or global) might change the hashing results, unless you build a full mesh of 
source routed paths… but then, why BFD at all, you could use INT only instead, 
take a look at HPCC draft 
 
 



The role of MH BFD is to verify reachability between 2 non directly connected 
IP end-points, not to monitor every path available.


[XM]>>> IMHO BFD for SR Policy does care about the path, and some SP's networks 
require bidirectional path consistency while employing BFD.









[jeff] how did we get to SR here? If you have got a strict source routed path, 
you only need to validate that path, if it is loose however, same issues
 
 



 


Best Regards,


Xiao Min


 


As a viable solution, run SH BFD on each link/LAG, MH BFD end2end and make sure 
your timers are aligned and not interact with each other in funny ways.


 


Cheers,


Jeff





 
 


On Mar 24, 2023, at 09:26, xiao.m...@zte.com.cn wrote:






Hi Abhinav,


 


When I come across your problem, the first idea coming into my mind is not 
trying to change the source port for a BFD session, but to run multiple BFD 
sessions between the two peers, using each BFD session to monitor a respective 
ECMP path, and then the application would not be declared in failure unless all 
the BFD sessions go down.


 


Best Regards,


Xiao Min


 









From: AbhinavSrivastava 



To: Alexander Vainshtein ;



Cc: rtg-bfd@ietf.org ;



Date: 2023年03月23日 22:27



Subject: Re: [EXTERNAL] Re: Can a BFD session change its source port to 
facilitate auto recovery




Agree that deletion and recreation (possibly automatically) by associated 
protocol is a good alternative, instead of inbuilt BFD recovery. 


 


Thanks



Abhinav





 


On Thu, 23 Mar, 2023, 3:08 am Alexander Vainshtein, 
 wrote:



Abhinav, Jeff and all,


FWIW I concur with Jeff.


 


In my experience, MH IP BFD sessions are typically used to monitor peering 
between iBGP neighbors, and when the MH IP BFD session goes down, BGP treats 
this as if its session has gone – and deletes the MH IP BFD session in question.


 


I.e., fast recovery of such a session will not happen until BGP would not 
re-create it.


 


Regards,


Sasha



 



From: Rtg-bfd  On Behalf Of Jeff Tantsura
 Sent: Thursday, March 23, 2023 8:27 AM
 To: Abhinav Srivastava 
 Cc: rtg-bfd@ietf.org
 Subject: [EXTERNAL] Re: Can a BFD session change its source port to facilitate 
auto 

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

[xiao.min2]

Aijun,






Thanks for your support and review.



Please see inline...



Original



From: AijunWang 
To: 'Jeffrey Haas' ;rtg-bfd@ietf.org ;
Date: 2023年04月04日 17:28
Subject: RE: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


Support its forwarding.
 
The implementation and deployment of unaffiliated-echo can extend the BFD
based fault detection technology in large scale, because it has no special
BFD related requirements to the other side.
 [XM]>>> I absolutely agree.




>From the description of this document, the state machine of local device is
conformed that described in RFC5880, the main standard parts of this
document are the contents of related fields within the BFD ECHO Packet. If
so, I suggested to point out these fields and its value in more explicit
manner, to facilitate the implementation interoperability.
 [XM]>>> Note that BFD Unaffiliated Echo does not use the AdminDown state.

Jeff has proposed a number of text changes to improve the readability, and I'm 
sure there is still room for improvement.




Should the section 2(update to RFC5880) be moved afterwards the section
3(Unaffiliated BFD Echo Procedures)?  
And I am worrying that is it easy for the reader/implementer to keep up with
the updated contents in current manner, because they must compare the two
documents simultaneously?  
 
Is there any other better style to point out the update to RFC5880?
 [XM]>>> There was a discussion among the authors on how to describe the 
updates to RFC 5880, and the current style was the best one we can think of. If 
there is a better style, I'm happy to do a switch.




Thanks,

Xiao Min




Best Regards
 
Aijun Wang
China Telecom
 
-Original Message-
From: rtg-bfd-boun...@ietf.org  On Behalf Of
Jeffrey Haas
Sent: Wednesday, March 22, 2023 12:02 AM
To: rtg-bfd@ietf.org
Subject: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
 
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: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

Greg,






Thank you for the detailed reply.


I suspect I've known where your concern derive from, that's a misunderstanding.


Note that the Unaffiliated BFD Echo is NOT intended to replace the BFD Echo 
function defined in RFC 5880.


I don't think an interoperability between a system using the RFC5880-style Echo 
function and a system with the unaffiliated Echo is needed.


In Figure 1, device A supports BFD and device B does not support BFD, that 
means neither device A nor device B can run RFC5880-style Echo function in this 
scenario.


With that said, I suggest to add below text into the third paragraph from the 
bottom of Introduction section, clarifying the relationship between the 
Unaffiliated BFD Echo and the RFC5880-style Echo.


NEW


The former scenario is not changed by this document in any way.







As to your new technical questions, please see inline...



Original



From: GregMirsky 
To: 肖敏10093570;
Cc: jh...@pfrc.org ;rtg-bfd@ietf.org ;
Date: 2023年04月06日 09:03
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)




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.

[XM]>>> As said above, this specification does NOT replace the Echo function 
defined in RFC 5880, it adds a new usage of BFD Echo while not affecting the 
existing one. In section 2.2 of RFC 7130 (BFD on LAG), it says "the use of the 
BFD echo function is outside the scope of this document".

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.

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




Best Regards,

Xiao Min




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 

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

[xiao.min2]

Jeff,






Thank you for initiating WGLC on this draft per request of the authors.


I support progressing this draft to publication (as a co-author).


I agree with you that the draft could use very high scrutiny.



Note that I've posted version -06 attempting to address your last call 
comments, and the detailed reply has been sent to the mailing list. Links as 
below.


https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-06 




https://mailarchive.ietf.org/arch/msg/rtg-bfd/si2-rPPZxe6l8tq8xJZEEY8DlDM/
 
Best Regards,


Xiao Min



Original



From: JeffreyHaas 
To: rtg-bfd@ietf.org ;
Date: 2023年03月22日 00:02
Subject: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)


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: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[xiao.min2]

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.




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.




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: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[xiao.min2]

Jeff, Greg,






Please see inline...



Original



From: JeffreyHaas 
To: Greg Mirsky ;
Cc: draft-ietf-bfd-unaffiliated-e...@ietf.org 
;rtg-bfd WG ;
Date: 2023年04月14日 04:10
Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check


Greg,
 
 
> On Apr 12, 2023, at 1:09 PM, Greg Mirsky  wrote:
>  
> 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?
 
The intent here is that this part of the BFD Async machinery is preserved.  My 
Discriminator is set to the known value, Your Discriminator is zero, and the 
session proceeds with the device talking to itself and resulting in My 
Discriminator and Your Discriminator getting the identical value.
 
We want to avoid re-stating RFC 5880 procedures on this point.  I realize one 
of your considerations here is likely that some BFD technologies begin by 
having out of band discriminator advertisement.
 
Would you find it helpful in illustrating the setup in bullet-point fashion as 
Aijun mentioned in prior threads?
 
>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.
 
My expectation is that there would be a single such session to a given 
destination endpoint simlar to what we see out of the usual BFD 1-hop cases.  
It'd be good to see if this matches the expectations of the authors.
 [XM]>>> My expectation is the same to Jeff. Besides, ZTE's implementation 
allows for multiple BFD Unaffiliated sessions off Interface 1, differentiated 
by IP addresses (both DA and SA), so the answer to Greg's question is Yes, 
although there is no real use till now.




Best Regards,

Xiao Min




> 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).
 
Reviewing RFC 5880, that RFC tends to use "the system".  While I find "device 
A/B" to be clear, is it your desire to see "system" to be used for consistency 
with other RFCs?
 
-- Jeff

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

[xiao.min2]

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?


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?


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.

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.

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?






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.
[XM]>>> I'd like to follow your suggestion if there is no objection from Jeff.

What is the interpretation of "expected value"? It appears that none of these 
values are used, but are ignored. Right?

[XM]>>> As indicated by Jeff, "the desire is that we avoid unset values being a 
potential vector for disclosure of uninitialized memory".

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?

[XM]>>> As indicated by Jeff, "the desire is that we avoid unset values being a 
potential vector for disclosure of uninitialized memory".

In the description



   Afterwards, the


   provisioned transmission interval is used.


What is the event that triggers the "afterward" transition?
[XM]>>> The preceding text says 

Re: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10

[xiao.min2]

Hi Magnus,






Thank you for the prompt reply.


A new version has just been posted to address your comments. Link as below.


https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-bfd-geneve-11


I also cc BFD WG to see if some new ideas can be motivated by your good 
observation.






Best Regards,


Xiao Min




Original



From: MagnusWesterlund 
To: 肖敏10093570;
Cc: tsv-...@ietf.org ;draft-ietf-nvo3-bfd-geneve@ietf.org 
;last-c...@ietf.org 
;n...@ietf.org ;
Date: 2023年07月04日 15:59
Subject: Re: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10


___
nvo3 mailing list
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

 

Hi Xiao Min,


 


I think that text is mostly fine, I would think that this RECOMMENDED needs to 
be a “MUST unless BFD is congestion controlled”. That later part as a caveat if 
one can actually deploy a BFD congestion control.  


 


I would really recommend routing area to look into this problem of how to 
separate path failures, from on path congestion (especially self inflicted), or 
endpoint overload. Which appears to be the different things desired to be 
separated for BFD.


 


Note, I don’t expect congestion control for BFD to look like TCP at all. I 
would expect it to be something may be fairly slow in reaction, which allows 
BFD in those deployments where it is needed to step down the load on the 
network and the end points to see if the failure to get all/some packets 
through are dependent on the introduced load.


 


Cheers


 


Magnus


 


 




From: xiao.m...@zte.com.cn 
 Date: Tuesday, 4 July 2023 at 08:49
 To: Magnus Westerlund 
 Cc: tsv-...@ietf.org , 
draft-ietf-nvo3-bfd-geneve@ietf.org 
, last-c...@ietf.org 
, n...@ietf.org 
 Subject: Re: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10


Hi Magnus,

 

Thank you for the review and thoughtful comments.

Please see inline.


Original



From: MagnusWesterlundviaDatatracker 



To: tsv-...@ietf.org ;



Cc: draft-ietf-nvo3-bfd-geneve@ietf.org 
;last-c...@ietf.org 
;n...@ietf.org ;



Date: 2023年07月03日 17:36



Subject: [nvo3] Tsvart last call review of draft-ietf-nvo3-bfd-geneve-10




Reviewer: Magnus Westerlund
 Review result: Not Ready
 
 This document has been reviewed as part of the transport area review team's
 ongoing effort to review key IETF documents. These comments were written
 primarily for the transport area directors, but are copied to the document's
 authors and WG to allow them to address any issues raised and also to the IETF
 discussion list for information.
 
 When done at the time of IETF Last Call, the authors should consider this
 review as part of the last-call comments they receive. Please always CC
 tsv-...@ietf.org if you reply to or forward this review.
 
 I have reviewed BFD for Geneve (draft-ietf-nvo3-bfd-geneve-10) and have one
 significant point on this protocol. So when BFD was published after quite some
 discussion about the lack of an actual congestion control mechanism in BFD in
 RFC 5880 there was agreement on the following that was included in Section 7 of
 RFC 5880:
 
When BFD is used across multiple hops, a congestion control mechanism
MUST be implemented, and when congestion is detected, the BFD
implementation MUST reduce the amount of traffic it generates.  The
exact mechanism used is outside the scope of this specification, and
the requirements of this mechanism may differ depending on how BFD is
deployed, and how it interacts with other parts of the system (for
example, exponential backoff may not be appropriate in cases where
routing protocols are interacting closely with BFD).
 
 As this usage of BFD although is point to point inside the tunnel, the fact
 that it is a tunnel and can bridge both multisegment L2 and especially IP
 networks means that this document in my view need to define how it fulfills the
 above requirements when using BFD.
 
 I do note the security consideration do note that overload is a factor due to
 multiple path sharing tunnel establishments. So there are apparently risks from
 two types of overlad situations here. First that multiple tunnles between
 endpoints are established. Secondly, that there are congestion due to network
 cross traffic on the paths the tunnels share.
 
 So I think there are two paths forward. Either restrict the applicability of
 this usage to paths where it is known to have provisioned capacity for the BFD,
 as noted as required in RFC 5881 applicability statement. The alternative is to
 extend BFD to actually have a real congestion control. Something I think would
 have benefit all considering how wide spread use there is of BFD over various
 overlay networks that really are ignoring this potential issue.

[XM]>>> I lean to the former one. Propose to add a new paragraph to the last of 
Introduction section.

NEW

As specified in Section 4.2 of [RFC8926], Geneve MUST be used with 

Fw: I-D Action: draft-ietf-bfd-unaffiliated-echo-08.txt

[xiao.min2]

Dear BFD WG,






A new -08 version of Unaffiliated BFD Echo has just been posted. Link and Diff 
as below.


This version is intended to address Greg's comments on -07 version of this 
draft.


Many thanks to Greg for his thorough review and helpful comments.






Best Regards,


Xiao Min






Original



From: internet-dra...@ietf.org 
To: i-d-annou...@ietf.org ;
Cc: rtg-bfd@ietf.org ;
Date: 2023年07月06日 10:20
Subject: I-D Action: draft-ietf-bfd-unaffiliated-echo-08.txt



A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Bidirectional
Forwarding Detection (BFD) WG of the IETF.
 
   Title   : Unaffiliated BFD Echo
   Authors : Weiqiang Cheng
 Ruixue Wang
 Xiao Min
 Reshad Rahman
 Raj Chetan Boddireddy
   Filename: draft-ietf-bfd-unaffiliated-echo-08.txt
   Pages   : 12
   Date: 2023-07-05
 
Abstract:
   Bidirectional Forwarding Detection (BFD) is a fault detection
   protocol that can quickly determine a communication failure between
   two forwarding engines.  This document proposes a use of the BFD Echo
   where the local system supports BFD but the neighboring system does
   not support BFD.  BFD Control packet and its processing procedures
   can be executed over the BFD Echo port where the neighboring system
   only loops packets back to the local system.
 
   This document updates RFC 5880.
 
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
 
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-08
 
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-08
 
Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

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

[xiao.min2]

Hi Greg,






Thank you for the continued discussion.


As to Standard vs Experimental/Informational, I've stated my opinion and no 
more to add.


For the last two remaining discussion points, please see inline [XM-5]>>>.



Original



From: GregMirsky 
To: 肖敏10093570;
Cc: rtg-bfd@ietf.org ;
Date: 2023年06月15日 20:01
Subject: Re: Fw: New Version Notification for 
draft-ietf-bfd-unaffiliated-echo-07.txt




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




































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.

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

[XM-4]>>> Let me rephrase my words. :-) As you know, BFD can be used for either 
single-hop or multi-hop fault detection, while the text says "detect faults in 
communication with adjacent devices", which means only single-hop application, 
so "in some cases". In other cases, BFD is used only for multi-hop application, 
single-hop fault detection is not needed.








GIM4>> Thank you for the clarification. In that case, perhaps can explicitly 
point to the single-hop use of the Unaffiliated BFD Echo function, avoiding 
somewhat ambiguous "in some cases".

[XM-5]>>> OK. Propose to change the text 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 

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

[xiao.min2]

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/



















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.

















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.

[XM-2]>>> OK. Please see the proposed changes as below.


OLD

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

 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 packets and what to do with them.















I hope 

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

[xiao.min2]

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?























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.

[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?






















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.

[XM-2]>>> OK. Please see the proposed changes as below.


OLD

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

 

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

[xiao.min2]

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

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

[XM-4]>>> Let me rephrase my words. :-) As you know, BFD can be used for 

Re: bfd - Not having a session at IETF 119

[xiao.min2]

Hi Jeff, Reshad,

Thanks for the great summary!
Just one small update to the wiki, the title of 
draft-ietf-bfd-unaffiliated-echo has been changed from "Unaffiliated BFD Echo 
Function" to "Unaffiliated BFD Echo" since -03 version.
Cheers,
Xiao Min

Original


From: JeffreyHaas 
To: rtg-bfd@ietf. ;
Date: 2024年02月05日 00:40
Subject: Re: bfd - Not having a session at IETF 119

While the session request tool downgraded our area director into one of the 
chairs, it's our intention to not meet at the upcoming IETF 119 in Brisbane.
Current status of the working group is on the wiki:
https://wiki.ietf.org/en/group/bfd

It's our hope that prior to IETF 119 we'll have fully updated and ready for 
last call versions of:
draft-ietf-bfd-optimizing-authentication
draft-ietf-bfd-secure-sequence-numbers
draft-ietf-bfd-stability

Once those documents have been re-issued, we'll be asking for directorate 
review for them.

draft-ietf-bfd-unaffiliated-echo has been submitted for publication by the IESG 
and we're waiting on that process.

draft-ietf-bfd-large-packets has been refreshed, has an implementation at 
Juniper and was recently updated to add a YANG module covering its behavior.  
The authors (including myself) are in discussions with Xiao Min to see if his 
recent proposal is an appropriate fit to be incorporated in this draft in some 
fashion, or whether to keep it as a separate draft.

In non-bfd WG news, RFC 9521 came out for BFD for Geneve.  Congratulations to 
the authors!

BFD for BIER is apparently ready for WGLC:
https://mailarchive.ietf.org/arch/msg/bier/j5czUxHaqJRcmnrYxe8RfqEGUm0/

draft-ietf-spring-bfd appears to be ready for WGLC:
https://mailarchive.ietf.org/arch/msg/spring/qg3anN8M8Ks-rjkpJ6pXqmyjrw4/

This bit of work in the MPLS WG has impacts on RFC 5884, BFD for MPLS LSPs:
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-lspping-norao-06

Greg has raised issues covering RFC 5884 in MPLS.  The chairs believe if any 
work needs to be done, it's best done as a -bis to RFC 5884 in BFD:
https://mailarchive.ietf.org/arch/browse/mpls/?q=draft-mirsky-mpls-bfd-bootstrap-clarify

If I've missed anything else, please let the chairs know and we'll get the wiki 
updated.

-- Jeff and Reshad


On Feb 2, 2024, at 10:24 AM, IETF Meeting Session Request Tool 
 wrote:


John Scudder, a chair of the bfd working group, indicated that the bfd working 
group does not plan to hold a session at IETF 119.This message was generated 
and sent by the IETF Meeting Session Request Tool.

Re: [mpls] Review of draft-mirsky-mpls-bfd-bootstrap-clarify

[xiao.min2]

The suggestion from Jeff and Carlos seems reasonable to me, although I was not 
involved in the former mailing-list discussion.
Best Regards,
Xiao Min


Original


From: CarlosPignataro 
To: Jeff Haas ;
Cc: m...@ietf.org ;rtg-bfd@ietf. ;
Date: 2024年02月05日 11:35
Subject: Re: [mpls] Review of draft-mirsky-mpls-bfd-bootstrap-clarify


Thanks Jeff for refreshing the cache on those mailing-list comments.I was part 
of that conversation, and frankly did not remember them — now I do. And to put 
that in perspective, that was almost 6 **years** ago! 

I also missed the Errata, which was good.
And there’s also a couple other held for doc update: 
https://www.rfc-editor.org/errata_search.php?rfc=5884 

I will start with the last bit, borrowing from your text Jeff: Carlos is also 
completely unaware of anyone experiencing any sort of confusion covering RFC 
5884 procedures other than Greg.

And also, it’s a clarification that does not hurt.

I do not feel norao impacts 5884, but at the same time bundling all the updates 
on a RFC 5884-bis sounds like a most appropriate suggestion to me. I’m happy to 
help if needed.

And to that, I’d also bundle in the changes from RFC 7726.

Thanks,

Carlos.

On Feb 4, 2024, at 11:36 AM, Jeffrey Haas  wrote:

+bfd WG.
Some original comments to Adrian were:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/SYouXfNrVyKHErqacOuM2fICzMc/

Apparently, Greg didn't consider this worth holding his peace over.

https://www.rfc-editor.org/errata/eid5085 was filed and accepted as a 
clarification for RFC 5884 as part of a prior round of this discussion.


LSP Ping is getting its norao update currently in MPLS.  While it's my opinion 
that the current set of changes to that document don't negatively impact 
backward compatibility with RFC 5884, it's a normative enough change that 
perhaps it's worth moving forward with the small updates to RFC 5884.

In my opinion, the appropriate work is to take this to BFD for RFC 5884-bis, 
which would be co-reviewed with MPLS.  I believe we can get at least one of the 
original authors to pick up that work.

That said, the BFD chairs are completely unaware of anyone experiencing any 
sort of confusion covering RFC 5884 procedures other than Greg.

-- Jeff
 

On Jan 24, 2024, at 2:55 PM, Carlos Pignataro  wrote:

Hi!

Review of   draft-mirsky-mpls-bfd-bootstrap-clarify
Version 05
TypeGetting Ready for WG Adoption
TeamMPLS WG Review Team
Reviewer:   Carlos Pignataro 

I have been asked to provide a ‘getting ready for WG adoption’ review of this 
document, on behalf of the MPLS WG review team.

There are generally two relevant questions at this stage:

1. knowing whether the document is in scope for the working group, and
2. knowing whether the document is ready to be considered for WG adoption

My perspective is that:

1. Maybe - RFC 4884, the RFC that this document would update if approved, was 
progressed as draft-ietf-bfd-mpls in the bfd wg. As such, I wonder if that 
ought to be followed here. From a practical standpoint, both WGs (mpls and bfd) 
would have to review this document, but it is a chair decision and guidance 
whether this should live in mpls or bfd (and frankly I have no strong position 
either way so long as both WGs are in the loop, simply pointing historic 
datapoints.) The document is clearly in scope on the intersection of both WGs, 
and historically was in bfd.

2. Yes – this document addresses clear clarifications for implementation 
interoperability. Granted, this protocol is deployed without these 
clarifications, but are (at least) theoretical gaps.

A couple of further comments, since I read the document. Overall, well written 
and clear, achieves its goal, and:

a. Backwards compatibility is paramount, and neither of those two words appear 
in the document. I recommend a section detailing implications.

b. Section 5, IPv6, seems like an after-though, since it is not mentioned in 
the Abstract. Further, that case and explanation is well covered in RFC 8029, 
and as such seems like a distraction.

c. There are various nits and an editorial pass would help with clarity. These 
include things like unqualified “echo reply” uses.

Thanks,

Carlos Pignataro


___
mpls mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: BFD for large packets

[xiao.min2]

Hi Jeff,

Thanks for resuming your work on this document, which seems to me a useful one.
Glad to work with you and Albert on incorporating 
draft-xiao-bfd-padding-alteration-00 into draft-ietf-bfd-large-packets if 
applicable.
Best Regards,
Xiao Min

Original


From: JeffreyHaas 
To: rtg-bfd@ietf.org ;
Cc: 肖敏10093570;
Date: 2024年01月29日 05:56
Subject: BFD for large packets

[Speaking as an individual contributor.]
 
As part of trying to push BFD WG work to conclusion, I've re-issued BFD for
large packets.  Our last big push on the document was back in 2019,
including a first and not conclusive pass toward Working Group Last Call.
 
Since then, Juniper has done an initial implementation of the draft.  Les
might find it vindicating that part of the learnings from that
implementation were that naive implementations have interesting scaling
headaches.  That said, the outcome of that work were mostly the same as the
rest of the use of BFD: you have to work based on the scaling of your
platform.  Optimization work is under way to push our scaling up, but those  
implementation details rather than something that impacts the draft text.
 
There are two lingering items Albert and I will be addressing in the near
term, both tracked in the github I did the original work in[1]:
 
1. We should add YANG support for this feature.
2. There was a request from Xiao Min to consider whether work in his padding
   alteration proposal[2] was appropriate to directly incorporate in the large
   packets draft.  Albert and I will be considering what such a fit would
   look like and work with Xiao Min on the text.
 
   Reshad had indicated back in 2019 that incorporating such changes would
   likely require polled support from the Working Group.  We'll thus do some
   text for WG review prior to including it in future versions of the draft
   directly.
 
-- Jeff
 
[1] https://github.com/jhaas-pfrc/bfd-large-packets
[2] https://datatracker.ietf.org/doc/html/draft-xiao-bfd-padding-alteration-00
 
- Forwarded message from internet-dra...@ietf.org -
 
Date: Sun, 28 Jan 2024 13: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-large-packets-03.txt
 
Internet-Draft draft-ietf-bfd-large-packets-03.txt is now available. It is a
work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF.
 
   Title:   BFD Encapsulated in Large Packets
   Authors: Jeffrey Haas
Albert Fu
   Name:draft-ietf-bfd-large-packets-03.txt
   Pages:   7
   Dates:   2024-01-28
 
Abstract:
 
   The Bidirectional Forwarding Detection (BFD) protocol is commonly
   used to verify connectivity between two systems.  BFD packets are
   typically very small.  It is desirable in some circumstances to know
   that not only is the path between two systems reachable, but also
   that it is capable of carrying a payload of a particular size.  This
   document discusses thoughts on how to implement such a mechanism
   using BFD in Asynchronous mode.
 
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/
 
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-bfd-large-packets-03.html
 
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-03
 
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
 
 
- End forwarded message -