Subject: RE: PHP negotiation

From: [email-masked]
Date: Tue, 13 Feb 2001 12:29:09 -0000

Hi Kireeti.....You have missed the points.....let me expand for you below
(sorry its a bit long).

> We've had (much of) this discussion before.
>  The LSP termination point
> is the end of the LSP ... simple :-)
NH=> There are certain actions that a *trail termination point* has to
assume responsiblity for when terminating the characteristic information
that defines a trail entity.  If its not so clear with 'pure' MPLS
user-plane (shim header) then it ought to be very clear with GMPLS
user-plane (eg SDH_VC4 = trail trace, BIP8, etc)....however, let's revisit
the ones I noted below to make the points clear:
<snipped>
> 
> Let's take your points one-by-one:
> 
> > -	defect detection
> Two ways: a) failure of control plane, b) notification from 
> "lower layers".
> Example of (a): loss of Path/Resv message.  Example of (b): 
> Loss of light
> from SONET/SDH layer.  Either way, PHP is irrelevant.
NH=> In case (a) one may not always have congruently routed user and
control-planes.  Further, each of these functions has its own distinct
failure modes which although not relevant to the other directly, can be
relevant indirectly, eg user-plane failures could trigger control-plane
prot-sw action on S-PVCs say.  But note that control-plane failures should
*never* take down permanent/semi-permanent user-plane trails.....which seems
the case with GMPLS/RSVP due to soft-state holding.
In case (b) 1st let me correct a small arch error.  The 'light' is not part
of the SDH layer characteristic information, but a lower layer optical
network trail (eg part of a WDM system say).  If the fibre is cut (ie light
dies) then this is detected at the optical trail termination point.  At the
optical (server) -> SDH regen/mux/VC_X (client) trail termination points
there is a *recursive* server->client adaptation of the failure into their
respective Forward Defect Indication (FDI) signals....and in traditional WAN
technologies, such as SDH, this FDI signal is called AIS (Alarm
Inhibition/Indication Signal).  It key role is to inform client layer layer
networks that there is a lower layer failure and so *not* to create an alarm
storm in those client layer networks (since their trail termination points
could be geographically/organisationally far removed from the original
failure point).  However, there could be other failures of an SDH VC_4 (say)
trail, such as a break in the SDH fabric per se, BIP errors or trace trace
mismatch.  These are only relevant to the particular SDH trail type
considered (ie don't result in loss of light, since this is a lower layer),
and need correct defect handling (ie detection and consequent actions) at
the relevant trail termination point.  So, one is inherently taking
advantage of the fact that the SONET/SDH *user-plane* has already been
specified correctly wrt trail termination points and defect handling.
Now let's consider the user-plane of 'pure' MPLS.  This can have defects
that are neither relevant to IP nor any server layers....they arise due to
the new functionality the shim header introduces (indeed, LSPs create layer
networks....its just an arch fact and should not be regarded as a problem).
Such potential (new) defects include:
-	loss of MPLS layer connectivity (ie within the MPLS fabric, and not
from a server layer below it, eg SDH)....at some LSP level N
-	swapped LSPs....at some LSP level N
-	>=2 mismerged LSPs....at some level N
-	self-mismerged LSP (aka looping).....at some level N
These need defining, in terms of entry/exit criteria and consequent actions
(both for my Ops people so they can diagnose the defects, and to protect my
customer's traffic, eg leaking of VPN traffic say).  The defect detection
and consequent actions *must* be applied at the trail termination
point....so its essential I know where this is....and which leads into the
next item:
> 
> > -	server->client layer adapatation
> 
> If you mean (for example) IP->MPLS and MPLS->IP, this is 
> forwarding plane
> related.  PHP means this gets done one hop earlier.  I don't 
> see an issue
> here, though.
NH=> In order to detect all of the above defects we need some form of
network-unique Trail Termination Source Identifier (TTSI) to be sent from
the LSP source to the LSP sink on some deterministic basis. In the OAM work
we call this a CV (Connectivity Verification) packet flow.  Now suppose we
get one of the above defects occurring at some LSP at level N in a nested
LSP hierarchy.  This would (depending on the defect type) have varying
impact on all the client layer LSPs served by the initially affected LSP.
Let us take the very simplest case of a 'break' in connectivity.  In this
case all LSPs at/above the break (ie those that span the break) will defect
'loss of CV' (dLOCV).  The trail termination points of all these LSPs will
want to raise an alarm to signify the failure.....but to do this would be
disasterous from an operational perspective, since it could cause an alarm
storm in geographically/organisationally disjoint locations. (Note - in this
discussion I am focussing on explicitly routed LSPs which are largely
permanent/semi-permanent, and which one may use for VPNs, an LSP carrier
transit service (sort of VPN) or TE say, and not for LSPs just used to
support BE IP.....of course, this all applies to GMPLS too, but that is
largely OK since the user-plane has been specified earlier).  It is
therefore vital to apply an FDI at the lowest LSP affected by the break so
that all client LSPs see this FDI signal (recursively mapped at each
server->client adapatation function) and supress their own alarm generation.
Further we are propsoing to add a Defect Location and Defect Type fields to
the FDI so that upstream domains can identify the domain of the source of
the orginal defect.
Note:
(i)	In the case of the mismerging defects, where an unexpected TTSI is
observed at a trail termination point, (dTTSI) then a further important
consequent action will be the squelching of affected customer traffic to
avoid any security/censorship/misbilling issues arising for carriers.
(ii)	All above are pre-requisites for carriers to develop
robust/measurable availability (first/foremost) and QoS (only relevant to
available-state) SLAs for some MPLS-based services.
> 
> > -	performance monitoring
> 
> Forwarding plane, so PHP or not has an effect.  This is the 
> one argument
> against PHP that I buy.  And perhaps the OAM argument, 
> although I would
> have to see the OAM spec first.
NH=> Perf monitoring....one has to do this at the appropriate point *and*,
if we are talking about QoS, this is only relevant when the LSP is in the
up-state (so that needs defining 1st).  Kireeti...I'll send you a separate
direct mail on the OAM issue.....but I guess the discussion above gave
enough pointers as to why an unabiguous location of the trail termination
function is important.
> 
> > -	protection switching
> 
> Control plane.  PHP is irrelevant.
NH=> Its not irrelevant.  The control-plane may not always be congruous with
the user-plane, and in any case each 'plane' has its own specific failures
mechanisms.  The only other issue here (and the one I was trying to make in
the initial mail) is that when we are discussing prot-sw we have to be very
clear about the 2 points between which the working and prot-entity exist.
And since user-plane defects can be used as triggers to invoke control-plane
restorations (eg S-PVCs...something I see as very important in GMPLS, and
certanly before SVCs (re OIF UNI stuff), but as not yet properly
considered), then knowing where the trail termination point is (ie so that
we get the defect detection coupling) is important. 
<snipped>
Neil

---

From: Eric Rosen <[email-masked]>
Date: Tue, 13 Feb 2001 09:26:55 -0500

Neil> I  guess  the discussion  above  gave enough  pointers  as  to why  an
Neil> unambiguous location of the trail termination function is important

Well, I can say that it  didn't give me a clue.  Repeated unsupported claims
that it is "vital" to follow ITU architectures just aren't very persuasive.

Are  you expecting  to achieve  WG  consensus on  an OAM  proposal?  If  the
proposal is  an attempt to warp  an IP-based architecture into  some kind of
connection-oriented ITU-like scheme,  my guess is that there  is very little
chance of achieving consensus. 

Actually, I  wonder if the  OAM stuff falls  under the charter of  the CCAMP
group rather than the MPLS group.

---

From: Ben Mack-Crane <[email-masked]>
Date: Wed, 14 Feb 2001 08:35:08 -0600

Eric,

I don't know if one could describe the OAM proposal we're working on as
a "connection-oriented ITU-like scheme," but I have often found functional
modeling of layered networks (defined by ITU) useful in understanding how 
networks work (or fail to work) in various configurations.  I have even 
found it useful in understanding connectionless networks.

It seems to me that during its evolution MPLS has developed two personas.
It has a connectionless persona, exemplified by features like independent
unsolicited label distribution and PHP.  It also has developed a connection-
oriented persona with features like LSP tunnels and VPN applications.

For cases in which an LSP must have well-defined endpoints and there is
a need to be able to effectively detect MPLS layer defects (e.g. mis-merging)
some additional OAM features are needed.  These OAM features apply to the
MPLS (shim header) packet layer, not to sub-ip layers (for which similar
OAM features are already defined).

Regards,
Ben Mack-Crane

---

From: "Indra Widjaja" <[email-masked]>
Date: Wed, 14 Feb 2001 16:28:06 -0500

Hi Ben and Neil:

If I may get back to the technical discussion on why PHP impacts OAM ...

I still don't quite understand how PHP would specifically break the behavior
of your OAM proposal.

Behavior 1: OAM with PHP
Penultimate node pops the top label and sends an OAM packet to the ultimate node.
Upon receiving the packet, the ultimate node sees an OAM alert label and
forwards the packet to the local OAM engine for further processing.

Behavior 2: OAM without PHP
Penultimate node forwards an OAM packet without popping the top label.
Upon receiving the packet, the ultimate node pops the top label.
Since the next label indicates an OAM alert label, the packet is forwarded
to the local OAM engine for further processing.

So it looks like the OAM engine will see no difference in the two behaviors.
On the other hand, it would be different if the recently popped label is saved.
Appreciate your clarification.

indra