[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS signaling (RSVP) assignment request.

To: Lou Berger <lberger@movaz.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: RE: GMPLS signaling (RSVP) assignment request.
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Date: Tue, 12 Mar 2002 01:53:01 +0100
Cc: ccamp@ops.ietf.org, Scott Bradner <sob@harvard.edu>, IANA <iana@iana.org>
> 
> PS What values would you suggest we use during the 
> interoperability testing 
> you have discussed?
> 
So that sounds like a good reason to try and convince IANA
to do the assignment earlier on.
Of course you can "test" with some temp agreed values.
I assume the testing is done in a controlled environment, right?

Bert

> At 06:50 PM 3/11/2002, Wijnen, Bert (Bert) wrote:
> >Lou, nomrally the IANA assigns such number right at the
> >time that the RFC gets published. The reason for that is
> >that they do not want to end up with assignments for
> >stuff that does not make it up to RFC.
> >
> >Bert
> >
> > > -----Original Message-----
> > > From: Lou Berger [mailto:lberger@movaz.com]
> > > Sent: Tuesday, March 12, 2002 12:44 AM
> > > To: ccamp@ops.ietf.org
> > > Subject: Fwd: GMPLS signaling (RSVP) assignment request.
> > >
> > >
> > > FYI
> > >
> > > >Date: Mon, 11 Mar 2002 18:39:18 -0500
> > > >To: iana@iana.org
> > > >From: Lou Berger <lberger@movaz.com>
> > > >Subject: GMPLS signaling (RSVP) assignment request.
> > > >
> > > >Hello!
> > > >
> > > >We'd like to request assignment of types defined in
> > > >draft-ietf-mpls-generalized-rsvp-te-06.  This draft has
> > > >passed WG last call and is on it's way to IESG/IETF last call.
> > > >Assignment is needed to ensure interoperability.
> > > >
> > > >Thank you,
> > > >Lou Berger (and co-authors)
> > > >
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >
> > > >RSVP related values defined in 
> draft-ietf-mpls-generalized-rsvp-te-06
> > > >with suggested values.
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >Message Types
> > > >
> > > >o Notify message (suggested Message type =21)
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >Class Types
> > > >
> > > >o RSVP_HOP (Existing C-Num 3)
> > > >   - IPv4 IF_ID RSVP_HOP (Suggested C-type =3)
> > > >   - IPv6 IF_ID RSVP_HOP (Suggested C-type =4)
> > > >
> > > >o ERROR_SPEC (Existing C-Num 6)
> > > >   - IPv4 IF_ID ERROR_SPEC (Suggested C-type =3)
> > > >   - IPv6 IF_ID ERROR_SPEC (Suggested C-type =4)
> > > >
> > > >o LABEL_REQUEST (Existing Class-Num 19)
> > > >   - Generalized_Label_Request (Suggested C-Type =4)
> > > >
> > > >o RSVP_LABEL (Existing  Class-Num 16)
> > > >   - Generalized_Label (Suggested C-Type =2)
> > > >   - Waveband_Switching_Label C-Type (Suggested C-Type =3)
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >New Class-Nums, C-Types inherited from Label object 
> (same as CNum16)
> > > >
> > > >o RECOVERY_LABEL     Class-Num of form 0bbbbbbb (suggested =34)
> > > >o SUGGESTED_LABEL    Class-Num of form 10bbbbbb (suggested =129)
> > > >o UPSTREAM_LABEL     Class-Num of form 0bbbbbbb (suggested =35)
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >New Class-Nums
> > > >
> > > >o LABEL_SET                     Class-Num of form 0bbbbbbb
> > > (suggested =36)
> > > >   - Type 1               (C-Type =1)
> > > >o ACCEPTABLE_LABEL_SET          Class-Num of form 10bbbbbb
> > > (suggested =130)
> > > >   - Type 1 Acceptable_Label_Set (C-type from label_set cnum)
> > > >o NOTIFY_REQUEST                Class-Num of form 11bbbbbb
> > > (suggested =195)
> > > >   - IPv4 Notify Request  (C-Type =1)
> > > >   - IPv6 Notify Request  (C-Type =2)
> > > >o PROTECTION                    Class-Num of form 0bbbbbbb
> > > (suggested =37)
> > > >   - Type 1               (C-Type =1)
> > > >o ADMIN STATUS                  Class-Num of form 11bbbbbb
> > > (suggested =196)
> > > >   - Type 1               (C-Type =1)
> > > >o RESTART_CAP                   Class-Num of form 10bbbbbb
> > > (suggested =131)
> > > >   - Type 1               (C-Type =1)
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >ERO/RRO subobject types
> > > >
> > > >o Label ERO subobject
> > > >   Type 3 - Label
> > > >
> > > >o Label RRO subobject
> > > >   Type 3 - Label
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >Error codes
> > > >
> > > >o "Routing problem/Label Set"
> > > (Suggested value =11)
> > > >o "Routing problem/Switching Type"
> > > (Suggested value =12)
> > > >o "Routing problem/Unacceptable label value"
> > > (Suggested value =13)
> > > >o "Routing problem/Unsupported Encoding"
> > > (Suggested value =14)
> > > >o "Routing problem/Unsupported Link Protection"
> > > (Suggested value =15)
> > > >o "Notify Error/Control Channel Active State"
> > > (Suggested value =4)
> > > >o "Notify Error/Control Channel Degraded State"
> > > (Suggested value =5)
> > > 
> >---------------------------------------------------------------------
> > > >
> > > >[related section from draft]
> > > >13. IANA Considerations
> > > >
> > > >    IANA assigns values to RSVP protocol parameters.  Within
> > > the current
> > > >    document multiple objects are defined.  Each of these
> > > objects contain
> > > >    C-Types.  This section defines the rules for the
> > > assignment of the
> > > >    related C-Type values.  This section uses the
> > > terminology of BCP 26
> > > >    "Guidelines for Writing an IANA Considerations 
> Section in RFCs"
> > > >    [BCP26].
> > > >
> > > >    As per [RFC2205], C-Type is an 8-bit number that 
> identifies the
> > > >    function of an object.  There are no range restrictions.  All
> > > >    possible values except zero are available for assignment.
> > > >
> > > >    The assignment of C-Type values of the objects 
> defined in this
> > > >    document fall into three categories.  The first category
> > > inherit C-
> > > >    Types from the Label object, i.e., object class number
> > > 16 [RSVP-TE].
> > > >    IANA is requested to institute a policy whereby all 
> C-Type values
> > > >    assign for the Label object are also assigned for 
> the following
> > > >    objects:
> > > >       o Suggested_Label    (Class-Num TBA)
> > > >       o Upstream_Label     (Class-Num TBA)
> > > >       o Recovery_Label     (Class-Num TBA)
> > > >
> > > >    The second category of objects follow independent policies.
> > > >    Specifically, following the policies outlined in 
> [BCP26], C-Type
> > > >    values in the range 0x00 - 0x3F are allocated through an IETF
> > > >    Consensus action, values in the range 00x40 - 0x5F are
> > > allocated as
> > > >    First Come First Served, and values in the range 
> 0x60 - 0x7F are
> > > >    reserved for Private Use.  This policy applies to 
> the following
> > > >    objects.
> > > >       o Label_Set          (Class-Num TBA)
> > > >       o Notify_Request     (Class-Num TBA)
> > > >       o Protection         (Class-Num TBA)
> > > >       o Admin Status       (Class-Num TBA)
> > > >       o Restart_Cap        (Class-Num TBA)
> > > >
> > > >
> > > >
> > > >Berger, et. al.
> > >   [Page 35]
> > > >Internet Draft draft-ietf-mpls-generalized-rsvp-te-06.txt
> > > November 2001
> > > >
> > > >
> > > >    The assignment of C-Type values for the remaining object, the
> > > >    Acceptable_Label_Set object, follows the assignment of
> > > C-Type values
> > > >    of the Label_Set object.  IANA is requested to 
> institute a policy
> > > >    whereby all C-Type values assigned for the Label_Set
> > > object are also
> > > >    assigned for the Acceptable_Label_Set object.
> > >
> > >
>
Prev by Date: RE: GMPLS signaling (RSVP) assignment request.
Next by Date: Reminder: Survey forms due tomorrow
Previous by thread: RE: GMPLS signaling (RSVP) assignment request.
Next by thread: Reminder: Survey forms due tomorrow
Index(es):
- Date
- Thread