[CCAMP] comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-08

[Lou Berger <[e-mail]>]

Hi,

Here are some editorial and technical suggested changes to / comments on
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-08.  Please
use/respond as you see
appropriate. 

- The draft has a bunch of idnits issues which need to be fixed
  see
hhttp://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-08.txt
  (I'll use line numbers from this URL below.)

- Line 18-20:
  OLD
   achieved by defining the new Association Types in (Extended)
   ASSOCIATION object.  In addition, RSVP extensions allow asymmetric
   upstream and downstream bandwidths for the bidirectional LSP.
  NEW
   achieved by defining new Association Types for use in ASSOCIATION and
   in Extended ASSOCIATION objects. One of these types enables
   independent provisioning of the associated bidirectional LSPs, while
   the other enables single sided provisioning. The REVERSE_LSP Object
   is also defined to enable a single endpoint to specify all the
   parameters of an associated LSP in the single sided provisioning case.

- Line 147
  s/an/the
  s/object/objects

- Line 148:
  Add new sentence: "This document refers to the [RFC4872] defined
  ASSOCIATION objects and the [RFC6780] defined the Extended ASSOCIATION
  objects collectively as the (Extended) ASSOCIATION objects."

- Lines 150-154
  OLD
   This document specifies mechanisms for binding two reverse
   unidirectional LSPs into an associated bidirectional LSP. The
   association is achieved by defining new Association Types in the
   (Extended) ASSOCIATION object. RSVP extensions allow asymmetric
   upstream and downstream bandwidths for the bidirectional LSP.
  NEW
   This document specifies mechanisms for binding two reverse
   unidirectional LSPs into an associated bidirectional LSP. The
   association is achieved by defining new Association Types for use in
   (Extended) ASSOCIATION objects. One of these types enables
   independent provisioning of the associated bidirectional LSPs, while
   the other enables single sided provisioning. The REVERSE_LSP Object
   is also defined to enable a single endpoint to specify all the
   parameters of an associated LSP in the single sided provisioning
   case. For example, the REVERSE_LSP Object allow asymmetric upstream
   and downstream bandwidths for the associated bidirectional LSP.


- You introduce the terms "single sided and double sided provisioning" in
  this document.  This is fine, but they shouldn't have a recursive
  definition.  I therefore suggest
  - Line 180: s/side/endpoint
  - Lines 118,190: s/sides/endpoints

- Line 183: drop "to this"

- Line 264:
 OLD
   New REVERSE_LSP object applicable to the single sided provisioning
 New
   A new REVERSE_LSP object for use in the single sided provisioning

- Line 266-268
 OLD
   the existing SENDER_TSPEC object is
   added in the REVERSE_LSP object as a subobject in the initiating
   LSP's Path message to specify the reverse LSP's traffic parameters.
 NEW
   a SENDER_TSPEC object can be
   added in the REVERSE_LSP object as a subobject in the initiating
   LSP's Path message to specify an different bandwidth for the reverse
   LSP. 

- Line 270
  Add at end of sentence: "by including other existing objects in a
  REVERSE_LSP object."

- line 275
  s/inserts SENDER_TSPEC subobject/inserts a SENDER_TSPEC subobject for
                                   use by LSP2

- Line 283/4
  s/asymmetric bandwidths independently/separate bandwidths, which may
                                       or may not be identical.

- Section 3.4
  - Perhaps it's worth starting out the section with an informative
    description of how recovery is impacted before jumping into an
    illustrative example. 

- Section 3.4.1,  Lines 305-6
  Has anyone actually implemented what this says???  I don't think it
  says what you intend.  My understanding was that the recovery of each
  LSP would be independent and based on the parameters signaled in their
  respective path messages (same as 3.4.2), and both must use the
  identical (Extended) ASSOCIATION objects as used in during initial LSP
  establishment.  The only difference (between single and double) is
  that the egress of the initiating LSP would need to recognize that the
  recovery LSP is tied to the existing reverse LSP. (Which really
  should fall out of normal processing anyway.)

  (No matter what the processing rules need to be aligned with the
  resulting text.)

- Section 3.5
   As I read it, this section says  mesh-group LSPs using
   associated bidirectional use this (associated bidirectional)
   document. is that your intent?  If so, I think the section adds no
   value and should be dropped. 

  Alternatively, is it your intent to say that mesh-group LSPs MUST NOT
  use corouted bidirectional signaling?  If so, this should be explicitly
  stated, discussed and agreed to by the WG.

- Ordering of sections 4 & 5
  So section 4, which is called processing rules, starts with section
  4.1/4.2 which essentially defines formats.  I think the document would
  more readable if it started with the format definitions and then went
  on to procedures.  Yes this is certainly an editorial/style comment,
  but I found the current formulation quite confusing.  Also 5.2 is
  completely redundant with 4.1. 

- Lines 352/4 shouldn't these be LSP not LSPs?

Section 4.3 - Lines 394-427 - Suggested reordering, edits and additions:

(lines 394-39)
   This document defines the processing for the association of two
   unidirectional LSPs to form an associated bidirectional LSP.
   Such association is based on the use of an (Extended) ASSOCIATION
   object.
(lines 420-427)
   The procedures related to the actual identification of associations
   between LSPs based on (Extended) ASSOCIATION objects are defined in
   [RFC6780]. [RFC6780] specifies that in the absence of Association
   Type-specific rule for identifying association, the included
   (Extended) ASSOCIATION objects in the LSPs MUST be identical in order
   for an association to exist. This document adds no specific rules
   for the new Association Types defined, and the identification of LSP
   association therefore proceeds as specified in [RFC6780].
(lines 411-418)
   As described in [RFC6780], association of LSPs can be upstream or
   downstream initiated, as indicated by (Extended) ASSOCIATION objects
   in Path or Resv Messages.  The association of bidirectional LSPs is
   always upstream initialized, therefore the Association Types defined
   in this document are only to be interpreted in Path Messages.  These
   types SHOULD NOT be used in ASSOCIATION objects carried in Path
   messages and SHOULD be ignored if present. Only one
(lines 398-402)
   To indicate an associated bidirectional LSP, an ingress MUST insert
   an (Extended) ASSOCIATION object into the Path message of the
   unidirectional LSP that is part of the associated bidirectional LSP it
   initiates. If either Global Association Source or Extended
   Association Address is required, then an Extended ASSOCIATION object
   [RFC6780] MUST be inserted in the Path message. Otherwise, an
   ASSOCIATION object MAY used. Only one (Extended) ASSOCIATION object
   with the Association Types defined in this document SHOULD be
   included by an egress in an outgoing Path message. (Extended)
   ASSOCIATION objects with both single sided and double sided
   Association Types MUST NOT be added in the same Path message.
(lines 404-409)
   The ingress node MUST set the Association Type field in the
   (Extended) ASSOCIATION object to "Single Sided Associated
   Bidirectional LSPs" when single sided provisioning is used, and to
   "Double Sided Associated Bidirectional LSPs" when double sided
   provisioning is used.
(new)
   A transit node MAY identify the unidirectional LSPs of an associated
   bidirectional LSP based on (Extended) ASSOCIATION objects, with the
   Association Type values  defined in this document, carried in Path
   messages. Clearly, such associations are only possible when the LSPs
   the transit node. As defined above, such associations are made per
   the rules defined in [RFC6780].

   Egress nodes which support the Association Types defined in this
   document identify the unidirectional LSPs of an associated
   bidirectional LSP based on (Extended) ASSOCIATION objects carried in
   Path messages.  Note that an ingress node will normally be the ingress
   for one of the unidirectional LSPs that make up an associated
   bidirectional LSP.  When an egress node receives a Path message
   containing an (Extended) ASSOCIATION objects with one of the
   Association Types defined in this document, it MUST attempt to
   identify other LSPs (including ones for which it is an ingress node)
   with which the LSP being processed is associated.  As defined above,
   such associations are made per the rules defined in [RFC6780].

- Section 4.3.1 Covers tear down, but what about setup and changes to
  single sided provisioned reverse LSPs?  This really needs to be
  specified.

  How about moving & modifying 459/460 to the end of the previous
  section:

    No additional processing is needed for Path messages with an
    (Extended) ASSOCIATION object containing an Association Type field
    of Double Sided Associated Bidirectional LSP.

  and then rename

   Section 4.3.1. Single Sided Associated Bidirectional LSP Processing

  and have it cover the setup, modification, and teardown cases. It
  should include how the reverse LSP's objects are created from the
  triggering LSP, both when the REVERSE_LSP object is present and when
  it isn't.  It should also cover/mention the possibility of when
  modification to (or even a new) the originating LSP does or doesn't
  change a previously established reverse LSP.

  Lines 505-509 also belong in this section as they relate to
  single sided provisioning in general and not just REVERSE_LSP object
  processing.

    -- Let me know if you get stuck and I'll try to help.

- Lines 429-440: move to the end of section 4.3.2

- Line 432: s/MAY exist/can be present

- Line 433: s/MAY/can

- Line 452 (new paragraph):
   When an LSP signaled with a Path message containing an (Extended)
   ASSOCIATION object with an Association Type defined in this document
   is torn down, the processing node SHALL remove the binding of the LSP
   to any previously identified associated bidirectional LSP.

- Line 478: s/MAY/MUST
  (how else could it control the reverse LSP)

- Line 480:  s/LSP/LSP originating
- Line 480/1: Drop "and to specify the reverse LSP's traffic parameters."

- Line 485/486: "A REVERSE_LSP object MUST contain at least one subobject."

  What does it include if their are no objects to include?

- Line 489: s/endpoint/egress

- Line 492->501: reorder and revise:

   An egress node, upon receiving a Path message containing one or more
   REVERSE_LSP objects MUST verify that the Path message contains an
   ASSOCIATION or Extended ASSOCIATION object with the Association Type
   set to "Single Sided Associated Bidirectional LSPs". If it does not,
   the message MUST NOT trigger a reverse LSP.  This verification
   failure SHOULD NOT trigger any RSVP message but can be logged
   locally, and perhaps reported through network management mechanisms.

   Once validated, the egress MUST use the subobjects contained in any
   present REVERSE_LSP objects in the management of the reverse LSP
   described in the previous section.  Note that the contents of a
   REVERSE_LSP object may change over the life of an LSP and such
   changes MUST result in corresponding changes in the reverse LSP.

- Section 4.4.1  - belongs in 4.3.1.

- Line 544
  s/[ <REVERSE_LSP]/[ <REVERSE_LSP> ... ]

- Line 579 s/subobjects/objects

- Section 6, this section should identify the registries impacted in
  this document.  See draft-ietf-ccamp-gmpls-signaling-g709v3-12 for a
  recent example.

- Section 9.2
  I'd say 3473 is normative.