RE: [Seamoby] CAR DiscoveryProtocol Requirements...

Hi Hesham, 

some comments inline

> -----Original Message-----
> From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
> Sent: Friday, January 11, 2002 11:42 AM
> To: Govind Krishnamurthi; seamoby@ietf.org
> Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
> 
> 
> Govind and all, 
> 
> Some comments below.
> 
> Generally I think it would be useful to identify
> which protocol these requirements apply to. 
> I.e. the protocol between the ARs or the one between
> the MN and the AR?
> 
> 
> 
>   > >
>   > >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.

> 
>   > >
>   > >6. Protocol applicability - SHOULD (show of hands 
>   > indicated that a MUST
>   > >is needed here) support inter-domain as well as 
> Intra-domain scope
>   > >
> 
> => Definitely a MUST IMO. Also we should be clear on the 
> meaning of 'domain'.

I agree with the MUST. Clarification of domain is certainly 
helpful.

> 
>   > >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. 

It is obvious that CAR does not guarantee full knowledge, but it has 
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. 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. 

> 
> 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?

Regards,

Dirk

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby