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:[email protected]] > Envoyé : mardi 26 juillet 2016 06:09 > À : [email protected]; [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/dmm
