1 / 16

MVPN Update

MVPN Update. Continued work on both architecture draft and BGP-MVPN draft Seeing “light at end of tunnel” ☺ Progress since last time: Carrier’s carrier procedures specified Inter-AS procedures written Single Forwarder Selection procedures written

herb
Télécharger la présentation

MVPN Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MVPN Update • Continued work on both architecture draft and BGP-MVPN draft • Seeing “light at end of tunnel” ☺ • Progress since last time: • Carrier’s carrier procedures specified • Inter-AS procedures written • Single Forwarder Selection procedures written • Procedures for use of MSDP to avoid tree switching • Refined definition of “MVPN”, to make it clear that some sites may be receive-only and some may be transmit only • Arch. and BGP encoding drafts now aligned IETF 66, L3VPN WG

  2. Issues to be Discussed Today • Change: Eliminating (S,G,R) prunes • New (work in progress): • Support of C-bidir trees • Use of MP2MP P-LSPs IETF 66, L3VPN WG

  3. Eliminate (S,G,R) Prunes from BGP Control Plane • Very desirable, reduces state and complexity • Two Alternative Methods: • MSDP-based: Every C-RP uses MSDP to announce Active Sources to at least one PE • Coordinated switch: when one PE switches from (C-*,C-G) to (C-S,C-G), force others to do so as well • Both methods use BGP-based Source Active messages, already defined. IETF 66, L3VPN WG

  4. MSDP-Based Method • Each C-RP talks MSDP to a PE • Some variations, such as co-location and anycast RP • PEs use BGP to tell each other of active sources • When a PE has PIM Join(*,G) state from a CE, the PE instead joins all the (S,G)’s • If MSDP message has piggybacked data packet, send it over default I-PMSI, if possible • Prevents “first packet loss” • Does add some complications to the procedures for handling packets received on MI-PMSI • Optional IETF 66, L3VPN WG

  5. Coordinated Switch Method • CE switches to (S,G) • CE sends Join(S,G) to upstream PE PIM neighbor • That PE uses BGP to send (S,G) Join • That Join is received by PE connected to source • PE connected to source sends BGP-based Source Active message • Other PEs switch to (S,G) as well because they receive the Source Active message • Ingress PE on (C-*,C-G) (PE connected to site that has RP) sends PIM (S,G,R) prune to upstream CE neighbor • But no BGP-based (S,G,R) prune messages IETF 66, L3VPN WG

  6. Support for C-Bidir Trees • Assuming unidirectional P-Tunnels • PIM Bidir has complex forwarding rules depending on whether packet is received from up- or downstream • Must carefully define how a PE determines whether a given packet is traveling upstream or downstream • PIM Bidir fundamentals: choose single Designated Forwarder for packets from upstream on each “link” • We have BGP-based procedures for this choice • We can discard packets that come from upstream but from the wrong transmitter • Transmitter always known when unidirectional P-tunnels are used IETF 66, L3VPN WG

  7. Choose one Ingress PE • For this slide, assume everything is intra-AS • Choose one PE to be ingress PE for the C-tree • Procedures already defined • Other PEs must not transmit packets arriving from upstream • If some wrong PE does do so, PEs receiving packets arriving from upstream from wrong PE must discard them • As long as P-trees are unidirectional, can always tell who transmitted a given packet, can discard if transmitter is “wrong” IETF 66, L3VPN WG

  8. Multi-AS C-Bidir • Choose “Root AS” • Need to define procedures • Previous slide applies within root AS • At border routers, discard packets from upstream which aren’t from proper root AS • Root AS can always be identified, as there are distinct unidirectional tunnels from each ingress AS IETF 66, L3VPN WG

  9. MP2MP LSPs as Intra-AS Tunnels • For every multicast flow: • Single ingress PE must be designated transmitter of packets traveling downstream • We have procedures to choose a single ingress PE • For safety’s sake we want an egress PE to discard packets arriving from wrong ingress PE • Therefore it must be possible to identify packets on the LSP by their transmitters • Really a matter of aggregating P2MP tunnels into an MP2MP tunnel • Dependency on work in progress in MPLS WG IETF 66, L3VPN WG

  10. MP2MP LSPs Aggregating Segments of Inter-AS Tunnels • Inter-AS Tunnels are always P2MP • Intra-AS segments of Inter-AS tunnels are therefore inherently P2MP • Within a single AS, we would like to aggregate all these segments (for a given MVPN) into a single MP2MP LSP • Dependency on MPLS context-label procedures (work in progress) to identify transmitting ASBR, with upstream-assigned label identifying the particular inter-AS tunnel (i.e, the root AS of that tunnel) IETF 66, L3VPN WG

  11. BGP-MVPN Update • draft-raggarwa-l3vpn-2547bis-mcast-bgp-02.txt • The following slides list the main changes IETF 66, L3VPN WG

  12. New Auto-Discovery (AD) Route Types • S-PMSI AD route • To switch traffic for one or more <C-S, C-Gs> to a S-PMSI. • Switching to S-PMSI described in terms of the S-PMSI AD route • Different AD route types for I-PMSI AD and S-PMSI AD IETF 66, L3VPN WG

  13. New Auto-Discovery (AD) Route Types… • Source Active AD route • Used to advertise active sources for the scheme that co-locates a C-RP on a PE • This scheme described in terms of the SA AD route • Used to advertise an active source to force all PEs to switch to the C-source tree from the C-shared tree, when one PE switches from the C-source tree to the C-shared tree • Procedures for choosing a single forwarder PE when switching from RPT to SPT described IETF 66, L3VPN WG

  14. C-Multicast Routing Protocol • Added procedures for mLDP as a C-multicast routing protocol • For Carrier’s Carrier IETF 66, L3VPN WG

  15. C-Multicast Routes • C-multicast route dampening • Dampening of C-mcast prunes • May cause a PE to receive unwanted traffic • Dampening of C-mcast joins • May result in join latency for the first join • Dampening of leaf AD routes • C-multicast route aggregation • Clarified C-multicast route aggregation by RR and also by an ASBR IETF 66, L3VPN WG

  16. Next Steps • Procedures for using MSDP or PIM Anycast RP between C-RP and PE based scheme • Procedures for using BGP or RSVP-TE as the PE-CE protocol for Carrier’s Carrier model are for further study IETF 66, L3VPN WG

More Related