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

From: [email-masked]
Date: Fri, 16 Feb 2001 20:59:12 -0000

Giles Heron [mailto:[email-masked]] wrote 14 February 2001 11:42
>
> 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.
NH=> We are only considering explicitly routed pt-pt LSPs, as one would
set-up by RSVP or CR-LDP and not plain LDP LSPs, ie no merging.  So the way
I would look at this diagram is that:
-	there is a single LSP A-D
-	there are 2 server LSPs B-C
So there would be one OAM flow on the (client) LSP from A-D, and seperate
OAM flows on each of the server LSPs going between B-C. Note -
Architecturally load splitting like this is functionally creating 2 lower
level trails that need management.
So if traffic (which includes the OAM pkts from A->D) is 'split' to load
share for some reason on each of the server LSPs B-C, then as far as LSP A-D
is concerned this is still a single LSP and it does not see the 2 server
layer LSPs....just as they don't see (for example) the SDH VC4s they might
be carried on, etc to the duct.
 
> 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 ;-)
NH=> From the soure LSR 'normal' pkts will have a single normal label
header, and OAM pkts will have a normal label header (top) and an OAM
labelled header (bottom)....so yes, normal pkts will have S bit set and OAM
pkts will not (as they arrive at LSR B).
> 
> 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 :(
NH=> Shahram is producing an ID at the moment.  But in the meantime I will
sent what others asked for in Word format by separate mail.  BTW I am out
all next week and unlikely to be looking at mail, so sorry if I can't
respond to any further questions.

---

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

> be carried on, etc to the duct.

I guess this would imply that on any set of parallel links between two
MPLS routers you'd be pushing an extra level of label to handle the
linkset?  I'm not sure that's the most efficient way of doing
load-sharing?

And in any case you'd come back to the same issue.  How does B decide
which packets of a given LSP from A-D need to be placed on the "upper"
link and which on the "lower"?  If OAM packets are routed on a different
physical link than user data packets then the OAM no longer measures the
LSP accurately?

[rest of original message snipped]

Giles

-- 
===================================================
Giles Heron - IP Architect - Level 3 Communications
phone: +44 20 7864 0719     mobile: +44 7880 506185
===================================================