Subject: RE: [mpls] BFD For MPLS LSPs

From: [email-masked]
Date: Wed, 10 Nov 2004 17:20:56 -0000

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
> > [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: SP <[email-masked]>
Date: Wed, 10 Nov 2004 12:35:08 -0500

what routing protocols have what to do with QoS?

I mean distance vector and link state IGP protocols are just how the 
routers discuss cost of paths and update each others routing tables.

The main ones used for cisco are IGRP, and EIGRP...
The QoS is mainly layer 2 to layer 4, with GoS and ToS.

---

From: Erblichs <[email-masked]>
Date: Wed, 10 Nov 2004 14:46:23 -0800

SP,

	OSPFv2, a link state protocol used to have
	support for QOS, but that was never widely
	used.

	One admistrator of a domain may set router
	path costs within that domain based on delay 
	or other metrics.

	If one looks at QOS in a granular way,
	one may set the cost very high with the assumption
	that their is a alternate path with a lower
	summed cost. This would in effectly generate
	a lower loading on the dst paths that are NOT
	transiting this path. Thus, the dst based
	paths would get a higher quality of service.

	However, if you are looking to guarantee a
	service level of service as a load increases
	this won't help.

	Mitchell Erblich
	----------------------

---

From: SP <[email-masked]>
Date: Thu, 11 Nov 2004 22:19:22 -0500

What layer is MPLS?

since MPLS over ip over ethernet...
and since ip over ethernet (layer 3 over layer 2)...

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Fri, 12 Nov 2004 09:47:12 -0500

>and since ip over ethernet (layer 3 over layer 2)...
Older layering models (e.g., the ISO 7498 basic OSI Refernence Model 
approved in 1984) are obsolete for discussing modern stacks. If you 
want ISO/OSI references, I would suggest reading the OSI supplemental 
report on the Internal Organization of the Network Layer. 
Unfortunately, as far as I know, ISO only sells it online.

Alteratively, look at some of the sub-IP temporary area architectural 
discussions in the IETF.

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 12 Nov 2004 12:59:57 -0800 (PST)

> and since ip over ethernet (layer 3 over layer 2)...

Let MPLS be Layer N.

By the above, N > 3.

You can also carry Ethernet over MPLS,

Hence, 2 > N.

Therefore, 2 > 3.  QED.

Hope that helps :-)

Kireeti.
-------

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 13 Nov 2004 14:48:32 -0800

Kireeti,

> You can also carry Ethernet over MPLS,

Just to help more, here are few points from one of my presentations
on (G)MPLS:

(G)MPLS is not a Network Layer on its own, as it does not have routing
and addressing on its own - it uses IP addressing + IP routing (with
extensions)

(G)MPLS is not a Link Layer because MPLS works over various Link Layer
technologies (e.g., SONET, Ethernet, ATM, etc.)

(G)MPLS is not a Layer in the OSIRM (OSI Reference Model) sense as it
does not have a single format for transport of the data from the
layer above (e.g., (G)MPLS uses "shim" on SONET, VCI/VPI on ATM, time
slot on TDM, lambda on OXC, etc...).

Yakov.

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Sat, 13 Nov 2004 18:17:19 -0500

>slot on TDM, lambda on OXC, etc...).

To be excessively pedantic, could (G)MPLS not be either a subnetwork 
access protocol, or perhaps even a control plane for subnetwork 
access, under the OSI Internal Organization of the Network Layer 
definition?

---

From: Spice Sylvia <[email-masked]>
Date: Tue, 16 Nov 2004 15:08:12 +0000 (GMT)

Hi SP,

If you need it I could send you a small stack which
tunnels anything in HTTP.

It is automagically bidirectional :) 
(ofcourse one side has to initiate the connection)

and it also traverses any proxy (including content
filters)

> and since ip over ethernet (layer 3 over layer 2)...

___________________________________________________________ 
Win a castle for NYE with your mates and Yahoo! Messenger 
http://uk.messenger.yahoo.com