The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

On Mon, 2002-04-15 at 18:25, David Allan wrote:
> Giles:
> 
> Agreed that EXP drop preference is an issue. Looks like we may converge on
> the label only... IMHO some of this should be captured in sect 3.12 of 3031
> when it comes around.

possibly - or 3032?
 
> I thought [y, s=1] hashed the same as [y, s=0] if we simply skipped 's' ;-)

it does.

but not the same as [y, s=0][z, s=1].

> later
> Dave
> 
> > -----Original Message-----
> > From: Giles Heron [mailto:giles@packetexchange.net]
> > Sent: Monday, April 15, 2002 3:20 PM
> > To: Allan, David [CAR:NS00:EXCH]
> > Cc: mpls@UU.NET
> > Subject: RE: response to ITU-T SG13
> > 
> > 
> > On Mon, 2002-04-15 at 17:59, David Allan wrote:
> > > My comment was that this would be true for any 
> > detection/diagnotic tool
> > > discussed. e.g. use of explicit V4 label to permit ICMP 
> > ping to be used for
> > > non-IP LSPs or use GTTP to explore non-IP LSPs or to 
> > measure anything such
> > > as DSCP RTT.
> > 
> > oh, okay.
> > 
> > > That to me is sufficient reason to suggest that in a load 
> > sharing scenario,
> > > the answer should be the same for the combination of label 
> > and exp bits. S
> > > bit and TTL MUST be excluded....
> > 
> > in fact it should probably just be the label (and not the EXP bits) as
> > the EXP bits may be describing different drop precedences within the
> > same queue?
> > 
> > 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]).
> > 
> > Giles
> >  
> > > cheers
> > > Dave
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Giles Heron [mailto:giles@packetexchange.net]
> > > > Sent: Monday, April 15, 2002 2:47 PM
> > > > To: Allan, David [CAR:NS00:EXCH]
> > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu;
> > > > mpls@UU.NET
> > > > Subject: RE: response to ITU-T SG13
> > > > 
> > > > 
> > > > On Mon, 2002-04-15 at 17:38, David Allan wrote:
> > > > > Thanks Giles, 
> > > > > 
> > > > > I understand the scenario you are discussing and the S bit 
> > > > is a legit issue.
> > > > > To re-use your pictures, I was considering when y=OAM 
> > > > alert, not OAM alert
> > > > > under 'y'.
> > > > > 
> > > > > But ultimately I think the problem exists independently of 
> > > > the OAM alert
> > > > > label. It would also be true if any reserved label (e.g. 
> > > > explicit V4 label)
> > > > > was used, and suggests that for stuff to function correctly your
> > > > > implementation should only be looking one label further 
> > > > into the stack and
> > > > > MUST ignore the S bit. The existence of reserved labels 
> > > > means that hashing
> > > > > more than one label deep has problems, and including the S 
> > > > bit has problems.
> > > > > Implementation wise this may not be the case today, but 
> > > > live and learn ;-)
> > > > 
> > > > Yes, this "problem" exists for other traffic, but it only 
> > > > matters in the
> > > > OAM case - where the aim is for the OAM traffic to follow the 
> > > > same path
> > > > as the user traffic.
> > > > 
> > > > If I have Internet traffic from PE A to PE B and this follows a
> > > > different path to a draft-martini circuit from PE A to PE B 
> > > > (i.e. where
> > > > there is an extra label) then I don't care.  All I care 
> > about is that
> > > > all the traffic for a given draft-martini circuit between A and B
> > > > follows the same path.
> > > > 
> > > > Giles
> > > > 
> > > > > This preserves any detection properties for any tools 
> > > > employed regardless of
> > > > > the type used, payload used etc. 
> > > > > 
> > > > > cheers
> > > > > Dave
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Giles Heron [mailto:giles@packetexchange.net]
> > > > > > Sent: Monday, April 15, 2002 2:28 PM
> > > > > > To: Allan, David [CAR:NS00:EXCH]
> > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; 
> > sob@harvard.edu;
> > > > > > mpls@UU.NET
> > > > > > Subject: RE: response to ITU-T SG13
> > > > > > 
> > > > > > 
> > > > > > On Mon, 2002-04-15 at 16:59, David Allan wrote:
> > > > > > > Giles:
> > > > > > > 
> > > > > > > So then why does whether or not the S bit is set matter? 
> > > > > > 
> > > > > > perhaps a picture would help?
> > > > > > 
> > > > > > Say an LSR switches a packet with the following stack:
> > > > > > 
> > > > > > |--------|--------|
> > > > > > | X, S=0 | Y, S=1 |
> > > > > > |--------|--------|
> > > > > > 
> > > > > > It has an L-FIB entry for X that has n equal cost paths.
> > > > > > 
> > > > > > What we would like to be able to do is to hash across the 
> > > > > > entire stack. 
> > > > > > This way a second packet with the following stack:
> > > > > > 
> > > > > > |--------|--------|
> > > > > > | X, S=0 | Z, S=1 |
> > > > > > |--------|--------|
> > > > > > 
> > > > > > can use a different one of the n equal cost paths (depending 
> > > > > > on the hash
> > > > > > function and the values of Y and Z of course).
> > > > > > 
> > > > > > However the problem arises if you have MPLS OAM and the 
> > > > > > following packet
> > > > > > is sent:
> > > > > > 
> > > > > > |--------|--------|--------|
> > > > > > | X, S=0 | Y, S=0 |14, S=1 |
> > > > > > |--------|--------|--------|
> > > > > > 
> > > > > > If the hash includes the S bit then this will most likely 
> > > > be sent on a
> > > > > > different link to the first packet.
> > > > > > 
> > > > > > Likewise if the hash includes *all* labels then this will 
> > > > > > most likely be
> > > > > > sent on a different link.
> > > > > > 
> > > > > > So what you need is to know a-priori the minimal depth of 
> > > > stack for
> > > > > > non-OAM traffic and hash over that number of labels.  But 
> > > > > > this coarsens
> > > > > > the granularity of the load balancing, and also requires 
> > > > > > configuration -
> > > > > > unless you take the most simplistic approach and hash 
> > > > only using the
> > > > > > first label (which barely qualifies as load balancing).
> > > > > > 
> > > > > > > Seem to me that both scenarios need to be covered unless I 
> > > > > > was producing a
> > > > > > > very specialized implementation....
> > > > > > > - the current label is also the bottom label
> > > > > > > - the current label is not the bottom label and the label 
> > > > > > underneath may be
> > > > > > > transport or reserved.
> > > > > > 
> > > > > > not sure what you mean by "current" label.  Do you mean 
> > > > the label you
> > > > > > are switching on?
> > > > > > 
> > > > > > Giles
> > > > > > 
> > > > > > > cheers
> > > > > > > Dave
> > > > > > > 
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net]
> > > > > > > > Sent: Monday, April 15, 2002 11:07 AM
> > > > > > > > To: Allan, David [CAR:NS00:EXCH]
> > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; 
> > > > sob@harvard.edu;
> > > > > > > > mpls@UU.NET
> > > > > > > > Subject: RE: response to ITU-T SG13
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote:
> > > > > > > > > Giles:
> > > > > > > > > 
> > > > > > > > > A clarification...
> > > > > > > > > 
> > > > > > > > > > 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.
> > > > > > > > > 
> > > > > > > > > If I am inverse muxing an LSP at an 
> > intermadiate LSR, is 
> > > > > > > > this not on the
> > > > > > > > > basis of some hashing on the payload for the 
> > current label, 
> > > > > > > > which could be
> > > > > > > > > more labels...I'm not quite getting your example.
> > > > > > > > 
> > > > > > > > effectively yes, you are hashing on the payload for the 
> > > > > > > > current label -
> > > > > > > > given that it includes more labels.  So, for example, an 
> > > > > > LSR switching
> > > > > > > > based on an LDP-assigned label might have a set 
> > of equal cost 
> > > > > > > > next hops
> > > > > > > > in its IGP - across which it could load balance 
> > traffic based 
> > > > > > > > on a hash
> > > > > > > > which includes the draft-martini label inside that LDP 
> > > > > > assigned label
> > > > > > > > (though of course it wouldn't know whether the inner 
> > > > > > label was being
> > > > > > > > used for draft-martini, for MPLS VPN, or for 
> > > > something else...)
> > > > > > > > 
> > > > > > > > Giles
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Dave
> > > > > > > > > 
> > > > > > > > >  
> > > > > > > > -- 
> > > > > > > > 
> > > > =================================================================
> > > > > > > > Giles Heron    Principal Network Architect    
> > > > PacketExchange Ltd.
> > > > > > > > ph: +44 7880 506185              "if you build it 
> > > > they will yawn"
> > > > > > > > 
> > > > =================================================================
> > > > > > > > 
> > > > > > > > 
> > > > > > -- 
> > > > > > 
> > =================================================================
> > > > > > Giles Heron    Principal Network Architect    
> > PacketExchange Ltd.
> > > > > > ph: +44 7880 506185              "if you build it 
> > they will yawn"
> > > > > > 
> > =================================================================
> > > > > > 
> > > > > > 
> > > > -- 
> > > > =================================================================
> > > > Giles Heron    Principal Network Architect    PacketExchange Ltd.
> > > > ph: +44 7880 506185              "if you build it they will yawn"
> > > > =================================================================
> > > > 
> > > > 
> > -- 
> > =================================================================
> > Giles Heron    Principal Network Architect    PacketExchange Ltd.
> > ph: +44 7880 506185              "if you build it they will yawn"
> > =================================================================
> > 
> > 
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================