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

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi Rakesh,

A couple of additional comments:
- you swapped [Extended] to (Extended) in Section 3 (and later in the document), whereas in Section 4, you removed the brackets. As Lou said previously, this is not needed and it is confusing as it's not aligned with RFC6780.
- Section 3 on provisioning and signaling procedures needs 2219 language.
- you changed the text in the introduction, and now have MPLS-TP requirement 14 twice listed. The previous version was better organized. It seems the rationale for repeating requirement 14 was to add a new paragraph describing Internet services applications. As this document is on meeting the referenced MPLS-TP requirements, this is out-of-context. Suggest going back to the previous version's introduction.
- As Lou previously suggested, for the compatibility, you noted compatibility aspects for intermediate nodes, it would be also helpful to add RFC's 6780 processing rules for egress nodes not supporting the Extended Association C-Type.

Thanks,
Deborah

-----Original Message-----
From: CCAMP [mailto:[e-mail]] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: Friday, May 09, 2014 4:27 PM
To: Lou Berger; [e-mail]
Cc: CCAMP
Subject: Re: [CCAMP] comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-08

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

_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp