Re: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option

I would suggest:

   - Two options, with different semantics
   - Option format is one IP address per option
   - This means that servers can't send two IP addresses, because that's
   not the format of the option
   - Clients silently discard malformed options (don't need to specify
   this--it's just what clients should do in general)
   - Define the semantics for the case where the client receives both
   options.

On Thu, Jun 9, 2016 at 9:08 AM, Ian Farrer <ianfarrer@gmx.com> wrote:

> HI Ted,
>
> Cheers,
> Ian
>
> On 9 Jun 2016, at 14:34, Ted Lemon <mellon@fugue.com> wrote:
>
> Actually, this is a classic example of what we try to avoid: special
> server behavior for options.   Options are just payload, not protocol,
> unless they are intended to affect the flow of the protocol.   It should
> not be necessary for the server to have special code to support a different
> payload, any more than the TCP stack should have to be modified in order to
> support new extensions to HTTP.
>
> So you could make an operational note about how servers ought to be
> configured, but you should not require that the server check to make sure
> it is configured that way.   You should not require that the server
> understand the semantics of the option--what it means for there to be two
> of them, or what order they should occur in, or what meaning that ordering
> has.
>
>
> [if - So, for the original reason that the point was raised, do you
> suggest that enforcing this only in the client (i.e. if it receives an
> invalid option combination/content then drop all instances) in addition to
> the operation guidance for server config?]
>
>
>
> If you have two different uses for an option, with different semantics,
> you should define two different options, each of which has only one
> semantics.
>
> On Thu, Jun 9, 2016 at 3:44 AM, Ian Farrer <ianfarrer@gmx.com> wrote:
>
>> Hi Med,
>>
>> To be clear, both of the suggestions include the modification to the
>> Section 5 client text? I think this is necessary. But is the error
>> condition that all of the enclosed options are the same scope, or that two
>> or more are?
>>
>> Between the two, I would prefer (1) - a MUST NOT with an exception is a
>> SHOULD NOT. An alternative wording that tries to get the best of both:
>>
>> A server MUST NOT send more than on one instance of OPTION_V6_PREFIX64
>> per scope. Servers MAY send one instance of OPTION_V6_PREFIX64 for each
>> distinct IPv6 multicast prefix with a distinct scope.
>>
>> Thanks,
>> Ian
>>
>> On 9 Jun 2016, at 08:49, mohamed.boucadair@orange.com wrote:
>>
>> Hi Ian,
>>
>> There are two options:
>>
>> (1)
>>
>> Maintain the current text in the draft but add the following text to
>> Section 4:
>>
>>    Servers SHOULD NOT send more than one instance of OPTION_V6_PREFIX64,
>>    except if distinct IPv6 multicast prefixes with distinct scopes are
>>    configured.
>>
>> This is the behavior defined in
>> https://tools.ietf.org/html/rfc6334#section-5/.
>>
>> (2)
>>
>> Add this text in Section 4:
>>
>>    Servers MUST NOT send more than one instance of OPTION_V6_PREFIX64,
>>    except if distinct IPv6 multicast prefixes with distinct scopes are
>>    configured.
>>
>> And modify the text in Section 5 to indicate that the client must discard
>> the options if all enclosed addresses are of the same scope.
>>
>> I agree with you that (2) will help to identify a server error, but with
>> a risk to induce service disruptions.
>>
>> Which one do you prefer to be implemented in the draft?
>>
>> Thank you.
>>
>> Cheers,
>> Med
>>
>> *De :* Ian Farrer [mailto:ianfarrer@gmx.com <ianfarrer@gmx.com>]
>> *Envoyé :* mercredi 8 juin 2016 19:10
>> *À :* BOUCADAIR Mohamed IMT/OLN; Softwires WG
>> *Cc :* dhcwg-chairs@ietf.org
>> *Objet :* Fwd: Problem in draft-ietf-softwire-multicast-prefix-option
>>
>> Hi Med,
>>
>> Forwarding this to the list (the left group mailing addresses were not
>> working earlier).
>>
>> Please see inline below.
>>
>> Thanks,
>> Ian
>>
>>
>> Begin forwarded message:
>>
>> *From: *<mohamed.boucadair@orange.com>
>> *Subject: RE: Problem in draft-ietf-softwire-multicast-prefix-option*
>> *Date: *8 June 2016 16:50:51 CEST
>> *To: *ian Farrer <ianfarrer@gmx.com>, "softwires@ietf.org" <
>> softwires@ietf.org>, Jacni Qin <jacni@jacni.com>, "dxhbupt@gmail.com" <
>> dxhbupt@gmail.com>
>> *Cc: *"dhcwg-chairs@ietf.org" <dhcwg-chairs@ietf.org>
>>
>> Hi Ian,
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>> *De :* ian Farrer [mailto:ianfarrer@gmx.com <ianfarrer@gmx.com>]
>> *Envoyé :* mercredi 8 juin 2016 16:11
>> *À :* softwires@ietf.org; BOUCADAIR Mohamed IMT/OLN; Jacni Qin;
>> dxhbupt@gmail.com
>> *Cc :* dhcwg-chairs@ietf.org
>> *Objet :* Problem in draft-ietf-softwire-multicast-prefix-option
>>
>> Hi,
>>
>> On reviewing this draft I would like to raise a problem with section 5 of
>> the draft. The text is:
>>
>> "If all the enclosed IPv4-embedded IPv6 multicast prefixes have the same
>> scope, the first instance of the option MUST be used."
>>
>> The problem is that this contravenes section 17 of RFC7227:
>>
>> Option order, either the order among many DHCPv6 options or the order
>>
>>    of multiple instances of the same option, SHOULD NOT be significant.
>>
>>    New documents MUST NOT assume any specific option processing order.
>>
>>
>>
>> [Med] That sentence does not assume any (preference) order. It does only provide one way to select one instance among that list. As a reminder, the server is supposed to return one instance (per scope).
>>
>>
>> [if - If the client is taking the first occurrence within the option and
>> attempting to configure it, then it is preferring this option over other
>> instances based on the order in which it occurs in the message.
>>
>> The current text which describes the server behaviour (section 4) does
>> not mention scope at all and does not specify any limitations on the number
>> of instances or criteria for which they may be included - see RFC7227 sec
>> 16.
>>
>> If the server is meant to only return a single instance of the option per
>> scope, but it is sending more than one, then this is a server configuration
>> error. A quasi-random mechanism for the client to try and work around this
>> just means that the configuration error may get masked.
>>
>> As a suggestion, wouldn’t it be better to specify what the valid cases
>> for the server including multiple option instances are and are not (with
>> normative language). The client’s behaviour can then be defined to discard
>> the options if they do not meet this criteria?]
>>
>>
>>
>>
>>
>>
>> I raised this with the DHC WG chairs, and they have a couple of
>> suggestions:
>>
>> 1. Define an encapsulating option - as the data inside an option can be
>> order dependent.
>> 2. Add a “preference” (octet?) and then a client can sort them based
>> on this preference.
>>
>> Thanks,
>> Ian
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>
>