RE: [netlmm] Significance of MN-Identifier

Hi Kuntal,

> I don't know what the issue is for MN-ID in the PMIP6 signaling
> messages. Could you explain why we are having this debate?

Because, the current text is locking all PMIP6 deployments to one security
model and not leaving any room for using anything else. And it is doing so
without a good reason (unintentionally, I believe).

> MN-ID is the unique identifier to identify the session state in the LMA.

It is necessary only of the MN does not know its HNP. As soon as it knows
the HNP (e.g., when HNP is assigned during network access authentication),
we can rely on HNP to identify the session state. 

> There are several good reasons to mandate the presence of MN-ID in the
> PBU/PBA. For example, it helps to identify the session state in the LMA
> for PMIP6 - MIP6 transition scenarios, when the LMA is collocated with a
> MIP6 HA. 

Can you elaborate on this scenario? You may have something here, but I need
to understand.

Alper

> Note that during IKEv2 exchange for MIP6, the IDi field (that
> carries the same MN-ID) in the IKE packets help identify the ongoing
> (PMIP6) session related to the MN.
> 
> Hope this helps.
> 
> -Kuntal
> 
> 
> > -----Original Message-----
> > From: Alper Yegin [mailto:alper.yegin@yegin.org]
> > Sent: Tuesday, September 11, 2007 3:46 AM
> > To: 'Sri Gundavelli'
> > Cc: netlmm@ietf.org
> > Subject: RE: [netlmm] Significance of MN-Identifier
> >
> > Sri,
> >
> > > At handoff, nMAG may not know the HNP of the mobile node. How does
> it
> > > communicate with the LMA about the MN, if MN-Id is not used ? That's
> > > is essential, its required in BCE and also in signaling messages.
> >
> >
> > So it is just for HNP assignment as I was saying:
> >
> > >>> Is it for the sake of identifying the MN during dynamic HNP
> > >>> assignment in-band with PMIP?
> >
> >
> > HNP can be assigned during network access authentication. I can't
> imagine
> > when this is not possible or desirable.
> >
> > That's why mandating presence of MN-id that identifies the MN is not
> > necessary, imo.
> >
> > If people can show a reason why we must also support HNP assignment
> in-
> > band
> > with PMIP, we can say:
> >
> > 	When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that
> > carries 	the MN-id MUST be included in the PBU.
> >
> >
> >
> > Alper
> >
> >
> > >
> > > Sri
> > >
> > >
> > > > Alper
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >>
> > > >> Sri
> > > >>
> > > >>
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org]
> > > >>> Sent: Monday, September 10, 2007 4:27 AM
> > > >>> To: netlmm@ietf.org
> > > >>> Subject: [netlmm] Significance of MN-Identifier
> > > >>>
> > > >>> What's the significance of MN-Identifier as carried in PBU?
> > > >>>
> > > >>> Is it for the sake of identifying the MN during dynamic HNP
> > assignment
> > > >>> in-band with PMIP?
> > > >>>
> > > >>> If so, given that the HNP may also be assigned during network
> access
> > > >>> authentication (out-of band with PMIP, as commonly done in
> > integrated
> > > >>> bootstrapping scenarios), we shall not mandate that the MN-
> > identifier
> > > >>> identifies the real MN.
> > > >>>
> > > >>> Another way of using of MN-identifier is to identify the
> > > >>> "proxy MN" (MAG)
> > > >>> with RFC 4285.
> > > >>>
> > > >>> Alper
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> netlmm mailing list
> > > >>> netlmm@ietf.org
> > > >>> https://www1.ietf.org/mailman/listinfo/netlmm
> > > >
> >
> >
> > _______________________________________________
> > netlmm mailing list
> > netlmm@ietf.org
> > https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 
> "This email message and any attachments are confidential information of
> Starent Networks, Corp. The information transmitted may not be used to
> create or change any contractual obligations of Starent Networks, Corp.
> Any review, retransmission, dissemination or other use of, or taking of
> any action in reliance upon this e-mail and its attachments by persons or
> entities other than the intended recipient is prohibited. If you are not
> the intended recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> postmaster@starentnetworks.com -- and destroy all copies of this message
> and any attachments without reading or disclosing their contents. Thank
> you."

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm