Subject: RE: IGP Extensions - CCAMP Milestones

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 17 Nov 2005 19:47:49 +0100

Hi Dimitri,

Thanks for the comment.

As just explained by JP, the TE Node Cap TLV carries topology related parameters used as constraints in path computation. The leaking of such info across areas sounds useless as LSR TE visibility is limited to one area anyway... 
But this is, of course, open to discussions. By the way, do you have any application in mind where such leaking would be useful?

Regards,

JL

> -----Message d'origine-----
> De : JP Vasseur [mailto:[email-masked]] 
> Envoyé : jeudi 17 novembre 2005 16:58
> À : Dimitri Papadimitriou; Dimitri Papadimitriou
> Cc : [email-masked]; [email-masked]; LE ROUX 
> Jean-Louis RD-CORE-LAN
> Objet : Re: IGP Extensions - CCAMP Milestones
> 
> Hi dimitri,
> 
> On Nov 16, 2005, at 6:30 PM, dimitri papadimitriou wrote:
> 
> > adrian,
> >
> > could you explain the reasoning for having a TE specific TLV in the 
> > auto-mesh document with area and AS-wide flooding scope 
> while the TE 
> > router cap TLV is restricted to an area flooding scope ?
> > shouldn't be one way or the other i.e. either restrict all TE info 
> > area-local or allow for TE router cap TLV with AS-wide 
> flooding scope 
> > ?
> >
> > note: there is nothing in the TE router cap TLV that would impact 
> > scaling more than the TE auto-mesh TLV does
> >
> 
> I guess that the reason for allowing both intra and inter-area  
> flooding scopes for automesh is obvious (we need to have TE LSP mesh  
> within areas and spanning multiple areas).
> 
> So your question is probably why don't we allow the TE router 
> cap TLV  
> to be flooded across the domain ? As far as I can remember JL 
> already  
> answered this question ... JL, could you forward your email again ?
> 
> In the meantime, I can answer it: the reason is that such TE node  
> capabilities are used for TE LSP computation which cannot take into  
> account nodes that do not reside in the node's area.
> 
> Thanks.
> 
> JP.
> 
> > thanks,
> > - dimitri.
> >
> > Adrian Farrel wrote:
> >
> >
> >> Hi,
> >> We have two immediate milestones to address:
> >> Oct 05  First version WG I-D for Advertising TE Node Capabilities  
> >> in ISIS
> >> and OSPF
> >> Oct 05  First version WG I-D for Automatic discovery of 
> MPLS-TE mesh
> >> membership
> >> There are two personal submissions which address these topics:
> >> draft-vasseur-ccamp-te-node-cap-01.txt
> >> draft-vasseur-ccamp-automesh-02.txt
> >> I propose that we move these into the WG and then kick the tires
> >> thoroughly.
> >> Opinions please.
> >> Thanks,
> >> Adrian
> >> .
> >
>

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Nov 2005 21:40:22 +0100

hi jean-louis

LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi Dimitri,
> 
> Thanks for the comment.
> 
> As just explained by JP, the TE Node Cap TLV carries topology related
> parameters used as constraints in path computation. The leaking of
> such info across areas sounds useless as LSR TE visibility is limited
> to one area anyway... But this is, of course, open to discussions. By
> the way, do you have any application in mind where such leaking would
> be useful?

stitching capability is the major application i see for the time being - 
others will more than probably come when technology specific application 
will progress (VCAT support is a good example here but this is for 
further discussion)

note: i would like also to point out that "capability" advertisement 
that are of the following nature

1. exchanged on a per node basis
2. variation of the information value >>> LS refresh time
3. usage of the information and setting up LSP across these nodes does
    not trigger any LS update

are not scaling impacting more than any other inter-area routing 
information exchanged per current OSPF/IS-IS RFCs

> Regards,
> 
> JL
> 
> 
> 
> 
> 
> 
> 
>> -----Message d'origine----- De : JP Vasseur
>> [mailto:[email-masked]] Envoyé : jeudi 17 novembre 2005 16:58 À
>> : Dimitri Papadimitriou; Dimitri Papadimitriou Cc :
>> [email-masked]; [email-masked]; LE ROUX Jean-Louis
>> RD-CORE-LAN Objet : Re: IGP Extensions - CCAMP Milestones
>> 
>> Hi dimitri,
>> 
>>> could you explain the reasoning for having a TE specific TLV in
>>> the auto-mesh document with area and AS-wide flooding scope
>> 
>> while the TE
>> 
>>> shouldn't be one way or the other i.e. either restrict all TE
>>> info area-local or allow for TE router cap TLV with AS-wide
>> 
>> flooding scope
>> 
>>> ?
>>> 
>> flooding scopes for automesh is obvious (we need to have TE LSP
>> mesh within areas and spanning multiple areas).
>> 
>> So your question is probably why don't we allow the TE router cap
>> TLV to be flooded across the domain ? As far as I can remember JL 
>> already answered this question ... JL, could you forward your email
>> again ?
>> 
>>  capabilities are used for TE LSP computation which cannot take
>> into account nodes that do not reside in the node's area.
>> 
>> Thanks.
>> 
>> JP.
>> 
>> 
>>> thanks, - dimitri.
>>> 
>>> Adrian Farrel wrote:
>>> 
>>> 
>>> 
>>>> Hi, We have two immediate milestones to address: Oct 05  First
>>>> version WG I-D for Advertising TE Node Capabilities in ISIS and
>>>> OSPF Oct 05  First version WG I-D for Automatic discovery of
>> 
>> MPLS-TE mesh
>> 
>>>> membership There are two personal submissions which address
>>>> these topics: draft-vasseur-ccamp-te-node-cap-01.txt 
>>>> draft-vasseur-ccamp-automesh-02.txt I propose that we move
>>>> these into the WG and then kick the tires thoroughly. Opinions
>>>> please. Thanks, Adrian .
>>> 
> 
> 
> .
>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 17 Nov 2005 18:25:11 -0500

On Nov 17, 2005, at 3:50 PM, Adrian Farrel wrote:

> If I understand the question it is...
>
> In draft-ietf-ospf-cap-07.txt introduces the OSPF router  
> information LSA
> and states that this LSA may have type 9, 10 or 11 scope.
>
> In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node  
> Capability
> Descriptor) is added to the OSPF router information LSA. This TLV  
> (when
> generated) MUST be advertised with type 10 scope. JL has given the  
> reason
> why this is limited to type 10. This reason is, of course, open for
> discussion as he says.
>
> In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is  
> added
> to the OSPF router information LSA. It states that the LSA may be
> advertised with type 10 or type 11 scope. JP has given a reason why  
> you
> might want type 11 in addition to type 10. This reason is, of  
> course, open
> for discussion.
>
> An interesting feature is that a router advertising an AS-wide mesh  
> group
> *and* a TE router capability may require that two OSPF router  
> information
> LSAs are advertised by the router.
>
> The language in draft-ietf-ospf-cap-07.txt leans towards a router  
> sending
> *an* OSPF router information LSA. But nowhere does it say that the  
> router
> cannot send more than one and in section 2.5 we find...
>   The originating router MAY advertise
>    multiple RI LSAs as long as the flooding scopes differ.
>

You're 100% correct and this is exactly why we wrote that section in  
draft-ietf-ospf-cap

Thanks.

JP.

> Hope this answers the point.
>
> Adrian
> ----- Original Message -----
> From: "LE ROUX Jean-Louis RD-CORE-LAN"
> <[email-masked]>
> To: "JP Vasseur" <[email-masked]>; "Dimitri Papadimitriou"
> <[email-masked]>; "Dimitri Papadimitriou"
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, November 17, 2005 6:47 PM
> Subject: RE: IGP Extensions - CCAMP Milestones
>
>
> Hi Dimitri,
>
> Thanks for the comment.
>
> such
> info across areas sounds useless as LSR TE visibility is limited to  
> one
> area anyway...
> But this is, of course, open to discussions. By the way, do you  
> have any
> application in mind where such leaking would be useful?
>
> Regards,
>
> JL
>
>
>
>
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Nov 2005 20:50:10 -0000

In draft-ietf-ospf-cap-07.txt introduces the OSPF router information LSA
and states that this LSA may have type 9, 10 or 11 scope.

In draft-vasseur-ccamp-te-node-cap-01.txt a new TLV (TE Node Capability
Descriptor) is added to the OSPF router information LSA. This TLV (when
generated) MUST be advertised with type 10 scope. JL has given the reason
why this is limited to type 10. This reason is, of course, open for
discussion as he says.

In draft-vasseur-ccamp-automesh-02.txt a new TLV (TE-MESH-GROUP) is added
to the OSPF router information LSA. It states that the LSA may be
advertised with type 10 or type 11 scope. JP has given a reason why you
might want type 11 in addition to type 10. This reason is, of course, open
for discussion.

An interesting feature is that a router advertising an AS-wide mesh group
*and* a TE router capability may require that two OSPF router information
LSAs are advertised by the router.

The language in draft-ietf-ospf-cap-07.txt leans towards a router sending
*an* OSPF router information LSA. But nowhere does it say that the router
cannot send more than one and in section 2.5 we find...
  The originating router MAY advertise
   multiple RI LSAs as long as the flooding scopes differ.

Adrian
----- Original Message ----- 

Hi Dimitri,

Thanks for the comment.

As just explained by JP, the TE Node Cap TLV carries topology related
parameters used as constraints in path computation. The leaking of such
info across areas sounds useless as LSR TE visibility is limited to one
area anyway...
But this is, of course, open to discussions. By the way, do you have any
application in mind where such leaking would be useful?

Regards,

JL

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 18 Nov 2005 16:57:53 +0100

adrian

i think JL's reply did partially translate the initial concern

in brief, there are three well identified TE applications that could 
make use of the TE node cap TLVs on both intra and inter-area basis:
- LSP Stitching edge node capability
- Edge nodes connecting/being P2MP TE egresses
- TE auto-mesh

hence, the question on why keeping separated TLVs as part of the router 
capability and not consider these as sub-TLVs of the TE router cap TLV 
this would
1) provide a logical grouping of TE sub-TLVs as part of the same TLV and 
2) leave the flexibility of flooding scope on a per application need -

note: that the path computation specific sub-TLVs could still be 
restricted with their current area-scope

hope this clarifies the issue,

thanks,
- dimitri.

---

From: "Igor Bryskin" <[email-masked]>
Date: Sat, 19 Nov 2005 11:16:01 -0500

Hi everybody,

I'd like to note that although the AS scope flooding is allowed for opaque
LSAs, in my experience it does not work. Imagine that some routing
controller advertises an AS scope LSA and goes out of service quickly after
that. Controllers outside of the area that the dead controller belongs to
have no way of detecting its death and, therefore, will keep using the
advertising for another 90 min before the LSA times out. Note that the
controllers located within the same area do not have such a problem because
they can always verify the validity of the advertising by trying to locate a
sequence of active adjacencies interconnecting each of them with the
advertising controller. If they find at least one such a sequence, the
advertising is valid (otherwise, it would be withdrawn); on the other hand,
if no such sequences exist, than advertising is likely to be stale and hence
could not be trusted. The conclusion is that opaque LSAs should never be
flooded within AS, rather, within a single area, and, if there is a need for
the information to be propagated beyond the area boundaries, ABRs must relay
the advertising into other areas (by originating new area-scope LSAs). Note
also that as far as I remember OSPF itself never uses AS scope advertisings
for its own needs. For example, an ASBR does not distribute external routes
learned by BGP from other ASs using AS scope LSAs, rather, the routes are
advertised within a single area and ABRs relay the advertisings into other
areas.

The bottom line is that the TLVs described in the draft should be of the
area scope (just like TE LSAs), and hence it is not all that important
whether we use new high level TLVs or sub-TLVs of the TE router cap TLV.

Igor

----- Original Message ----- 

From: "dimitri papadimitriou" <[email-masked]>

To: "Adrian Farrel" <[email-masked]>

Cc: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>;
"JP Vasseur" <[email-masked]>; "Dimitri Papadimitriou"
<[email-masked]>; <[email-masked]>

Sent: Friday, November 18, 2005 10:57 AM

Subject: Re: IGP Extensions - CCAMP Milestones

reason
added
group
information
sending
router

---

From: JP Vasseur <[email-masked]>
Date: Sun, 20 Nov 2005 09:57:01 -0500

Hi Igor,

On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote:

> LSAs, in my experience it does not work.

So your experience is different than the one of many people ...  
Opaque LSA have been
used for quite a few years without any problem. See RFC2370 (July 1998)

> Imagine that some routing
> advertising for another 90 min before the LSA times out.

I guess that you mean 60 min (Maxage=60mn, Architectural Constant) -  
See RFC2328, but this is not the point, see below.

> Note that the

This is not correct. External routes are redistributed with LSA Type  
5 which are
flooded across the entire domain except in stub-area (not generated by
the ABR as type 3 as you mention).

Anyway, back to the point, one cannot say of course that "Opaque LSA
Type 11 does not work". There are suitable to some application, this is
all. You can perfectly reply on an opaque LSA Type 11 to learn the
capability of a router which does not reside in the local area and rely
on another mechanism to detect its liveness. There are several such
examples.

Hope this helps.

JP.

>>> course,
> open
>>>>> the
>>>> mesh

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 20 Nov 2005 20:40:37 +0100

hi jp,

indeed, i don't really understand the issue brought up by igor;

in the present case, one should also underline that, the information 
distributed across the OSPF domain using opaque LSAs, is *indirectly* 
used by e.g. TE applications (note: RFC2370 allows for this information 
to be used directly by OSPF but i think we're not discussing this 
alternative)

this means that these e.g. TE applications can in case of control engine 
failure detect this failure and trigger any necessary action in order to 
avoid the behaviour described by igor

thanks,
- dimitri.

JP Vasseur wrote:
> So your experience is different than the one of many people ...  Opaque 
> LSA have been
> This is not correct. External routes are redistributed with LSA Type  5 
> which are
>>>> might want type 11 in addition to type 10. This reason is, of  course,
>>>>
>> open
>>
>>>> for discussion.
>>>>

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 21 Nov 2005 10:13:56 -0500

Hi JP,

See in-line.

Cheers,

Igor

----- Original Message ----- 

From: "JP Vasseur" <[email-masked]>

To: "Igor Bryskin" <[email-masked]>

Cc: <[email-masked]>; <[email-masked]>; "Adrian
Farrel" <[email-masked]>; "LE ROUX Jean-Louis RD-CORE-LAN"
<[email-masked]>; <[email-masked]>

Sent: Sunday, November 20, 2005 9:57 AM

Hi Igor,

IB>> True, that what is written in RFC2328. And my contention here is that
if an ASBR advertises LSAs type 5 and dies after that, than OSPF speakers
outside of the ASBR's area have good likelihood to use stale external routes
for a considerable period of time. There is no remedy to that (OSPF speakers
do not use Keep Alive protocol :=). This, however, could be fixed by
avoiding using of AS scope flooding, and that's exactly the reason why some
OSPF applications that I know of do just that. But this is the discussion
for OSPF WG, I suggest not argue about that. See below.

IB>> Let's stick to your example. Why is it better to flood router
capability LSAs across an AS, rather than flood them within a single area
and have ABRs relay the advertisings into other areas by originating their
own LSAs? Yes, the AS-scope flooding is simpler. But what I am suggesting
has the following advantages:

a)      Advertisings of a crashed LSR could be withdrawn from use by all AS
LSRs immediately after the crash;

b)      Advertisings could be summarized by an ABR providing scalability
improvements;

c)      What is more important that policies could be applied on ABRs wrt to
what information is leaked to external areas. Regretfully, you keep
forgetting about the policy aspects, but in the context of AS-scope flooding
how can you enforce that an LSR capabilities are advertised into some areas,
not advertised into some other areas, and advertised in a modified way into
the third set of areas?

Igor

Hope this helps.

JP.

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 21 Nov 2005 10:21:08 -0500

Dimitri,

See my reply to JP. Also see below.

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: "Igor Bryskin" <[email-masked]>; <[email-masked]>;
"Adrian Farrel" <[email-masked]>; "LE ROUX Jean-Louis RD-CORE-LAN"
<[email-masked]>; <[email-masked]>
Sent: Sunday, November 20, 2005 2:40 PM
Subject: Re: IGP Extensions - CCAMP Milestones

> avoid the behaviour described by igor

IB>> Two points here:

a) all TE LSAs are of the area scope;
b) A TE application can detect a control engine failure only within one
area. It does not help for LSRs located outside of this area because no LSR
(including ABR) is allowed to withdraw somebody else's LSAs - the LSAs could
be withdrawn or modified by the LSR that has originated them.

Igor

course,
the
mesh

---

From: JP Vasseur <[email-masked]>
Date: Mon, 21 Nov 2005 11:36:19 -0500

Hi Igor,

On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote:

> IB>> True, that what is written in RFC2328.

well not just written in the RFC but implemented and deployed in OSPF  
networks for years.

> And my contention here is that

There is nothing to fix here. Anyway, see below ...

> b)      Advertisings could be summarized by an ABR providing  

OSPF provides an efficient way to flood information across the entire  
routing domain: opaque LSA Type 11. If the use of such LSA is useful  
to some applications why not using it ?

You highlight two aspects here
- Liveness of the capability advertising router: just rely on a  
liveness protocol if you need to quickly detect a crash of the router
- Scalability improvement: this is in fact the opposite ... Think of  
the extra work required on the ABR to leak TLV in other areas  
compared to flood a Type 11 LSA. Apparently you do not appreciate the  
architectural change that this would mean on OSPF.

> not advertised into some other areas, and advertised in a modified  

Policy is of the utmost importance in many contexts such as Inter-AS/ 
Providers ... not sure the case of inter-area within a single AS is  
the case. Now, if you want to propose a new mode of operation for  
OSPF, you may want to discuss it with the OSPF WG ... We could  
continue the discussion there ... since it belongs to OSPF.

JP.

>>>>>> info
>>>>> into

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 21 Nov 2005 12:19:45 -0500

JP,

Could you give me an example of application that uses AS scope opaque LSAs?

Thanks,
Igor

----- Original Message ----- 
From: "JP Vasseur" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Adrian
Farrel" <[email-masked]>; "LE ROUX Jean-Louis RD-CORE-LAN"
<[email-masked]>; <[email-masked]>
Sent: Monday, November 21, 2005 11:36 AM
Subject: Re: IGP Extensions - CCAMP Milestones

Hi Igor,

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 21 Nov 2005 12:26:47 -0500

Hi Igor,

> Could you give me an example of application that uses AS scope  

I'll be happy to spend time with you next time we meet to help you  
understand how to use Opaque LSA Type 11, but do not have enough  
bandwidth as of now ... If you need help on the OSPF front, you may  
want to poll the OSPF WG.

JP.

---

From: dimitri papadimitriou <[email-masked]>
Date: Tue, 22 Nov 2005 00:19:44 +0100

igor

> a) all TE LSAs are of the area scope;

you are confusing TE LSAs (opaque type 1, area-scope) applicability with 
the broader context of e.g. TE applications (see initial statement) that 
can make use of RI LSAs for inst.

> area. 

this is not correct, as by definition, application dependent;

thanks,
- dimitri.

> It does not help for LSRs located outside of this area because no LSR
>>>>could not be trusted. The conclusion is that opaque LSAs should  never
> 
> be
> 
>>>>The bottom line is that the TLVs described in the draft should be  of
> 
> the
> 
>>>>whether we use new high level TLVs or sub-TLVs of the TE router cap
> 
> TLV.
> 
>>>>
>>>>
>>>>Igor
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>hence, the question on why keeping separated TLVs as part of the
> 
> router
> 
>>>>>capability and not consider these as sub-TLVs of the TE router cap
> 
> TLV
> 
>>>>>this would
>>>>>2) leave the flexibility of flooding scope on a per application
> 
>  need -
> 
>>>>>>As just explained by JP, the TE Node Cap TLV carries topology
> 
> related
>

---

From: Mr Xu <[email-masked]>
Date: Tue, 22 Nov 2005 17:01:31 +0800

I think distributing opaque LSAs for TE router cap across OSPF domain is not a good idea, because this information is concrete and can not aggregated, it will cause too much flooding in an AS. 

***************************************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
***************************************************************************************

---

From: "Igor Bryskin" <[email-masked]>
Date: Tue, 22 Nov 2005 11:14:52 -0500

JP,

Thanks for the suggestion. I did some research on OSPF. Here are my
conclusions:

1. LSAs type  5 (AS-external-LSAs) are the only LSAs that are flooded across
AS (so I was wrong saying that there are no precedents of AS-scope
flooding);
2. However, LSAs type 5 are never used alone, rather, they are used in
conjunction with LSAs type 4 (ASBR-summary-LSAs), which advertise location
of ASBRs from area to area and have area scope. LSAs type 4 serve two
purposes:
a) they provide the cost of paths from advertising ABRs to ASBRs;
b) they help validate LSAs type 5: when an ASBR crashes, ABRs co-located
with the ASBR within the same area withdraw the LSAs type 4 and, thus,
invalidate associated LSAs type 5.

The conclusion is that if one uses AS scope LSAs one must rely on some
additional mechanism (internal or external) to validate the LSAs ( which is
BTW not necessary if one uses the area scope advertising). Thus, if AS scope
node capabilities LSAs are used for advertising PCE capabilities one should
use something like KEEP ALIVE PCC-PCE protocol, while if they advertise some
other capabilities (like mesh membership) one should use some other (TBD for
the case of mesh membership) mechanism. At very least, this should be
spelled out in the draft.

Igor

----- Original Message ----- 
From: "JP Vasseur" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Adrian
Farrel" <[email-masked]>; "LE ROUX Jean-Louis RD-CORE-LAN"
<[email-masked]>; <[email-masked]>
Sent: Monday, November 21, 2005 12:26 PM
Subject: Re: IGP Extensions - CCAMP Milestones

Hi Igor,

JP.