Folks,

No additional comments were received and earlier ones were already addressed in 
-02 revision. The WGLC, which ended a long ago, is now closed. The chairs will 
look into moving the document forward unless there are issues found in the 
chair review or additional discussion raised on the list.

- JOuni & Dapeng


> On Aug 3, 2016, at 1:02 AM, pierrick.se...@orange.com wrote:
> 
> Folks,
> 
> -01 was updated following Danny's review. -02 is here: 
> https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/  
> 
> Below are revision notes.
> 
> 
> Pierrick
> 
>> In section 1 (Introduction):
>> In the paragraph below the 4 bullets change the past tense to present tense:
>> replace - 'This document was introducing the concept.' with - 'This 
>> document is introducing the concept.'
>> 
> 
> Fixed
> 
>> In the lower left side of figure 1, there are two flows: Flow-3 and 
>> Flow-4. There is a typo in the label of flow-4 - it is labeled 'Flow0= -4'. 
>> Please fix.
>> 
> 
> Fixed
> 
>> Below figure 1, the sentence -
>> 'Current version of Proxy Mobile IPv6.', should be:  - 'The current 
>> version of Proxy Mobile IPv6 .'.
>> 
> 
> Fixed
> 
>> And further on in that paragraph, the word 'tunnel' appears twice:
>> '.only one MAG/LMA link, i.e. IP-in-IP tunnel, tunnel can .'.
>> Remove the second one.
>> 
> 
> Fixed
> 
>> And then, an 's' is missing in the word 'overcome'. The sentence - 
>> 'This document overcome this.', should be - 'This document overcomes this.'.
>> 
> 
> Fixed
> 
>> In section 3 (Overview):
>> Please consider adding a description of the call flow. Show what is 
>> happening in each operation and where is the new stuff (i.e. the 
>> creation of the
> second tunnel).
>> The call flow shows two tunnels being created and two delegated 
>> mobile network prefixes assigned to the MAG. But since in both 
>> cases, DMNP is used, it is not clear if both prefixes are the same or 
>> different.
>> I would also recommend to add the terms NAI, MAG-NAI, DMNP, MMB, PBU 
>> and PBA to the terminology section. You don't have to copy the exact 
>> definition from the relevant RFCs, but please provide a short 
>> description and a reference to the RFC in which they were introduced.
>> 
>> It is not clear what are operations (9) and (10).
>> 
>> 
> I have added text. 
>> 
>> The last paragraph of this section offers the feature of selecting 
>> the tunnel that best fits the application that generates the 
>> packets. It is not clear to me how this is possible since the MAG 
>> performs the tunnel selection but it cannot know the applications 
>> that created the packets (and thus, does not have knowledge of the 
>> application's sensitivity to
> throughput, latency etc.).
>> 
> 
> You're pointing out the weakness of that king of solution :-)
> 
> In per-packet IP distribustion scheme, the MAG receives IP packets 
> from the MN and the, selects one of the tunnel to forward IP packets. 
> There are various ways to split the traffic, packets can be 
> distributed sequentially over tunnel interfaces, or you can always 
> forward on a given tunnel (e.g. wifi tunnel) until a given load threshold is 
> reached and then, overflow over the other tunnel (LTE tunnel).
> 
> Then you're right, this distribution scheme introduces latency and it 
> can be disruptive for some applications (eg VoIP) . This is why the 
> system must not use packet distribution for all applications but also 
> rely on usual per-flow distribution used in IP mobility system. The 
> MAG is thus provisioned with IP flow disytribution policy ( using IP flow 
> mobility option) to manage this.
> 
>> In section 4.1 (MAG Multipath-Binding Option):
>> There is a problem with the format of the description of the 
>> different fields of the MAG Multipath-Binding Option. For the first 
>> two fields - Type and Length, the description states their name with 
>> a paragraph defining them. But for all the rest, there are 
>> paragraphs describing the fields without their names at the beginning of 
>> each paragraph.
>> 
> 
> fixed
> 
>> The description of the If-ATT is unclear. It states that 'The mobile 
>> node identifies the label for each of the interfaces.', but my 
>> understanding is that these interfaces are transparent to the mobile 
>> node as they are in the MAG and are managed between the MAG and  LMA.
> 
>> You mean If-label, right? It should be 'The MAG identifies the label 
>> for each of the interfaces."
>> 
>> Further in this description, there is reference to the
>>> Home Agent. Shouldn't it be the LMA?
>> 
> 
> yes
> 
>> In the paragraph describing the If-Label, it is described as 
>> uniquely identifying the specific binding of the mobile node. 
>> Shouldn't it be a specific binding of the MAG?
>> 
> 
> Yes
> 
>> In the description of the B flag, the word flag appears twice: '. if 
>> the value of the Registration Overwrite Flag (O) flag is set.'. 
>> Remove one occurrence.
>> 
>> 
> Ok
>> 
>> Throughout the document there are three actions for IANA labeled:
>> IANA-1, IANA-2 and IANA-4. I recommend to change the labels to 
>> IANA-1, IANA-2
> and IANA-3.
>> 
>> 
> 
> Ok. Thanks.
> 
>> -------------------------
> 
>> -----Message d'origine-----
>> De : Jouni Korhonen [mailto:jouni.nos...@gmail.com]
>> Envoyé : mardi 26 juillet 2016 06:09
>> À : dmm@ietf.org; draft-ietf-dmm-mag-multihom...@ietf.org
>> Cc : 刘大鹏(鹏成)
>> Objet : Re: WGLC #1 for draft-ietf-dmm-mag-multihoming-01
>> 
>> Folks,
>> 
>> I noticed there was a spurious update of the document before the conclusion 
>> of
>> the WGLC. Since we are at the beginning of the WGLC anyway it does not hurt 
>> if
>> you actually review -02 instead of -01. I'll note this in the document 
>> history timeline.
>> 
>> Regards,
>>      Jouni & Dapeng
>> 
>> 7/23/2016, 9:09 PM, Jouni kirjoitti:
>>> Folks,
>>> 
>>> As said during the WG meeting we’ll start the WGLC#1 for draft-ietf-dmm-mag-
>> multihoming-01.
>>> 
>>> The WGLC starts:  7/23/2016
>>>           ends:  8/7/2016
>>> 
>>> Please send your review comments, concerns and support to the list. Please,
>> also make use of the Issue Tracker so that tracking down comments and their
>> resolutions become easier.
>>> 
>>> Thanks,
>>>     Dapeng & Jouni
>>> 
>>> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to