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

[Yangguang Xu <xuyg@lucent.com>]

Kireeti,

I am trying to understand what you mean about a general document. Does a general
document cover only "lowest common denominator" or define a flexible mechanism
that could accommodate various situations? I think it should be the latter.
Then, layering and flexible layer adaptation are pretty common, I think this
draft should define a general mechanism to deal with it. (and sure, xxx
technology specific values can be defined in other xxx specific draft)

BTW, could a general document be really general without fully
studying/understanding most of xxx specific routings first? 

Thanks,

Yangguang 


> 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?
> 
> > 3. Layer specific attributes are not supported*.  Specifically:
> 
> Good points.  Please raise this with the SDH routing doc.
> 
> > 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.
> 
> > 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.
> 
> This has been discussed elsewhere.  This is the model in the base
> TE document; it has proven reasonable in practice.  If deployment
> proves otherwise, this is easy to fix.  For now, though, I would
> leave it as is.
> 
> Thanks again for your comments,
> Kireeti.