On Wed, Aug 2, 2017 at 4:46 AM, <[email protected]> wrote: > Hello Mirja, > > Thanks for the comments. We will update the document accordingly; please > see inline for resolution. > > Regards, > Pierrick > > > -----Message d'origine----- > > De : dmm [mailto:[email protected]] De la part de Mirja Kühlewind > > Envoyé : lundi 31 juillet 2017 23:49 > > À : The IESG > > Cc : [email protected]; [email protected]; > > [email protected] > > Objet : [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-mag- > multihoming-04: > > (with DISCUSS and COMMENT) > > > > Mirja Kühlewind has entered the following ballot position for > > draft-ietf-dmm-mag-multihoming-04: 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-dmm-mag-multihoming/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > 1) This document should not recommend the use of MPTCP for tunneling, as > TCP- > > in-TCP tunnels are generally not recommend if that can be avoided. > > The document does not recommend such a thing... the document leverages > PMIP (RFC5213) tunneling mechanisms, i.e. IP-in-IP, GRE, ... > > Please remove > > the following part from section 3.2 and leave IP-level tunneling as the > only option: > > „Packet distribution can be done either at the transport level, e.g. > using MPTCP …“ > > > > Ok, we will remove the sentence. But just to clarify: this sentence refers > to MPTCP as packet distribution scheme, not tunneling, i.e. run MPTP over > PMIP tunnels (IP tunnels). This document follows the idea that building > the datapath, with the multiple binding option, is one thing and how to use > the tunnels is another thing.... MPTCP can thus be one of the way to > distribute the traffic across these tunnels; we actually believe that use > existing IETF protocols instead of reinventing hazardous mechanisms... > > I think you are talking about the hybrid access solution that was discussed long time back in BBF. Such a discussion belongs to BANANA group not dmm.
This draft is supposed to be a maintenance draft coming from Netext which is now closed. dmm is not the place to add new functionality such as hybrid access capability to PMIP. Such a capability would require PMIP support at the home gateways which was not agreed upon in BBF. I support Mirja's comment and suggest removing the whole discussion from the draft. Regards, Behcet > > 2) Further the following sentences also in section 3.2 should be revised: > > „For example, high throughput services (e.g. > > video streaming) may benefit from per-packet distribution scheme, > > while latency sensitive applications (e.g. VoIP) are not be spread > > over different WAN paths.“ > > High throughput services only benefit from per-packet scheduling if the > service > > requires higher throughput than one of the links can provide. Also video > streaming > > may not be a good example here because high latency variations can lead > to > > stalls. Therefore in general per-flow scheduling should be recommend for > all > > traffic. It could still be beneficial to schedule flows that require low > latency over the > > link with the lower base latency, or maybe more important lower jitter, > however, > > often it is not known to the network what the requirements on latency > are for a > > given flow. Therefore is should probably be recommended to schedule all > traffic > > on the "better" link (where better can be pre-configured knowledge or > measured) as > > long as the bandwidth of the incoming traffic is smaller than the > bandwidth of the > > that link, and only use a second link (with per-flow scheduling) if the > capacity is > > required. > > > > I agree. However, this document does not aim to recommend ways to steer > traffic over multiple paths. Examples focuses on use-cases from RFC4908 to > which the document inerits. Actually, as per RFC7864 (flow mobility > extension for PMIPv6), leaves possibility to use either per-flow and > per-packet distribution.. use one of this scheme, or both it is an > implementation choice that is out the scope of this document. > > > > 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. > > Good point... > > Section 4.3 states the LMA that does not support multipath binding.SHOULD > replies with the error message: CANNOT_SUPPORT_MULTIPATH_BINDING > > However, if the LMA does not support this spec and, thus, does not support > this error message, the MAG shall not receive the MAG identifier in the PBU > ack. So, that MAG shall thus fall-back to the legacy RFC5213 compliant MAG > behavior. > > We will clarifiy that. > > Why are there two different options? > > What happens if one of the options is present in the Proxy Binding > Update but not > > the other? > > > > The proxy binding update contains the MAG identifier and the multihoming > . The LMA replies with only the MAG identifier option. This is in section > 3.1 (which should be renamed as "protocol overview"), but I confess that it > should be better highlighted....Also, if one option is missing in the PBU, > the behavior should be similar to what it is specified in PMIPv6 RFC5213: > "MISSING_XXX_OPTION" error should be sent by the LMA in the PBA... we will > add this. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Please also clarify the definitions of Interface Label and Binding > Identifier as > > requested by the gen-art review (Thanks Robert!) > > > > > > Yes, of course. > > > _______________________________________________ > > dmm mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmm > > ____________________________________________________________ > _____________________________________________________________ > > 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 >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
