[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Advertising of inter-AS TE links
adrian
what i am saying is that flooding inter-AS TE link when the topology
is in Y (AS_1 connected to both AS_2 and AS_3) is de-facto covered
the point is that PCE or not PCE the resulting problematic in terms
of blocking is identical
either the problem is linearized beforehand and then both solution
would lead to a result or it is not and then the path discovery aka
path exploration issue is left unsolved by both techniques
thanks,
- d.
"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
17/01/2007 13:15
Please respond to "Adrian Farrel"
To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: <ccamp@ops.ietf.org>
Subject: Re: Advertising of inter-AS TE links
Yes, Dimitri, I agree that the situation you describe is not solved by
limited flooding of inter-AS TE links within only their adjacent ASes.
It is my view that this wider problem space has been delegate for
resolution
by PCE. That is, in order to fully resolve the problem by flooding of TE
link information it would be necessary to also aggregate TE reachabilty
across AS_2 and AS_3 in your example. Such aggregation is non-trivial
given
the number of TE parameters and the number of potential routes, and so we
would have at least one of:
- excess information flooding
- excess aggregation processing
- valueless information flooding.
In the light of these options we (the Routing Area) decided to pursue PCE
as
a solution.
Adrian
----- Original Message -----
From: <Dimitri.Papadimitriou@alcatel-lucent.be>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>; "'JP Vasseur'" <jvasseur@cisco.com>; "'Mach
Chen'"
<mach@huawei.com>; <owner-ccamp@ops.ietf.org>; "ZhangRenhai"
<zhangrenhai@huawei.com>
Sent: Wednesday, January 17, 2007 11:26 AM
Subject: Re: Advertising of inter-AS TE links
> 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.
>>>
>>> >
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>