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

From: Yakov Rekhter <[email-masked]>
Date: Thu, 11 Apr 2002 06:14:05 -0700

Alex,

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

see my response in-line...

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

I'll fix this in the next version of the draft.

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

That is not exactly correct, as the extensions defined in this
document could certainly be used for establishing LSPs that span
multiple area. An example of how this could be accomplished can
be found in Section 4.1 of draft-kompella-mpls-multiarea-te-02.txt.

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

Ok. I'll remove the list.

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

Could you please suggest the text.

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

Link Local Identifier. For more information consult Section 6.1
of draft-ietf-ccamp-gmpls-routing-03.txt.

>
> > 5.2. Link Remote Identifier
> >
> >    A Link Remote Identifier is a sub-TLV of the Link TLV with type 12,
> >    and length 4.
> >
>
> Ditto

Link Remote Identifier. For more information consult Section 6.1
of draft-ietf-ccamp-gmpls-routing-03.txt.

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

I'll do this in the next version of the draft.

>
> Something should also be said about other octets.

Ditto.

> Are they reserved and ignored on receipt?

Should be set to zero by the sender and should be 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.

Will do in the next version of the draft.

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

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

ditto.

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

ditto.

>
> >
> >    When the Switching Capability field is L2SC, there is no specific
> >    information.
>
> So, the field is not included? Please specify.

Yes, there is no Switching Capability specific information field.
I'll clarify this in the next version of the draft.

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

Will add to the next version of the draft.

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

Ditto.

>
> > 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 :)

Do you think it would be better to put TE Graceful Restart into
a separate Internet Draft ?

> >    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"?

Will add to the next version of the draft.

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

Will fix in the next version of the draft.

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

Ditto.

Yakov.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 11 Apr 2002 16:00:45 -0700

Yakov,

 Thanks for the follow up.
 See below, pls.

> be found in Section 4.1 of draft-kompella-mpls-multiarea-te-02.txt.

OK, I see what you mean. What I meant is that the document
does not described any sort of aggregation and distribution
of introduced parameters between areas.

> Could you please suggest the text.

If I may, I would leave the exact wording to the authors, please.
I would, however, be willing to review proposed text.

> of draft-ietf-ccamp-gmpls-routing-03.txt.

Please specify in the draft (though the names happen to be the same).

Ditto

> Should be set to zero by the sender and should be ignored on receipt.

Please specify as well.

Thanks a lot!

Alex