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.
