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

[[e-mail]]

Hi Reshad,







Thank you for the quick reply.


Please see inline [XM-2]...









Original



From: ReshadRahman <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
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 <RR>.






On Monday, November 7, 2022, 02:14:05 AM EST, [e-mail] <[e-mail]> wrote:









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?




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




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




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



<RR> 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) <[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