Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 28 Sep 2007 18:29:25 -0400

Link IDs are not guaranteed to be unique and constant per interface if
the MN does not have MAC addresses. There are access technologies out
there (e.g. HRPD) where MN's link Id is not even known by the AR.

I agree with Vijay. Assuming interface specific MN-ID or embedding Link
ID in PBU is a non-starter.

-Kuntal

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Friday, September 28, 2007 5:21 PM
> To: Vijay Devarapalli; Basavaraj Patil
> Cc: ext Kilian Weniger; [email-masked]; ext Genadi Velev
> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs
> 
> We are just talking about equivalents of link-layer IDs here.  The MN
> will have a different link ID on each of its interfaces.  Actually,
the
> MN here has to do nothing.  The MAG needs to pick up an interface
> specific identity for the MN - e.g., use its MAC address or something
> equivalent.
> 
> Vidya
> 
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:[email-masked]]
> > Sent: Friday, September 28, 2007 2:18 PM
> > To: Basavaraj Patil
> > Cc: ext Kilian Weniger; [email-masked]; ext Genadi Velev
> > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs
> >
> > Using two different identifiers on two different interfaces
> > is a non-starter. The MN might just not have two different
> > identifiers to use.
> >
> > Vijay
> >
> > Basavaraj Patil wrote:
> > > I don't know if we have really converged ;)
> > >
> > > Two questions:
> > > 1. How can you prevent a device from attaching via multiple
> > interfaces
> > > simultaneously? Are you suggesting that within the scope of a
PMIP6
> > > domain, you could potentially verify (at AAA level or some
> > such thing)
> > > if an MN is already attached via another interface and
> > hence prevent
> > > it from attaching via the second interface?
> > >
> > > 2. How do you ensure that variable MN-IDs are used depending on
the
> > > interface used by the host to attach to a network?
> > >
> > > An MN which attaches via different interfaces simultaneously to a
> > > PMIP6 domain will result in the LMA having a BCE for the
> > last received
> > > PBU. Host behavior when multiple interfaces have the same
> > address is
> > > unspecified and we can just leave it at that. In the
> > context of this
> > > document, we do not need to solve it.
> > >
> > > -Raj
> > >
> > >
> > > On 9/28/07 10:59 AM, "ext Genadi Velev"
> > > <[email-masked]>
> > > wrote:
> > >
> > >> Hi Sri,
> > >>
> > >> it seems that we converge on this issue :-)
> > >>
> > >> I was also agnostic on any of the initial options 1-4.  Of
> > course the
> > >> simplest way to go forward is to describe options 1 and 2. The
> > >> operator can choose between not allowing multiple interfaces to
be
> > >> simultaneously attached (option 1) or to support multiple
> > interfaces
> > >> to be attached but assuring that different MN-ID is
> > assigned to each interface.
> > >>
> > >> Option 3 still needs to be worked out in
> > >> draft-muhanna-mip6-binding-revocation-01, as discussed by
> > Kilian and
> > >> Vijay. So, we can leave it out for the base PMIP specification.
> > >>
> > >> Genadi
> > >>
> > >>> -----Original Message-----
> > >>> From: Sri Gundavelli [mailto:[email-masked]]
> > >>> Sent: Friday, September 28, 2007 4:15 PM
> > >>> To: Genadi Velev
> > >>> Cc: Narayanan, Vidya; ext Kilian Weniger; [email-masked]
> > >>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed
MNs
> > >>>
> > >>> Hi Genadi,
> > >>>
> > >>> Please see inline.
> > >>>
> > >>>
> > >>> On Fri, 28 Sep 2007, Genadi Velev wrote:
> > >>>
> > >>>
> > >>>> I can think about several approaches to overcome this issue:
> > >>>> 1) we can specify that the network operator shall take care of
> > >>>> preventing that a MN attaches with 2 interfaces to a PMIP
domain
> > >>>> (at least to the same LMA). For example, the operator
> > doesn't allow
> > >>>> attachment (i.e. authorization) of interface 2, since
> > interface 1
> > >>>> is still attached.
> > >>>
> > >>>> 2) we can write a short text in the draft that the
> > network operator
> > >>>> shall take care about assignment of different MN-ID (NAI)
> > >>> to different
> > >>>> interfaces during attachment procedure.
> > >>>> 3) we can describe how the current protocol behaves when a
> > >>> MN attempts
> > >>>> to attach with two interfaces. Similar to what is explained
> > >>> in Vijay's
> > >>>> email:
> > >>>>
> > http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html
> > >>> I'm ok with any of the above three options. We can certainly
> > >>> document the scenario and close the issue. I do no think,
> > we should
> > >>> try to solve this problem here or use this issue to
> > explicitly add
> > >>> text to block the inter-access handoff, we did not do any
> > thing to
> > >>> support that scenario. When the charter says, its out of
> > scope, we
> > >>> dont need to solve all the issues, when the scenario is enabled.
> > >>> Operators can solve this issue, these are managed
> > deployments. Its
> > >>> not a like a consumer buying a device and turning it on
> > at home. So,
> > >>> I agree with your above three suggested options.
> > >>>
> > >>> Regards
> > >>> Sri
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >> Panasonic R&D Center Germany GmbH
> > >> 63225 Langen, Hessen, Germany
> > >> Reg: AG Offenbach (Hessen) HRB 33974
> > >> Managing Director: Thomas Micke
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> netlmm mailing list
> > >> [email-masked]
> > >> https://www1.ietf.org/mailman/listinfo/netlmm
> > >
> > >
> > >
> > > _______________________________________________
> > > netlmm mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/netlmm
> >
> >
> >
> >
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/netlmm
> >
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 29 Sep 2007 01:07:54 +0200

Chowdhury, Kuntal wrote:
> Link IDs are not guaranteed to be unique and constant per interface
> if the MN does not have MAC addresses. There are access technologies
> out there (e.g. HRPD) where MN's link Id is not even known by the AR.

I agree, this is right.

> I agree with Vijay. Assuming interface specific MN-ID or embedding
> Link ID in PBU is a non-starter.

As presented it sounds non-starter to me too (two NAIs for one MN).
Because NAI is for user, not for interface.

And couldn't we just keep all this NAI and identifier issue out of the 
base spec?

Imagine PMIP6 basic just goes about IP addresses.  Imagine the AAA or
DHCP does all address assignment based on NAI, MAC address, 
Subscriber-ID, CGA SeND Public Key and any other identifier that is not 
an IP address.  What's so far-fetched about this?

Not only MN-Id looks as overspecification, but its entire use in PMIP6 
sounds as overspecification to me.

Alex

> 
> -Kuntal
> 
> 
>> -----Original Message----- From: Narayanan, Vidya
>> [mailto:[email-masked]] Sent: Friday, September 28, 2007 5:21
>> PM To: Vijay Devarapalli; Basavaraj Patil Cc: ext Kilian Weniger;
>> [email-masked]; ext Genadi Velev Subject: RE: [netlmm] Issue:
>> Prefix allocation and multihomed MNs
>> 
>> We are just talking about equivalents of link-layer IDs here.  The
>> MN will have a different link ID on each of its interfaces.
>> Actually,
> the
>> specific identity for the MN - e.g., use its MAC address or
>> something equivalent.
>> 
>> Vidya
>> 
>>> -----Original Message----- From: Vijay Devarapalli
>>> [mailto:[email-masked]] Sent: Friday, September
>>> 28, 2007 2:18 PM To: Basavaraj Patil Cc: ext Kilian Weniger;
>>> [email-masked]; ext Genadi Velev Subject: Re: [netlmm] Issue:
>>> Prefix allocation and multihomed MNs
>>> 
>>> Using two different identifiers on two different interfaces is a
>>> non-starter. The MN might just not have two different identifiers
>>> to use.
>>> 
>>> Vijay
>>> 
>>> Basavaraj Patil wrote:
>>>> Two questions: 1. How can you prevent a device from attaching
>>>> via multiple
>>> interfaces
>>>> An MN which attaches via different interfaces simultaneously to
>>>> a PMIP6 domain will result in the LMA having a BCE for the
>>> last received
>>>> <[email-masked]> wrote:
>>>> 
>>>>> Hi Sri,
>>>>> 
>>>>> simplest way to go forward is to describe options 1 and 2.
>>>>> The operator can choose between not allowing multiple
>>>>> interfaces to
> be
>>>>>> -----Original Message----- From: Sri Gundavelli
>>>>>> [mailto:[email-masked]] Sent: Friday, September 28,
>>>>>> 2007 4:15 PM To: Genadi Velev Cc: Narayanan, Vidya; ext
>>>>>> Kilian Weniger; [email-masked] Subject: RE: [netlmm]
>>>>>> Issue: Prefix allocation and multihomed
> MNs
>>>>>> Hi Genadi,
>>>>>> 
>>>>>> Please see inline.
>>>>>> 
>>>>>> 
>>>>>>> I can think about several approaches to overcome this
>>>>>>> issue: 1) we can specify that the network operator shall
>>>>>>> take care of preventing that a MN attaches with 2
>>>>>>> interfaces to a PMIP
> domain
>>>>>>> is still attached. 2) we can write a short text in the
>>>>>>> draft that the
>>> network operator
>>>>>>> interfaces during attachment procedure. 3) we can
>>>>>>> describe how the current protocol behaves when a
>>>>>> MN attempts
>>>>>> I'm ok with any of the above three options. We can
>>>>>> certainly document the scenario and close the issue. I do
>>>>>> no think,
>>> we should
>>>>>> dont need to solve all the issues, when the scenario is
>>>>>> enabled. Operators can solve this issue, these are managed
>>> deployments. Its
>>>>>> Regards Sri
>>>>> Panasonic R&D Center Germany GmbH 63225 Langen, Hessen,
>>>>> Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing
>>>>> Director: Thomas Micke
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________ netlmm
>>>>> mailing list [email-masked] 
>>>> _______________________________________________ netlmm mailing
>>>> list [email-masked] 
>>> _______________________________________________ netlmm mailing
>>> list [email-masked] 
>> _______________________________________________ netlmm mailing list
>>  [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________