The MPLS WG Archive

[neil.2.harrison@bt.com]

Nurit.....Here are my observations on your questions and Tom's
additional remarks.

> On Nov 9, 2004, at 4:35 PM, Nurit Sprecher wrote:
> 
> 	
> > 	2.  	It looks like being companion to the ITU-T OAM 
> mechanism defined
> > for the MPLS.
> 
> 	Which ITU OAM mechanism are you referring to?
NH=> I can only assume you mean Y.1711?  Though Y.1710 sets the
requirements.
> 
> > 	4.  	Is it compliant to the requirements for the MPLS OAM?
> 
> 	Yes, I think so. Many of the same authors worked on both.
NH=> No it is not IMO.....but then this depends what the requirements
are for and who is defining these.

I have seen misinformation presented about Y.1711 in the past, and maybe
this has tainted some folks views.  I don't how many folks have read
this stuff, and even if they have whether they have really grokked many
of the nuances that it covers.  Y.1711 is about the most minimalist
automatic defect detection/handling OAM solution for the co-ps mode.
Further, all defects are defined in terms of entry/exit criteria and
consequent actions, and careful thought has been applied to relating
defects and (un)availability.  There is some other stuff I'll come back
to in a momemnt (as to why Y.1711 has the correct behaviour vs BFD) but
I want to make an important related observation first:

The functional components of networks in general (not just OAM, but
signalling etc) have a best-of-breed solution in each of the 3 networks
modes, and they should therefore be similar irrespective of the
particular technology considered (they have been different in the past
as each technology that comes along thinks it knows best....this leads
to the stovepipe 'technology=service' problem).  The functional
components *cannot* however be identical across all the 3 modes, because
each mode has fundamental and important differences (and its these
differences are the things that are 'good', but in any case they cannot
be ignored).  For example, let's look at some key differences between
GMPLS (co-cs forwarding mode) and MPLS (co-ps forwarding mode):
-	the co-cs mode forces control/management OOB wrt traffic in
GMPLS.....not true in MPLS
-	the co-cs mode will not allow you to break the connectivity
rules of co trails in GMPLS, ie no mp2p is possible even if you try
it.....not true in some forms of MPLS, and PHP also causes a similar
merging behaviour.
-	the co-cs mode means there are no QoS/traffic classes in GMPLS
(this is actually a far more important observation than some may
think).....not true in MPLS
-	the co-cs mode forces a fixed/known hierarchy in the data-plane
of GMPLS, this means one can still get full functional decoupling
between layer networks (important for commercial client/server
functional decoupling between operators, and also important for
scaling/stability).....not true in MPLS, this is a 'digital wrapper'.

So, as we can see there are some pretty fundamental important
differences in the above.  The defect detection/handling requirements
for both the co-cs mode and co-ps mode data-planes are actually quite
similar, but the differences of the modes means their defects are
different.  That is (under an assumption of a defect-free
control-plane):  The only possible defects in the co-cs mode are breaks
and swaps between *exactly alike* trails.  In the co-ps mode we can get
breaks, swaps (between any trails) and various types of
mis-branching/merging.  For comparison, the cl-ps mode can only ever
have breaks.

Why so?  Well each/every pkt in the cl-ps mode carried its own
Connectivity Verification (CV) function (ie SA).  In the co-ps and co-cs
mode we have to add the CV function in the data-plane in some
deterministic way.  This is easy in the co-cs mode as the period is
determined by the frame/multiframe structure, eg check out the J0 byte
(which is like an IP pkt SA function) in an SDH VC4.  In Y.1711 a
periodic CV pkt carries the SA of the LSP.  Worth noting here that we
really need a consistent method of source addressing of LSPs so that on
swaps/mismerges the offending LSP can be easily identified.  I note BFD
is now proposing something similar (not quite the same) wrt to the
discriminator field.  As noted this should be an LSP source address and
it should be the same no matter how the LSP is instantiated.

Now a few other requirements:
-	the OAM must be in the data-plane....esp vital when the
control/management-plane is OOB, like it is in GMPLS
-	the OAM must be activated/deactiviated in concert with whatever
sets-up/tears-down the LSP, else we are going to get operational
problems.  I believe BFD suggests using LSP-Ping for this.  This is
wrong (ie a heavyweight diagnostic OAM tool invoking a lightweight fault
detection tool?!), as it still needs synch'ing with whatever is the real
set-up/tear-down mechanism, eg signalling or management.
-	OAM must be unidirectional.  This is important for several
reasons, 2 keys ones are:
	* the defects must be detected/handled at the LSP sink so the
relevent consequent actions can be taken in the right place, eg suppress
traffic, send FDI to clients, etc
	* in p2mp constructions any server layer failures (ie in
whatever is below the p2mp MPLS layer considered) must result in FDI
being sent down the affected parts of the (client MPLS) tree towards the
sink....where they then take the consequenct actions noted above but
only at the affected sink points.
You can't really do any of this very well with something that has a
bi-directional behaviour like BFD.
> 
> > 	5.  	Is it a reasonable solution?
> 
> 	I think so. 8)
NH=> Well, it's starting to look more like Y.1711......some way to go
yet as noted above.  As noted earlier, the *functional requirements*
here remain the same whatever we call it.  Though is does beg the
question of why re-invent the wheel?

regards, Neil
> 
> 	--Tom
> 
> 
> >
> > Thanks,
> >
> > Nurit,
> > _______________________________________________
> > mpls mailing list
> > mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls