Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt

From: [email-masked]
Date: Sat, 10 Jun 2017 03:33:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations of the IETF.

        Title           : Basic Requirements for IPv6 Customer Edge Routers
        Author          : Jordi Palet Martinez
	Filename        : draft-ietf-v6ops-rfc7084-bis-03.txt
	Pages           : 31
	Date            : 2017-06-10

Abstract:
   This document specifies requirements for an IPv6 Customer Edge (CE)
   router.  Specifically, the current version of this document focuses
   on the basic provisioning of an IPv6 CE router and the provisioning
   of IPv6 hosts attached to it.  The document also covers several
   transition technologies, as required in a world where IPv4 addresses
   are no longer available, so hosts in the customer LANs with IPv4-only
   or IPv6-only applications or devices, requiring to communicate with
   IPv4-only services at the Internet, are able to do so.  The document
   obsoletes RFC 7084.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-03
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc7084-bis-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jun 2017 08:49:14 +1200

Hi,

Looking at this and thinking about some recent discussions, I realised
that I have a basic comment about the scope of this draft, which leads
to suggestions about its title, Abstrac, and Introdcution.

The text in 4.2 "IPv6 End-User Network Architecture" asserts that
"The end-user network architecture for IPv6 should provide equivalent
or better capabilities and functionality than the current IPv4
architecture."

I don't think anybody would disagree with that gial, but the very
next sentence says

"The end-user network is a stub network."

That is no better capability or functionality than IP4. Apart from
NAT, it's the same.

So, naturally, HNCP and homenet is out of scope.

If that is the target for this draft, fine, but then its title, Abstract
and Introduction need rephrasing. Something like:

Title: Requirements for Low-end IPv6 Customer Edge Routers

Abstract:

   This document specifies requirements for a low-end IPv6 Customer Edge (CE)
   router.  Specifically, the current version of this document focuses
   on the basic provisioning of an IPv6 CE router that does not support
   subsidiary routers, and the provisioning of IPv6 hosts attached directly
   to it. ...

1.  Introduction

   This document defines basic IPv6 features for a low-end residential
   or small-office router, referred to as an "IPv6 CE router", in order 
   to establish an industry baseline for features to be implemented on 
   such a minimal router with directly attached IPv6 hosts. CE routers
   intended to support subsidiary IPv6 routers in a more complex 
   residential or office network need additional features such as
   those described in [homenet].  

Regards
   Brian

On 10/06/2017 22:33, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Fred Baker <[email-masked]>
Date: Sat, 10 Jun 2017 13:55:28 -0700

> So, naturally, HNCP and homenet is out of scope.

no hats

I'm not sure how you get from "stub network" to "no HNCP". The residential network is a stub, which is to say it offers no transit services. Enterprise and university networks are also stubs; they offer no transit services. However, they can have a great deal of internal complexity.

Why does making the home offer no transit services preclude HNCP and homenet?

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jun 2017 13:54:20 +1200

> Why does making the home offer no transit services preclude HNCP and homenet?

It doesn't so my phrasing was a bit wrong. The point is that what the
draft describes is services to hosts, not services to hosts and additional
routers. IMHO, that should be made explicit in the title and abstract and
the very beginning of the introduction, even sooner than:

"Automatic provisioning of more
complex topology than a single router with multiple LAN interfaces is
out of scope for this document."

It's a truth in advertising issue, and it needs to leave the door
open for a future spec that does require support for more complex
topologies.

    Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 11 Jun 2017 10:27:57 +0200

Hi Brian,

I don’t think the original intent of the document (even when it was RFC6204 and even before that), was to exclude the support of more complex topologies, but just to make sure that those mechanisms aren’t described in the document itself.

And yes, if that’s the case, I agree that there is some text in the abstract and intro that may preclude the support for HNCP, so this needs to be changed.

I’m trying to confirm that I understand your point correctly, either
1) We have a very basic IPv6-only CE that ONLY allows hosts to connect to it but no other routers behind it.
2) We have non-so-basic IPv6 CE which allows host and automatically provisioned routers behind it.

I’m not making here considerations about transition mechanisms, only if the basic CE, the one that most of the ISPs provide for “free” to the customers, should support automatic provisioning (with HNCP) or not?

Now, do we agree that scenario 1) is unrealistic in the near term? If we still want to define this case, shall it be something like “Minimum Requirements for IPv6-only Edge Routers”, and even not considering IPv4 support at all there … as this may be the case for very simple networks that only need to connect a few sensors and nothing else, etc. This is the case for new networks that are being deployed since the start with IPv6-only in mind, and not considering IPv4 support at all.

And then we can have a more realistic scenario for a “customer oriented” CE, which may have the need to HNCP (other routers may need to be provisioned behind the main one), and has still some apps/devices with IPv4 support (so transition mechanisms need to be supported for those hosts to work in an IPv6-only access link). This may be what we have as our actual “Basic Requirements for IPv6 Customer Edge Routers”.

What do you think?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
Organización: University of Auckland
Responder a: <[email-masked]>
Fecha: domingo, 11 de junio de 2017, 3:54
Para: Fred Baker <[email-masked]>
CC: IPv6 Operations <[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt

    

        Brian

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jun 2017 08:27:02 +1200

> I don’t think the original intent of the document (even when it was RFC6204 and even before that), was to exclude the support of more complex topologies, but just to make sure that those mechanisms…

Fair enough. 
 
> And yes, if that’s the case, I agree that there is some text in the abstract and intro that may preclude the support for HNCP, so this needs to be changed.

Right. I think it's important to set the reader's expectations accurately in
the first hundred words or so.

Also this in 4.2. "IPv6 End-User Network Architecture":
"The IPv6 CE router may be manually configured in an arbitrary
topology with a dynamic routing protocol."
should perhaps be extended to make it clear that HNCP is an option.
 
> I’m not making here considerations about transition mechanisms, only if the basic CE, the one that most of the ISPs provide for “free” to the customers, should support automatic provisioning (with…

Personally, I don't want to encourage 1) because that is, basically, IPv4
with bigger addresses. The future should be 2). But I don't think this draft
is aiming to be a procurement spec for homenet, is it? It's more of a baseline
for 2). And that's fine, as long as nobody reads it and thinks it's the
end of the story.

> Now, do we agree that scenario 1) is unrealistic in the near term? If we still want to define this case, shall it be something like “Minimum Requirements for IPv6-only Edge Routers”, and even not c…

Right, but will those really exist? I have no idea, personally.
 
> And then we can have a more realistic scenario for a “customer oriented” CE, which may have the need to HNCP (other routers may need to be provisioned behind the main one), and has still some apps/…

That would be the "procurement spec for homenet". Are we ready to write that today??

Regards,
    Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 11 Jun 2017 22:37:59 +0200

To make it short:

My main motivation when I started working on this was not being a procurement spec for homenet, but making sure that the actually deploying IPv6-only links with support of IPv4 “as a service” is possible, which is not the case in the market.

After that, I got inputs about the need for homenet, and then got convinced that we should support it. I think that’s feasible just referencing to the HNCP document (as I did), but as you said, you found the intro, and other parts that contradict that.

I’m still for a single document (draft-ietf-v6ops-rfc7084-bis-03), so that will be the right place to correct the text with your suggestions.

Regarding very cheap and simple IPv6-only routers, I think we will have then. There will be scenarios (probably very small homes or apartments) or remote sensor networks, typically with a single link, where they will be needed, and I guess there HNCP is not needed at all. This is the document that I submitted an hour ago.

I’m not saying all those documents should go forward. We should take a decision of what is the way to go …

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
Organización: University of Auckland
Responder a: <[email-masked]>
Fecha: domingo, 11 de junio de 2017, 22:27
Para: <[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt

    Fair enough. 

    

    

    
    
    Regards,
        Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 11 Jun 2017 23:25:46 +0200

Considering your inputs, I’ve summited a “more conservative” version of RFC7084-bis with HNCP support and removing the transition support, which will come in a new document.

https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis4-hncp/

Opinions?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
Organización: University of Auckland
Responder a: <[email-masked]>
Fecha: domingo, 11 de junio de 2017, 22:27
Para: <[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt

    Fair enough. 

    

    

    
    
    Regards,
        Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jun 2017 13:56:31 +1200

Hi Jordi,

I think you are saying that there are several theoretically independent
components here:

#1. A vanilla CE router that simply support an IPv6 provider, and IPv6 hosts
on directly attached /64 subnets.

#2. IPv4 coexistence (with multiple possible solutions on the provider side)

#3. IPv6 subnetting and routing on the customer side (by default, supported
by HNCP and BABEL).

You are proposing three drafts, for cases
#1
#1+#2
#1+#3

You don't have a draft for #1+#2+#3

Have I understood correctly?

If yes, we should perhaps discuss whether that's the best document structure.

Regards
    Brian

Regards
   Brian Carpenter

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 12 Jun 2017 08:58:48 +0200

Hi Brian,

Not exactly:

#2. IPv6 subnetting and routing on the customer side (by default, supported
by HNCP and BABEL).

#3. IPv4 coexistence (this is “diff” from the actual https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ - either #1 or #2, so it will be just coexistentce or coexistence+HNCP. I will cook it today …)

I still believe that only one document should be enough, that will be #1+2+3 and this one is https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/

This was discussed in the list and in the Chicago meeting and I understood we agreed on that … However, if now we don't agree on that (3-4 people voiced against that), then I think we need to choose among #1 OR #2 (those are the 2 ID’s that I submitted yesterday).

So clearly, we need a WG decision if we still agree on what we decided a couple of months ago, or we have now a different view …

Saludos,
Jordi

-----Mensaje original-----
De: Brian E Carpenter <[email-masked]>
Organización: University of Auckland
Responder a: <[email-masked]>
Fecha: lunes, 12 de junio de 2017, 3:56
Para: <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt

    Hi Jordi,

    

    

    
    Regards
        Brian
    
    Regards
       Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jun 2017 08:56:57 +1200

> I still believe that only one document should be enough, that will be #1+2+3 and this one is https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/

Yes, *if* the 3 different aspects are clearly separated. I think that
is a matter of document organisation, not of technical content. Nothing
wrong with including a more formal version of the #1 #2 #3 list in the
Introduction, to make everything clear for the reader.

> This was discussed in the list and in the Chicago meeting and I understood we agreed on that … However, if now we don't agree on that (3-4 people voiced against that), then I think we need to choos…

To me it seems that if the three aspects are clearly separated, then
even people who don't want #2 in particular as a required feature
should be able to agree. Those people just use #1 and #3 to define
their product or procurement spec.

> So clearly, we need a WG decision if we still agree on what we decided a couple of months ago, or we have now a different view …

Yes. 
    Brian