Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Barbara,

I’m trying to understand what was the goal for the original document. You mention “retail vendors”.

Not being a native English speaker I really feel that I’m in the limit to understand correctly what is a “retail” vendor and what are the other types, so to understand what makes them different in terms of requirements.

At this way I think we can take a better decision if we want a single document or separate ones.

Regards,
Jordi
 

-----Mensaje original-----
De: "STARK, BARBARA H" <[e-mail]>
Responder a: <[e-mail]>
Fecha: martes, 21 de febrero de 2017, 20:19
Para: "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Asunto: RE: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

    Some of my thoughts on things that have been said ...
    
    > ... vendors need a very strong signal here, otherwise, many of them (and this is happening), are reading actual 7084 and only reacting to implement those transition technologies with specific firmware versions for “very big” customers which will buy several hundred thousand units in one shot.
    
    I'm not aware of any vendors *who sell to ISPs* and use RFC 7084 as the basis for what they put in their firmware. Most such vendors use BBF TR-124 or CableLabs CE Router specs. As an author of RFC 7084, I really saw this RFC as targeting the retail vendors. That was my reason for working on it. If all I needed was requirements for vendors to ISPs, BBF TR-124 would have been sufficient. 
    I do sympathize with the small ISPs. I just wonder if this is the right way to do it. I wonder if a completely new (not modified RFC 7084) draft whose intent is clearly stated as being to specify additional transition functionality needed by many small ISPs might be a better approach. It might be good to strategize on the best way to achieve this desired goal, rather than first discussing what requirements are MUST/SHOULD/MAY. And also agree on this as the goal of a new draft.
    It may be more effective to have a small targeted draft that says "do mandatory dual stack parts of RFC 7084; and here is additional transition technology that many small ISPs need to be able to get from their vendors". 
    We would need a number of smaller ISPs to join in support, if it's to be successful. And the set of requirements definitely need to be limited.
    If that were the focus of the draft, I wouldn't bother including 6rd at all.
    
    > And AT&T has a very large 6rd deployment, so I wouldn't be surprised to see push back from them on downgrading 6rd to MAY (though perhaps they don't much care, idk).
    
    At this point, for me, it's a "don't care". When deployment first started, there was a distinct percentage of AT&T customers who had no (and no option for) AT&T-provided CE Router (because of a legacy broadband architecture in the southeast US). As I mentioned, RFC 7084 was about retail and not ISP-procured CE routers -- so having 6rd in retail routers provided these customers (including me) a way to get 6rd up and running on AT&T. Over the past 1.5 years, AT&T has put FTTH in place for almost all (or maybe by now all) those customers, which means AT&T CE routers are available (and for FTTH, required). You can't even find the 6rd configuration info on the AT&T website anymore. [You can still find the info where other people have posted it. Just not from AT&T.] 
    I do have my own CE router behind the AT&T CE router. The AT&T CE router provides a /64 from the 6rd /60 via IA_PD to my router. So it looks to my router like native IPv6.
    AT&T configured and enabled 6rd, LAN-side SLAAC, and LAN-side DHCPv6 IA_PD in the AT&T CE Router, without my doing anything.
    
    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.