Subject: Re: [CCAMP] Request for early IANA Allocation for draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 2 Sep 2014 14:18:28 +0000

Thank you Adrian for the follow up.

Hi Lou,  Deborah,

We have addressed the chairs review comments in the latest revision of this draft.

Please help with the next steps for this request.

Many thanks,
Rakesh

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Reply-To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Date: Monday, 25 August, 2014 2:31 PM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, Lou Berger <[email-masked]<mailto:[email-masked]>>, DEBORAH BRUNGARD <[email-masked]<mailto:[email-masked]>>
Cc: CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] Request for early IANA Allocation for draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09

Chairs,

Not sure whether this fell through a crack as well.

I have to say that I *really* hate it when the early request is "Please give us these numbers because we are already shipping". Can we all please to try to get to this a little sooner so that the request can be "Please give us some numbers because we are moving from testing to shipping very soon."

>From a process point of view, the text below looks adequate to me. The chairs need to:
- check that this is what is in the I-D and that they think it is clear
- decide that the draft is sufficiently stable and likely to be
  developed based on these code points.
- issue the request to IANA

Thanks,
Adrian

From: CCAMP [mailto:[email-masked]] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: 12 August 2014 15:10
To: Lou Berger; DEBORAH BRUNGARD
Cc: CCAMP
Subject: Re: [CCAMP] Request for early IANA Allocation for draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09

Hi Lou, Deborah,

Can you please advise next steps for this request ?

Thank you for your guidance.

Regards,
Rakesh

From: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 24 July, 2014 6:54 PM
To: Lou Berger <[email-masked]<mailto:[email-masked]>>, DEBORAH BRUNGARD <[email-masked]<mailto:[email-masked]>>
Cc: CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: Request for early IANA Allocation for draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09

Hi CCAMP WG Chairs,

Following the procedure for Early IANA Allocation of Standards Track Code Points defined in Section 3.1 of RFC 7120, on behalf of the authors of the WG draft "RSVP-TE Extensions for Associated Bidirectional LSPs",  draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09, we are requesting to CCAMP WG chairs the early allocation of the following values:

http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09#section-6

6.1. Association Types

   New Association Types for ASSOCIATION and Extended ASSOCIATION Objects are defined in this document as follows:

   Value      Type

   -----      -----

   4 (TBD)    Double Sided Associated Bidirectional LSP (D)

   5 (TBD)    Single Sided Associated Bidirectional LSP (A)

   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, which will be extended and updated by this document.

6.2.  REVERSE_LSP Object

   A new class type for RSVP REVERSE_LSP Object has been requested in the 11bbbbbb range (TBD) with the following definition:

   Class Types or C-types (TBD), Value (TBD): 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, which will be extended and updated by this document.

The main reason for this request is that this draft has been implemented in a shipping product (using values from the draft and reserved range) but this can now lead to interoperability issues and we like to make sure we are using standard values before software is largely deployed in networks and avoid interoperability issues.

Thank you,
Rakesh and co-authors