Re: [Pce] Experimental Codepoints allocation in PCEP registry

2016-06-15 Thread Ramon Casellas

On 16/06/2016 7:25, Dhruv Dhody wrote:

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


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.


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


Re: [Pce] Experimental Codepoints allocation in PCEP registry

2016-06-15 Thread Jeff Tantsura
Hi Adrian,

8 sounds like a good number.

Cheers,
Jeff

On 6/16/16, 9:25 AM, "Pce on behalf of Dhruv Dhody"  wrote:

>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:adr...@olddog.co.uk]
>> Sent: 15 June 2016 23:52
>> To: Dhruv Dhody ; 'Ramon Casellas'
>> ; pce@ietf.org
>> 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:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
>> > Sent: 10 June 2016 11:03
>> > To: Ramon Casellas; pce@ietf.org
>> > Subject: Re: [Pce] Experimental Codepoint allocation in PCEP registry
>> >
>> > Hi Ramon,
>> >
>> > > -Original Message-
>> > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ramon Casellas
>> > > Sent: 10 June 2016 14:42
>> > > To: pce@ietf.org
>> > > 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"
>> > > > > > > on behalf of dhruv.dh...@huawei.com> 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
>> > > Pce@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/pce
>> >
>> > ___
>> > Pce mailing list
>> > Pce@ietf.org
>> > https://www.ietf.org/mailman/listinfo/pce
>
>___
>Pce mailing list
>Pce@ietf.org

Re: [Pce] Experimental Codepoints allocation in PCEP registry

2016-06-15 Thread Dhruv Dhody
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:adr...@olddog.co.uk]
> Sent: 15 June 2016 23:52
> To: Dhruv Dhody ; 'Ramon Casellas'
> ; pce@ietf.org
> 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:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> > Sent: 10 June 2016 11:03
> > To: Ramon Casellas; pce@ietf.org
> > Subject: Re: [Pce] Experimental Codepoint allocation in PCEP registry
> >
> > Hi Ramon,
> >
> > > -Original Message-
> > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ramon Casellas
> > > Sent: 10 June 2016 14:42
> > > To: pce@ietf.org
> > > 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"
> > > >  > > on behalf of dhruv.dh...@huawei.com> 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
> > > Pce@ietf.org
> > > https://www.ietf.org/mailman/listinfo/pce
> >
> > ___
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


[Pce] RFC 7897 on Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)

2016-06-15 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries.


RFC 7897

Title:  Domain Subobjects for the Path 
Computation Element Communication Protocol (PCEP) 
Author: D. Dhody, U. Palle, R. Casellas
Status: Experimental
Stream: IETF
Date:   June 2016
Mailbox:dhruv.i...@gmail.com, 
udayasree.pa...@huawei.com, 
ramon.casel...@cttc.es
Pages:  35
Characters: 71770
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-pce-pcep-domain-sequence-12.txt

URL:https://www.rfc-editor.org/info/rfc7897

DOI:http://dx.doi.org/10.17487/RFC7897

The ability to compute shortest constrained Traffic Engineering Label
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains has been
identified as a key requirement.  In this context, a domain is a
collection of network elements within a common sphere of address
management or path computational responsibility such as an Interior
Gateway Protocol (IGP) area or an Autonomous System (AS).  This
document specifies a representation and encoding of a domain
sequence, which is defined as an ordered sequence of domains
traversed to reach the destination domain to be used by Path
Computation Elements (PCEs) to compute inter-domain constrained
shortest paths across a predetermined sequence of domains.  This
document also defines new subobjects to be used to encode domain
identifiers.

This document is a product of the Path Computation Element Working Group of the 
IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


[Pce] RFC 7896 on Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)

2016-06-15 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries.


RFC 7896

Title:  Update to the Include Route 
Object (IRO) Specification in the Path 
Computation Element Communication Protocol (PCEP) 
Author: D. Dhody
Status: Standards Track
Stream: IETF
Date:   June 2016
Mailbox:dhruv.i...@gmail.com
Pages:  5
Characters: 9966
Updates:RFC 5440

I-D Tag:draft-ietf-pce-iro-update-07.txt

URL:https://www.rfc-editor.org/info/rfc7896

DOI:http://dx.doi.org/10.17487/RFC7896

The Path Computation Element Communication Protocol (PCEP) enables
communications between a Path Computation Client (PCC) and a PCE, or
between two PCEs.  RFC 5440 defines the Include Route Object (IRO) to
specify network elements to be traversed in the computed path.  The
specification does not specify if the IRO contains an ordered or
unordered list of subobjects.  During recent discussions, it was
determined that there was a need to define a standard representation
to ensure interoperability.  It was also noted that there is a
benefit in the handling of an attribute of the IRO's subobject, the L
bit.

This document updates RFC 5440 regarding the IRO specification.

This document is a product of the Path Computation Element Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


Re: [Pce] Experimental Codepoint allocation in PCEP registry

2016-06-15 Thread Adrian Farrel
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:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: 10 June 2016 11:03
> To: Ramon Casellas; pce@ietf.org
> Subject: Re: [Pce] Experimental Codepoint allocation in PCEP registry
> 
> Hi Ramon,
> 
> > -Original Message-
> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ramon Casellas
> > Sent: 10 June 2016 14:42
> > To: pce@ietf.org
> > 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"  > on behalf of dhruv.dh...@huawei.com> 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-00
> > >>
> > >> Please provide your feedback.
> > >>
> > >> Thanks,
> > >> Dhruv & Daniel
> > >>
> > >> -
> > >>
> > >> Name:   draft-dhody-pce-pcep-exp-codepoints
> >
> > ___
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce