Subject: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 10 Mar 2007 17:02:30 -0800

Hello,

This is a two week working group last call for
draft-ietf-mipshop-mis-ps-00.txt. You can find the
document at the following URL.

http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mis-ps-00.txt

The last call expires on March 26 2007.

Please post any issues or comments on this document to
the MIPSHOP WG mailing list. In case you have reviewed
the document and found no issues, please send an email
saying you support advancing this document.

The intended status for this document is Informational.

Vijay

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

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 12 Mar 2007 01:13:29 +0200

Vijay,

If not mandated, it is at least a recommended practice not to overlap a LC
with the IETF week. Could you please move the call to after the IETF week?

Alper

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Sunday, March 11, 2007 3:03 AM
> To: [email-masked]
> Subject: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps
> 
> Hello,
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 11 Mar 2007 16:28:32 -0700

> with the IETF week. Could you please move the call to after the IETF week?

Why is that? In fact I see that folks are more active around
the IETF meeting week, read more documents and send in more
comments. :)

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 12 Mar 2007 02:33:20 +0200

I think it is right that people are tuning into the IETF matters the weeks
before IETF. But the other fact is that, people go to IETF for attending
official and unofficial meetings, do face-to-face discussions. Not to sit by
themselves and read full documents and write down comments. 

I have heard this from ADs enough many times. But I don't know if this is
written anywhere. 

Alper

> Sent: Monday, March 12, 2007 1:29 AM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps
> 
> Alper Yegin wrote:
> > Vijay,
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 11 Mar 2007 20:35:53 -0700

> themselves and read full documents and write down comments. 

Ok. Let me extend it by another week.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 11 Mar 2007 20:37:14 -0700

The last call expires on April 2 2007.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 12 Mar 2007 10:28:42 +0200

Thank you.

Alper

> Sent: Monday, March 12, 2007 5:36 AM
> To: Alper Yegin
> Cc: [email-masked]
> >>> If not mandated, it is at least a recommended practice not to overlap
> a
> >> LC

---

From: "Daniel Park" <[email-masked]>
Date: Tue, 13 Mar 2007 01:09:19 +0900

I've read this document again.

First off:

I am not familiar with the subject of this document. As I pointed out
before, this document does not mention *problem statements* clearly.
Rather, it is entirely focusing on the solution space. What's the
intention of this document ? Also, the scope of this document is too
much wide. Here is the previous thread on this concern: (it was
silently discarded though.)
http://www1.ietf.org/mail-archive/web/mipshop/current/msg02879.html

Also, I am really confused what consistency happens between DT and
this document. Most stuffs in the PS document seem to be in DT's
effort especially solution components. No matter which document would
address these aspects, but the current situation seems a bit weird. DT
is working for another things ? Or trying to meet the requirement and
solution components described in the PS document ? The solution
components described in this document implies WG consensus in
accordance with IEEE 802.21 consensus ?

Further details will be forthcoming, but hope to see the clarification
on this matter above first.

Daniel

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 12 Mar 2007 16:48:10 -0000

daniel, 

> From: Daniel Park [mailto:[email-masked]] 
> Sent: 12 March 2007 16:09
> To: Vijay Devarapalli
> Cc: [email-masked]
> I am not familiar with the subject of this document. As I 
> pointed out before, this document does not mention *problem 
> statements* clearly.
> Rather, it is entirely focusing on the solution space. What's 
> the intention of this document ? Also, the scope of this 
> document is too much wide. Here is the previous thread on 
> this concern: (it was silently discarded though.) 

i believe that thread was discussing this document:
http://tools.ietf.org/html/draft-melia-mipshop-mobility-services-ps-00
"Mobility Services: Problem Statement" of 40 pages.

the current document is
http://tools.ietf.org/html/draft-ietf-mipshop-mis-ps-00
"Mobility Independent Services: Problem Statement" of 19 pages.

the last substantive comment in the thread was from Behcet
"change the title and then remove all annexes"

well, i think the title could still be made more precise (to 
point to the content of section 5.1, which is the main purpose of
the document), but what else do you think has been ignored?

> 
> Also, I am really confused what consistency happens between 
> DT and this document. Most stuffs in the PS document seem to 
> be in DT's effort especially solution components. No matter 
> which document would address these aspects, but the current 
> situation seems a bit weird. DT is working for another things 
> ? Or trying to meet the requirement and solution components 
> described in the PS document ? The solution components 
> described in this document implies WG consensus in accordance 
> with IEEE 802.21 consensus ?

Please point out which bits you see as overlapping. Speaking
personally, my belief is that the role of the DT is to produce
a solution for the blob called "MSTP" in Figure 5, along with
any associated work needed to support that (e.g. definitions
of the boundary of the blob). I'd be interested to know if 
people think that anything else is expected, and if so what.

In terms of the relationship with .21 work, I guess that WG
consensus means "mipshop thinks that producing a solution that
fits the role of the MSTP is a useful thing to do". We hope
that a solution for the MSTP will be useful for .21 - but 
I don't see how mipshop can *decide* that, it's a matter for
.21 to judge.

robert h.

> 
> Further details will be forthcoming, but hope to see the 
> clarification on this matter above first.
> 
> Daniel
> 
> > draft-ietf-mipshop-mis-ps-00.txt. You can find the document at the 
> > following URL.
> >
> > Please post any issues or comments on this document to the 
> MIPSHOP WG 
> > mailing list. In case you have reviewed the document and found no 
> > issues, please send an email saying you support advancing this 
> > document.
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 12 Mar 2007 10:37:17 -0700

Yoshihiro Ohba wrote:

> There is a specific set of requirements on L3 transport of 802.21,
> which is described in Annex D of P802-21-D04-00.  MIPSHOP solution for
> this problem scope needs to meet those requirements to be useful for
> 802.21.  From 802.21 perspective, I think that the most important
> thing in this WG Last Call is to make sure that the requirements
> described in draft-ietf-mipshop-mis-ps covers the 802.21 requirements.

IMO, this is very important.

Vijay

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 12 Mar 2007 17:39:30 -0000

hi Yoshihiro,

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: 12 March 2007 17:31
> To: Hancock, Robert
> Cc: Daniel Park; Vijay Devarapalli; [email-masked]; 
> [email-masked]
> Hi Robert,
> (cc'ing to 802.21)
> Thank you very much for leading the Design Team.  I have one 
> comment below.

thanks - I hope I can meet people's needs.

> 
> On Mon, Mar 12, 2007 at 04:48:10PM -0000, Hancock, Robert wrote:
> > 
> consensus 
> > means "mipshop thinks that producing a solution that fits 
> the role of 
> > the MSTP is a useful thing to do". We hope that a solution for the 
> > MSTP will be useful for .21 - but I don't see how mipshop 
> can *decide* 
> > that, it's a matter for
> > .21 to judge.
> 
> There is a specific set of requirements on L3 transport of 
> 802.21, which is described in Annex D of P802-21-D04-00.  
> MIPSHOP solution for this problem scope needs to meet those 
> requirements to be useful for 802.21.  From 802.21 
> perspective, I think that the most important thing in this WG 
> Last Call is to make sure that the requirements described in 
> draft-ietf-mipshop-mis-ps covers the 802.21 requirements.

I think this is absolutely correct. We need to know if the problems
that .21 needs solving will be solved by this solution. (There could be
other reasons for mipshop people to comment on the document, but this is
the specific
thing that is important to know from .21.)

> Best Regards,
> Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Mar 2007 13:31:26 -0400

Hi Robert,

(cc'ing to 802.21)

Thank you very much for leading the Design Team.  I have one comment
below.

Best Regards,
Yoshihiro Ohba

---

From: "Daniel Park" <[email-masked]>
Date: Tue, 13 Mar 2007 04:05:55 +0900

> I don't see how mipshop can *decide* that, it's a matter for

I am afraid if you say "...how mipshop can *decide* that..." since
this document is under WGLC. It means this document is a mipshiop WG
document. Once completing its WGLC, it will may be forward to IESG for
official publication. AFAIC, that means mipshop admits the solution
components described in this document to the IETF consensus. It does
not a matter for 802.21 at all. Are you thinking that mipshop or other
WGs will develop a new solution components regardless of this  mipshop
publication ? If yes, it is a redundent effort on the same subject.

I thought DT will show up these sorts of components for MIH transport
protocol solution through their in-depth discussion.

In fact, I was surprised to see WGLC announcement. I recommand WG not
to progress WGLC on this document as it is. After looking at DT's
report in Prague meeting, then WG will be able to resume its process.

Daniel

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 12 Mar 2007 12:22:05 -0700

> report in Prague meeting, then WG will be able to resume its process.

This last call is on a problem statement document. The
document provides a problem definition, deployment scenarios
and the required solution components. It does not tie us
to a particular solution.

If you think the problem statement is tying us to a
particular solution, please point out those parts of the
draft. We can remove that text.

Vijay

---

From: Subir Das <[email-masked]>
Date: Mon, 12 Mar 2007 16:01:37 -0400

Agree. Another option:

Once MIPSHOP completes the design and gain consensus
within IETF, the document can be sent to .21 via the liaison
for their review.

OTH, I assume since there are some folks who attend both IETF
and .21 it is very unlikely that things will not be noticed
or discussed if the solution does not address .21 requirements.

-Subir

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 12 Mar 2007 22:27:13 +0200

> to a particular solution.

Why would a so-called "problem statement" document ever talk about "solution
components"?

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 12 Mar 2007 13:41:32 -0700

> Why would a so-called "problem statement" document ever talk about "solution

I was talking about what is there in the document currently.
There is no particular format for a problem statement. It
is for the working group to decide what goes into it.

Folks, please review the document and if you have any
comments, please post them to the mailing list. If you have
specific suggestions for text changes, it will help.

Vijay

---

From: "Daniel Park" <[email-masked]>
Date: Wed, 14 Mar 2007 04:46:44 +0900

Sorry if I am digressing from the core. But I am still confused why
solution components and relevant framework are included in this
document. To me, these parts are not ready to be moved forward. Ok, I
will wait for DT's presentation in Prague, and get back to the list
with more technical comments.

Daniel

--

---

From: Anurag Uxa <[email-masked]>
Date: Wed, 14 Mar 2007 14:20:26 +0530

I have reviewed the draft-ietf-mipshop-mis-ps. I didn't find convincing 
solution for the neighbor-hood discovery for heterogeneous networks. I 
still feel the discovery should not be the job of light weight router(Like 
Access Router). There is no need to have information about peer-hood ACRs 
or ARs . I feel this job should be more related to Edge Routers which 
should be or might be(future for IP) connected to IP Banck bone.

Regards
----------------------------------------------------------------------
Anurag Uxa
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
( ) L&T Infotech Proprietary & Confidential
(+) L&T Infotech Confidential
( ) L&T Infotech Internal Use only
( ) General Business Information
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

"Alper Yegin" <[email-masked]> 
03/13/2007 01:57 AM

To
"'Vijay Devarapalli'" <[email-masked]>, "'Daniel Park'" 
<[email-masked]>
cc
[email-masked]
Subject
RE: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps

> to a particular solution.

Why would a so-called "problem statement" document ever talk about 
"solution
components"?

______________________________________________________________________

______________________________________________________________________

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Mar 2007 07:23:31 -0400

Neighborhood discovery for heterogeneous networks is being defined as
an 802.21 service (i.e., Information Service) which allows information
server to be located at any node.  From 802.21 perspective, secure L3
transport for 802.21 services as well as 802.21 point of service
discovery at L3 (note: point of service discovery is different from
neighborhood discovery) are missing pieces and expected to be defined
in MIPSHOP.

Regards,
Yoshihiro Ohba

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 14 Mar 2007 16:41:24 -0000

daniel,

i can attempt to answer part of your question. 

> Sent: 13 March 2007 19:47
> To: Vijay Devarapalli
> Cc: [email-masked]
> Sorry if I am digressing from the core. But I am still 
> confused why solution components and relevant framework are 
> included in this document. 

The situation we have here is that there are two "problems":
(1) how to do signalling for handover control & associated 
functions (this is the overall problem)
(2) how to carry those signalling messages in IP networks
(which is a sub-problem of (1) above)

My understanding is that the design team is working on a solution
to problem (2), and that the PS draft is a statement of what
problem (2) actually is. However, to understand problem (2), it
is helpful to explain how it fits into problem (1).

So the 'solution components' are just a suggestion of how (2) would
fit together with other things to solve (1). I don't think we
are trying to prove that this is the correct way to solve (1), 
and in any case that is out of scope of the activity (as I 
understand the charter); however, the explanation of how (2)
fits into the bigger picture is I think helpful background for
making sure that our solution for (2) is actually useful.

We've already identified in the DT that we need better terms
for (1) and (2). Since 50% of the DT are also authors of the PS
draft, I hope that we can synchronise this pretty efficiently.

hope this helps,

robert h.

> To me, these parts are not ready 
> to be moved forward. Ok, I will wait for DT's presentation in 
> Prague, and get back to the list with more technical comments.
> 
> Daniel
> 
> > >> This last call is on a problem statement document. The document 
> > >> provides a problem definition, deployment scenarios and the 
> > >> required solution components. It does not tie us to a particular 
> > >> solution.
> > >
> > >
> > > "solution components"?
> is for the 
> > working group to decide what goes into it.
> >
> comments, please 
> > post them to the mailing list. If you have specific suggestions for 
> > text changes, it will help.
> >
> > Vijay
> >
> 
> 
> -- 
> 
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 14 Mar 2007 17:56:18 -0000

hi all,

I agree with Yoshihiro here. Neighbourhood discovery (e.g. finding out
about local access
points and so on) is part of the overall handover control signalling
problem. Using the
802.21 technology, the information could be provided by the MIIS for
example. 

The mipshop work is to not to provide that discovery function; it is to
support the 
transfer of MIIS (and other) messages. This might involve discovering
the MIIS entity,
but as Yoshihiro says, that is different from neighbourhood discovery.

Robert H.

> Sent: 14 March 2007 11:24
> To: Anurag Uxa
> Cc: [email-masked]; 'Vijay Devarapalli'
> Neighborhood discovery for heterogeneous networks is being 
> defined as an 802.21 service (i.e., Information Service) 
> which allows information server to be located at any node.  
> From 802.21 perspective, secure L3 transport for 802.21 
> services as well as 802.21 point of service discovery at L3 
> (note: point of service discovery is different from 
> neighborhood discovery) are missing pieces and expected to be 
> defined in MIPSHOP.
> 
> Regards,
> Yoshihiro Ohba
> 
> > I have reviewed the draft-ietf-mipshop-mis-ps. I didn't find 
> > convincing solution for the neighbor-hood discovery for 
> heterogeneous 
> > networks. I still feel the discovery should not be the job of light 
> > weight router(Like Access Router). There is no need to have 
> > information about peer-hood ACRs or ARs . I feel this job should be 
> > more related to Edge Routers which should be or might 
> be(future for IP) connected to IP Banck bone.
> > 
> > Regards
> > 
> > > provides a problem definition, deployment scenarios and 
> the required 
> > > solution components. It does not tie us to a particular solution.
> > 
> >

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 14 Mar 2007 13:09:13 -0700

Incidentally, there is "neighborhood discovery" in FMIP. It involves
discovering neighboring subnet information (called AR-Info in RFC 4068,
RFC4068bis). FMIP provides the Proxy Router signaling to resolved
neighboring access points to this AR-Info. It does not specify how the
neighborhood information is populated on the access routers.

This should be clarified.

Regards,

-Rajeev

---

From: <[email-masked]>
Date: Wed, 14 Mar 2007 15:31:17 -0500

Colleagues,

Just a comment that FMIP in general has done an great job of
incorporating the learnings and advances from .21 and elsewhere directly
into the L3 protocol when possible.

BR,
Michael

-----Original Message-----
From: ext Rajeev Koodli [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 4:09 PM
To: ext Hancock, Robert; Yoshihiro Ohba; Anurag Uxa
Cc: [email-masked]; Vijay Devarapalli
Subject: Re: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps

Regards,

-Rajeev

> about local access points and so on) is part of the overall handover 
> control signalling problem. Using the
> The mipshop work is to not to provide that discovery function; it is 
> to support the transfer of MIIS (and other) messages. This might 
> involve discovering the MIIS entity, but as Yoshihiro says, that is 
> different from neighbourhood discovery.
> 
> Robert H.
> 

>> an 802.21 service (i.e., Information Service) which allows 
>> information server to be located at any node.
>> From 802.21 perspective, secure L3 transport for 802.21 services as 
>> well as 802.21 point of service discovery at L3
>> (note: point of service discovery is different from neighborhood 
>> discovery) are missing pieces and expected to be defined in MIPSHOP.
>> 
>> Regards,
>> Yoshihiro Ohba
>>

---

From: Anurag Uxa <[email-masked]>
Date: Thu, 15 Mar 2007 11:12:46 +0530

Pls find the reply Inline.
Regards

Yoshihiro Ohba <[email-masked]> 
03/14/2007 04:53 PM

To
Anurag Uxa <[email-masked]>
cc
Alper Yegin <[email-masked]>, [email-masked], "'Vijay 
Devarapalli'" <[email-masked]>
Subject
Re: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps

Neighborhood discovery for heterogeneous networks is being defined as
an 802.21 service (i.e., Information Service).
True. If MIH protocol is running and PSS information is relayed to IS 
services via ACR or AR. 
There are conditions 
1. All network should have MIH support and then IS Server can populate its 
database based on information by sending MIH_get_informatin.request.
2.Its a costly as well as time consuming opration for a PSS(MN) to get 
information from IS Server where It wants the pre indication for 
FMIPv6(MIH User).MN can cash the information prior but IS Server's 
updation is periodically so MN need to confirm before sending FBU.
BUT your draft abstract says IP handover mechanisms between heterogeneous
   wired and wireless access systems including, but not limited to, IEEE
   802.21.  Intelligent access selection, taking into account link layer
   attributes, requires the delivery of a variety of different
   information types to the terminal from different sources within the
   network and vice-versa.
 which allows information server to be located at any node.  From 802.21 
perspective, secure L3
transport for 802.21 services as well as 802.21 point of service
discovery at L3 (note: point of service discovery is different from
neighborhood discovery) are missing pieces and expected to be defined
in MIPSHOP.

FMIPv6(MIH user) specification talks about policy based handover too. with 
or without MIH. Edge router any way are having the information about the 
PoA to extend the RS/RA or via Routing protocols we can think of getting 
QoS related parameters(information). The same thing is described by your 
draft also in brief too.
This Internet Draft provides a problem statement for the exchange of
   information to support handover in heterogeneous link environments.
   This mobility support service allows more sophisticated handover
   operations by making available information about network
   characteristics, neighboring networks and associated characteristics,
   indications that a handover should take place, and suggestions for
   suitable target networks to which to handover.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 20 Mar 2007 08:35:01 -0400

Hi Anurag,

> database based on information by sending MIH_get_informatin.request.

How IS server constructs its database is out of scope of 802.21.
Also, what do you mean by "all network should have MIH support" and
why?

> updation is periodically so MN need to confirm before sending FBU.

In 802.21, the IS server is not supposed to support dynamically
changing information which requires periodical update.

>    information types to the terminal from different sources within the

Sure.  My comment was mostly from IEEE 802.21 perspective.

> QoS related parameters(information). The same thing is described by your 

I think this level of details is a bit too specific for PS draft.  I
don't think the current draft precludes your scenario.

Regards,
Yoshihiro Ohba

---

From: Anurag Uxa <[email-masked]>
Date: Tue, 20 Mar 2007 18:36:19 +0530

03/20/2007 06:05 PM

To
Anurag Uxa <[email-masked]>
cc
Yoshihiro Ohba <[email-masked]>, Alper Yegin 
<[email-masked]>, [email-masked], "'Vijay Devarapalli'" 
<[email-masked]>
Subject
Re: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps

Hi Anurag,

I just wanted to convey that MIH capable network should include it in its 
capability broadcast message(Like WLan becons should show its a MIH 
capable n/w).

Regards
Anurag uxa

Regards,
Yoshihiro Ohba

> > I have reviewed the draft-ietf-mipshop-mis-ps. I didn't find 
convincing

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 20 Mar 2007 14:12:09 +0100

hi all,

Hi Anurag,

I just wanted to convey that MIH capable network should include it in its
capability broadcast message(Like WLan becons should show its a MIH capable
n/w).  

My understanding is that questions like L2 capability broadcast in beacons
and so on are totally out of scope for the mipshop work. That doesn't stop
the PS document noting the functionality and pointing out that it is a
separate part of the solution architecture. Probably about 50% of people
think that information is good to add and 50% think that it makes the
document too long/too general/too confusing/and so on. This seems to be a
general problem with problem statements.
 
robert h. 

Regards 
Anurag uxa 

Regards,
Yoshihiro Ohba

> > should be or might be(future for IP) connected to IP Banck bone.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------------
> > ( ) General Business Information
----------------------------------------------------------------------------
----------------------------------------------------------------------------
----------------------------------------------------------

---

From: Anurag Uxa <[email-masked]>
Date: Tue, 20 Mar 2007 18:52:02 +0530

"Robert Hancock" <[email-masked]> 
03/20/2007 06:42 PM

To
"'Anurag Uxa'" <[email-masked]>, "'Yoshihiro Ohba'" 
<[email-masked]>
cc
<[email-masked]>, "'Vijay Devarapalli'" 
<[email-masked]>
Subject
RE: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps

hi all,
Hi Anurag,

 
Hi Robert,

Yes its certainly a issue regarding a L2 capabilty. Can we discuss or 
think if we can take MIH broadcasting after L2 establishment. WLAN AP will 
work here as a normal L2 Bridge. We can broadcast this message via L3(Like 
router adv.).

Regards 
Anurag uxa 

Regards,
Yoshihiro Ohba

convincing

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 20 Mar 2007 11:41:32 -0400

Hi, Anurag

> work here as a normal L2 Bridge. We can broadcast this message via L3(Like 

802.21 allows MIH capability message to be broadcast in both media
dependent and independent ways.  Said that, use of L3 for broadcasting
MIH capability message seems to be a valid 802.21 scenario.

Yoshihiro Ohba

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 20 Mar 2007 16:56:24 +0100

Hi all,

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.

telemaco

telemaco

---

From: Anurag Uxa <[email-masked]>
Date: Wed, 21 Mar 2007 10:41:07 +0530

Hi  All,

I have one doubt. As there are multiple DHCP6 servers and all listen on 
multicast address ff05::1:3 (multicast address with global scope). Will it 
be good idea to extend DHCP Server and client messages for query& update 
IS server information. Can't we use specific global multicast address for 
IS Server. 

Regards
----------------------------------------------------------------------
Anurag Uxa
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
( ) L&T Infotech Proprietary & Confidential
( ) L&T Infotech Confidential
( ) L&T Infotech Internal Use only
(+) General Business Information
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Telemaco Melia <[email-masked]> 
03/20/2007 09:26 PM

To
Yoshihiro Ohba <[email-masked]>
cc
Anurag Uxa <[email-masked]>, [email-masked], 'Vijay 
Devarapalli' <[email-masked]>
Subject
Re: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps

Hi all,

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.

telemaco

telemaco

Yoshihiro Ohba wrote: 
Hi, Anurag

router adv.).

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 21 Mar 2007 09:25:12 +0100

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

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 21 Mar 2007 14:10:03 +0100

Hi Alper,

I would suggest to wait for tomorrow's DT presentation.

telemaco

-- 
Telemaco Melia          	[email-masked]
Research Staff Member		Tel: +49 (0) 6221 4342- 142
Network Laboratories    	Fax: +49 (0) 6221 4342- 155
NEC Europe Ltd.         	Web: http://www.netlab.nec.de
Network Laboratories           
Kurfuersten-Anlage 36       
69115 Heidelberg
GERMANY   

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Mar 2007 14:17:06 +0100

You still might want to explain these aspects on the mailing list given 
that not everyone will be able to see the presentation.

Ciao
Hannes

Telemaco Melia wrote:
>>     The DT is currently considering different scenarios and 
>> associated     requirements targeting a single solution.

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 21 Mar 2007 06:15:15 -0700

Indeed. However, I need to add something. Alper, can you help me understand in which forum or framework or circle it is an accepted scenario that ES and CS are taken care at L2? That may be true for some (few) access technologies, but cannot be generalized, therefore there is the need for a L3 solution. As a matter of fact, there is plenty of discussion going on on why it is useful to have it @ L3 for many technologies, in particular to have a technology independent solution for multi-mode terminals and networks.
 
If we want to talk about L2 solution, there are technologies (e.g. 802.11) that have solutions @ L2.  
 
Stefano

________________________________

From: Telemaco Melia [mailto:[email-masked]]
Sent: Wed 3/21/2007 6:10 AM
To: Alper Yegin
Cc: [email-masked]; [email-masked]; 'Vijay Devarapalli'
Subject: Re: [Mipshop] DHCP

Hi Alper,

telemaco

--
Telemaco Melia                  [email-masked]
Research Staff Member           Tel: +49 (0) 6221 4342- 142
Network Laboratories            Fax: +49 (0) 6221 4342- 155
NEC Europe Ltd.                 Web: http://www.netlab.nec.de <http://www.netlab.nec.de/> 
Network Laboratories          
Kurfuersten-Anlage 36      
69115 Heidelberg
GERMANY

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 21 Mar 2007 14:58:17 +0100

Stefano,

I'm not denying the need for a L3 ES and CS transport.

I'm saying L2 ES and CS transport is also one of the accepted scenarios.

Are we not on the same page?

Alper

  _____  

From: Stefano Faccin [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 2:15 PM
To: Telemaco Melia; Alper Yegin
Cc: [email-masked]; [email-masked]; Vijay Devarapalli
Subject: RE: [Mipshop] DHCP

Indeed. However, I need to add something. Alper, can you help me understand
in which forum or framework or circle it is an accepted scenario that ES and
CS are taken care at L2? That may be true for some (few) access
technologies, but cannot be generalized, therefore there is the need for a
L3 solution. As a matter of fact, there is plenty of discussion going on on
why it is useful to have it @ L3 for many technologies, in particular to
have a technology independent solution for multi-mode terminals and
networks.

If we want to talk about L2 solution, there are technologies (e.g. 802.11)
that have solutions @ L2.  

Stefano

  _____  

Hi Alper,

telemaco

<http://www.netlab.nec.de/> 
Network Laboratories          
Kurfuersten-Anlage 36      
69115 Heidelberg
GERMANY  

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
W3 6BL | Registered in England 2832014

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 21 Mar 2007 07:03:29 -0700

Alper, 

it really sounded like ES and CS @ L2 are "the" solution so there is no
need for ES and CS at L3, that's why I reacted. If we agree on the need
for ES and CS @ L3, then I am fine, and I would avoid further references
to what is being done or not @ L2, since we're here to work on the L3
solution. Whether the same protocol needs to provide all three service
or not is another question, and I would not discuss its merit at this
point (that's more of DT decision than a chair suggestion).

Stefano

From: Alper Yegin [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 6:58 AM
To: Stefano Faccin; 'Telemaco Melia'
Cc: [email-masked]; [email-masked]; 'Vijay Devarapalli'
Subject: RE: [Mipshop] DHCP

Stefano,

Alper

Indeed. However, I need to add something. Alper, can you help me
understand in which forum or framework or circle it is an accepted
scenario that ES and CS are taken care at L2? That may be true for some
(few) access technologies, but cannot be generalized, therefore there is
the need for a L3 solution. As a matter of fact, there is plenty of
discussion going on on why it is useful to have it @ L3 for many
technologies, in particular to have a technology independent solution
for multi-mode terminals and networks.

If we want to talk about L2 solution, there are technologies (e.g.
802.11) that have solutions @ L2.  

Stefano

Hi Alper,

telemaco

>       The DT is currently considering different scenarios and
associated

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 10:34:53 -0500

Hi Alper,
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
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

	discovery.

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

---

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

Thanks Srini.
This should also answers Hannes request.

telemaco 

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

Hi Alper,
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 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

	discovery.

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

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 21 Mar 2007 17:20:15 +0100

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? 

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

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 28 Mar 2007 21:19:04 +0300

I just read the document and here are my comments.

The title reads "Problem Statement". But the document contains not only a
problem statement, but also some of "requirements", "design considerations",
"analysis of alternative solutions", "formats", "layering", etc. I don't
think it makes sense to get into all of that. We shall be more strict about
what we have in this document. Let's agree on the desired scope and have a
complete document on that, and just be silent about anything else.

As for the relationship to IEEE 802.21... I have always been under the
impression that, we'd be defining the transport protocol for their IS, ES,
and CS. Can we confirm that's our goal and nothing about going beyond IEEE
802.21? And if that's the case, I'd naturally think that the generic problem
statement and even requirements shall be defined by IEEE, and we at IETF
simply use those in defining the transport. Or, our problem statement simply
becomes: Define the L2-agnostic transport for IEEE 802.21.

I don't understand what "Mobility Independent Services" really means.
Independent of mobility?? 

What does "mobility service" mean? Is "Mobile IPv4" an example of such?

I see scenarios defined in 4.2, 4.3, and 4.4. Are these definitions coming
from IEEE? If not, it is not clear from this document why we have such
scenarios? They are not simply all possible permutations, are they?

   Much of the functionality required for this problem is available from
   existing IETF protocols or combination thereof.  

Probably it is true, but in the absence of an analysis in this document, it
is not really valuable to make such statements. 
 
Regards,

Alper