Subject: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00)

From: <[email-masked]>
Date: Thu, 13 Apr 2017 07:49:17 +0000

Hi Fred, 

I agree.

IMO, avoiding to obsolete RFC7084 seems the right approach to follow here. 

Cheers,
Med

> -----Message d'origine-----
> De : Fred Baker [mailto:[email-masked]]
> Envoyé : mercredi 12 avril 2017 19:11
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : STARK, BARBARA H; [email-masked]; JORDI PALET MARTINEZ;
> [email-masked]
> Objet : Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
> 
> 
> > On Apr 12, 2017, at 6:12 AM, [email-masked] wrote:
> >
> > Hi Barbara,
> >
> > Wouldn't just be fine for those ISPs not interested in transition
> mechanisms to continue referring to RFC7084?
> 
> The tricky bit tends to be in how we label the update. If it "obsoletes"
> or "updates" 7084, we mean that any reference to 7084 becomes a reference
> to the new thing, or 7084 plus the new thing. We would need to clearly
> label it so that a procurement could reference 7084 without it, or
> reference 7084 and the new thing separately.
> 
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : STARK, BARBARA H [mailto:[email-masked]]
> >> Envoyé : mercredi 12 avril 2017 14:53
> >> À : BOUCADAIR Mohamed IMT/OLN; [email-masked];
> >> [email-masked]
> >> Cc : [email-masked]
> >> Objet : RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
> >>
> >>> I tend to agree with you but with a slightly different proposal:  pick
> >> ONE
> >>> mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P
> >>> mechanism (MAP-E).
> >>
> >> Because RFC 7084 is also used as a mandatory reference in BBF TR-124
> (used
> >> by telco ISPs to help with CE router RFPs), and most ISPs have no
> interest
> >> in requiring capabilities that are not useful to or relevant in their
> >> deployment, there MUST NOT be any mandatory transition mechanisms
> included
> >> in a 7084-bis.
> >> Barbara
> > _______________________________________________
> > v6ops mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/v6ops

---

From: james woodyatt <[email-masked]>
Date: Thu, 13 Apr 2017 11:59:58 -0700

> IMO, avoiding to obsolete RFC7084 seems the right approach to follow here. 

I prefer to obsolete.

My reasoning: while the various IPv6 service provisioning mechanisms and IPv4 service transition mechanism available have changed and will probably continue to change, the behavior of CE routers in the local area interior routing domain is badly out of date and needs to be revised to include the proposed standards developed in the HOMENET working group.

Also I’d like to declare that I’m in general agreement with the spirit of what Barbara Stark wrote earlier on proposed requirements on the wide-area link interface of the CE router can be introduced in an acceptable revision of RFC 7084. She wrote:

>> For this document to be a true replacement of RFC 7084, it MUST NOT introduce any "MUST" requirements that an operator currently using RFC 7084 (directly or indirectly) does not want in their CE router.
>> 7084-bis MUST NOT interfere with, place undue burden on, or add cost to existing deployments and the CE routers used in those existing deployments. 

Where I might be departing from her on this point (not sure) is that I don’t believe it’s a good idea, or even really possible, to publish RFC 7084-bis without adding some non-recurring costs to the development of new CE routers that implement the more recent HOMENET standards for the LAN interfaces in home networks.

Maybe there are operators that don’t “want” their CE routers to participate in the HNCP distributed consensus protocol on the LAN interface. If there are such operators, then I think it would help to surface their objections sooner rather than later.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: <[email-masked]>
Date: Tue, 18 Apr 2017 07:08:11 +0000

Hi James,

How obsoleting RFC7084 will be different (better?) for homenet vs updating it? Homenet-related requirements will be at best listed as SHOULD in a obsoleted/updated documents.

I like the idea of an update because I allows operators to easily scope their requirements to their particular context.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de james woodyatt
Envoyé : jeudi 13 avril 2017 21:00
À : [email-masked]
Objet : Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00)

On Apr 13, 2017, at 00:49, [email-masked]<mailto:[email-masked]> wrote:

I prefer to obsolete.

My reasoning: while the various IPv6 service provisioning mechanisms and IPv4 service transition mechanism available have changed and will probably continue to change, the behavior of CE routers in the local area interior routing domain is badly out of date and needs to be revised to
include the proposed standards developed in the HOMENET working group.

--james woodyatt <[email-masked]<mailto:[email-masked]>>

---

From: james woodyatt <[email-masked]>
Date: Tue, 18 Apr 2017 11:04:29 -0700

> I like the idea of an update because I allows operators to easily scope their requirements to their particular context.  

Let me come at this from a slightly different angle… if the only community of interest for this document are the operators of internet service distribution networks, and the interests of application developers and consumer-oriented host operating system developers are not to be given any consideration, then why is it even necessary for IETF to be involved? Shouldn’t this work be handed off to some industry consortium, e.g. BBF or CableLabs?

I’m beginning to think I should just object on general principle to publishing this document. Perhaps it would be better to advocate moving RFC 7084 to Historical.

---

From: james woodyatt <[email-masked]>
Date: Tue, 18 Apr 2017 13:12:45 -0700

On Apr 18, 2017, at 11:48, STARK, BARBARA H <[email-masked]> wrote:
> 
> […] I do think that obsoleting RFC7084 with something that is a shopping list isn't very useful to anyone.

I would say it's the opposite of useful. If that’s all this draft can accomplish when published, then I would argue that it should be published by somebody other than IETF. If there is any value to IETF publishing its own guide to the available transition technologies, then it should not be published as an update to, or an obsoleting of, RFC 7084. A simple informational category draft as an Independent Submission is probably a better vehicle.

That said, I’m a little saddened that RFC 7084 cannot be revised to recommend inclusion of the HOMENET protocols. That really does take a lot of wind out of the case for IPv6 in the home appliance networking case.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 18 Apr 2017 18:48:28 +0000

> Let me come at this from a slightly different angle… if the only community of interest 
> for this document are the operators of internet service distribution networks, and the 
> interests of application developers and consumer-oriented host operating system 
> developers are not to be given any consideration, then why is it even necessary for 
> IETF to be involved? Shouldn’t this work be handed off to some industry consortium, 
> e.g. BBF or CableLabs?

> I’m beginning to think I should just object on general principle to publishing this document. 
> Perhaps it would be better to advocate moving RFC 7084 to Historical.

The current RFC 7084 very much took into account the consumer-oriented CE router vendors. CableLabs and BBF had already taken care of their member operators. And RFC 7084 (in its current form) is still very relevant to those devices.

The people pushing for this are representing operators who don’t participate in BBF or have any great influence in CableLabs (I have no idea if they are even members of CableLabs, though I hear CableLabs is doing some work for non-US cable operators).

But I have to say that since the request seems to be to supply these smaller operators with a shopping list of transition technologies they can use as a reference when they go shopping, I think Mohamed’s suggestion of an update instead of -bis makes a lot of sense. I do think that obsoleting RFC7084 with something that is a shopping list isn't very useful to anyone.

Barbara

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2017 11:19:00 +1200

On 19/04/2017 06:04, james woodyatt wrote:
...
> why is it even necessary for IETF to be involved?

Because it's our mission to make the Internet work better? Do you really trust a trade association to do that?

(BTW, I also think the homenet stuff should be listed, at least as desirable, if not recommended.)

    Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 19 Apr 2017 11:40:57 +0200

I think it has been clear that there is no such differentiation among vendors/products for ISPs or retail. Both are the same products, sometimes with OEM labels.

Small and medium, even some times large ISPs from all the world, don’t have the resources to participate in BBF/CableLabs, so the right place to do this is IETF.

This document RFC7084 is being used in many references, so if we declare it historic, I think we may break existing RFQs, etc. and don’t think is the intend. I still believe that obsoleting it is the most reasonable way, if we don’t change to MUST the requirements that were SHOULD, so we don’t break existing references, RFQs, etc.

I think the concept of shopping list comes because, despite implementing 5 instead of 2 doesn’t mean extra code which is something workable for actual products in the market (so even easier for new ones), because most of the code is shared, we have them as SHOULD instead of MUST. Note that I’m not saying we should change that, just explaining why it may look as a shopping list. However, if I’m a vendor, and know that I can implement all them at no extra cost, so I can compete better in the market, will do, right?

Let me to repeat this again. The code needed for LW4o6 is NAT44 plus 4in6, which is the same as for DS-Lite. 6in4 and 6rd use the same code. 464XLAT and MAP-T share the same 4to6 translation, MAP-E uses 4in6. I know it is not so simple as that, but basically is what we have.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 18 de abril de 2017, 20:48
Para: james woodyatt <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00)

    

    
    
    Barbara

**********************************************
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: Hans Liu <[email-masked]>
Date: Wed, 19 Apr 2017 17:51:33 +0800

On Wed, Apr 19, 2017 at 2:48 AM, STARK, BARBARA H <[email-masked]> wrote:

>
>
> The current RFC 7084 very much took into account the consumer-oriented CE
> router vendors. CableLabs and BBF had already taken care of their member
> operators. And RFC 7084 (in its current form) is still very relevant to
> those devices.
>

CE-router is not entirely provided by operators, it is still available in
the retail market. Since RFC 6204, there have been only a few vendors
follow RFC 7084 in their products, and even less submitted their
implementations for IPv6 CE-Router Ready Logo certification.  IMHO, the
more we add into the specification the less vendor gonna follow it. That
then doesn't help IPv6 deployment.   As a CE-router vendor that supports
IPv6 in the retail models, I used to support 6to4, 6in4, and 6rd, all three
of them (and Teredo pass-through, required by "Work with Vista" logo
program. :p) in the router in 2008.  I gradually removed most transition
protocols as I realized they are merely configured and used by users.  I
still don't understand why 9 years later we want to add them back to the
specification?

>
> The people pushing for this are representing operators who don’t
> participate in BBF or have any great influence in CableLabs (I have no idea
> if they are even members of CableLabs, though I hear CableLabs is doing
> some work for non-US cable operators).
>
> But I have to say that since the request seems to be to supply these
> smaller operators with a shopping list of transition technologies they can
> use as a reference when they go shopping, I think Mohamed’s suggestion of
> an update instead of -bis makes a lot of sense. I do think that obsoleting
> RFC7084 with something that is a shopping list isn't very useful to anyone.
>

+1

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 19 Apr 2017 12:00:05 +0200

So, how you will support customers (ISPs and retail) that need a router with IPv6-only in the WAN, but still need IPv4 support in the LANs and to talk to IPv4-only servers in the real Internet?

Do you think this is not a real scenario and will become more and more frequent in the next years, until we get rid-off IPv4?

Even if you only supply (which is not the case as I know), routers to ISPs for big RFQs, you need to realize that end-customers of those ISPs my need a more powerful router than the one delivered by the ISP, or that other ISPs don’t have the purchasing power to do big RFQs, so just go to the retail market and by 10 or 100 units each week or month. This is a reality.

I don’t think adding more, if it is a SHOULD, will make it worst, is a guidance, because you participate in IETF, but there are many ISPs and vendors that don’t do, so they don’t read all the RFCs or understand the need for other transition mechanisms. Including them in this document means they will wake up and read more and then they will decide whatever they want to do, but at least, we provided a guidance in a single document that introduces the “whys and hows”.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Hans Liu <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 19 de abril de 2017, 11:51
Para: "STARK, BARBARA H" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Hans Liu <[email-masked]>, Claire Cheng <[email-masked]>
Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00)

    

    CE-router is not entirely provided by operators, it is still available in the retail market. Since RFC 6204, there have been only a few vendors follow RFC 7084 in their products, and even less submitted their implementations for IPv6 CE-Router Ready Logo certification.  IMHO, the more we add into the specification the less vendor gonna follow it. That then doesn't help IPv6 deployment.   As a CE-router vendor that supports IPv6 in the retail models, I used to support 6to4, 6in4, and 6rd, all three of them (and Teredo pass-through, required by "Work with Vista" logo program. :p) in the router in 2008.  I gradually removed most transition protocols as I realized they are merely configured and used by users.  I still don't understand why 9 years later we want to add them back to the specification?  

    

    
    +1

    Barbara

---

From: Hans Liu <[email-masked]>
Date: Wed, 19 Apr 2017 22:55:37 +0800

On Wed, Apr 19, 2017 at 6:00 PM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> So, how you will support customers (ISPs and retail) that need a router
> with IPv6-only in the WAN, but still need IPv4 support in the LANs and to
> talk to IPv4-only servers in the real Internet?

I'm not standing against all those transition protocols. For retail users,
IMHO, giving them a shopping list doesn't help as most of them don't know
how to get it correctly configured.

>
> I don’t think adding more, if it is a SHOULD, will make it worst, is a
> guidance, because you participate in IETF, but there are many ISPs and
> vendors that don’t do, so they don’t read all the RFCs or understand the
> need for other transition mechanisms. Including them in this document means
> they will wake up and read more and then they will decide whatever they
> want to do, but at least, we provided a guidance in a single document that
> introduces the “whys and hows”.
>

Including them in a single document as a clear guidance definitely will
help CE router vendors during the development. I actually appreciate the
work. However, I don't think that means we should obsolete 7084.

> CC: "[email-masked]" <[email-masked]>, Hans Liu <[email-masked]>,
> Claire Cheng <[email-masked]>
>     The current RFC 7084 very much took into account the consumer-oriented
> CE router vendors. CableLabs and BBF had already taken care of their member
>     CE-router is not entirely provided by operators, it is still available
> in the retail market. Since RFC 6204, there have been only a few vendors
> 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.
>
>
>

-- 
Instead of following the fashion, we lead it through.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 19 Apr 2017 17:25:04 +0200

Hi Hans,

Users will not need to choose, unless the ISP don’t have a provisioning system that does it, or the ISP tells them what to configure (which in some places is still the way it works, unfortunately).

I’ve seen even cases where each router is pre-configured by the ISP before “shipping” it to the customer, or the technician that installs it setup for the customer on-site.

Ideally, the ISP decides which transition mech is going to use in the network, so when user’s plugin the router, it should be configured by the provisioning system.

Regards,
Jordi

-----Mensaje original-----
De: Hans Liu <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 19 de abril de 2017, 16:55
Para: <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00)

    On Wed, Apr 19, 2017 at 6:00 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:

    I'm not standing against all those transition protocols. For retail users, IMHO, giving them a shopping list doesn't help as most of them don't know how to get it correctly configured.  

    
    Including them in a single document as a clear guidance definitely will help CE router vendors during the development. I actually appreciate the work. However, I don't think that means we should obsolete 7084.  

    Regards,
    Jordi

    -----Mensaje original-----
    De: v6ops <[email-masked]> en nombre de Hans Liu <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: miércoles, 19 de abril de 2017, 11:51
    Para: "STARK, BARBARA H" <[email-masked]>
    CC: "[email-masked]" <[email-masked]>, Hans Liu <[email-masked]>, Claire Cheng <[email-masked]>
    Asunto: Re: [v6ops] Obsolete or Update (RE: LISP support for draft-ietf-v6ops-rfc7084-bis-00)

    

    

    
        +1

        Barbara