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
