The MPLS WG Archive

[neil.2.harrison@bt.com]

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.