Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-distributed-mobility-anchoring-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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 <
> [e-mail]> 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