Re: [CCAMP] Comments / questions on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09

[Lou Berger <[e-mail]>]

Rakesh,

Looks fine, although I think section 5.3 could benefit from some additional 
tweaks.  That can be done as part of normal wg process. Also, you don't 
need to include current assignments in the iana section.

Lou


On September 13, 2014 9:22:55 AM "Rakesh Gandhi (rgandhi)" 
<[e-mail]> wrote:

> Hi Lou,
>
> Appreciate the careful review of the document.
>
> Please see updated draft diffs attached and advise if OK to publish it.
>
> Please see inline for replies <RG> ..
>
>
> On 2014-09-12 5:28 PM, "Lou Berger" <[e-mail]> wrote:
>
> >Authors,
> >    As part of processing the early allocation request, I've the chairs
> >review of the draft.  I have some comments and questions.  I know I've
> >previously sent comments on the draft, nonetheless  I still found some
> >topics to discussion on this version.
> >
> >General comment:
> >- I think the phrase "reverse unidirectional LSPs" should be formally
> >defined in the document.
>
>
> <RG> Added.
>
>
> >
> >Section 4.2: I propose some more consistent/flexible wording
> >OLD
> >      For double sided provisioning, Association Source MUST be set to
> >      an address selected by the node that originates the association
> >      for the bidirectional LSP (which may be a management entity.)
> >
> >      For single sided provisioning, Association Source MUST be set to
> >      an address assigned to the node that originates the LSP.
> >NEW
> >      Association Source MUST be set to
> >      an address selected by the node that originates the association
> >      for the bidirectional LSP. For example, this may be a management
> >entity, or
> >     in the case of single sided provisioning, an address assigned to
> >the node that
> >     originates the LSP.
>
>
> <RG> Updated.
>
> >
> >Section 4.4.1
> >- You need to assign and name C-Type 1 (it's not TBD).
>
>
> <RG> Updated.
>
> >
> >
> >Section 4.4.2
> >- You should explicitly state the format of the subobects, perhaps
> >something along the lines of: "Subobjects have the same format as RSVP
> >Objects, see Section 3.1.2 of [RFC2205]."
>
>
> <RG> Updated.
>
> >
> >Section 5.1 (I might have proposed this text, so the error is mine!)
> >OLD
> >   types SHOULD NOT be used in ASSOCIATION objects carried in Path
> >   messages and SHOULD be ignored if present.
> >NEW
> >   types SHOULD NOT be used in ASSOCIATION objects carried in Resv
> >   messages and SHOULD be ignored if present.
>
> <RG> Fixed, I should have caught it.
>
>
> >
> >3rd to last paragraph need to point to section 5.3
> >OLD
> >    Note that teardown procedures of the
> >NEW
> >    Generally, the teardown procedures of the
> >and
> >OLD
> >    state removal).
> >NEW
> >    state removal). See Section 5.3below for additional rules related to
> >    LSPs established using single sided provisioning.
>
>
> <RG> Updated both.
>
>
> >
> >Section 5.1.1
> >TEXT says:
> >   As specified in [RFC4872], an endpoint node that does not support the
> >   new Association Types defined in this document MUST return a PathErr
> >   message with the error code "LSP Admission Failure" (value 01 as
> >   defined in [RFC2205]) and the sub-code "Bad Association Type" (value
> >   5 as defined in [RFC4872]).
> >
> >Humm, In keeping with being liberal in what you accept, I always
> >interpreted the admittedly vague reference (2nd to last paragraph of
> >section 16 in RFC4872)  to  define the error for a failure in
> >"appropriate PROTECTION object  settings" rather than an unknown
> >association type. I think the above should be dropped.
>
>
> <RG> Ok.
>
>
> >
> >Section 5.2.1 2nd paragraph
> >    This is a unique interpretation of 2205's definition for handling
> >unknown c-types in the form of 11bbbbbb.  I suggest dropping the
> >paragraph.
>
>
> <RG> Ok.
>
>
> >
> >Section 5.3
> >
> >The section is missing the handling of teardown when the REVERSE_LSP is
> >present.  Perhaps just drop:
> >
> >   For the single sided provisioning where the REVERSE_LSP Object is not
> >   signaled,
>
>
> <RG> It was there in the following paragraph. I edited the two paragraphs
> for clarity.
>
>
> >
> >Section 6.1
> >- Drop the suggested values
> >- please copy the table format from the text version of the registry and
> >then show the exact changes you'd like to see made (with the caveat of
> >using TBD where the assignments go) . See RFC5226 for general directions.
> >- The final paragraph should be the 1st, and the other section text
> >adjusted accordingly.
> >
> >Section 6.2
> >- Drop the first "(TBD)"
> >- Fix the text to distinguish between class number and c-type and which
> >is being requested and defined.
> >- also same final 2 comments from 6.1
>
>
> <RG> Both sections updated as follows:
>
>
> 6.1.  Association Types
>
>    IANA maintains the "Generalized Multi-Protocol Label Switching
>    (GMPLS) Signaling Parameters" registry (see
>    http://www.iana.org/assignments/gmpls-sig-parameters).  "Association
>    Type" subregistry is included in this registry.
>
>    This registry will be updated by new Association Types for
>    ASSOCIATION and Extended ASSOCIATION Objects defined in this document
>    as follows:
>
>
>    Value    Name                                            Reference
>     0     Reserved                                           [RFC4872]
>     1     Recovery (R)                                       [RFC4872]
>     2     Resource Sharing (S)                      [RFC4873][RFC6780]
>     TBD   Double Sided Associated Bidirectional LSP (D)    Section 4.2
>     TBD   Single Sided Associated Bidirectional LSP (A)    Section 4.2
>
>
> 6.2.  REVERSE_LSP Object
>
>    IANA maintains the "RSVP Parameters" registry (see
>    http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml).
>     Class Names, Class Numbers, and Class Types subregistry is included
>    in this registry.
>
>    This registry will be extended for new Class Number (Class-Num) and
>    Class Type (C-type) for RSVP REVERSE_LSP Object requested in the
>    11bbbbbb range defined in this document as follows:
>
>
>      Class Number   Class Name              Reference
>        199         ASSOCIATION               [RFC4872]
>        TBD         REVERSE_LSP               Section 4.4
>
>
>    - REVERSE_LSP Object: Class Type or C-type = 1
>
>
>
>
>
>
>
> >
> >I think that's it.  I'd like to get these issues resolved before putting
> >in the early allocation request.
>
>
> Thanks Lou,
>
> Regards,
> Rakesh
>
>
>
> >
> >Lou
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >CCAMP mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ccamp
>