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

[Kireeti Kompella <[e-mail]>]

Hi Jonathan,

On Sun, 23 Feb 2003, Jonathan Sadler wrote:

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

Is the suggestion that Min LSP bw be removed for PSC?

> 2. The mechanism for showing relationships between server and client layers is not
> generalized*.  Specifically:

I've incorporated most of Stephen Shew's text on layer relations
almost as is.  Most of the specific comments you have should really
be addressed (IMO) to a document on routing for SONET/SDH (such as
draft-mannie-ccamp-gmpls-sonet-sdh-isis[ospf]-00.txt).  Please review
the new text, and let us know if there are issues to be addressed by
*this* document.

> 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).
...
>  - Many attributes discussed actually refer to a specific layer*.
...
>  - 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.

Do you have specific text that you think falls under the realm of
the overall functional spec (as opposed to layer-specific docs)?

Thanks,
Kireeti.