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

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Thank you Lou for the detailed review of the draft.

We will go through these comments and update/advise accordingly.

Thanks again,
Rakesh and co-authors



On 2014-05-09 1:28 PM, "Lou Berger" <[e-mail]> wrote:

>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-ccam
>p-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.
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp