The MPLS WG Archive

["David Allan"<dallan@nortelnetworks.com>]

Title: RE: response to ITU-T SG13

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: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"
> =================================================================
>
>