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

From: Lou Berger <[email-masked]>
Date: Mon, 01 Dec 2008 10:25:45 -0500

that's what "SHOULD" is for...

At 04:47 AM 11/30/2008, JP Vasseur wrote:

>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.
>
>>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
>>
>>
>>
>>On Nov 28, 2008, at 11:38 PM, Lou Berger wrote:
>>
>>>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.)
>>
>>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.
>>>
>>>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:
>>>>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
>>
>
>

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 7 Dec 2008 10:54:17 -0000

Hi,

I don't see a lot of support for Lou's suggestion of having more than 16 
bits for the path key.

Lou points out that standards...
>>>shouln't stop you from doing something intelligent/creative

While the idea would certainly leave future implementations plenty of room 
to do clever things, we haven't had any indication that there is a pressing 
requirement for this change.

Lou wrote...
>>>>a 32 bit key would allow for

But this leaves us guessing, and without some further hints I don't think we 
can make a change based on this level of evidence.

In conclusion, Lou also said...
>>>>On the other hand, if changing this now also impacts

Since I have been told of successful interop test of the current definition, 
I suggest we leave things as they are.
If 32 bits (or more!) become a requirement in the future, we can develop a 
new subobject.

Cheers,
Adrian