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

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

On 12/06/2017 09:25, JORDI PALET MARTINEZ wrote:
> 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 <v6ops-bounces@ietf.org> en nombre de Brian E Carpenter <brian.e.carpenter@gmail.com>
> Organización: University of Auckland
> Responder a: <brian.e.carpenter@gmail.com>
> Fecha: domingo, 11 de junio de 2017, 22:27
> Para: <v6ops@ietf.org>
> Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt
> 
>     On 11/06/2017 20:27, JORDI PALET MARTINEZ wrote:
>     > 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.
>     
>     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 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?
>     
>     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 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.
>     
>     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/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”.
>     
>     That would be the "procurement spec for homenet". Are we ready to write that today??
>     
>     Regards,
>         Brian
>      
>     > What do you think?
>     > 
>     > Regards,
>     > Jordi
>     >  
>     > 
>     > -----Mensaje original-----
>     > De: v6ops <v6ops-bounces@ietf.org> en nombre de Brian E Carpenter <brian.e.carpenter@gmail.com>
>     > Organización: University of Auckland
>     > Responder a: <brian.e.carpenter@gmail.com>
>     > Fecha: domingo, 11 de junio de 2017, 3:54
>     > Para: Fred Baker <fredbaker.ietf@gmail.com>
>     > CC: IPv6 Operations <v6ops@ietf.org>
>     > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-03.txt
>     > 
>     >     On 11/06/2017 08:55, Fred Baker wrote:
>     >     > 
>     >     > On Jun 10, 2017, at 1:49 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>     >     >> "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.
>     >     > 
>     >     > 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?
>     >     
>     >     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
>     >      
>     >     
>     >     _______________________________________________
>     >     v6ops mailing list
>     >     v6ops@ietf.org
>     >     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.
>     > 
>     > 
>     > 
>     > _______________________________________________
>     > v6ops mailing list
>     > v6ops@ietf.org
>     > https://www.ietf.org/mailman/listinfo/v6ops
>     > 
>     
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org
>     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.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 