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 PROTECTED]>
Date: Sat, 29 Nov 2008 14:05:46
To: Lou Berger<[EMAIL PROTECTED]>
Cc: Adrian Farrel<[EMAIL PROTECTED]>; <[email protected]>
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 protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
