Re: Advertising of inter-AS TE links
ZhangRenhai <zhangrenhai@huawei.com> Sat, 27 January 2007 07:22 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAhtB-0003vj-3G for ccamp-archive@ietf.org; Sat, 27 Jan 2007 02:22:17 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAht4-00077I-5y for ccamp-archive@ietf.org; Sat, 27 Jan 2007 02:22:17 -0500
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1HAhZ4-0003zB-4J for ccamp-data@psg.com; Sat, 27 Jan 2007 07:01:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7
Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from <zhangrenhai@huawei.com>) id 1HAhYy-0003yN-DR for ccamp@ops.ietf.org; Sat, 27 Jan 2007 07:01:28 +0000
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCI00MNFM63P9@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Sat, 27 Jan 2007 15:01:15 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCI00GR1M62VM@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Sat, 27 Jan 2007 15:01:15 +0800 (CST)
Received: from z18605 ([10.111.12.160]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCI006BFM5FNX@szxml03-in.huawei.com> for ccamp@ops.ietf.org; Sat, 27 Jan 2007 15:01:14 +0800 (CST)
Date: Sat, 27 Jan 2007 15:00:49 +0800
From: ZhangRenhai <zhangrenhai@huawei.com>
Subject: Re: Advertising of inter-AS TE links
In-reply-to: <058301c73a26$ca1bdb60$0a23fea9@your029b8cecfe>
To: 'Adrian Farrel' <adrian@olddog.co.uk>, 'JP Vasseur' <jvasseur@cisco.com>, 'Mach Chen' <mach@huawei.com>, 'Dimitri Papadimitriou' <Dimitri.Papadimitriou@alcatel-lucent.be>
Cc: ccamp@ops.ietf.org
Message-id: <000201c741e0$e2699b00$a00c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="gb2312"
Content-transfer-encoding: quoted-printable
Thread-index: Acc6J2g4vXZOi5P2TfGCP/3OD10EcQHtsxIA
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Hi, Adrian I have submitted a draft last year in which the BGP extension to advertise inter-as link connection information is described: http://tools.ietf.org/wg/pce/draft-zhang-pce-locate-asbr-00.txt I'm now drafting the problem statements and corresponding IGP(so far only OSPF in the doc) extension, it's upcoming soon. Regards, Zhang Renhai > Hi, > > Since this discussion is blossoming, it can have its own thread... > > I'd like to try to bring some focus. > > The motivation seems clear... > When computing a path through one AS into another AS, the computation point > needs to know about TE links that connect to the next AS. This enables it to > select: > - A TE link that connects to the next AS > - A TE link that is suitable for the LSP. > > Other questions about reachability and TE connectivity across the next AS > are out of scope and have been defined as problems that PCE is used to > solve. This is an important point! We are not talking about distributing > information to provide a graph to compute multi-AS TE paths. That is (IMHO) > out of scope and what PCE was invented to solve. > > I see two scenarios. > 1. An ASBR has two links to the next AS. > 2. An AS has two ASBRs to the next AS. > In either case, the AS may have multiple ASBRs. > > The path computation point must determine: > a. The set of ASBRs that connect to the next AS. > b. Which ASBR to use. > c. Which inter-AS link to use. > > Some cases are easy: > - If the ERO already includes the ASBR address > no choice to be done > - If the ASBR has multiple inter-AS links then > the choice can be a local matter (no > advertising required) > > But other cases require advertisement of the inter-AS link as a TE link > with: > - the normal TE information > - an indication that this is an inter-AS link > - the identity of the remote ASBR > - the identity of the remote AS > > This information is needed through-out the local AS. That is, although all > of the ASBRs may be interested for LSPs that entirely cross the local AS, > and although a PCE could be a BGP speaker, the information is also needed > for LSPs that are originated within the AS. > > Thus we must decide how paths for LSPs that exit the AS will be computed: > > - If we require computation by a PCE that > is (somewhat) centralised within the AS > we can use BGP to distribute the information > and require that the PCEs are BGP speakers. > (Note that the information is only needed > within the local AS, so we would limit its > flooding by BGP.) > > - If we require computation by any LSR in > the AS (i.e. PCE function is fully > distributed) then we require IGP flooding > of the information across the whole AS. > > In both cases the cost is not particularly high since the number of inter-AS > TE links will not be large. > > Thanks, > Adrian > > ----- Original Message ----- > From: "ZhangRenhai" <zhangrenhai@huawei.com> > To: "'JP Vasseur'" <jvasseur@cisco.com>; "'Mach Chen'" <mach@huawei.com> > Cc: <ccamp@ops.ietf.org>; <owner-ccamp@ops.ietf.org> > Sent: Wednesday, January 17, 2007 4:11 AM > Subject: 答复: Progressing the three inter-domain I-Ds > > > >> > After reading these docs I also have the same concern with you > >> > about inter-ASBR links flooding. > >> > I think, in oder to perform inter-AS path computation, inter-ASBR > >> > links fooding is desired. > >> > >> As pointed out in the document, this is not a MUST, but an optimization. > >> > >> > But > >> > such kind of inter-ASBR link info should include more information > >> > than "normal" TE links do, > >> > e.g: the inter-ASBR links info SHOULD still include the peer AS > >> > number and peer ASBR router id > >> > besides those link info which has been specified in rfc3630 and > >> > rfc3784. > >> > >> I don't think that the peer AS number info should be included in the > >> IGP for sure. You should rely on BGP for that purpose. > > [ZhangRenhai>] maybe BGP is not enough for some circumstance, take this > > scenario for example: > > > > / ASBR4 > > ASBR1--------ASBR2-- > > \ ASBR3 > > ------AS 1----------||-----AS 2---------- > > > > ASBR2 in AS 1 would only advertise the optimal route received respectively > > from ASBR3 and ASBR4 (both are from AS 2) to ASBR1, ASBR1 also doesn't > > have > > the full knowledge of topology(such as which AS the ASBR2 is connected to > > and which router is in that AS)between the two AS. PCE would have the > > similar problem when performing the brpc. > > Another issue, when ASBR1 receives a path mesg from upstream domain > > containing a loose ERO:AS number(say AS2), there should be a method for it > > to locate the asbr(say ASBR2) in the local domain connected to AS2. > > > > Regards, > > Zhang Renhai > > > >> > >> > > >> > So I think there need a document to clarify and specify inter-ASBR > >> > links flooding. we are considering to > >> > write such a document. If someone interested in such work, we could > >> > cooperate. > >> > > >> > >> JP. > >> > >> > > > > > > > > > > > > > > >
- Progressing the three inter-domain I-Ds Adrian Farrel
- Re: Progressing the three inter-domain I-Ds Dimitri.Papadimitriou
- Re: Progressing the three inter-domain I-Ds Peng He
- Re: Progressing the three inter-domain I-Ds Mach Chen
- Re: Progressing the three inter-domain I-Ds Peng He
- Re: Progressing the three inter-domain I-Ds Mach Chen
- Re: Progressing the three inter-domain I-Ds Peng He
- Re: Progressing the three inter-domain I-Ds Mach Chen
- Re: Progressing the three inter-domain I-Ds Adrian Farrel
- Re: Progressing the three inter-domain I-Ds JP Vasseur
- Re: Progressing the three inter-domain I-Ds JP Vasseur
- Re: Progressing the three inter-domain I-Ds JP Vasseur
- Re: Progressing the three inter-domain I-Ds JP Vasseur
- Re: Progressing the three inter-domain I-Ds Dimitri.Papadimitriou
- Re: Progressing the three inter-domain I-Ds Dimitri.Papadimitriou
- 答复: Progressing the three inter-domain I-Ds ZhangRenhai
- Advertising of inter-AS TE links Adrian Farrel
- Re: Advertising of inter-AS TE links Dimitri.Papadimitriou
- Re: 答复: Progressing the three inter-domain I-Ds JP Vasseur
- Re: Advertising of inter-AS TE links Adrian Farrel
- Re: Advertising of inter-AS TE links Dimitri.Papadimitriou
- Re: Advertising of inter-AS TE links ZhangRenhai
- Fwd: Progressing the three inter-domain I-Ds JP Vasseur