The MPLS WG Archive

[Dimitri.Papadimitriou@alcatel.be]

hi jean-philippe,

some additional comments in-line ...

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.

-> yes, but as i said this was not the "justification" of this i-d
   (and this is what i see from the document)  

=> note here (using your argument) that i don't see any reference to 
   {ospf,isis}te when using bypass tunnels in frr i-d so it might be 
   wise to consider what value has to be included if we don't use them 
   (i think that the recommendation made in rfc 3477 - router_id <- 
   router_address would apply here so that we would be using the 
   router_id in any case ?)

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

-> wise to include this in the document (to be considered as a default,
   probably) in addition specific cases might occur for transit traffic
   imagine an intra-as edge-to-edge fa for instance where you will fall
   on the other edge asbr

=> the next point i wanted to mention is following the above reasoning
   it seems that we can fall on cases (here provided as example) where 
   independently on the ASBR_Y capabilities, the ASBR_X will then see 
   its backup will falling on Z (when protected lsp is flowing through 
   X1-Y1-Z1 ?)

   ASBR_X1---------ASBR_Y1------------- ASBR_Z1
      |             |   |                |
       ------ ASBR_Y2---ASBR_Y3 ---------

   here the question is not "does the method has to support everything"
   but do we allow cases where a backup tunnel X1-Y2-Y3-Z1 ? or does 
   this method restricts to cases where the backup tunnel MUST fall w/i
   the neighboring AS? i miss probably something here ... would you
   please clarify; (reviewing frr i-d) i don't see something that would
   preclude this? is this also part of the policy? from what i see in
   the current i-d the "insertion" rules simply states: "A node MAY 
   decide to include its node-id subobject in the RRO object only for 
   the TE LSP whose IPv4 or IPv6 address source address (specified in 
   the SENDER-TEMPLATE object of the RSVP Path message) does not belong 
   to its local area/AS." and further "before forwarding the RRO object
   outside of an AS, the ASBR may filter some/all node-id subobjects 
   pertaining to the downstream nodes in the AS." we don't say anything
   about Z1 here thus ?

   note that the previous sentence says "In addition, any LSR compliant 
   with this draft must systematically include a node-id IPv4 or IPv6 
   subobject in the RRO object for each protected TE LSP (in addition 
   to the sub-objects required by MPLS TE Fast Reroute as defined in 
   [FAST-REROUTE])." which in the context of the paragraph makes it 
   difficult to read. 

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

-> see above (also i think it was and this is why we're
   discussing the solution)
 
> >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

-> see previous e-mail (pointer) 
 
> >(*) 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

-> idem (but want probably to ask the question more succintly
   here, why a new subobject wasn't considered ? or does it
   really makes the proposal less impacting ? but independently
   of the proposed solution i think this item must be worked
   out

thanks,
- dimitri.
 
> 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