IP Prefix Advertisement in Ethernet VPN (EVPN)
draft-ietf-bess-evpn-prefix-advertisement-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-10-08
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-09-29
|
11 | (System) | RFC Editor state changed to AUTH48 |
2021-09-01
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2021-07-30
|
11 | (System) | RFC Editor state changed to REF from EDIT |
2021-07-29
|
11 | (System) | RFC Editor state changed to EDIT from MISSREF |
2018-06-12
|
11 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2018-05-29
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-05-25
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-05-25
|
11 | (System) | RFC Editor state changed to MISSREF |
2018-05-25
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-05-25
|
11 | (System) | Announcement was received by RFC Editor |
2018-05-24
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-05-24
|
11 | (System) | IANA Action state changed to In Progress |
2018-05-24
|
11 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-05-24
|
11 | Cindy Morgan | IESG has approved the document |
2018-05-24
|
11 | Cindy Morgan | Closed "Approve" ballot |
2018-05-24
|
11 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-05-24
|
11 | Alvaro Retana | Ballot approval text was generated |
2018-05-21
|
11 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my comments! I leave the original ballot text below for reference. DISCUSS There are a lot of places where … [Ballot comment] Thank you for addressing my comments! I leave the original ballot text below for reference. DISCUSS There are a lot of places where the actual requirements seem (potentially) ambiguously written or incomplete, or the document is internally inconsistent. I expect that at least some of these are just confusion on my part, so hopefully someone can clue me in on where I'm going astray. Not exactly a DISCUSS, but is there a plan for resolving the normative reference to the expired draft-ietf-bess-evpn-inter-subnet-forwarding? Does Section 3's [...] In case two or more NVEs are attached to different BDs of the same tenant, they MUST support RT-5 for the proper Inter-Subnet Forwarding operation of the tenant. apply even when there is a SBD between them in the topology, or does something in the SBD also need to support RT-5 in such cases? Section 3.2's o The ESI and GW IP fields may both be zero, however they MUST NOT both be non-zero at the same time. A route containing a non-zero GW IP and a non-zero ESI (at the same time) SHOULD be treat-as- withdraw [RFC7606]. seems to say that ESI and GW IP cannot both be zero at the same time, but there seem to be entires in Table 1 that have that be the case. There are also potential combinations not included in Table 1 -- are we supposed to infer that anything not listed is an error condition (and thus treat-as-withdraw)? Section 4.4.1's Each RT-5 will be sent with a route-target identifying the tenant (IP-VRF) and two BGP extended communities: seems to say that there will always be these two extended communities, but there seems to be other text later implying that the "Router's MAC" extended community is not always present. COMMENT There seem to be a lot of different mechanisms listed to do the same thing, and not much guidance on in what scenarios each one is better/worse (i.e., some justification for including this much flexibility instead of a smaller number of generally applicable options). Is that something the authors are interested in adding? It might be worth sorting the definitions in Section 1 to help readers find specific definitions as they refer back. (Also, "EVPN" is not marked as well-known on the RFC Editor's list (https://www.rfc-editor.org/materials/abbrev.expansion.txt) and thus would be expected to be defined as well.) Nitpicking, but is "GARP message" or "gratuitous ARP message" the more common usage? "GARP" is only used once other than the definition... "TOR" (actually "ToR"?) is not defined here. "NLRI", "VTEP", "ESI", "ES", "AD" as well. Section 2.1 o Note that the same IP address could exist behind two of these TS. It sounds like this is "same IP address and endpoint" as opposed to "same IP address due to multiple endpoints being assigned the same (e.g., private) IP address in different domains"? Should that be specifically clarified? In Section 3.1, when adapting to other reviews and noting how the IPv4/IPv6 distinction is made, perhaps it would also be good to note that the IP Prefix and GW IP Address must represent the same family. Also, maybe "The GW IP field MUST be zero" should say "all bytes zero". Does the recursive resolution requirement represent a risk of DoS via resource consumption? (Is the recursion depth limited to one additional resolution?) Still in Section 3.1, please say something about the other 4 bits, even if it's "zero on send, ignore on receive". Section 4.1 The parenthetical about "(ND-snooping if IPv6)" does not make much sense in the context of an example that explictly uses IPv4. (Additionally, there should probably be some IPv6 examples.) In Section 4.4.2, does the "GS IP address=IRB-IP" refer to the IP of the SBD? Section 4.4.2 (1) NVE1 advertises the following BGP routes: o Route type 5 (IP Prefix route) containing: . IPL=24, IP=SN1, Label= SHOULD be set to 0. . GW IP=IP1 (sBD IRB's IP) . Route-target identifying the tenant (IP-VRF). o Route type 2 (MAC/IP route for the SBD IRB) containing: . ML=48, M=M1, IPL=32, IP=IP1, Label=10. . A [RFC5512] BGP Encapsulation Extended Community. . Route-target identifying the SBD. This route-target may be the same as the one used with the RT-5. I don't understand how the route-target can be the same for the RT-5 and RT-2 routes -- aren't they identifying different things (tenant and SBD)? Also, "NVE1 IP" is used in the body text, but in the figure I think this would just be "IP1"? I am less sure what "NVE1 IP" is supposed to be in Section 4.4.3. The Security Considerations talk of a security advantage from blocking dynamic routing protocols on the NVE/PE ACs; this would seem more relevant if phrased as "not allowing the tenant to interact with the infrastructure's dynamic routing protocols". (The customer could of course tunnel whatever sort of dynamic routing protocol they want over the EVPN.) |
2018-05-21
|
11 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2018-05-18
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-05-18
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-05-18
|
11 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-11.txt |
2018-05-18
|
11 | (System) | New version approved |
2018-05-18
|
11 | (System) | Request for posting confirmation emailed to previous authors: John Drake , Jorge Rabadan , Wim Henderickx , Ali Sajassi , Wen Lin |
2018-05-18
|
11 | Jorge Rabadan | Uploaded new revision |
2018-05-10
|
10 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-05-10
|
10 | Warren Kumari | [Ballot comment] NoObjection in the "I read the protocol action, and I trust the sponsoring AD so have no problem." / ran out of cycles … [Ballot comment] NoObjection in the "I read the protocol action, and I trust the sponsoring AD so have no problem." / ran out of cycles sense. |
2018-05-10
|
10 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-05-09
|
10 | Adam Roach | [Ballot comment] The density of unexpanded acronyms makes this document particularly challenging to read. Please expand the following acronyms upon first use and in the … [Ballot comment] The density of unexpanded acronyms makes this document particularly challenging to read. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - EVPN - NVO - MAC - VXLAN - nvGRE - PE - TOR - IP-VPN - VM - ESI - NLRI - VTEP - VSID - ES - AD - GPE - sBD - DA - ABR - CE |
2018-05-09
|
10 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from No Record |
2018-05-09
|
10 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-05-09
|
10 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-05-09
|
10 | Adam Roach | [Ballot comment] Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - EVPN - NVO - MAC - … [Ballot comment] Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - EVPN - NVO - MAC - VXLAN - nvGRE - PE - TOR - IP-VPN - VM - ESI - NLRI - VTEP - VSID - ES - AD - GPE - sBD - DA - ABR - CE |
2018-05-09
|
10 | Adam Roach | Ballot comment text updated for Adam Roach |
2018-05-09
|
10 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4698 I found this document pretty dense and only gave it a light read. COMMENTS S 2.2 … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4698 I found this document pretty dense and only gave it a light read. COMMENTS S 2.2 > independent of and not subject to the interpretation of the IPL and > the IP value. E.g.: a default IP route 0.0.0.0/0 must always be > easily and clearly distinguished from the absence of IP > information. > > o In MAC/IP routes, the MAC information is part of the NLRI, so if IP You need to define NLRI on first use. S 3.1 > > o The total route length will indicate the type of prefix (IPv4 or > IPv6) and the type of GW IP address (IPv4 or IPv6). Note that the > IP Prefix + the GW IP should have a length of either 64 or 256 > bits, but never 160 bits (IPv4 and IPv6 mixed values are not > allowed). Really shaving the bits tight here, I see. S 3.2 > Table 1 shows the different RT-5 field combinations allowed by this > specification and what Overlay Index must be used by the receiving > NVE/PE in each case. Those cases where there is no Overlay Index, are > indicated as "None" in Table 1. If there is no Overlay Index the > receiving NVE/PE will not perform any recursive resolution, and the > actual next-hop is given by the RT-5's BGP next-hop. How do I behave if something appears that is not on this table S 6. > overlay MAC addresses, overlay ESI, underlay BGP next-hops, etc. > > d) An EVPN implementation not requiring IP Prefixes can simply > discard them by looking at the route type value. > > 6. Security Considerations I'm not sure that this is a security consideration, but does the ability to specify an IP as the next hop mean that you could route packets somewhere totally off EVPN? |
2018-05-09
|
10 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-05-09
|
10 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-05-09
|
10 | Ben Campbell | [Ballot comment] I agree with Alissa that the GenART review should be addressed. |
2018-05-09
|
10 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-05-09
|
10 | Alissa Cooper | [Ballot comment] The Gen-ART reviewer did an in-depth review and I have not seen any response yet: https://datatracker.ietf.org/doc/review-ietf-bess-evpn-prefix-advertisement-10-genart-lc-davies-2018-04-14/ |
2018-05-09
|
10 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-05-09
|
10 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-05-09
|
10 | Benjamin Kaduk | [Ballot discuss] There are a lot of places where the actual requirements seem (potentially) ambiguously written or incomplete, or the document is internally inconsistent. I … [Ballot discuss] There are a lot of places where the actual requirements seem (potentially) ambiguously written or incomplete, or the document is internally inconsistent. I expect that at least some of these are just confusion on my part, so hopefully someone can clue me in on where I'm going astray. Not exactly a DISCUSS, but is there a plan for resolving the normative reference to the expired draft-ietf-bess-evpn-inter-subnet-forwarding? Does Section 3's [...] In case two or more NVEs are attached to different BDs of the same tenant, they MUST support RT-5 for the proper Inter-Subnet Forwarding operation of the tenant. apply even when there is a SBD between them in the topology, or does something in the SBD also need to support RT-5 in such cases? Section 3.2's o The ESI and GW IP fields may both be zero, however they MUST NOT both be non-zero at the same time. A route containing a non-zero GW IP and a non-zero ESI (at the same time) SHOULD be treat-as- withdraw [RFC7606]. seems to say that ESI and GW IP cannot both be zero at the same time, but there seem to be entires in Table 1 that have that be the case. There are also potential combinations not included in Table 1 -- are we supposed to infer that anything not listed is an error condition (and thus treat-as-withdraw)? Section 4.4.1's Each RT-5 will be sent with a route-target identifying the tenant (IP-VRF) and two BGP extended communities: seems to say that there will always be these two extended communities, but there seems to be other text later implying that the "Router's MAC" extended community is not always present. |
2018-05-09
|
10 | Benjamin Kaduk | [Ballot comment] There seem to be a lot of different mechanisms listed to do the same thing, and not much guidance on in what scenarios … [Ballot comment] There seem to be a lot of different mechanisms listed to do the same thing, and not much guidance on in what scenarios each one is better/worse (i.e., some justification for including this much flexibility instead of a smaller number of generally applicable options). Is that something the authors are interested in adding? It might be worth sorting the definitions in Section 1 to help readers find specific definitions as they refer back. (Also, "EVPN" is not marked as well-known on the RFC Editor's list (https://www.rfc-editor.org/materials/abbrev.expansion.txt) and thus would be expected to be defined as well.) Nitpicking, but is "GARP message" or "gratuitous ARP message" the more common usage? "GARP" is only used once other than the definition... "TOR" (actually "ToR"?) is not defined here. "NLRI", "VTEP", "ESI", "ES", "AD" as well. Section 2.1 o Note that the same IP address could exist behind two of these TS. It sounds like this is "same IP address and endpoint" as opposed to "same IP address due to multiple endpoints being assigned the same (e.g., private) IP address in different domains"? Should that be specifically clarified? In Section 3.1, when adapting to other reviews and noting how the IPv4/IPv6 distinction is made, perhaps it would also be good to note that the IP Prefix and GW IP Address must represent the same family. Also, maybe "The GW IP field MUST be zero" should say "all bytes zero". Does the recursive resolution requirement represent a risk of DoS via resource consumption? (Is the recursion depth limited to one additional resolution?) Still in Section 3.1, please say something about the other 4 bits, even if it's "zero on send, ignore on receive". Section 4.1 The parenthetical about "(ND-snooping if IPv6)" does not make much sense in the context of an example that explictly uses IPv4. (Additionally, there should probably be some IPv6 examples.) In Section 4.4.2, does the "GS IP address=IRB-IP" refer to the IP of the SBD? Section 4.4.2 (1) NVE1 advertises the following BGP routes: o Route type 5 (IP Prefix route) containing: . IPL=24, IP=SN1, Label= SHOULD be set to 0. . GW IP=IP1 (sBD IRB's IP) . Route-target identifying the tenant (IP-VRF). o Route type 2 (MAC/IP route for the SBD IRB) containing: . ML=48, M=M1, IPL=32, IP=IP1, Label=10. . A [RFC5512] BGP Encapsulation Extended Community. . Route-target identifying the SBD. This route-target may be the same as the one used with the RT-5. I don't understand how the route-target can be the same for the RT-5 and RT-2 routes -- aren't they identifying different things (tenant and SBD)? Also, "NVE1 IP" is used in the body text, but in the figure I think this would just be "IP1"? I am less sure what "NVE1 IP" is supposed to be in Section 4.4.3. The Security Considerations talk of a security advantage from blocking dynamic routing protocols on the NVE/PE ACs; this would seem more relevant if phrased as "not allowing the tenant to interact with the infrastructure's dynamic routing protocols". (The customer could of course tunnel whatever sort of dynamic routing protocol they want over the EVPN.) |
2018-05-09
|
10 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-05-09
|
10 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-05-08
|
10 | Ignas Bagdonas | [Ballot comment] NVGRE and VXLAN-GPE references throughout the document – would be better to replace with Geneve, as NVGRE is historic, and GPE will wait … [Ballot comment] NVGRE and VXLAN-GPE references throughout the document – would be better to replace with Geneve, as NVGRE is historic, and GPE will wait until Geneve progresses. This does not change the logic of operation for non-Ethernet NVO tunnels. s2.1, last bullet: TS4 connectivity is not required to be physical, it is just connectivity. s3.2: s/fail to install/MUST not install s4.3, steps 1 and 2: what if MAC address is both signaled and learned by policy? How would such conflict be resolved? Which one would take precedence? s2: s/program/propagate A few assorted nits: Document would benefit from reduction of hyphenation of common terms and normalizing the spelling of the terms throughout the document (as an example, there are forms of route type, route-type, and Route Type intermixed). Re-advertise, stripped-off, mass-withdrawal, ip-lookup, mac-lookup, re-used, inter-subnet-forwarding, next-hop. s/route-target/Route Target s/layer-2/layer 2 s/layer-3/layer 3 RT-2, RT-5: please consider unifying the terminology and use route type 2/route type 5, RFC7432 does not use RT-x notation. S4.4.2: s/IP10/IP1 |
2018-05-08
|
10 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-05-04
|
10 | Barry Leiba | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Barry Leiba. Sent review to list. |
2018-04-26
|
10 | Alvaro Retana | Ballot approval text was generated |
2018-04-26
|
10 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-04-26
|
10 | Alvaro Retana | Ballot has been issued |
2018-04-26
|
10 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2018-04-26
|
10 | Alvaro Retana | Created "Approve" ballot |
2018-04-14
|
10 | Elwyn Davies | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Elwyn Davies. Sent review to list. |
2018-04-12
|
10 | Min Ye | Request for Telechat review by RTGDIR Completed: Has Issues. Reviewer: Geoff Huston. |
2018-04-10
|
10 | Alvaro Retana | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2018-04-10
|
10 | Alvaro Retana | Ballot writeup was changed |
2018-04-10
|
10 | Alvaro Retana | Changed consensus to Yes from Unknown |
2018-04-10
|
10 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-04-09
|
10 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2018-04-09
|
10 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-bess-evpn-prefix-advertisement-10. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-bess-evpn-prefix-advertisement-10. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete. In the EVPN Route Types registry on the Ethernet VPN (EVPN) registry page located at: https://www.iana.org/assignments/evpn/ the temporary registration for Value: 5 Description: IP Prefix route will be made permanent and have its reference changed to [ RFC-to-be ]. The IANA Services Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-04-05
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2018-04-05
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2018-04-05
|
10 | Mahesh Jethanandani | Assignment of request for Last Call review by OPSDIR to Mahesh Jethanandani was rejected |
2018-04-04
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani |
2018-04-04
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani |
2018-03-29
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2018-03-29
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2018-03-29
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Barry Leiba |
2018-03-29
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Barry Leiba |
2018-03-27
|
10 | Min Ye | Request for Telechat review by RTGDIR is assigned to Geoff Huston |
2018-03-27
|
10 | Min Ye | Request for Telechat review by RTGDIR is assigned to Geoff Huston |
2018-03-27
|
10 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-03-27
|
10 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-04-10): From: The IESG To: IETF-Announce CC: zzhang@juniper.net, draft-ietf-bess-evpn-prefix-advertisement@ietf.org, aretana.ietf@gmail.com, Zhaohui Zhang , … The following Last Call announcement was sent out (ends 2018-04-10): From: The IESG To: IETF-Announce CC: zzhang@juniper.net, draft-ietf-bess-evpn-prefix-advertisement@ietf.org, aretana.ietf@gmail.com, Zhaohui Zhang , bess-chairs@ietf.org, bess@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IP Prefix Advertisement in EVPN) to Proposed Standard The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'IP Prefix Advertisement in EVPN' as Proposed Standard 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 ietf@ietf.org mailing lists by 2018-04-10. 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 EVPN provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO-based network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-03-27
|
10 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-03-27
|
10 | Alvaro Retana | Requested Telechat review by RTGDIR |
2018-03-27
|
10 | Alvaro Retana | Placed on agenda for telechat - 2018-05-10 |
2018-03-27
|
10 | Alvaro Retana | Last call was requested |
2018-03-27
|
10 | Alvaro Retana | Ballot approval text was generated |
2018-03-27
|
10 | Alvaro Retana | Ballot writeup was generated |
2018-03-27
|
10 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-03-27
|
10 | Alvaro Retana | Last call announcement was generated |
2018-03-27
|
10 | Alvaro Retana | Last call announcement was generated |
2018-03-21
|
10 | Amy Vezza | Shepherding AD changed to Alvaro Retana |
2018-03-21
|
10 | Amy Vezza | Shepherding AD changed to Martin Vigoureux |
2018-02-27
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-02-27
|
10 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-10.txt |
2018-02-27
|
10 | (System) | New version approved |
2018-02-27
|
10 | (System) | Request for posting confirmation emailed to previous authors: John Drake , Jorge Rabadan , Wim Henderickx , Ali Sajassi , Wen Lin |
2018-02-27
|
10 | Jorge Rabadan | Uploaded new revision |
2018-02-13
|
09 | Alvaro Retana | === AD Review of draft-ietf-bess-evpn-prefix-advertisement-09 === https://mailarchive.ietf.org/arch/msg/bess/P-eHCTeqb87bh4nOVZAeyghfNpE/?qid=37f73f01416d4e4cb217a22eafeb332c Dear authors: I just finished reading this document. I am glad to finally get to process it -- … === AD Review of draft-ietf-bess-evpn-prefix-advertisement-09 === https://mailarchive.ietf.org/arch/msg/bess/P-eHCTeqb87bh4nOVZAeyghfNpE/?qid=37f73f01416d4e4cb217a22eafeb332c Dear authors: I just finished reading this document. I am glad to finally get to process it -- thank you for the work! I do have a long list of comments (see below). Many of my major ones are related to the use of Normative Language and some other clarifications, including places where I think the technology might still be underspecified. Central to the technology specified in this document is the use of an Overlay Index. The use cases make clear the use, but there is no place where it is discussed what it is (except for "An Overlay Index is a next-hop that requires a recursive resolution...", which doesn't provide significant information) or how/when to use it (except for the use cases in Section 4). I think the readability would be improved if there was a section (or paragraph) that explicitly talked about the concept. Suggestion: put it somewhere in Section 2.1, *before* the name is introduced ("...associated to an Overlay Index that can be a VA IP address, a floating IP address, a MAC address or an ESI."). Thanks! Alvaro. Major: M1. Support for RT-5 M1.1. Section 3 says: The support for this new route type is OPTIONAL. Since this new route type is OPTIONAL, an implementation not supporting it MUST ignore the route, based on the unknown route type value, as specified by Section 5.4 in [RFC7606]. (1) I understand what you mean by "OPTIONAL" above -- from an IETF process point of view it means that you're not formally Updating rfc7432, so EVPN compliant implementations (according to rfc7432) may not support this new route. However, from the point of view of this specification, the support cannot be optional because otherwise then there would be no point in writing this document; IOW, if you want to use RT-5, then you MUST support it. (2) You cannot specify in this document what implementations not supporting this specification should do (much less use a MUST to describe that), because, by definition, those implementations don't know about this document. The text above just repeats what rfc7606 already says...so in reality you seem to be making a statement about backwards compatibility: nothing bad will happen if an implementation not supporting this specification receives the new route because of rfc7606. Suggestion: NEW> According to Section 5.4 in [RFC7606], a node that doesn't recognize the RT-5 will ignore it. Add something about backwards compatibility... [This change would also allow rfc7606 to become an Informative Reference.] M1.2. I do have a question. If the operation of the network, for instance in the case described in 2.2, depends on the RT-5, but a node ignores it (because it doesn't support it yet), what is the effect? I'm assuming that the result will be that none of the routes associated to vIP23 will be known, so no traffic will be sent to it (even if the ownership is known). That seems to mean that all nodes (NVEs) MUST support RT-5 for the system to work, right? (This relates back to the "OPTIONAL" nature in the text above.) Please include this operational consideration somewhere. M2. Section 3.1 (IP Prefix Route Encoding) M2.1. "RD, Ethernet Tag ID and MPLS Label fields will be used as defined in [RFC7432] and [EVPN-OVERLAY]." Both documents use those fields in different ways depending on the route type and the application -- you need to be more specific. Note also that a couple of bullets later there is a specification for the MPLS Label field. M2.1.1. Depending on the specifics, we may need EVPN-OVERLAY to be a Normative reference. M2.2. "The IP Prefix will be a 32 or 128-bit field (ipv4 or ipv6). The size of this field does not depend on the value of the IP Prefix Length field." Does that mean that the IP Prefix Length field can be set (for example) to a number > 32 while the IP Prefix and GW IP Address fields both contain IPv4 addresses? That doesn't make sense, but the text currently allows it! M2.3. BTW, there's nothing in the document that talks about what should be an error and what do to about them. An example is the case above...another one would be if the IP Prefix Length is set to anything > 128...etc. M2.4. [minor] I noticed that rfc7432 uses IP Address Length/IP Address instead of IP Prefix Length/IP Prefix...and that the setting and meaning are slightly different. For my own education, why the change? Having discrete values for the length, for example, seems cleaner and simpler than a range... M2.5. [minor] s/GW IP (Gateway IP Address)/GW (Gateway) IP Address field M2.6. [minor] The figure shows the lengths in octets, but the description talks about bits for the IP addresses. Please be consistent. M2.7. [minor] The figures in 3 and 3.1 don't have names. M3. Section 3.2 says that "an Overlay Index can be an ESI, IP address in the address space of the tenant or MAC address". How do I know which one? Table 1 provides an answer, but I think there are a couple of inconsistencies and contradictions...and several open questions: M3.1. From 3.2: The ESI and GW IP fields MAY both be zero, however they MUST NOT both be non-zero at the same time. A route containing a non-zero GW IP and a non-zero ESI (at the same time) will be treated as- withdraw. M3.1.1. [minor] s/treated as-withdraw/treat-as-withdraw ...and please add a reference to rfc7606 after "treat-as-withdraw".] M3.1.2. The "MAY" above is out of place because it just represents a fact, the Normative part is covered by the "MUST NOT". s/MAY/may M3.1.3. The text above (and the table) reflect that if the ESI or the GW IP are non-zero, then the other one must be 0. However, 3.1 says that the GW IP "SHOULD be zero if it is not used as an Overlay Index." The problem here is that if the GW IP is not used as an Overlay Index, then it may still be non-zero (because the SHOULD leaves that door open), and if the ESI is also non-zero (because it is the Overlay Index) then we should treat-as-withdraw. IOW, I think that the "SHOULD" should be a "MUST" -- or are there cases where the GW IP would be non-zero (if it is not the Overlay Index)? M3.2. Table 1 is missing the combination where ESI is Zero, GW-IP is Non-Zero and the MAC is Non-Zero. I would assume that the result is still GW-IP. If that is the case, then explicitly indicating it would be beneficial. Suggestion: "If either the ESI or GW-IP are non-zero, then one of them will be the Overlay Index, regardless of whether the EC is present or the value of the Label..." M3.3. The Notes for Table 1 mention a couple of examples of invalid MAC addresses, but it doesn't explain what a valid one is. I hope that draft-ietf-bess-evpn-inter-subnet-forwarding talks about that, but I couldn't find anything there right away. It would be ideal to put a reference, and (if not in the other draft) to remember to add it... M3.4. The only requirement for the ESI or GW-IP seems to be a non-zero value...but that is obviously not enough. I hope that rfc7432 contains something along the lines of a valid ESI and maybe even something about IP addresses in the EVPN context... Please reference that. M3.5. For the cases where both ESI and GW-IP are zero, the zero/zero MAC and Label combination is missing. Section 3.1 says that "If the received MPLS Label value is zero, the route MUST contain an Overlay Index...", but if the other 3 values are all zero, now what? Should a route in those conditions result also in treat-as-withdraw? M3.6. If the Router's MAC Extended Community is present, but the address is invalid, does that translate to zero or non-zero in the table? M3.7. The second Note on the Table says that "Overlay Index may be the RT-5's MAC address or None, depending on the local policy of the receiving NVE/PE", but a few paragraphs before (still in 3.2) the text says that "Overlay Index for a given IP Prefix is set by local policy at the NVE that originates an RT-5 for that IP Prefix". That results in a contradiction (or at least an incomplete specification of that case): is the policy set at the originator or the receiver? What if they conflict? M3.8. [minor] At the start of 3.2 it says that an "Overlay Index can be an ESI, IP address in the address space of the tenant or MAC address"...but towards the end of that section the text says that "The Overlay Index is None...different Overlay Indexes supported by RT-5 (GW IP, ESI, MAC or None)". It seems to me that the Overlay Index is not really "None", but that there is no Overlay Index in some cases...is that correct? Please clarify. M3.9. "Any other use-case using a given Overlay Index, SHOULD follow the procedures described in this document for the same Overlay Index." Why is "SHOULD" used? Are there use cases that are not applicable to this specification? If so, please mention them. If not, or if you don't know, then why keep the "SHOULD", or even make that statement at all? M4. From 3.2: "Irrespective of the recursive resolution, if there is no IGP or BGP route to the BGP next-hop of an RT-5, BGP SHOULD fail to install the RT-5 even if the Overlay Index can be resolved." Why is that a "SHOULD" and not a "MUST"? Are there cases for which the RT-5 would be installed? M5. Section 4 is introduced by saying that it "describes some use-cases". I take that to mean that it includes examples of how the technology specified in Section 3 is used. That seems to be correct, except that the use cases in the 4.4.* sections contain Normative Language. In general, please let the examples be examples and keep the Normative nature in the specification part of the document. Some specifics... M5.1. Both 4.4.1 and 4.4.2 end with: "An EVPN IP-VRF-to-IP-VRF implementation is REQUIRED to support the ingress and egress procedures described in this section." Not only does that sound obvious (otherwise this document wouldn't exist), but I don't know what the Normative requirement is beyond supporting RT-5 as described in this document. The text seems superfluous to me. M5.2. Section 4.4.3 ends with: "This model is OPTIONAL for an EVPN IP-VRF-to-IP-VRF implementation." The optional nature of any of the procedures should be reflected in Section 3. The text also seems superfluous to me. M5.3. Section 4.4.1 contains the following Normative text: o The second one is the Router's MAC Extended Community as per [EVPN-INTERSUBNET] containing the MAC address associated to the NVE advertising the route. This MAC address identifies the NVE/DGW and MAY be re-used for all the IP-VRFs in the NVE. The Router's MAC Extended Community MUST be sent if the route is associated to an Ethernet NVO tunnel, for instance, VXLAN. If the route is associated to an IP NVO tunnel, for instance VXLAN GPE with IP payload, the Router's MAC Extended Community SHOULD NOT be sent. Section 3.1 just says that RT-5 "MAY be sent along with a Router's MAC Extended Community" (and not "MUST" as it says above). However, I see nothing (related to the Normative Language) that this text specifies that is not already in, or contradicts, 3.*, is that true? If so, then you should be able to just use lower case for the rfc2119 keywords. M5.3.1. "GW IP= SHOULD be set to 0" s/SHOULD be set to 0/set to 0 M5.4. Section 4.4.2 also has Normative language: M5.4.1. In some cases (for example: "Label value SHOULD be zero..."), the Normative language seems to just indicate a fact, not a specification. Later again: "Label= SHOULD be set to 0." s/SHOULD/should M5.4.2. "The Router's MAC Extended Community SHOULD NOT be sent in this case." This is another example of a fact...going back to Table 1, (IIRC) it doesn't matter if the MAC EC is present... s/SHOULD NOT/should not M5.4.3. "This route-target MAY be the same as the one used with the RT-5." This sounds like another fact to me. s/MAY/may M5.5. Normative Language in Section 4.4.3 M5.5.1. "SHOULD be set to 0": sounds like a statement of fact s/SHOULD/should M5.5.2. "This MAC address MAY be re-used for all the IP-VRFs in the NVE." s/MAY/may M6. The Security Considerations Section only says that "The security considerations discussed in [RFC7432] apply to this document." Ok, fine, but why? Is it because this document doesn't add new functionality? No. Is it because this document uses the same procedures? Not really. Why? Are there considerations specific to the new RT-5? Maybe not...but at least say so. What about the dependency between RT-5 and other route types (RT-2 or RT-1) in some use cases: where if both are not present then it doesn't work..? Could that be considered a security issue? Can a router in the middle of the network drop RT-5 (or RT-2/RT-1) and cause the resulting routing to either not be possible or be different? Is there anything that can be done to mitigate that? [Note: just thinking out loud. It seems to be possible to filter out RT-5 (or any type) routes...] M7. The Reference to EVPN-INTERSUBNET should be Normative because the Router's MAC Extended Community is used here. Minor: P1. The text uses "will be" in several places. Being more prescriptive (and using rfc2119 Normative language, if needed) is the right way to clearly specify the expected behavior. Please revise. P2. While the bess reader will understand when the text talks about "BD-10 route-target", it will not be straight forward for the typical reader to connect the two because a BD is defined as a "broadcast domain" and the relationship to a RT is not clear. Please add text to the terminology section to make the connection. P3. In 4.2, vIP23 is used as the floating IP. But simply "IP23" is used in the description -- so the Figure and the description don't match. Note that 2.1 uses vIP23 throughout. P4. In 4.3, this "MAY" is out of place: "the VNI MAY directly identify the egress interface". Not only is it part of an example (no place for Normative language), but it is just stating a fact. s/MAY/may P5. References: RFC4364 can be Informative. Nits: N1. Move Section 6 (Conventions used in this document) up into the Terminology Section. And please use the template from rfc8174. N2. SN and DGW are used in many places, but were not introduced/defined. N3. Please don't use "we"; e.g. s/we assume/it is assumed N4. s/M3"/M3 N5. "...this route is used to address the current and future inter-subnet connectivity requirements" Future requirements? Now do you know that? ;-) N6. s/"EVPN Route Types/"EVPN Route Types" N7. In 3.1: s/IP Prefix advertisement route NLRI/IP Prefix Route Type N8. s/ipv4/IPv4 N9. s/ipv6/IPv6 N10. Ethernet Tag ID is used un some places, and Eth-Tag ID in others. N11. In the use cases, the "M" variable is not defined. N12. Please expand GARP. N13. The narrative/format of the use cases in 4.1-4.3 is different than what is in 4.4.* -- it would be nice for the format to be consistent. N14. Figure 7 has "IP10", but the text talks about "IP1". |
2018-02-13
|
09 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-01-31
|
09 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2018-01-31
|
09 | Alvaro Retana | Notification list changed to "Zhaohui Zhang" <zzhang@juniper.net>, aretana.ietf@gmail.com from "Zhaohui Zhang" <zzhang@juniper.net> |
2017-11-23
|
09 | Zhaohui Zhang | (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? Standards track, as indicated in the page header. It is appropriate because it specifies standard procedures for Advertising IP prefixes using EVPN address family. Implementations must follow the same procedures to be inter-operable. (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 EVPN provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO-based network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used. Working Group Summary This document is a BESS Working Group document, and has gone through WG adoption, WG LC processes. Document Quality Revisions -5~-08 addressed quite a few issues raised by Eric Rosen and Zhaohui Zhang (document shepherd) during the WGLC. The shepherd agrees with co-authors that it is now solid, mature and ready for publication. Cisco, Juniper and Nokia have partially implemented the procedures specified in this document. Personnel Document Shepherd: Zhaohui (Jeffrey)Zhang (zzhang@juniper.net) Responsible Area Director: Alvaro Retana (aretana@cisco.com) (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. Revisions -5~-08 addressed quite a few issues raised by Eric Rosen and Zhaohui Zhang (document shepherd) during the WGLC. The shepherd agrees with co-authors that it is now solid, mature and ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. No. (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. No. (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 confirmed no IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure has been identified by the following search: https://datatracker.ietf.org/ipr/search/?draft=draft-ietf-bess-evpn-prefix-advertisement&submit=draft&rfc=&doctitle=&group=&holder=&iprtitle=&patent= (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? draft-rabadan-l2vpn-evpn-prefix-advertisement-00 was first published on 7/15/2013. The -03 revision became WG document on 1/28/2015, and the WG revision -04 went to LC on 2/13/2017. Over the course of four years the document has been endorsed by three major vendors (Cisco, Juniper, Nokia). Besides the vote of support of publication during the LC, there were extensive comments and suggestions from two WG members and all the issues have been addressed by -08 Revision. The document is solid and mature. (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.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Idnits have been addressed in the latest -09 revision. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (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? No. (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. No. (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. No. (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 5226). This document already has the early allocation of value 5 in the "EVPN Route Types" registry defined by [RFC7432]: Value Description Reference 5 IP Prefix route [this document] (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. N/A. (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. N/A. |
2017-11-23
|
09 | Martin Vigoureux | (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? Standards track, as indicated in the page header. It is appropriate because it specifies standard procedures for Advertising IP prefixes using EVPN address family. Implementations must follow the same procedures to be inter-operable. (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 EVPN provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO-based network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used. Working Group Summary This document is a BESS Working Group document, and has gone through WG adoption, WG LC processes. Document Quality Revisions -5~-08 addressed quite a few issues raised by Eric Rosen and Zhaohui Zhang (document shepherd) during the WGLC. The shepherd agrees with co-authors that it is now solid, mature and ready for publication. Cisco, Juniper and Nokia have partially implemented the procedures specified in this document. Personnel Document Shepherd: Zhaohui (Jeffrey)Zhang (zzhang@juniper.net) Responsible Area Director: Alvaro Retana (aretana@cisco.com) (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. Revisions -5~-08 addressed quite a few issues raised by Eric Rosen and Zhaohui Zhang (document shepherd) during the WGLC. The shepherd agrees with co-authors that it is now solid, mature and ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. No. (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. No. (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. Four out of five co-authors declared "not aware of IPRs" related to the document. Did not find declaration from other co-authors/contributors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure has been identified by the following search: https://datatracker.ietf.org/ipr/search/?draft=draft-ietf-bess-evpn-prefix-advertisement&submit=draft&rfc=&doctitle=&group=&holder=&iprtitle=&patent= (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? draft-rabadan-l2vpn-evpn-prefix-advertisement-00 was first published on 7/15/2013. The -03 revision became WG document on 1/28/2015, and the WG revision -04 went to LC on 2/13/2017. Over the course of four years the document has been endorsed by three major vendors (Cisco, Juniper, Nokia). Besides the vote of support of publication during the LC, there were extensive comments and suggestions from two WG members and all the issues have been addressed by the latest -08 Revision. The document is solid and mature. (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.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Idnits with verbose output identified some issues. Have asked the authors to look into those. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (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? No. (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. No. (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. No. (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 5226). This document requests the allocation of value 5 in the "EVPN Route Types" registry defined by [RFC7432]: Value Description Reference 5 IP Prefix route [this document] An early allocation has been assigned, consistent with this document. (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. N/A. (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. N/A. |
2017-11-23
|
09 | Martin Vigoureux | Responsible AD changed to Alvaro Retana |
2017-11-23
|
09 | Martin Vigoureux | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-11-23
|
09 | Martin Vigoureux | IESG state changed to Publication Requested |
2017-11-23
|
09 | Martin Vigoureux | IESG process started in state Publication Requested |
2017-11-21
|
09 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-09.txt |
2017-11-21
|
09 | (System) | New version approved |
2017-11-21
|
09 | (System) | Request for posting confirmation emailed to previous authors: John Drake , Jorge Rabadan , Wim Henderickx , Ali Sajassi , Wen Lin |
2017-11-21
|
09 | Jorge Rabadan | Uploaded new revision |
2017-11-07
|
08 | Zhaohui Zhang | Changed document writeup |
2017-10-20
|
08 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-08.txt |
2017-10-20
|
08 | (System) | New version approved |
2017-10-20
|
08 | (System) | Request for posting confirmation emailed to previous authors: John Drake , Jorge Rabadan , Wim Henderickx , Ali Sajassi , Wen Lin |
2017-10-20
|
08 | Jorge Rabadan | Uploaded new revision |
2017-10-19
|
07 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-07.txt |
2017-10-19
|
07 | (System) | New version approved |
2017-10-19
|
07 | (System) | Request for posting confirmation emailed to previous authors: John Drake , Jorge Rabadan , Wim Henderickx , Ali Sajassi , Wen Lin |
2017-10-19
|
07 | Jorge Rabadan | Uploaded new revision |
2017-10-16
|
06 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-06.txt |
2017-10-16
|
06 | (System) | New version approved |
2017-10-16
|
06 | (System) | Request for posting confirmation emailed to previous authors: John Drake , Jorge Rabadan , Wim Henderickx , Ali Sajassi , Wen Lin |
2017-10-16
|
06 | Jorge Rabadan | Uploaded new revision |
2017-09-25
|
05 | Martin Vigoureux | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-07-18
|
05 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-05.txt |
2017-07-18
|
05 | (System) | New version approved |
2017-07-18
|
05 | (System) | Request for posting confirmation emailed to previous authors: John Drake , Jorge Rabadan , Wim Henderickx , Ali Sajassi , Wen Lin |
2017-07-18
|
05 | Jorge Rabadan | Uploaded new revision |
2017-02-13
|
04 | Martin Vigoureux | IETF WG state changed to In WG Last Call from WG Document |
2017-02-12
|
04 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-04.txt |
2017-02-12
|
04 | (System) | New version approved |
2017-02-12
|
04 | (System) | Request for posting confirmation emailed to previous authors: "Jorge Rabadan" , "Aldrin Isaac" , "Senad Palislamovic" , "John Drake" , "Ali Sajassi" , bess-chairs@ietf.org, … Request for posting confirmation emailed to previous authors: "Jorge Rabadan" , "Aldrin Isaac" , "Senad Palislamovic" , "John Drake" , "Ali Sajassi" , bess-chairs@ietf.org, "Wim Henderickx" , "Wen Lin" |
2017-02-12
|
04 | Jorge Rabadan | Uploaded new revision |
2017-02-06
|
03 | Martin Vigoureux | Notification list changed to "Zhaohui Zhang" <zzhang@juniper.net> |
2017-02-06
|
03 | Martin Vigoureux | Document shepherd changed to Zhaohui (Jeffrey) Zhang |
2016-11-13
|
03 | Martin Vigoureux | Added -03 to session: IETF-97: bess Mon-1330 |
2016-09-13
|
03 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-03.txt |
2016-09-13
|
03 | Jorge Rabadan | New version approved |
2016-09-13
|
03 | Jorge Rabadan | Request for posting confirmation emailed to previous authors: "Wim Henderickx" , bess-chairs@ietf.org, "Senad Palislamovic" , "Aldrin Isaac" , "Jorge Rabadan" |
2016-09-13
|
03 | (System) | Uploaded new revision |
2015-10-02
|
02 | Martin Vigoureux | Notification list changed to none from "Martin Vigoureux" <martin.vigoureux@alcatel-lucent.com> |
2015-10-02
|
02 | Martin Vigoureux | Document shepherd changed to (None) |
2015-09-14
|
02 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-02.txt |
2015-03-09
|
01 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-01.txt |
2015-01-28
|
00 | Thomas Morin | Intended Status changed to Proposed Standard from None |
2015-01-28
|
00 | Thomas Morin | This document now replaces draft-rabadan-l2vpn-evpn-prefix-advertisement instead of None |
2015-01-28
|
00 | Martin Vigoureux | Notification list changed to "Martin Vigoureux" <martin.vigoureux@alcatel-lucent.com> |
2015-01-28
|
00 | Martin Vigoureux | Document shepherd changed to Martin Vigoureux |
2015-01-28
|
00 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-prefix-advertisement-00.txt |