Download
1 / 8
80 likes | 96 Views
Extensions to IGP for Inter-AS TE draft-ietf-ccamp-ospf-interas-te-extension-02.txt draft-chen-ccamp-isis-interas-te-extension-02.txt Mach Chen ( mach@huawei.com ) Renhai Zhang ( zhangrenhai@huawei.com ) Xiaodong Duan(duanxiaodong@chinamobile.com). Background & Objectives.
E N D
Extensions to IGP for Inter-AS TEdraft-ietf-ccamp-ospf-interas-te-extension-02.txt draft-chen-ccamp-isis-interas-te-extension-02.txtMach Chen(mach@huawei.com) Renhai Zhang(zhangrenhai@huawei.com)Xiaodong Duan(duanxiaodong@chinamobile.com)
Background & Objectives • Inter-AS TE requirements have been defined in RFC4216 for many years. • When performing inter-AS path computation, a path computation entity needs to know the TE information of: • Intra-area links (RFC 3630 and RFC 3784), and • Inter-AS links (not standard) • Extensions to IGP(OSPF and ISIS) in support of inter-AS TE • Advertise the Inter-AS TE links within local AS (by ASBR)
Summary of the OSPF draft • Define two separate LSAs for OSPFv2 and OSPFv3 • Inter-AS-TE-v2 LSA • Type 10 or type 11 Opaque LSA • Inter-AS-TE-v3 LSA • Set U bit to 1 • S2S1 bits (could be set to “01” or “10”) • Add three new sub-TLV to the Link TLV • Remote AS Number sub-TLV • Carry the AS Number of the remote AS • IPv4 Remote ASBR ID TLV • Carry the IPv4 ASBR ID of the remote ASBR • IPv6 Remote ASBR ID TLV • Carry the IPv6 ASBR ID of the remote ASBR • Facilitate the Per-domain and BRPC for inter-AS path computation
Changes from 01 version • Include OSPFv3 functionality • Define two separate LSAs for OSPFv2 and OSPFv3 instead of using the “TE LSA” which is defined in RFC3630 • Using type of LSA to identify an inter-AS link instead of link type • To make sure v2 and v3 have similar implementations • Already discussed in CCAMP and OSPF lists, no objections received • For an inter-AS link, using the remote ASBR ID to identify the remote side of an inter-AS TE link • Not carrying the Link ID sub-TLV in OSPFv2 advertisement, and • Not carrying the Neighbor ID sub-TLV in OSPFv3 advertisement, and • The IPv4/IPv6 Remote ASBR ID sub-TLV is required. • Many editorial and wording changes
Summary of the ISIS draft • Define a new TLV: Inter-AS Reachability TLV • Same as Extended IS Reachability TLV, but with a single octet control field introduced: • A single bit of flooding-scope information, and • A single bit of up/down information • 6 reserved bits • In addition to the sub-TLVs defined in ISIS-TE, three new sub-TLVs are defined for inclusion in the Inter-AS Reachability TLV • Remote AS Number sub-TLV • IPv4 Remote ASBR ID sub-TLV • IPv6 Remote ASBR ID sub-TLV • If the TE Router ID needs to reach all routers within an entire ISIS routing domain: • Propose using IS-IS Capability TLV to advertise the TE Router ID of the ASBR, two new sub-TLVs are defined for inclusion in the IS-IS Capability TLV to do this: • IPv4 TE Router ID sub-TLV, and • IPv6 TE Router ID sub-TLV
Changes from 01 version • Using Inter-AS Reachability TLV, instead of using the Extended IS Reachability TLV for inter-AS TE • In some cases, the inter-AS TE information needs to reach all routers in the entire ISIS routing domain, but the Extended IS Reachability TLV only has area-flooding scope. • The approach proposed in ISIS draft is similar to that in OSPF draft. • Propose a mechanism which uses the IS-IS Capability TLV to advertise the TE Router ID of the ASBR to reach all routers within an entire ISIS routing domain • The TE Router ID should/must have the same flooding scope as the Inter-AS Reachability TLV does. • Some editorial and wording changes
Next steps • Request that the ISIS draft become a WG document • Resolve upcoming comments.
