I don't know if the pun was intended, but I do like Kireeti's comment about
"bring them to light". Undoubtedly, this would be within the ITU-T
(wavelength) grid! ;-)
There is, I think, some commonality in the comments and the reply in that
the intent is to generalize the extensions needed for routing to accomodate
non-PSC resources. I agree with the first 4 points that Jonathan made in
that I think layer information must be included in routing so that important
functions can be performed. I believe that the use of one or two bandwidth
values was motivated by the desire to use a "lowest common denominator"
attribute to generalize on path computation and avoid extensive details of
links. Unfortunately, this can obscure variable adaptation on a link and
the ability to determine a path at a particular adaptation (e.g., VC-3).
In variable adaptation, multiple layers can be supported on a link (actually
a G.805 trail) as mentioned in the 2nd point. When a label (channel) is
used at a particular layer, it has the effect of modifying the available
labels in other layers supported on the same link. It is important to thus
be able to reflect the layer relationship in routing.
For the issue of path computation at a particular layer, while bandwidth can
give a superset of possible paths, what is needed in many contexts is a path
at a specific adaptation. Because different combinations of adaptations can
provide the same b/w, the result is that it infeasible paths can be computed
because there is no distinction between what type of adaptation can be
supported. There are times when for example, you want to have a VC-3
connection end-to-end and not just an LSP with its equivalent bandwidth
because the service that was sold was specifically a VC-3.
-----Original Message-----
From: Kireeti Kompella [mailto:kireeti(_at_)juniper(_dot_)net]
Sent: Saturday, March 01, 2003 14:29
To: Jonathan Sadler
Cc: iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
ccamp(_at_)ops(_dot_)ietf(_dot_)org
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS
vto Proposed Standard
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 (*).
Thanks for your comments. Most of these would have more appropriate to
raise in the WG Last Call, but it is certainly better to bring them to light
now than never.
==========
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.
2. The mechanism for showing relationships between server and client
layers is not generalized*. Specifically:
- Relationships between SONET/SDH layers (ISC type: TDM) are
implicitly stated based on the Min and Max LSP bandwidth
advertised*. To quote draft-ietf-ccamp-gmpls-routing-05.txt:
"On an interface having Standard SDH multiplexing, 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."
This requires node doing the route calculation to understand
the G.707 multiplexing hierarchy. Since LSP routing is source
routed, it could be the node doing the route calculation
doesn't understand G.707.
This document does *not* cover how path computation is done. Of course, the
information is less than useful if it cannot be used effectively. However,
it has been pointed out implicitly and explicitly in several documents that
the head end does *not* have to do the entire route computation -- this is
one reason why there are loose hops in the ERO. See also the various drafts
on multi-area TE computation.
- 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.
- 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?
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.