Subject: RE: response to ITU-T SG13

From: [email-masked]
Date: Mon, 15 Apr 2002 09:31:06 +0100

Kireeti, 
Thanks for raising this.  I too had some concerns about one of the comments
you have picked-up on.....please see in-line below.

<snipped> 
> > A further concern is the impact on the MPLS forwarding 
> plane as currently
> > defined.  In certain points in a MPLS network, based on an 
> incoming label,
> > the label is removed and the packet is forwarded with no 
> further inspection
> > of subsequent headers (be it another MPLS label or some 
> other header).
> > Y.1711 seems to imply that the above behavior would not 
> satisfy Y.1711.
> > Specifically, there are some cases where Y.1711 would 
> expect a network
> > element to intercept an OAM packet. This raises issues of backward
> > compatibility with existing MPLS systems and ASICs.
> 
> A deeper question is the implication of different forwarding decisions
> for OAM and non-OAM packets.  In particular, if OAM packets are
> treated differently, how valuable is feedback from those forwarding
> decisions on the forwarding of regular packets?  And isn't the whole
> point just that -- to know what "regular forwarding" is doing?

NH=> Quick back-track to explain rationale of what is in Y.1711:
-	main focus is distributed, automatic and as-simple-as-possible
defect detection/handling
-	ad hoc diagnostics tools come later......and IMO these are
functionally distinct from the above and also require a conscious decision
to invoke, eg a trail-tracing function would fit this class.

To that end only 1 OAM pkt is required whilst in the up-state....the CV pkt
(this is functionally just a 'hello').  And there are 2 pkts that 'come-on'
when a defect is detected.....FDI/BDI which are intended to flow
forwards/backwards to given indications to client layer(s) and LSP head-ends
respectively.  This is all pretty standard/well-known stuff that operators
need for fault handling.

A key behavioural tenet of the defect detection/handling OAM CV pkt, is that
it must be treated as normal traffic and is therefore only ever relevant to
the LSP source/sink points.....it is completely transparent to intermediate
LSRs.  This is nothing unusual, but normal/required behaviour in layered
networks.  And each LSP is independent in this respect, ie 1 or more LSPs
can form a client=>server relationship with a lower level LSP, thus each LSP
has its own independent CV flow.

This is achieved by adding a (lower) extra labelled header to the normal
traffic on an LSP when a CV pkt is sent.  The key differences (from normal
traffic) are:
-	S bit is now only set on OAM alert labelled header
-	OAM alert labelled header carries globally unique label (14 is
suggested) to identify the payload as an OAM pkt.....this is what was
discussed on the list over 12 months ago now, and seemed the only
non-contentious solution to the problem of not having a PID field in the
MPLS header.

So, in summary:
-	the CV pkt is only visible to LSP source/sink points
-	it is treated as 'normal traffic' by intermediate LSRs
-	each LSP is independent of other LSPs
-	since there is no PID in the MPLS header the only way to identify
OAM pkts is via a globally unique/reserved label.

Hope that clarifies.

regards, Neil

---

From: Giles Heron <[email-masked]>
Date: 15 Apr 2002 12:08:55 +0000

On Mon, 2002-04-15 at 08:31, [email-masked] wrote:
[snip]
> non-contentious solution to the problem of not having a PID field in the

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.

I'm not sure that this is the case for all current implementations...

In fact this also would seem to imply that you have to hash over a fixed
number of labels (to ensure that both the OAM traffic and the user
traffic get the same hash value).  This coarsens the load balancing
granularity somewhat :(

The alternatives would be either to preclude hashed load-balancing or to
require OAM-aware core LSRs.  Neither of these options is acceptable
IMO.

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================