John,

Thanks for sharing the usefulness of MAP and its applicability to cable MSOs. 
Glad to read that MAP-T/R being included in the eRouter spec. 

The drafts you mention are at the verge of becoming RFCs, as they are in RFC 
editor queue. Perhaps, another month. 

Cheers,
Rajiv

> On Jun 18, 2015, at 6:41 PM, John Berg <[email protected]> wrote:
> 
> This is my first time posting to the Softwires mailing list and I would like 
> to introduce myself, John Berg, Lead Engineer supporting emerging network 
> technologies projects for CableLabs.  I have been a long term proponent for 
> migration to IPv6 and a long time follower of drafts coming out of this 
> working group, even if this is my first time posting here.  A lot of good 
> work has come out of this group over the years, and a lot of the substance of 
> this work has helped form the standards in many CableLabs specifications.  
> So, I hope to continue to learn from and contribute to this working group 
> going forward.
> 
> My purpose in writing to the mailing list today was to draw attention to some 
> of the work being done around co-existence technologies, particularly MAP-E 
> and MAP-T.  Over the last several years I have seen great progress made by 
> several of our member organizations in the migration to IPv6 only networks.  
> It has also been clear that IPv6 network evolution has outpaced the adoption 
> of IPv6 in home networks, particularly in the various CPE products that would 
> be attached to them.  There is no question that this has bogged down the 
> efforts of operators to migrate to full end to end IPv6 networks.
> 
> In the past year or so, another thing that has become clear is the need to 
> continue to co-exist with IPv4 only devices in the home network.  IPv4 
> exhaustion set aside, there is a clear and imminent need to accommodate IPv4 
> only capable devices in IPv6 only networks.  In fact, several MSOs have come 
> to us asking that we help define new standards that will make IPv4/IPv6 
> co-existence possible, particularly in customer edge devices such as home 
> routers and eRouters.  These new standards must avoid the pitfalls of earlier 
> co-existence technologies that introduced a potential for impacting the user 
> experience.  Enter MAP-E and MAP-T as viable and scalable solutions to this 
> problem.
> 
> CableLabs, with the input of our member organizations, is now aggressively 
> adding requirements to our eRouter specification for MAP-E and MAP-T.  These 
> technologies are viewed as being the quick and near term solution to 
> IPv4/IPv6 co-existence, and the hope is that they can be adopted quickly and 
> in a manner that is seamless to the subscriber.  But although the substance 
> of the MAP IETF draft documents is solid, we find ourselves writing 
> requirements against the current versions of the drafts and not the RFCs.
> 
> Given the urgency with which operators would like to deploy MAP as a solution 
> for IPv4/IPv6 co-existence, CableLabs respectfully requests the Softwires 
> working group to advance the IETF drafts for MAP to RFC status as quickly as 
> possible.  In particular, MAP-E, MAP-T, and MAP DHCP IETF drafts are 
> extremely relevant to defining requirements for edge devices and operator 
> deployment strategies.  We feel that RFC versions of these standards would 
> lead to more stable implementations of MAP in vendor products, and the 
> potential for new or shifting requirements would be greatly reduced or 
> eliminated.  
> 
> Thank you in advance for your consideration of my observations and requests, 
> and I will look forward to my future interaction with this working group.
> 
> Best Regards,
> 
> John Berg
> CableLabs
> Lead Engineer – Network Technologies
> 858 Coal Creek Circle
> Louisville, CO  80027
> 303 661-3882
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to