Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05

From: <[email-masked]>
Date: Fri, 5 Apr 2013 21:03:33 +0200

Hi,

I have one comment about the current version: It is using an IPv4 default route as the method for sending traffic out of the MAP domain. This is likely to cause provisioning complexity and conflicts with two other related drafts:

1, The unified CPE draft is looking for the presence of a configured BR/AFTR v6 address as the mechanism for whether to configure 'binding mode' (i.e. MAP 1:1 in this case). A v4 default route isn't easily compatible with this.

2, For DHCP based provisioning, the updated OPTION_MAP (described in the unified CPE draft) + RFC6334 give a method for configuring basic softwire functionality using just a DHCPv6 server. This doesn't provide any way of distributing IPv4 default routes. Therefore, to provision a MAP 1:1 client, you would need to deploy the DHCPv4 over DHCPv6 infrastructure just for this single DCHPv4 option. This is, of course assuming that the DHCPv4 over DHCPv6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechanism for v4 over v6 provisioning.

I raised this point in Orlando (See Ole's comment on using RFC6334 as the DMR in the minutes). I think that this change would fix the two points above.

Thanks,
Ian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Dienstag, 26. März 2013 05:23
To: Softwires WG
Cc: Yong Cui; Ralph Droms
Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05

Hi all,
  This message starts a two week softwire working group last call on advancing the draft about providing Mapping of Address and Port with Encapsulation as a Standards Track RFC. The authors believe that this version has addressed all the issues raised on the document. The latest version of the draft is available at

http://www.ietf.org/id/draft-ietf-softwire-map-05.txt
http://tools.ietf.org/html/draft-ietf-softwire-map-05

Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. The chairs will send in their comments as well during the last call period. This last call will conclude on April 9, 2013.

Regards,
Suresh & Yong
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 9 Apr 2013 13:09:38 +0200

Hi Ian,

a default route appears to be by far the best way to model the reachability
of destinations outside of the MAP domain, and actually *any* IP domain
(i.e. this is not a MAP specific aspect).

On 5 April 2013 21:03, <[email-masked]> wrote:

> Hi,
>
> I have one comment about the current version: It is using an IPv4 default
> route as the method for sending traffic out of the MAP domain. This is
> likely to cause provisioning complexity and conflicts with two other
> related drafts:
>
> 1, The unified CPE draft is looking for the presence of a configured
> BR/AFTR v6 address as the mechanism for whether to configure 'binding mode'
> (i.e. MAP 1:1 in this case). A v4 default route isn't easily compatible
> with this.
>

Could you elaborate on what incompatibility you see?
This is a case of an implicit default route (much as is also the norm in
say PPP connections).

>
> 2, For DHCP based provisioning, the updated OPTION_MAP (described in the
> unified CPE draft) + RFC6334 give a method for configuring basic softwire
> functionality using just a DHCPv6 server. This doesn't provide any way of
> distributing IPv4 default routes. Therefore, to provision a MAP 1:1 client,
> you would need to deploy the DHCPv4 over DHCPv6 infrastructure just for
> this single DCHPv4 option. This is, of course assuming that the DHCPv4 over
> DHCPv6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechanism
> for v4 over v6 provisioning.
>

This appears back to front. RFC6334 is naturally the DS-lite AFTR option,
and an AFTR does not equal a BR, (nor a Lw46 gateway). I believe that that
the use of rfc6334 is unnecessary, and the unified CPE does not need to
depend on it, esp given that it will need additional options anyway. In
short, it makes little sense for a unified CPE to use both rfc6334 + some
new option.

> I raised this point in Orlando (See Ole's comment on using RFC6334 as the
> DMR in the minutes). I think that this change would fix the two points
> above.
>

IMO The unified CPE notion needs to be fixed (and it is something I have
commented on previously): It's not unification by dumping all the existing
stuff together, but a) a functional rationalization (all solution share the
same functions) and b) a unified configuration method (which likely
excludes things like rfc6334, given its  applicability to only one solution)

Regards,
Woj.

>   This message starts a two week softwire working group last call on
> advancing the draft about providing Mapping of Address and Port with
> Encapsulation as a Standards Track RFC. The authors believe that this
> version has addressed all the issues raised on the document. The latest
> version of the draft is available at
>
> Substantive comments and statements of support/opposition for advancing
> this document should be directed to the mailing list. Editorial suggestions
> can be sent directly to the authors. The chairs will send in their comments
> as well during the last call period. This last call will conclude on April
> 9, 2013.
>
> Regards,
> Suresh & Yong

---

From: <[email-masked]>
Date: Tue, 9 Apr 2013 17:59:26 +0200

Hi Woj,

To (hopefully) prevent a long, cross purpose discussion, could you describe how you see that the BR address should be configured for MAP 1:1? It's described as a possible use case in the appendix, but it only covers how to provision the client, not how it learns the BR.

Thanks,
Ian

From: Wojciech Dec <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 9 April 2013 13:09
To: Ian Farrer <[email-masked]<mailto:[email-masked]>>
Cc: Suresh Krishnan <[email-masked]<mailto:[email-masked]>>, Softwires-wg <[email-masked]<mailto:[email-masked]>>, Yong Cui <[email-masked]<mailto:[email-masked]>>, Ralph Droms <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05

Hi Ian,

a default route appears to be by far the best way to model the reachability of destinations outside of the MAP domain, and actually *any* IP domain (i.e. this is not a MAP specific aspect).

On 5 April 2013 21:03, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Could you elaborate on what incompatibility you see?
This is a case of an implicit default route (much as is also the norm in say PPP connections).

This appears back to front. RFC6334 is naturally the DS-lite AFTR option, and an AFTR does not equal a BR, (nor a Lw46 gateway). I believe that that the use of rfc6334 is unnecessary, and the unified CPE does not need to depend on it, esp given that it will need additional options anyway. In short, it makes little sense for a unified CPE to use both rfc6334 + some new option.

IMO The unified CPE notion needs to be fixed (and it is something I have commented on previously): It's not unification by dumping all the existing stuff together, but a) a functional rationalization (all solution share the same functions) and b) a unified configuration method (which likely excludes things like rfc6334, given its  applicability to only one solution)

Regards,
Woj.

Thanks,
Ian

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Suresh Krishnan
Sent: Dienstag, 26. März 2013 05:23
To: Softwires WG
Cc: Yong Cui; Ralph Droms
Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05

Hi all,

Regards,
Suresh & Yong
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 9 Apr 2013 18:46:34 +0200

Hi Ian,

sure. In the current MAP the BR gets configured via the DMR (as an IP
address) -
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.3
That's not set in stone, but it's a reasonable way of doing things. A name
could be another equivalent way.

Note: The working of this, incl DHCPv6, has been verified in trials also
with the 1:1 mode and hooking up to a DS-lite AFTR, and an issue of
compatibility, which you're voicing a concern about, hasn't come up.

Regards,
Woj.

On 9 April 2013 17:59, <[email-masked]> wrote:

> Hi Woj,
>
> To (hopefully) prevent a long, cross purpose discussion, could you
> describe how you see that the BR address should be configured for MAP 1:1?
> It's described as a possible use case in the appendix, but it only covers
> how to provision the client, not how it learns the BR.
>
> Thanks,
> Ian
>
> From: Wojciech Dec <[email-masked]>
> To: Ian Farrer <[email-masked]>
> Cc: Suresh Krishnan <[email-masked]>, Softwires-wg <
> [email-masked]>, Yong Cui <[email-masked]>, Ralph Droms <
> [email-masked]>
> a default route appears to be by far the best way to model the
> reachability of destinations outside of the MAP domain, and actually *any*
> IP domain (i.e. this is not a MAP specific aspect).
>
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 9 Apr 2013 21:41:35 +0200

Ian,

> To (hopefully) prevent a long, cross purpose discussion, could you describe how you see that the BR address should be configured for MAP 1:1? It's described as a possible use case in the appendix,…

what I meant by an IPv4 default route was something like:

0.0.0.0/0, Tunnel0, 2001:db8::1

i.e. the BR IPv6 address as next-hop.
is that OK?

(the alternative would be an IPV4 address, which would force the BR to have an address within the MAP domain).

cheers,
Ole

> Cc: Suresh Krishnan <[email-masked]>, Softwires-wg <[email-masked]>, Yong Cui <[email-masked]>, Ralph Droms <[email-masked]>

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 10 Apr 2013 15:12:16 +0200

Qi,

the name doesn't matter. It's an IP address, it can be a name, of the BR.
MAP-E talks about that. In the dhcpv6 draft it has been codified as a DMR
and is actually much more flexible than 6334. (feel free to use a name you
feel comfortable with). That said 6334, is an orthogonal discussion - topic
for comments on the dhcp draft.

MAP-E requires the address of a BR to operate and implicitly points a
default route to it, and as much is said in the draft. How it gets that
address is clearly part of provisioning.

The original claim was of some incompatibilities, I'm still wondering what
these are.

Cheers,
Woj.

On 10 April 2013 09:48, Qi Sun <[email-masked]> wrote:

>
> Hi Woj ,
>
> AFAIK, there is no DMR defined in draft-map-05. And for map-e, what a
> 'DMR' DHCPv6 option does is the same as that of RFC6334, both for
> configuring the IPv6 address of the tunnel concentrator. It is convenient
> for the unified CPE to leverage RFC6334 for this configuration, IMHO.
>
>
> Best Regards,
> Qi Sun
>
>
> On 2013-4-10, at 上午12:46, Wojciech Dec wrote:
>
> Hi Ian,
>
>>> I have one comment about the current version: It is using an IPv4
>>> default route as the method for sending traffic out of the MAP domain. This
>>> is likely to cause provisioning complexity and conflicts with two other
>>> related drafts:
>>>
>>> I raised this point in Orlando (See Ole's comment on using RFC6334 as
>>> the DMR in the minutes). I think that this change would fix the two points
>>> above.
>>>
>>

---

From: <[email-masked]>
Date: Wed, 10 Apr 2013 15:12:48 +0200

HI Woj,

Thanks for that. So we actually aren't too far apart. There needs to be a DMR (or equivalent) that has the IPv6 address of the BR.

But, this is one thing that's been confusing me since the publication of (I think v03), where the DMR is no longer described, or mentioned anywhere in the MAP base draft. However it does still exist in the MAP DHCP option draft. But neither of the drafts actually describes what it is and how to use it. The current map 05 draft only discusses the use of an IPv4 route, which I think is misleading – the IPv6 address of the BR is also needed (as Ole's pointed out in his mail).

A DMR, or something functionally equivalent is necessary, but this is not just an IPv4 route. It has to have the v6 address of the BR, used to build a tunnel. The v4 route points then to that tunnel.

So, the reason that I said it's incompatible is that the current text in the MAP base draft doesn't describe any way of getting the v6 address of the BR other than those that can be provided with a BMR and FMRs. I.e. An IPv4 default route with an IPv4 next hop which is in a map domain which the CPE has an FMR for. lw4o6, which doesn't use mapping rules cannot calculate the v6 address of the concentrator from a v4 next hop address.

I realise that this is not how it is meant to work (and you've confirmed that), but this is the only way that you could make it work given the text that is actually in the draft and that's what I think needs to be changed. This would bring the MAP/lw4o6 & unified CPE drafts back in line…

… then we can have the discussion about what the best DHCP mechanism to provision the client with the v6 address of the concentrator is :-)

Cheers,
Ian

Date: Tuesday, 9 April 2013 18:46

Hi Ian,

sure. In the current MAP the BR gets configured via the DMR (as an IP address) - http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.3
That's not set in stone, but it's a reasonable way of doing things. A name could be another equivalent way.

Note: The working of this, incl DHCPv6, has been verified in trials also with the 1:1 mode and hooking up to a DS-lite AFTR, and an issue of compatibility, which you're voicing a concern about, hasn't come up.

Regards,
Woj.

On 9 April 2013 17:59, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Woj,

Thanks,
Ian

Hi Ian,

Regards,
Woj.

Thanks,
Ian

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Suresh Krishnan
Sent: Dienstag, 26. März 2013 05:23
To: Softwires WG
Cc: Yong Cui; Ralph Droms
Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05

Hi all,

Regards,
Suresh & Yong

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Apr 2013 15:20:40 +0200

Ian,

> … then we can have the discussion about what the best DHCP mechanism to provision the client with the v6 address of the concentrator is :-)

please propose text.
the MAP base document does not specify the provisioning mechanism itself.
but it does specify which parameters need to be provisioned.

section 7 states:

For a given MAP domain, the BR and CE MUST be configured with the
   following MAP elements.  The configured values for these elements are
   identical for all CEs and BRs within a given MAP domain.

   o  The Basic Mapping Rule and optionally the Forwarding Mapping
      Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and
      Length of EA bits

   o  The IPv6 address of the MAP BR.

   o  Hub and spoke mode or Mesh mode.  (If all traffic should be sent
      to the BR, or if direct CE to CE traffic should be supported).

section 5.4 states:
   To reach IPv4 destinations outside of the MAP domain, traffic is sent
   to the configured address of the MAP BR.  On the CE, the default can
   be represented as a point to point IPv4 over IPv6 tunnel [RFC2473] to..

would it help you if section 5.4 states the "configured IPv6 address of the MAP BR"?

cheers,
Ole

---

From: <[email-masked]>
Date: Wed, 10 Apr 2013 15:38:03 +0200

Hi Ole,

I think that the change that you've proposed would help. But actually the
worst offender is in section 5:

Port-aware IPv4 entries in the Rules table are installed for all the
Forwarding Mapping Rules and an IPv4 default route to the MAP BR.

What about if this read?:

Port-aware IPv4 entries in the Rules table are installed for all the
Forwarding Mapping Rules and an IPv4 default route via a tunnel to the MAP
BR.

Cheers,
Ian

On 10/04/2013 15:20, "Ole Troan" <[email-masked]> wrote:

>Ian,
>
>> Thanks for that. So we actually aren't too far apart. There needs to be
>>a DMR (or equivalent) that has the IPv6 address of the BR.
>> 
>> But, this is one thing that's been confusing me since the publication
>>of (I think v03), where the DMR is no longer described, or mentioned
>>anywhere in the MAP base draft. However it does still exist in the MAP
>>DHCP option draft. But neither of the drafts actually describes what it
>>is and how to use it. The current map 05 draft only discusses the use of
>>an IPv4 route, which I think is misleading  the IPv6 address of the BR
>>is also needed (as Ole's pointed out in his mail).
>> 
>> A DMR, or something functionally equivalent is necessary, but this is
>>not just an IPv4 route. It has to have the v6 address of the BR, used to
>>build a tunnel. The v4 route points then to that tunnel.
>> 
>> So, the reason that I said it's incompatible is that the current text
>>in the MAP base draft doesn't describe any way of getting the v6 address
>>of the BR other than those that can be provided with a BMR and FMRs.
>>I.e. An IPv4 default route with an IPv4 next hop which is in a map
>>domain which the CPE has an FMR for. lw4o6, which doesn't use mapping
>>rules cannot calculate the v6 address of the concentrator from a v4 next
>>hop address.
>> 
>> I realise that this is not how it is meant to work (and you've
>>confirmed that), but this is the only way that you could make it work
>>given the text that is actually in the draft and that's what I think
>>needs to be changed. This would bring the MAP/lw4o6 & unified CPE drafts
>>back in lineŠ
>> 
>> Š then we can have the discussion about what the best DHCP mechanism to
>>provision the client with the v6 address of the concentrator is :-)
>
>please propose text.

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Apr 2013 09:46:51 +0200

Ian,

> Forwarding Mapping Rules and an IPv4 default route via a tunnel to the MAP

that's not quite correct if we model the MAP domain as an NBMA link which all MAP nodes
are connected to. what about adding similar text to what is in 6rd?

"
   When 6rd is enabled, a typical CE router will install a default route
   to the BR, a black hole route for the 6rd delegated prefix, and
   routes for any LAN side assigned and advertised prefixes.  For
   example, using a CE IPv4 address of 10.100.100.1, a BR IPv4 address
   of 10.0.0.1, an IPv4MaskLen of 8, 2001:db8::/32 as the 6rdPrefix, and
   one /64 prefix assigned to a LAN side interface, a typical CE routing
   table will look like:

     ::/0 -> 6rd-virtual-int0 via 2001:db8:0:100:: (default route)
     2001:db8::/32 -> 6rd-virtual-int0 (direct connect to 6rd)
     2001:db8:6464:100::/56 -> Null0 (delegated prefix null route)
     2001:db8:6464:100::/64 -> Ethernet0 (LAN interface)
"

cheers,
Ole

---

From: <[email-masked]>
Date: Thu, 11 Apr 2013 11:07:20 +0200

Great. That works for me.

Cheers,
Ian