Re: [Pce] A New Internet-Draft on Advertising of inter-AS TE links

[Zhang Renhai <zhangrenhai@huawei.com>]

Hi,

See in-line please.


> Hi Greg,
> 
>> - would you agree that usually ASBRs are eBGP speakers
>> and are fully mesh connected. In that case eBGP can be
>> viable solution for the inter-AS TE links computation by
>> ASBR.
[ZRH]What do you mean by "eBGP", should it be "iBGP"?
> 
> So the question has to be:
> Do other nodes apart from ASBRs need this information?
> 
> What about an ingress LSR trying to compute a path out of the AS?
> 
> If we require that the ingress LSR always consults an external PCE that is a 
> BGP speaker, then I guess this is fine, but most LSRs today are capable of 
> path computation and could handle this case (for example, for the pd-path 
> scenario) without needing to consult an external PCE.
> 
>> - I'm concerned with scaling aspect of flooding inter-AS TE
>> information throughout both AS and an area
> 
> I have this concern, too, but I wonder how many TE links we are talking 
> about, and how this compares with the number of TE links within an area.
[ZRH]Indeed, so I don't think the additional advertisement in this draft will 
bring out a new scalability issue.

> 
>> and I see that  you're concerned as well (SHOULD for Type
>> 10 and MAY for Type 11). I think that it would be
>> helpful if use of both Type 10 and Type 11 for inter-AS
>> TE Link advertisement be illustrated by scenarios. 
[ZRH]Indeed, as Adrian said below, we still havn't consider very clear some
inter-AS TE applications, consequently, the way for choosing  type 11 or type 10 is not 
given in the draft so far. I just want to relax it for the future discussion and revise this accordingly.

I think
>> that use of area scope makes these OSPF extensions less
>> applicable to inter-AS path computation by the head-end
>> LSR/LER.
[ZRH]Currently, I also think the type 11 may be the batter choice. but I don't think now we have
enough proof to abandon the use of type 10.
> 
> Yes, that would be the case.
> I agree that we need to look more closely at the scenarios. I don't think we 
> have given enough thought to the nested domains case (i.e. areas in ASes) 
> given that both pd-path and brpc (largely) treat the nested case as simply a 
> flat sequence.
> 
>> - Could you please illustrate which links are excluded by the
>> following:
>>"   Routers or PCEs that are capable of processing advertisements of
>>   inter-AS TE links SHOULD NOT use such links to compute paths that
>>   exit an AS to a remote ASBR and then immediately re-enter the AS.
>>   Such paths would constitute extremely rare occurrences and MUST only
>>   be allowed as the result of specific policy configuration at the
>>   router or PCE computing the path."
>> Are there two links that interconnect a pair of ASBRs that belong to two
>> different neighboring ASes?
> 
> Renhai can comment, but I assumed that this meant that two ASes are linked 
> by more than two TE links. The LSP should not under normal circumstances 
> leave AS1 to AS2 through TE link 1 and return to AS1 from AS2 through TE 
> link 2.
[ZRH]Yes, here I meant that we should have some method to prevent computation loop.
Think that there are two pairs of ABSR (R1, R2 belong to AS1 and R3, R4 belong to AS2)
and two links interconnect them(R1 connected with R3, R2 connected with R4 )
and a intra-AS link interconnects R3 and R4. There would be a possibility of computation
loop.

Regards,
Zhng Renhai

> 
> The example you give (ASBR1 in AS1 connects to ASBR2 in AS2 with two links, 
> the LSP goes out on one and back on the other) would be detected as a loop 
> in RSVP-TE, and would not offer any benefit anyway.
> 
> Regards,
> Adrian 
> 
> 
>