Re: IGP Extensions - CCAMP Milestones

["Igor Bryskin" <ibryskin@movaz.com>]

Dimitri,

See my reply to JP. Also see below.

----- Original Message ----- 
From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
To: "JP Vasseur" <jvasseur@cisco.com>
Cc: "Igor Bryskin" <ibryskin@movaz.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 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;
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

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