Hi Quan, Thanks for bringing this up.
Hi WG, I see these options - 1) Leave the last bit in flag field in LSP object as unassigned and all future allocations in 'LSP-EXTENDED-FLAG TLV'. 2) Mark the last bit as Extended (X) which directs the implementation to parse the 'LSP-EXTENDED-FLAG TLV'. And all future allocations in 'LSP-EXTENDED-FLAG TLV'. 3) Allocate the last flag in LSP object to the first request and any other future allocations in 'LSP-EXTENDED-FLAG TLV'. Thoughts? The 'LSP-EXTENDED-FLAG TLV' and the associated registry can be created in an independent document or the first document that is progressed in the WG that requires the flag. Thanks! Dhruv On Mon, Sep 16, 2019 at 2:12 PM <[email protected]> wrote: > > > Hi all, > > > As defined in [RFC8231], the length of LSP Object Flag field is 12 bits and > it defined the value from bit 5 to bit 11. > > The bits from 1 to 3 are defined in [RFC8623] and the bit value 4 is used in > [RFC8281]. So all bits of the flag has been occupied as the following shown. > > > > I noticed many other drafts have extended the flag, for example, > draft-li-pce-sr-path-segment defined a new P bit. > I think the path segment is the only one > But no unused bit can be assigned for it. So I propoese a new > LSP-EXTENDED-FLAG TLV for LSP object to extend the > > length of the flag as the following shown. > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type=TBD | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Extended Flag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > What is ypur opnion? Do you have other suggestions? > > > Thanks, > > Quan > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
