Subject: Adoption call of draft-boucadair-6man-prefix-routing-reco for 6MAN

From: Ole Troan <[email-masked]>
Date: Fri, 3 Oct 2014 09:28:04 +0200

All,

The authors have requested an adoption call for this document as a standards track document.

Please provide a view with reasons as to whether the WG should adopt this or not.

This message starts a one week 6MAN Working Group call on adopting:

	Title           : IPv6 Prefix Length Recommendation for Forwarding
	Author(s)    : M. Boucadair, A. Petrescu
	Filename    : draft-boucadair-6man-prefix-routing-reco-02
	Pages        : 4
	Date          : 2014-09-24

http://tools.ietf.org/html/draft-boucadair-6man-prefix-routing-reco-02

The call ends on October 10th, 2014.

Regards,

Bob Hinden & Ole Trøan

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Oct 2014 17:07:17 +0900

> Please provide a view with reasons as to whether the WG should adopt this

Why does this belong in 6man? There are no protocol changes. Looks like it
should be in v6ops instead.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Oct 2014 14:32:52 +0200

Le 03/10/2014 10:07, Lorenzo Colitti a écrit :
> On Fri, Oct 3, 2014 at 4:28 PM, Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Why does this belong in 6man? There are no protocol changes. Looks like
> it should be in v6ops instead.

In a sense yes - there is no protocol change, because the idea of 
matching on arbitrary prefix lengths is rather an algorithm rather than 
a protocol to be operated;  like what MD5 is to IPsec.

I suppose it could be seen in v6ops as well, provided deployers care 
about it.  Or not.

Alex

---

From: Karsten Thomann <[email-masked]>
Date: Fri, 03 Oct 2014 16:04:52 +0200

Regardless of the discussion if this should be a 6man or v6ops document, I 
don't think it needs an extra document to recommend that the routers should be 
able to route every prefix length, if the routing is not working for every 
prefix length the implementation is in a way broken that I would not call it an 
IPv6 implementation.

To document that there are throughput problems for longer prefixes is nothing I 
would document in a standards track document.

Regards
Karsten

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Oct 2014 08:28:01 +0200

All,

The adoption call for draft-boucadair-6man-prefix-routing-reco for ended October 10th.
With only two replies, none of them in support, I can only conclude that there is no support to adopt this document in 6MAN.

Best regards,
Ole

> On 03 Oct 2014, at 9:28 , Ole Troan <[email-masked]> wrote:
> 
> All,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 13 Oct 2014 16:44:55 +0200

Hello,

I am surprised there is no support in favor of 
draft-boucadair-6man-prefix-routing-reco?

https://tools.ietf.org/html/draft-boucadair-6man-prefix-routing-reco-02

Its main recommendation is:
>    Forwarding decision-making processes MUST NOT restrict by design the
>    length of IPv6 prefixes.  In particular, forwarding processes MUST be
>    designed to process prefixes of any length up to /128, by increments
>    of 1.

What do you think?

Alex

Le 13/10/2014 08:28, Ole Troan a écrit :
> All,
>
> The adoption call for draft-boucadair-6man-prefix-routing-reco for
> ended October 10th. With only two replies, none of them in support, I
> can only conclude that there is no support to adopt this document in
> 6MAN.
>
> Best regards, Ole
>
>
>> Author(s)    : M. Boucadair, A. Petrescu Filename    :
>> draft-boucadair-6man-prefix-routing-reco-02 Pages        : 4 Date
>> : 2014-09-24
>>
>> [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: 神明達哉 <[email-masked]>
Date: Mon, 13 Oct 2014 11:49:36 -0700

At Mon, 13 Oct 2014 16:44:55 +0200,

> >    designed to process prefixes of any length up to /128, by increments

I've been busier for the last couple of weeks and couldn't respond to
the adoption call before the deadline, but I agree this topic is worth
discussing.  I don't have a strong opinion on whether this should
belong to 6man or v6ops (or somewhere else), although v6ops seems to
be slightly better than 6man.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Oct 2014 08:50:32 +1300

>>    designed to process prefixes of any length up to /128, by increments

My view is that this draft is totally correct but that it states the
obvious. (BTW, it's taken for granted in draft-ietf-6man-why64.)

It is pretty clear in the IPv6 addressing architecture (RFC 4291):

"IPv6 unicast addresses are aggregatable with prefixes of arbitrary
 bit-length, similar to IPv4 addresses under Classless Inter-Domain
 Routing."

I suspect the reason for the lack of replies is that people
don't think it's necessary to publish a new standards track RFC
for this.

   Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 13 Oct 2014 20:13:04 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> 
> Hello,
> 

I agree fully with the recommendation of this draft, but I'm not sure what it is contradicting, if anything. Or is it meant just for emphasis?

Bert

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Oct 2014 11:26:58 +0200

Le 13/10/2014 21:50, Brian E Carpenter a écrit :
> obvious.

Yes, it states the obvious.  What easier to get through than the obvious.

It sticks to this obvious even in corner cases such as when longer than 
64 prefixes may induce performance hits.

> (BTW, it's taken for granted in draft-ietf-6man-why64.)

Contrary to the why64 draft where we abstained from making any 
recommendations, this draft does.

>   bit-length, similar to IPv4 addresses under Classless Inter-Domain

I could guess the intention of this paragraph; but because it uses that 
'aggregatable' word I think it may loose substance - it may lead to 
interpretations which dont disallow the 64bit limits.

Besides, the paragraph is about how addresses are aggregated with 
prefixes, whereas the reco draft is about the forwarding. (aggregation 
is opaque to forwarding mechanisms).

> don't think it's necessary to publish a new standards track RFC

Noted.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Oct 2014 11:29:17 +0200

Le 13/10/2014 22:13, Manfredi, Albert E a écrit :
>> -----Original Message----- From: ipv6
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>>
>> Hello,
>>
Its main recommendation is:
>>> Forwarding decision-making processes MUST NOT restrict by design
>>> the length of IPv6 prefixes.  In particular, forwarding processes
>>> MUST be designed to process prefixes of any length up to /128, by
>>> increments of 1.
>>
>> What do you think?
>
> I agree fully with the recommendation of this draft, but I'm not sure
> what it is contradicting, if anything. Or is it meant just for
> emphasis?

Yes, it is meant for emphasis.

Alex

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Oct 2014 11:39:38 +0200

Alex,

> It sticks to this obvious even in corner cases such as when longer than 64 prefixes may induce performance hits.
> 
> Contrary to the why64 draft where we abstained from making any recommendations, this draft does.
> 
> I could guess the intention of this paragraph; but because it uses that 'aggregatable' word I think it may loose substance - it may lead to interpretations which dont disallow the 64bit limits.
> 
> Besides, the paragraph is about how addresses are aggregated with prefixes, whereas the reco draft is about the forwarding. (aggregation is opaque to forwarding mechanisms).

I've trawled through the IPv6 RFCs, and I can't find anything that directly specifies how forwarding is done, apart from the reference to CIDR. RFC1812 is more specific on this for IPv4.

that said, it hasn't been a problem. all the routing protocols handle arbitrary prefix lengths, and as far as I know all the forwarding engines do too.

>> don't think it's necessary to publish a new standards track RFC

taking a document through to RFC publication has a cost. given that there hasn't so far been any problems from not having this document, is probably good enough reason to not publish it.
even though I'm pretty sure this document reflects the consensus of the community. ;-)

cheers,
Ole

---

From: David Farmer <[email-masked]>
Date: Tue, 14 Oct 2014 08:38:33 -0500

> be slightly better than 6man.

Last week was NANOG and ARIN, the call for adoption came out Friday just 
before, well within its shadow and ended the same day as the ARIN 
meeting finished.

I think this is an important issue and needs work.  I also don't have a 
strong opinion if it should be in 6man or v6ops.

In my opinion the 64 bit netmask is an operational or at best an 
operational design issue that has been inappropriately promoted to an 
architectural issue without ever having a clear justification why it 
needs to be considered from architectural point of view.  The Why64 
draft at least provides some real reasons, but even in this draft it is 
clear that IPv6 is schizophrenic about the issue.  More clarity is 
needed, this draft might be that depending where we end up with it.

Thanks.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 15 Oct 2014 11:45:27 -0700

On 10/14/14 2:39 AM, Ole Troan wrote:
> taking a document through to RFC publication has a cost. given that 
> there hasn't so far been any problems from not having this document, 
> is probably good enough reason to not publish it. even though I'm 
> pretty sure this document reflects the consensus of the community. ;-)

I wonder whether the document would be useful to the larger community.

The folks that have spent the last decade (or two) on this and earlier 
mailing list might have a fairly good grasp on how prefix assignment 
plus routing works in IPv6, but as IPv6 gets deployed more widely there 
is a larger community that needs to understand these aspects.

*If* an RFC provides useful information in this area, then it probably 
make sense for us to get it done, even if it would take some work to get 
the document reviewed.

My 2 cents,
    Erik

---

From: Ole Troan <[email-masked]>
Date: Wed, 15 Oct 2014 21:14:14 +0200

>> taking a document through to RFC publication has a cost. given that there hasn't so far been any problems from not having this document, is probably good enough reason to not publish it. even though I'm pretty sure this document reflects the consensus of the community. ;-)
> 
> The folks that have spent the last decade (or two) on this and earlier mailing list might have a fairly good grasp on how prefix assignment plus routing works in IPv6, but as IPv6 gets deployed more widely there is a larger community that needs to understand these aspects.
> 
> *If* an RFC provides useful information in this area, then it probably make sense for us to get it done, even if it would take some work to get the document reviewed.

OK, so I may be to embedded in this to understand what the possible misunderstandings could be.
are these speculations about possible problems in the future, or are there actual problems with the documents today that have led other designers of protocols or implementors to have got it wrong?

as a slight digression, since we're on the topic of forwarding.
IPv6 uses the CIDR (RFC1519/RFC1812) forwarding algorithm. aka longest matching prefix.
if someone is interested there is work in the routing area / homenet on modifying this, and including the source address in the algorithm. Source Address Dependent Routing.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Oct 2014 11:06:09 -0300

Folks,

I have reviewed this document, and support its adoption as a 6man
document provided the following issues are addressed in a next rev:

1) IMO, the document should clearly state what's the problem it is
addressing. My understanding is that this document has been published in
response to 6man discussions where it was noted that some
implementations have performance penalties for prefixes longer than 64.
If that's the case, the very abstract should state that.

2) The current track of this document is "Std Track". But this document
doesn't specify anything new, nor does it formally update any existing
standard. So  would suggest that (either):

 a) The track is changed to "Informational", such that this document
    serves as a kind of "implementation guidance", or,

 b) It clearly states which document it is updating.

Thanks,
Fernando

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Oct 2014 01:37:24 +0900

> With only two replies, none of them in support, I can only conclude
> that there is no support to adopt this document in 6MAN.

yikes.  that would be a damned shame.  this is a simple doc, to the
point, and sadly seems to be needed.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Oct 2014 01:38:39 +0900

> I suspect the reason for the lack of replies is that people don't
> think it's necessary to publish a new standards track RFC for this.

sadly, the whack-a-mole of short compares is very much alive

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Oct 2014 08:02:43 +1300

> sadly, the whack-a-mole of short compares is very much alive

Ack. So is an RFC going to help? (Not being sarcastic: it's a genuine question.)

   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Oct 2014 07:34:36 +0900

> Ack. So is an RFC going to help? (Not being sarcastic: it's a genuine

first, do no harm

and yes a very simple clear statement will help

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Oct 2014 07:58:57 +0900

> please explain.

[ omg, i need to justify my clearly stated opinion.  because it goes
  against two decades of ipv6 ivory towerism? ]

for example:

i know this will be hard to believe in this wonderous day and age of
universal ipv6 deployment, but some vendors actually go around the tcam
twice for long prefixes, creating a non-trivial performance penalty.
some take the slow path.

and about once a month, this discussion swirls around ops groups.
"don't do this because vendor support may not exist or, if it does, it
sucks."

the current documentation is muddy, possibly related to years of muddy
thinking on this issue.  a simple statement making it unequivocally
clear would be quite helpful.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Oct 2014 08:57:08 +0900

[ rant continues ]

just to be a bit clearer.  to me, slaac is a misspelling of a well known
accelerator north of palo attitude.  you want a full on colonoscopy from
a traceroute through my network?

and an enterprise is used to far more control, i.e. dhcp.  but the ietf
faught against dhcpv4 [0], so this is a long story.  look at how long
and hard we denied nats, and how well that worked out.

otoh, slaac might work in most home invironments.  or mobile phones.

randy

--

[0] - would not allow/provide dhcp on the ietf meeting network.  so in
      stockholm, i ran a dhcp server on my laptop in the corner of the
      terminal room.  and that was the end of that.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Oct 2014 13:05:41 +1300

> and yes a very simple clear statement will help

OK, I will +1 for WG adoption then.

   Brian

---

From: Steven Blake <[email-masked]>
Date: Mon, 20 Oct 2014 20:25:47 -0400

> twice for long prefixes, creating a non-trivial performance penalty.

And an IETF document will change this?

There is no free lunch.  Tradeoff is FIB prefix capacity vs. lookup
rate/latency vs. $$.  TCAMs are hot & !cheap.

// Steve

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Oct 2014 09:28:32 +0900

> rate/latency vs. $$.  TCAMs are hot & !cheap.

thanks for your email from the mid-'90s cidr wars.  it reminds me of the
ethernet vendors explaining why 100mb, no 1g, no 10g, no 100g, is too
expensive.

randy

---

From: Fernando Gont <[email-masked]>
Date: Mon, 20 Oct 2014 21:35:42 -0300

> And an IETF document will change this?

One could expect that if a clear statement is made on the topic, this
might make a difference for e.g. compliance suites?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Steven Blake <[email-masked]>
Date: Mon, 20 Oct 2014 21:22:09 -0400

> might make a difference for e.g. compliance suites?

Compliance to what?  The complaint was not about allowed prefix lengths,
it was about forwarding performance.

Here is the meat of draft-boucadair-6man-prefix-routing-reco-03:

---

2.  Recommendation

   Obviously, policies can be enforced to restrict the length of IP
   prefixes advertised within a given domain or in a given
   interconnection link.  These policies are deployment-specific and/or
   driven by administrative (interconnection) considerations.

   This recommendation does not conflict with the 64-bit boundary
   involved when IPv6 stateless address autoconfiguration (SLAAC,
   [RFC4862]) is used on links such as Ethernet [RFC2464].

   Some lookup algorithm implementations (find the prefix matching a
   given destination address) may be affected by this recommendation,
   even more so for IPv6 than IPv4.  The performance of some
   implementations may be degraded when prefix lengths are longer than
   /64.

---

How is *this recommendation* going to dissuade a vendor from
implementing an algorithm that is "faster" for <= 64-bit prefixes,
especially if it allows greater total prefix capacity or lower
cost/power?

Regards,

// Steve