1. 61st IETF Washington DC, Nov. 2004 GMPLS Inter-domain Traffic Engineering Requirements GMPLS Inter-domain Traffic Engineering Requirements draft-otani-ccamp-interas-gmpls-te-01.txt Tomohiro Otani otani@kddilabs.jp Kenji Kumaki ke-kumaki@kddi.com Satoru Okamoto okamoto.satoru@lab.ntt.co.jp

2. 61st IETF Washington DC, Nov. 2004 Summary of this requirement draft This draft fits to the following charter item –“defining signaling and routing mechanisms to create paths that span multiple IGP areas, multiple ASes, and multiple providers”. This draft –clarifies the need for dynamic or static TE information exchange between GMPLS-controlled domains. This is in addition of requirements imposed by inter-domain MPLS TE. –describes the general requirement for GMPLS Inter-AS TE signaling, routing and management. –is jointly proposed by SPs (KDDI/NTT) and is tailored to improve operational efficiency for interconnecting GMPLS networks. This draft can be used by following applications –L1-VPN –MPLS-TE LSC GMPLS AS 1 GMPLS AS 2 AS boarder nodes LSC/SONET/10G LSC/SONET/2.5G Ingress (2.5G SONET LSP) Egress Based on GMPLS constrains Shortest path AS 1’s view

3. 61st IETF Washington DC, Nov. 2004 Major Changes Added section to explain (under the agreement of the last meeting) –General requirement for GMPLS Inter-AS TE signaling, routing and management EGP extensions for GMPLS –Requirement for TE parameters in EGP and EGP redistribution GMPLS Inter-AS signaling for the support of TE –GMPLS per-AS basis/end-to-end path calculation support –Fast Recovery support GMPLS Inter-domain TE Management –Requirement for fault management and TE MIB Incorporated feedback from various discussions –Updated the section of “Introduction” –Aligned to the general description “inter domain” from “AS” or “area” –Changed to the clear comparison model Between PSC (namely MPLS) and Non-PSC (namely GMPLS) –Fixed the inconsistency in comparison models –Added “protection type” for TE parameters exchanged over domains New co-author –Kenji Kumaki from KDDI Corporation

4. 61st IETF Washington DC, Nov. 2004 Remaining Issues Consider the general description from “a GMPLS LSP created within an AS will be announced as a (transit) link resource” in section 5.1 –Should replace a GMPLS-LSP with a GMPLS FA-LSP Investigate the extra load of ASBRs by introducing GMPLS EGP extensions –Minimum sets of extensions ? –Necessity of TE parameters per priority ? Investigate a collaboration with L1-VPN work The bit assignment mechanism in SRLG to maintain a global consistency is an open item. To proceed to develop the GMPLS EGP solution as a different draft, do we need re-chartering or ask IDR WG?

5. 61st IETF Washington DC, Nov. 2004 Next Steps Will propose this to be a working group document to initiate a solution work as a separate draft from this. –More discussion and feedback Will investigate GMPLS EGP extensions in another draft.