1 / 15

73rd IETF - Minneapolis

73rd IETF - Minneapolis. draft-wijnands-mpls-mldp-csc-00. I. Wijnands ice@cisco.com E.Rosen erosen@cisco.com M. Napierala mnapierala@att.com. Problem statement. mLDP LSP’s are build based on the Unicast reachability of the root address.

ursa-schmidt
Download Presentation

73rd IETF - Minneapolis

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. 73rd IETF - Minneapolis draft-wijnands-mpls-mldp-csc-00 I. Wijnands ice@cisco.com E.Rosen erosen@cisco.com M. Napierala mnapierala@att.com

  2. Problem statement • mLDP LSP’s are build based on the Unicast reachability of the root address. • Unicast routing decides how the LSP is build through the MPLS network. • If the root address is not reachable in the core, the LSP can’t be established. • This is possible when the root depends on a BGP route and the core is BGP free.

  3. Problem statement (cont) • The edge routers normally have the BGP route and know the exit point in the network that can be used to reach the root of the LSP.

  4. Solution • What if we can “temporarily” replace the FEC to reach the exit router, and restore the original FEC when the exit router is reached. • We define a new mLDP Recursive Opaque encoding. • The root of the ‘new’ FEC will be the IP address of exit router to reach the original root address. • The ‘original’ FEC is encoded into the opaque field of the ‘new’ FEC.

  5. mLDP FEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Address Family | Address Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Root Node Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Length | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ | Opaque Value | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  6. Recursive Opaque Type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | P2MP or MP2MP FEC Element | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  7. Recursive Opaque Type C-FEC: P2MP C-root Opaque X P2MP P-root Opaque type 6 {C-FEC} P-FEC: C-FEC: P2MP C-root Opaque X • C-FEC is the original Customer FEC • C-root is the original root. • P-FEC is the new Provider FEC • P-root is the exit router in the P network

  8. Recursive Opaque Type • The original FEC type is copied into the new FEC, • P2MP, • MP2MP up • MP2MP down. • This makes sure the correct mLDP LSP procedures are followed. • So we’re not introducing a new FEC type…!!

  9. Recursive Opaque Type • The customer FEC (including opaque value) is just encoded into the recursive opaque type. • The solution is independent of the opaque type of the customer. • A single recursive encoding can be used to encode different customer encodings.

  10. Recursive Opaque Type • Is the new FEC unique? • Yes, it is unique if its global table only, the original FEC is part of the P-FEC. • For Carrier's Carrier it may not unique because different customers may have the same C-FEC, resulting in the same P-FEC.

  11. VPN-Recursive Opaque Type • We’re adding an RD to the P-FEC to make it unique per customer of the CsC service.

  12. VPN-Recursive Opaque Type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | P2MP or MP2MP FEC Element | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  13. mLDP CsC • Procedures for both encodings are the same. • The VPN recursive encoding is used for true carriers carrier. • The recursive encoding is used for global table transport, kind of like the RPF vector in PIM.

  14. mLDP CsC • The authors welcome comments…

  15. Questions?

More Related