Re: draft-otani-ccamp-interas-gmpls-te-00.txt

Tomohiro Otani <otani@kddilabs.jp> Wed, 28 July 2004 01:59 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27809 for <ccamp-archive@ietf.org>; Tue, 27 Jul 2004 21:59:55 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpdlH-0004IG-LV for ccamp-archive@ietf.org; Tue, 27 Jul 2004 22:01:44 -0400
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpdUe-000NxN-57 for ccamp-data@psg.com; Wed, 28 Jul 2004 01:44:32 +0000
Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpdUc-000Nwy-IC for ccamp@ops.ietf.org; Wed, 28 Jul 2004 01:44:31 +0000
Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 54D92EC89E; Wed, 28 Jul 2004 10:44:28 +0900 (JST)
Received: from silver.onw.kddlabs.co.jp (silver.onw.kddlabs.co.jp [172.19.83.4]) by mandala.kddilabs.jp (Postfix) with ESMTP id D73F0EC8C3; Wed, 28 Jul 2004 10:44:27 +0900 (JST)
Received: from T-OTAN.kddilabs.jp ([172.19.83.39]) by silver.onw.kddlabs.co.jp (ExpressMail 4.01) with ESMTP id BAA266754; Wed, 28 Jul 2004 10:44:27 +0900 (JST)
Message-Id: <6.0.0.20.2.20040728094655.048b55f8@mail.onw.kddlabs.co.jp>
X-Sender: otani@mail.onw.kddlabs.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3
Date: Wed, 28 Jul 2004 10:44:24 +0900
To: Adrian Farrel <adrian@olddog.co.uk>, mc-hayashi@kddilabs.jp, okamoto.satoru@lab.ntt.co.jp
From: Tomohiro Otani <otani@kddilabs.jp>
Subject: Re: draft-otani-ccamp-interas-gmpls-te-00.txt
Cc: ccamp@ops.ietf.org
In-Reply-To: <004d01c473be$0fbb7360$455708c3@Puppy>
References: <004d01c473be$0fbb7360$455708c3@Puppy>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_7216640==.ALT"
X-Virus-Scanned: by amavisd-new
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027

Hi Adrian,

Thank you for your comments.

Some of SPs including ourselves have a plan to introduce GMPLS control plane
technologies for a NGN, and even NGNs should be interconnected with each other,
as SONET/SDH networks are as well as IP/MPLS networks are.

Your supposed model is another example to reveal the necessity of Inter AS TE.
I agree that a crankback mechanism is one of the ways to achieve this.

In terms of the amount of computation by the ASBR, we have to investigate
the impact on the load to the ASBR, hearing from the routing (EGP: BGP4?) expert.
That's why, in the draft, we described that the TE information may be 
statically or
dynamically exchanged.  Operators would like to know the route of a GMPLS LSP
within an AS and the pair of ASBR in advance, if the LSP is established across
the inter AS, especially multiple ISPs, resulting in the implementation of 
TE extensions.

The network resiliency is getting significant more and more in a SP environment.
There was a big discussion about SRLGs among us and so far, as you pointed out,
we do not have any solutions for this.  Altouhgh each SP believes that 
these TE links
are not a SRLG because these are belonging to a different SP, fibers 
accommodating
such TE links may be laid in the same duct otherwise the same tunnel under 
the road.
Our conclusion is that the level of SRLG is another issue.....(one issue is 
indeed how
to assign SRLG IDs to each SP)

Regards,

tomo




At 18:41 04/07/27, Adrian Farrel wrote:
>Hi,
>
>A nice short draft. Congratulations!
>
>Also, it is very good to see SPs bringing forward requirement drafts. Thank you.
>
>I understand the point you are making in the draft, but I am not sure it 
>is specific to GMPLS and switching capabilities.
>
>For example, suppose we modify the bandwidth in your MPLS example network to:
>
>   +----+          +----+    |    +----+          +----+
>   | A1 |----//----| A3 |---------| B1 |----//----| B3 |
>   +----+   10G    +----+   10G   +----+   2.5G   +----+
>      |               |      |        |               |
>      =2.5G           =10G   |        =2.5G           =2.5G
>      |               |      |        |               |
>   +----+          +----+    |    +----+          +----+
>   | A2 |----//----| A4 |---------| B2 |----//----| B4 |
>   +----+   2.5G   +----+   10G   +----+   10G    +----+
>                             |
>          MPLS AS 1          |         MPLS AS 2
>Now, set up a 10G service from A1 to B4.
>AS 1 is going to select the ASBR pair A3/B1 as the shortest path out of AS 1.
>But B1 will fail the setup.
>We must rely on crankback or a wider view (PCE, TE aggregation, etc.) in 
>order to be successful.
>
>
>I think what your draft points out, however, is that the complexity for 
>GMPLS is increased considerably (perhaps to a power of three). It is 
>further worth noting that if we added some speculative future routing 
>constraints (such as source-based lambda selection, optical impairments, 
>etc.) the problem would get even more complex.
>
>Essentially, however, the problem is the same: IP route aggregation is 
>not sufficient to enable inter-domain TE and some other solution is 
>needed. Your proposal for EGP extensions to general reachability 
>information is certainly one option.
>
>The concern that I have heard voiced is that there may be significant 
>churn in this information, and this would result in a significant amount 
>of aggregation computation by the ASBRs. My view is that:
>- in a non-PSC GMPLS network the rate of change is
>   not likely to be significant
>- we should, in any case, specify damping of computation
>   and updates if we proceed with this approach.
>But I would be interested to hear this debated further especially by the 
>EGP experts.
>
>
>
>Your point about SRLGs is very valid. Currently, however, (as I 
>understand it) we don't have a satisfactory encoding for SRLG IDs to allow 
>an ID to be globally unique *and* to allow an SRLG to span ASs.
>
>Thanks,
>Adrian