[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IGP Extensions - CCAMP Milestones
JP,
Could you give me an example of application that uses AS scope opaque LSAs?
Thanks,
Igor
----- Original Message -----
From: "JP Vasseur" <jvasseur@cisco.com>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: <dpapadimitriou@psg.com>; <dimitri.papadimitriou@alcatel.be>; "Adrian
Farrel" <adrian@olddog.co.uk>; "LE ROUX Jean-Louis RD-CORE-LAN"
<jeanlouis.leroux@francetelecom.com>; <ccamp@ops.ietf.org>
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" <jvasseur@cisco.com>
>
> To: "Igor Bryskin" <ibryskin@movaz.com>
>
> Cc: <dpapadimitriou@psg.com>; <dimitri.papadimitriou@alcatel.be>;
> "Adrian
> Farrel" <adrian@olddog.co.uk>; "LE ROUX Jean-Louis RD-CORE-LAN"
> <jeanlouis.leroux@francetelecom.com>; <ccamp@ops.ietf.org>
>
> 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" <dpapadimitriou@psg.com>
>>
>> To: "Adrian Farrel" <adrian@olddog.co.uk>
>>
>> Cc: "LE ROUX Jean-Louis RD-CORE-LAN"
>> <jeanlouis.leroux@francetelecom.com>;
>> "JP Vasseur" <jvasseur@cisco.com>; "Dimitri Papadimitriou"
>> <dimitri.papadimitriou@alcatel.be>; <ccamp@ops.ietf.org>
>>
>> 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"
>>>> <jeanlouis.leroux@francetelecom.com>
>>>> To: "JP Vasseur" <jvasseur@cisco.com>; "Dimitri Papadimitriou"
>>>> <dpapadimitriou@psg.com>; "Dimitri Papadimitriou"
>>>> <dimitri.papadimitriou@alcatel.be>
>>>> Cc: <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
>>>> 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:jvasseur@cisco.com]
>>>>> Envoyé : jeudi 17 novembre 2005 16:58
>>>>> À : Dimitri Papadimitriou; Dimitri Papadimitriou
>>>>> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org; 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
>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> .
>>>>
>>>>
>>>>
>>>
>>>
>>
>