Subject: [Softwires] introduction and endorsement for MAP

From: John Berg <[email-masked]>
Date: Thu, 18 Jun 2015 22:40:31 +0000

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 18 Jun 2015 22:56:38 +0000

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-masked]> wrote:
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Mark Townsley <[email-masked]>
Date: Thu, 25 Jun 2015 18:00:53 +0200

John,

Here is a link to the cluster of documents that I believe you are looking
to have RFC numbers for:

http://www.rfc-editor.org/cluster_info.php?cid=C247

IIRC, at least back when I was AD, it was possible to request RFC numbers
in advance as long as they were in the Editor's queue (past all WG, IESG,
and IETF approvals). I've cc'd the softwires AD and the RFC Editor here as
they would be the ones that could make that happen if it is still possible.
Of course, it will be important in the cablelabs documents to only use the
RFC number as a placeholder until the RFC is actually available.

As for how long it will take with the normal process, you may draw your own
conclusions here:

http://www.rfc-editor.org/all_clusters.php
http://www.rfc-editor.org/CurrQstats.txt

Pro tip: If you reference a draft using the tools.ietf.org website without
a specific version number, it will automatically reflect the RFC number and
a link to it once the RFC is finally published. e.g.,

https://tools.ietf.org/html/draft-ietf-softwire-map-dhcp

It could be better though, as while you will get the link to the RFC once
it arrives, what you really want is to see the final RFC itself displayed
by default. For example,

https://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd

displays draft-ietf-softwire-ipv6-6rd-10 rather than RFC5969 by default.
I'll open a wish-list ticket to fix that :-)

Hope this helps,

- Mark

> > 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

---

From: RFC Editor <[email-masked]>
Date: Thu, 25 Jun 2015 10:13:38 -0700

Hi John,

If Mark is correct, and if C247
<http://www.rfc-editor.org/cluster_info.php?cid=C247> is the set of
documents in question, note that we expect to have these documents
moved to AUTH48 within the next week.  

The information Mark provided is correct from the RPC perspective
(thanks Mark), but we would ask the the IESG to request expedited
processing, which means that the docs would take priority in our queue
and we could realease the documents (with their assigned RFC numbers)
to AUTH48 more quickly.  This isn't necessary for C247 because the
cluster is about ready to move to AUTH48.

Please let us know if you have any questions.

Thank you,
RFC Editor/sg

On Thu, Jun 25, 2015 at 06:00:53PM +0200, Mark Townsley wrote:
> > > Lead Engineer ??? Network Technologies
> > > 858 Coal Creek Circle
> > > Louisville, CO  80027
> > > 303 661-3882

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 30 Jun 2015 05:02:43 +0000

Hi John,
   Thanks for sharing your experiences. It is great to hear market 
feedback for these specs. As Rajiv and Mark pointed out, these documents 
are on the verge of becoming RFCs. In fact, as of today they entered the 
AUTH48 state which means they will hopefully be published in a matter of 
days rather than weeks. I will keep you posted once the documents are 
published.

Thanks
Suresh

On 06/18/2015 06:41 PM, John Berg wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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

---

From: John Berg <[email-masked]>
Date: Tue, 30 Jun 2015 23:29:34 +0000

Thank you Suresh and others who have responded to my inquiry.  This is
very good news and I am happy to hear these will become RFCs soon.  MAP is
being viewed as the most favorable solution for IPv4/IPv6 co-existence by
operators who have deployed extensive IPv6 only networks.  The benefit of
this technology is a great step to move the industry forward.

Best Regards,

John Berg

CableLabs
Lead Engineer  Network Technologies
858 Coal Creek Circle
Louisville, CO  80027
303 661-3882

On 6/29/15 11:02 PM, "Suresh Krishnan" <[email-masked]>
wrote:

>> Lead Engineer  Network Technologies
>> 858 Coal Creek Circle
>> Louisville, CO  80027
>> 303 661-3882
>