[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IGP Extensions - CCAMP Milestones
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. 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. 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.
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
> >>>>.
> >>>
> >
> >
> >
> >
> > .
> >
>