Sure, but that's their *implementation* issue. Standards don't stop you from doing something stupid, but they shouln't stop you from doing something intelligent/creative either...
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
