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 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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
