Re: Advertising of inter-AS TE links

[ZhangRenhai <zhangrenhai@huawei.com>]

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.
> >>
> >> >
> >
> >
> >
> >
> >
> >
> 
>