Subject: RE: response to ITU-T SG13

From: [email-masked]
Date: Mon, 15 Apr 2002 13:30:21 +0100

Giles Heron wrote 15 April 2002 13:09

> On Mon, 2002-04-15 at 08:31, [email-masked] wrote:
> [snip]
> > 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.
> 
> 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.
> 
NH=>I understand your point Giles, but if you do as you suggest you don't
have a single trail between source and sink any longer but multiple parallel
trails.....each of which I would argue should be managed as a trail in its
own right.  

regards, Neil

---

From: Giles Heron <[email-masked]>
Date: 15 Apr 2002 13:56:36 +0000

> trails.....each of which I would argue should be managed as a trail in its

so you're effectively saying that in order to apply OAM at a higher
layer trail you need strictly CO trails at all lower layers?

Giles

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