Subject: RE: response to ITU-T SG13

From: Shahram Davari <[email-masked]>
Date: Mon, 15 Apr 2002 11:42:00 -0700

Eric/Giles,

> -----Original Message-----
> From: Eric Osborne [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 2:39 PM
> To: Shahram Davari
> Cc: 'Giles Heron'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: response to ITU-T SG13
> 
> 
> On Mon, Apr 15, 2002 at 10:41:32AM -0700, Shahram Davari wrote:
> > Hi Giles,
> > 
> > 
> > > which means that intermediate LSRs that use a hash to load 
> > > balance MPLS
> > > traffic over equal cost links/paths have to be careful to 
> > > exclude the S
> > > bit from any hash.
> > 
> > An more logical method is for the hash result
> > to point to the same region of the hash key 
> > when S=0 or S=1 in the bottom-most label.
> 
> Maybe I'm missing something.  If you set S=0 in the bottom-most label
> of the stack, how do you know where the stack ends and the payload
> starts?
>

By Bottom-most label I meant the last label when you parse a fixed number of
labels from the stack. For example if you have 5 labels and you parse only 3 labels
the 3rd label is the one that I was referring to.

-Shahram

> 
> 
> eric
> 
> > > 
> > > I'm not sure that this is the case for all current 
> implementations...
> > 
> > I don't think specific implementations should be a concern 
> for a standard
> > body such as IETF. You could always find a specific 
> implementations that can't
> > support a new function. Any objection regarding backward 
> compatibility should be
> > based on a standard. AFAIK there is no standard for 
> hash-based ECMP MPLS switching. 
> > 
> > > 
> > > In fact this also would seem to imply that you have to hash 
> > > over a fixed
> > > number of labels (to ensure that both the OAM traffic and the user
> > > traffic get the same hash value).  This coarsens the load 
> balancing
> > > granularity somewhat :(
> > 
> > If only 0.1% of a single label range is used, you could 
> still select up to ~1000 different flows using that "single" 
> label. I am not sure of how coarse this is!!!
> > 
> > > 
> > > The alternatives would be either to preclude hashed 
> > > load-balancing or to
> > > require OAM-aware core LSRs.  Neither of these options is 
> acceptable
> > > IMO.
> > > 
> > 
> > Giles, even MPLS-ping that is carried over non-IP carrying LSP uses
> > an extra label (Explicit Null label). So I don't think you can find 
> > any solution that can satisfy the restricted 
> implementations in your boxes. 
> > 
> > Yours,
> > -Shahram
> > 
> > > Giles
> > > 
> > > -- 
> > > =================================================================
> > > Giles Heron    Principal Network Architect    PacketExchange Ltd.
> > > ph: +44 7880 506185              "if you build it they will yawn"
> > > =================================================================
> > > 
>

---

From: Shahram Davari <[email-masked]>
Date: Mon, 15 Apr 2002 11:26:54 -0700

Eric,

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 2:20 PM
> To: Shahram Davari
> Cc: 'Scott Bradner'; [email-masked]
> Shahram> Some vendors may have implemented their MPLS 
> data-plane in hardware
> Shahram> and some  in software.  Why should a  vendor's 
> implementation  be a
> Shahram> concern for a standard body such as IETF?
> 
> Shahram> I don't  think specific implementations  should be a 
> concern  for a
> Shahram> standard  body such  as  IETF.  You could  always  
> find a  specific
> Shahram> implementations that  can't support  a new function. 
>  Any objection
> Shahram> regarding backward compatibility should be based on 
> a standard.
> 
> Are  you  saying  that  the  characteristics  of  existing  
> deployments  and
> implementations should  deliberately be  ignored by the  WG 
> as it  makes its
> decisions?

No. I am saying that a specific implementation by a specific vendor/
operator should not be the basis for any standard argument. If most vendors/operators
implement a function in the same manner, then that is a different story.
But still an alternative solution should exist, otherwise it is best to have 
a solution rather than nothing at all.

> 
> I'd have  to disagree.  If  one is trying  to produce 
> solutions  which solve
> real problems for real people, and which will be adopted by 
> the real market,
> then one is well-advised to take the existing situation into 
> consideration.  
> 
> I am not aware of any IETF  policy or precedent that says to 
> ignore existing
> implementations or deployments.

I am not also aware of any IETF policy that says take to account 
vendor "X"'s implementation.

-Shahram

---

From: [email-masked]
Date: Mon, 15 Apr 2002 20:47:21 +0100

Giles Heron wrote 15 April 2002 19:02
<snipped>
> 
> Not all technologies below IP are CO.  What about the most common link
> layer for IP - Ethernet?
> 
> Sure, Ethernets run over wires (which are inherently CO).  
> But then what
> about 802.11b wireless LANs?  Not much CO going on there AFAIK.
> 
> But yes, as someone who connects IP routers for a living, I am well
> aware that in the wide area IP runs over CO technologies ;-)
NH=> You answered your own question I see, and this is why I stated WAN
connectivity for this reason.....as ethernet, being broadcast in true native
mode, cannot span the wide area.
BTW - Not sure if you are aware but IEEE are looking at OAM for
ethernet....I assume in a p2p mode.....and I understand similar connectivity
verification checks are being considered, though I have not had the time to
look at the details.
> 
> At any rate, your "yes" answer gives me cause for concern.  If you
> require strictly CO trails (i.e. TE) at *all* lower layers in order to
> use OAM at a higher layer then OAM would seem to have quite limited
> utility?
NH=> My answer 'yes' was in respect of the need for *independent trail
management* of a client/server set of lower level co trails.  But of course
you don't have to run, or maybe you can't run, OAM on all of these.  One
obvious example is where you are virtualising link-connectivity at layer N
(which you own say) by leasing a trail at layer N+1 (which you don't
own).....and as I am sure you know this happens all the time between
operators when they want to increase their geographic reach and don't own
all the layers to the duct.

The one thing you should not do however, is ask the OAM functions of 1 layer
network to proxy for such functionality which is missing in either a client
or server layer network.  Not only is there a layer network ownership issue
as in the example above, but the trails won't usually be congruent (ie the
server trail is only a link-connection, ie 1-hop, in the client layer
network trail), and its a layer violation anyway.  No doubt you will recall
we discussed such a problem on the PWE3 list recently in respect of the
Brayley draft, which has just such a violation in asking SDH/Sonet FDI to
proxy for ATM layer failures.

However, if you ran p2p LSPs over mp2p LSPs (which is what rfc2547 VPNs
using a server LDP-based layer is) then in theory you could run OAM on the
top layer LSPs (to check their connectivity) and not use OAM on the lower
layer LSPs.  

regards, Neil

---

From: [email-masked]
Date: Mon, 15 Apr 2002 21:30:17 +0100

Hi Giles.....you wrote 15 April 2002 20:20
><snipped>
> 
> but we still have the problem of needing to know the stack depth
> a-priori (or of figuring out a way to make [Y, S=1] hash to the same
> link as [Y, S=0][OAM, S=1]).
> 
NH=> Well I guess we can thank the orignal MPLS architects for this.  Fault
management of MPLS was clearly never given sufficient consideration at the
outset.....so there is no overhead function which indicates that the payload
is not traffic but OAM (or something else).  If we had such an overhead
function then we would not need to stack labels like this.

When we debated this over a year ago I initially wanted to avoid this label
stacking by reviewing the need for a whole 8 bit TTL.....256 hops is way
overkill IMO.  We could have taken a couple of bits out of this to give some
ability to indicate a 'non-traffic payload'.  However this was deemed
unacceptable......and that's why we are where we are now.  

regards, Neil

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 15 Apr 2002 20:47:21 -0400

>a solution rather than nothing at all.

         Why not? The mantra at the IETF is "working code and rough consensus."
Sounds like we base things on real implementations around here to me.

> > solutions  which solve real problems for real people, and which will be 
> adopted by
> > the real market, then one is well-advised to take the existing 
> situation into
> > consideration.
> >
> > ignore existing implementations or deployments.
>

         See above.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: Shahram Davari <[email-masked]>
Date: Tue, 16 Apr 2002 13:49:45 -0700

-----Original Message-----
From: Thomas D. Nadeau
To: Shahram Davari
Cc: [email-masked]'; 'Scott Bradner'; [email-masked]
Sent: 15/04/02 5:47 PM
Subject: RE: response to ITU-T SG13 

>a solution rather than nothing at all.

         Why not? The mantra at the IETF is "working code and rough
consensus."
Sounds like we base things on real implementations around here to me.

Rough consensus is not = Cisco consensus

         See above.

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 16 Apr 2002 17:03:51 -0400

>Rough consensus is not = Cisco consensus

         Working code and rough consensus often
comes from a variety of fine device vendors. If it happens
to include some that you don't particularly like, that really isn't the
point, is it?

         --Tom

---

From: Shahram Davari <[email-masked]>
Date: Wed, 17 Apr 2002 06:47:29 -0700

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 5:04 PM
> To: Shahram Davari
> Cc: [email-masked]' '; ''Scott Bradner' '; [email-masked] '
> > >But still an alternative solution should exist, otherwise 
> it is best to
> >have

Unfortunately you didn't get my point. My point was that one company's
implementation is not enough for consensus. It has nothing to do with liking
or disliking or being a fine vendor or not. 

-Shahram

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 17 Apr 2002 11:44:57 -0400

>or disliking or being a fine vendor or not.

         If your point was indeed that more than one vendor needs to implement
the OAM that was discussed at the last MPLS WG meeting, I believe that
there are at least 3 vendors doing that and more on the way from what
I understand.   So your assertion that the solution the we have been discussing
is a one vendor solution, then I think that your assertion is flawed.

         --Tom

---

From: Shahram Davari <[email-masked]>
Date: Wed, 17 Apr 2002 08:53:55 -0700

> Sent: Wednesday, April 17, 2002 11:45 AM
> To: Shahram Davari
> > > > >operator should not be the basis for any standard 
> argument. If most
> > > > >vendors/operators
> > > > >implement a function in the same manner, then that is 
> a different
> > > >story.

Nobody was talking about this. I suggest that you read the contents of the emails
before commenting.

-Shahram