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)
jean-philippe, zafar, i've stressed the question raised, below in the following e-mail: http://cell.onecall.net/mhonarc/mpls/current/msg00025.html thanks, - dimitri. Jean Philippe Vasseur wrote: > > 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 -- 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
|
|