LC comments on draft-ietf-ccamp-ospf-gmpls-extensions-05.txt

[Alex Zinin <azinin@nexsi.com>]

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.

Cheers!

Alex

> 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
> 
>              draft-ietf-ccamp-ospf-gmpls-extensions-05.txt
> 
> 
[...]

>
> 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-
>    ROUTING].

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
> 

[OSPF-TE] says:

   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.
> 

Ditto

>
> 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
way.

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:

ditto

...

> 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
>    information.

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
>    aligned.

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
>    information.

"... 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
type.

<the end>