Subject: [MEXT] FW: [netlmm] Separation of Control and Data Plane for PMIPv6

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 20 Nov 2008 14:40:50 -0500

Sri,

You did not respond to the following email. 

The text in RFC 5213 is not sufficient for separation of control and
data plane using altCoA option. 

Vijay 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Vijay Devarapalli
Sent: Tuesday, October 28, 2008 11:33 AM
To: Sri Gundavelli
Cc: [email-masked]
Subject: Re: [netlmm] Separation of Control and Data Plane for PMIPv6

Hi Sri,

Sri Gundavelli wrote:
> Hi Vijay,
> 
> 
>>>
>>>  The primary purpose of Alt-CoA option is the control/data plane
>>>  seperation. 
>>
>> Where is this explained in RFC 3775? I repeat, separation of control
and
>>  data plane for a Mobile IPv6 mobile node does not make sense.
>>
> 
> Its not about the presence of the phrase "Control Plane/Data Plane
> seperation". The option can be used that way and cant see why it
> wont work. 

This is actually a mis-use of the AltCoA option. It was not intended for

  supporting the separation of control and data plane. Even if you do 
want to use the AltCoA option for this purpose, the specifications are 
missing. More below.

> If not, why is the use of Alt-CoA even made it to 5213 ?

RFC 5213 does not specify the separation of control and data plane. For 
instance, see the following text fragments from 5213.

Section 5.3.6

    o  The Destination Address field in the IPv6 header of the message
       MUST be set to the source address of the received Proxy Binding
       Update message.  When there is no Alternate Care-of Address
option
       present in the request, the destination address is the same as
the
       Proxy-CoA; otherwise, the address may not be the same as the
       Proxy-CoA.

What does "may not be the same" mean? If you had intended to use this 
for control and data plane separation, the above paragraph should have 
said, if there is an alternate care-of address option present and if the

address in the option is different from the source address of the 
received PBU, then the destination address on the PBACK MUST be set to 
the source address of the received PBU. Otherwise it is not guaranteed 
to work. It becomes LMA implementation specific.

Section 6.9.1.5

    o  The Source Address field in the IPv6 header of the message MUST
be
       set to the global address configured on the egress interface of
       the mobile access gateway.  When there is no Alternate Care-of
       Address option present in the request, this address will be
       considered as the Proxy-CoA for this Proxy Binding Update
message.
       However, when there is an Alternate Care-of Address option
present
       in the request, this address will be not be considered as the
       Proxy-CoA, but the address in the Alternate Care-of Address
option
       will be considered as the Proxy-CoA.

The above paragraph tells me that the contents of the AltCoA option 
should be stored as the Proxy CoA. When the LMA needs to send a binding 
revocation message, where would it send the message to? There is no 
guarantee that the LMA will store the source address of the original 
PBU, since none of the specifications told the LMA to do this. Another 
example is the HA/LMA Switch Message [RFC 5142]. Where would this 
message be sent to?

IMO, it is not possible to implement separation of control and data 
plane using RFC 5213 and the alternate CoA option. You have to make a 
lot of assumptions. Perhaps you had it figured out how to implement 
this, but it is not specified in the document.

One option is to revise RFC 5213 and describe clearly how to use the 
AltCoA option to separate control and data plane. Another option is to 
develop a clean solution to separate the concepts of Proxy CoA and Data 
Plane Address. The Proxy CoA would be used for all control plane 
signaling and the Data Plane address would be used for tunneling data 
traffic. I of course prefer the cleaner solution.

> Again, refer to discussions from Anand Bedekar and others.

The mailing list or the off line discussions? We had a lot of 
discussions on the separation of control and data plane when PMIPv6 was 
being adopted by the NETLMM WG. We decided to come back to this later 
after specifying the basic PMIPv6 protocol assuming the control and data

plane end-points are co-located. And thats what we did. Do you remember 
something different?

Vijay

> 
> 
>>> >  Second, the missing parameter that you suggest is actually quite
>>> >  significant. Neither RFC 5213 or 3775 mention that the HA/LMA
should
>>> >  store the source address of the original BU/PBU if the altCoA 
>>> option is
>>> >  present. Only the contents of the altCoA is stored in the binding

>>> cache
>>> >  entry. DS-MIPv6, OTOH, says that if the source address on the 
>>> outer IPv4
>>> >  header is different from the IPv4 care-of address option (the 
>>> equivalent
>>> >  of the AltCoA option), then in fact the source address on the 
>>> outer IPv4
>>> >  header should be stored as the CoA. The IPv4 care-of address
option
>>> >  contents are not stored. Therefore, at any time, there is only
one
>>> >  address stored in the binding cache entry. A MAG or a mobile node

>>> cannot
>>> >  be sure that the LMA/HA did store two different addresses. So the
>>> >  separation of control and data plane will not work.
>>> >
>>>
>>>  What is stored and what is not stored is an implementation issue. 
>>
>> It is not. Unless the MAG knows that the LMA did store both
addresses, 
>> the MAG cannot be sure the LMA does support this.
>>
> 
> If the option is present, the LMA must preserve it, else its a
software
> defect. When there is Alt-CoA option in the BU request, if the client
> does not store it, where is the BA message being sent ?
> 
> 
>> From
>>>  the perspective of protocol interoperability, we require a given 
>>> message
>>>  to be sent to a specific address. If that address that is obtained
in
>>>  the prior state of the protocol is cached or not, is not a protocol
>>>  issue, its an implementation issue. The conceptual data structure
is a
>>>  general recommendation/aid to implementations, its presence/absence
has
>>>  no bearing on the wire protocol messages. Many protocols dont have
this
>>>  conceptual structure at all, its a good practice to provide that in
the
>>>  specs.
>>>
>>>
>>> >  Third, any message that is initiated by the HA/LMA will be sent
to 
>>> the
>>> >  CoA or Proxy CoA. Not to the source address of the original 
>>> BU/PBU. Even
>>> >  the BACK/PBACK is not guaranteed to be sent to the source address

>>> on the
>>> >  original BU/PBU. Implementations have done it differently, i.e.,
used
>>> >  the contents of the binding cache entry to construct the
BACK/PBACK.
>>> >
>>>
>>>  When the BU/PBU that triggered the registration has an Alt-CoA
option,
>>>  any explicit signaling messages should be sent to the source
address 
>>> and
>>>  not to the CoA/Proxy-CoA.
>>
>> Where is this specified?
>>
> 
> Again, where is BA message sent when this option is present ?
> 
> 
>>> >  Finally, fixing this in 3775-bis does not make sense to me, since
I
>>> >  don't believe a mobile node will ever use this feature. It is not
>>> >  required for Mobile IPv6.
>>> >
>>>
>>>  Alt-CoA option is specified in 3775 and the related parameters have
to
>>>  added to that spec and even if its not used by a mobile node.
>>
>> This defies logic. :)
>>
> 
> The option that is defined in 3775 is the sole reason why the source
> and CoA addresses would be different and so it must be defined there.
> Where else ?
> 
> 
> Sri

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 20 Nov 2008 12:20:01 -0800 (PST)

Vijay,

> want to use the AltCoA option for this purpose, the specifications are

3775 or 5213 clearly do not use the word CP/DP seperation. But, the
hook that they provided in the form of Alt-CoA option allows PBA/BA
to be received on an address which is different from the tunnel
end point. There can be more than one scenario in which this option
can be used.

> to work. It becomes LMA implementation specific.

Where is the confusion. The text says the destination is always
the src address of the PBU. While PCoA is the address in Alt-CoA option.
When that option is not there, both src and pcoa are same. Why this
does not work ?

> example is the HA/LMA Switch Message [RFC 5142]. Where would this

Conceptual data structures do not define protocol behaviour. IMO,
no implementation would loose the src address of the BU, else the
BA will not make it.

Any ways, the topic of CP/DP seperation should not prevent Binding
revocation draft from sending the Bind Rev ack's to the src address
when Alt-CoA option is present.

Sri