Jeff,
Thank you for the thorough review and thoughtful comments.
Please see inline...
Best Regards,
Xiao Min
Original
From: JeffreyHaas <jh...@pfrc.org>
To: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>;
Cc: NVO3 <nvo3@ietf.org>;rtg-...@ietf.org <rtg-...@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 +0000, 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
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
