Hi Acess, all,
> Hi Adrian, et al,
>
> On Jul 24, 2007, at 11:31 PM, Adrian Farrel wrote:
>
>> Hi Vishal,
>>
>>> I have a doubt regarding the opposition I heard your opposition to
>>> the
>>> introduction of a new Link type (Inter-AS link) field.
>>
>> So, the reason why a separate link type was proposed was a
>> suggestion to help the other nodes (also legacy nodes) in the rest
>> of the network. We wanted to allow a distinction to be made between
>> inter-AS TE links and intra-AS TE links. (Note also that the intra-
>> AS links may have normal IGP advertisements, but the inter-AS links
>> are only advertised as TE links.)
>>
>> But, I think we are happy to be guided by the OSPF WG on this.
>
> I wouldn't base this decision solely on my questions on what is and
> isn't necessary for inter-AS TE. If you look at how OSPF interacts
> with iBGP, we don't require the AS numbers to permeate into OSPF
Don't require does not mean don't allow, in fact, the AS number attribute of
an inter-AS link is a kind of "identifier" just as other attribues and such AS
number may not be from BGP.
> (given that RFC 1745 is historic). However, I'd look to those
> implementing this to verify that this makes sense for inter-AS TE.
Yes, impementing always is the best method to check it out.
The AS number attribute is optinal for per-domain method when there are no AS
numbers as loose hop in the ERO.
But for PCE-based path computation senario, especially for BRPC method, the AS
number attribute is very useful and essential.See the following example
PCE1<------->PCE2<------->PCE3
R1------R3----R5-----R7------R9-----R11
| | \ | / |
| | \ | ---- |
| | \ | / |
-----R4----R6 --R8------R10----R12
: :
- AS1 -->:<---- AS2 --->:<--- AS3 --->
In the above figure, three PCEs(PCE1 PCE2 PCE3) work together to perform
inter-AS path computation, hence to setup a path from r1 to r12.The traversed
domains are assumed to be selected before path computation: AS1->AS2->AS3.
Firstly, the path computation request originated from r1 is relaied(by PCE1 and
PCE2) to PCE3, then PCE3 begins to compute the path segments which from the
entry boundary nodes that provide connection to AS2 to the destination in its
responsiable domain(AS3), but PCE3 only knows that the path should be from AS2,
so PCE3 needs to determine the entry boundary nodes based on its upstream AS
number(AS2).
And we will enhace the PCE-based senario in the next revision.
Best regards,
Mach
> Thanks,
> Acee
>
>
>
>>
>> If the WG feels that we should use the same link type, that will be
>> fine. But if the WG feels we should use a separate link type or
>> doesn't care, we should use a different link type.
>>
>>> I know of CSPF implementations that do a two way check before we can
>>> use a link for CSPF. In the Inter-AS case, there will not be such a
>>> case. Will that not mean that even when a router is down and its LSA
>>> exist, we will still use the links for SPF?
>>
>> Something that has been missed, I think, and was raised by John
>> Drake in the meeting, is that we need to advertise both directions
>> of the inter-AS TE link. That actually means that the local ASBR is
>> going to do a "proxy" advertisement.
>>
>>> I also overheard Dave Ward comment that such information could
>>> also be
>>> useful in case of OAM too.
>>
>> Thanks,
>> Adrian
>>
>>
>> _______________________________________________
>> OSPF mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/ospf
>
>
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
