[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
Re: [bess] AD Review of draft-ietf-bess-mvpn-extranet-03
On 11/17/15, 4:33 PM, "Eric C Rosen" wrote: >[Eric] Alvaro, thanks for your review. I just posted revision -04, >with a number of edits made in response to your comments. Thanks! I've requested IETF Last Call and put the document on the Telechat agenda. Alvaro. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags -> adopted
Hi working group, We have a new working group document. Authors, can you please repost as draft-ietf-bess-bgp-vpls-control-flags ? Thank you, -Thomas/Martin 2015-10-26, Ravi Singh: Hi Thomas, Martin Before adopting this draft, we would like hear people actually experiencing pain related to not solving this issue and hear about implementations in actual products. In a network where some BGP-VPLS PEs have ability to insert CW and some do not, not implementing section 3 has potential to cause the PW to not come up or cause dropped packets (depending on implementation). Section 3 of this draft is implemented in JunOS. See last paragraph on http://www.juniper.net/techpubs/en_US/junos14.1/topics/concept/vpls-bgp-control-word-overview.html This was implemented in response to a specific-network-deployment-issue. The key aspect of RFC4761 that necessitates the text of section 3 of this draft is that the NLRI-advertising-PE is predicating on all other PEs in the same VPLS, that they must or must-not insert the CW, for example, regardless of whether they have the capability or not. [See https://tools.ietf.org/html/rfc4761#section-3.2.4] This is in contrast to the proposed modification (for a different purpose) where this PE is just advertising its ability (https://tools.ietf.org/html/draft-ietf-bess-fat-pw-bgp-00#section-2) The proposed text in section 3 provides a way around presumption of other-PEs' abilities. Section 4 provides an extension of the same intent for a deployment where the transport LSP maybe a p2mp LSP. Section 5 generalizes the previous sections as deployed to multi-homing scenarios. Both p2mp and multi-homing have some deployments and may run into the issue. Regards Ravi -Original Message- From: thomas.mo...@orange.com [mailto:thomas.mo...@orange.com] Sent: Monday, October 5, 2015 12:29 AM To: bess@ietf.org; draft-singh-bess-bgp-vpls-control-fl...@tools.ietf.org; Ravi Singh ; Kireeti Kompella ; senad.palislamo...@alcatel-lucent.com Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags Authors of draft-singh-bess-bgp-vpls-control-flags, working group, The support base for this proposal is not large. Before adopting this draft, we would like hear people actually experiencing pain related to not solving this issue and hear about implementations in actual products. Let's consider this poll for adoption open until we hear more. Best, Thomas/Martin thomas.mo...@orange.com : Hello working group, This email starts a two-week poll on adopting draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item. Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons). This poll runs until **September 29th**. *Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). ==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thank you, Martin & Thomas bess chairs [1] https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
Hi Diego, Thanks for your comments. Pls see inline with [Vincent]. Vincent 发件人: BESS [mailto:bess-boun...@ietf.org] 代表 Diego Garcia del Rio 发送时间: 2015年11月18日 14:25 收件人: bess@ietf.org 主题: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Some comments from my side, I think the draft makes quite a few assumptions on specific implementation details that are way too general to be considered widely available. Most of the TOR devices today already pay a double-pass penalty when doing routing of traffic in/out of vxlan-type tunnels. Only the newest generation can route into tunnels without additional passes. And are definitively limited in being able to arbitrary select UDP ports on a per tunnel basis. In fact, most are even limited at using more than one VNID per "service" of sorts. [Vincent]: Yes, the new generation BCM chipset has already supported VXLAN routing without additional passes. For OVS/TOR, VXLAN encapsulation is more popular than MPLSoGRE/UDP, and has better performance. The IP-addressed based implementation which would, I assume, imply assigning one or more CIDRs to a loopback interface on the ASBR-d is also quite arbitrary and does not seem like a technically "clean" solution. (besides burning tons of IPs). As a side-note, most PE-grade routers i've worked with were quite limited in terms of IP addresses used for tunnel termination and it wasn't that just a simple pool can be used. [Vincent]: I think the larger VTEP IP address range on ASBR-d has no limitations. For the hardware on ASBR-d, it has capability to terminate multiple VXLAN tunnels with arbitrary destination VTEP IP addresses. Wim's mentions on cases where the Application itself, hosted in a datacenter, would be part of the option-C interconnect, was dismissed without much discussion so far, while, if we look in detail at the type of users which will even consider a complex topology like model-C its most likely users and operators very familiar with MPLS VPNs in the WAN. Those type of operators will most likely be very interested in deploying MPLS or WAN-grade applications (i.e., virtual-routers or other VNFs) in the DC and thus its highly likely that the interconnect would not terminate at the NVE itself but rather the TS (the virtual machine). Also, the use of UDP ports at random would imply quite complex logic on the ASBR-d IMHO. Im not saying its impossible, but since the received packet now not only has to be received on a random (though locally chosen) UDP port and this information preserved in the pipeline to be able to do the double-tunnel-stitching, it sounds quite complex. I am sure someone in the list will mention this has already been implemented somewhere, and I won't argue with that. And let's not even bring into account what this would do to any DC middlebox that now has to look at vxlan over almost any random port. We have to go back to the "is it a 4 or is it a 6 in byte x" heuristics to try to guess whether the packet is vxlan or just something entirely different running over IP. [Vincent]: Using NP or multi-core CPU hardware technology, it can be implemented although deeper packet inspection is needed to perform UDP port and MPLS stitching. In general I feel the proposed solution seems to be fitting of a specific use-case which is not really detailed in the draft and does not describe a solution that would "elegantly" solve the issues at hand. It just feels like we're using any available bit-space to stuff data into places that do not necesarily belong. Yes, MPLS encapsulations on virtual switches are not yet fully available, and there can be some performance penalty on the TORs, but the solutions are much cleaner from a control and data plane point of view. Maybe I'm too utopic. [Vincent]: I think pure VXLAN solution has its scenario, it's general rather than specific. We can't require all OVS/NVEs support VXLAN + MPLSoGRE at the same time. Best regards, Diego - Hi, The problem we are trying to solve is to reduce data center GW/ASBR-d's forwarding table size, the motivation is same as traditional MPLS VPN option-C. Currently, the most common practise on ASBR-d is to terminate VXLAN encapsulation, look up local routing table, and then perform MPLS encapsulation to the WAN network. ASBR-d needs to maintain all VM's MAC/IP. In Option-C method, only transport layer information needed to be maintained at GW/ASBR-d, the scalability will be greatly enhanced. Traditonal Option-C is only for MPLS VPN network interworking, because VXLAN is becoming pervasive in data center, the solution in this draft was proposed for the heterogeneous network interworking. The advantage of this solution is that only VXLAN encapsulation is required for OVS/TOR. Unlike Wim's solution, east-west bound traffic uses VXLAN encap, while north-south bound traffic uses M
