Thanks a lot Benjamin! We'll implement your wording suggestions in the next revision!
Carlos On Tue, Mar 17, 2020 at 11:39 PM Benjamin Kaduk <[email protected]> wrote: > Hi Carlos, > > Sorry for the slow reply; it's been a crazy couple weeks. > > On Sat, Mar 07, 2020 at 05:55:59PM +0100, CARLOS JESUS BERNARDOS CANO > wrote: > > Hi Benjamin, > > > > Thanks a lot for your comments. Please find below my answers. > > > > On Thu, Mar 5, 2020 at 3:00 AM Benjamin Kaduk via Datatracker < > > [email protected]> wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-dmm-distributed-mobility-anchoring-14: 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-distributed-mobility-anchoring/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > Thanks for discussing the need to secure the various control-plane > > > interactions as part of the Security Considerations. In addition to > the > > > integrity and source-authentication properties already mentioned, we > > > need to say that the control-plane functionality will apply > > > authorization checks to any commands or updates that are made by the > > > control-plane protocol. > > > > > > > [CB] Thanks. I've added that to version -15 (to be submitted soon). > > > > > > > > > > Similarly, I didn't see any discussion of authorization for applying or > > > making changes to the "rules" that are mentioned as needing to be > > > applied by a data-plane node (as mentioned in the COMMENT where I ask > > > for clarification on the nature of such rules). > > > > > > > [CB] Thanks. Even though we have changed a bit the writing to avoid the > > term "rule", we have added some text regarding the use of authentication > > and authorization mechanisms when doing traffic indirection in version > -15. > > > > > > > > > > Also, we should reference RFCs 8221 and 8247 for the current guidance > on > > > IPsec and IKEv2 usage. > > > > > > > [CB] Thanks. Added. > > Thanks! > I think the current placement of these references in the -15 make it sound > like they are references for IPsec and IKEv2 respectively, and not "just" > the best-practices for configuring them. Just moving the references later > in the sentences would probably help, though I'd recommend adding another > sentence "The current guidance for IPsec and IKEv2 usage is given in > [RFC8221] and [RFC8247], respectively" to be fully clear about why they are > being referenced. > > That said, I'm going to change my ballot position to No Objection after I > send this mail, so no need to check back on the precise wording. > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > While I see the value in having this document to crystallize thinking > > > about the various mobility anchoring techniques that are possible, it's > > > not clear to me how much archival value this document would add to the > > > RFC series in the absence of specific protocol mechanisms to implement > > > the functionality described therein. As such, I expect to change my > > > ballot position to Abstain after my Discuss points are resolved. > > > > > > Section 1 > > > > > > When the MN wants to continue using its assigned prefix to complete > > > ongoing data sessions after it has moved to a new network, the > > > network needs to provide support for the MN's IP address -- and > > > > > > The new network, right? > > > > > > > > [CB] The new network and the old one, understanding "old" by the one > > anchoring the prefix used by the MN. That's why we just use the generic > > term "network" without prepending "new". > > Ah, I see now; thanks. > > > Section 2 > > > > > > Anchoring (of an IP prefix/address): An IP prefix, i.e., Home > > > Network Prefix (HNP), or address, i.e., HoA, assigned for use by > > > an MN is topologically anchored to an anchor node when the anchor > > > node is able to advertise a connected route into the routing > > > > > > Is "connected route" a term of art I should be looking up? > > > > > > > > [CB] I agree it's probably better to just use "route". We have changed > this > > in version -15 (to be submitted soon). > > > > > > > and manages the network location information of an MN. The > > > location information may be a binding of the advertised IP > > > address/prefix, e.g., HoA or HNP, to the IP routing address of > the > > > MN or of a node that can forward packets destined to the MN. > > > > > > I assume this ("may be [...] or") is not intended to be an exhaustive > > > list? > > > > > > > [CB] Right. Though the cases listed are the ones I can think of now as > > making sense. But we don't want to close the door for other options that > > might also work there. > > Sometimes a list of two options like this can be misread as intended to be > exhaustive, in which case a phrase like "may be (for example)" can help, or > adding some generic catch-all clause to the end of the list. > > > > > > > > > In a client-server protocol model, location query and update > > > messages may be exchanged between a Location Management client > > > (LMc) and a Location Management server (LMs), where the location > > > information can be updated to or queried from the LMc. > > > > > > nit: s/updated to/updated from/? > > > > > > > [CB] Right, thanks. > > > > > > > > > > Do we want to discuss the authentication/authorization for such > location > > > management functions here? (Including both MN/LMc and LMc/LMs > > > interactions.) > > > > > > > [CB] I've added "secure (i.e., authenticated and authorized)" before > > "location query and update messages may be > > exchanged between [...]" to make it clear that of course these signalling > > needs to be properly secured. I think going into more details there will > > deviate the focus from the main point of this document. Anyway, the > > security considerations section should cover all these parts as well. > > Sounds good, thanks. > > > > > > > > > Section 4 > > > > > > There may be multiple IP prefixes/addresses that an MN can select > > > when initiating a flow. They may be from the same access network or > > > different access networks. The network may advertise these prefixes > > > with cost options [I-D.mccann-dmm-prefixcost] so that the mobile > node > > > may choose the one with the least cost. In addition, these IP > > > > > > This draft has not been updated since 2016. Is it still expected to > > > progress, such that a reference to it remains valuable? > > > > > > > [CB] We use this reference as an example of approach. There are other > > examples that we could reference, but I wanted to give the credit to the > > guys that I think first proposed this. That's why I kept the reference, > but > > I can very easily replace it with another one if you think it would be > > best. > > My personal preference for picking references is biased towards referencing > documents that can be used to build deployable solutions, but I see no flaw > in your reasoning here. > > > > > > prefixes/addresses may be of different types regarding whether > > > mobility support is needed [RFC8653]. A MN will need to choose > which > > > IP prefix/address to use for each flow according to whether it needs > > > IP mobility support or not, using for example the mechanisms > > > described in [RFC8653]. > > > > > > I'm confused. "these prefixes/addresses" seems to refer to the ones > > > advertised by the network, but the question of whether mobility support > > > is needed seems like a matter local to the MN and not a need of the > > > network. (Perhaps the network might *provide* different mobility > > > services for different prefixes/addresses, but that's not what this > text > > > currently says.) > > > > > > > [CB] The prefixes/addresses refer to the one provided by the network. The > > question of whether the MN needs mobility or not is local to the MN, but > if > > the MN actually need it, support from the network might be needed > > (depending on the type of mobility support of the MN and network). I've > > reworded it to: > > > > "In addition, the IP prefixes/addresses provided by the network may be of > > different types regarding whether mobility support is supported [RFC > 8653] > > ." > > > > I hope now the text is clearer. > > I think so, thanks. > > > > > > Section 4.1 > > > > > > I suggest to expand access router or list it in the terminology > section. > > > > > > > [CB] Done (expanded first time it appears in the text). > > > > > > > > > > When IP session continuity is needed, even if a flow is ongoing as > > > the MN moves, it may still be desirable for the flow to change to > > > using the new IP prefix configured in the new network. The flow may > > > then close and then restart using a new IP address configured in the > > > new network. Such a change in the IP address of the flow may be > > > > > > It's perhaps a little confusing, in a rhetorical sense, to talk about > > > "the flow changing to use the new prefix" but doing that by having the > > > flow "close and then restart" -- is it really the same flow after it > has > > > closed? > > > > > > > [CB] You are right. If we are picky with the terminology, the flow is > > indeed different. I've reworded to use "application flow" instead of > > "flow". Hope this is a bit better. Current text (some other small changes > > performed) read as follows: > > > > "When IP session continuity is needed, even if an application flow is > > ongoing as > > the MN moves, it may still be desirable for the application flow to > change > > to > > using the new IP prefix configured in the new network. The application > flow > > may > > then be closed at IP level and then be restarted using a new IP address > > configured in the new network. Such a change in the IP address used by > the > > application flow may be enabled using a higher layer mobility support > which > > is > > not in the scope of this document." > > Thank you! > > > > > > > > > Note that in this scenarios, if there is no mobility support > provided > > > by L4 or above, an application might be able to stop before changing > > > point of attachement, and therefore the traffic would stop. > > > > > > I'm not sure what "might be able to stop" is intended to mean. > > > Regardless, it's quite clear that the traffic will stop upon the > > > mobility event in this scenario, since the network does not provide > > > continuity services! > > > > > > > [CB] That sentence was definitely not good. I've just simplified it to: > > > > "Note that in these scenarios, if there is no mobility support provided > by > > L4 or > > above, application traffic would stop." > > > > which is kind of clear, but I think it doesn't harm keeping it. > > > > > > > Section 4.2 > > > > > > prefix. The latter enables optimized routes but requires some data > > > plane node that enforces rules for traffic indirection. Next, we > > > > > > I'm not sure I understand the role this rule-enforcment is meant to > > > play. What sort of rules would it be enforcing? > > > > > > > [CB] We mean routing updates that enable the anchor mobility. I probably > > used the term "rules" because one example of approach to use in a local > > domain is OpenFlow. I've reworded it to the following: > > > > "The latter enables optimized routes but requires some data plane node > that > > enforces > > traffic indirection." > > > > > > > > > > to AR1 per default routing). The LM and FM functions are > implemented > > > as shown in Figure 6. > > > > > > Where is FM indicated in Figure 6? I cannot find it. > > > > > > > [CB] Ooops. Thanks. Fixed! > > > > > > > > > > Also, should there be any control-plane anchoring indicated in Figure > 6? > > > > > > > [CB] There is the LM part indicated in AR2. > > > > > > > > > > Section 4.3 > > > > > > We focus next on the case where the mobility anchor (data plane > > > function) is changed but binds the MN's transferred IP address/ > > > prefix. This enables optimized routes but requires some data plane > > > node that enforces rules for traffic indirection. > > > > > > [same question as above about the rules] > > > > > > > [CB] Same resolution as before. > > > > > > > > > > IP mobility is invoked to enable IP session continuity for an > ongoing > > > flow as the MN moves to a new network. Here the anchoring of the IP > > > address of the flow is in the home network of the flow (i.e., > > > different from the current network of attachment). A centralized > > > > > > nit(?): this usage of "here" is surprising, in that it seems to discuss > > > the same case as the previous section, and not the new mechanism that > > > we're describing in this section. > > > > > > > [CB] OK, I've removed "here". > > > > > > > > The IP prefix/address anchoring may move without changing the IP > > > prefix/address of the flow. Here the LM and FM functions in Figure > 1 > > > in Section 3.1 are implemented as shown in Figure 7. > > > > > > Where is the FM function indicated in Figure 7? I cannot find it. > > > > > > > [CB] FM is not involved here. I've fixed the text. When we wrote the > text I > > was thinking on a generic way of referring to LM and FM functions, not > > implying that they need to be implemented in all the cases. But I agree > it > > is not very clear. > > > > > > > > > > [I-D.ietf-rtgwg-atn-bgp]. When a mobile associates with an anchor > > > the anchor injects the mobile's prefix into the global routing > > > system. If the mobile moves to a new anchor, the old anchor > > > > > > nit: "mobile node" or just "MN" (twice)? > > > > > > > [CB] Probably better to use MN. I've fixed it. > > > > > > > > > > withdraws the /64 and the new anchor injects it instead. > > > > > > What kind of synchronization and/or serialization is needed between the > > > withdrawl and injection of the /64 in question? > > > > > > > [CB] That'd be part of the control plane signalling, which would depend > on > > the actual solution being used. Since this document does not go into the > > specifics of an actual solution, we don't go further. > > Hmm, okay. > > > > > > > > > Section 5 > > > > > > As stated in [RFC7333], "a DMM solution MUST supportany security > > > > > > nit: s/supportany/support any/ > > > > > > > [CB] Fixed, thanks. > > > > Thanks again for all the good comments. > > And thanks for the updates! > > -Ben >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
