Subject: Framework last call issues

From: [email-masked]
Date: Wed, 1 Sep 1999 14:31:44 -0400

Thanks to all who commented on the Framework draft.
Following is the current list of outstanding issues, as
well as the suggestion revisions.
Please let me know if I'm missing anything,
or any other comments you may have.

Nancy
-----------------------------------------------------------------------------------------------------------------

>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).

The difference between an MPLS node and an LSR are
defined in the glossary.
Text will be added that says that a node that is
not capable of L3 forwarding can either blackhole,
OR it may choose to delay route advertisements
until a downstream LSP has been created, thereby
eliminating the need to blackhole traffic.

>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.

References to 'L2 forwarding' will be
changed to 'L2 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).

This sentence has been added to the intro.

>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.

I do not have a reference for this.  If anyone can supply
one, I would appreciate it.

>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.

This section has been reworked, to eliminate the egress-only
explicit routing.

>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.

Will add exception case of loose source routing.

>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.

As one who is not a security expert, I have left the
security section as is.  If anyone has suggestions,
please put forward on the list.

>7) VP Merge interoperability

Text will be added describing other VP merge interoperability
issues, as suggested by Jeremy.

>8)  Section 4.1.4 on LDP Reliability seems too strong.  It
>    is true that it is important for at least one LDP
>    developed by the MPLS WG to ensure reliable delivery
>    of label information, but need it be a requirement for
>    all such LDPs?

I have removed the word "any", resulting in:
"any LDP developed by the MPLS WG to ensure reliable delivery"
replaced with
"an LDP developed..."

This softens this section a bit.

>9)  Section 4.2 and in particular section 4.2.1 describes
>    the requirements of VC merge.  It is suggested that the
>    entire AAL5 frame must always be received before any
>    cells can be forwarded.  While this is generally true,
>    there may be optimizations where the first frame can
>    start to be forwarded and only the second (and subsequent)
>    one needs to be buffered.

I have added the word "generally" to the sentence describing
the need to wait before forwarding.