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... > 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
