[netext] review - draft-ietf-netext-pmipv6-flowmob-03

["Zuniga, Juan Carlos" <[e-mail]>]

Hi all,

 

These are the comments I have for draft-ietf-netext-pmipv6-flowmob-03:

 

 

 

1.       Introduction:

 

-          I would suggest rewriting the second and third paragraph as
follows:

 

"PMIPv6 allows an MN to connect to the same PMIPv6 domain through
different interfaces.  This document specifies protocol extensions to
Proxy Mobile IPv6 between the LMA and MAGs to enable "flow mobility" and
hence distribute specific traffic flows on different physical
interfaces. It is assumed that an MN IP layer interface can
simultaneously and/or sequentially attach to multiple MAGs, possibly
over multiple media. One form to achieve this multiple attachment is
described in [I-D.ietf-netext-logical-interface-support], which allows
the mobile node supporting traffic flows on different physical
interfaces regardless of the assigned prefixes on those physical
interfaces."

 

 

2.       Terminology

 

-          It should be "FMA - Flow Mobility Acknowledgement" (several
instances throughout the document)

 

 

 

3.1   Use case scenarios

 

-          I would suggest changing the first paragraph as follows:

 

"In contrast to a typical handover where connectivity to a physical
medium is relinquished and then re-established, flow mobility assumes a
mobile node can have simultaneous access to more than one network. In
this specification, it is assumed that the LMA is aware of the mobile
node's capabilities to have simultaneous access to both access networks
and it can handle the same or a different set of prefixes on each
access.  How this is done is outside the scope of this specification."

 

-          The three numbered scenarios are first described at the
initialization point (i.e. attachment), and then the flow mobility use
case is described for each one of them below in the text. This is
confusing, as at first sight it looks like the numbered paragraphs
contain the whole use case description text. I would suggest describing
each scenario in full in each one of the numbered sections (e.g.
scenario 2 should describe the initial attachment and also the flow
mobility use case to make it clear why it needs signaling extensions).
It would also help adding a reference stating that the operational
description will be provided in sections 3.2.1, 3.2.2, etc.

 

-          Rewrite the last paragraph in section 3.1 as follows:

 

"The extensions described in this document support all the
aforementioned scenarios."

 

 

 

3           

3.1           

3.2.1          MN sharing a common set of prefixes on all MAGs 

 

-          Remove the following sentence from the paragraph:

 

"When a multi-interfaced mobile node connects to a PMIPv6-domain, it
performs regular attachment and as a result is able to configure an IP
address (or a set of IP addresses) on the logical interface hiding the
different physical interfaces."

 

-          I believe the following should be a MUST:

 

"In this document a new Handoff Indicator (HI) value ("Attachment over a
new interface sharing prefixes") is defined, to allow the mobile access
gateway indicate to the local mobility anchor that the same set of
prefixes MUST be assigned to the mobile node. The considerations in
Section 5.4.1 of [RFC5213] are updated by this specification as
follows:"

 

-          Suggest promoting the paragraph starting with "As described
in [I-D.ietf-netext-logical-interface-support]..." to the end of section
3.2 (before 3.2.1) and reword as follows:

 

"Both MN and LMA SHOULD have local policies in place that ensure packets
are forwarded coherently for unidirectional and bidirectional
communications. The details about how this consistency is ensured are
out of the scope of this document."

 

-          I believe the following should be a MUST (+ typo):

 

"In case the MAGs need to be configured to support flow mobility because
of packet policing, packet enforcement, charging or similar reasons, the
LMA MUST re-use the signaling defined later in this document to convey
this information."

 

-          In the paragraph starting with "Figure 3 shows the state...",
remove the parenthesis and the text inside.

 

 

 

3.2.2          MN with different sets of prefixes on each MAG 

 

-          I believe the following should be a MUST

 

"If the flow is being moved from its default path (which is determined
by the destination prefix) to a different one, the LMA constructs a Flow
Mobility Initiate (FMI) message.  This message MUST be sent to the new
target MAG, i.e. the one selected to be the used in the forwarding of
the flow..."

 

-          It would probably be clearer to have one section 3.2.1, 3.2.2
and 3.2.3 for each described scenario (1, 2 and 3), even if the text in
the section simply states that the use case is the same as the
next/previous section. It would make it easier to read back and forth in
the document when searching for specific information about a use case.

 

-          Figure4: I would suggest exchanging the order of the optional
FMI/FMA messages after the new flow Y through MAG1, as these messages
are not time-critical.

 

-          Figure 6: I would suggest exchanging the order of the
optional BRI/BRA messages after the new flow Y through MAG2, as these
messages are not time-critical. 

 

-          I believe the following requirements language is needed
(original paragraphs starting with "Optionally, a message can be
sent..."):

 

"Optionally, a Binding Revocation Indication message [RFC5846] with the
P bit set MAY be sent to MAG1 to indicate that this is a revocation of
PMIP prefix(es).  After processing BRI, the source MAG MUST send a
Binding Revocation Acknowledgement (BRA) message back to the LMA.

 

-          Move the paragraph starting with "In case flow mobility is
needed with a finer granularity...") to after Figure 6, and reword with
requirements language as follows:

 

"In case flow mobility is needed with a finer granularity (e.g., flow
level instead of full prefix), a Flow Identification Mobility option
(specified in [RFC6089]) that can convey full flow information MUST be
included in the PBA.  The MAG MAY also include the Flow Identification
Mobility option in the PBU message that it sends to the LMA.  This
serves as a request from MAG to LMA to consider the flow policy rules
specified in the option.  In this case, no prefix is removed from any
MAG because the movement is performed at a flow level."

 

 

4.       Messages

 

-          Add the following sentence to the beginning of the section:

 

"This section defines extensions to the Proxy Mobile IPv6 [RFC5213]
protocol messages"

 

4.1   Flow Mobility Initiate (FMI)

 

-          Replace "acknowledge" by "acknowledgement" in the "Sequence
Number:" description

 

 

 

I hope you find these comments useful.

 

Best regards,

 

Juan Carlos