Re: IGP Extensions - CCAMP Milestones

["Igor Bryskin" <[e-mail]>]

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" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Adrian
Farrel" <[e-mail]>; "LE ROUX Jean-Louis RD-CORE-LAN"
<[e-mail]>; <[e-mail]>
Sent: Monday, November 21, 2005 12:26 PM
Subject: Re: IGP Extensions - CCAMP Milestones


Hi Igor,

On Nov 21, 2005, at 12:19 PM, Igor Bryskin wrote:

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

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.

> Thanks,
> Igor
>
>
> ----- Original Message -----
> From: "JP Vasseur" <[e-mail]>
> To: "Igor Bryskin" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>;
> "Adrian
> Farrel" <[e-mail]>; "LE ROUX Jean-Louis RD-CORE-LAN"
> <[e-mail]>; <[e-mail]>
> Sent: Monday, November 21, 2005 11:36 AM
> Subject: Re: IGP Extensions - CCAMP Milestones
>
>
> Hi Igor,
>
> On Nov 21, 2005, at 10:13 AM, Igor Bryskin wrote:
>
>
>> Hi JP,
>>
>>
>>
>> See in-line.
>>
>>
>>
>> Cheers,
>>
>> Igor
>>
>>
>>
>> ----- Original Message -----
>>
>> From: "JP Vasseur" <[e-mail]>
>>
>> To: "Igor Bryskin" <[e-mail]>
>>
>> Cc: <[e-mail]>; <[e-mail]>;
>> "Adrian
>> Farrel" <[e-mail]>; "LE ROUX Jean-Louis RD-CORE-LAN"
>> <[e-mail]>; <[e-mail]>
>>
>> Sent: Sunday, November 20, 2005 9:57 AM
>>
>> Subject: Re: IGP Extensions - CCAMP Milestones
>>
>>
>>
>> Hi Igor,
>>
>> On Nov 19, 2005, at 11:16 AM, Igor Bryskin wrote:
>>
>>
>>
>>> 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.
>>>
>>>
>>
>> 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
>>> 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.
>>>
>>>
>>
>> I guess that you mean 60 min (Maxage=60mn, Architectural Constant) -
>> See RFC2328, but this is not the point, see below.
>>
>>
>>
>>> 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.
>>>
>>>
>>
>> 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).
>>
>>
>>
>> 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
>> 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.
>>
>>
>
> There is nothing to fix here. Anyway, see below ...
>
>
>> 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.
>>
>>
>>
>> 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;
>>
>>
>
> 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.
>
>
>> 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?
>>
>
> 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.
>
>
>>
>>
>>
>> Igor
>>
>> Hope this helps.
>>
>> JP.
>>
>>
>>
>>
>>>
>>>
>>>
>>> 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" <[e-mail]>
>>>
>>> To: "Adrian Farrel" <[e-mail]>
>>>
>>> Cc: "LE ROUX Jean-Louis RD-CORE-LAN"
>>> <[e-mail]>;
>>> "JP Vasseur" <[e-mail]>; "Dimitri Papadimitriou"
>>> <[e-mail]>; <[e-mail]>
>>>
>>> Sent: Friday, November 18, 2005 10:57 AM
>>>
>>> Subject: Re: IGP Extensions - CCAMP Milestones
>>>
>>>
>>>
>>>
>>>
>>>
>>>> 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.
>>>>
>>>> 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.
>>>>>
>>>>> Hope this answers the point.
>>>>>
>>>>> Adrian
>>>>> ----- Original Message -----
>>>>> From: "LE ROUX Jean-Louis RD-CORE-LAN"
>>>>> <[e-mail]>
>>>>> To: "JP Vasseur" <[e-mail]>; "Dimitri Papadimitriou"
>>>>> <[e-mail]>; "Dimitri Papadimitriou"
>>>>> <[e-mail]>
>>>>> Cc: <[e-mail]>; <[e-mail]>
>>>>> Sent: Thursday, November 17, 2005 6:47 PM
>>>>> Subject: RE: IGP Extensions - CCAMP Milestones
>>>>>
>>>>>
>>>>> 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:[e-mail]]
>>>>>> Envoyé : jeudi 17 novembre 2005 16:58
>>>>>> À : Dimitri Papadimitriou; Dimitri Papadimitriou
>>>>>> Cc : [e-mail]; [e-mail]; 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
>>>>>>>> .
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>