Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Alex Zinin (azininNEXSI.COM)
Date: Tue Apr 09 2002 - 15:04:50 CDT
Kireeti, et al:
Please find my comments on the draft below.
I'm also CC'ing the OSPF WG to make sure we
have a good coverage here.
> CCAMP Working Group K. Kompella (Juniper Networks)
> Internet Draft Y. Rekhter (Juniper Networks)
> Expiration Date: October 2002 A. Banerjee (Calient Networks)
> J. Drake (Calient Networks)
> G. Bernstein (Ciena)
> D. Fedyk (Nortel Networks)
> E. Mannie (GTS Network)
> D. Saha (Tellium)
> V. Sharma (Metanoia, Inc.)
I would consult your ADs about the length of the author list.
IMHO, it's kind of hard to imagine 9 people editing
a draft containing 7 pages of useful info ;))
> OSPF Extensions in Support of Generalized MPLS
> 2. Abstract
> This document specifies encoding of extensions to the OSPF routing
> protocol in support of Generalized Multi-Protocol Label Switching
> (GMPLS). The description of the extensions is specified in [GMPLS-
The rfc-ed will request the citation to be removed from the abstract.
> 4. Introduction
> This document specifies extensions to the OSPF routing protocol in
> support of carrying link state information for Generalized Multi-
> Protocol Label Switching (GMPLS). The set of required enhancements to
> OSPF are outlined in [GMPLS-ROUTING].
It might be a good idea to explicitly mention that only
intra-area issues are covered here.
> 5. OSPF Routing Enhancements
> In this section we define the enhancements to the TE properties of
> GMPLS TE links that can be announced in OSPF TE LSAs. The Traffic
> Engineering (TE) LSA, which is an opaque LSA with area flooding scope
> [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and
> has one or more nested sub-TLVs for extensibility. The top-level TLV
> can take one of two values (1) Router Address or (2) Link. In this
> document, we enhance the sub-TLVs for the Link TLV in support of
> GMPLS. Specifically, we add the following sub-TLVs to the Link TLV:
> 1. Link Local Identifier,
> 2. Link Remote Identifier,
> 3. Link Protection Type,
> 4. Interface Switching Capability Descriptor, and
> 5. Shared Risk Link Group.
Minor: given the table below, do we need the above list really?
> The following defines the Type and Length of these sub-TLVs:
> Sub-TLV Type Length Name
> 11 4 Link Local Identifier
> 12 4 Link Remote Identifier
> 14 4 Link Protection Type
> 15 variable Interface Switching Capability Descriptor
> 16 variable Shared Risk Link Group
The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
exactly once. All other sub-TLVs defined here may occur at most
once. These restrictions need not apply to future sub-TLVs.
Unrecognized sub-TLVs are ignored.
Considering the last two sentences, it would be really nice if
this document said something about this.
You might also say something about processing of sub-TLVs
with unexpected length.
> 5.1. Link Local Identifier
> A Link Local Identifier is a sub-TLV of the Link TLV with type 11,
> and length 4.
What do I put in it?
> 5.2. Link Remote Identifier
> A Link Remote Identifier is a sub-TLV of the Link TLV with type 12,
> and length 4.
> 5.3. Link Protection Type
> The Link Protection Type is a sub-TLV of the Link TLV, with type 14,
> and length of four octets, the first of which is a bit vector
> describing the protection capabilities of the link. They are:
Might be a good idea to include an IETF-style format illustration
here, to make sure everyone understands "first octet" the same
Something should also be said about other octets. Are they reserved
and ignored on receipt?
> 0x01 Extra Traffic
> 0x02 Unprotected
> 0x04 Shared
> 0x08 Dedicated 1:1
> 0x10 Dedicated 1+1
> 0x20 Enhanced
> 0x40 Reserved
> 0x80 Reserved
I believe these are described in [GMPLS-ROUTING]. You may want
to add a reference to it here.
> 5.4. Shared Risk Link Group (SRLG)
> The SRLG is a sub-TLV of the Link TLV with type 16. The length is the
> length of the list in octets. The value is an unordered list of 32
> bit numbers that are the SRLGs that the link belongs to. The format
> of the value field is as shown below:
> 5.5. Interface Switching Capability Descriptor
> The Interface Switching Capability Descriptor is a sub-TLV of the
> Link TLV with type 15. The length is the length of value field in
Minor: might want to change wording, not clear what "with type 15" is
relative to, one may ready "Link TLV with type 15".
> octets. The format of the value field is as shown below:
> When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4,
> the specific information includes Interface MTU, Minimum LSP
> Bandwidth, and padding. The Interface MTU is encoded as a 2 octets
> integer. The Minimum LSP Bandwidth is is encoded in a 4 octets field
> in the IEEE floating point format. The units are bytes (not bits!)
> per second. The padding is 2 octets, and is used to make the
> Interface Switching Capability Descriptor sub-TLV 32-bits aligned.
Would be just great to have a field format illustration here.
> When the Switching Capability field is L2SC, there is no specific
So, the field is not included? Please specify.
> When the Switching Capability field is TDM, the specific information
> includes Minimum LSP Bandwidth, an indication whether the interface
> supports Standard or Arbitrary SONET/SDH, and padding. The Minimum
> LSP Bandwidth is encoded in a 4 octets field in the IEEE floating
> point format. The units are bytes (not bits!) per second. The
> indication whether the interface supports Standard or Arbitrary
> SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the
> interface supports Standard SONET/SDH, and 1 if the interface
> supports Arbitrary SONET/SDH. The padding is 3 octets, and is used
> to make the Interface Switching Capability Descriptor sub-TLV 32-bits
Again, would appreciate a format illustration here. Breaking field
description into a list here and above would be nice as well.
> When the Switching Capability field is LSC, there is no specific
"... and the <blah> field is not included."
> The Interface Switching Capability Descriptor sub-TLV may occur more
> than once within the Link TLV.
"...to indicate multiple switching capabilities supported by the link.
The resulting set of capabilities includes all those announced in
multiple instances of the sub-TLV" or something like this?
> 6. Implications on Graceful Restart
> The restarting node should follow the OSPF restart procedures [OSPF-
> RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP].
These look like normative references and hence it means that the
document will be delayed until those are complete. Just a heads-up :)
> When a restarting node is going to originate its TE LSAs, the TE LSAs
> containing Link TLV should be originated with 0 unreserved bandwidth,
> and if the Link has LSC or FSC as its Switching Capability then also
> with 0 as Max LSP Bandwidth, until the node is able to determine the
> amount of unreserved resources taking into account the resources
> reserved by the already established LSPs that have been preserved
> across the restart. Once the restarting node determines the amount of
> unreserved resources, taking into account the resources reserved by
> the already established LSPs that have been preserved across the
> restart, the node should advertise these resources in its TE LSAs.
> In addition in the case of a planned restart prior to restarting, the
> restarting node SHOULD originate the TE LSAs containing Link TLV with
> 0 as unreserved bandwidth, and if the Link has LSC or FSC as its
> Switching Capability then also with 0 as Max LSP Bandwidth.
"...to discourage new LSP establishment through the restarting router"?
> Neighbors of the restarting node should continue advertise the actual
> unreserved bandwidth on the TE links from the neighbors to that node.
> Regular graceful restart should not be aborted if a TE LSA or TE
> topology changes. TE graceful restart need not be aborted if a TE LSA
> or TE topology changes.
> 7. Security Considerations
> The sub-TLVs proposed in this document does not raise any new
> security concerns.
"do not raise"
> 9. References
Might be a good idea to split these to normative and
informative or specify the type if all of them are the same