Subject: [Pce] Path Key I-D : number of bits

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 27 Nov 2008 23:37:43 -0000

Hi,

To repeat something discussed briefly in Minneapolis (this was raised in 
CCAMP in discussion of draft-ietf-ccamp-path-key-ero-02.txt, but more 
properly applies to draft-ietf-pce-path-key-05.txt).

The path key subobject is formed as...

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |L|    Type     |     Length    |           Path Key            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         PCE ID (4 bytes)                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The question is: Are 16 bits enough for the Path Key? Isn't it possible that 
more than 2^16 path segments will be computed and "held" for possible 
expansion during signaling at any one time?

My feeling is that this would not be the case. The keys are relatively short 
lived, and can be recycled after a short safety period as described in the 
draft.

There are some special cases where resignaling of the LSP (from the head end 
with the same path key) would require the key to be held for longer, but the 
domain entry router can hold the key (in association with the session) to 
avoid any issues in this case.

Further, if there really are issues with depletion of keys, the PCE could 
use another PCE ID to create a further 2^16 keys.

What does the working group think?

Thanks,
Adrian

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Fri, 28 Nov 2008 06:53:45 +0100

Hi Adrian,

I certainly share my opinion; I think that in realistic deployment  
we'll be very far from seeing 2^16 pending LSP computations at any  
given time.

Cheers,

JP.

On Nov 28, 2008, at 12:37 AM, Adrian Farrel wrote:

> Hi,
>
> To repeat something discussed briefly in Minneapolis (this was  
> raised in CCAMP in discussion of draft-ietf-ccamp-path-key- 
> ero-02.txt, but more properly applies to draft-ietf-pce-path- 
> key-05.txt).
>
> The question is: Are 16 bits enough for the Path Key? Isn't it  
> possible that more than 2^16 path segments will be computed and  
> "held" for possible expansion during signaling at any one time?
>
> My feeling is that this would not be the case. The keys are  
> relatively short lived, and can be recycled after a short safety  
> period as described in the draft.
>
> There are some special cases where resignaling of the LSP (from the  
> head end with the same path key) would require the key to be held  
> for longer, but the domain entry router can hold the key (in  
> association with the session) to avoid any issues in this case.
>
> Further, if there really are issues with depletion of keys, the PCE  
> could use another PCE ID to create a further 2^16 keys.
>

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 28 Nov 2008 02:19:09 -0600

Adrian,

	I mostly agree with your reasoning.

	In the first case, it is probably going to be a too
interesting world in which we live if we can expect to get
close to exceeding this many current path keys for each of
potentially many PCEs.  This implies that we would expect
to see on the rough order of 64K traffic engineered multi
(adminstrative) domain LSPs for which it is necessary for
a subset of all PCEs to maintain active state information
relative to ongoing signaling transactions.  I dislike 
thinking about the number of actual steady-state traffic
engineered, multi (administrative) domain LSPs that might
be expected to exist when we expect this many to be in the
process of being setup at any time.  I also have trouble
imagining the application that would require orders of
magnitude more than 64K such multi domain TE LSPs.

	Also, if real-world implementations find it necessary
to exceed this number by (for example) 2 or 3 times, a need 
to maintain multiple PCE IDs is likely to be the least of 
the issues they will face.  

	However, should a need arise for orders of magnitude
greater numbers of path keys (for example, should it turn
out that there's a need to record assigned path key values
for some period of time - like 24 hours - for any reason),
then the approach of using multiple PCE IDs scales rather
poorly and would probably require more work.  For one thing, 
I am not sure how this would work; would the PCE from whom 
a path computation is requested be able to provide responses 
that specify a separate PCE ID?  Do we expect that both PCS 
and PCC implementations will be able to maintain state on 
orders of magnitude more PCE IDs?  Do extra PCE ID instances 
go away when no longer needed?

	Wasn't one of the options to possibly define another
subobject in the future - should the need arise?  If that
were the case, the current sub-object definition allows the
implementers today to scale their implementation resource 
needs to fit a smaller number of possible values we think
we might need in the near future, while leaving open the
the possibility of later implementations that support
larger values...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Adrian Farrel
> Sent: Thursday, November 27, 2008 6:38 PM
> To: [email-masked]
> Subject: [Pce] Path Key I-D : number of bits
> 
> Hi,
> 
> To repeat something discussed briefly in Minneapolis (this was raised
> in CCAMP in discussion of draft-ietf-ccamp-path-key-ero-02.txt, but
> more properly applies to draft-ietf-pce-path-key-05.txt).
> 
possible
> that more than 2^16 path segments will be computed and "held" for 
> possible expansion during signaling at any one time?
> 
> My feeling is that this would not be the case. The keys are relatively
> short lived, and can be recycled after a short safety period as 
> described in the draft.
> 
> head end with the same path key) would require the key to be held for 
> longer, but the domain entry router can hold the key (in association
> with the session) to avoid any issues in this case.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Nov 2008 11:04:25 -0000

Hi Eric,

> subobject in the future - should the need arise?

Yes. We always have that option.
And if we believe 2^16 is enough for the foreseeable future, then we have 
nothing more to do at the moment.

As JP says...

> I certainly share my opinion;

Which is good to know :-)

Adrian

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Nov 2008 17:38:03 -0500

So bits in this object are cheap and a 32 bit key would allow for 
potential future cases that we can already envision as well as 
today's known cases.  (BTW I know of one experimental usage of PCE 
that I suspect will want this immediately.)  IMO optimizing the 
subobject by 2/4 bytes is completely unwarranted.

Now, that said, it is quite late in the process to raise this 
point.  (mea culpa.) If the only impact of this change is a minor 
delay in progressing the documents, then I think we should make the 
change now.  On the other hand, if changing this now also impacts 
implementations, I think we should only support longer keys once 
there is real (not today's theoretical) demand for them.

So, IMO we should make this change based on implementation impact.

Is there anyone with an implementation who wants to weigh in on the 
real/practical impact to them on this change?

Lou

At 06:37 PM 11/27/2008, Adrian Farrel wrote:
>raised in CCAMP in discussion of 
>draft-ietf-ccamp-path-key-ero-02.txt, but more properly applies to 
>draft-ietf-pce-path-key-05.txt).
>

---

From: JP Vasseur <[email-masked]>
Date: Sat, 29 Nov 2008 14:05:46 +0100

On Nov 28, 2008, at 11:38 PM, Lou Berger wrote:

> that I suspect will want this immediately.)

Well, I may make a comment: in this case, I can see a *number* of  
issues that they will be facing if they have a model where you can end  
up with more than 65 K pending requests ...

>  IMO optimizing the subobject by 2/4 bytes is completely unwarranted.
>

---

From: "Lou Berger" <[email-masked]>
Date: Sat, 29 Nov 2008 14:58:25 +0000

Sure, but that's their *implementation* issue. Standards don't stop you from doing something stupid, but they shouln't stop you from doing something intelligent/creative either...

Lou
-----Original Message-----
From: JP Vasseur <[email-masked]>

Date: Sat, 29 Nov 2008 14:05:46 
To: Lou Berger<[email-masked]>
Cc: Adrian Farrel<[email-masked]>; <[email-masked]>
Subject: Re: [Pce] Path Key I-D : number of bits

---

From: JP Vasseur <[email-masked]>
Date: Sun, 30 Nov 2008 10:47:00 +0100

On Nov 29, 2008, at 3:58 PM, Lou Berger wrote:

> Sure, but that's their *implementation* issue. Standards don't stop  
> you from doing something stupid,

Well standard should at least "warn" you from doing something stupid ...

> but they shouln't stop you from doing something intelligent/creative  
> either...
>

Surely.

Cheers,

JP.