Subject: [OSPF] Inter-AS TE

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 24 Jul 2007 18:06:03 -0700

Hi Kireeti,

I have a doubt regarding the opposition I heard your opposition to the
introduction of a new Link type (Inter-AS link) field.

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?

I also overheard Dave Ward comment that such information could also be
useful in case of  OAM too.

Thanks,
Vishwas

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Jul 2007 04:31:22 +0100

Hi Vishal,

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

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.

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

> useful in case of  OAM too.

Thanks,
Adrian

---

From: Mach Chen <[email-masked]>
Date: Wed, 25 Jul 2007 22:27:06 +0800

Hi Adrian, vishal and all,

> But, I think we are happy to be guided by the OSPF WG on this.

Yes, agree.

> link. That actually means that the local ASBR is going to do a "proxy" 

Yes, this will be added in the next revision.

>> useful in case of  OAM too.

Best regards,
Mach

---

From: Acee Lindem <[email-masked]>
Date: Wed, 25 Jul 2007 11:24:04 -0400

Hi Adrian, et al,

On Jul 24, 2007, at 11:31 PM, Adrian Farrel wrote:

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

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  
(given that RFC 1745 is historic). However, I'd look to those  
implementing this to verify that this makes sense for inter-AS TE.

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

---

From: Mach Chen <[email-masked]>
Date: Thu, 26 Jul 2007 00:38:57 +0800

Hi Acess, all,

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

> 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

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Thu, 26 Jul 2007 16:19:35 +0200

Hi,

I have some comment/questions on this topic.

First about the link type I would be concerned if we use the same link type
for intra and inter domain link because I think it may lead to some
confusion on legacy system.
RFC3630 states that unrecognised sub TLV must be ignored. 
So a legacy system will actually see inter domain link as intra domain link.
Generally this would probably have no consequence but the link Id of intra
and inter AS link, if I understand correctly, are allocated from 2 different
address spaces.
So an inter AS link Id may actually match an OSPF router Id of the local
domain.
In this case I think it may lead to some wrong intra AS path computation
from legacy system.

Besides I don't really see the advantage of having a single link type.

A question: is the AS sub TLV mandatory? I guess yes but I'm not sure the
draft states it.

Another question for my understanding about the need to advertise both
directions of the TE link. 
I'm not sure to understand what is the goal of this.
Is it to be able to advertise asymmetric TE information for each direction
of the link?

Thanks
Fabien

-----Message d'origine-----
De : Mach Chen [mailto:[email-masked]] 
Envoyé : mercredi 25 juillet 2007 18:39
À : Acee Lindem; Adrian Farrel
Cc : OSPF List
Objet : Re: [OSPF] Inter-AS TE

Hi Acess, all,

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

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

     |     |  \   |  ----  |

     |     |   \  | /      |

        :              :

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

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Thu, 26 Jul 2007 10:31:51 -0500

Hi Fabien,

pls see inline.

Hi,

Mach>> Agree, a deferent link type will bring us many benifits. i.e. giving a easy way to identify a inter-AS link, OAM ...

Mach>> Yes, for inter-AS TE link, the AS number attribute is essential, as I pointed out in my previous message, the AS number is needed in the PCE-based path computation senario. 

Mach>> Since there is no OSPF adjancy runing on the inter-AS TE links,  to advertise both directions of the TE link can make sure that the inter-AS TE link is valid for path computation. As Vishwas Manral said, CSPF implementations will do a two way check before using the TE link for path computation.

Best regards,
Mach

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Thu, 26 Jul 2007 18:10:52 +0200

Hi Mach,

Thanks for the fast answer.
I still have some comments:

>Mach>> Yes, for inter-AS TE link, the AS number attribute is essential, as 
> I pointed out in my previous message, the AS number is needed in the PCE-
> based path computation senario.

To be more precise, my question is not to know if the AS number sub TLV is
useful cause I agree that it is. 
But rather is it madatory to encode such sub TLV in each inter domain TE
link.
There are some scenario where it is useful (e.g. PCE based path
computation), maybe it is not in some other scenarios.

For instance RFC3630 states that " The Link Type and Link ID sub-TLVs are
mandatory, i.e., must appear exactly once", and I think the same kind
statement should be done to explicitly indicate if the AS number sub TLV is
mandatory or optional in case of inter domain TE link.

Note that if it is optional it is even more important to have a different
link type.

>Mach>> Since there is no OSPF adjancy runing on the inter-AS TE links,  to
>advertise both directions of the TE link can make sure that the inter-AS TE
>link is valid for path computation. As Vishwas Manral said, CSPF
>implementations will do a two way check before using the TE link for path
>computation.

Ok. But then if the only purpose of having 2 links LSA is to be able to do 2
way connectivity check, why not rather stating that the inter domain TE link
is bidirectional (unlike intra domain link).
That is, this TE link would be advertised only if the advertising routers
has checked the 2-way connectivity.

Thanks
Fabien

-----Message d'origine-----
De : Mach Chen [mailto:[email-masked]] 
Envoyé : jeudi 26 juillet 2007 17:32
À : [email-masked]; 'Acee Lindem'; 'Adrian Farrel'
Cc : 'OSPF List'
Objet : Re: [OSPF] Inter-AS TE

Hi Fabien,

pls see inline.

Hi,

Mach>> Agree, a deferent link type will bring us many benifits. i.e. giving
a easy way to identify a inter-AS link, OAM ...

Mach>> Yes, for inter-AS TE link, the AS number attribute is essential, as I
pointed out in my previous message, the AS number is needed in the PCE-based
path computation senario. 

Mach>> Since there is no OSPF adjancy runing on the inter-AS TE links,  to
advertise both directions of the TE link can make sure that the inter-AS TE
link is valid for path computation. As Vishwas Manral said, CSPF
implementations will do a two way check before using the TE link for path
computation.

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Mon, 30 Jul 2007 16:12:11 +0800

Hi Fabien,
Sorry for delay reply.
pls see inline.
> mandatory or optional in case of inter domain TE link.
Yes, we will make such statement in the next revision.
As to mandatory or optional, although the AS number attribute of an inter-AS
TE links is very useful for many computation scenarios, but only if there is
one scenario that does not need the AS number attribute, the AS number
sub-TLV should not be mandatory, so optional is more reasonable for the AS
number sub-TLV.
> has checked the 2-way connectivity.
A bidirectional inter-AS link is an option. But, IMO, from the aspect of
implementing (especially CSPF),  using 2 link LSAs as current intra-area TE
does is simpler than using a new bidirectional inter-AS LSA. Anyway, there
should be mechanism to advertise the backward directions of an inter-AS
links, the ASBR within local AS will do the "proxy" advertisement. So, no
matter which option is adopted, the objective is to make few changes to the
current mechanisms. We would like to hear suggestion from implementers.

Best regards,
Mach

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 30 Jul 2007 20:14:04 +0100

>> To be more precise, my question is not to know if the AS number
>> sub TLV is useful cause I agree that it is.
>> But rather is it madatory to encode such sub TLV in each inter
>> domain TE link.
>> For instance RFC3630 states that " The Link Type and Link ID
>> sub-TLVs are mandatory, i.e., must appear exactly once", and
>> I think the same kind statement should be done to explicitly
>> indicate if the AS number sub TLV is mandatory or optional
>> in case of inter domain TE link.
>
> As to mandatory or optional, although the AS number attribute of
> an inter-AS TE links is very useful for many computation scenarios,
> but only if there is one scenario that does not need the AS number
> attribute, the AS number sub-TLV should not be mandatory, so
> optional is more reasonable for the AS number sub-TLV.

I think quite the oposite!

If there is one scenario where the information is required then 
advertisement is mandatory. Consider that the advertising router does not 
know to what use the information will be put. Therefore, you cannot allow 
the advertising router to make an arbitrary decision about what information 
to advertise - that would potentially make the advertisement useless.

The only reason that you would make this less than a MUST, would be if you 
find policy reasons why the AS number might be withheld.

>>> Since there is no OSPF adjancy runing on the inter-AS TE
>>> links, to advertise both directions of the TE link can
>>> make sure that the inter-AS TE link is valid for path
>>> computation. As Vishwas Manral said, CSPF implementations
>>> will do a two way check before using the TE link for path
>>> computation.
>>
>> Ok. But then if the only purpose of having 2 links LSA is
>> to be able to do 2 way connectivity check, why not rather
>> stating that the inter domain TE link is bidirectional
>> (unlike intra domain link).
>> That is, this TE link would be advertised only if the
>> advertising routers has checked the 2-way connectivity.
>
> A bidirectional inter-AS link is an option. But, IMO,
> from the aspect of implementing (especially CSPF),  using
> 2 link LSAs as current intra-area TE does is simpler than
> using a new bidirectional inter-AS LSA.

Right. We don;t want to force changes to core code (such as CSPF) for this 
new function.

Adrian