Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 11 Jan 2002 18:57:44 +0100

> >   > >1. MUST translate L2 Ids (APs and ARs) to L3 Ids of ARs
  > >   > >
  > >   > >
  > >   > >2. MUST support L2 devices of different technologies
  > > 
  > > => What does this really mean ?
  > 
  > Having an AP in WLAN and Bluetooth and being able to discover
  > both.
  > 

=> OK. 

  > > 
  > >   > >8. SHOULD minimize involvement of ARs which are not 
  > GAARs in CAR
  > >   > >discovery
  > > 
  > > => Going to Phil's comment, how do we measure a SHOULD ?
  > > What tradeoffs will be acceptable to exempt a solution
  > > from following this requirement? 
  > > I think it would be esaier to make it a MUST.
  > 
  > This minimization has to be seen compared to other protocols in
  > the first place. If there is a solution that does not at all involve
  > non-GAARs, the minimization is certainly optimized. The other
  > extreme would be a general flooding of the entire Internet to
  > resolve the L2 identifier. In between these extremes (including
  > them), the solutions will exist, and they have to be evaluated
  > against this requirement.
  > 
  > The SHOULD has been used since it wasn't clear if such kind of
  > evaluation for the selection of the final solution should be
  > mandatory or not. Personally, I prefer the MUST, too since I'd like
  > to see a final solution that minimizes involvement of non-GAARs.
  > 
  > > 
  > > I'd like to also suggest that if the WG still wants to
  > > keep section 4.1 of the problem statement draft, we 
  > > should at least change the wording in the first
  > > paragraph to reflect that the AR will _never_ 
  > > guarantee to know _all_ neighbouring ARs. 
  > > I think this is obvious. 
  > 
  > The wording in Section 4.1. doesn't imply that CAR guarantees
  > the knowledge of ALL GAARs. The wording has to be seen at the
  > point of TAR selection. For that, only the current status of 
  > knowledge regarding the GAARs is taken into account. 

=> To me the following text from the draft suggests
that the AR knows ALL GAARs. I think that's unrealistic.

  4.1 Anticipated CAR Discovery

   In this approach, an AR currently serving the MN identifies all CARs
   for the MN's handoff, at some point prior to handoff.

  > 
  > It is obvious that CAR does not guarantee full knowledge, 
  > but it has 

=> So we agree, then I suggest you reflect it in the text.

  > at least to maximize the information regarding the GAARs with its
  > optimal
  > point of operation, i.e., the knowledge of all GAARs, though 
  > this optimal point might never be reached.

=> Surely the MN would be able to know about all ARs in its
coverage area, that is if it can see their RAs.

 But a solution that
  > at least enables to reach this point in a finite time is certainly
  > better than a mechanism that never reaches this point. Example
  > for the latter would be solution that were entirely be based on one
  > mobility management protocol. This solution could never 
  > discover GAARs that are using another mobility management protocol. 

=> You\re making a lot of assumptions about the discovery
mechanism. If a MN can hear RAs from different
GAARs, it will discover them. If that is not 
possible due to l2 limitations, there are ways to go
around that, without depending on any mobility
management protocol, but keeping in line with
existing protocols. 
I didn\t want to start arguing about solutions but
I think it can be done.

  > 
  > > 
  > > Also 'anticipation' is misleading, because it is seems
  > > to imply that the MN does not signal. The MN can
  > > certainly anticipate and that is explained in the 
  > > low latency and FMIPv6 drafts referenced in the doc.
  > 
  > I don't see the problem of excluding MN signaling by using
  > the word 'anticipation'. Could you point out which wording
  > you don't like?

=> anticipation should not be associated with the 
case where the MN does not signal, you can have
anticipation when the MN signals also. Therefore
associating 'anticipation' with a certain model
where the MN does not signal, does not seem right.

I'm referring to the title of ch 4.1

Regards,
Hesham

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 11 Jan 2002 10:49:46 -0800

Hesham,

OK, this sounds like some comments on
draft-ietf-seamoby-cardiscovery-issues-01.txt.

It certainly would have been helpful if you had posted your comments
during the Last Call period.
Last Call expired Jan. 4 on this document. I don't believe comments sent
in after
Last Call necessarily need to be accommodated, but, if these are simple
editorial changes that can be
 resolved in the next day or two, then I think we can accommodate them.
However, I do not want to get into a
 long discussion about requirements prior to releasing the problem
statement. If we can't resolve these
editorial issues by Tuesday, the draft will go to the IESG as it
currently stands.

Here are some suggestions about changes in the wording.

>    for the MN's handoff, at some point prior to handoff.

How about:

    In this approach, an AR currently serving the MN identifies some set
of
    suitable CARs for the MN's handoff, at some point prior to handoff.

If this text is unsatisfactory, please feel free to propose an
alternative.

> I'm referring to the title of ch 4.1

One of the problems with not having a consistent set
of terminology for wireless networking in the IETF
is that it becomes difficult to find a word that describes
the concept you are trying to get at without impinging
on what somebody else thinks a particular word
means. I believe this is the case here. The "anticipated"
here has nothing to do with "anticipated handover."
Here, the AR is anticipating the need for CARs
by performing discovery prior to the MN needing
them. The anticipation is exactly the same anticipation
as occurs for distribution of routing information prior
to a packet arriving at a router that requires that
routing information.

Perhaps another word would be suitable? Please
feel free to suggest one. Perhaps "router based"?

            jak