The MPLS WG Archive

[neil.2.harrison@bt.com]

John Drake wrote:

> I'm not sure how you justify the second half of this assertion. [NH=> that
> BTW nested LSPs also fit this model.......but this has not been recognised
> yet. ] 
> 
> Clearly the authors of the relevant I-Ds as well as other interested
> parties have recognized the first part of your assertion since the
> GMPLS work began. 
> 
	NH=> This is based on requiring to have independence between layer
networks and that overhead which is relevant only to a given layer network
has fixed/known points of generation/termination.  This is not so much an
issue for GMPLS (ie a philosophy of a common control-plane across L1/2/3)
but more about nested LSPs from a user-plane perspective and, specifically,
the OH fields in the shim header.  Let me give you 3 examples of what I
mean, and all stem from the "server layer trails = client layer links"
relationship between layer networks:

	-	TTL:  A link connection between 2 nodes in layer N is 1 hop
in layer N.  The fact that there may be a further LSP (ie trail), at layer
N-1, serving this link connection and having its own X label swapping links
connections should not be known to layer N.  This relationship can recurse.
One should therefore not try and predict the TTL at Layer N (in terms of
some prior decrement for the single link connection) due to nested (latent)
LSPs (and their hops) below it.  This may become quite important when
considering (future) inter-domain LSPs, eg when a private network running
MPLS want to tunnel its LSPs across one or more intervening operator MPLS
domains.  Prior guessing of TTLs would also be a potential problem when one
considers restoration, ie the server LSP hop count may change, but the
client remains at 1 hop.  In essence, the TTL of LSP N is relevant only to
LSP N and should not make any assumptions about hops in any server LSPs.

	-	Pipe vs Uniform model:  Here I am considering the Exp bits.
Again consider a private network tunnel across one of more operators
networks.  The private network may want to keep its own Exp LSP codings
which may not have any relationship to how the operators use these bits.  So
all the private network may require from the operator(s) is some LSP SLA
that covers some notions of 'effective LSP BW' and LSP survivability.

	-	PHP:  If an LSP is supposed to run across LSR1-2-3-4, but
PHP is done at LSR 3 then this terminates the LSP header at LSR3.  So in
reality the trail does not extend to LSR4.  This may cause some problems
when one wants to associate consistent functional processing (ie defect
handling, restoration between 2 points, client/server adaptation, etc) with
a known trail termination point.

	John, I hope the above is clear as to what my concerns are.  Which,
in summary, can be stated as we really ought to have some rules governing
where trail OH is generated and terminated and those rules ought to be
employed consistently.

	Alex.....I also saw you tagged mail on this too this morning, wrt to
saying that nested LSP has been thought about.  I think you are talking
about the control-plane aspacts (and I agree its has been here) whilst I am
talking about the user-plane aspects here (in terms of where OH
functionality is consistently generated/terminated and processed).

	Enjoyed the debate.....thanks for all comments.

	Neil

> 	
>