Subject: draft-pfister-6man-sadr-ra - Call for opinions on TLV format and type D host definition

From: Pierre Pfister <[email-masked]>
Date: Mon, 4 May 2015 16:33:25 +0200

Hello everyone,

In order to get draft-pfister-6man-sadr-ra next iteration right, I would like to get a sense of the WG concerning two comments I got after the presentation in Dallas.

These are not big issues in general, but I would rather have opinions now than awkward comments and endless iterations later.

1. Define a type D host.

RFC4191 defines hosts types A,B and C. It would perfectly make sense to define type D hosts (For those hosts that are able to handle Source Address Dependent Routing Information Option - SADRIO).

So, the question is: Should we refer to those hosts as ... ?
  a. "Hosts implementing this specification"
  b. "Type D hosts"" (Which would be properly defined early in the document)

I personally have no strong preference.

2. TLV format - Prefix alignment

The draft defines one new TLV containing two variable length prefix fields.
As a reminder, RA options MUST start and finish at 64bits boundaries.

What is your favorite ?
  a. RA compression:
     Source and Destination prefix would be aligned on 8bits boundaries.
	 This minimizes the amount of wasted bytes (Between 0 and 7 wasted bytes per TLV).
  b. 64 bits Prefix alignment:
     Source and Destination prefixes are both 64bits aligned.
	 This approach wastes between 7 and 21 bytes per TLV (7 of which could be reserved for other use).
  c. 32 bits Prefix alignment:
     Same idea than b but slightly less wasteful.
	 Wastes between 3 and 9 bytes (3 of which can be reserved for other).

3. TLV format - Source prefix length position

It is possible to either put the Source Prefix length as part of the TLV header, or in between the source prefix and destination prefix.

  a. In the TLV header:
     Cleaner, but breaks first prefix alignment (Or creates 3 or 7 reserved bytes).
  b. Between the first and second prefix:
     A bit ugly, but simpler to implement, and less wasteful.
	 Note that this approach changes the wasted bytes values given in previous question (2.)

Currently, my favorite format is the following:

   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     |   Dst Length  |Resvd|Prf|Resvd|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Route Lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Destination Prefix (Variable Length)            |
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Src Length   |     Source Prefix (Variable Length)           |
   +-+-+-+-+-+-+-+-+                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
Note: The source length is placed at the next 8bits boundary after Destination Prefix.
      It can have any alignment depending on the destination prefix length.

Pros:
It ensures Destination Prefix alignment.
It uses the same format as the RIO for first fields and hence greatly simplifies implementation upgrade.
It compresses the TLV as much as possible.

Cons:
No Source Prefix alignment.
Src Length is right in the middle of the TLV.

Thanks,

- Pierre

---

From: Dan Lüdtke <[email-masked]>
Date: Mon, 4 May 2015 17:43:07 +0200

Hi Pierre,

>   b. 64 bits Prefix alignment:
This one.

> Src Length is right in the middle of the TLV.

In my opinion, the cons overweight the pros here. It looks unclean and is not implementation-friendly. I would opt for the “more wasteful” but clearer design.

We thought about that a little and came up with this:  
>    Fields containing prefixes or addresses or lists of such MUST be
>    sized using a multiple of 16 octets.  For example, such a field
>    SHOULD NOT be specified of length smaller than sizeof(struct
>    in6_addr).  Otherwise implementations may be forced to fill the field
>    using inet_pton() or define it to be of variable length, which is
>    strongly discouraged.
Source: https://tools.ietf.org/html/draft-sarikaya-6man-ra-guidelines-00#section-5.5

Cheers,

Dan

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 May 2015 18:34:41 +0200

Le 04/05/2015 16:33, Pierre Pfister a écrit :
> Hello everyone,
>
> In order to get draft-pfister-6man-sadr-ra next iteration right, I would
> like to get a sense of the WG concerning two comments I got after the
> presentation in Dallas.
>
> These are not big issues in general, but I would rather have opinions
> now than awkward comments and endless iterations later.
>
>
> 1. Define a type D host.
>
> RFC4191 defines hosts types A,B and C. It would perfectly make sense to
> define type D hosts (For those hosts that are able to handle Source
> Address Dependent Routing Information Option - SADRIO).
>

Yes, and to reach boundaries it should include Pad1 or PadN options 
(these options are in RFC2460).

> This minimizes the amount of wasted bytes (Between 0 and 7 wasted bytes

Further compression could be to use arbitrary bit positions, not 
necessarily on 8bit boundaries.

But it depends whether this compression level is needed or not.  Often 
it is a temptation to do smart, although not needed.

> It is possible to either put the Source Prefix length as part of the TLV
> header, or in between the source prefix and destination prefix.
>
>    a. In the TLV header:

In the above you would need padding options (Pad1 and PadN of RFC2460).

On another hand, I think the easiest for the programmer is to reserve 2 
128bit regions for the prefixes, and 2 8bit fields for the plengths, 
each anchored at fixes places.  It is easy to program, and easy to specify.

It may waste bandwidth, but maybe it is good to consume bandwith on some 
smart links which are put down automatically if they are not used enough.

On what kinds of links is this technology going to be used?

In all cases, one should make sure that prefixlengths other than 64 are 
not forbidden by design.

Alex

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 4 May 2015 16:50:08 -0500

Dan, Alex, all,

Thanks for the comments.

I submitted one solution to SADR problem with Pierre, it is at:
http://www.ietf.org/id/draft-sarikaya-6man-sadr-ra-01.txt

utilizing the comments given below.

Regards,

Behcet

On Mon, May 4, 2015 at 11:34 AM, Alexandru Petrescu
<[email-masked]> wrote:
> Yes, and to reach boundaries it should include Pad1 or PadN options (these
> options are in RFC2460).
>
>> What is your favorite ?
>>    a. RA compression:
> Further compression could be to use arbitrary bit positions, not necessarily
> on 8bit boundaries.
>
> But it depends whether this compression level is needed or not.  Often it is
> a temptation to do smart, although not needed.
>
>
> 128bit regions for the prefixes, and 2 8bit fields for the plengths, each
> anchored at fixes places.  It is easy to program, and easy to specify.
>
> In all cases, one should make sure that prefixlengths other than 64 are not
> forbidden by design.
>
> Alex
>
>>
>> Pros:

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 5 May 2015 01:00:42 +0200

Dear all,

> http://www.ietf.org/id/draft-sarikaya-6man-sadr-ra-01.txt

I did not give my consent to be put as author of the mentioned document.
Please see my answer to the new draft notification message for further details.

My own current proposal is detailed here: https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-00

Thanks Alex and Dan for the comments so far.

- Pierre

---

From: 神明達哉 <[email-masked]>
Date: Tue, 5 May 2015 09:45:22 -0700

At Mon, 04 May 2015 18:34:41 +0200,

> (these options are in RFC2460).

(not about the main point of this thread but) I don't get it...Pad1 or
PadN options are for Hop-by-Hop or Destination extension headers, not
intended to be used with RA (or any ND in general) options.  But if
you actually meant we'd need some kind of padding to meet the
alignment requirement, that's of course correct (but in that case it's
better not to use Pad1 or PadN to avoid unnecessary confusion).

--
JINMEI, Tatuya

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 May 2015 09:49:31 +0200

> better not to use Pad1 or PadN to avoid unnecessary confusion).

Hi,

Ah, so Pad1 and PadN are exclusively for HbH and DO.

You imply Pad1/PadN outside DO and HbH would bring in confusion.  Maybe. 
  Or it may be a same function to be reused.

And yes, I agree with you and also with what Pierre described - that if 
alignment is needed then padding is needed.

Alex

---

From: Dan Lüdtke <[email-masked]>
Date: Wed, 6 May 2015 11:08:29 +0200

Hi,

This is an implementer speaking: please do align whenever possible. It really makes things much easier to handle and also reduces the possibility of strange, platform-immanent bugs. Unless it is something that is going to be heavily parsed in hardware (like EH or ipv6 header in general) alignment is always worth the effort in standardization.

Thanks

Dan

> On 06 May 2015, at 09:49, Alexandru Petrescu <[email-masked]> wrote:
> 
> You imply Pad1/PadN outside DO and HbH would bring in confusion.  Maybe.  Or it may be a same function to be reused.
> 
> And yes, I agree with you and also with what Pierre described - that if alignment is needed then padding is needed.
> 
> Alex
> 
>> 
>> --
>> JINMEI, Tatuya
> 
>

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 6 May 2015 11:33:24 +0200

Hello Dan,

Thanks for participating in this,

Just to balance your comment, I do implementation too, and I believe programmers are clever enough to deal with variable lengths prefixes.
And I also believe alignment is not that important in software slow-paths (Which is where RAs are parsed).
(Of course I am not even thinking about bitwise shifting. Only 8bit alignment instead of 64bits.)

The thing is we will want some kind of compression anyway. We are not going to put 128bits of zeroes to express a ::/0 prefix.
RIO compression allows 0, 64 or 128 bits long prefix field. This was an easy design decision as the option ends right after anyway.

My point is, if we have this 0/64/128 choice, it is not that much complex to make bytewise compression mandatory.
In the first case you do: byte_length = ((bitlen - 1) / 64) + 8   (sparing you the bitlen==0 case)
In the second case you do: byte_length = ((bitlen - 1)/8) + 1

So there is not much difference on the complexity side.
On the other side, not aligning may require a memcpy. Which is not going to kill your cpu neither.

But this is just my very humble opinion. And such topic is probably subject to religious opinions anyway.
I am hoping we can get more opinions in order to make a clear decision.

Thanks,

- Pierre

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 May 2015 11:57:28 +0200

Le 06/05/2015 11:33, Pierre Pfister a écrit :
[...]
> The thing is we will want some kind of compression anyway. We are not
> going to put 128bits of zeroes to express a ::/0 prefix.

Pierre - are you asking whether or not we agree to encode a prefix in a 
compressed manner, rather than all 128bits?

Alex

  RIO
> compression allows 0, 64 or 128 bits long prefix field. This was an
> easy design decision as the option ends right after anyway.
>
> My point is, if we have this 0/64/128 choice, it is not that much
> complex to make bytewise compression mandatory. In the first case you
> do: byte_length = ((bitlen - 1) / 64) + 8   (sparing you the
> bitlen==0 case) In the second case you do: byte_length = ((bitlen -
> 1)/8) + 1
>
> So there is not much difference on the complexity side. On the other
> side, not aligning may require a memcpy. Which is not going to kill
> your cpu neither.
>
> But this is just my very humble opinion. And such topic is probably
> subject to religious opinions anyway. I am hoping we can get more
> opinions in order to make a clear decision.
>
> Thanks,
>
> - Pierre
>
>> Hi,
>>
>> This is an implementer speaking: please do align whenever possible.
>> It really makes things much easier to handle and also reduces the
>> possibility of strange, platform-immanent bugs. Unless it is
>> something that is going to be heavily parsed in hardware (like EH
>> or ipv6 header in general) alignment is always worth the effort in
>> standardization.
>>
>> Thanks
>>
>> Dan
>>
>>
>>
>>>> At Mon, 04 May 2015 18:34:41 +0200, Alexandru Petrescu
>>>>>> The draft defines one new TLV containing two variable
>>>>>> length prefix fields. As a reminder, RA options MUST start
>>>>>> and finish at 64bits boundaries.
>>>>>
>>>>> Yes, and to reach boundaries it should include Pad1 or PadN
>>>>> options (these options are in RFC2460).
>>>>
>>>> (not about the main point of this thread but) I don't get
>>>> it...Pad1 or PadN options are for Hop-by-Hop or Destination
>>>> extension headers, not intended to be used with RA (or any ND
>>>> in general) options.  But if you actually meant we'd need some
>>>> kind of padding to meet the alignment requirement, that's of
>>>> course correct (but in that case it's better not to use Pad1 or
>>>> PadN to avoid unnecessary confusion).
>>>
>>> Hi,
>>>
>>> You imply Pad1/PadN outside DO and HbH would bring in confusion.
>>> Maybe.  Or it may be a same function to be reused.
>>>
>>> And yes, I agree with you and also with what Pierre described -
>>> that if alignment is needed then padding is needed.
>>>
>>> Alex
>>>
>>>>
>>>> -- JINMEI, Tatuya
>>>
>>>
>>> [email-masked] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Dan Lüdtke <[email-masked]>
Date: Wed, 6 May 2015 12:40:43 +0200

Hi all,

Having either 64 or 128 long prefixes would be a compromise. Everything else seems to complex for too little gain from my point of view. But let me think about that a bit.

> On 6 May 2015, at 11:33, Pierre Pfister <[email-masked]> wrote:
> 

I care more about the bus than the CPU here. But lets discuss that on a different level. What are good reasons for compression in the first place? On links were compression matters, isn’t there already compression below the network layer?

Cheers

Dan

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 6 May 2015 13:13:17 +0200

Hello Alex,

> Pierre - are you asking whether or not we agree to encode a prefix in a compressed manner, rather than all 128bits?
> 

It already is compressed in RIO. It is not mandatory thought. But parsing compressed RIO is mandatory.

Regards,

- Pierre

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 6 May 2015 13:17:30 +0200

Dan,

> I care more about the bus than the CPU here. But lets discuss that on a different level. What are good reasons for compression in the first place? On links were compression matters, isn’t there alr…

I’d say the main motivation is to be conservative in terms of packet size use.
We are adding things to RAs at a quite regular pace. And at some point we will reach the MTU, which is a hard boundary for RAs.
We could rely on jumbo packets, or expect the MTU is going to increase in the coming decade, or that we will simply not reach it anytime soon, but I think we should try to be careful when adding options to RAs. Try not to consume too much packet space.

- Pierre

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 May 2015 13:33:33 +0200

> We could rely on jumbo packets, or expect the MTU is going to increase in the coming decade, or that we will simply not reach it anytime soon, but I think we should try to be careful when adding op…

there’s (unfortunately) precedence for all variants here.
- 16 octets
- pad out to nearest octet
- pad out to nearest 64 bit bounadry

at least I’d like for both prefixes in the option to have the same rules.
my preference is to be consistent with RFC4191’s 0, 8 or 16 octets if at all possible.
that would mean we either would have to replace the preference bits with source prefix length, or insert 7 reserved octets before the source prefix.

my second choice is to pad out to nearest octet.

cheers,
Ole

---

From: Dan Lüdtke <[email-masked]>
Date: Wed, 6 May 2015 14:39:18 +0200

Hi,

> We are adding things to RAs at a quite regular pace. And at some point we will reach the MTU, which is a hard boundary for RAs.

I think it is not at all a hard boundary. I have a draft in the pipeline where even the grouping of multi packet NDP messages is discussed. I will release it as soon as it is ready, hopefully next week.

For the meantime, here is an extract from draft-sarikaya-6man-ra-guidelines-00 that I wrote, which I hope helps clarifying.
> 5.8.  RAs Spanning Over Multiple Packets
> 
> 
>    Due to many and/or large options, a Router Advertisement may not fit
>    into a single packet, such RAs are called RAs spanning over multiple
>    packets.  In this case the router sends multiple Router Advertisement
>    messages with identical ICMPv6 header, filling each of the messages
>    with different options.
> 
>    Note that, if used, the Flags Expansion option as defined in
>    [RFC5175] is present in all Router Advertisement messages with
>    identical ICMPv6 header.

Cheers

Dan

---

From: Dan Lüdtke <[email-masked]>
Date: Wed, 6 May 2015 14:42:11 +0200

Hi,

> there’s (unfortunately) precedence for all variants here.

It wastes the most space, but is easy to implement.

> - pad out to nearest 64 bit bounadry

Requires inet_pton or manual expanding to 128 bit. It’s fine, too, but just not very friendly in terms of implementation. I know that we will have a trade-off in the end, but for now I see not so much value in using smaller fields for that very special application.

Cheers

Dan

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 6 May 2015 23:46:46 +0000 (UTC)

From: Pierre Pfister <[email-masked]>
 To: Dan Lüdtke <[email-masked]> 
Cc: Alexandru Petrescu <[email-masked]>; IPv6 IPv6 List <[email-masked]>; 神明達哉 <[email-masked]> 
 Sent: Wednesday, 6 May 2015, 21:17
 Subject: Re: Padding and draft-pfister-6man-sadr-ra - Call for opinions on TLV format and type D host definition
   
Dan,

/ While I agree with the approach of minimising option size, be aware that an individual RA doesn't have to contain all of the options that the RA announcing router wants to announce, they instead can be spread across multiple RAs to cope with the set of options exceeding the size of a single RA:
RFC4861, "6.2.3.  Router Advertisement Message Content"
"  If including all options causes the size of an advertisement to   exceed the link MTU, multiple advertisements can be sent, each   containing a subset of the options."
/ I think this is also why the Router Lifetme field has no influence of the lifetime of options carried in the RA, and why RA options need to have their own lifetime fields if their values need to age in any way.
/ Regards,Mark.

- Pierre

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 7 May 2015 16:22:09 -0500

> - pad out to nearest octet

This does not require any padding because prefix length is 8 bits anyway.
So I don't understand this choice. Smaller sizes are flags.

> - pad out to nearest 64 bit boundary

I used 32 bit boundary but it is easy to make it 64 bit boundary.

> that would mean we either would have to replace the preference bits with source prefix length, or insert 7 reserved octets before the source prefix.

Before or after? I am using padding after the source prefix.

> my second choice is to pad out to nearest octet.

To make Dan happy maybe we should not use this choice?

Regards

Behcet