[bess] Protocol Action: 'EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding' to Proposed Standard (draft-ietf-bess-evpn-irb-mcast-11.txt)
The IESG has approved the following document: - 'EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding' (draft-ietf-bess-evpn-irb-mcast-11.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/ Technical Summary Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined external to the EVPN domain. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was solid consensus on this document. The number of authors on the document results from substantive textual contributions by all involved and in this case I believe it to be justified. 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? Personnel The Document Shepherd for this document is Mankamana Prasad Mishra. The Responsible Area Director is Andrew Alston. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (BGP Usage for SD-WAN Overlay Networks) to Informational RFC
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'BGP Usage for SD-WAN Overlay 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-c...@ietf.org mailing lists by 2024-02-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The document discusses the usage and applicability of BGP as the control plane for multiple SD-WAN scenarios. The document aims to demonstrate how the BGP-based control plane is used for large- scale SD-WAN overlay networks with little manual intervention. SD-WAN edge nodes are commonly interconnected by multiple types of underlay networks owned and managed by different network providers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Preference-based EVPN DF Election' to Proposed Standard (draft-ietf-bess-evpn-pref-df-13.txt)
The IESG has approved the following document: - 'Preference-based EVPN DF Election' (draft-ietf-bess-evpn-pref-df-13.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/ Technical Summary The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the PE responsible for sending Broadcast, Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/ network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single-active multi-homing. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default Designated Forwarder Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on- demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE. This document proposes a Designated Forwarder Election algorithm that meets the requirements of determinism and operation control. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Consensus seemed to be broad and no problems were found with the process. 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? There was broad consensus for this document. One change was made at the last minute but there is no indication this affected consensus. There is indication that there are active implementations of this draft. Personnel The Document Shepherd for this document is Stephane Litkowski. The Responsible Area Director is Andrew Alston. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'PBB-EVPN ISID-based C-MAC-Flush' to Proposed Standard (draft-ietf-bess-pbb-evpn-isid-cmacflush-09.txt)
The IESG has approved the following document: - 'PBB-EVPN ISID-based C-MAC-Flush' (draft-ietf-bess-pbb-evpn-isid-cmacflush-09.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/ Technical Summary Provider Backbone Bridging (PBB) can be combined with Ethernet Virtual Private Networks (EVPN) to deploy Ethernet Local Area Network (ELAN) services in large Multi-Protocol Label Switching (MPLS) networks (PBB-EVPN). Single-Active Multi-homing and per-I-SID (per Service Instance Identifier) Load-Balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active Multi-Homed Ethernet Segments, PBB-EVPN defines a flush mechanism for Customer MACs (CMAC- flush) that works for different Ethernet Segment Backbone MAC (BMAC) address allocation models. This document complements those CMAC- flush procedures for cases in which no PBB-EVPN Ethernet Segments are defined (the attachment circuit is associated to a zero Ethernet Segment Identifier) and a Service Instance Identifier based (I-SID- based) CMAC-flush granularity is required. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document seemed to have broad consensus, nothing beyond that. 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? One known implementation exists, that was disclosed during the implementation poll Personnel The Document Shepherd for this document is Matthew Bocci. The Responsible Area Director is Andrew Alston. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'MVPN/EVPN Tunnel Aggregation with Common Labels' to Proposed Standard (draft-ietf-bess-mvpn-evpn-aggregation-label-14.txt)
The IESG has approved the following document: - 'MVPN/EVPN Tunnel Aggregation with Common Labels' (draft-ietf-bess-mvpn-evpn-aggregation-label-14.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/ Technical Summary The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple VPNs. The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream- assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No issues were found in the working group on this draft and it didn't generate any controversy. 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? There are reported implementations of this draft. Personnel The Document Shepherd for this document is Stephane Litkowski. The Responsible Area Director is Andrew Alston. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding' 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 last-c...@ietf.org mailing lists by 2023-10-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined external to the EVPN domain. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3245/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (SD-WAN edge nodes are commonly interconnected by multiple types of underlay networks owned and managed by different network providers.) to I
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'SD-WAN edge nodes are commonly interconnected by multiple types of underlay networks owned and managed by different network providers.' 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-c...@ietf.org mailing lists by 2023-08-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The document discusses the usage and applicability of BGP as the control plane for multiple SD-WAN scenarios. The document aims to demonstrate how the BGP-based control plane is used for large-scale SD-WAN overlay networks with little manual intervention. SD-WAN edge nodes are commonly interconnected by multiple types of underlay networks owned and managed by different network providers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (MVPN/EVPN Tunnel Aggregation with Common Labels) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'MVPN/EVPN Tunnel Aggregation with Common Labels' 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 last-c...@ietf.org mailing lists by 2023-07-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple VPNs. The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream- assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4571/ https://datatracker.ietf.org/ipr/3341/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (PBB-EVPN ISID-based CMAC-Flush) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'PBB-EVPN ISID-based CMAC-Flush' 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 last-c...@ietf.org mailing lists by 2023-07-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Provider Backbone Bridging (PBB) can be combined with Ethernet Virtual Private Networks (EVPN) to deploy Ethernet Local Area Network (ELAN) services in large Multi-Protocol Label Switching (MPLS) networks (PBB-EVPN). Single-Active Multi-homing and per-I-SID (per Service Instance Identifier) Load-Balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active Multi-Homed Ethernet Segments, PBB-EVPN defines a flush mechanism for Customer MACs (CMAC- flush) that works for different Ethernet Segment Backbone MAC (BMAC) address allocation models. This document complements those CMAC- flush procedures for cases in which no PBB-EVPN Ethernet Segments are defined (the attachment circuit is associated to a zero Ethernet Segment Identifier) and a Service Instance Identifier based (I-SID- based) CMAC-flush granularity is required. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-pbb-evpn-isid-cmacflush/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Preference-based EVPN DF Election) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Preference-based EVPN DF Election' 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 last-c...@ietf.org mailing lists by 2023-07-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the PE responsible for sending Broadcast, Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/ network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single-active multi-homing. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default Designated Forwarder Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on- demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE. This document proposes a Designated Forwarder Election algorithm that meets the requirements of determinism and operation control. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3836/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'LSP-Ping Mechanisms for EVPN and PBB-EVPN' to Proposed Standard (draft-ietf-bess-evpn-lsp-ping-11.txt)
The IESG has approved the following document: - 'LSP-Ping Mechanisms for EVPN and PBB-EVPN' (draft-ietf-bess-evpn-lsp-ping-11.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/ Technical Summary LSP Ping is a widely deployed Operation, Administration, and Maintenance mechanism in MPLS networks. This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS based EVPN and PBB-EVPN networks. Working Group Summary Consensus seemed strong and the authors were responsive and addressed the comments and concerns raised. Document Quality While I did not find any concrete statements about current implementations of the draft, the support from the working group and the authors indicate strong support. The document is well written and I found it easy to read. I'd also note that the authors were very responsive to the various directorate reviews and all comments received from those reviews seem to have been adequately addressed. Personnel Document Shepherd: Matthew Bocci Responsible AD: Andrew Alston IANA Note There are IANA actions as follows: - Four new sub-TLV types for the target FEC stack TLV. - Two new return codes for the echo reply. The details of this are correctly described in sections 8.1 and 8.2 of the document. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (EVPN Virtual Ethernet Segment) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'EVPN Virtual Ethernet Segment' 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 last-c...@ietf.org mailing lists by 2023-04-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract EVPN and PBB-EVPN introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced features among which their multi-homing capabilities. These solutions introduce Single-Active and All-Active for an Ethernet Segment (ES), itself defined as a set of physical links between the multi-homed device/network and a set of PE devices that they are connected to. This document extends the Ethernet Segment concept so that an ES can be associated to a set of EVCs (e.g., VLANs) or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), referred to as Virtual Ethernet Segments (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3169/ https://datatracker.ietf.org/ipr/3354/ https://datatracker.ietf.org/ipr/3353/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (LSP-Ping Mechanisms for EVPN and PBB-EVPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'LSP-Ping Mechanisms for EVPN and PBB-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 last-c...@ietf.org mailing lists by 2022-10-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract LSP Ping is a widely deployed Operation, Administration, and Maintenance mechanism in MPLS networks. This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS based EVPN and PBB-EVPN networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'SRv6 BGP based Overlay Services' to Proposed Standard (draft-ietf-bess-srv6-services-15.txt)
The IESG has approved the following document: - 'SRv6 BGP based Overlay Services' (draft-ietf-bess-srv6-services-15.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/ Technical Summary This draft defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN, and Internet services. It builds on RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 "BGP MPLS-Based Ethernet VPN". Working Group Summary The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP. These services have traditionally been deployed over MPLS networks. However, there is a need to be able to implement them on new SRv6 based networks. A solution was needed to allow the advertisement of segment identifiers associated with layer 2 and layer 3 service endpoint functions over SRv6. This draft provides such a solution, including services such as IPv4 VPNs, IPv6 VPNs, and EVPN. The document was developed over a period of time in the BESS WG, in parallel with the development of SRv6 in the 6MAN and SPRING working groups. Document Quality Segment routing using SRv6 is starting to be deployed. There is a requirement for a standardised specification for how to deliver widely used VPN services such as provider provisioned IP VPNs and EVPN over an SRv6 infrastructure, making use of functions available in SRv6. A number of participants have indicated knowledge of implementations. Personnel Document Shepherd: Matthew Bocci (matthew.bo...@nokia.com) Responsible Area Director: Martin Vigoureux (martin.vigour...@nokia.com) ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'IGMP and MLD Proxy for EVPN' to Proposed Standard (draft-ietf-bess-evpn-igmp-mld-proxy-21.txt)
The IESG has approved the following document: - 'IGMP and MLD Proxy for EVPN' (draft-ietf-bess-evpn-igmp-mld-proxy-21.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/ Technical Summary This draft enables in an EVPN network: flooding reduction of IGMP messages, distributed anycast multicast proxy and selective multicast (forward multicast only to PEs that have interest). Working Group Summary The draft has been updated multiple times due to a good amount of discussions. An important change on the encoding has been introduced late in the process but this change has been agreed and has a consensus in the WG. Document Quality There are implementations of the specification. Personnel Stephane Litkowski is the document shepherd. Martin Vigoureux is the responsible AD ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Optimized Ingress Replication Solution for Ethernet VPN (EVPN)' to Proposed Standard (draft-ietf-bess-evpn-optimized-ir-12.txt)
The IESG has approved the following document: - 'Optimized Ingress Replication Solution for Ethernet VPN (EVPN)' (draft-ietf-bess-evpn-optimized-ir-12.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/ Technical Summary Network Virtualization Overlay (NVO) networks using EVPN as control plane may use Ingress Replication (IR) or PIM (Protocol Independent Multicast) based trees to convey the overlay BUM traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the NVO core network. IR avoids the dependency on PIM in the NVO network core. While IR provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of IR in NVO networks. Working Group Summary The document was developed to address the desire to provide efficient replication. It is important because it avoids the need to deploy PIM in the core of the network only for this application, which is particularly a consideration where EVPN is deployed to implement Network Virtualization Overlays in data centers. It makes use of a new BGP PMSI Tunnel Type to do this. Document Quality The document has been widely reviewed and discussed on the list over a number of years. There are known implementations. Personnel The document shepherd is Matthew Bocci (matthew.bo...@nokia.com). The responsible Area Director is Martin Vigoureux (martin.vigour...@nokia.com). ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Updates on EVPN BUM Procedures' to Proposed Standard (draft-ietf-bess-evpn-bum-procedure-updates-14.txt)
The IESG has approved the following document: - 'Updates on EVPN BUM Procedures' (draft-ietf-bess-evpn-bum-procedure-updates-14.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/ Technical Summary This document specifies/clarifies/redefines certain/additional EVPN BUM procedures, with a salient goal that they're better aligned among MVPN, EVPN and VPLS. For brevity, only changes/additions to relevant RFC 7117 and RFC 7524 procedures are specified, instead of repeating the entire procedures. Note that these are to be applied to EVPN only, even though sometimes they may sound to be updates to RFC 7117/7524. Working Group Summary The document went through few rounds of reviews, comments and revisions and there is consensus in the WG to publish this document. Document Quality The document is a stable document and supported for publication in the working group. At the time of WG LC there was no known implementation. However the WG was polled (according to policy in practice in BESS) on whether the draft should progress, and there was not any opposition to that. Personnel Document Shepherd: Zheng Zhang zzhang_i...@hotmail.com Area Director: Martin Vigoureux martin.vigour...@nokia.com ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (SRv6 BGP based Overlay Services) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'SRv6 BGP based Overlay Services' 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 last-c...@ietf.org mailing lists by 2021-11-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN, and Internet services. It builds on RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 "BGP MPLS-Based Ethernet VPN". The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4520/ https://datatracker.ietf.org/ipr/4521/ https://datatracker.ietf.org/ipr/3795/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Operational Aspects of Proxy-ARP/ND in Ethernet Virtual Private Networks' to Proposed Standard (draft-ietf-bess-evpn-proxy-arp-nd-16.txt)
The IESG has approved the following document: - 'Operational Aspects of Proxy-ARP/ND in Ethernet Virtual Private Networks' (draft-ietf-bess-evpn-proxy-arp-nd-16.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/ Technical Summary This document describes the EVPN Proxy-ARP/ND function, augmented by the capability of the ARP/ND Extended Community. Together, these help operators of Internet Exchange Points (IXPs), Data Centers (DCs), and other networks deal with IPv4 and IPv6 address resolution issues associated with large Broadcast Domains (DBs) by reducing and even suppressing the flooding produced by address resolution in the EVPN network. Working Group Summary The document was developed to address the desire to minimise flooding of traffic associated with address resolution in EVPN. It is particularly important due to the large size that EVPN networks can grow to, particularly in terms of the numbers of CEs and hosts. It makes recommendations for implementations of Proxy-ARP/ND to help operators deal with the issues derived from Address Resolution in large broadcast domains. There are no IPR declarations on the draft . Document Quality There is no concern about the quality of the document. It represents WG consensus, and it has been widely reviewed and discussed on the list over a number of years. The document was also reviewed by the various directorates and comments addressed The document does not specify any MIB changes or additions which would need review. Personnel The document shepherd is Matthew Bocci (matthew.bo...@nokia.com). The responsible Area Director is Martin Vigoureux (martin.vigour...@nokia.com). ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Optimized Ingress Replication solution for EVPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Optimized Ingress Replication solution for 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 last-c...@ietf.org mailing lists by 2021-09-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Network Virtualization Overlay (NVO) networks using EVPN as control plane may use Ingress Replication (IR) or PIM (Protocol Independent Multicast) based trees to convey the overlay BUM traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the NVO core network. IR avoids the dependency on PIM in the NVO network core. While IR provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of IR in NVO networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (IGMP and MLD Proxy for EVPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'IGMP and MLD Proxy for 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 last-c...@ietf.org mailing lists by 2021-09-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Ethernet Virtual Private Network (EVPN) solution is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services, and in service provider (SP) applications for next generation virtual private LAN services. This draft describes how to support efficiently endpoints running IGMP for the above services over an EVPN network by incorporating IGMP proxy procedures on EVPN PEs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3673/ https://datatracker.ietf.org/ipr/2949/ https://datatracker.ietf.org/ipr/2942/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Integrated Routing and Bridging in EVPN' to Proposed Standard (draft-ietf-bess-evpn-inter-subnet-forwarding-15.txt)
The IESG has approved the following document: - 'Integrated Routing and Bridging in EVPN' (draft-ietf-bess-evpn-inter-subnet-forwarding-15.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/ Technical Summary EVPN provides an extensible and flexible multi-homing VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and End Devices while maintaining the multi-homing capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements. Working Group Summary The document went through a couple of rounds LCs with reviews/comments/revisions, after which onsensus was reached. Document Quality There are implementations from major vendors and deployments by major operators. The document has reached WG consensus and passed WG LC. Eric Rosen and Document shephered reviewed and provided substantive comments during the first WG LC in February 2017. The issues have been addressed and a second WG LC was done in August 2018. Another round of comments from others have been addressed. Personnel Document Shepherd is Zhaohui (Jeffrey) Zhang. Responsible Area Director is Martin Vigoureux ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Site Interconnection' to Proposed Standard (draft-ietf-bess-datacenter-gateway-13.txt)
The IESG has approved the following document: - 'Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Site Interconnection' (draft-ietf-bess-datacenter-gateway-13.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/ Technical Summary Data centers are critical components of the infrastructure used by network operators to provide services to their customers. 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. Segment Routing is a protocol mechanism that can be used within a data center, and also for steering traffic that flows between two data center sites. In order that one data center site may load balance the traffic it sends to another data center site, it needs to know the complete set of gateway routers at the remote data center, the points of connection from those gateways to the backbone network, and the connectivity across the backbone network. Segment Routing may also be operated in other domains, such as access networks. Those domains also need to be connected across backbone networks through gateways. This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the Segment Routing domains to which it provides access, and also to advertise on behalf of each other gateway to the same Segment Routing domain. Working Group Summary This draft provides a solution to allow the discovery of multiple DC gateway routers in such scenarios. The document was developed over a period of time in the BESS WG, but required an extended WG last call to ensure sufficient review, as well as additional cross review of some points with the IDR WG. Document Quality Segment routing for supporting BGP based services between data centers is becoming widely deployed. The document leverages relatively mature BGP extensions. The draft received a number of comments during WG last call which were addressed. Personnel Document Shepherd: Matthew Bocci Responsible Area Director: Martin Vigoureux ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'MVPN and MSDP SA Interoperation' to Proposed Standard (draft-ietf-bess-mvpn-msdp-sa-interoperation-08.txt)
The IESG has approved the following document: - 'MVPN and MSDP SA Interoperation' (draft-ietf-bess-mvpn-msdp-sa-interoperation-08.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interoperation/ Technical Summary This document specifies the procedures for interoperation between Multicast Virtual Private Network (MVPN) Source Active routes and customer Multicast Source Discovery Protocol (MSDP) Source Active routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure. Without the procedures described in this document, VPN-specific MSDP sessions are required among the PEs that are customer MSDP peers. This document updates RFC6514. Working Group Summary We had good support for this work. This work removed need for extra protocol for mVPN deployments. Document Quality There is at least one implementation. Personnel Document Shepherd: Mankamana Mishra Responsible AD: Martin Vigoureux ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Document Action: 'EVPN Operations, Administration and Maintenance Requirements and Framework' to Informational RFC (draft-ietf-bess-evpn-oam-req-frmwk-10.txt)
The IESG has approved the following document: - 'EVPN Operations, Administration and Maintenance Requirements and Framework' (draft-ietf-bess-evpn-oam-req-frmwk-10.txt) as Informational RFC This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/ Technical Summary This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and PBB-EVPN. The framework defines the layered OAM model encompassing the EVPN service layer, network layer and underlying Packet Switched Network (PSN) transport layer. Working Group Summary EVPN is an becoming widely adopted as a technology for implementing layer 2 VPNS. OAM is required to aid in the maintenance of EVPN and to make it deployable by service providers. There is strong consensus that this work is required by the BESS working group, and this draft is required to set the context for determining the applicability of existing OAM protocols or making extensions or indeed defining new ones. Theer was no particularly controversial aspects to the draft. Document Quality EVPN is widely implemented and deployed. This draft is an informational set of requirements and a framework to guide the development of OAM for EVPN and as such does not require implementations in its own right, yet. The draft received a number of comments during WG last call which were addressed. Personnel Document Shepherd: Matthew Bocci (matthew.bo...@nokia.com) Responsible Area Director: Martin Vigoureux (martin.vigour...@nokia.com) ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection' 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 last-c...@ietf.org mailing lists by 2021-04-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Data centers are critical components of the infrastructure used by network operators to provide services to their customers. 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. Segment Routing is a protocol mechanism that can be used within a data center, and also for steering traffic that flows between two data center sites. In order that one data center site may load balance the traffic it sends to another data center site, it needs to know the complete set of gateway routers at the remote data center, the points of connection from those gateways to the backbone network, and the connectivity across the backbone network. Segment Routing may also be operated in other domains, such as access networks. Those domains also need to be connected across backbone networks through gateways. This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the Segment Routing domains to which it provides access, and also to advertise on behalf of each other gateway to the same Segment Routing domain. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (MVPN and MSDP SA Interoperation) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'MVPN and MSDP SA Interoperation' 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 last-c...@ietf.org mailing lists by 2021-04-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the procedures for interoperation between Multicast Virtual Private Network (MVPN) Source Active routes and customer Multicast Source Discovery Protocol (MSDP) Source Active routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure. Without the procedures described in this document, VPN-specific MSDP sessions are required among the PEs that are customer MSDP peers. This document updates RFC6514. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interoperation/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Propagation of ARP/ND Flags in EVPN' to Proposed Standard (draft-ietf-bess-evpn-na-flags-09.txt)
The IESG has approved the following document: - 'Propagation of ARP/ND Flags in EVPN' (draft-ietf-bess-evpn-na-flags-09.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-na-flags/ Technical Summary An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or IPv6 addresses associated with a MAC address. Remote PEs can use this information to populate their ARP/ND tables on IRB interfaces or their proxy-ARP/ND tables in Broadcast Domains (BD). PEs can then reply locally (act as an ARP/ND proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. However, the information conveyed in the MAC/IP route may not be enough for the remote PE to reply to local ARP or ND requests. For example, if a PE learns an IPv6->MAC ND entry via EVPN, the PE would not know if that particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address, as this information is not carried in the EVPN MAC/IP Advertisement routes. Similarly, other information relevant to the IP->MAC ARP/ND entries may be needed. This document defines an Extended Community that is advertised along with an EVPN MAC/IP Advertisement route and carries information relevant to the ARP/ND resolution, so that an EVPN PE implementing a proxy-ARP/ND function can reply to ARP Requests or Neighbor Solicitations with the correct information. Working Group Summary The document was developed to address the desire to minimise flooding of traffic associated with address resolution in EVPN. It is particularly important due to the large size that EVPN networks can grow to, particularly in terms of the numbers of CEs and hosts. It makes use of some flags in a new BGP extended community to do this. There are no IPR declarations on the draft . Document Quality This document quite well written. It represents WG consensus, and it has been widely reviewed and discussed on the list over a number of years. Personnel The document shepherd is Matthew Bocci The responsible Area Director is Martin Vigoureux ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Multicast VPN Fast Upstream Failover' to Proposed Standard (draft-ietf-bess-mvpn-fast-failover-15.txt)
The IESG has approved the following document: - 'Multicast VPN Fast Upstream Failover' (draft-ietf-bess-mvpn-fast-failover-15.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/ Technical Summary This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures. Working Group Summary There was no particular controversy on this draft but multiple enhancements have been added over time by various contributors. The document has been in the WG for a while and the initial authors/editors were not maintaining it anymore. Chairs had to appoint a new editor to close the work as the WG was interested to finish the work. Document Quality There is at least one known implementation. The document has been reviewed by some key experts of the working group. Personnel Stephane Litkowski is the document shepherd Martin Vigoureux is the responsible AD. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (EVPN Operations, Administration and Maintenance Requirements and Framework) to Informational RFC
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'EVPN Operations, Administration and Maintenance Requirements and Framework' 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-c...@ietf.org mailing lists by 2021-02-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and PBB-EVPN. The framework defines the layered OAM model encompassing the EVPN service layer, network layer and underlying Packet Switched Network (PSN) transport layer. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Operational Aspects of Proxy-ARP/ND in EVPN Networks) to Informational RFC
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Operational Aspects of Proxy-ARP/ND in EVPN 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-c...@ietf.org mailing lists by 2020-12-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The EVPN MAC/IP Advertisement route can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs importing those routes in the same Broadcast Domain (BD) can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large BDs, where the amount of ARP/ND flooded traffic causes issues on connected routers and CEs. This document describes the EVPN Proxy-ARP/ND function augmented by the capability of the ARP/ND Extended Community, which together help IXPs and other operators to deal with the issues derived from Address Resolution in large BDs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Multicast VPN Fast Upstream Failover) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Multicast VPN Fast Upstream Failover' 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 last-c...@ietf.org mailing lists by 2020-10-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a Standby Upstream PE. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2696/ https://datatracker.ietf.org/ipr/2697/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop' to Proposed Standard (draft-ietf-bess-rfc5549revision-06.txt)
The IESG has approved the following document: - 'Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop' (draft-ietf-bess-rfc5549revision-06.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/ Technical Summary Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. Working Group Summary The WG supports the publication of this Document. This Document was progressed rapidly in to address a simple gap in the current specifications compared to all known deployed implementations. This document was coordinated with the chairs of the IDR working group. It was progressed in the BESS working group since most applications for it reside within the charter of BESS. Document Quality The document was developed as a response to an observed gap in the current specifications that did not reflect deployed implementations. The ability to advertise an IPv6 next hop in an IPv4/VPN-IPv4 NLRI is something that has been implemented and deployed and this document reflects the need to standardise the procedures to ensure future interoperability. It also introduces a new capability advertisement for this. Personnel The document shepherd is Matthew Bocci The responsible Area Director is Martin Vigoureux ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'BGP Control Plane for the Network Service Header in Service Function Chaining' to Proposed Standard (draft-ietf-bess-nsh-bgp-control-plane-18.txt)
The IESG has approved the following document: - 'BGP Control Plane for the Network Service Header in Service Function Chaining' (draft-ietf-bess-nsh-bgp-control-plane-18.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/ Technical Summary The document defines a BGP control plane for NSH based service chaining. Working Group Summary There is a good level of consensus on the document. Document Quality There is no implementation or committed roadmap. However, the WG supports the publication of the document as an RFC (as per BESS implementation policy) Personnel Stephane Litkowski is the document shepherd. Martin Vigoureux is the responsible AD. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Propagation of ARP/ND Flags in EVPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Propagation of ARP/ND Flags 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 last-c...@ietf.org mailing lists by 2020-08-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or IPv6 addresses associated with a MAC address. Remote PEs can use this information to populate their ARP/ND tables on IRB interfaces or their proxy-ARP/ND tables in Broadcast Domains (BD). PEs can then reply locally (act as an ARP/ND proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. However, the information conveyed in the MAC/IP route may not be enough for the remote PE to reply to local ARP or ND requests. For example, if a PE learns an IPv6->MAC ND entry via EVPN, the PE would not know if that particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address, as this information is not carried in the EVPN MAC/IP Advertisement routes. Similarly, other information relevant to the IP->MAC ARP/ND entries may be needed. This document defines an Extended Community that is advertised along with an EVPN MAC/IP Advertisement route and carries information relevant to the ARP/ND resolution, so that an EVPN PE implementing a proxy-ARP/ND function can reply to ARP Requests or Neighbor Solicitations with the correct information. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-na-flags/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop' 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 last-c...@ietf.org mailing lists by 2020-07-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. This document obsoletes RFC5549. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Integrated Routing and Bridging in EVPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Integrated Routing and Bridging 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 last-c...@ietf.org mailing lists by 2020-07-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract EVPN provides an extensible and flexible multi-homing VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and End Devices while maintaining the multi-homing capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3352/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] BGP Enabled ServiceS (bess) WG Virtual Meeting: 2020-04-28
The BGP Enabled ServiceS (bess) Working Group will hold a virtual interim meeting on 2020-04-28 from 07:00 to 08:30 America/Los_Angeles (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc61438dc8dd5b87733564a765f5c1b80 ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (BGP based Multi-homing in Virtual Private LAN Service) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'BGP based Multi-homing in Virtual Private LAN Service' 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 last-c...@ietf.org mailing lists by 2020-03-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-vpls-multihoming/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-vpls-multihoming/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1809/ https://datatracker.ietf.org/ipr/3838/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (BGP Control Plane for NSH SFC) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'BGP Control Plane for NSH SFC' 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 last-c...@ietf.org mailing lists by 2019-12-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC AFI/SAFI with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header defined in RFC 8300. This document adopts the SFC architecture described in RFC 7665. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3107/ https://datatracker.ietf.org/ipr/2980/ https://datatracker.ietf.org/ipr/3826/ https://datatracker.ietf.org/ipr/2898/ https://datatracker.ietf.org/ipr/3347/ https://datatracker.ietf.org/ipr/3011/ The document contains these normative downward references. See RFC 3967 for additional information: rfc7665: Service Function Chaining (SFC) Architecture (Informational - IETF stream) rfc8596: MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) (Informational - IETF stream) ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Updated processing of Control Flags for BGP VPLS' to Proposed Standard (draft-ietf-bess-bgp-vpls-control-flags-08.txt)
The IESG has approved the following document: - 'Updated processing of Control Flags for BGP VPLS' (draft-ietf-bess-bgp-vpls-control-flags-08.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/ Technical Summary This document updates the meaning of the "control flags" fields inside the "layer2 info extended community" used for BGP-VPLS NLRI as defined in RFC4761. If approved, this document updates RFC4761. Working Group Summary There is good consensus from the WG, and there is no controversy. Document Quality There were active discussions in the WG, many valuable comments received and addressed. A number of iterations reflecting that. Personnel Document Shepherd: Mach Chen Responsible Area Director: Martin Vigoureux ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Updated processing of Control Flags for BGP VPLS) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Updated processing of Control Flags for BGP VPLS' 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 i...@ietf.org mailing lists by 2019-04-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates the meaning of the Control Flags field in the Layer2 Info Extended Community used for BGP-VPLS NLRI as defined in RFC4761. This document updates RFC4761. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2235/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Framework for EVPN Designated Forwarder Election Extensibility' to Proposed Standard (draft-ietf-bess-evpn-df-election-framework-09.txt)
The IESG has approved the following document: - 'Framework for EVPN Designated Forwarder Election Extensibility' (draft-ietf-bess-evpn-df-election-framework-09.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ Technical Summary Broadcast, Unknown an Multicast traffic forwarding requires the election of a designated forwarder (DF) is EVPN. RFC7432 defines an election procedure that does not cover all the use cases and may also cause some issues. This document defines a flexible framework that allows to negotiate the DF election algorithm to be used as well as some capabilities. This document also defines a new optional DF election algorithm as well as one capability which allows to recompute DF election based on an attachment circuit failure. Working Group Summary The document is coming from a merge of two documents. The merge was requested by the chairs during the WGLC of the two documents. There was no controversy about the content of the document. 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? There is one implementation of HRW as well as one implementation of AC-DF. As the framework is new, these implementations may not be 100% compliant. Personnel Stephane Litkowski is the document shepherd. Martin Vigoureux is the responsible AD. IESG Note This Document has more than 5 authors because it results from a merge of two documents, requested by the chairs. The three main authors/contributors were kept from each original document. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Framework for EVPN Designated Forwarder Election Extensibility' 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 i...@ietf.org mailing lists by 2018-12-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Designated Forwarder (DF) in EVPN networks is the Provider Edge (PE) router responsible for sending broadcast, unknown unicast and multicast (BUM) traffic to a multi-homed Customer Equipment (CE) device, on a given VLAN on a particular Ethernet Segment (ES). The DF is selected out of a list of candidate PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network. By default, EVPN uses a DF Election algorithm referred to as "Service Carving" and it is based on a modulus function (V mod N) that takes the number of PEs in the ES (N) and the VLAN value (V) as input. This default DF Election algorithm has some inefficiencies that this document addresses by defining a new DF Election algorithm and a capability to influence the DF Election result for a VLAN, depending on the state of the associated Attachment Circuit (AC). In addition, this document creates a registry with IANA, for future DF Election Algorithms and Capabilities. It also presents a formal definition and clarification of the DF Election Finite State Machine. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: ((PBB-)EVPN Seamless Integration with (PBB-)VPLS) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - '(PBB-)EVPN Seamless Integration with (PBB-)VPLS' 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 i...@ietf.org mailing lists by 2018-12-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft specifies procedures for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB- EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions (PBB-)VPLS. It also provides mechanisms for seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this draft enables service providers to introduce (PBB-)EVPN PEs in their brown-field deployments of (PBB-)VPLS networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2472/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Explicit Tracking with Wild Card Routes in Multicast VPN' to Proposed Standard (draft-ietf-bess-mvpn-expl-track-13.txt)
The IESG has approved the following document: - 'Explicit Tracking with Wild Card Routes in Multicast VPN' (draft-ietf-bess-mvpn-expl-track-13.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ Technical Summary This document clarifies the explicit tracking procedures in Multicast VPNs. The existing documents are leaving ambiguity for some scenarios that are clarified by this document. In addition, the document provides new optimized procedures to request explicit tracking of individual flows when wildcard S-PMSIs are used. Working Group Summary There was no real controversy on this document. Some technical points have been discussed and resolved with the WG consensus. Document Quality There is no implementation yet. The draft-ietf-bier-mvpn has a normative dependency with this document. There was no opposition in the WG to progress the document without implementations to help the BIER document progressing. Personnel Stephane Litkowski is the document shepherd. Martin Vigoureux is the responsible Area Director. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Explicit Tracking with Wild Card Routes in Multicast VPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Explicit Tracking with Wild Card Routes in Multicast VPN' 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 i...@ietf.org mailing lists by 2018-10-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The MVPN specifications provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, and 7524. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2807/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'BGP/MPLS Layer 3 VPN Multicast Management Information Base' to Proposed Standard (draft-ietf-bess-mvpn-mib-12.txt)
The IESG has approved the following document: - 'BGP/MPLS Layer 3 VPN Multicast Management Information Base' (draft-ietf-bess-mvpn-mib-12.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multicast communication over IP Virtual Private Networks (VPNs) supported by MultiProtocol Label Switching/Border Gateway Protcol (MPLS/BGP) on a Provider Edge router. Working Group Summary There is good consensus from the WG, and there is no controversy. Document Quality The Document has been thoroughly reviewed by MIB Doctor Glenn Mansfield and all of his comments were addressed. Personnel Document Shepherd: Mach Chen Responsible Area Director: Martin Vigoureux ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (L2L3 VPN Multicast MIB) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'L2L3 VPN Multicast MIB' 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 i...@ietf.org mailing lists by 2018-09-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes two MIB modules which will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (BGP/MPLS Layer 3 VPN Multicast Management Information Base) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'BGP/MPLS Layer 3 VPN Multicast Management Information Base' 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 i...@ietf.org mailing lists by 2018-09-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multicast communication over IP Virtual Private Networks (VPNs) supported by MultiProtocol Label Switching/Border Gateway Protcol (MPLS/BGP) on a Provider Edge router. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels' to Proposed Standard (draft-ietf-bess-fat-pw-bgp-04.txt)
The IESG has approved the following document: - 'Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels' (draft-ietf-bess-fat-pw-bgp-04.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-fat-pw-bgp/ Technical Summary This draft defines protocol extensions required to synchronize flow label states among PEs when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer2 Virtual Private Networks (L2VPNs). This draft updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. Working Group Summary Normal process, nothing special to highlight. Document Quality At least one implementation exists. The Document is fairly simple. Personnel Martin Vigoureux is the Document Shepherd Alvaro Retana is the Responsible AD ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] 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 i...@ietf.org mailing lists by 2018-04-10. Exceptionally, comments may be sent to i...@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. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Interconnect Solution for EVPN Overlay networks' to Proposed Standard (draft-ietf-bess-dci-evpn-overlay-10.txt)
The IESG has approved the following document: - 'Interconnect Solution for EVPN Overlay networks' (draft-ietf-bess-dci-evpn-overlay-10.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/ Technical Summary This document describes how Network Virtualization Overlays (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPN) and other L2VPN technologies used in the WAN. It also describes how the existing Technical Specifications apply to the Interconnection and extends the EVPN procedures needed in some cases. Working Group Summary Nothing specific to note -- support from the WG. Document Quality Several implementations of this technology exist. The Document is clear and well written. Personnel Martin Vigoureux is the Document Shepherd Alvaro Retana is the Responsible AD ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Document Action: 'Usage and applicability of BGP MPLS based Ethernet VPN' to Informational RFC (draft-ietf-bess-evpn-usage-09.txt)
The IESG has approved the following document: - 'Usage and applicability of BGP MPLS based Ethernet VPN' (draft-ietf-bess-evpn-usage-09.txt) as Informational RFC This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-usage/ Technical Summary This document discusses the usage and applicability of BGP MPLS based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained on the example scenario, analyzing the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks. Working Group Summary Not much to report, except that there is support from the WG. Document Quality There are multiple implementations of the EVPN technology. This Document describes in a clear manner the use of the EVPN technology building blocks and components. Personnel Martin Vigoureux is the Document Shepherd Alvaro Retana is the Responsible Area Director ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Usage and applicability of BGP MPLS based Ethernet VPN) to Informational RFC
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Usage and applicability of BGP MPLS based Ethernet VPN' 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 i...@ietf.org mailing lists by 2018-02-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document discusses the usage and applicability of BGP MPLS based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained on the example scenario, analyzing the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-usage/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-usage/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels' 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 i...@ietf.org mailing lists by 2018-02-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft defines protocol extensions required to synchronize flow label states among PEs when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer2 Virtual Private Networks (L2VPNs). This draft updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-fat-pw-bgp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-fat-pw-bgp/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'A Network Virtualization Overlay Solution using EVPN' to Proposed Standard (draft-ietf-bess-evpn-overlay-11.txt)
The IESG has approved the following document: - 'A Network Virtualization Overlay Solution using EVPN' (draft-ietf-bess-evpn-overlay-11.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ Technical Summary This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control-plane and procedures. In particular, the following encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE. GENEVE is considered in a separate document (draft-boutros-bess-evpn-geneve). Working Group Summary There was very large support for adopting this work. So much so that the list of authors (6) reflects the people who made the most significant contributions, while others (10 more) are listed as Contributors. Document Quality This specification is of very good technical quality and are known to have multiple interoperable specifications. Personnel Thomas Morin is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (A Network Virtualization Overlay Solution using EVPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'A Network Virtualization Overlay Solution using 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 i...@ietf.org mailing lists by 2017-12-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control-plane and procedures. In particular, the following encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE. This specification is also applicable to GENEVE encapsulation; however, some incremental work is required which will be covered in a separate document. This document also specifies new multi-homing procedures for split-horizon filtering and mass-withdraw. It also specifies EVPN route constructions for VxLAN/NvGRE encapsulations and ASBR procedures for multi-homing NV Edge devices. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7637: NVGRE: Network Virtualization Using Generic Routing Encapsulation (Informational - Independent Submission Editor stream) draft-ietf-idr-tunnel-encaps: The BGP Tunnel Encapsulation Attribute (None - IETF stream) rfc7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks (Informational - Independent Submission Editor stream) draft-ietf-nvo3-vxlan-gpe: Generic Protocol Extension for VXLAN (None - IETF stream) ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'E-TREE Support in EVPN & PBB-EVPN' to Proposed Standard (draft-ietf-bess-evpn-etree-14.txt)
The IESG has approved the following document:
- 'E-TREE Support in EVPN & PBB-EVPN'
(draft-ietf-bess-evpn-etree-14.txt) as Proposed Standard
This document is the product of the BGP Enabled ServiceS Working Group.
The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard.
A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/
Technical Summary
The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
Ethernet service known as Ethernet Tree (E-Tree). A solution
framework for supporting this service in MPLS networks is proposed in
RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a
Multiprotocol Label Switching (MPLS) Network"). This document
discusses how those functional requirements can be easily met with
Ethernet VPN (EVPN) and how EVPN offers a more efficient
implementation of these functions. This document makes use of the
most significant bit of the scope governed by the IANA registry
created by RFC7385, and hence updates RFC7385 accordingly.
Working Group Summary
Nothing substantial. A first call for adoption did not lead to
adoption, for lack of an observable support base, but the document
was later adopted on a second pass.
Document Quality
The document is of satisfying technical and editorial quality.
Three vendors are known to be working on an implementation or
update of pre-standard implementations.
Personnel
Thomas Morin is the Document Shepherd.
Alvaro Retana is the Responsible Area Director.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Virtual Private Wire Service support in Ethernet VPN' to Proposed Standard (draft-ietf-bess-evpn-vpws-14.txt)
The IESG has approved the following document: - 'Virtual Private Wire Service support in Ethernet VPN' (draft-ietf-bess-evpn-vpws-14.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ Technical Summary This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. Working Group Summary This document was processed by the bess WG; nothing specific to highlight. Document Quality At least 3 major vendors have implemented this specification. Personnel Document Shepherd: Jeffrey Zhang (zzh...@juniper.net) Responsible Area Director: Alvaro Retana (aret...@cisco.com) ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Ingress Replication Tunnels in Multicast VPN' to Proposed Standard (draft-ietf-bess-ir-05.txt)
The IESG has approved the following document: - 'Ingress Replication Tunnels in Multicast VPN' (draft-ietf-bess-ir-05.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-ir/ Technical Summary RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to- multipoint trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding details that are specific to the use of IR tunnels. Working Group Summary There was consensus in the WG that a clarification document was needed to completement RFC6513/RFC6514. Document Quality This document started from implementation experience realated to IR in MVPN -- the clarifications in the document come from there. The document can be technically detailed and maybe even confusing to the uninitiated, but it has gone through multiple reviews and discussion in the bess WG by experts. Personnel Document Shepherd = Thomas Morin. Responsible AD = Alvaro Retana. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Ingress Replication Tunnels in Multicast VPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Ingress Replication Tunnels in Multicast VPN' 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 i...@ietf.org mailing lists by 2016-08-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to- multipoint trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be "directly connected" to its child nodes. When a parent node has to send a multicast data packet to its child nodes, it does not use layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-ir/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-ir/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags' to Proposed Standard (draft-ietf-bess-pta-flags-03.txt)
The IESG has approved the following document: - 'Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags' (draft-ietf-bess-pta-flags-03.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ Technical Summary The BGP-based control procedures for Multicast Virtual Private Networks make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the Flags field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the PMSI Tunnel attribute. This document updates RFC 6514. Working Group Summary This document fills a hole in previous specification (the lack of creation of a registry). Document Quality Well written and to the point. Personnel Martin Vigoureux is the Document Shepherd Alvaro Retana is the responsible Area Director ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags) to Proposed Standard
The IESG has received a request from the BGP Enabled Services WG (bess) to consider the following document: - 'Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags' 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 i...@ietf.org mailing lists by 2016-04-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The BGP-based control procedures for Multicast Virtual Private Networks make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the Flags field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the PMSI Tunnel attribute. This document updates RFC 6514. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Document Action: 'Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution' to Informational RFC (draft-ietf-bess-virtual-subnet-07.txt)
The IESG has approved the following document: - 'Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution' (draft-ietf-bess-virtual-subnet-07.txt) as Informational RFC This document is the product of the BGP Enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ Technical Summary This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as Virtual Subnet, which can be used for building Layer3 network virtualization overlays within and/or between data centers. Working Group Summary This document generated a lot of discussions within L3VPN/BESS Working Groups up to the level where it "could have been considered controversial" (Shepherd), due to the existence of certain limitations of the solution. The consensus nevertheless was in favor of the adoption, and the limitations have been described in the document. Document Quality The extension described in the document amounts to a potential set of deployment scenarios using existing technology, so it doesn't specify protocol extensions. There is at least one known deployment. Personnel Martin Vigoureux is the Document Shepherd Alvaro Retana is the Responsible AD ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Extranet Multicast in BGP/IP MPLS VPNs) to Proposed Standard
The IESG has received a request from the BGP Enabled Services WG (bess) to consider the following document: - 'Extranet Multicast in BGP/IP MPLS VPNs' 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 i...@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide MVPN extranet service. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution) to Informational RFC
The IESG has received a request from the BGP Enabled Services WG (bess) to consider the following document: - 'Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution' 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 i...@ietf.org mailing lists by 2015-11-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as Virtual Subnet, which can be used for building Layer 3 network virtualization overlays within and/or between data centers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication' to Proposed Standard (draft-ietf-bess-mvpn-bidir-ingress-replication-04.txt)
The IESG has approved the following document: - 'Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication' (draft-ietf-bess-mvpn-bidir-ingress-replication-04.txt) as Proposed Standard This document is the product of the BGP Enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-bidir-ingress-replication/ Technical Summary This specifies an alternate technique than what has already been described to transport Bidir-PIM multicast traffic of a multicast VPN across a provider network. RFC 6513 described a method to support bidirectional C-flow using "Partial Mesh of MP2MP P-Tunnels". This document describes how partial mesh of MP2MP P-Tunnels can be simulated with Ingress Replication, instead of a real MP2MP tunnel. This enables a Service Provider to use Ingress Replication to offer transparent BIDIR-PIM service to its VPN customers. Working Group Summary No controversy or rough consensus decisions. Document Quality The document is of good technical quality. There is no known implementation yet, but one vendor has mentioned plans for implementing these specs. Personnel Thomas Morin is the doc shepherd. Alvaro Retana is the responsible AD. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'Shortest Path Bridging, MAC Mode Support over EVPN' to Proposed Standard (draft-ietf-bess-spbm-evpn-02.txt)
The IESG has approved the following document: - 'Shortest Path Bridging, MAC Mode Support over EVPN' (draft-ietf-bess-spbm-evpn-02.txt) as Proposed Standard This document is the product of the BGP Enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ Technical Summary This document describes how Ethernet Shortest Path Bridging MAC Mode (802.1aq) can be combined with EVPN in a way that interworks with PBB-PEs as described in the PBB-EVPN solution. This is achieved via operational isolation of each Ethernet network subtending an EVPN core while supporting full interworking between the different variations of Ethernet networks. Working Group Summary This document is a product of the L2VPN Working Group and was handed out to the BESS Working Group at the time of the closure of L2VPN. Document Quality The Document is focused, well written, and provides the necessary information. The WG has been polled on the existence (or plans) of implementations. The Document Shepherd is aware of one implementation plan. Personnel Martin Vigoureux is the Document Shepherd Alvaro Retana is the Responsible AD ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: (Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication) to Proposed Standard
The IESG has received a request from the BGP Enabled Services WG (bess) to consider the following document: - 'Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication' 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 i...@ietf.org mailing lists by 2015-10-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 6513 described a method to support bidirectional C-flow using "Partial Mesh of MP2MP P-Tunnels". This document specifiess how partial mesh of MP2MP P-Tunnels can be simulated with Ingress Replication, instead of a real MP2MP tunnel. This enables a Service Provider to use Ingress Replication to offer transparent Bidir-PIM service to its VPN customers. These specifications update RFC 6514. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-bidir-ingress-replication/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-bidir-ingress-replication/ballot/ No IPR declarations have been submitted directly on this I-D. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'BGP ACCEPT_OWN Community Attribute' to Proposed Standard (draft-ietf-l3vpn-acceptown-community-10.txt)
The IESG has approved the following document: - 'BGP ACCEPT_OWN Community Attribute' (draft-ietf-l3vpn-acceptown-community-10.txt) as Proposed Standard This document is the product of the BGP Enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-acceptown-community/ Technical Summary Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system. Working Group Summary: Opposition to the proposal was initially expressed by one contributor, but there was good support for adoption and no particular follow-up from that contributor. Document Quality: The specs are clear and concise, and document a fairly straightforward optional change to the BGP protocol procedures. The document was discussed in both l3vpn and idr working groups. These specs have been implemented at least in Cisco's IOS XR with field deployment. Personnel: Thomas Morin is the Document Shepherd. Alvaro Retana is the responsible AD. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Protocol Action: 'MVPN: Using Bidirectional P-Tunnels' to Proposed Standard (draft-ietf-bess-mvpn-bidir-04.txt)
The IESG has approved the following document: - 'MVPN: Using Bidirectional P-Tunnels' (draft-ietf-bess-mvpn-bidir-04.txt) as Proposed Standard This document is the product of the BGP Enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-bidir/ Technical Summary A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the Provider Multicast Service Interface (PMSI) Tunnel attribute. Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513, 6514 and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels. Working Group Summary The consensus for adoption back in 2011 was rough, with a few contributors disagreeing on the scope that bidir P-tunnels should apply to. This debate has settled down a long time ago and the document has evolved since; no disagreement was expressed in the last years, nor during the last calls. Document Quality The document is believe to be of good quality by the shepherd. It can be noted that it was written by a co-autor of the base mVPN specs based on an understanding of underspecified areas, which are now addressed. It has been indicated that Cisco has implemented the two main methods described by these specs, the Flat Partitioned Method (with MP2MP LSPs) and the Unpartitioned method (with MP2MP LSPs and also with BIDIR-PIM). The document had two thorough reviews (by a WG contributor and by the shepherd), leading to substantive changes in the document. Personnel Thomas Morin is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Last Call: draft-ietf-bess-orf-covering-prefixes-03.txt (Covering Prefixes Outbound Route Filter for BGP-4) to Proposed Standard
The IESG has received a request from the BGP Enabled Services WG (bess) to consider the following document: - 'Covering Prefixes Outbound Route Filter for BGP-4' draft-ietf-bess-orf-covering-prefixes-03.txt 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 i...@ietf.org mailing lists by 2015-02-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-bess-orf-covering-prefixes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-bess-orf-covering-prefixes/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2397/ http://datatracker.ietf.org/ipr/2398/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
