Subject: [MIPSHOP-MIH-DT] FW: [Mipshop] DHCP

From: "Telemaco Melia" <[email-masked]>
Date: Wed, 21 Mar 2007 17:33:08 +0100

Hi all,

Should we explicitly mention in the PS doc that a single MSTP for all mobility services is preferable?

tele

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 5:20 PM
To: [email-masked]; [email-masked]; Telemaco Melia
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Mipshop] DHCP

Hi Srini,

> MIPSHOP is only aware of a MIH protocol not its constituents. The 
> transport characteristics being the same, the requirements from 802.21 
> have been for a single transport. This is not to say that DHCP may not

Could you please expand what you mean by "single transport"? You mean all IS, ES, and CS shall be transported by the same protocol? 

We are proposing to use DHCP for IS only, not for ES or CS.

Alper

> meet all the MIH protocol requirements. Both L2 and L3 are suitable 
> for the entire MIH protocol covering all services. As such, it is also 
> acceptable that the MIPSHOP provided transport could be specifically 
> used for a certain functionality and a L2 transport can be used for 
> others.
> 
> Regards,
> Srini
> 
> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2007 3:25 AM
> To: 'Anurag Uxa'; 'Telemaco Melia'
> Cc: [email-masked]; [email-masked]; 'Vijay Devarapalli'
> Subject: RE: [Mipshop] DHCP
> 
> 	There have been already proposals using DHCP for 802.21 services
> 
> 	discovery.
> 
> 	The DT is currently considering different scenarios and associated
> 	requirements targeting a single solution.
> 	This might change if complexity increases too much.
> 
> 
> I don't understand why designing one protocol that does three things 
> (IS, ES, CS) is better than using an existing protocol (DHCP) for what 
> it has used for (configuration [IS]), and designing another protocol 
> that takes care of the other two (ES, CS).
> 
> I'm not aware of any technical reason that requires all three 
> functionalities to be bundled up in single protocol. And in fact, I 
> see reason to separate them. It is an accepted scenario that ES and CS 
> are taken care of by the L2 in some networks, leaving IS to L3.
> 
> Comments?
> 
> Alper
> 
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 11:54:40 -0500

Hi Tele,
Yes, if not already. The requirements have not differentiated the
different contents/functionalities in the MIH protocol from the
transport point of view.  

>From my point of view, splitting the functionalities limits the
deployment scope of the standard. It may require additional protocol
interaction between IS and ES/CS servers that are not considered within
the problem scope or standardized anywhere.

Regards,
Srini

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 11:33 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] FW: [Mipshop] DHCP

Hi all,

Should we explicitly mention in the PS doc that a single MSTP for all
mobility services is preferable?

tele

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, March 21, 2007 5:20 PM
To: [email-masked]; [email-masked];
Telemaco Melia
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Mipshop] DHCP

Hi Srini,

> have been for a single transport. This is not to say that DHCP may not

Could you please expand what you mean by "single transport"? You mean
all IS, ES, and CS shall be transported by the same protocol? 

Alper

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 21 Mar 2007 18:18:26 +0100

hi all, 

personally i would leave this out. in some sense, it is not a well
defined position: for example, given that the MSTP might be a
wrapper (which defines the use of a 'traditional' transport protocol
or two and a small handful of discovery mechanisms), in what sense
is that a 'single' MSTP compared to multiple ones?

what we are actually talking about here is a set of design goals
about deployability, simplicity, extensibility and so on. we should
handle that as design work.

DNS requires both UDP and TCP. does that mean that the DNS design
is wrong? I wouldn't say so - it's the result of a tradeoff. i
think we can leave ourselves to make that tradeoff.

robert h.

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 21 March 2007 17:55
> To: [email-masked]; [email-masked]
> Subject: RE: [MIPSHOP-MIH-DT] FW: [Mipshop] DHCP
> 
> Hi Tele,
> Yes, if not already. The requirements have not differentiated 
> the different contents/functionalities in the MIH protocol 
> from the transport point of view.  
> 
> deployment scope of the standard. It may require additional 
> protocol interaction between IS and ES/CS servers that are 
> not considered within the problem scope or standardized anywhere.
> 
> Regards,
> Srini
> 
> To: [email-masked]; 
> [email-masked]; Telemaco Melia
> Could you please expand what you mean by "single transport"? 
> You mean all IS, ES, and CS shall be transported by the same 
> protocol? 
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 21 Mar 2007 13:15:56 -0400

I agree with both of you, but I would not like to make it too strict
like "shall" or "must" use one single protocol. I think that there could
be scenarios where some information could be sent with one transport
service (eg DHCP) and a second one with another (eg MSTP).

If we write it, I'd rather keep the "preferable" word as Tele put it.

Jc

-----Original Message-----
Sent: March 21, 2007 12:55 PM

Hi Tele,

Regards,
Srini

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 11:33 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] FW: [Mipshop] DHCP

Hi all,

tele

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, March 21, 2007 5:20 PM
To: [email-masked]; [email-masked];
Telemaco Melia

Hi Srini,

Alper

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 12:39:35 -0500

Hi Robert,
Ideally, MIPSHOP has no knowledge of different protocol functionalities
in MIH. I am not saying you cannot have two options like tcp/udp in the
transport. But we should not end up in a situation where we have
different protocol choices for different functionalities and possibly
more than than one protocol for the same functionality e.g. DHCP and UDP
for MIH IS. Very simple to see the interoperability issues here.

I would entirely remove/not add the sentence, if we were to use the word
"preferable". Mainly because it is not sufficient since the PS is
addressing those issues related to using different protocols.

Regards,
Srini

-----Original Message-----
From: ext Robert Hancock [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 12:18 PM
To: Sreemanthula Srinivas (Nokia-SIR/Dallas);
[email-masked]; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] FW: [Mipshop] DHCP

hi all, 

personally i would leave this out. in some sense, it is not a well
defined position: for example, given that the MSTP might be a wrapper
(which defines the use of a 'traditional' transport protocol or two and
a small handful of discovery mechanisms), in what sense is that a
'single' MSTP compared to multiple ones?

what we are actually talking about here is a set of design goals about
deployability, simplicity, extensibility and so on. we should handle
that as design work.

DNS requires both UDP and TCP. does that mean that the DNS design is
wrong? I wouldn't say so - it's the result of a tradeoff. i think we can
leave ourselves to make that tradeoff.

robert h.

> interaction between IS and ES/CS servers that are not considered 
> within the problem scope or standardized anywhere.
> 
> Regards,
> Srini
> 
> You mean all IS, ES, and CS shall be transported by the same protocol?
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 21 Mar 2007 13:38:18 -0400

Hi Robert,

Somehow your response appeared in my inbox after I had sent my mail.
I agree that we can leave it out of the PS and handle it as a trade-off
in the DT.

Regards,

Jc

-----Original Message-----
From: Robert Hancock [mailto:[email-masked]] 
Sent: March 21, 2007 1:18 PM
To: [email-masked]; [email-masked];
[email-masked]

hi all, 

robert h.

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 21 Mar 2007 10:41:37 -0700

Hi,
thank you all!!! Finally a real DT discussion!

One favor: when replying, can you reply ONLY to the DT list, not all the other authors in previous e-mails? That's why e-mails reach the inbox out of sequence.

Stefano

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 21 Mar 2007 18:50:46 +0100

srini,

i think we are talking past each other. it's clear that an
MIH/MSTP implementation should not have the flexibility to
make incompatible MSTP option choices depending on what
service is being used. interoperability is an absolute
requirement. 

however, it is still quite possible for the MSTP to consist
of a family of solutions, and for the 'MIH over MSTP' 
specification to say ES goes over option A and IS over
option C (or whatever). it happens to be that this has a 
direct impact on the syntax of the MIH/MSTP interface (see 
the earlier slides).

it just so happens that the solution I originally proposed
is an integrated solution. however, it is an integrated 
solution which contains several components, so whether it
is really a single protocol is somehow ill-defined.

r.

> Sent: 21 March 2007 18:40
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Ideally, MIPSHOP has no knowledge of different protocol 
> functionalities in MIH. I am not saying you cannot have two 
> options like tcp/udp in the transport. But we should not end 
> up in a situation where we have different protocol choices 
> for different functionalities and possibly more than than one 
> protocol for the same functionality e.g. DHCP and UDP for MIH 
> IS. Very simple to see the interoperability issues here.
> 
> I would entirely remove/not add the sentence, if we were to 
> use the word "preferable". Mainly because it is not 
> sufficient since the PS is addressing those issues related to 
> using different protocols.
> 
> Regards,
> Srini
> 
> personally i would leave this out. in some sense, it is not a 
> well defined position: for example, given that the MSTP might 
> be a wrapper (which defines the use of a 'traditional' 
> transport protocol or two and a small handful of discovery 
> mechanisms), in what sense is that a 'single' MSTP compared 
> to multiple ones?
> 
> what we are actually talking about here is a set of design 
> goals about deployability, simplicity, extensibility and so 
> on. we should handle that as design work.
> 
> DNS requires both UDP and TCP. does that mean that the DNS 
> design is wrong? I wouldn't say so - it's the result of a 
> tradeoff. i think we can leave ourselves to make that tradeoff.
> 
> robert h.
> 
> protocol

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 21 Mar 2007 18:52:35 +0100

> thank you all!!! Finally a real DT discussion!

pah! we've been having discussions for a month.
nicer to have been having them for two months, but none
of us is perfect.

> 
> One favor: when replying, can you reply ONLY to the DT list, 
> not all the other authors in previous e-mails? That's why 
> e-mails reach the inbox out of sequence.

good catch.

r.

---

From: Subir Das <[email-masked]>
Date: Thu, 22 Mar 2007 05:54:19 -0400

> direct impact on the syntax of the MIH/MSTP interface (see 
    I agree with that there may be a  family of Transport solutions but 
it is not clear to
   me why we need to separate .21 services. I had also expressed my view 
on this.
   Again I agree with Srini that regarding .21 services, it is the MIH 
protocol that will 
    interface with the MSTP,NOT individual service.
>>> Should we explicitly mention in the PS doc that a single 
>>>       
>> MSTP for all 
>>     
>>>> transport characteristics being the same, the requirements
>>>>         
>>> from 802.21
>>>
>>>       
>>>> have been for a single transport. This is not to say that
>>>>         
>>> DHCP may not
>>>
>>> You mean all IS, ES, and CS shall be transported by the 
>>>       
>> same protocol?
>>     
>>>> meet all the MIH protocol requirements. Both L2 and L3 
>>>>         
>> are suitable 
>>     
>>>> for the entire MIH protocol covering all services. As such,
>>>>         
>>> it is also
>>>
>>>       
>>>> acceptable that the MIPSHOP provided transport could be
>>>>         
>>> specifically
>>>       
>>>> used for a certain functionality and a L2 transport can 
>>>>         
>> be used for 
>>     
>>>> others.
>>>>
>>>> Regards,
>>>> Srini
>>>>
>>>> Cc: [email-masked]; [email-masked]; 'Vijay
>>>>         
>>> Devarapalli'
>>>       
>>>> 	The DT is currently considering different scenarios and
>>>>         
>>> associated
>>>       
>>>> I don't understand why designing one protocol that does
>>>>         
>>> three things
>>>       
>>>> (IS, ES, CS) is better than using an existing protocol
>>>>         
>>> (DHCP) for what
>>>
>>>       
>>>> it has used for (configuration [IS]), and designing another
>>>>         
>>> protocol
>>>       
>>>> functionalities to be bundled up in single protocol. And 
>>>>         
>> in fact, I 
>>     
>>>> see reason to separate them. It is an accepted scenario
>>>>         
>>> that ES and CS
>>>
>>>

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 22 Mar 2007 11:00:21 +0100

hi subir, 

> From: Subir Das [mailto:[email-masked]] 
> Sent: 22 March 2007 10:54
> To: Robert Hancock
> Cc: [email-masked]; 
> Subject: Re: [MIPSHOP-MIH-DT] FW: [Mipshop] DHCP
> 
> 
> 
> Robert Hancock wrote:
> > srini,
> >
> > i think we are talking past each other. it's clear that an MIH/MSTP 
> > implementation should not have the flexibility to make incompatible 
> > MSTP option choices depending on what service is being used. 
> > interoperability is an absolute requirement.
> >
> > however, it is still quite possible for the MSTP to consist of a 
> > family of solutions, and for the 'MIH over MSTP'
> > specification to say ES goes over option A and IS over option C (or 
> > whatever). it happens to be that this has a direct impact on the 
> > syntax of the MIH/MSTP interface (see the earlier slides).
> >   
>     I agree with that there may be a  family of Transport 
> solutions but it is not clear to
>    me why we need to separate .21 services. I had also 
> expressed my view on this.
>    Again I agree with Srini that regarding .21 services, it 
> is the MIH protocol that will 

well, this is the part of yesterday's meeting that you missed.
please read the slides and michael's notes. this is analysis 
that we need to do in the DT; I don't believe that any of us
yet understands the full implications of the decision here.

robert h.

> > it just so happens that the solution I originally proposed is an 
> > integrated solution. however, it is an integrated solution which 
> > contains several components, so whether it is really a 
> single protocol 
> > is somehow ill-defined.
> >
> > r.
> >
> >   
> >> functionalities in MIH. I am not saying you cannot have 
> two options 
> >> like tcp/udp in the transport. But we should not end up in a 
> >> situation where we have different protocol choices for different 
> >> functionalities and possibly more than than one protocol 
> for the same 
> >> functionality e.g. DHCP and UDP for MIH IS. Very simple to see the 
> >> interoperability issues here.
> >>
> >> I would entirely remove/not add the sentence, if we were 
> to use the 
> >> word "preferable". Mainly because it is not sufficient 
> since the PS 
> >> is addressing those issues related to using different protocols.
> >>
> >> Regards,
> >> Srini
> >>
> >> (which defines the use of a 'traditional'
> >> mechanisms), in what sense is that a 'single' MSTP compared to 
> >> multiple ones?
> >>
> design is 
> >> wrong? I wouldn't say so - it's the result of a tradeoff. 
> i think we 
> >> can leave ourselves to make that tradeoff.
> >>
> >> robert h.
> >>
> >>

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 17:10:32 -0500

it is not clear to
on this.
protocol that will 
>> contains several components, so whether it is really a single
protocol 
>> is somehow ill-defined.

I might be missing some subtleties here, but I agree with Subir here. I
think
that the MSTP will interface with the MSTP.  I actually think that
having too
many options for this will make things unnaturally complex.  I know SIP
has a huge complexitiy problem due to the fact that it runs over TCP or
UDP,
and generally (even from small, bw constrained devices) running of TCP
makes
life a lot easier.

John