The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Check MPLS WG Consensus (on nodeid-subobject)
Hi Dimitri, At 19:34 01/04/2003 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >hi, > >zafar ali wrote: > > > several points here, first i'd like to know how this > > > relates to the current polling of inter-area req's to > > > worked out in the scope of the tewg ? then i thought > > > that inter-area/inter-as solution development were > > > within the scope of the ccamp wg (just to be sure that > > > we also keep some consistence on the work is organised > > > within the sub-ip area) > > > > > > Hi Dimitri, > > > > I would just like to point out that the ID is applicable to an single > > area TE case as well. This is for the cases where, either a box may like > > to avoid peeking into IGP database to find the Merge Point address from > > the interface addresses, or IGP is not used (a non-practical case). > >well what does it mean that you will remove all the content >related to inter-area/inter-as and keep only the two cases >mentioned here above ? ... ... Zafar just wanted to stress the fact that the applicability of the draft was not restricted to multi-area and inter-AS TE, that's it. >page 4/5 of this i-d explicitly >mentioned why this solution would make sense in inter-area >cases and for inter-as, i'd like to know how far we can go >in "advertizing" the ospf router-id between as's using rsvp? not sure to see what you mean by "how far" ... I guess you're referring to some need for hiding the topology of ASx to ASy. If that's the case, in order to use FRR Bypass with NNHOP backup tunnel to protect against an ASBR node failure, this just requires to give the visibility of every ASBR Next hop. >- it also explains why we don't need it in single area case >i am not sure "avoid a lookup" would justify this - > > > In addition, as the contents/ extension in the drafts are so minor, the > > WG discussions at the IETF meeting went along the line of moving forward > > with this as a more generic solution (which is not a 100% tied up with > > the Inter-AS/ Inter-area discussions). > >i am not sure we're on the same line here, do we propose >a solution to a problem, or do we define a "minor object" >and then try to see its applications ? ... Do you think the problem statement was not clear enough ? >in fact you >have to spell it out in another way this draft raises a >major issue (in section 5. you may not be an MP so might >be wise to list the implications) I do not see your point here >(*) it is like a newobject in fact not only a flag since >we've to define the processing from the "worst case" view >point when none information was previously available (this >is what you referred as "filtration cases") idem JP. >thanks, >- dimitri. > > Thanks > > > > Regards... Zafar > > > > > now independently of the work organisation, this i-d > > > is valuable when backup tunnels are used and i think > > > the following i-d "complements" the proposed solution > > > using detour lsp's for this real problem being "abr > > > node protection and as border node protection": > > > > > http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-protect > > ion-00.txt > > > > thanks, > > - dimitri. > > > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > > > I agree for support of this draft > > > > > > JL > > > > > > >In San Francisco the workgroup showed support for making > > > > Definition of an RRO node-id subobject > > > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > > > > > >an MPLS WG Document. This message is to solicit any further comments > > > > > > >prior to making a final determination. > > > > > > > >Please reply by 4/7 24:00 GMT. > > > > > > > >...George > > > > > > > >===================================================================== > > > >= > > > > > > >George Swallow Cisco Systems (978) > > > 936-1398 > > > > 250 Apollo Drive > > > > Chelmsford, Ma 01824 > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html >E-mail : dpapadimitriou@psg.com >Public : http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : +32 3 240-8491
|
|