Hi,

ATTENTION!
Authors of PCEP, XRO, BRPC and Path-Key.

I updated the temporary registry at http://www.olddog.co.uk/pce.htm

This is based on pcep-11 xro-04, brpc-05, and path-key-02

What I found was...

PCEP is a bit of a mess, sometimes numbering bits from most-significant and 
sometimes numbering from least-significant. Sometimes the count starts at 
zero, sometimes at one. I believe I have reproduced what the PCEP draft 
says, but do we want to fix it? It's probable that IANA will get confused 
unless we get some consistency.

Maybe best to count all bits left-to-right (most to least significant) 
starting at zero. This seems to be the usual IETF way.

Maybe good to also show the hex for each bit.

That would be a revision of PCEP, but it would fit in the review cycle if it 
was done quickly.


I believe I also found two points of confusion in BRPC...

14.1 defines the VSPT (V-bit) as
"Bit Number: 10
 Value: 0x60"
I may be old, but I am not aware of a way to encode 0x60 as a single bit.
Note also, however, that the registry for "Request Parameters Bit Flags" has 
a couple of unassigned bits. Maybe you'd like to close the gap?

14.2 assigns a new bit as
"Bit number (suggested value): 0x04"
If this is supposed to be the bit number (i.e. it number 4) this fits with 
the PCEP registry. But if it is supposed to be the hex representation of the 
bit-field note that PCEP says that the count starts at zero and assigns bits 
1, 2, and 3. So 0x04 is already assigned.


In Path-Key section 7.3, I found the RP object bits numbered from the other 
end.
In section 7.4, there is an allocaiton from the No-Path Vector TLV bit 
flags, and an attempt is made to allocate bit 1. This is already in use for 
PCEP.


Please fix drafts and let me know the updates.

Thanks,
Adrian 


_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce

Reply via email to