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, Please see comments in-lined. Thanks Regards... Zafar > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Tuesday, April 01, 2003 12:34 PM > To: zafar ali > Cc: mpls@UU.NET > Subject: Re: Check MPLS WG Consensus (on nodeid-subobject) > > > 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 ? ... 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? This will strictly be based on a policy enforced between the ASs. > - 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 ? Clearly draft proposes a solution to a practical problem (and I think we agree on that). I am not sure how one can conclude the later part of your statement, from my comments. > ... 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) > Sorry, can you please elaborate more on the implications that you are referring to? > (*) 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") > > 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-prote > > ct > > 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 >
|
|