On Nov 17, 2005, at 3:50 PM, Adrian Farrel wrote:
If I understand the question it is...In draft-ietf-ospf-cap-07.txt introduces the OSPF router information LSAand 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 reasonwhy 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 addedto the OSPF router information LSA. It states that the LSA may beadvertised 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, openfor 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 informationLSAs 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 routercannot 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.
You're 100% correct and this is exactly why we wrote that section in draft-ietf-ospf-cap
Thanks. JP.
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 relatedparameters used as constraints in path computation. The leaking of such info across areas sounds useless as LSR TE visibility is limited to onearea anyway...But this is, of course, open to discussions. By the way, do you have anyapplication 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 scopewhile the TErouter 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-wideflooding scope? note: there is nothing in the TE router cap TLV that would impact scaling more than the TE auto-mesh TLV doesI 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 ofMPLS-TE meshmembership 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 .