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

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 10 Jul 2012 15:17:16 -0400

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 10 Jul 2012 22:28:36 +0200

Hi Juan Carlos,

Thanks a lot for your review. I'll take a look at it and post an updated
version of the draft (taking also into account Marco's comments) by this
week.

Thanks,

Carlos

On Tue, 2012-07-10 at 15:17 -0400, Zuniga, Juan Carlos wrote:
> “PMIPv6 allows an MN to connect to the same PMIPv6 domain through
> Proxy Mobile IPv6 between the LMA and MAGs to enable “flow mobility”
> and hence distribute specific traffic flows on different physical
> interfaces.”
> -          It should be “FMA – Flow Mobility Acknowledgement” (several
> “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.”
> 
>  
> 
> 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.
> 
>  
> 
> “The extensions described in this document support all the
> aforementioned scenarios.”
> 
>  
> 
>  
> 
>  
> 
> 3           
> 
> 3.1           
> 
> “When a multi-interfaced mobile node connects to a PMIPv6-domain, it
> different physical interfaces.”
> 
>  
> 
> “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
> 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
> out of the scope of this document.”
> 
>  
> 
> “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…”,
> “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
> (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
> “In case flow mobility is needed with a finer granularity (e.g., flow
> MAG because the movement is performed at a flow level.”
> 
>  
> 
>  
> 
> 4.       Messages
> 
>  
> 
> “This section defines extensions to the Proxy Mobile IPv6 [RFC5213]
> protocol messages”
> 
>  
> 
> -          Replace “acknowledge” by “acknowledgement” in the “Sequence
> Number:” description
> 
>  
> 
>  
> 
>  
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
   GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                IEEE Network Special Issue on
                  Video over Mobile Networks
 http://www.comsoc.org/netmag/call-papers (EXTENDED: July, 31)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 16 Jul 2012 21:16:30 +0200

Hi Juan Carlos,

Please see inline below. Since Marco also made some comments regarding
the draft, and some are related, I've tried to update the document
taking into account both reviews.

> interfaces regardless of the assigned prefixes on those physical
[Carlos] OK, thanks for the proposed text. I've modified the draft
re-using most of your proposed text.

> instances throughout the document)
[Carlos] OK, fixed.

> “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…
[Carlos] OK, thanks.

> operational description will be provided in sections 3.2.1, 3.2.2,
[Carlos] OK, thanks. I've tried to implement this change in -04.

> different physical interfaces.”
[Carlos] OK, done.

> Section 5.4.1 of [RFC5213] are updated by this specification as
[Carlos] Fixed.

> out of the scope of this document.”

[Carlos] OK, done.
> document to convey this information.”
[Carlos] Fixed.

> remove the parenthesis and the text inside.
[Carlos] What parenthesis are you referring to?

> forwarding of the flow...”
[Carlos] Fixed.

> in the document when searching for specific information about a use

[Carlos] Done.
> messages are not time-critical.
[Carlos] Done.

> messages are not time-critical. 

[Carlos] Done.
> MUST send a Binding Revocation Acknowledgement (BRA) message back to

[Carlos] Done.
> MAG because the movement is performed at a flow level.”
[Carlos] Done.

> “This section defines extensions to the Proxy Mobile IPv6 [RFC5213]

[Carlos] Done.
> -          Replace “acknowledge” by “acknowledgement” in the “Sequence
[Carlos] Fixed.

> I hope you find these comments useful.

I did indeed. Thanks again for providing them.

Carlos