Re: IGP Extensions - CCAMP Milestones

[dimitri papadimitriou <[e-mail]>]

igor

Igor Bryskin wrote:

> Dimitri,
> 
> See my reply to JP. Also see below.
> 
> ----- Original Message ----- 
> From: "dimitri papadimitriou" <[e-mail]>
> To: "JP Vasseur" <[e-mail]>
> Cc: "Igor Bryskin" <[e-mail]>; <[e-mail]>;
> "Adrian Farrel" <[e-mail]>; "LE ROUX Jean-Louis RD-CORE-LAN"
> <[e-mail]>; <[e-mail]>
> Sent: Sunday, November 20, 2005 2:40 PM
> Subject: Re: IGP Extensions - CCAMP Milestones
> 
> 
> 
>>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
> 
> 
> IB>> Two points here:
> 
> 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.

> b) A TE application can detect a control engine failure only within one
> 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
> (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
> 
> 
>>thanks,
>>- dimitri.
>>
>>JP Vasseur wrote:
>>
>>>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).
>>>
>>>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.
>>>
>>>
>>>
>>>>
>>>>
>>>>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
>>>>>>>>>.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>.
>>>>>>
>>>>>>
>>>>>
>>>
>>>.
>>>
>>
> 
> 
> .
>