Subject: RE: response to ITU-T SG13

From: "David Allan"<[email-masked]>
Date: Mon, 15 Apr 2002 13:59:40 -0400

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.

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

cheers
Dave

> -----Original Message-----
> From: Giles Heron [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 2:47 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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:[email-masked]]
> > > Sent: Monday, April 15, 2002 2:28 PM
> > > To: Allan, David [CAR:NS00:EXCH]
> > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]
> > > 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:[email-masked]]
> > > > > Sent: Monday, April 15, 2002 11:07 AM
> > > > > To: Allan, David [CAR:NS00:EXCH]
> > > > > Cc: [email-masked]; [email-masked]; 
> [email-masked];
> > > > > [email-masked]
> > > > > 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"
> =================================================================
> 
>

---

From: Giles Heron <[email-masked]>
Date: 15 Apr 2002 19:19:48 +0000

> non-IP LSPs or use GTTP to explore non-IP LSPs or to measure anything such

oh, okay.

> 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