Subject: RE: Check MPLS WG Consensus (on nodeid-subobject)

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Tue, 1 Apr 2003 09:47:07 +0200

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

---

From: [email-masked]
Date: Tue, 01 Apr 2003 12:24:06 +0200

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)

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-protection-00.txt

thanks,
- dimitri.
 
> LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
> 

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: "zafar ali" <[email-masked]>
Date: Tue, 1 Apr 2003 10:11:41 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> Sent: Tuesday, April 01, 2003 5:24 AM
> To: [email-masked]
> Subject: Re: Check MPLS WG Consensus (on nodeid-subobject)
> 
> 

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

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

Thanks

Regards... Zafar 

> node protection and as border node protection":
http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-protect
ion-00.txt

thanks,
- dimitri.

---

From: "zafar ali" <[email-masked]>
Date: Tue, 1 Apr 2003 13:49:36 -0500

Hi Dimitri, 

Please see comments in-lined. 

Thanks
 
Regards... Zafar

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2003 12:34 PM
> To: zafar ali
> Cc: [email-masked]
> hi,
> zafar ali wrote:
> 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,
> > 
> > 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
> > 
> >===================================================================
> > > >==
> > > >=
> > >

---

From: [email-masked]
Date: Tue, 01 Apr 2003 19:34:22 +0200

hi,

and then try to see its applications ? ... in fact you 

thanks,
- dimitri.

---

From: [email-masked]
Date: Wed, 02 Apr 2003 01:17:05 +0200

hi 

see in-line

> your statement, from my comments.

that's a detail but when you mention "i can also apply it
another contexts" it looks like seeking for app's, turning
this in the other way around makes more sense and from this
perspective we discuss the solution to this practical problem

> Sorry, can you please elaborate more on the implications that you are

i've listed here what i have to support to become an MP 
(using the present proposal):

1) "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]).
   
   => the MUST here ? i think it still works even if you 
      don't set it even when you support it as long as
      one of the lsr's (not within the same area/as) sets 
      this value ? thus why do you *mandate* this kind of 
      "discovery process" ... on the other hand taking the
      policy enforcment mentioned here above it means that
      even if you'll filter it out you have to include the
      flag ?

  further "To remain compatible with the nodes that do not support the 
  RRO IPv4 or IPv6 node-id subobjects, a node can safely ignore these 
  objects. The implication of this limitation will be that these nodes 
  could not be MP in a network with inter-area or inter-AS traffic 
  engineering." 

   => i can safely ignore the object, even if you say could 
      i don't have such limitation in the following case 
      what happens if i push an unnumbered i/f (Type 4) that
      includes the the Router ID which is recommended to be 
      set to the Router Address (see RFC 3477) is there right ? 
      now how do i combine now the to be "standardized" method 
      you propose here? do i have to push it twice - and this 
      to become compliant ? - i would suggest to refine the 
      scope 

(**) Router Address being a stable IP address of the advertising 
router that is always reachable if there is any connectivity to it.

> > is what you referred as "filtration cases")

yes, i think that we have defined here a new subobject being
the "half" of the Type 4 subobject available today (keeping
only the node_id part); and further work might consider this 
way of doing - being also my init conclusion on this discussion
 
thanks,
- dimitri.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Tue, 01 Apr 2003 19:25:54 -0500

Hi Dimitri,

At 19:34 01/04/2003 +0200, [email-masked] wrote:
>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

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.

>and then try to see its applications ? ...

Do you think the problem statement was not clear enough ?

>in fact you

I do not see your point here

>is what you referred as "filtration cases")

idem

JP.

---

From: [email-masked]
Date: Wed, 02 Apr 2003 11:31:00 +0200

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.

---

From: [email-masked]
Date: Wed, 02 Apr 2003 21:19:16 +0200

hi jean-philippe,

some additional comments in-line ...

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

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

> 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)
 
> I do not see your point here

-> see previous e-mail (pointer) 
 
> >is what you referred as "filtration cases")

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

---

From: "Xiaoning He" <[email-masked]>
Date: Wed, 2 Apr 2003 11:48:07 -0800

Hi all

I just start to look at MPLS and I have a silly question. 

What's the purpose to use MPLS over Ethernet? I read some article about
to use MPLS to support QoS and Failure-recovery in the Ethernet.
However, how to do that is very vague in those documents.

Can anyone give me some comments about how to use MPLS over Ethernet to
achieve such things or give me some pointers to the draft, RFC ...

Thanks in advance

-----------------------------
 
Xiaoning He, Ph.D
Research Engineer
 
NTT-DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
 
Email: [email-masked]
Phone: +1 (408) 451-4737
Fax:   +1 (408) 573-1090