Re: IGP Extensions - CCAMP Milestones
"Igor Bryskin" <ibryskin@movaz.com> Mon, 21 November 2005 17:25 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFPl-0001xq-3A for ccamp-archive@megatron.ietf.org; Mon, 21 Nov 2005 12:25:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16854 for <ccamp-archive@ietf.org>; Mon, 21 Nov 2005 12:24:35 -0500 (EST)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFiF-0001cp-9P for ccamp-archive@ietf.org; Mon, 21 Nov 2005 12:44:20 -0500
Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeFKW-0008gc-TX for ccamp-data@psg.com; Mon, 21 Nov 2005 17:19:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0
Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeFKV-0008gO-9j for ccamp@ops.ietf.org; Mon, 21 Nov 2005 17:19:47 +0000
Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id DE51C1722A; Mon, 21 Nov 2005 12:19:11 -0500 (EST)
Message-ID: <001e01c5eebf$c4e65200$7a1810ac@movaz.com>
From: Igor Bryskin <ibryskin@movaz.com>
To: JP Vasseur <jvasseur@cisco.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
References: <D109C8C97C15294495117745780657AE039CD8D2@ftrdmel1.rd.francetelecom.fr> <05d401c5ebb8$f343bde0$d501a8c0@Puppy> <437DFA01.9080804@psg.com> <01ae01c5ed24$891c5c70$6601a8c0@movaz.com> <B2039488-3FA6-4E0A-9AE5-F43BC5E25B41@cisco.com> <00aa01c5eeae$31737ea0$7a1810ac@movaz.com> <8337AD85-1FA6-4F01-9993-7DEFE24ED4FB@cisco.com>
Subject: Re: IGP Extensions - CCAMP Milestones
Date: Mon, 21 Nov 2005 12:19:45 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA16854
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 >>>>>>> . >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> . >>>> >>>> >>>> >>> >>> >> >
- IGP Extensions - CCAMP Milestones Adrian Farrel
- Re: IGP Extensions - CCAMP Milestones dimitri papadimitriou
- Re: IGP Extensions - CCAMP Milestones JP Vasseur
- RE: IGP Extensions - CCAMP Milestones LE ROUX Jean-Louis RD-CORE-LAN
- Re: IGP Extensions - CCAMP Milestones dimitri papadimitriou
- Re: IGP Extensions - CCAMP Milestones JP Vasseur
- Re: IGP Extensions - CCAMP Milestones dimitri papadimitriou
- Re: IGP Extensions - CCAMP Milestones JP Vasseur
- Re: IGP Extensions - CCAMP Milestones Adrian Farrel
- Re: IGP Extensions - CCAMP Milestones Adrian Farrel
- Re: IGP Extensions - CCAMP Milestones dimitri papadimitriou
- Re: IGP Extensions - CCAMP Milestones Igor Bryskin
- Re: IGP Extensions - CCAMP Milestones JP Vasseur
- Re: IGP Extensions - CCAMP Milestones dimitri papadimitriou
- RE: IGP Extensions - CCAMP Milestones LE ROUX Jean-Louis RD-CORE-LAN
- Re: IGP Extensions - CCAMP Milestones Igor Bryskin
- Re: IGP Extensions - CCAMP Milestones Igor Bryskin
- Re: IGP Extensions - CCAMP Milestones JP Vasseur
- Re: IGP Extensions - CCAMP Milestones Igor Bryskin
- Re: IGP Extensions - CCAMP Milestones JP Vasseur
- Re: IGP Extensions - CCAMP Milestones dimitri papadimitriou
- Re: IGP Extensions - CCAMP Milestones Mr Xu
- New WG drafts [Was: IGP Extensions - CCAMP Milest… Adrian Farrel
- Re: IGP Extensions - CCAMP Milestones Igor Bryskin