Subject: [netlmm] FW: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 13 Apr 2008 23:26:43 -0700

FYI ...

Response to Lars Eggert's review. As I see, no open
issues.

Sri

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Wednesday, April 09, 2008 6:44 PM
> To: 'Lars Eggert'; [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6 
> 
> Hi Lars,
> 
> Thanks for the review. Please see inline.
> 
> 
> > -----Original Message-----
> > From: Lars Eggert [mailto:[email-masked]] 
> > Sent: Wednesday, April 09, 2008 3:51 PM
> > To: [email-masked]
> > Cc: [email-masked]; 
> > [email-masked]
> > Subject: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6 
> > 
> > Discuss:
> >   DISCUSS: What happens with packets destined for the MN 
> > arriving at the
> >   LMA during the time a handoff is ongoing? Are they 
> dropped? Are they
> >   buffered?
> >
> 
> This issue was discussed in the WG and the document addresses this
> issue. The issue is bit more relevant on the prev-MAG or new-MAG
> than on the LMA. On the LMA, there is always one tunnel to the prev
> MAG or to the new MAG. The PBU from the nMAG is really the indicator
> that there is a handoff hapenning. The forwarding plane on the LMA
> will always route the traffic to the existing tunnel/MAG. So, till
> the signaling from the nMAG is complete, the LMA will route the
> traffic to the prev MAG and once the PBU from the nMAG is accepted,
> the data path gets moved to the new MAG.  This is covered in Sec
> 5.3.5 (bullet 1 and 2).
>  
> 
>  
> > 
> > Section 5.5., paragraph 5:
> > > As an alternative to the Timestamp based approach, the 
> specification
> > > also allows the use of Sequence Number based scheme, as per [RFC-
> > > 3775].  However, for this scheme to work, the serving 
> mobile access
> > > gateways in a Proxy Mobile IPv6 domain MUST have the ability to
> > > obtain the last sequence number that was sent in a binding
> > > registration message for updating a given mobile node's 
> > binding.  The
> > > sequence number MUST be maintained on a per mobile node basis and
> > > MUST be synchronized between the serving mobile access gateways.
> > 
> >   DISCUSS: Although the document doesn't describe the mechanism for
> >   synchronizing the last sequence number sent, it needs to 
> discuss the
> >   timing and reliability requirements of such synchronization 
> > protocols,
> >   because this introduces an upper bound on the frequency of binding
> >   updates that can be served.
> > 
> 
> As part of the context transfer procedures, this seq number can be
> synchoronized between the prev MAG and the serving MAG. This really
> leverages 3775 mechanism, where the MN maintains the running seq
> number and in case of Proxy Mobile IPv6, this is maintained on the
> MAG and is floated to the new MAG, as per the MN's movements. 
> 
> 
> > 
> > Section 2., paragraph 0:
> > > 2.  All the mobility entities in a Proxy Mobile IPv6 
> domain that are
> > >     exchanging binding registration messages using the Timestamp
> > >     option must have adequately synchronized time-of-day clocks.
> > >     This is the essential requirement for this solution 
> to work.  If
> > >     this requirement is not met, the solution will not predictably
> > >     work in all cases.
> > 
> >   DISCUSS: The requirement for clock synchronization deserves 
> > a capital
> >   MUST, and if it can't be guaranteed, the document should clearly
> >   require that it MUST NOT be used. Also, the document needs 
> > to describe
> >   what it considers "adequate" to be, because the maximum 
> > possible clock
> >   drift between different MAGs establishes an upper bound on the
> >   supportable frequency of binding updates.
> > 
> 
> Yes. It must be in upper case. In some deployments where 
> such MAG contention is not seen, based on the topology
> of the network and other characterstics, a given deployment
> can manage to avoid the contention. The draft says, that
> the solution will not work if the requirement is not met.
> Wondering, if this is not sufficient.
> 
> 
> > 
> > Section 6., paragraph 0:
> > > 6.  Upon receipt of a Proxy Binding Update message with the 
> > Timestamp
> > >     option, the local mobility anchor MUST check the 
> timestamp field
> > >     for validity.  In order for it to be considered valid, the
> > >     timestamp value contained in the Timestamp option 
> MUST be close
> > >     enough (within TimestampValidityWindow amount of time 
> > difference)
> > >     to the local mobility anchor's time-of-day clock and the
> > >     timestamp MUST be greater than all previously accepted 
> > timestamps
> > >     in the Proxy Binding Update messages sent for that 
> mobile node.
> > 
> >   DISCUSS: If an MN-provided timestamp is used, as described 
> > under point
> >   3 above, this validity-checking isn't possible, because 
> there is no
> >   requirement that the MN clock is synchronized to the LMA clock.
> > 
> 
> Yes. We did not want to specify exactly how MN generated timestamp
> can be leveraged. Its really left to the implementations. However,
> for this, we can add a configuration knob that specifies the timestamp
> mode that is enabled in a given PMIP domain and we can relax this
> above check for the MN-generated timestamp mode.
> 
> 
> > 
> > Section 6.3., paragraph 1:
> > > This specification supports only point-to-point access link 
> > types and
> > > thus it assumes that the mobile node and the mobile access gateway
> > > are the only two nodes on the access link.  The link is assumed to
> > > have multicast capability.  This protocol may also be 
> used on other
> > > link types, as long as the link is configured in such a 
> way that it
> > > guarantees a point-to-point delivery between the mobile 
> node and the
> > > mobile access gateway for all the protocol traffic.
> > 
> >   DISCUSS: I find the concept of a point-to-point link that supports
> >   multicast strange, because unicast = multicast for such 
> > links. Also, I
> >   don't quite understand what the requirement "guarantees a
> >   point-to-point delivery" means - surely this isn't meant 
> to require
> >   reliable delivery? For example, is a switched Ethernet a link type
> >   supported by NETLMM? Finally, I also don't understand why 
> NETLMM is
> >   restricted to certain link types - that seems to be a pretty
> >   fundamental restriction compared to non-proxy MIPv6. Could 
> > all this be
> >   explained in a bit more detail?
> > 
> 
> The link-type is one of the supported link-type in RFC-4861.
> 
> " point-to-point - a link that connects exactly two interfaces.  A
>                     point-to-point link is assumed to have multicast
>                     capability and a link-local address."
> 
> 
> > "guarantees a  point-to-point delivery" 
> 
> "Guarantees" is probably a strong word :). We were trying to
> say, there are only two nodes on the link, any packets sent by
> one node on the link is received by the other node. I do not
> know if we can clarify any thing beyond this. Or, we can just
> point to RFC-4861.
> 
> 
> > switched Ethernet a link type supported by NETLMM?
> 
> No, not in this specification. Its out of scope. Reason -
> there are issues related to link-local address collision
> and its gets very complex in case of shared links and so
> the WG has decided not to support this in the base spec.
> Additionally, looking at the applicability of this protocol
> in SDO environments, such as in 3GPP, 3GPP2 or WiMAX, the
> link between the MN and the access network is always a 
> p2p link. So, we dont have strong usecase for this feature
> at this point, as seen by the WG.
> 
> 
> 
> 
> > Comment:
> > Section 4., paragraph 2:
> > > The mobile access gateway and the local mobility anchor MUST
> > > implement IPsec for protecting the Proxy Mobile IPv6 signaling
> > > messages [RFC-4301].  That is, IPsec is mandatory to implement
> > > security mechanism.  However, additional documents may specify
> > > alternative mechanisms.
> > 
> >   Is there a mechanism by which the MAG and the LMA can 
> detect if the
> >   other side is using one of the to-be-defined mechanisms, i.e., not
> >   IPsec? Or is this supposed to be up to configuration?
> > 
> 
> There is no such negotiation capability. In future, if there is a
> spec that defines such alternative mechanism, that needs to be
> manually configured on mobility entities in a Proxy Mobile IPv6 
> domain, or leverage mechanisms such as GSS API interface to
> negotiate the mechanism to be used and that negotiation is agnostic
> to this protocol.
> 
> 
> 
> > Section 5.3.6., paragraph 0:
> > > 5.3.6.  Constructing the Proxy Binding Acknowledgement Message
> > 
> >   This section has several "option X MUST be present, if..." 
> > constructs.
> >   Please say something about whether option X MAY or MUST NOT 
> > be present
> >   when the conditional is false.
> > 
> 
> It covers all the cases. Looking the Home Network Prefix option
> as an example:
> 
> > The Home Network Prefix option MUST be present.
> >
> >      *  If the Status field is set to a value greater than 
> or equal to
> >         128, i.e., if the binding request is rejected, then 
> the prefix
> >         value in the Home Network Prefix option MUST be set to the
> >         prefix value in the Home Network Prefix option of 
> the received
> >         Proxy Binding Update request.  But, if the option was not
> >         present in the request, the value in the option 
> MUST be set to
> >         ALL_ZERO.
> >
> >      *  For all other cases, the prefix value in the option 
> MUST be set
> >         to the allocated prefix value for that mobility session.
> >
> 
> So, this includes all possibilities. But, point taken. We 
> will review and
> ensure its clear for all the options.
> 
> 
> > 
> > Section 3., paragraph 0:
> > >     Alternatively, if there is mobile
> > >     node generated timestamp that is increasing at every 
> attachment
> > >     to the access link and if that timestamp is available to the
> > >     mobile access gateway (Ex: The timestamp option in the SEND
> > >     messages that the mobile node sends), the mobile 
> access gateway
> > >     can use this timestamp or sequence number in the Proxy Binding
> > >     Update messages and does not have to depend on any 
> > external clock
> > >     source.  However, the specific details on how this is 
> > achieved is
> > >     outside the scope of this document.
> > 
> >   The MN link-attach "timestamp" here might as well be a sequence
> >   number, so it's not quite accurate to characterize this a
> >   timestamps-based approach. The magic bits from the MN are carried
> >   inside the timestamp fields, but that's about as much as 
> > can be said.
> >   Essentially, this scheme is a third approach that depends 
> > on the side
> >   effects of certain link layer technologies implemented at 
> > the MN, and
> >   I'm not extremely thrilled to see this suggested in an IETF 
> > document.
> > 
> 
> There was some push from some members to list this approach.
> When SEND is in use, the AR and a node do exchange timestamps
> and there was interest from people to leverage that timestamp
> learnt from those ND messages. So, we had to provide some minimal
> hints regards to that approach. 
> 
> 
> > Section 2., paragraph 0:
> > > 2.  An implementation MUST support Sequence Number based 
> scheme, as
> > >     per [RFC-3775].
> > 
> >   It would be good to repeat the requirement from above that 
> > to use this
> >   scheme, a mechanisms that synchronizes the last sequence 
> number sent
> >   across all MAGs is REQUIRED.
> > 
> 
> Sure. Agreed.
> 
> > 
> > Section 10., paragraph 0:
> > > 10.  IANA Considerations
> > 
> >   Who are the proposed IANA Experts for the registries 
> > requiring expert
> >   review? (Question to the AD.)
> > 
> 
> Jari ?
> 
> > 
> > Nits:
> > 
> > Section 4.1., paragraph 2:
> > >          and authorize CHILD_SA for remote address lma_addres_1
> > 
> >   Nit: s/lma_addres_1/lma_address_1/
> > 
> 
> Ok. Thanks
> 
> 
> > Section 9., paragraph 12:
> > >    EnableMAGLocalrouting
> > 
> >   Nit: s/EnableMAGLocalrouting/EnableMAGLocalRouting/
> > 
> 
> Sure. 
> 
> Thanks again for the review.
> 
> Best Regards
> Sri
> 

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 13 Apr 2008 23:32:31 -0700

FYI ... 

Response to Dave Ward's review. No open issues.

Sri

> Sent: Thursday, March 27, 2008 9:18 AM
> To: 'David Ward'
> Cc: [email-masked]; 
> [email-masked]; 
> [email-masked]
> Subject: Re: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
> 
> 
> Hi Dave,
> 
> Thanks for the review, please see inline ..
> 
> David Ward:
> 
> > Discuss [2008-03-26]:
> > In section 5.9 it is mentioned that Return Routability 
> procedures in 3775
> cannot
> > be used. What impact on the chosen path through the routing 
> topology is
> expected
> > from the LMA to the home prefix and between the LMA and the 
> mobile node?
> It
> > appears that the addresses being passed around are very 
> close to being
> routing
> > protocols.
> 
> The RR procedure for establishing RO is not supported in this 
> spec. However,
> there are some proposals on this topic. The path for the 
> traffic is always
> through LMA, it is the topological anchor point and it sets 
> up forwarding
> for
> the prefix towards the MAG through the L3 tunnel.
>  
> This is very similar to NEMO/Mobile Router support (RFC-3963) 
> and with the
> subtle difference of hosting the prefix on the MN-MAG link as 
> supposed to
> delegating the prefix to the mobile.
> 
> 
> 
> Prefix Anchor
>  Point
>  |
> LMA===========MAG---------------MN
>      Tunnel            (hosted prefix)
> 
> 
> > Later in 5.2 there is mention that this is a per-MN-prefix 
> model and does
> not
> > support a shared-prefix model. What about aggregate prefixes?
> 
> The assigned addresses for each mobile (specifically for a 
> given interface)
> is always a unique prefix. As supposed to the base Mobile 
> IPv6 approach of
> assigning an /128 bit address to a mobile node, the entire prefix is
> assigned
> to the mobile node. The serving MAG's host the prefix on the 
> respective
> MAG-AR
> links. The prefix aggregation is on the LMA and the LMA can 
> certainly inject
> an aggregated prefix (spanning multiple MN prefixes) into IGP.
> 
> Thanks Dave for the review.
> 
> Sri
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 25 Apr 2008 14:50:11 -0700 (PDT)

Hi Sri,
  Please see inline.

Regards,

Behcet

----- Original Message ----
From: Sri Gundavelli <[email-masked]>
To: [email-masked]
Sent: Monday, April 14, 2008 1:35:52 AM
Subject: [netlmm] FW: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6

FYI. 

From Pasi's review, only one issue remains, on the changes
required to allow multiple prefix assignment.

[behcet] I am curious if we really need this. I know Pasi said:
 why compliance with current and
future IPv6 standards really requires allowing multiple
prefixes. 3GPP fixed their specs based on this

However, in 3GPP spec 23.401, sec. 5.3.1 on IP address allocation it says:
During the attach procedureand default bearer establishment, the PDN GW sends the IPv6 prefix andInterface Identifier to the SGW, and then the S-GW forwards the IPv6 prefix andInterface Identifier to the MME or to the SGSN. The MME or the SGSN forwardsthe IPv6 Interface Identifier to the UE. Even if the UE receives the IPv6prefix in the Attach Accept message, it shall ignore it.

I don't see mention of multiple prefixes there. I think that multiple prefixes should be sent to MAG and PBU should allow this. It is required for PD (mainly for renumbering).
Am I missing something?

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 28 Apr 2008 11:36:42 -0700 (PDT)

I had an offline discussion with Sri on this.
He explained to me that IPv6 links need to be assigned multiple prefixes.
This was the point I missed.

Thanks Sri for your hard work on PMIP6 base draft.

Regards,

Behcet

----- Original Message ----
From: Behcet Sarikaya <[email-masked]>
To: Sri Gundavelli <[email-masked]>; [email-masked]
Sent: Friday, April 25, 2008 4:50:11 PM
Subject: Re: [netlmm] FW: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6

Hi Sri,
  Please see inline.

Regards,

Behcet

----- Original Message ----
From: Sri Gundavelli <[email-masked]>
To: [email-masked]
Sent: Monday, April 14, 2008 1:35:52 AM
Subject: [netlmm] FW: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6

FYI.