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:
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 protected]
https://www.ietf.org/mailman/listinfo/pce
