Re: [Softwires] Suresh Krishnan's Discuss on draft-ietf-softwire-multicast-prefix-option-12: (with DISCUSS)

[<[e-mail]>]

Hi Suresh,

Please see inline.

Cheers,
Med

De : Suresh Krishnan [mailto:[e-mail]]
Envoyé : jeudi 2 février 2017 15:00
À : BOUCADAIR Mohamed IMT/OLN
Cc : The IESG; [e-mail]; [e-mail]; Ian Farrer; [e-mail]
Objet : Re: Suresh Krishnan's Discuss on draft-ietf-softwire-multicast-prefix-option-12: (with DISCUSS)

Hi Med,

On Feb 1, 2017, at 7:26 AM, [e-mail]<mailto:[e-mail]> wrote:

Hi Suresh,

Thank you for the review.

Please see inline.

Cheers,
Med


-----Message d'origine-----
De : Suresh Krishnan [mailto:[e-mail]]
Envoyé : mercredi 1 février 2017 00:44
À : The IESG
Cc : [e-mail]<mailto:[e-mail]>; softwire-
[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Suresh Krishnan's Discuss on draft-ietf-softwire-multicast-prefix-
option-12: (with DISCUSS)

Suresh Krishnan has entered the following ballot position for
draft-ietf-softwire-multicast-prefix-option-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast-prefix-
option/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 3:

How can the ASM_mPrefix64 and SSM_mPrefix64 be (variable) as described in
the packet format when the asm-length and the ssm-length MUST be set to
96? Not sure which of these is correct and which is wrong but one of
these things (either the fixed length or the variable prefix) needs to be
fixed.

[Med] The text is correct. The "(variable)" mention in the figure is removed from my local copy.

Sounds good.





* Section 4:

This section contains a bunch of must and may level requirements but
contains the following "disclaimer" text.

"This section is not normative but specifies a set of configuration
guidelines."

Not sure what the intent behind this is. Can you clarify?

[Med] We are not using normative language on purpose because of previous comments we received from some DHC experts (T. Lemon). The use of normative text for the server behavior would mean that we are updating RFC 3315, which we do not want to do. This is why we are defining this section as configuration guidelines.

That reasoning does not help me understand the impacts. What happens when these “guidelines” are not respected by the servers?
[Med] If the server does not follow the guidelines, this will be detected by the client and behave accordingly (covered in Section 5). Let’s consider same sample examples:

·         If the server return an SSM prefix instead of an ASM one, this will be rejected by the IPv4/IPv6 mapping algorithm.

·         If multiple instance of the option having the same scope are returned to the client, the client will ignore the option.

Will the mechanism in the draft still work?
[Med] Yes…because the client (and underlying multicast library) is designed to catch these cases.

Can such a server interoperate with a client that expects the server to follow these guidelines?
[Med] The client DOES NOT expect to always be facing a server that follow the guidelines. The client is designed to cover both cases: “good” servers and badly configured ones. The configuration that is received from a well behaving server will be validated by the client (and underlying multicast library) while mis-configuration will be rejected.

Thanks
Suresh