Subject: Re: [Pce] Experimental Codepoints allocation in PCEP registry

From: Dhruv Dhody <[email-masked]>
Date: Thu, 16 Jun 2016 05:25:47 +0000

Hi Adrian,

> How would you all feel about 8? (My instinct is to push for 4, but I can
> pre-emptively compromise :-)

I can work with 8 :)

Regards,
Dhruv

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 15 June 2016 23:52
> To: Dhruv Dhody <[email-masked]>; 'Ramon Casellas'
> <[email-masked]>; [email-masked]
> Subject: RE: [Pce] Experimental Codepoint allocation in PCEP registry
> 
> To Ramon's point...
> 
> > We do need to reach a consensus on what range to set aside.
> 
> Yes, we do. Both to satisfy ourselves and to get past the current IESG (not
> the one that approved the MANET registry).
> 
> I think you captured the essence. There should be enough code points to run
> the parallel experiments that need to be run together, but not so many that
> experiments that don't need to be run at the same time can grab values and
> expect to keep them. Essentially, before running an experiment all
> participants should get together to agree what values to use, and then when
> the experiment is over they should consider the values to have no meaning
> (until the next and completely different experiment).
> 
> As far as I can see, 30 messages looks like a complete orgy of experimentation!
> Four times more active experimentation in one experimental network than in
> the whole of the standardised and soon-to-be standardised history of PCEP.
> 
> How would you all feel about 8? (My instinct is to push for 4, but I can
> pre-emptively compromise :-)
> 
> Adrian
> 
> > -----Original Message-----
> > From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
> > Sent: 10 June 2016 11:03
> > To: Ramon Casellas; [email-masked]
> > Subject: Re: [Pce] Experimental Codepoint allocation in PCEP registry
> >
> > Hi Ramon,
> >
> > > -----Original Message-----
> > > From: Pce [mailto:[email-masked]] On Behalf Of Ramon Casellas
> > > Sent: 10 June 2016 14:42
> > > To: [email-masked]
> > > Subject: Re: [Pce] Experimental Codepoint allocation in PCEP
> > > registry
> > >
> > > Hi Dhruv, Jeff, all
> > >
> > > Indeed. Having been involved in PCE-related experimental and
> > > research activities I would welcome this and could be very helpful.
> > > It will not solve the issues but at least it defines the ranges.
> > >
> > > I can't provide much feedback, just curious about the rationale to
> > > allocate a given range e.g. 224-255 > 30 messages, etc.
> >
> > [Dhruv] You hit the jackpot.... we wanted to get the feedback of the
> > WG about this.
> >
> > IMHO we need to strike a right balance that there are enough
> > codepoints set aside for multiple parallel experimentations at a given
> > time, and not to give
> up a
> > big chunk out for experimentation that it hinders IANA allocation.
> >
> > We currently have 9 messages set by IANA, some 4 new messages in queue
> > to be sent to IANA, 13/255 ... so we do not have to worry about
> > running out any time soon :)
> >
> > BTW I could find one instance in MANET where a similar range is
> > allocated -
> > https://tools.ietf.org/html/rfc5444#section-6.2
> >
> > We do need to reach a consensus on what range to set aside.
> >
> > Regards,
> > Dhruv
> >
> > >
> > > Best regards
> > > Ramon
> > >
> > > On 10/06/2016 11:00, Jeff Tantsura wrote:
> > > > Hi Dhruv,
> > > >
> > > > Support, very much needed!
> > > >
> > > > Thanks,
> > > > Jeff
> > > >
> > > > On 6/9/16, 5:09 AM, "Pce on behalf of Dhruv Dhody"
> > > > <[email-masked]
> > > on behalf of [email-masked]> wrote:
> > > >
> > > >> Hi WG,
> > > >>
> > > >> In PCE IANA registry [http://www.iana.org/assignments/pcep] we do
> > > >> not
> > > have any codepoints for experimental usage. As we work on some new
> > experiments
> > > with PCEP (sometimes in open source platform), it would be wise to
> > > use experimental codepoints to avoid any conflict. For this purpose
> > > we have written a small draft to carve out some codepoints for
> > > experimental usage for PCEP messages, objects and TLVs.
> > > >>
> > > >> https://tools.ietf.org/html/draft-dhody-pce-pcep-exp-codepoints-0
> > > >> 0
> > > >>
> > > >> Please provide your feedback.
> > > >>
> > > >> Thanks,
> > > >> Dhruv & Daniel
> > > >>
> > > >> -----
> > > >>
> > > >> Name:           draft-dhody-pce-pcep-exp-codepoints
> > >
> > > _______________________________________________
> > > Pce mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/pce
> >
> > _______________________________________________
> > Pce mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pce

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 16 Jun 2016 09:42:08 +0400

Hi Adrian,

8 sounds like a good number.

Cheers,
Jeff

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 16 Jun 2016 07:56:40 +0200

>> pre-emptively compromise :-)

Seems quite reasonable to me :) now, let's say the "message" was the 
first (easy?) one. Objects and TLVs? Although I don't have a strong 
opinion, my two cents:

If I had to suggest something, in the experiments I have been involved 
with, procedures "at the message level" are rarely modified and not 
significantly extended. Most of the time we can do with 2-3 experimental 
messages ("PCEPTopologyUpdate, PCEPAlarm, PCEPCrossConnect", etc.) which 
is inline with the above.  Most of the time we try to extend a given 
message with either objects, TLVs is where most of the extensions go 
(e.g. to add "optical specific information", and I would rather use a 
"notification type wrapper for topology" instead of "PCEPTopologyUpdate")

- Objects 224 - 255 , to me it is ok. Shifting a bit around would either 
be 192 or 240, which at first sight seems too many or too few.

- TLVs 65280-65535 IMHO, this is slightly "tight" (erring on the side of 
caution, we never used that many)  other alternatives 63488, 64512 and 
65024 (I may tend to suggest these values for bit masking rather than 
65000- but both are perfectly ok

One final comment. If we want (do we? do we need to?) to cover 
everything, we may need to consider (just thinking out loud):

- OF Codes  -- we use this a lot, almost none of the std. algorithms 
address e.g. wavelength aspects, etc.

- Error types, error values, -- we use this to convey "failed because 
there were no optical regenerators available"

- Notification types, notification values -- see above

- ?RO subobjects (this is tricky, it is not only PCEP)  -- we have used 
"transceiver subobject", "regenerator subobject"

- ... other?

thank you and best regards
R.

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Jun 2016 13:37:49 +0000

However it's not prime

Yours Irrespectively,

John

> From: Pce [mailto:[email-masked]] On Behalf Of Jeff Tantsura
> Sent: Thursday, June 16, 2016 1:42 AM
> To: Dhruv Dhody; [email-masked]; 'Ramon Casellas'; [email-masked]
> Subject: Re: [Pce] Experimental Codepoints allocation in PCEP registry
> 
> Hi Adrian,
> 
> >> How would you all feel about 8? (My instinct is to push for 4, but I
> >> can pre-emptively compromise :-)
> >
> >I can work with 8 :)
> >
> >Regards,
> >Dhruv
> >
> >> Yes, we do. Both to satisfy ourselves and to get past the current
> >> IESG (not the one that approved the MANET registry).
> >>
> >> I think you captured the essence. There should be enough code points
> >> to run the parallel experiments that need to be run together, but not
> >> so many that experiments that don't need to be run at the same time
> >> can grab values and expect to keep them. Essentially, before running
> >> an experiment all participants should get together to agree what
> >> values to use, and then when the experiment is over they should
> >> consider the values to have no meaning (until the next and completely different
> experiment).
> >>
> >> Four times more active experimentation in one experimental network
> >> than in the whole of the standardised and soon-to-be standardised history of PCEP.
> >>
> >> How would you all feel about 8? (My instinct is to push for 4, but I
> >> can pre-emptively compromise :-)
> >>
> >> Adrian
> >>
> >> > > I can't provide much feedback, just curious about the rationale
> >> > > to allocate a given range e.g. 224-255 > 30 messages, etc.
> >> >
> >> > [Dhruv] You hit the jackpot.... we wanted to get the feedback of
> >> > the WG about this.
> >> >
> >> > codepoints set aside for multiple parallel experimentations at a
> >> > given time, and not to give
> >> up a
> >> > We currently have 9 messages set by IANA, some 4 new messages in
> >> > queue to be sent to IANA, 13/255 ... so we do not have to worry
> >> > about running out any time soon :)
> >> >
> >> > > >> In PCE IANA registry [http://www.iana.org/assignments/pcep] we
> >> > > >> do not
> >> > > with PCEP (sometimes in open source platform), it would be wise
> >> > > to use experimental codepoints to avoid any conflict. For this
> >> > > purpose we have written a small draft to carve out some
> >> > > codepoints for experimental usage for PCEP messages, objects and TLVs.
> >> > > >>

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 16 Jun 2016 16:26:54 +0000

Hi Ramon, 

See inline...

> From: Ramon Casellas [mailto:[email-masked]]
> Sent: 16 June 2016 11:27
> To: Dhruv Dhody <[email-masked]>; [email-masked];
> [email-masked]
> Seems quite reasonable to me :) now, let's say the "message" was the first
> (easy?) one. Objects and TLVs? Although I don't have a strong opinion, my
> two cents:
> 
> If I had to suggest something, in the experiments I have been involved with,
> procedures "at the message level" are rarely modified and not significantly
> extended. Most of the time we can do with 2-3 experimental messages
> ("PCEPTopologyUpdate, PCEPAlarm, PCEPCrossConnect", etc.) which is inline
> with the above.  Most of the time we try to extend a given message with either
> objects, TLVs is where most of the extensions go (e.g. to add "optical
> specific information", and I would rather use a "notification type wrapper
> for topology" instead of "PCEPTopologyUpdate")
> 
[Dhruv] Assuming we have messages and objects out of our way with -  
PCEP Messages - 246-255
PCEP Objects - 224-255

> 65000- but both are perfectly ok
[Dhruv] Yes, there are experiments that can require quite a few TLVs at disposal, I felt that setting aside 255 (65280-65535) was appropriate. 
To be extra safe and moving it to 65024 would be ok too if that is what the WG desire. 

> One final comment. If we want (do we? do we need to?) to cover everything,
> we may need to consider (just thinking out loud):
> 
> - OF Codes  -- we use this a lot, almost none of the std. algorithms address
> e.g. wavelength aspects, etc.
> 
> - Error types, error values, -- we use this to convey "failed because there
> were no optical regenerators available"
> 
[Dhruv] I will create a separate thread for this for easier tracking. 

Regards,
Dhruv