Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS and COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Thanks! Will wait for the next version!

> Am 18.08.2017 um 03:08 schrieb Sri Gundavelli (sgundave) <[e-mail]>:
> 
> Hi Mirja,
> 
> Thank you for your quick feedback. Please see inline …
> 
> 
> 
> On 8/17/17, 6:12 AM, "Mirja Kuehlewind (IETF)" <[e-mail]> wrote:
> 
> <snip> .. keeping only the open issues.
> 
>> 
>>> 
>>> 
>>> 
>>>> 
>>>> 3) This document does not really normative specify the use of the newly
>>>> defined
>>>> options. It only gives an examples but it does not specify normatively
>>>> any
>>>> actions that need to performed on receipt of these options. How does
>>>> the
>>>> MAG
>>>> know if the LMA does not support Multipath binding? An LMA that does
>>>> not
>>>> implement this spec will not send back an error message. Why are there
>>>> two
>>>> different options? What happens if one of the options is present in the
>>>> Proxy
>>>> Binding Update but not the other?
>>>> 
>>> 
>>> 
>>> This is a good point. There is an implicit assumption that the LMA
>>> behavior is consistent with the behavior when dealing with any unknown
>>> options. 
>>> We can put a note that the PBU will rejected with error code 128.
>> 
>> That's good. Are you supposed to resend without the new options if you
>> received 128? And again what happens if only one option is present?
> 
> I will take care of this. Will add considerations on both LMA/MAG behavior
> when there is version incompatibility. Will post a new rev with these
> considerations. But, thank you; we definitely overlooked this part.
> 
> 
> 
> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> Please also clarify the definitions of Interface Label and Binding
>>>> Identifier
>>>> as requested by the gen-art review (Thanks Robert!)
>>>> 
>>> 
>>> Interface label is a static field, Ex: “LTE-Interface”, “my blue
>>> interface”. Traffic policy is tied to this static label,
>>> 
>>> HTTP Flow: Use LTE-Interface, if not available, use “WiFI-Interface”.
>>> Label is tied to a policy; which the MAG and LMA will translate it bind
>>> the flow to a dynamically created tunnel using the CoA from that
>>> interface.
>>> 
>>> Binding identifier is what is dynamically generated and using to
>>> identify
>>> a specific binding on the LMA.
>> 
>> I think this comment was on the way it is described in the draft. Maybe
>> the wording can be further clarified there. Here is the original text
>> from the genart review of Robert Sparks:
> 
> 
> I have looked at both the definitions and I agree it needs to some
> clarification. I will fix this.
> 
> 
> 
> 
>> 
>> "* I still find the definitions of Interface Label and Binding Identifier
>> confusing.
>>  I suspect they _both_ need to be carefully rewritten to make sure they
>> are
>>  definitions of the terms, and not descriptions of the interactions of
>> the two
>>  fields. Why is the Interface Label definition talking so much about
>> binding?
>>  As currently written, that last sentence of the Binding Identifier
>>  definition says  the document says the mobile access gateway assigns
>>  a single unique binding identifier for each of its interfaces. „
>> 
>> 
>> Thanks!
>> Mirja
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>>> 
>>> 
>> 
>