[bess] Re: John Scudder's Abstain on draft-ietf-bess-evpn-vpws-fxc-11: (with COMMENT)

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi John,

With regard to your comment on the clarity of this document as a whole from an implementer perspective, I just want to mention that you can consider this document as a second order of derivatives wrt EVPN baseline RFC7432 (with RFC8214 being the first order of derivatives wrt RFC7432).  As such, it is assumed that the reader is fluent in RFC7432 and RFC8214. If you think this point is not clear, then we can add couple of sentences to the introduction to make it explicit.

Regards,
Ali

From: John Scudder <[e-mail]>
Date: Thursday, December 5, 2024 at 10:28 AM
To: Luc André Burdet <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [bess] John Scudder's Abstain on draft-ietf-bess-evpn-vpws-fxc-11: (with COMMENT)
Hi Luc André,

Yes you’re right about the nature of the Abstain. While I’m reviewing the full update I’ll give it a think and see if I can come up with something. It may be a few days.

—John


On Dec 5, 2024, at 1:12 PM, Luc André Burdet <[e-mail]> wrote:

[External Email. Be cautious of content]

Hi John,

Thanks for the rapid back-and-forth this morning regarding the Discuss and other comments below – I have addressed them all in latest.
The underlying reason for the Abstain, as I read it, it a little general in nature and not pertaining to a specific section but rather with the document “when read as a whole”.

Other than resolving the few nits below, would you have other suggestions regarding clarity issues that could enhance legibility or implementatbility in your view?

Regards,
Luc André

Luc André Burdet |  Cisco  |  [e-mail]  |  Tel: [phone]


From: John Scudder via Datatracker <[e-mail]>
Date: Thursday, December 5, 2024 at 11:10
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [bess] John Scudder's Abstain on draft-ietf-bess-evpn-vpws-fxc-11: (with COMMENT)
John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-vpws-fxc-11: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!Ai4e_DsS-aMppWiND_isTfAXP6ZQKjygRv_zji68kwVj1hRa7W62y3p2ZzmUkPCxrC4_tAoK209tbbpsYxEx$>
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/__;!!NEt6yMaO-gk!Ai4e_DsS-aMppWiND_isTfAXP6ZQKjygRv_zji68kwVj1hRa7W62y3p2ZzmUkPCxrC4_tAoK209tbQX5equU$>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Sorry for the noise -- because I was trying to multitask a little too much, I
improperly moved from DISCUSS to NOOBJ when what I intended was ABSTAIN. To
repeat the reasoning for the ABSTAIN, from my earlier ballot:

"After having reviewed this document, I can say that if I were a coder handed
this spec and told to implement it, I'd have a hard time. What I can't
determine is whether the spec is insufficient, or if it would be OK if I were
an experienced EVPN coder who had already memorized all the other specs.

"The top bullet on the IESG DISCUSS criteria list is "The specification is
impossible to implement due to technical or clarity issues." Because of the
ambiguity mentioned above, and because of the difficulty in providing you a
specific action plan to resolve it, I ultimately plan to ballot ABSTAIN on this
document."

I will review the current revision (I haven't done a full re-review yet) and
see if the updates allow me to move to NOOBJ.

## COMMENT

### Section 1

   Some service providers have very large number of ACs (in millions)
   that need to be back hauled across their MPLS/IP network.  These ACs
   may or may not require tag manipulation (e.g., VLAN translation).
   These service providers want to multiplex a large number of ACs
   across several physical interfaces spread across one or more PEs
   (e.g., several Ethernet Segments) onto a single VPWS service tunnel
   in order to a) reduce number of EVPN service labels associated with
   EVPN-VPWS service tunnels and thus the associated OAM monitoring, and
   b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is
   the case in [RFC8214]).

As far as I can tell, (b) isn't satisfied by the "VLAN-Signaled Flexible
Xconnect" mode, because in that mode "the PE sends a single Ethernet A-D per
EVI route for each AC that is configured".

I don't have a problem with you providing a menu of different options to meet
different operators' needs, but I think the Introduction should be clearer
about this.

As an aside, I found the "some service providers... these service provider"
writing style of the Introduction to be unusual and a little distracting.

### Section 1.1, terms that aren't needed here

These terms are defined, never referenced:

- CE
- EPL

These terms are defined, only used once, so you might as well just expand them
in-line:

- EVPL (already expanded in-line)
- L2 (your single use is in a diagram, so if you don't want to clutter it, OK,
  though the expansion would fit. But unlike many of the abbreviations in this
  document, I don't think this one actually needs definition.)
- MTU (same comment as for L2. This one is starred as "well-known" on the RFCEd
  list of abbreviations. I've asked the RFCEd why "L2" isn't starred.)
- VCCV

PW is used twice but really, there is no savings in time, space, or
readability, from defining and then using an initialism. I suggest just writing
out "pseudowire" those two places. One of them precedes the definition anyway.

RT is used 3x but defined in-line each time so you don't need a definition here.

VRF has a typo. You've called it "Virtual Route Forwarding". But
https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list<https://urldefense.com/v3/__https:/www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list__;!!NEt6yMaO-gk!Ai4e_DsS-aMppWiND_isTfAXP6ZQKjygRv_zji68kwVj1hRa7W62y3p2ZzmUkPCxrC4_tAoK209tbdpTVrIf$> says it is "Virtual
Routing and Forwarding". Although RFC 4364 is the authority AFAICT and it says
"VPN Routing and Forwarding table" which I think is better -- "table" is
important.

### Section 3.1, VLAN-Aware bundle

I can't understand what this means:

   *  VLAN-Aware Bundle : a unique value for individual VLANs, and is
      considered same as the normalised VID.

I was hoping it would become clear as I read the rest of the document, but it
didn't. Indeed this is the only place "VLAN-Aware Bundle" is mentioned.

### Section 3.1, ASBR

Please expand ASBR on use.

### Section 3.2, how do PEs know about VLAN mappings?

   Regarding the data-plane aspects of this solution, both imposition
   and disposition Provider Edge (PE) devices MUST be aware of the VLANs
   as the imposition PE performs VID normalization and the disposition
   PE carries out VID lookup and translation.

I guess the assumption is that this is done through configuration, hopefully
through a management system. I think the document really has to say this
somewhere, even if the precise means of doing it is out of scope. It seems like
a fundamental assumption, but it's never spelled out.

### Section 3.2, SHOULD ideally

                                               There SHOULD ideally be a
   single point-to-point (P2P) EVPN VPWS service tunnel between a pair
   of PEs for a specific set of Attachment Circuits (ACs).

It's hard for me to understand this use of RFC 2119 SHOULD. Normally RFC 2119
keywords tell the protocol implementor what to do. I don't see how an
implementor could do anything with this, though. Sometimes, RFC 2119 keywords
are (ab)used to tell operators how to deploy a solution. I *think* that's what
you're doing here, but if so I think at a minimum, you have to be much clearer
about that, something like, "When deploying the solution, the operator SHOULD
ideally provision a single..." I also encourage you to drop the RFC 2119
keyword, and just use "should".

### Section 3.2 VID-VRF

I think you need to put "VID-VRF" in your Terminology section, or otherwise
define it.

### Section 5, VCCV-BFD

You mention VCCV-BFD, but you don't have a reference for it. Please add one.

### Section 5, switchover procedure

                                                                the
   switch over procedure to the backup S-PE is the same as the one
   described above.

I don't see any switchover procedure described above. What am I missing?

## NITS

- In Section 3.2, "The generated EVPN route is an Ethernet A-D per EVI route
with and ESI of 0" should be "The generated EVPN route is an Ethernet A-D per
EVI route with an ESI of 0" ("an" not "and").



_______________________________________________
BESS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]