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.