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 PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Adrian Farrel
> Sent: Thursday, November 27, 2008 6:38 PM
> To: pce@ietf.org
> 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).
>
> 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
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
