Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Anoop Ghanwani <[e-mail]>]

I support the publication of this draft.  I have the following comments
and suggested edits.

--

Technical comments

Section 4.1

I find this statement confusing

   While "local-bias" MUST be supported along with GENEVE encapsulation,
   the use of the Ethernet option-TLV is RECOMMENDED to follow the same
   procedures used by EVPN MPLS.


I'm not sure how it helps to carry an extra TLV when it is known
that its absence or presence results in identical behavior.

I also find the encoding confusing.  Why is the Type=0, instead of
using EVPN-OPTION with a length of 0x1 instead of 0x2?
What does Type=0 indicate?  Is this assigned by IANA?

Section 6

What is inter-AS option B?  Can we provide a reference?

Section 8

Doesn't IANA also need to allocate a codepoint for the
EVPN-OPTION type?

--

Editorial comments

Entire document

- 3 of the references listed as drafts are now RFCs.  Those should
  be fixed both in the reference section and in the text.

- There are several uses of GENEVE and Geneve in the document.
  Recommend replacing GENEVE with Geneve, including in the
  abbreviations and terminology section.

Section 1

Change

   This EVPN control plane extension will allow an NVE to express what
   Geneve option TLV types it is capable of receiving from, or sending
   to, over the Geneve tunnel with its peers.

To

   This EVPN control plane extension will allow an NVE to express what
   Geneve option TLV types it is capable of receiving or sending
   over the Geneve tunnel with its peers.


Section 4

Change

   This document adds an extension to the [I-D.ietf-nvo3-geneve
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-03#ref-I-D.ietf-nvo3-geneve>]
   encapsulation that are relevant to the operation of EVPN.

To

   This document adds an extension to the [I-D.ietf-nvo3-geneve
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-03#ref-I-D.ietf-nvo3-geneve>]
   encapsulation that is relevant to the operation of EVPN.

End

Section 4.1

Change

   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses
   ingress replication to flood unknown unicast traffic to the egress
   NVEs, the ingress NVE needs to indicate to the egress NVE that the
   Encapsulated packet is a BUM traffic type.

To

   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses
   ingress replication to flood unknown unicast traffic to the egress
   NVEs, the ingress NVE needs to indicate to the egress NVE that the
   Encapsulated packet is a BUM packet.


Change

   For GENEVE, we need a bit to for this purpose.

To

   For GENEVE, we need a bit for this purpose.


Expand first use of AC and add to abbreviations and terminology.

ecnapsulations -> encapsulations


GENVE -> Geneve

(There are 2 instances of this.)


"20- bit MPLS label" -> "20-bit MPLS label"


Add figure captions for the 2 figures showing the TLVs.

Expand first use of ES and ESI and add to abbreviations and terminology.

Change

   The ESI-label value is encoded in the high-order 20 bits
   of the Source-ESI field.

To

   The ESI-label value is encoded in the high-order 20 bits
   of the Source-ID field.


Change

   The egress NVEs that make use of ESIs in the data path because they
   have a local multi-homed ES or support [RFC8317
<https://datatracker.ietf.org/doc/html/rfc8317>] SHOULD advertise
   their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV
   and in addition to the ESI-label Extended Community.

Remove "and".

On Mon, Sep 27, 2021 at 11:02 PM <[e-mail]> wrote:

> Hi,
>
>
>
> This email starts a two-week working group last call for draft-ietf-bess-evpn-vpws-fxc [1]
>
>
>
> Please review the draft and send any comments to the BESS list. Also, please indicate if you support publishing the draft as a Standards Track RFC.
>
>
>
> This poll runs until the 12th October 2021.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The document won't progress without answers from all the authors and contributors.
>
> There are currently two IPR disclosures.
>
>
>
> In addition, we are polling for knowledge of implementations of this draft, per the BESS policy in [2].
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>