adrian
agreed on the analysis - there is one additional case that
needs to be addressed
AS_1 is connected to AS_2 and AS_3 both connected to AS_4
the ERO, includes AS_1 and AS_4, perfectly clear there is
no intention to pass AS_2 - AS_4 and AS_3 - AS_4 TE link
information to AS_1
but what about AS_1 - AS_2 and AS_1 - AS_3 whose info. is
defacto available
the issue is one sentence, the initial linearization does
not hold in the generic case of loose abstract AS's
comments ?
-d.
"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
17/01/2007 12:00
Please respond to "Adrian Farrel"
To: "ZhangRenhai" <zhangrenhai@huawei.com>, "'JP Vasseur'"
<jvasseur@cisco.com>, "'Mach Chen'" <mach@huawei.com>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: <ccamp@ops.ietf.org>
Subject: Advertising of inter-AS TE links
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.
>