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

[George Newsome <gnewsome@ieee.org>]

Kireeti,

Just a few comments (in line) on your brush off of Jonathans remarks.

Regards

		George

Kireeti Kompella wrote:

> Hi Jonathan,
>
> On Sun, 23 Feb 2003, Jonathan Sadler wrote:
>
>
>
>>==========
>>
>>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.
>>
>
> Note that all possible permutations cannot possibly be addressed; 
however,
> we will consider adding some examples here.
>

This doesn't sound like a lack of examples, but a missing specification
of the field contents.

>

>>  - 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*.
>>
>
> It is not the intent of this document to support all possible info
> about a link, but to support a useful *and* scalable subset.  We will
> be guided by implementation and deployment experience to add
> selectively to the information.  Note that the Max Reservable bandwidth
> field remains, and in the case that the link is not a bundle, will be
> set to ~2.5G.
>

But it must be the intent of the document to be non contradictory.

It also seems to me to be unlikely that multiplexing structure can be 
encoded in two parameters. The actual tribs available on an OC-48 
interface depend strongly on the hardware provided, as well as on the 
agreement with whoever owns the far end. (In general, this is not the 
distant client)

>
>> - 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*.
>>
>
> It is also not the intent of this document to provide a full description
> of routing info for SDH.  This is a *general* document.  The intent is
> to provide a code point for SDH to be expanded by another document.  This
> was the model used for signaling as well: a *general* func spec, a
> *general* doc for each protocol, and *SDH-specific* docs.  There is an
> SDH specific routing doc; detailed comments are better directed there.
>
>
>> - 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.
>>
>
> Is this pointed out as a curiosity, or is there a question that needs
> to be addressed?
>

The question that needs addressing is that layering is NOT a technology
specific concept. The fact that different technologies seem to have
different descriptions for the same concept suggests that the concept is
perhaps not understood. This is not good for a purportedly generic document.


>
>>3. Layer specific attributes are not supported*.  Specifically:
>>
>
> Good points.  Please raise this with the SDH routing doc.
>

The points that follow are generic. So I can understand that while
specific values are perhaps left to technology specific documents, the
concept must be covered by the framework.

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

Ditto