1 / 6

Hui Ni, Shunwan Zhuan, Zhenbin Li Huawei Technologies IETF 87, Berlin, Germany

BGP Extensions for Setup Service-Driven Co-Routed LSP in L3VPN draft-ni-l3vpn-bgp-ext-sd-co-lsp-00. Hui Ni, Shunwan Zhuan, Zhenbin Li Huawei Technologies IETF 87, Berlin, Germany. Solution Suggested in [draft- li - mpls - serv -driven-co- lsp - fmwk ]. For L3VPN Scenario:

infinity
Download Presentation

Hui Ni, Shunwan Zhuan, Zhenbin Li Huawei Technologies IETF 87, Berlin, Germany

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. BGP Extensions for Setup Service-Driven Co-Routed LSP in L3VPNdraft-ni-l3vpn-bgp-ext-sd-co-lsp-00 Hui Ni, Shunwan Zhuan, Zhenbin Li Huawei Technologies IETF 87, Berlin, Germany

  2. Solution Suggested in [draft-li-mpls-serv-driven-co-lsp-fmwk] • For L3VPN Scenario: • Co-routed RSVP-LSPs between a pair of VRFs could be setup automatically driven by L3VPN Service • It contains 4 steps: • STEP1: Doing L3VPN Service A-D by using VT VPN A-D Route in VRF granularity • STEP2: One side PE(Active PE) setup LSP first and advertise Tunnel Type/ID to other side PE(Passive PE) • STEP3: Passive PE setup reverse LSP based on forward LSP’s Path info and advertise the Tunnel Type/ID back to Active PE • STEP4: Both PEs bind the tunnels together for above L3VPN service. • A new BGP VT Type Route is defined to support above Step2&3 works.

  3. BGP Extensions: VT Tunnel-ID Signal Route(1) • VT Tunnel-ID Signal Route is defined as: • +----------------------------------------------+ • | Local VRF's RD (8 octets) | • +----------------------------------------------+ • | Local Router's IP Address | • +----------------------------------------------+ • | Remote VRF's RD (8 octets) | • +----------------------------------------------+ • | Remote Router's IP Address | • +----------------------------------------------+ • | Tunnel Type (1 octet) | • +----------------------------------------------+ • | Flags (1 octet) | • +----------------------------------------------+ • | Tunnel ID (variable) | • +----------------------------------------------+ • Local VRF’s RD together with Local Router’s IP Address identifies a Local VRF • Remote VRF’s RD together with Remote Router’s IP Address identifies a Remote VRF

  4. BGP Extensions: VT Tunnel-ID Signal Route(2) • VT Tunnel-ID Signal Route(Tunnel Info Part) • +----------------------------------------------+ • | Tunnel Type (1 octet) | • +----------------------------------------------+ • | Flags (1 octet) | • +----------------------------------------------+ • | Tunnel ID (variable) | • +----------------------------------------------+ • Tunnel Type: 2 values are defined: • 0: RESERVED • 1: RSVP-TE Tunnel • other value: to be defined later if need • Flags Field: Lowest 1 Bit is used/defined as R bit (other 7 bits are RESERVED): • 1: Active – Tunnel info is advertised from Active PE to Passive PE • 0: Passive – Tunnel info is advertised from Passive PE to Active PE • Tunnel ID: • Tunnel ID format is defined specific according to Tunnel Type, • For RSVP-TE tunnel, it has same format of SESSION Object defined in RSVP-TE [RFC 3209]

  5. Active/Passive PE Role Auto Selection • Active/Passive PE role COULD be determined by 2 manners: • Manually Configured • Auto Selected through BGP protocol • InVTCapability Negotiation, peer’s Router IDs are compared as unsigned integer, peer with Larger value is selected as Active PE.

  6. Next Steps • Solicit more comments & feedbacks • Revise the draft

More Related