Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard

From: Jonathan Sadler <[email-masked]>
Date: Sun, 23 Feb 2003 22:55:16 -0600

Please consider the following comments on these drafts:
    draft-ietf-ccamp-gmpls-routing-05.txt
    draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
Many of the comments are based on implementation experience.  These comments are
marked with a (*).

Jonathan Sadler

==========

1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the operations for
Packet Switch Capable (PSC) are defined.  Reference is made to Minimum LSP bandwidth
for SDH encoding.  None of the examples in section 5 of
draft-ietf-ccamp-gmpls-routing-05.txt show how this field should filled.

2. The mechanism for showing relationships between server and client layers is not
generalized*.  Specifically:
  - Relationships between SONET/SDH layers (ISC type: TDM) are
    implicitly stated based on the Min and Max LSP bandwidth
    advertised*.  To quote draft-ietf-ccamp-gmpls-routing-05.txt:

     "On an interface having Standard SDH multiplexing, an LSP
      at priority p could reserve any bandwidth allowed by the
      branch of the SDH hierarchy, with the leaf and the root
      of the branch being defined by the Minimum LSP Bandwidth
      and the Maximum LSP Bandwidth at priority p."

    This requires node doing the route calculation to understand
    the G.707 multiplexing hierarchy.  Since LSP routing is source
    routed, it could be the node doing the route calculation
    doesn't understand G.707.

    Furthermore, the G.707 multiplexing hierarchy is not a simple
    tree.  For example VC-11 and VC-12 can be supported over VC-3
    as well as over VC-4.  Consequently, the definition provided
    does not allow a system to explicitly state which "branch" of
    the G.707 hierarchy should be followed.

  - Relationships between PSC-n (for IP switching) and SONET/SDH are
    explicitly specified on the encoding type specified in the PSC-n
    announcement*.  However, SONET/SDH is not a single layer.  It
    must be possible to identify if the PSC-n layer can be carried
    by a VC-11 trail, a VC-12 trail, a VC-3 trail, a VC-4 trail,
    or a VC-4-nc trail.

    Section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt tries
    to deal with this in the following paragraph:

     "On a PSC interface that supports Standard SDH encoding, an
      LSP at priority p could reserve any bandwidth allowed by
      the branch of the SDH hierarchy, with the leaf and the root
      of the branch being defined by the Minimum LSP Bandwidth
      and the Maximum LSP Bandwidth at priority p."

    The problem is this contradicts the following paragraph:

     "The Maximum LSP Bandwidth takes the place of the Maximum
      Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum
      Bandwidth is a single fixed value (usually simply the link
      capacity), Maximum LSP Bandwidth is carried per priority,
      and may vary as LSPs are set up and torn down."
    Specifically, how does a completely available OC-48 interface
    with VC-11 over VC-3, VC-3, and VC-4 get encoded?  Based on
    the first paragraph, the encoding would be MinLSPBW=1.5M, and
    MaxLSPBW[p]=155M.  Ignoring the issue that VC-11 over VC-4
    ends up being shown as supported, the second paragraph states
    that the MaxLSPBW[p] should be 2.5G.

    Knowing the OC-48 is completely available is useful information,
    as multiple VC-4s could be used in an LCAS group to support
    connections that need data rates over 155M*.

 - The mechanism does not support describing common muli-layer
   relationships such as IP over DS1 over VC-11 or IP over DS3
   over VC-3*.

 - Sometimes layer relationships are described in an "inverted"
   manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt
   states:
     "STM-16 POS Interface on a LSR

          Interface Switching Capability Descriptor:
             Interface Switching Capability = PSC-1
             Encoding = SDH
             Max LSP Bandwidth[p] = 2.5 Gbps, for all p"

   Where PSC-1 is the client of an SDH (sic) server.

   Section 5.5 states:
      "Interface of an opaque OXC (SDH framed) with support for
       one lambda per port/interface"

      "   Interface Switching Capability Descriptor:
             Interface Switching Capability = LSC
             Encoding = SDH"

   In this case, SDH is a client of a wavelength server (LSC).
   However, unlike in section 5.1, the layer relationship is
   inverted.

3. Layer specific attributes are not supported*.  Specifically:
 - It is not possible to have a link with different costs at
   different layers (ex. VC-11, VC-4, VC4-4c).  The link cost
   is a tool used by network designers to bias traffic toward or
   away from specific links.

   Since different hardware platforms are optimized for different
   layers, the network designer may wish to bias traffic in a layer
   to use or avoid a platform that inefficiently supports a
   particular layer.  The announcement of a link in the layer may
   still be desirable to allow for diverse routing.

 - Many attributes discussed actually refer to a specific layer*.
   For example SRLG can be an MS-layer attribute that is inherited
   by all supported layers (VC-11, VC-12, VC-3, VC-4, VC-4-nc).
   Likewise Protection mechanisms supported can be specified at
   the MS-layer and the path layer.

   Knowing the specific layer the attributes exist at allow for
   higher quality routes to be developed*.  It can also allow for
   proper provisioning of upper layer functions, such as protection
   hold off timers*.

 - Combining layer specific attributes with layer relationships can
   provide a more efficient encoding mechanism than requiring
   separate link announcements per layer*.

4. The "TDM" Interface Switching Capability presumably includes
   layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and
   G.709.  The interaction with these layers needs to be defined.

5. In many cases, 8 levels of priority are not necessary*.  A more
   compact encoding that has a bitfield stating the priority levels
   being announced would reduce the size of the announcement.

The IESG wrote:

> The IESG has received a request from the Common Control and Measurement
> Plane Working Group to consider publication of the following two
> Internet-Drafts as Proposed Standards:
>
> o Routing Extensions in Support of Generalized MPLS
>     <draft-ietf-ccamp-gmpls-routing-05.txt>
> o OSPF Extensions in Support of Generalized MPLS
>     <draft-ietf-ccamp-ospf-gmpls-extensions-09.txt>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2003-2-24.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-05.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================