Advertising of inter-AS TE links

["Adrian Farrel" <adrian@olddog.co.uk>]

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