Subject: RE: Concerns regarding the numerous layer violations in base MPLS drafts

From: [email-masked]
Date: Wed, 20 Dec 2000 00:19:11 -0000

I agree...see comments in line

> I am greatly concerned by the numerous layer violations in the current
> base MPLS drafts (MPLS Architecture and MPLS Label Stack Encoding, in
> particular).  Why are these layer violations in these drafts when they
> clearly work against the multiprotocol intent of MPLS?
> 
> Specific layer violation examples:
> 
> <draft-ietf-mpls-arch-07.txt>
> Section 3.23
> ..
>    This provides some level of protection against forwarding loops that
>    may exist due to misconfigurations, or due to failure or slow
>    convergence of the routing algorithm. TTL is sometimes used for other
>    functions as well, such as multicast scoping, and supporting the
>    "traceroute" command. This implies that there are two TTL-related
>    issues that MPLS needs to deal with: (i) TTL as a way to suppress
>    loops; (ii) TTL as a way to accomplish other functions, such as
>    limiting the scope of a packet.
> 
>    When a packet travels along an LSP, it SHOULD emerge with the same
>    TTL value that it would have had if it had traversed the same
>    sequence of routers without having been label switched.  If the
>    packet travels along a hierarchy of LSPs, the total number of LSR-
>    hops traversed SHOULD be reflected in its TTL value when it emerges
>    from the hierarchy of LSPs.
> ..
> 
> The first paragraph offers traceroute as an example of an application
> which requires layer 3 TTL manipulation.  While this is certainly the
> case, traceroute is actually just a hack to get information out of the
> network without specific protocol support.  Rather than suggest that LSRs
> process or otherwise support processing of layer 3 packets in the data
> plane, support for this functionality should be present in the control
> plane protocols (for example, through the use of LDP Path Vector TLVs).
> 
> The second paragraph drives this violation further home.  The implicit
> assumption is that any packets carried across an LSP will have some sort
> of TTL mechanism (if not, why bother suggesting LSRs manipulate it?).
> This is certainly true for IP, but what about circuit emulation services?
> What about LSRs that have no visibility into the data (existing ATM
> switches, for example)?
	NH=> I have stated in several mails now that, from a functional
architecture prespective, a client layer link = a server layer
trail......and this relationship recurses (to the duct).  That is, from a
client layer perspective it is 1 hop, ie TTL should be decremented by 1 in
client LSP header, but in the server trail (ie end-end LSP in server) it is
N hops, and so TTL here should be decremented by N.   Putting all this a
different way...the overhead of a layer N LSP is relevant *only* to that LSP
and no client LSPs or server layer LSPs.....so similar issues exist for the
EXP bits, and this is quite clear if one considers the requirement for
transparency when tunneling a VPN DS/MPLS-EXP regime across several provider
MPLS domains all using their own DS/MPLS-EXP regimes.

> <draft-ietf-mpls-label-encaps-08.txt>
> Section 2.2
> ..
>    conditions under which it is desirable.  For instance, if an
>    intermediate LSR determines that a labeled packet is undeliverable,
>    it may be desirable for that LSR to generate error messages which are
>    specific to the packet's network layer.  The only means the
>    intermediate LSR has for identifying the network layer is inspection
>    of the top label and the network layer header.  So if intermediate
>    nodes are to be able to generate protocol-specific error messages for
>    labeled packets, all labels in the stack must meet the criteria
>    specified above for labels which appear at the bottom of the stack.
> ..
> 
> I am simply at a loss to understand why an LSR should, under ANY
> circumstance, generate protocol-specific messages based on error
> states unrelated to the MPLS domain edge.  Intermediate LSRs MUST
> NOT be concerned with the payload of an LSP.  To do otherwise would
> be a layer violation leading to all manner of specification and
> implementation complexity.
> 
> Sections 3.4 and 3.5 SHOULD be changed to say that any labeled packet
> which is "too big" should be silently discarded.  Again, I have no
> idea why all this IP-specific information is in what is, allegedly,
> intended to be a protocol independent transport mechanism.  Asking
> that intermediate LSRs be capable of full IP router functionality in
> the _data plane_ makes no sense in light of the intent of MPLS.
> 
> 
> I look forward to reading perspectives on why these layer violating,
> protocol-specific components of the base specifications exist.
	NH=> Again I agree.  As I have also stated in several mails one
should not appeal to a client layer network's OAM tools  to handle a server
layer defect.  If there is failure in an MPLS domain, that failure should be
handled by OAM in that domain and within the MPLS fabric *but* an indication
needs passing to the clients supported by the failed LSP.  In particular,
one should not expect MPLS layer defects to be handled by ICMP on at least 3
counts:  
	1	To ask ICMP to handle this would be a functional OAM layer
violation, ie failure is in MPLS layer, but request for failure notification
in IP layer.
	2	Ultimate client layer may not be IP....so ICMP is not even
an option.
	3	If failure is in the middle of a transit MPLS domain
carrying private IP addresses inside LSPs (eg a VPN), then the operators IGP
would not seem able to route the ICMP indication.
	You may like to know that I and a few others have been working on an
MPLS OAM ID which deals with MPLS layer defects and their fault handling,
taking a functional architecture perspective of layered networks.  I hope to
have this out early in the new year....it should have been done sooner but
the day-job got in the way.

---

From: [email-masked]
Date: Wed, 20 Dec 2000 00:19:51 -0000

Juha...that is indeed a great shame, and damages the technical credibility
of the work and the IETF.

neil

> -----Original Message-----
> From:	Juha Heinanen [SMTP:[email-masked]]
> Sent:	Monday, December 18, 2000 1:17 AM
> To:	Ben Black
> Cc:	[email-masked]
> Subject:	Concerns regarding the numerous layer violations in base
> MPLS drafts
> 
> ben,
> 
> i pointed out a long time ago that the encap i-d is full of wrong
> assupmtions and statements regarding what is carried in the mpls
> packets, but i was asked to shut up in order to not to delay its
> publication as an rfc.
> 
> -- juha

---

From: [email-masked]
Date: Wed, 20 Dec 2000 00:19:52 -0000

GMPLS suffers the same fate......so just why should an OTN that is
user-plane transparent, CO and has to carry multiple clients be best served
by a control-plane developed for a CNLS transfer mode?  The arguments 'for'
don't hold on analysis, and the lack of comparative analysis (to get best of
breed) has not be done.  For example, how on earth can anyone justifiably
and honestly say that RSVP as-is and a 32 bit address (ie unacceptably too
small) are the 'right' answers for an OTN?

Observation....we 3 are operators.....maybe that explains our
concerns/views?

neil

> From:	Ben Black [SMTP:[email-masked]]
> Sent:	Monday, December 18, 2000 2:24 AM
> To:	Juha Heinanen
> Cc:	[email-masked]
> Subject:	Re: Concerns regarding the numerous layer violations in base
> MPLS drafts
> 
> I've noticed that response quite a few times.  I wonder if, in this
> case, all the IP bits are in there to maintain a connection to the
> mission of the IETF, since a truly protocol-independent spec would
> fall outside of its domain.
> 
> 
> Ben
> 
> On Mon, Dec 18, 2000 at 03:17:26AM +0200, Juha Heinanen wrote:
> > ben,
> >

---

From: [email-masked]
Date: Wed, 20 Dec 2000 00:46:50 -0000

I agree with all Ben says in here.

neil

> Sent:	Tuesday, December 19, 2000 9:31 PM
> To:	[email-masked]
> Cc:	Kireeti Kompella; [email-masked]
> On Tue, Dec 19, 2000 at 04:06:36PM -0500, Curtis Villamizar wrote:
> > Kireeti,
> > 
> > I am surprised to see you take such a hard stance on this.
> > 
> > There should be no requirement that the midpoints of an LSR do special
> > processing for a particular L3PID.  There should also be no
> > requirement that an LSR be completely ignorant of the L3PID.
> > 
> 
> The issue I am raising is whether the processing of a particular L3PID
> should be in the base specification.  I don't believe it should.  There
> should be an IP-specific draft addressing how L3PID-aware LSRs should
> handle IPv4 (and IPv6) packets. 
> 
> > If the MTU is passed back to the ingress of a TE tunnel, then the
> > ingress can fragment or generate the ICMP for packets with "don't
> > fragment" set.
> > 
> 
> Absolutely.  However, if the MTU can be determined before any packets
> flow across, why add _anything_ to the specification for processing
> packets which need to be fragmented?  The combination of proper
> signalling and silent discard within the MPLS domain provides all that
> is required.
> 
> > If the L3PID is IPv4, it is perfectly legitimate to send TTL expired
> > ICMP if TTL expires.  It is equally legitimate to ignore the L3PID and
> > not generate ICMP, or disable TTL decrement at all but the egress for
> > TE tunnels (where no loop is ever possible).  LSR that don't generate
> > ICMP are simply traceroute unfriendly and the path will pick up again
> > as soon as the TTL is large enough to reach the egress of the LSP.
> > 
> > If the L3PID is not IPv4 (for example MPLS) then an LSR should not try
> > to guess the type of payload.  Providers who want to retain
> > functionality that is only available if the L3PID is known will have
> > to set up TE hierarchical tunnels for IPv4 only and other hierarchical
> > tunnels to carry "anything else".  This would be true of hierarchical
> > tunnels for specific diff-serv CT values so this is no surprise.
> > 
> > The text is therefore fine as is.  Perhaps some minor clarification
> > can be made, but it does not make sense to remove this.
> > 
> 
> Then I propose we add text for ATM, Frame Relay, Circuit Emulation, ...
> 
> 
> Ben

---

From: [email-masked]
Date: Wed, 20 Dec 2000 18:10:19 -0000

Curtis....some small observations:

<snipped>

> This is some detail on the text above where I said "see below".  The
> L3PID is significant for an LSP regardless of stack depth.  The L3PID
> of the top label should not conflict with the lower L3PID, and if so,
> the setup should be rejected.  The L3PID must exactly match the one
> immediately below it unless the outer L3PID is MPLS, in which case any
> inner L3PID is allowed, but the outer label no longer provides the
> payload type.  The midpoint LSR usually do not know anything about the
> lower labels so all L3PID specific tricks are disabled.
	NH=> This seems to work only for a 1:1 client/server LSP nesting
arrangement.  What happens when one wants a lower level server LSP to carry
several client LSPs each having a different L3PID?

	> (KP=>) Note too for IP VPNs and for BGP-free cores, traceroute
will not work
	> (easily) -- intermediate LSRs don't know whom to send the ICMP
error
	> to.  Yes, one may be able to hack around this, but it ain't
pretty.

	This is solved by sending the ICMP forward through the LSP.  The
	egress should be able to look up the destination in the ICMP packet
in
	the correct VPN forwarding table if private address is used.
	NH=> I agree with Kireeti on this.  Why should an IP layer OAM
function be invoked in response to a MPLS layer problem....noting that this
argument can be extended to other defects besides TTL expiry as you are
aware?  If I was a VPN customer using one or more transit MPLS/LSP providers
I would not want to see ICMP pkts for defects sourced in their networks when
they themselves are not being told there is a problem, ie lack of MPLS layer
OAM.  This also ignores the fact that (i) the ICMP pkt may not be routable
(or difficult to route) or (ii) that the LSP client is not IP.  Solutions to
defect handling in MPLS really ought to be specific to the MPLS fabric and
not rely on other layer's OAM functions....otherwise we can get future layer
evolution problems.  We do, however, need a method of conveying forward
derfect indications between layers at the server-> client adaptation point.
This is standard practice in most other technologies and indeed IP relies on
such mechanisms today for fast defect detection eg AIS from SDH->ATM->IP
say.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 20 Dec 2000 10:59:50 -0800 (PST)

Hi Curtis,

> That would only be the case if the L3PID on the outer tunnel (top) was
> set up as MPLS.  If the L3PID was set up as IPv4, then only tunnels
> containing IPv4 in the payload (other tunnels with a L3PID of IPv4)
> should be placed inside.
> 
> I think this has been quite clear, but if not, we should make it
> clear.  The right place might be the hierarchical draft.  See below.

Philosophically, one could define:
a) L3PID applies only when the stack depth is 1.
b) L3PID applies always.

Neither definition is a priori better.  (a) is (I think) more convenient
(for SPs).  However, not being an SP myself, I will let them speak.

Whatever the decision, some text somewhere should capture this.  I agree,
the hierarchical draft is a good place.

> > Note too for IP VPNs and for BGP-free cores, traceroute will not work
> > (easily) -- intermediate LSRs don't know whom to send the ICMP error
> > to.  Yes, one may be able to hack around this, but it ain't pretty.
> 
> egress should be able to look up the destination in the ICMP packet in

True.  This is what I meant by "hack around this".  But it does work.

Kireeti.

---

From: [email-masked]
Date: Thu, 21 Dec 2000 05:43:32 -0000

Eric...see below:

> Neil> With all due respect Eric, I  think your comments as regarding MPLS
> as
> Neil> an extension  to IP  is the root  of many  of the problems  people
> are
> Neil> expressing with MPLS 
> 
> I would say  to the contrary that the folks who  tend to express
> unhappiness
> are just the ones who fail to see that MPLS is simply an extension of IP.
	NH=> I am not unhappy with MPLS and I don't see it just as an
extension of IP.  Indeed, I see it as a possible (indeed the only possible)
way to unify CO/CNLS transfer modes (for application a priori selection)
that may be needed one day to properly solve QoS and reduce unecessary
network complexity and/or ineffectiveness (which arises if one tries to do
everything in either a CO or CNLS mode only).  I am not going to explain
this again here as I have done so before.  

> If you try to think of MPLS as a different, independent layer, then you
> will
> inevitably end  up confusing yourself.   This confusion manifests  itself
> in
> several forms:
	NH=> I don't 'think' of MPLS as a new layer network and I can assure
you I am not confused.  It is a layer network by definition.  If you add
overhead to some payload (from a higher client layer, eg IP or indeed a
higher LSP) at point X and remove it at point Y then that constitutes a
trail in functional architecture (see G.805).  I, and many others,
understand these issues very well......and they are people who are not
confused.  Indeed, the main confusion I see directly stems from 2 facts:
	(a) that functional architecture is not understood/applied by many
people (usually those who only subscribe to there being only one L3
network.....that OSI model has a lot to answer for)
	(b) that MPLS user-plane functionality (ie the overhead applied to a
payload to create a trail entity) is quite a different/disjoint issue from
GMPLS where the (user-plane) trail OH is untouched but the goal is a common
control-plane across all forms of user-plane trail technologies.
	<snip>

> I think this  misunderstanding of MPLS can be found  both in "bellheads"
> and
> in "IP bigots", though it comes out in different ways.
	NH=> I agree sadly. But if we keep talking and are prepared to
listen we will (I hope) reach a better common understanding one day.