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

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

Thank you Lou.

I will address these comments and upload a new revision.

Thanks,
Rakesh


On 2014-09-13 11:40 AM, "Lou Berger" <[e-mail]> wrote:

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