The MPLS WG Archive

[Dimitri.Papadimitriou@alcatel.be]

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?
- 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 ? ... 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)

(*) 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-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