Subject: RE: MPLS OAM? (was Re: PHP negotiation)

From: Shahram Davari <[email-masked]>
Date: Fri, 16 Feb 2001 13:40:53 -0800

Hi Giles,

1) As you said, if you know that you are using OAM, and if the stack depth without OAM label is 1, then you probably should not configure your load balancing node to hash on S-bit.

2) If the A-D LSP is using a label stack of depth > 1 (excluding OAM label), then S=0 in both OAM packets and user data packets. And there won't be any problem.

3) I think MPLS has enough capabilities for load balancing using TE methods, so that there probably is no need to do load balancing by hashing methods. 

Yours,
-Shahram

> -----Original Message-----
> From: Giles Heron [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2001 6:42 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Shahram
> Davari; [email-masked]
> Subject: MPLS OAM? (was Re: PHP negotiation)
> 
> 
> [email-masked] wrote:
> > 
> > Hi Indra,
> > 
> > >From a quick analysis I think you are right (Ben and 
> Shahram may wish to
> > confirm this).  However,  this is a fortuitous consequence 
> rather than a
> > planned one, ie a lack of protocol ID in the normal 
> labelled header forces
> > one to create a special bottom-of-stack OAM alert label, 
> and so increase the
> > label stack by + 1, thereby fortuitously negating the effect of PHP.
> > However, PHP must not be allowed on the OAM alert labelled header.
> 
> Hi Neil,
> 
> I think there might be a potential problem lurking in your OAM
> solution...
> 
> Imagine the network shown below (apologies for the quality of my ASCII
> art):
> 
>  LER       LSR       LSR       LER
> |---|     |---|-----|---|     |---|
> | A |-----| B |     | C |-----| D |
> |---|     |---|-----|---|     |---|
> 
> LSPs from A to D need to be load-balanced across the two 
> links from B to
> C.  This may be done using explicit routes, but I would expect it is
> more likely to be done using some form of automated load-balancing. 
> This load-balancing is quite likely to use a hash on the top label in
> the stack.  Because OAM packets will have the stack bit unset to
> indicate the presence of an additional label they will most 
> likely hash
> onto a different link to user packets?  So you can't be sure that the
> OAM packets have taken the same path as your data?  I guess if vendors
> implement load balancing to ignore the stack bit in their hash then
> there won't be a problem, but I'll leave it to the vendors 
> here present
> to comment on that ;-)
> 
> BTW, is there any way you can share your proposal with the 
> list in more
> detail?  I'm having to guess at what you're doing by reading 
> between the
> lines on these posts :(
> 
> Giles
> 
> > 
> > Neil
> > > -----Original Message-----
> > > From: Indra Widjaja [mailto:[email-masked]]
> > > Sent: 14 February 2001 21:28
> > > To: Ben Mack-Crane
> > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]
> > > Subject: Re: PHP negotiation
> > >
> > >
> > > Hi Ben and Neil:
> > >
> > > If I may get back to the technical discussion on why PHP
> > > impacts OAM ...
> > >
> > > I still don't quite understand how PHP would specifically
> > > break the behavior
> > > of your OAM proposal.
> > >
> > > Behavior 1: OAM with PHP
> > > Penultimate node pops the top label and sends an OAM packet
> > > to the ultimate node.
> > > Upon receiving the packet, the ultimate node sees an OAM
> > > alert label and
> > > forwards the packet to the local OAM engine for further 
> processing.
> > >
> > > Behavior 2: OAM without PHP
> > > Penultimate node forwards an OAM packet without popping 
> the top label.
> > > Upon receiving the packet, the ultimate node pops the top label.
> > > Since the next label indicates an OAM alert label, the packet
> > > is forwarded
> > > to the local OAM engine for further processing.
> > >
> > > So it looks like the OAM engine will see no difference in the
> > > two behaviors.
> > > On the other hand, it would be different if the recently
> > > popped label is saved.
> > > Appreciate your clarification.
> > >
> > > indra
> > >
> > >
> > > Ben Mack-Crane wrote:
> > >
> > > > Eric,
> > > >
> > > > I don't know if one could describe the OAM proposal we're
> > > working on as
> > > > a "connection-oriented ITU-like scheme," but I have often
> > > found functional
> > > > modeling of layered networks (defined by ITU) useful in
> > > understanding how
> > > > networks work (or fail to work) in various configurations.
> > > I have even
> > > > found it useful in understanding connectionless networks.
> > > >
> > > > It seems to me that during its evolution MPLS has developed
> > > two personas.
> > > > It has a connectionless persona, exemplified by features
> > > like independent
> > > > unsolicited label distribution and PHP.  It also has
> > > developed a connection-
> > > > oriented persona with features like LSP tunnels and VPN
> > > applications.
> > > >
> > > > For cases in which an LSP must have well-defined endpoints
> > > and there is
> > > > a need to be able to effectively detect MPLS layer defects
> > > (e.g. mis-merging)
> > > > some additional OAM features are needed.  These OAM
> > > features apply to the
> > > > MPLS (shim header) packet layer, not to sub-ip layers (for
> > > which similar
> > > > OAM features are already defined).
> > > >
> > > > Regards,
> > > > Ben Mack-Crane
> > > >
> > > > Eric Rosen wrote:
> > > > >
> > > > > Neil> I  guess  the discussion  above  gave enough
> > > pointers  as  to why  an
> > > > > Neil> unambiguous location of the trail termination
> > > function is important
> > > > >
> > > > > Well, I can say that it  didn't give me a clue.  Repeated
> > > unsupported claims
> > > > > that it is "vital" to follow ITU architectures just
> > > aren't very persuasive.
> > > > >
> > > > > Are  you expecting  to achieve  WG  consensus on  an OAM
> > > proposal?  If  the
> > > > > proposal is  an attempt to warp  an IP-based architecture
> > > into  some kind of
> > > > > connection-oriented ITU-like scheme,  my guess is that
> > > there  is very little
> > > > > chance of achieving consensus.
> > > > >
> > > > > Actually, I  wonder if the  OAM stuff falls  under the
> > > charter of  the CCAMP
> > > > > group rather than the MPLS group.
> > >
> 
> -- 
> ===================================================
> Giles Heron - IP Architect - Level 3 Communications
> phone: +44 20 7864 0719     mobile: +44 7880 506185
> ===================================================
>

---

From: Giles Heron <[email-masked]>
Date: Fri, 16 Feb 2001 21:50:41 +0000

> 1) As you said, if you know that you are using OAM, and if the stack depth without OAM label is 1, then you probably should not configure your load balancing node to hash on S-bit.

Agreed (though this is rather unlikely to be configurable!)

> 2) If the A-D LSP is using a label stack of depth > 1 (excluding OAM label), then S=0 in both OAM packets and user data packets. And there won't be any problem.

Agreed.

> 3) I think MPLS has enough capabilities for load balancing using TE methods, so that there probably is no need to do load balancing by hashing methods.

Probably true for the CR-LDP and RSVP-TE case.  But if you want to
extend the OAM idea to support LDP then I suspect you'll have a problem
with this...

Giles