Skip to main content

Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks
draft-ietf-nvo3-evpn-applicability-06

Revision differences

Document history

Date Rev. By Action
2023-09-18
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-08-28
06 (System) RFC Editor state changed to AUTH48
2023-06-13
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-05-05
06 (System) IANA Action state changed to No IANA Actions from In Progress
2023-05-03
06 (System) RFC Editor state changed to EDIT
2023-05-03
06 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-05-03
06 (System) Announcement was received by RFC Editor
2023-05-03
06 (System) IANA Action state changed to In Progress
2023-05-03
06 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2023-05-03
06 Cindy Morgan IESG has approved the document
2023-05-03
06 Cindy Morgan Closed "Approve" ballot
2023-05-03
06 Cindy Morgan Ballot approval text was generated
2023-04-28
06 (System) Removed all action holders (IESG state changed)
2023-04-28
06 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-04-28
06 Jorge Rabadan New version available: draft-ietf-nvo3-evpn-applicability-06.txt
2023-04-28
06 Jorge Rabadan New version accepted (logged-in submitter: Jorge Rabadan)
2023-04-28
06 Jorge Rabadan Uploaded new revision
2023-04-27
05 (System) Changed action holders to Jorge Rabadan, Matthew Bocci, Sami Boutros, Ali Sajassi (IESG state changed)
2023-04-27
05 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2023-04-27
05 Paul Wouters
[Ballot comment]
Abstract:

I find the "Conclusion" section (with the word 'justifies' replaced
with 'documents') a clearer Abstract of the document than the
current Abstract. …
[Ballot comment]
Abstract:

I find the "Conclusion" section (with the word 'justifies' replaced
with 'documents') a clearer Abstract of the document than the
current Abstract. Maybe move the Conclusion as Abstract, and move
some technical details of the current Abstract to the Introduction?

Section 1:

        TOR/Leaf switches

I had to follow the link a few sentences down to RFC 7365 to realize
TOR here does not mean Tor Onion Routing but Top of Rack switch.

RFC 7365 uses "ToR" and not "TOR" as well. So maybe expand and fix
the capitalization.

Section 2:

The terminology is listed alphabetically, but some items are referred
in items before they are explained. It might be better to re-order
them. But perhaps not - me as a newbie in this space didn't know any,
but perhaps people familiar with terms find this sorting method easier
to use when reading the document.


        NVO3 tunnels or simply Overlay tunnels will be used interchangeably

Why not stick to one term for simplicity ?
2023-04-27
05 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2023-04-27
05 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document.  I only have minor, editorial type comments.

Minor level comments:                  …
[Ballot comment]
Hi,

Thanks for this document.  I only have minor, editorial type comments.

Minor level comments:                                                                                                                                                                                                                                       
                                                                                                                                                                                                                                                           
(1) p 6, sec 3.  Why is EVPN Needed in NVO3 Networks?                                                                                                                                                                                                       
                                                                                                                                                                                                                                                           
  Why is a control-plane protocol along with NVO3 tunnels required?                                                                                                                                                                                       
  There are three main reasons:                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                           
Given that you give an example of why a control-plane protocol isn't required for the first two, would it be fairer to write 'helpful' or 'useful' rather than 'required'?                                                                             


(2) p 23, sec 6.  Conventions Used in this Document

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in BCP
  14
[RFC2119] [RFC8174] when, and only when, they appear in all
  capitals, as shown here.

It is really unusual to have this boilerplate text need the end of the document, I don't recall seeing it done in other RFCs.  It would probably be better before the current section 2, or as part of the current section 2.

Nit level comments:

(3) p 6, sec 3.  Why is EVPN Needed in NVO3 Networks?

  On this architecture and as discussed by [RFC7364], multi-tenant
  intra-subnet and inter-subnet connectivity services are provided by
  NVO3 tunnels, being VXLAN [RFC7348] or GENEVE [RFC8926] two examples
  of such tunnels.

The latter part of the sentence (, being ...) doesn't scan well for me.


(4) p 7, sec 3.  Why is EVPN Needed in NVO3 Networks?

  *  "Flood and learn" solves the issues of auto-discovery and learning
      of the MAC to VNI/tunnel IP mapping on the NVEs for a given
      Broadcast Domain.  However, it does not provide a solution for
      advanced features and it does not scale well (mostly due to the
      need for constant flooding and the underlay PIM states that are
      needed to maintain).

I suggest "must be maintained" rather than "needed to maintain".

Regards,
Rob
2023-04-27
05 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2023-04-27
05 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2023-04-26
05 John Scudder
[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-nvo3-evpn-applicability-05
CC @jgscudder

Thanks for this document, I found it easy to read and understand, which …
[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-nvo3-evpn-applicability-05
CC @jgscudder

Thanks for this document, I found it easy to read and understand, which is a real credit to the authors considering the complexity of the subject matter. I have some minor comments below which I hope may be helpful.

## COMMENTS

### Section 2, spelling of "Clos"

You've spelled "Clos" as "CLOS" as if it were an acronym. It's not, it's the inventor's name (indeed you've cited him, [CLOS1953]) so should be spelled mixed-case. (https://en.wikipedia.org/wiki/Clos_network, https://en.wikipedia.org/wiki/Clos). (Also in Section 3.)

### Section 2, sorting

I found this section very useful. It looks like it started out sorted alphabetically but the sorting falls apart part-way through? It would be even more useful if the sorting were maintained.

### Section 2, VIDs

Seems like "VIDs" needs a definition also.

### Section 2, 2119 keyword

You have a MUST in your definition of Ethernet Tag. Since as you rightly say in your abstract, "This document does not introduce any new procedures in EVPN", you probably don't need that MUST, I suggest making it some plain-English word, either "must" or "has to", for instance.

If you make that change, then you can and should remove Section 6 (the 2119 citation).

### Section 3, "fairly optimal"

"Fairly optimal" gave me a smile, if one is strict about the meaning of "optimal" it's kind of a contradiction, like "orthogonal but related". :-) It's clear from context so leave it if you like, fine with me, but if you want a replacement it could be "... ECMP generally distributes utilization well across all the links".

### Section 3, PIC ref

You might want to add a reference for PIC.

### Section 3, MAP/IP

Did you mean MAC/IP? (Also in Section 5.) If not, then please say what MAP/IP is?

### Section 4.1, confusing description of RT-1

I don't understand what you mean by "Multi-homing: Per-ES: Mass withdrawal". I guess maybe it means something like

Multi-homing:
Per-ES: Mass withdrawal
Per-EVI: aliasing/backup

But (assuming that's right) without the additional context of whitespace/indents, I think it's not straightforwardly or unambiguously understandable. You might need to write this out in complete sentences.

### Section 4.3, confusing sentence

I couldn't make out what you meant by

          EVPN uses MAC/IP Advertisement and IP Prefix routes for the
  exchange of host IP routes (in the case of the MAC/IP Advertisement
  and the IP Prefix routes)
 
The problematic bit is the stuff in parentheses. It parses as meaning that host routes are used in the case of IP Prefix routes, which makes no sense. This sentence probably needs a rewrite for clarity.

### Section 4.7.2 bug in description of MAC duplication extension

I was surprised by this,

                                                the NVE may install it
  as a black-hole MAC and drop received frames with source MAC address
  and destination MAC address matching that duplicate MAC
 
since it implies only the case SA == DA == duplicate MAC is covered. Looking at rfc7432bis S. 15.3, the actual condition is SA == dup MAC || DA == dup MAC, so perhaps change the "and" to "or" in the quoted text.

Also you might as well cite the relevant section and not just rfc7432bis, to save the reader the effort of searching for it.

Also you may want to consider rewording "black-hole" in some other way (others may also flag this, and so might the RFC Editor).

### Section 4.7.5, ES2?

When you write ES2, did you mean ESI? (If not, what did you mean?)

### Section 4.7.6, GW

You don't expand or gloss "GW" anywhere. Yes it's pretty common usage, but I think it bears expanding on first use.

### Section 4.7.8, "often"?

You have,

  Tenant Layer-2 and Layer-3 services deployed on NVO3 networks must be

wouldn't it be right to insert "often", as in

  Tenant Layer-2 and Layer-3 services deployed on NVO3 networks must often be

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
2023-04-26
05 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2023-04-26
05 Andrew Alston Changed consensus to Yes from Unknown
2023-04-25
05 Roman Danyliw
[Ballot comment]
Thank you to Kyle Rose for the SECDIR review.

** Section 1.  Editorial. Consider either expanding “TOR” (which I first read as an …
[Ballot comment]
Thank you to Kyle Rose for the SECDIR review.

** Section 1.  Editorial. Consider either expanding “TOR” (which I first read as an onion routing protocol) or use the “ToR” spelling that comes from https://www.rfc-editor.org/materials/abbrev.expansion.txt.

** Section 3.  Typo. s/addresss/addresses/

** Section 4.4

  The Generic Network Virtualization Encapsulation [RFC8926] has been
  recommended to be the proposed standard for NVO3 Encapsulation.

Recommended how?

** Section 4.4

  The NVO3 encapsulation design team has made a recommendation in
  [I-D.ietf-nvo3-encap] for a control plane to:

Practically, isn’t this a WG document?  Shouldn’t this document make these recommendations?
2023-04-25
05 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2023-04-24
05 Lars Eggert
[Ballot comment]
# GEN AD review of draft-ietf-nvo3-evpn-applicability-05

CC @larseggert

Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/aaqvb7lSJAu_1M2KpEt2AVal4bQ). …
[Ballot comment]
# GEN AD review of draft-ietf-nvo3-evpn-applicability-05

CC @larseggert

Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/aaqvb7lSJAu_1M2KpEt2AVal4bQ).

## Comments

### Section 2, paragraph 17
```
    *  Ethernet Tag: Used to represent a Broadcast Domain that is
        configured on a given ES for the purpose of Designated Forwarder
        election.  Note that any of the following may be used to represent
        a Broadcast Domain: VIDs (including Q-in-Q tags), configured IDs,
        VNIs (Virtual Extensible Local Area Network (VXLAN) Network
        Identifiers), normalized VIDs, I-SIDs (Service Instance
        Identifiers), etc., as long as the representation of the Broadcast
        Domains is configured consistently across the multihomed PEs
        attached to that ES.  The Ethernet Tag value MUST be different
        from zero.
```
The "MUST" in the last sentence is the only RFC2119 keyword in the document.
Can we rephrase to avoid it, and loose the BCP14 boilerplate text entirely?
(You could IMO just remove the entire last sentence.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2, paragraph 19
```
-      Route-Distinghisher (RD) and Route-Target(s) (RTs) are required
-                    ^
+      Route-Distinguisher (RD) and Route-Target(s) (RTs) are required
+                    ^
```

#### Section 2, paragraph 21
```
-      Route Distinghisher (RD) and Route Target(s) (RTs) are required
-                    ^
+      Route Distinguisher (RD) and Route Target(s) (RTs) are required
+                    ^
```

#### Section 3, paragraph 9
```
-          configured egress NVE destination IP addresss in the Broadcast
-                                                      -
```

#### Section 4.7.5, paragraph 3
```
-    *  All-active multi-homing means per-flow load-balanding for unicast
-                                                        ^
+    *  All-active multi-homing means per-flow load-balancing for unicast
+                                                        ^
```

### Outdated references

Document references `draft-sajassi-bess-secure-evpn-05`, but `-06` is the
latest available revision.

Document references `draft-ietf-bess-evpn-lsp-ping-08`, but `-09` is the latest
available revision.

Document references `draft-ietf-bess-evpn-geneve-04`, but `-05` is the latest
available revision.

Document references `draft-ietf-bess-rfc7432bis-04`, but `-07` is the latest
available revision.

Document references `draft-ietf-bess-evpn-pref-df-09`, but `-10` is the latest
available revision.

Document references `draft-ietf-nvo3-encap-08`, but `-09` is the latest
available revision.

Document references `draft-ietf-bess-evpn-irb-mcast-07`, but `-09` is the
latest available revision.

Document references `draft-ietf-bess-evpn-mvpn-seamless-interop-04`, but `-05`
is the latest available revision.

### Grammar/style

#### Section 2, paragraph 19
```
VRF and they are normally different than the ones defined in the associated
                                    ^^^^
```
Did you mean "different from"? "Different than" is often considered colloquial
style.

#### Section 3, paragraph 1
```
nels. When the destination host replies back and the frames arrive at the NVE
                                ^^^^^^^^^^^^
```
Consider using "replies".

#### Section 4.1, paragraph 2
```
, where MACs and the information to setup flooding trees are distributed by M
                                    ^^^^^
```
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

#### Section 4.2.2, paragraph 1
```
in MAC/IP Advertisement routes in a similar way. * The remote NVEs can then
                              ^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

#### Section 4.3, paragraph 5
```
3. In addition, NVE2 would advertise a IP Prefix route with TS3's IP address
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.7.2, paragraph 3
```
iven Broadcast Domain. For instance, an virtual-switch NVE that learns all it
                                    ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 4.7.4, paragraph 3
```
RFs in NVE1 and NVE2 are connected by a SBD (Supplementary Broadcast Domain)
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2023-04-24
05 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2023-04-20
05 Jim Guichard
[Ballot comment]
This is a nicely written document and I have no specific technical comments. From an editorial perspective:

- The placement of Section 6 …
[Ballot comment]
This is a nicely written document and I have no specific technical comments. From an editorial perspective:

- The placement of Section 6 "Conventions Used in this Document" is odd as it appears after the conclusion section of the document. I would suggest moving it closer to the beginning of the document.
- There are several references that are outdated so please correct these:

  == Outdated reference: A later version (-09) exists of
    draft-ietf-nvo3-encap-08

  == Outdated reference: A later version (-09) exists of
    draft-ietf-bess-evpn-lsp-ping-08

  == Outdated reference: A later version (-10) exists of
    draft-ietf-bess-evpn-pref-df-09

  == Outdated reference: A later version (-09) exists of
    draft-ietf-bess-evpn-irb-mcast-07

  == Outdated reference: A later version (-05) exists of
    draft-ietf-bess-evpn-geneve-04

  == Outdated reference: A later version (-05) exists of
    draft-ietf-bess-evpn-mvpn-seamless-interop-04

  == Outdated reference: A later version (-06) exists of
    draft-sajassi-bess-secure-evpn-05

  == Outdated reference: A later version (-07) exists of
    draft-ietf-bess-rfc7432bis-04
2023-04-20
05 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2023-04-05
05 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2023-04-01
05 Andrew Alston Placed on agenda for telechat - 2023-04-27
2023-04-01
05 Andrew Alston Ballot has been issued
2023-04-01
05 Andrew Alston [Ballot Position Update] New position, Yes, has been recorded for Andrew Alston
2023-04-01
05 Andrew Alston Created "Approve" ballot
2023-04-01
05 Andrew Alston IESG state changed to IESG Evaluation from Waiting for Writeup
2023-04-01
05 Andrew Alston Ballot writeup was changed
2022-12-26
05 Bernie Volz Request closed, assignment withdrawn: Zhen Cao Last Call INTDIR review
2022-12-26
05 Bernie Volz Closed request for Last Call review by INTDIR with state 'Withdrawn': Request is 6 months old with no action.
2022-09-01
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2022-09-01
05 Jorge Rabadan New version available: draft-ietf-nvo3-evpn-applicability-05.txt
2022-09-01
05 Jorge Rabadan New version approved
2022-09-01
05 (System) Request for posting confirmation emailed to previous authors: Ali Sajassi , Jorge Rabadan , Matthew Bocci , Sami Boutros
2022-09-01
05 Jorge Rabadan Uploaded new revision
2022-07-11
04 Kyle Rose Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Kyle Rose. Sent review to list.
2022-07-11
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-07-09
04 Scott Bradner Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Scott Bradner. Sent review to list.
2022-07-06
04 Reese Enghardt Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Reese Enghardt. Sent review to list.
2022-06-30
04 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2022-06-30
04 Michelle Thangtamsatid
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-nvo3-evpn-applicability-04, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-nvo3-evpn-applicability-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist
2022-06-30
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kyle Rose
2022-06-30
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kyle Rose
2022-06-30
04 Jean Mahoney Request for Last Call review by GENART is assigned to Reese Enghardt
2022-06-30
04 Jean Mahoney Request for Last Call review by GENART is assigned to Reese Enghardt
2022-06-29
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2022-06-29
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2022-06-27
04 Bernie Volz Request for Last Call review by INTDIR is assigned to Zhen Cao
2022-06-27
04 Bernie Volz Request for Last Call review by INTDIR is assigned to Zhen Cao
2022-06-27
04 Éric Vyncke Requested Last Call review by INTDIR
2022-06-27
04 Amy Vezza IANA Review state changed to IANA - Review Needed
2022-06-27
04 Amy Vezza
The following Last Call announcement was sent out (ends 2022-07-11):

From: The IESG
To: IETF-Announce
CC: Sam Aldrin , aldrin.ietf@gmail.com, andrew-ietf@liquid.tech, draft-ietf-nvo3-evpn-applicability@ietf.org, …
The following Last Call announcement was sent out (ends 2022-07-11):

From: The IESG
To: IETF-Announce
CC: Sam Aldrin , aldrin.ietf@gmail.com, andrew-ietf@liquid.tech, draft-ietf-nvo3-evpn-applicability@ietf.org, nvo3-chairs@ietf.org, nvo3@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Applicability of EVPN to NVO3 Networks) to Informational RFC


The IESG has received a request from the Network Virtualization Overlays WG
(nvo3) to consider the following document: - 'Applicability of EVPN to NVO3
Networks'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-07-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In NVO3 networks, Network Virtualization Edge (NVE) devices sit at
  the edge of the underlay network and provide Layer-2 and Layer-3
  connectivity among Tenant Systems (TSes) of the same tenant.  The
  NVEs need to build and maintain mapping tables so that they can
  deliver encapsulated packets to their intended destination NVE(s).
  While there are different options to create and disseminate the
  mapping table entries, NVEs may exchange that information directly
  among themselves via a control-plane protocol, such as Ethernet
  Virtual Private Network (EVPN).  EVPN provides an efficient, flexible
  and unified control-plane option that can be used for Layer-2 and
  Layer-3 Virtual Network (VN) service connectivity.  This document
  describes the applicability of EVPN to NVO3 networks and how EVPN
  solves the challenges in those networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-evpn-applicability/



No IPR declarations have been submitted directly on this I-D.




2022-06-27
04 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2022-06-27
04 Andrew Alston Last call was requested
2022-06-27
04 Andrew Alston Ballot approval text was generated
2022-06-27
04 Andrew Alston Ballot writeup was generated
2022-06-27
04 Andrew Alston IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2022-06-27
04 Andrew Alston Last call announcement was generated
2022-06-21
04 Jorge Rabadan New version available: draft-ietf-nvo3-evpn-applicability-04.txt
2022-06-21
04 Jorge Rabadan New version accepted (logged-in submitter: Jorge Rabadan)
2022-06-21
04 Jorge Rabadan Uploaded new revision
2022-06-19
03 Andrew Alston Awaiting follow-up on feedback received in last call routing area directorate review.
2022-06-19
03 Andrew Alston IESG state changed to AD Evaluation::AD Followup from Publication Requested
2022-06-02
03 Mach Chen Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Mach Chen. Sent review to list.
2022-06-01
03 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Mach Chen
2022-06-01
03 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Mach Chen
2022-06-01
03 Mohamed Boucadair Assignment of request for Last Call review by RTGDIR to Mohamed Boucadair was rejected
2022-06-01
03 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Mohamed Boucadair
2022-06-01
03 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Mohamed Boucadair
2022-05-24
03 Andrew Alston Requested Last Call review by RTGDIR
2022-03-23
03 Amy Vezza Changed action holders to Andrew Alston
2022-03-23
03 Amy Vezza Shepherding AD changed to Andrew Alston
2021-03-08
03 (System) Changed action holders to Martin Vigoureux (IESG state changed)
2021-03-08
03 Martin Vigoureux IESG state changed to Publication Requested from Dead
2020-11-02
03 Jorge Rabadan New version available: draft-ietf-nvo3-evpn-applicability-03.txt
2020-11-02
03 (System) New version approved
2020-11-02
03 (System) Request for posting confirmation emailed to previous authors: Ali Sajassi , Jorge Rabadan , Matthew Bocci , Sami Boutros , nvo3-chairs@ietf.org
2020-11-02
03 Jorge Rabadan Uploaded new revision
2020-06-23
02 (System) Document has expired
2020-06-23
02 (System) IESG state changed to Dead from AD is watching
2020-06-22
02 Martin Vigoureux IESG state changed to AD is watching from AD Evaluation
2020-03-26
02 Martin Vigoureux IESG state changed to AD Evaluation from Publication Requested
2020-03-26
02 Martin Vigoureux This document now replaces draft-rabadan-nvo3-evpn-applicability instead of None
2019-10-08
02 Amy Vezza Intended Status changed to Informational from None
2019-10-08
02 Sam Aldrin
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
> Informational. This is indicated on the title page, correctly.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
>In NVO3 networks, Network Virtualization Edge (NVE) devices sit at the edge of the underlay network and provide Layer-2 and Layer-3 connectivity among Tenant Systems (TSes) of the same tenant. The NVEs need to build and maintain mapping tables so that they can deliver encapsulated packets to their intended destination NVE(s). While there are different options to create and disseminate the mapping table entries, NVEs may exchange that information directly among themselves via a control-plane protocol, such as EVPN. EVPN provides an efficient, flexible and unified control-plane option that can be used for Layer-2 and Layer-3 Virtual Network (VN) service connectivity. This document describes the applicability of EVPN to NVO3 networks and how EVPN solves the challenges in those networks.


Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
> This document was extensively discussed within NVo3. Held a round table workshop like session during IETF 97 to discuss Control plane requirements and solutions. Gathered all the requirements and decided to have EVPN as one of the control plane solutions for NVo3. Draft was presented in subsequent WG sessions of IETF and many comments were provided by various members as part of WG adoption and WG LC.All of the comments were clearly answered and the draft got updated appropriately. There were no controversial or pending issues remaining.


Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


> EVPN protocol was implemented by almost all of the routing vendors. This is a well known protocol and is being used to deploy VXLAN protocol. Vendors have indicated that GENEVE protocol also used EVPN as control protocol in various deployments..


Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
> Document Shepherd: Sam Aldrin
  AD> Martin Vigoureux


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
> The document is well written. EVPN is widely deployed protocol. Employing this protocol for GENEVE requires no protocol work. This document captures how to use the existing protocol in deploying control plane for NVo3. All of the requirements were captured and detailed in the document. Various deployment aspects were discussed and addressed as part of the deployment scenarios, within the document. All of the comments, during the WG session and over the emails were addressed.


This document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
> There are no concerns.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
> This document does not introduce any protocol changes or require any new security considerations.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
> None.
(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
> All the authors have disclosed that there are no IPRs associated with this document, which were not already disclosed with EVPN protocol [RFC7432].


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
> None


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
> This draft was presented in various WG sessions. Consensus was very strong. There were no technical objections raised regarding this draft. When polled, both at the WG session and over the mailing list, the consensus was strong with no objections.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
> None.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
> No issues found.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
> None


(13) Have all references within this document been identified as either normative or informative?
> Yes. All references were clearly identified.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
> None.
(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
> None.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
> None.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
> No new IANA registrations requested.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
> None.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
> None.
2019-10-08
02 Sam Aldrin Responsible AD changed to Martin Vigoureux
2019-10-08
02 Sam Aldrin IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2019-10-08
02 Sam Aldrin IESG state changed to Publication Requested from I-D Exists
2019-10-08
02 Sam Aldrin IESG process started in state Publication Requested
2019-10-07
02 Sam Aldrin
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
> Informational. This is indicated on the title page, correctly.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary:
>In NVO3 networks, Network Virtualization Edge (NVE) devices sit at the edge of the underlay network and provide Layer-2 and Layer-3 connectivity among Tenant Systems (TSes) of the same tenant. The NVEs need to build and maintain mapping tables so that they can deliver encapsulated packets to their intended destination NVE(s). While there are different options to create and disseminate the mapping table entries, NVEs may exchange that information directly among themselves via a control-plane protocol, such as EVPN. EVPN provides an efficient, flexible and unified control-plane option that can be used for Layer-2 and Layer-3 Virtual Network (VN) service connectivity. This document describes the applicability of EVPN to NVO3 networks and how EVPN solves the challenges in those networks.


Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
> This document was extensively discussed within NVo3. Held a round table workshop like session during IETF 97 to discuss Control plane requirements and solutions. Gathered all the requirements and decided to have EVPN as one of the control plane solutions for NVo3. Draft was presented in subsequent WG sessions of IETF and many comments were provided by various members as part of WG adoption and WG LC.All of the comments were clearly answered and the draft got updated appropriately. There were no controversial or pending issues remaining.


Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


> EVPN protocol was implemented by almost all of the routing vendors. This is a well known protocol and is being used to deploy VXLAN protocol. Vendors have indicated that GENEVE protocol also used EVPN as control protocol in various deployments..


Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
> Document Shepherd: Sam Aldrin
  AD> Martin Vigoureux


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
> The document is well written. EVPN is widely deployed protocol. Employing this protocol for GENEVE requires no protocol work. This document captures how to use the existing protocol in deploying control plane for NVo3. All of the requirements were captured and detailed in the document. Various deployment aspects were discussed and addressed as part of the deployment scenarios, within the document. All of the comments, during the WG session and over the emails were addressed.


This document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
> There are no concerns.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
> This document does not introduce any protocol changes or require any new security considerations.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
> None.
(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
> All the authors have disclosed that there are no IPRs associated with this document, which were not already disclosed with EVPN protocol [RFC7432].


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
> None


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
> This draft was presented in various WG sessions. Consensus was very strong. There were no technical objections raised regarding this draft. When polled, both at the WG session and over the mailing list, the consensus was strong with no objections.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
> None.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
> No issues found.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
> None


(13) Have all references within this document been identified as either normative or informative?
> Yes. All references were clearly identified.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
> None.
(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
> None.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
> None.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
> No new IANA registrations requested.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
> None.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
> None.
2019-07-08
02 Jorge Rabadan New version available: draft-ietf-nvo3-evpn-applicability-02.txt
2019-07-08
02 (System) New version approved
2019-07-08
02 (System) Request for posting confirmation emailed to previous authors: Sami Boutros , Jorge Rabadan , Ali Sajassi , Matthew Bocci , nvo3-chairs@ietf.org
2019-07-08
02 Jorge Rabadan Uploaded new revision
2019-04-25
01 (System) Document has expired
2019-03-18
01 Matthew Bocci IETF WG state changed to In WG Last Call from WG Document
2019-03-18
01 Matthew Bocci Notification list changed to Sam Aldrin <aldrin.ietf@gmail.com>
2019-03-18
01 Matthew Bocci Document shepherd changed to Sam Aldrin
2018-10-22
01 Jorge Rabadan New version available: draft-ietf-nvo3-evpn-applicability-01.txt
2018-10-22
01 (System) New version approved
2018-10-22
01 (System) Request for posting confirmation emailed to previous authors: Sami Boutros , Jorge Rabadan , Ali Sajassi , Matthew Bocci
2018-10-22
01 Jorge Rabadan Uploaded new revision
2018-09-11
00 Jorge Rabadan New version available: draft-ietf-nvo3-evpn-applicability-00.txt
2018-09-11
00 (System) WG -00 approved
2018-09-11
00 Jorge Rabadan Set submitter to "Jorge Rabadan ", replaces to (none) and sent approval email to group chairs: nvo3-chairs@ietf.org
2018-09-11
00 Jorge Rabadan Uploaded new revision