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

[Jeffrey Haas <[e-mail]>]

Xiao Min,

On Sat, Nov 05, 2022 at 01:00:27PM +0800, [e-mail] wrote:
> 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.

The BFD for VXLAN procedures would similarly need to apply this type of
demultiplexing.  However, that document didn't list those details.
Perhaps listing them in the geneve document is clearer.

That said, if this is the case, shouldn't there also be discussion about the
Inner VLAN tag portion of the Inner Ethernet Header?

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

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

There normally isn't a default source port - its value is simply expected to
be in the ephemeral port range.

By listing it in the configuration and demultiplexing procedures, it becomes
additional configuration that must be consistent between each side of a BFD
session.

---

If the NVO3 Working Group is comfortable with all of the requirements for
session configuration, the procedures are fine for BFD.  I believe this
brings me to my final comment, which may be raised by the Area Directors as
well as part of their review: There is no YANG module for this feature.

I don't believe the IESG is requiring YANG modules at this time.  BFD for
VXLAN itself doesn't have a YANG module.  However, the creation of such a
module would highlight what the configuration parameters are for this
document.

Perhaps the NVO3 group should consider such a YANG module for the future.

-- Jeff