Subject: [netlmm] FW: comments to Sri's draft

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 11 Mar 2007 21:39:52 -0700

Hi Ryuji,

Thanks for the review comments. Please see inline. 

Sri

> -----Original Message-----
> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: Saturday, March 10, 2007 5:46 AM
> To: Sri Gundavelli; Kuntal Chowdhury; Vijay Devarapalli; 
> [email-masked]
> Cc: [email-masked]
> Subject: comments to Sri's draft
> 
> Hi Sri,
> 
> Here are my comments.
> 
> I didn't follow the netlmm ML before the Vidya's consensus call.  Some
> of my comments may be already pointed out...
> 
> * end of P8
> access access authentication procedure -> remove one access
> 

Fixed.

> * P9
> "Upon accepting the Proxy Binding Update request, the mobile access
> gateway sends a Proxy Binding Acknowledgment..."
> -> It must be Local Mobility Anchor instead of mobile access gateway.
>

Yes.

> * What you referred as Policy in the draft can be defined in the
>    terminology section
> 

This was covered briefly in Section 3. But, we can be very specific
and define the base line required for the protocol operation.

> * Section 5.1
>     "o  A flag indicating if IPv6 HoA mobility is accepted.  If this  
> flag
>        is set, the relevant IPv4 HoA fields in this data 
> structure have
>        to be set to the configured values.  If this flag."
> 
>     IPv4 HoA must be IPv6 HoA and the last sentence is incomplete.
> 

Ok. Will fix it.

> * Section 5.1
>     o  The interface id of the tunnel between the local 
> mobility anchor
>        and the mobile access gateway used for sending and 
> receiving the
>        mobile node's traffic.
> 
> Interface ID must be replaced with tunnel identifier.
> Interface ID is too much implementation specific, although in section

True, tunnel as an interface reflects a specific implementation model,
certainly, it can be done differently. We should state that.

> 6.2, the draft uses the tunnel identifier and explains how this can be
> implemented.  I think this sentence must be fixed with the similar way
> of section 6.2
> 

Ok

> 
> * Time Stamp option.
> I am not sure if this is the right way to ensure the BU order.  Which
> time accuracy are you assumed for netlmm protocol?
> 
> There may be another way to solve this...
> For example, whenever a new MAG sends PBU, it can flash the sequence
> value with "0".  If the LMA receives PBU with the seq set to zero, it
> just accepts this and discards any other PBUs sent by the old MAG.
> Alternatively, you can set some flag indicating that this is PBU from
> a new MAG.  This is a protocol for local domain, I am not sure whether
> such restricted way to prevent packet ordering is required or not...
> 

No. But, that wont solve the issue when the mobile is oscillating between
two MAG's. In the given case,

mobile attaches to MAG-1, MAG-1 sends PBU-1
mobile moves to MAG-2, MAG-2 sends PBU-2

Due to network conditions and under hypothetical scenario, the PBU-2
hits the LMA first, it creates a binding and then the PBU-1 arrives,
the LMA incorrectly updates the binding.

Also, Time-Stamp option is optional and in the presence of context
transfer mechanisms, its not required. This option is used by 4285 as
well for replay protection. Mobile IPv4 uses this option and deployments
prove that, it works. In any case, this is optional. This can be solved
in other ways, one way forcing the LMA always return the seq id the MAG
can use, but that will create an extra round trip.

> In addition to this, there is contradiction.  the draft first says
> that LMA MUST ignore the sequence field in PBU. Then it said the LMA
> can fall back to sequence number scheme if time stamp option is not
> appeared.
> 

Agree. That should be fixed.

> * Section 5.4
> What kind of scenario does MAG set 0.0.0.0 to the home address option?
> The MAG can learn IPv4 HoA from the policy, no?  If this is the
> required scenario, whenever a MN changes its attached MAG, each MAG
> sends PBU with IPv4 HoA address allocation?  I may miss something
> here, but I just don't understand the sequence of this IPv4 HoA
> allocation...
> 

For one scenario, where the address configuration is statically configured
in AAA.,it is possible the LMA can provide the configuration to the
MAG. The MAG can deliver this to the mobile in many ways, IPCP, IKE
or in some other ways. Many wanted this feature and we have decided to
permit that case.

> * section 6.1
> The first sentence missed period.
> 

OK

> * section 6.11
> When a LMA receives PBU from a new MAG due to MN movement, but it
> still receives a PBU from the previous MAG.  LMA can notify to the
> previous MAG to removes the BUL entry. It may useful to have signal
> from LMA to MAG in general other than BA.
> 

We have covered in 6.11, creating room for one or more ways. Typically,
the NUD is quite fast, less than a min and so should be ok. But, sure
it can be done.

> *section 7.1
> The draft must mention when a MN has multiple interfaces.  In such
> scenario, the MN may attach multiple interfaces to the netlmm link and
> send identity from both of interfaces.  This scenario is not
> considered in netlmm. Thus, the draft should say that something link:
> "A MN can send its identity to only single access network in netlmm
> domain all the time.  If MN has multiple active interfaces attached to
> netlmm domain, it must send identify only from one of interface."
> 

This is an interesting comment. Multi access introduces certain
challenges and sure, we need to state this. 

> * section 7.3
> The assumption of netlmm may be point-to-point access, but the draft
> also supports shared link access network.
> 

All the current SDO operating environments seem to assume this. This
is relevant for WLAN scenario and when VLANs cant be configured to
segregate traffic on the access link.

> We recently publish
> http://tools.ietf.org/id/draft-wakikawa-mip6-no-ndp-00.txt
> This draft may help to update the RS/RA operation.
> 

Thanks. Will look at it.

> You must carefully operate RA (specially on-link flag). Otherwise, if
> a malicious MN attached to a shared-link and obtains an IPv6 address
> from a home prefix of some other MN, the malicious MN can communicate
> with the MN on the link.  MAG cannot protects this packets between the
> malicious MN and the MN.
> 

Ok.

> * section 8
> It is better to write MH type value for PBU and PBA.  It is not clear
> whether this is an extension to the BU and BA of RFC3775 or brand-new
> options.
> 

MH Type is the same, the bit flag differentiates the two.

Thanks for your comments.

Sri

> thanks
> ryuji

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 13 Mar 2007 20:59:57 +0900

Dear Sri

I also went over the draft and here are my main concerns.

1. Link/ Subnet model
- I assume that the draft supports ONLY per-MN-prefix model and
doesn't consider shared prefix model. Am I right? If so, I recommend
the draft states that in more clear and explicit way.
- The drafts seems to support shared link from the below

   This Proxy Mobile IPv6 scheme is independent of the underlying access
   technology or the link model.  The interface between the mobile node
   and the mobile access gateway can be either:

   o  Point-to-Point Link

   o  Shared Link

I wonder this may conflict with 'per-MN-prefix model'. In previous
per-MN-prefix models such as 'IPv6 over 3GPP' or 'IPv6 over 802.16',
'per-MN-prefix model' entails a peer-to-peer link. Every MN belongs to
a peer-to-peer link and no two MNs belong to the same link at any
time. We'd better define per-MN-prefix model more clearly.

2. MN-HoA Role
- It's not clear what MN HoA's role will be. Is the Proxy Binding
established between
MN-HoA and Proxy CoA or
MN-HNP (Home Network Prefix) and Proxy CoA?
- I think it's easier to manage the binding with MN-HNP, instead of
MN-HoA. But there are several sentences implying the latter as below.

   Proxy Binding Update (PBU)

      A signaling message sent by the mobile access gateway to a mobile
      node's local mobility anchor for establishing a binding between
      the mobile node's MN-HoA and the Proxy-CoA.

Kindly clarify.

3. MN-HoA detection
- I have a few related questions
  1) Does PBU ALWAYS carry an MN-HoA?
  2) Does Binding Cache entry in 5.1 ALWAYS has an MN-HoA?
  3) Does Binding Update List in 6.2 ALWAYS has an MN-HoA?
  4) Does MN profile ALWAYS include an MN-HoA?
- If 1) is yes, how an MAG can reliably know a MN's MN-HoA, which is
stateless auto-configured?
- If 4) is yes, how a policy store can reliably know a MN's MN-HoA,
which is stateless auto-configured?

4. Home link emulation
- It's written MAG performs Home link emulation by sending RAs with
MN-HNP and OTHER PARAMETERS. But the other parameters such as link MTU
may not be valid in a currently attached link. I think it's enough
just to send MN-HNP in RAs without having to worry about other
parameters.

5. Home link attachment
- It's not clear to me whether an MN can attach to its Home link. In
other word, is it possible for an MN to attach to the same link as its
LMA? Kindly clarify.

I have a few suggestions.

1. I have difficulty grasping the whole PMIPv6 procedure. Sec 3
doesn't distinguish 'Initial Attachment' and 'Intra-LMD mobility' as
in draft-singh. I propose to present the procedure in two stages,
1) Inital attachment, where an MN attaches to a PMIPv6 domain for the
first time
   and doesn't have an MN-HoA yet and
2) Intra-LMD mobility where the MN moves inside PMIPv6 domain and has
the MN-HoA.

2. The order of signaling messages is not clear. I am not sure whether
'RA is sent before PBU' or not. I think the figure describing
signaling procedure like Figure 2), 3) in draft-singh would be of
help.

Thanks for your kind consideration.

Best Regards

JinHyeock