Hi Xiao Min,
Thanks for the prompt response. Inline <RR>.
On Monday, November 7, 2022, 02:14:05 AM EST, [email protected]
<[email protected]> wrote:
Hi Reshad,
Thank you for the thorough review and thoughtful comments.
Please see inline...
Best Regards,
Xiao Min
OriginalFrom: ReshadRahman <[email protected]>To: NVO3
<[email protected]>;[email protected] <[email protected]>;Bocci, Matthew (Nokia - GB)
<[email protected]>;Date: 2022年11月07日 00:06Subject: Re: Extending WG LC
for draft-ietf-nvo3-bfd-geneve by two weeksHi,
- 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.
- 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.
- 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.
Regards,Reshad.
Regards,Reshad.
On Friday, October 21, 2022, 05:37:22 AM EDT, Bocci, Matthew (Nokia - GB)
<[email protected]> 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
