Hi Dhruv, I agree with your proposed changes:
1. only mention the 20 bits label value 2. fix the length to 4. Thanks. s. > On Mar 24, 2020, at 3:14 PM, Dhruv Dhody <dhruv.i...@gmail.com> wrote: > > Hi Mrinmoy, > > I will give authors some time to respond and confirm (and spin a new > update). I have noted this in the PCE WG wiki [ > https://trac.ietf.org/trac/pce/wiki/WikiStart ] to make sure we could > track this to closure. > > Thanks! > Dhruv > > On Tue, Mar 24, 2020 at 7:11 PM Mrinmoy Das <mrinmoy.i...@gmail.com> wrote: >> >> Hi Dhruv, >> >> Thanks for your quick reply. >> >> I have added PCE WG in this mail. More inline. >> >> Thanks & Regards, >> Mrinmoy >> >> On Tue, Mar 24, 2020 at 6:00 PM Dhruv Dhody <dhruv.i...@gmail.com> wrote: >>> >>> Hi Mrinmoy, >>> >>> I was suggest you to also include pce@ietf.org; WG could benefit from >>> the discussion in future. More inline. >>> >>> On Tue, Mar 24, 2020 at 5:08 PM Mrinmoy Das <mrinmoy.i...@gmail.com> wrote: >>>> >>>> Respected Authors and Contributors, >>>> >>>> Hope you all are doing well and safe in this tough times of Corona Virus >>>> Outbreak. >>>> >>>> I like to draw your attention regarding some parts of >>>> draft-ietf-pce-binding-label-sid-02 which I didn't able to understand >>>> properly. >>>> >>>> 1. BT = 0: The binding value is an MPLS label carried in the format >>>> >>>> specified in [RFC5462] where only the label value is valid, and >>>> other fields (TC, S, and TTL) fields MUST be considered invalid. >>>> The Length MUST be set to 7. >>>> >>>> >>>> Previous versions of private draft uses 4 byte to store MPLS 20 Bit >>>> label and ignores TC, S & TTL fields. >>> >>> The length in the previous version was 6, which was incorrect. The TLV >>> length is as per https://tools.ietf.org/html/rfc5440#section-7.1 >>> Which didnt make sense and your calculation below is correct! >>> >>>> But in IETF draft after TLV structure redefinition, total length of the >>>> TLV becomes 7, i.e. BT(1 Byte)+Reserved(3 Byte)+MPLS 20bit Label(3 Byte) = >>>> 7 Byte >>> >>> Yes >>> >>>> So, now MPLS 20 Bit Labelwill be stored in 3 byte. Is it correct? >>> >>> You can consider it a case of rounding up 20 bits to 3 bytes. >>> >>> >>>> If this is correct then I feel the wording of the above paragraph needs >>>> to be more specific, meaning in 3 Byte Label there will be no space for >>>> TTL, so >>>> my suggestion is to make below correction: >>>> >>>> BT = 0: The binding value is an MPLS label carried in the format >>>> >>>> specified in [RFC5462] where only the label value is valid, and >>>> other fields (TC, S, and TTL) fields MUST be considered invalid. >>>> The Length MUST be set to 7. >>>> >>> >>> My suggestion would be not mention any of the other fields and talk >>> only of 20 bits of Label. I see other SR RFCs take similar approach. >> >> >> Sounds Good. I'm agree with you. >> >>> >>>> >>>> 2. In some cases, a stateful PCE can request the PCC to allocate a >>>> >>>> binding value. It may do so by sending a PCUpd message containing an >>>> empty TE-PATH-BINDING TLV, i.e., no binding value is specified >>>> (making the length field of the TLV as 2). A PCE can also make the >>>> request PCC to allocate a binding at the time of initiation by >>>> sending a PCInitiate message with an empty TE-PATH-BINDING TLV. >>>> >>>> >>>> As per new Binding TLV Structure below, BT is of 1 Byte and there will be >>>> 3 Byte Reserved. >>>> >>>> 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 | Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | BT | Reserved | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> ~ Binding Value (variable length) ~ >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> Now, an empty Binding TLV should have length of BT(1 Byte) + Reserved (3 >>>> Byte) = 4 Byte instead of 2 Byte. >>>> >>>> So, I do not understand how in the draft it is calculated as 2 Byte. >>>> Could you please give me some clue? >>> >>> >>> This seems to be an error IMHO. 4 seems to be correct. >> >> >> Okay. So what would be your suggestion to developer who is implementing >> this draft? Should it be taken as 4? If draft needs correction >> when will that be published? >>> >>> >>> Thanks! >>> Dhruv >>> >>>> >>>> Thanks & Regards, >>>> Mrinmoy _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
