Re: [bess] [Editorial Errata Reported] RFC9252 (7134)
Greetings Area Directors, We are unable to verify this erratum that the submitter marked as editorial. Please note that we have changed the “Type” of the following errata report to “Technical”. As Stream Approver, please review and set the Status and Type accordingly (see the definitions at https://www.rfc-editor.org/errata-definitions/). You may review the report at: https://www.rfc-editor.org/errata/eid7134 Please see https://www.rfc-editor.org/how-to-verify/ for further information on how to verify errata reports. Further information on errata can be found at: https://www.rfc-editor.org/errata.php. Thank you. RFC Editor/cs > On Sep 15, 2022, at 4:17 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC9252, > "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7134 > > -- > Type: Editorial > Reported by: Ketan Talaulikar > > Section: 6.4 > > Original Text > - > +---+ > | RD (8 octets)| > +---+ > | Ethernet Tag ID (4 octets) | > +---+ > | IP Address Length (1 octet) | > +---+ > | Originating Router's IP Address | > | (4 or 16 octets) | > +---+ > >Figure 10: EVPN Route Type 4 > > > Corrected Text > -- > +---+ > | RD (8 octets)| > +---+ > |Ethernet Segment Identifier (10 octets)| > +---+ > | IP Address Length (1 octet) | > +---+ > | Originating Router's IP Address | > | (4 or 16 octets) | > +---+ > >Figure 10: EVPN Route Type 4 > > > Notes > - > The 2nd field in the figure should be "Ethernet Segment Identifier" of size > 10 octets instead of the "Ethernet Tag ID" of size 4 octets. > > RFC7432 is the EVPN specification for Ethernet Segment Route (Type 4) and > hence the format in section 7.4 of RFC7432 is the correct one. > RFC9252 has an error when showing the encoding format of this EVPN Route Type > 4 as a reminder in Figure 10 in section 6.4. > > This is an editorial error. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC9252 (draft-ietf-bess-srv6-services-15) > -- > Title : BGP Overlay Services Based on Segment Routing over IPv6 > (SRv6) > Publication Date: July 2022 > Author(s) : G. Dawra, Ed., K. Talaulikar, Ed., R. Raszuk, B. > Decraene, S. Zhuang, J. Rabadan > Category: PROPOSED STANDARD > Source : BGP Enabled ServiceS > Area: Routing > Stream : IETF > Verifying Party : IESG > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] [Editorial Errata Reported] RFC7582 (6875)
Greetings, Errata (6875) has been deleted. Please resubmit your errata with the correct RFC number. Thank you. RFC Editor/cs > From: > Subject: RE: [Editorial Errata Reported] RFC7582 (6875) > Date: March 8, 2022 at 1:18:56 AM PST > To: RFC Errata System > Cc: "ero...@juniper.net" , "i...@cisco.com" > , "yiq...@microsoft.com" , > "ar...@boers.com" > > Dear RFC Editor, > > This errata is against RFC7285, not 7582. Can you please update the RFC > number? Thank you. > > Authors of RFC7582, apologies for the inconvenience. > > Cheers, > Med > On Mar 8, 2022, at 12:52 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC7582, > "Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6875 > > -- > Type: Editorial > Reported by: Mohamed Boucadair > > Section: 14.3 > > Original Text > - >+++ >| Identifier | Intended Semantics | >+++ >| pid| See Section 7.1.1 | >| priv: | Private use| >+++ > > Table 4: ALTO Endpoint Property Types > > Corrected Text > -- >+++ >| Identifier | Intended Semantics | >+++ >| pid| See Section 7.1.1 | >+++ > > Table 4: ALTO Endpoint Property Types > > Notes > - > priv is not an identifier, but a prefix. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC7582 (draft-ietf-bess-mvpn-bidir-04) > -- > Title : Multicast Virtual Private Network (MVPN): Using > Bidirectional P-Tunnels > Publication Date: July 2015 > Author(s) : E. Rosen, IJ. Wijnands, Y. Cai, A. Boers > Category: PROPOSED STANDARD > Source : BGP Enabled ServiceS > Area: Routing > Stream : IETF > Verifying Party : IESG > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] [Editorial Errata Reported] RFC9125 (6668)
Greetings, FYI - this report has been deleted as junk. Thank you. RFC Editor/cs > On Aug 29, 2021, at 11:05 PM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC9125, > "Gateway Auto-Discovery and Route Advertisement for Site Interconnection > Using Segment Routing". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6668 > > -- > Type: Editorial > Reported by: OGR4 > > Section: 9125 > > Original Text > - > > > > > Internet Engineering Task Force (IETF) A. Farrel > Request for Comments: 9125Old Dog Consulting > Category: Standards Track J. Drake > ISSN: 2070-1721 E. Rosen >Juniper Networks >K. Patel >Arrcus, Inc. >L. Jalil > Verizon > August 2021 > > > Gateway Auto-Discovery and Route Advertisement for Site Interconnection > Using Segment Routing > > Abstract > > Data centers are attached to the Internet or a backbone network by > gateway routers. One data center typically has more than one gateway > for commercial, load-balancing, and resiliency reasons. Other sites, > such as access networks, also need to be connected across backbone > networks through gateways. > > This document defines a mechanism using the BGP Tunnel Encapsulation > attribute to allow data center gateway routers to advertise routes to > the prefixes reachable in the site, including advertising them on > behalf of other gateways at the same site. This allows segment > routing to be used to identify multiple paths across the Internet or > backbone network between different gateways. The paths can be > selected for load-balancing, resilience, and quality purposes. > > Status of This Memo > > This is an Internet Standards Track document. > > This document is a product of the Internet Engineering Task Force > (IETF). It represents the consensus of the IETF community. It has > received public review and has been approved for publication by the > Internet Engineering Steering Group (IESG). Further information on > Internet Standards is available in Section 2 of RFC 7841. > > Information about the current status of this document, any errata, > and how to provide feedback on it may be obtained at > https://www.rfc-editor.org/info/rfc9125. > > Copyright Notice > > Copyright (c) 2021 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (https://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction > 2. Requirements Language > 3. Site Gateway Auto-Discovery > 4. Relationship to BGP - Link State and Egress Peer Engineering > 5. Advertising a Site Route Externally > 6. Encapsulation > 7. IANA Considerations > 8. Security Considerations > 9. Manageability Considerations > 9.1. Relationship to Route Target Constraint > 10. References > 10.1. Normative References > 10.2. Informative References > Acknowledgements > Authors' Addresses > > 1. Introduction > > Data centers (DCs) are critical components of the infrastructure used > by network operators to provide services to their customers. DCs > (sites) are interconnected by a backbone network, which consists of > any number of private networks and/or the Internet. DCs are attached > to the backbone network by routers that are gateways (GWs). One DC > typically has more than one GW for various reasons including > commercial preferences, load balancing, or resiliency against > connection or device failure. > > Segment Routing (SR) ([RFC8402]) is a protocol mechanism that can be > used within a DC as well as for steering traffic that flows between > two DC sites. In order for a source site (also known as an ingress > site) that uses SR to load-balance the flows it sends to a > destination
