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

[[e-mail]]

Hi Reshad,






Thank you for the thorough review and thoughtful comments.


Please see inline...





Best Regards,


Xiao Min



Original



From: ReshadRahman <reshad=[e-mail]>
To: NVO3 <[e-mail]>;[e-mail] <[e-mail]>;Bocci, Matthew (Nokia - GB) <[e-mail]>;
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) <[e-mail]> 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