Subject: RE: [Seamoby] Moving forward with paging

From: [email-masked]
Date: Mon, 4 Feb 2002 07:09:47 +0200

Hi Pat,
 
Sorry for my late comments, I completely forgot to reply to the mail.
 
My suggest was to be quite similar to what you proposed:  Use the Renker
draft as a starting point, nearly a sort of 'framework' to get the work
going.
 
Next, areas where the Renker document were deficient should be noted,
and areas where the other candidates were strong be noted as well.
 
From this, a conference call could be held to discuss the next steps
in paging could be held.  Most likely, the authors of the other documents
could help move the new work group document forward.
 
best regards,
John

-----Original Message-----
From: ext Pat R. Calhoun [mailto:[email-masked]]
Sent: 01 February, 2002 20:13
To: [email-masked]
Subject: [Seamoby] Moving forward with paging

All, 

As many of you know, last week we asked the WG for their comments on 
how to proceed with the paging work.  A summary of the comments that 
came in is: 

       Start from a known protocol - 5 
       Reopen selection phase - 3  
       Design team to start from scratch - 2  
       Drop the work altogether - 1  

Many did not give opinions obviously, and these numbers are not to be 
viewed as a "vote" (our AD reminds us that rough consensus is not 
voting).  But considering the 5 and 3, there is at least a preference 
for starting with a candidate, rather 
than from scratch. 

So the issue that needs to be resolved is which protocol should be 
used, since the protocol assessment wasn't conclusive, the chairs had 
picked one based on the findings of the assessment team. However, 
since an (admitedly useless) numbering rating scheme was used in the 
assessment, it was hard to really determine which protocol should be 
used. 

After discussing the matter ourselves, and with our AD, Allison, we 
decided to revise the paging assessment draft and remove the useless 
numerical ratings. This means that each draft must now be assessed 
using just technical merit. Further, a new section has been added to 
the document stating the chairs' basis (including charter 
reasons) for viewing the Renker draft as the starting point most 
likely to get us to the requirements and to a IETF-quality 
protocol... 

So we are calling a WG last call on the assessment document 
(draft-ietf-seamoby-paging-protocol-assessment-01.txt). We encourage 
folks to provide their *technical* comments on the draft should they 
believe that the findings of the assessment team are incorrect. We do 
ask the WG members to kindly refrain from posting any process related 
comments, since it detracts us from achieving our milestones. Once 
the WG last call is complete, we will collect the comments that have 
WG concensus and make any necessary changes to the draft. The WG last 
call ends February 25th. 

The end result is that the WG will get to decide which document is to 
be used as the *starting point*. 

Thanks for your patience, 

PatC & jak

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 8 Feb 2002 08:10:12 -0800

>  My comments follow. If these changes are incorporated, I am OK
> with this draft going  
>  for the last call.

Just for clarification - the IETF does not simply accept changes
proposed by a single person. If we have rough concensus for each
point, then they will be added to the document

> Page 13
> Draft-sarikaya was ruled out 
>   because it is based on a protocol that is currently under
> evaluation  
>   in another working group, setting up an unacceptable dependency 
>   between the Seamoby paging protocol design and the other working 
>   group's process.
> Action: add the following to this. Moreover draft-sarikaya is not
> the only draft that  has some dependency on HMIPv6. Draft-koodli
> also has included the mapping of their  protocol to HMIPv6. 

Is text along these lines in the actual review of the sarikaya draft?
It is needed in the review, as well as the summary

> Page 13
> While the assessment 
>   of draft-guri was positive, draft-guri is explicitly concerned
> with  
>   utilizing Layer 2 support for paging, and was therefore not 
>   sufficiently broad enough as a base for IP paging.
> Action: Replace by: The assessment of draft-guri was positive.

So as a point of clarification - you are stating that the assessment
of the protocol is incorrect?

> Page 13 and 14.
> Last 4 paragraphs starting with:
> Of these, both draft-renker and draft-ohba provided adequate
> support  
>   for the first two, independence of mobility protocol and support
> for  
>   existing mobility protocols.
> Until 5.0 Acknowledgements
> Action: Drop completely.
> The reasons are the following:
> 1.    Some comments on the "advantages:" of draft-renker may be
> taken to mean that: IETF > is soliciting the draft authors to have
> a long reference list of the published  literature including
> conference/journal  papers, otherwise you will be judged out not 
> knowing the field

Hmmm... This would clearly not be in the best interest of the IETF...
But I can't quite see where this implication is made. Could you be
more specific in terms of examples that led you to this conclusion?

> The fact is that the text and the related references of
> draft-renker fail to identify  clearly which is Layer 2 related
> (there is a very rich literature on the paging in  cellular
> networks which is called Layer 2 paging) and which is Layer 3
> related and some  key references on Layer 3 paging are missing.

Again, could you be more specific (examples) on how you came to this
conclusion?

> Action. Add the following text.
> As the response to the survey  sent out to the mailing list
> indicated, nobody is doing  product in this area in the near
> future, so we have some time to get this right.   

An RFC should never contain time-sensitive information, so this
cannot be added. The IETF is also not too keep on WGs that last
forever... We need an end goal.

> The Working Group wants a design that will last, like Internet
> routing has, and fit properly into the Internet architecture,
> since paging will be a key component of the future
> all-IP wireless networks.  This is naturally going to require 
> some time. 

As does any protocol design... No argument there... But define "some
time".

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Thu, 14 Feb 2002 17:17:43 -0800

> To James:
>  I appreciate your solutions but can you please bundle them in a
> draft, like draft-kempf > so that we can judge in its entirety?  

I somehow missed Jim's proposal, but we really should be discussing
the drafts at hand, not additional proposals. Of course, as we get
past this selection process, we will need to augment the starting
point...

PatC

---

From: [email-masked]
Date: Thu, 21 Feb 2002 14:47:58 -0600

James,

In HMIPv6, the MAP does NOT send the BU to the HA. The MN is the one that sends the BU to the HA to update the binding cache, using Regional CoA.

Rene Purnadi

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Thursday, February 14, 2002 2:17 PM
To: Yoshihiro Ohba
Cc: Behcet Sarikaya; [email-masked]
Subject: Re: [Seamoby] Moving forward with paging

Yoshi,

> But I don't think the hooks described in draft-renker really satisfies
> the requirements 4.7 and 4.8 even with Explicit Mode (see below).
>

I wasn't proposing that these be used without any modification.

> The scheme described in draft-renker relies on using the PA's address
> as the alternate CoA in order to redirect packets for the dormant host
> to the PA.  However, when a redirected data packet is received by the
> PA, the PA must look into the inner IP header (or the final entry of
> Routing Header if route opmization is used) in which the MN's Home
> Address is contained in the destination IP address field in order to
> distinguish the MN, as described in the draft.  This is very unnatural
> way of dealing with IP-in-IP packet (or Routing Header) at an
> intermediary node.

What about simply using a Deering-Zill tunnel from the HA?

Also, I'm not sure why a Routing Header wouldn't work. Suppose
there is a Routing Header with the PA's address in it at some point,
and what the PA does when it sees that header is to issue
an IP page. Then, when the MN replies, it sends along the packet.
It is up to the MN to renew it's mobility binding at the HA.

>This is also related to the following comments
> from the assessment team:
>
>   2) There is no description of how the mobility management is
>      completed after the paging request is received.  There must be
>      some coordination on when the deregistration is sent to PA.
>
> I think that the coordination is very difficult (especially in terms
> of security) as long as the solution relies on the use of the MN's
> Home Address at PA.
>

I agree that security is difficult. It essentially requires constructing
a trust relationship between the HA and PA that allows the PA
to issue binding updates to the HA when the MN moves in
dormant mode, on the mobile's behalf. But this is no different
in principle than HMIPv6. The benefit is that there is no state
on the mobile's location maintained in the foreign network,
it is all with the HA.

> In order to avoid this situation, an HMIPv6-like solution based on
> Regional CoA would be necessary for draft-renker, but this feature is
> not available for MIPv4.  This means that the scheme is not really
> independent of a mobility management protocol.
>

The issue I have with this is that the MNs location state gets
maintained at a "routing proxy." This is a potential source
of failure that needs to be replicated. Replication means expense.
I think we want a solution that looks like routing, where nearby
routers take over if one fails. I would rather confine an
expensive replicated agent to the HA, where it is unavoidable,
rather than introduce one into the foreign network. And, when the
IRTF Micromobility Task Force comes up with a micromobility
routing protocol, there will be no expensive routing proxy at all.

W.r.t. MIPv4, I think Regional Registration is now Informational, though
doesn't have an RFC number yet, it is like HMIPv6. But I don't
think it should be used either.

> On the other hand, the degree of "independency of mobility managenent
> protocol" specified in draft-ohba is the highest among all the
> proposals, and thus there is no problem of this kind with draft-ohba.
> I think this is a very important point.
>

draft-ohba doesn't specify where the tracking agent is, in particular,
it doesn't specify that it is handled by the mobility protocol. In
addition,
the security issue isn't discussed.

            jak

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

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