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 >> À : email@example.com; 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 firstname.lastname@example.org https://www.ietf.org/mailman/listinfo/dmm