Re: [babel] Comments about rfc7298bis

[Denis Ovsienko <[e-mail]>]

---- On Thu, 03 May 2018 22:55:37 +0100 Juliusz Chroboczek  wrote ---- 
>> Per each packet: one TS/PC TLV and at least one HMAC TLV (as 7298 explains it) 
>> Per each IHU TLV: one TS/PC sub-TLV (as 7298-bis explains it) 
> 
>> If you read the full I-D and confirm you have done that, I will 
>> appreciate that. 
> 
>I have read the I-D, although I skipped over the parts that merely restate 
>what is in 6126. I still don't understand how you deal with more TC/PC 
>sub-TLVs than can fit in a packet. 

Juliusz, the data item you are referring to is called "TS/PC", and this term has been around since 2012. I have already mentioned this before. Do you understand this leaves an impression of a conversation that is not fully two-way?

Regarding your recent concerns about 7298-bis data items not fitting into output packets, the task of fitting protocol data items into a packet buffer is neither new nor really difficult. This is one of the minor tasks you had done yourself when you authored RFC 6126 and its implementation. Specifically, you managed to place IHU TLVs, which consume either 8 octets (AE 0) or 12 octets (AE 1) or 16 octets (AE 3) into a sending buffer without overflowing it. So far so good for RFC 6126 (same for 6126-bis).

RFC 7298 discusses the additional buffer margin for the [per-packet] TS/PC TLV and HMAC TLV(s) in sufficient detail. Besides the margin, the buffer management remains exactly the same (and same for 7298-bis).

In 7298-bis the [IHU TLV-specific] TS/PC sub-TLV consumes 8 octets, so an IHU TLV now consumes either 16 octets (AE 0), or 20 octets (AE 1) or 24 octets (AE 3). The buffer management task again remains exactly the same, it is just one of its input data items that now comes in a different size.

This way, I am sorry to explain that from my point of view it reads as if you are claiming you do not understand how sending buffer management works in RFC 6126. If this is the case and your assumption is this is a fault of 7298-bis or myself, it is likely wrong.

But the main point is, sending buffer management is not the only or the biggest concern here. The main goal of 7298-bis is to add a true bi-directional exchange proof to 7298. This is exactly the approach you suggested if you remember. I believe the proposed solution achieves that goal, can you prove me wrong in that? If the working group intends to deliver proper quality results, this is one of the unfinished work items on that we could (and should) spend our energy.

-- 

    Denis Ovsienko