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

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

Thank you Deborah for your review comments.

Let us go through them and update accordingly.

thanks,
Rakesh and co-authors
 

On 2014-05-13 10:34 PM, "BRUNGARD, DEBORAH A" <[e-mail]> wrote:

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