Re: [Softwires] Provisioning Format for CPE BR/lwAFTR Address

[<[e-mail]>]

Hi Rajiv,

Please see inline.

Cheers,
Ian



On 26/04/2013 18:13, "Rajiv Asati (rajiva)" <[e-mail]> wrote:

>Hi Ian,
>
>Please see inline,
>
>> [ian] I'm also not sure about the need for this (I certainly don't plan
>>to
>> use it), but it's been raised. Do any other operators see a need for
>>this
>> in their architecture?
>
>Thanks for posing this Q to the other operators (and sharing your view).

[ian] It would be great if some other operators would share!

>
>
>
>> [ian] MAP-E & lw4o6 both need a /128 for the concentrator (whether this
>>is
>> supplied as a prefix or an FQDN) and will not work without this. MAP-T
>>can
>> not have a /128 prefix for the DMR (/96 is the longest). MAP-E & lw4o6
>> wouldn't work if they were provisioned with a MAP-T DMR compatible
>>prefix.
>> MAP-T wouldn't work if it was provisioned with a MAP-E / lw4o6 DMR
>> compatible prefix. It makes sense to have a single option/sub-option for
>> provisioning MAP-E and lw4o6 BRs and use a separate option/sub-option
>>for
>> MAP-T.
>
>If the same option provides prefix-length and prefix, then MAP-E, -T and
>lw4o6 can leverage it accordingly. This is how MAP-DHCP already does it
>(for MAP modes) and could be exploited to include lw4o6.
>
>This kinda approach is widely used in other protocols:
>
>IPv6 RA PIO - http://tools.ietf.org/html/rfc4861#section-4.6.2
>MPLS OAM - http://tools.ietf.org/html/rfc4379#section-3.2.2

[ian] Certainly it works. My problem here is how we can align all of the
different softwire approaches with the Unified CPE model of using the
presence or absence of the options to define which sw mode to configure?
MAP (E&T) use the DMR + an 8 bit flags field. A single DMR sub-option,
with the flag telling the CPE how to interpret it.

What would be more in line with the unified CPE model (and in line with
what's in 
http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11#section-5.2)
 would be to break out the MAP-T DMR and the MAP-E/lw4o6 DMR into
different sub-options and use their presence or absence to tell the CPE
which softwire mode use, rather than the current flags field that only has
a single option.

I don’t really like this mixed approach of 'option presence' for some
softwire modes and flags for others. I really think that we need to align
on a single approach here (the one in the Unified CPE draft).

>
>
>Cheers,
>Rajiv
>
>
>-----Original Message-----
>From: Ian Farrer <[e-mail]>
>Date: Friday, April 26, 2013 11:52 AM
>To: Rajiv Asati <[e-mail]>, Ole Troan <[e-mail]>
>Cc: Softwires-wg list <[e-mail]>
>Subject: Re: [Softwires] Provisioning Format for CPE BR/lwAFTR Address
>
>>Hi Rajiv,
>>
>>Thanks for your response. Comments in line.
>>
>>Cheers,
>>Ian
>>
>>
>>
>>On 26/04/2013 17:12, "Rajiv Asati (rajiva)" <[e-mail]> wrote:
>>
>>>
>>>I really don't see the need for having to specify more than one BR
>>>prefixes (of whatever length) inside a single MAP domain. Let alone FQDN
>>>or list of IP addresses.
>>>
>>>The reason is that having multiple BR prefixes in the same domain would
>>>at
>>>best allow the upstream traffic to go to different BR. But it would
>>>nothing to differentiate the downstream traffic, as it can come from any
>>>BR. So, load-splitting would be very poor and yield no benefit. As far
>>>as
>>>availability is concerned, then any casting is already good enough.
>>>
>>>After all, most 6rd deployments stick with a single BR prefix.
>>
>>[ian] I'm also not sure about the need for this (I certainly don't plan
>>to
>>use it), but it's been raised. Do any other operators see a need for this
>>in their architecture?
>>
>>>
>>>
>>>Lastly, it would be a severe mistake of ours to limit the BR to a prefix
>>>of /128 length. As few other operators (e.g. Reliance) have already
>>>noted
>>>their use of MAP-T, it would be prudent for the same provisioning option
>>>to work with it. Thankfully, this is correctly specified in the map-dhcp
>>>draft.
>>
>>[ian] MAP-E & lw4o6 both need a /128 for the concentrator (whether this
>>is
>>supplied as a prefix or an FQDN) and will not work without this. MAP-T
>>can
>>not have a /128 prefix for the DMR (/96 is the longest). MAP-E & lw4o6
>>wouldn't work if they were provisioned with a MAP-T DMR compatible
>>prefix.
>>MAP-T wouldn't work if it was provisioned with a MAP-E / lw4o6 DMR
>>compatible prefix. It makes sense to have a single option/sub-option for
>>provisioning MAP-E and lw4o6 BRs and use a separate option/sub-option for
>>MAP-T.
>> 
>>
>>
>>>
>>>Cheers,
>>>Rajiv
>>>
>>>
>>>-----Original Message-----
>>>From: Ole Troan <[e-mail]>
>>>Date: Friday, April 26, 2013 4:39 AM
>>>To: Ian Farrer <[e-mail]>
>>>Cc: Softwires-wg list <[e-mail]>
>>>Subject: Re: [Softwires] Provisioning Format for CPE BR/lwAFTR Address
>>>
>>>>Ian,
>>>>
>>>>> Sorry to dig this one up again, but although there has been a fair
>>>>>bit
>>>>>of discussion around the topic, I don't think that we have so far
>>>>>reached an agreement on how to provision sw CPEs with the address of
>>>>>the
>>>>>concentrator for MAP-E and lw4o6. We need to get a final answer on
>>>>>this
>>>>>as there's a few drafts (softwire-unified-cpe, softwire-map-dhcp,
>>>>>softwire-lw4over6) that are relying on it.
>>>>> 
>>>>> To try and summarise what's already out there:
>>>>> The Unified CPE & lw4o6 drafts propose the use of DHCPv6 Option 64
>>>>>(the
>>>>>DS-Lite AFTR FQDN option)
>>>>> Map-dhcp describes the use of the default mapping rule (DMR) to
>>>>>provide
>>>>>the /128 of the BR
>>>>> 
>>>>> I think that it's reasonable to say that both work ­ I.e. They
>>>>>contain
>>>>>enough information to provision the client with the /128 of the
>>>>>concentrator so that it can send traffic.
>>>>> 
>>>>> Here are the arguments for/against each that I've seen. I've tried to
>>>>>list all the ones that I've seen, so if I've missed any, then please
>>>>>add
>>>>>them:
>>>>> 
>>>>> DHCPv6 Option 64
>>>>> Pros
>>>>> FQDN means that DNS round-robin load balancing could be used
>>>>
>>>>RFC6334 specifies that only the first AAAA should be used.
>>>>
>>>>> Reuse of an existing option
>>>>> 
>>>>> Cons
>>>>> Can not be extended with additional sub-options
>>>>
>>>>the CE needs to deal with DNS TTL and the added complexity of having
>>>>the
>>>>resulting "lifetime" of the
>>>>default router be different than the lifetime of the address/mechanism.
>>>>
>>>>only one BR can be configured
>>>>
>>>>> map-dhcp DMR
>>>>> Pros
>>>>> Option has an 'encapsulated options' field, so could be extended with
>>>>>additional functionality (although no additional functionality has
>>>>>currently been proposed at this stage)
>>>>> 
>>>>> Cons
>>>>> Only one DMR /128 can be provisioned to a client, so round robin load
>>>>>balancing can't be used
>>>>
>>>>you can use anycast.
>>>>
>>>>> May conflict with the MAP-T (</128 prefix) DMR ­ Could be considered
>>>>>to
>>>>>be out of scope for this discussion, but if we are following the
>>>>>mechanisms described in Unified CPE so that a CPE can work out which
>>>>>SW
>>>>>mode to configure, then a dedicated MAP-T sub-option (not shared by
>>>>>any
>>>>>other mode) is needed. This is related to conversations that I've had
>>>>>around extending the Unified CPE model for other softwire approaches.
>>>>> 
>>>>> My view: If there is additional functionality required in this
>>>>>option,
>>>>>over an above the provisioning of a /128 prefix for the concentrator,
>>>>>then the MAP DMR (limited to MAP-E) is the clear choice. However, if
>>>>>no
>>>>>such functionality is needed, then we should re-use Option 64.
>>>>
>>>>does anyone know why a FQDN (with restrictions) was chosen for DS-lite?
>>>>
>>>>considerations:
>>>> - MAP: should BR be inside or outside of the domain. if inside use an
>>>>IPv4 address, if outside use an IPv6 address.
>>>>   (I believe we have agreed on outside, and for LW46 it must always be
>>>>outside).
>>>> - should the CE have multiple BRs? and if so, what should it do
>>>>between
>>>>them? load-balance?
>>>>   the choice in 6rd was to allow for multiple BRs, but not specify how
>>>>multiple BRs could be used
>>>>
>>>>my preference is for a simple list of IPv6 BR addresses. i.e. none of
>>>>the
>>>>two above options.
>>>>
>>>>cheers,
>>>>Ole
>>>>_______________________________________________
>>>>Softwires mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/softwires
>>>
>>
>