Subject: Framework Document - Comments

From: Eric Gray <[email-masked]>
Date: Thu, 26 Aug 1999 18:42:05 -0400

Folks,

	Most of the enclosed comments were discussed 
earlier with Nancy Feldman.  We both agreed that they
should be discussed on the list.

1)  In defining 'MPLS Node' and 'LSR', the Framework
    draft doesn't seem to make clear the implications 
    on routing associated with juxtapositioning an
    'MPLS Node' and an 'LSR'.  The difference is that
    an 'LSR' is defined to be an 'MPLS Node' with L3
    forwarding ability.  The implication is that an
    'MPLS Node' should not advertise a route until it 
    can actually deliver packets for that route.  In
    this sense, an MPLS node is more or less required
    to use ordered control (and may need to delay its
    route advertisements).

2)  There are several confusing references to 'layer
    2 forwarding' as equivalent to MPLS.  This is not
    true in those cases where L2 forwarding is based 
    on a separate L2 encapsulation.  Examples of this
    type of confusing text:

Page 6
>    layer 2
> 
>      the protocol layer under layer 3 (which therefore offers
>      the services used by layer 3); Forwarding, when done by the
>      swapping of short fixed length labels, occurs at layer 2
>      regardless of whether the label being examined is an ATM
>      VPI/VCI, a frame relay DLCI, or an MPLS label

Page 24
>    MPLS uses L2 forwarding as a way to provide simple and fast packet
>    forwarding capability. 
> ...
>    The relative performance of L2 and L3 forwarding may differ
>    considerably between nodes. Some nodes may illustrate an order of
>    magnitude difference. Other nodes (for example, nodes with more
>    extensive L3 forwarding hardware) may have identical performance
>    at L2 and L3.

    MPLS labels do not replace L2 encapsulation in any
    of the media for which it is currently defined.  In
    MPLS, a forwarding 'decision' is similar to an L2
    forwarding decision.  However, actual forwarding of
    labeled packets requires use of an L2 other than MPLS.

    As an example, the following from page 23:
>    There is no compelling reason to support a checksum field in the
>    MPLS header. A CRC mechanism at the L2 layer should be sufficient
>    to ensure the integrity of the MPLS header.

    In addition, some devices may actually support L3
    forwarding, L2 forwarding (bridging) AND MPLS label 
    switching.

    The relationship between L3, MPLS and L2 should be
    stated clearly as something akin to:

> MPLS is a 'shim-layer' which is used to provide link-layer services 
> to L3 but which itself may receive link-layer services from L2 over 
> some media (e.g. - ATM, Ethernet).

3)  I'm not sure that the definition of 'traffic
    shaping' implicit in discussion at the bottom of page
    42 and top of page 43 is accurate.  Do you have a
    reference for this definition?  I have the impression
    that there is more to it than simply spacing cells
    for individual AAL frames, but I could be wrong.

4)  Page 47 - partly because it assumes egress
    initiated Explicit Route (adding ingress initiated
    as an after thought) setup - doesn't do justice to
    the current state of explicit route setup protocols
    (both of them); for example, it dismisses 'source
    routing' (which is essentially what an ERO is) but
    lists other limitations with ingress initiated ER.

5)  Page 59 - the last two paragraphs of section 4.10.2
    are not necessarily correct.  For example, it may
    be possible for the upstream part of a broken ER to
    know whether or not it is safe to forward packets
    using L3.  In addition, in the loose explicit route
    case, the last LSR before the missing link may have
    established a redundant path, or may be able to do
    so very quickly.

6)  Finally, I think there is more to be said
    in the security section of this draft - but I would
    prefer to let the actual wording suggestions come
    from people with a great deal more security savvy
    than I even want to have.

    One example is that we need to address proper use
    of the 'per platform' label space.  An LSR should 
    not treat labels it receives on ALL interfaces in
    exactly the same way as it is intended to treat 
    those labels on interfaces in common with the peer 
    with which the labels were originally negotiated.
    Doing so would allow packets received on other 
    interfaces to gain privileges associated with the
    corresponding LSP.

--

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 27 Aug 1999 12:23:07 -0400

Eric,

> > some media (e.g. - ATM, Ethernet).

You may wish to add another sentence: "In addition, MPLS provides L2-like 
switching when that is not provided by the media over which it is used 
(e.g. PPP)."

Cheers,
Andy

________________________________________________________________________
Andrew G. Malis  [email-masked]  phone:978 952-7414  fax:978 392-2074
Lucent Technologies                 1 Robbins Road    Westford, MA 01886

---

From: Eric Rosen <[email-masked]>
Date: Fri, 27 Aug 1999 13:41:54 -0400

Andy> MPLS provides L2-like switching when that is not provided by the media
Andy> over which it is used (e.g. PPP)

Presumably ethernet switching is "L2  switching", but it is nothing like the
switching provided by MPLS.  (Or maybe ethernet switching isn't L2-like.)

What MPLS provides is label switching at layer 3.

I have  to wonder whether any  purpose is really served  by resurrecting the
framework document.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 27 Aug 1999 15:44:13 -0400

Eric,

>What MPLS provides is label switching at layer 3.

I've actually heard many people describe it as "layer 2.5", since to many 
people, layer 3 switching just means real fast routing, typically in 
hardware, but still based on the destination IP address.

Good point about Ethernet - it should be included in the example along with 
PPP.

>I have  to wonder whether any  purpose is really served  by resurrecting the

That's a question best answered by WG consensus.

Cheers,
Andy