Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 1 Mar 2007 10:42:36 +0100

Hi Jouni, Kuntal,

please see inline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Mittwoch, 28. Februar 2007 20:03
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02
> 
> Hi Kilian, 
> 
> > -----Original Message-----
> > From: Kilian Weniger [mailto:[email-masked]] 
> > Sent: 28. helmikuuta 2007 18:55
> > To: Korhonen, Jouni /TeliaSonera Finland Oyj
> > Cc: Chowdhury, Kuntal; Heejin Jang; [email-masked]; Basavaraj Patil
> > Subject: RE: [Mip6] WGLC: 
> draft-ietf-mip6-bootstrapping-integrated-02
> > 
> > Hi Kuntal, Jouni, 
> > 
> > yes, encoding the service in the Home Network Identifier 
> > field would also be possible (probably with changes to 
> > [HIOPT]). However, this has the danger of overloading the 
> > semantics, since this would change the network identifier to 
> > something like a "network+service" identifier. And don't we 
> 
> Hmmm.. lets be careful here. We are talking about only
> assigning different flavors of HA, nothing more.

If I understood the proposal we are talking about correctly, the FQDN is
used to negotiate a type of mobility service (e.g., DSMIP HA, MIP HA,
NEMO HA) and a corresponding protocol (e.g., DSMIP, MIP, NEMO). The MN
can request a specific mobility service/protocol by encoding into the HA
FQDN and the network would assign one by encoding into the HA FQDN. This
means that the MN would choose the mobility protocol based on the FQDN
received from the network. Is my understanding of the proposal correct?

> 
> > need to standardize a format then, since the format for 
> > encoding the service into the FQDN must be understood by the 
> > MSA *and all ASPs*, right? 
> 
> No. We cannot really mandate specific format as we probably do it
> wrong anyway for other SDOs in their architectures. Just state that
> FQDNs can be used to assign different flavors of HAs if an operator 
> or a SDO wishes to do so.

Kuntal said that "Using different FQDNs under the same operator domain
for differentiating between types of service nodes is already practised
in some 'relevant' SDOs." The point is "under the same operator domain".
I think the situation here is a bit different, since at least MN, MSP
(=ASP if ASP assigns HA to MN) and MSA must all understand the same
format and ASP and MSA are different operator domains. 

My point was that without specifying a encoding format, there might be
problems due to different understanding of the format (e.g., MN uses
different protocol than assigned by network). Not sure if the draft can
say something like "How the mobility protocol is encoded into the FQDN
is not specified, but the implementors must make sure that all involved
entities from different operator domains understand the same encoding". 

BTW, the IAB document RFC4367 talks about problems of information
encoded in domain names and recommends that "the behavior of the
protocol machinery should never change based on the domain name of the
host."

Regards,

Kilian

> 
> Cheers,
> 	Jouni
> 
> > 
> > Cheers,
> > 
> > Kilian
> > 
> > > -----Original Message-----
> > > From: Jouni Korhonen [mailto:[email-masked]]
> > > Sent: Mittwoch, 28. Februar 2007 10:55
> > > To: Kilian Weniger
> > > Cc: Chowdhury, Kuntal; Heejin Jang; [email-masked]; Basavaraj Patil
> > > Subject: Re: [Mip6] WGLC: 
> > draft-ietf-mip6-bootstrapping-integrated-02
> > > 
> > > Hi Kilian,
> > > 
> > > 
> > > [snip]
> > > 
> > > >> I heard at least one operator requesting such feature (and
> > > note that
> > > >> this is in principle possible with the HA discovery/assignment 
> > > >> mechanisms defined in the split scenario bootstrapping 
> draft). A
> > > > simple
> > > >> way to support this in the integrated scenario would be to add
> > > > something
> > > >> like a "type of requested HA service" field in the 
> Home Network 
> > > >> Identifier Option of the DHCP information request sent by
> > > the MN. The
> > > >> new field would encode the type of service, e.g., 0=MIPv6,
> > > 1=DS-MIPv6,
> > > >> 2=NEMO,...). Similarly, the Home Network Information
> > > Sub-option could
> > > >> include a "type of HA service" field to inform the MN
> > > about the type
> > > > of
> > > 
> > > Good point imho.
> > > 
> > > >> service supported by the HA offered in this option. 
> > > However, since the
> > > >> AAAH wouldn't know the HA service requested by the MN,
> > > AAAH would need
> > > >> to send at least one HA address per supported service 
> to the NAS.
> > > >>
> > > > [KC>] Alternatively, we can encode the Home Network
> > > Identifier (FQDN) as
> > > > ha.dsmip6.domain, ha.mip6.domain. This is possible with 
> > the current 
> > > > HIOPT I-D, no? From the AAAH perspective, it (AAAH) needs
> > > to send the HA
> > > > address - Service pair. The service can be indicated by the
> > > FQDN AVP. We
> > > > have the following AVPs in 
> draft-ietf-dime-mip6-integrated-03.txt:
> > > > 
> > > >                                 [ MIP6-Home-Agent-Address ]
> > > >                                 [ MIP6-Home-Agent-FQDN ]
> > > 
> > > Using different FQDNs under the same operator domain for 
> > > differentiating between types of service nodes is already 
> > practised in 
> > > some 'relevant'
> > > SDOs. In that sense I think it could be a good approach. 
> Dime's I-D 
> > > draft-ietf-dime-mip6-integrated allows a NAS to give hints 
> > already to 
> > > the AAAH using AVPs mentioned above and since we are about 
> > to revise 
> > > the Dime I-D this part could be clarified further.
> > > 
> > > > Perhaps we can group them under a new AVP for service, e.g.
> > > > MIP6-Home-Agent-Info AVP. For RADIUS we can perhaps link 
> > the MIP6-HA 
> > > > Attribute and MIP6-HA-FQDN Attribute.
> > > 
> > > There was also some other SDO asking for more generic 'ASP 
> > info' AVP 
> > > e.g. for local HA assignment. MAybe these could be combined.
> > > IMHO this
> > > discussion should be brought to Dime as well.
> > > 
> > > Cheers,
> > > 	Jouni
> > > 
> > > > 
> > > > 
> > > > 
> > > >> What do you think?
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Kilian
> > > >>
> > > >>
> > > >> Panasonic R&D Center Germany GmbH
> > > >> 63225 Langen, Hessen, Germany
> > > >> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas 
> > > >> Micke
> > > >>
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Mip6 mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/mip6
> > > > 
> > > 
> > > 
> > 
> > 
> > Panasonic R&D Center Germany GmbH
> > 63225 Langen, Hessen, Germany
> > Reg: AG Offenbach (Hessen) HRB 33974
> > Managing Director: Thomas Micke
> > 
> > 
> > 
> 
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

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