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
July 14, 2006
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
July 14, 2006
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.
July 14, 2006
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
July 14, 2006
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
July 14, 2006
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
July 14, 2006
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”
July 14, 2006
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
July 14, 2006
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
July 14, 2006
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)
July 14, 2006
IETF 66, L3VPN WG

11. BGP-MVPN Update draft-raggarwa-l3vpn-2547bis-mcast-bgp-02.txt
The following slides list the main changes
July 14, 2006
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
July 14, 2006
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
July 14, 2006
IETF 66, L3VPN WG

14. C-Multicast Routing Protocol
Added procedures for mLDP as a C-multicast routing protocol
For Carrier’s Carrier
July 14, 2006
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
July 14, 2006
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
July 14, 2006
IETF 66, L3VPN WG