Re: [DNA-BOF] Draft BoF agenda.

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi JinHyeock,

JinHyeock Choi wrote:
> Hi Erik
> 
> 
>>It might be quite useful to try to put together a first cut at
>>a charter for a WG before Vienna. That way the discussions during the
>>BoF can be used to tweak the charter.
>>And if the charter contains a list of proposed documents that a WG
>>would deliver it would make things more concrete.
> 
> 
> I agree. The meeting time is precious commodity so that, IMHO, we'd 
> better be well prepared. 
> 
> I also wish, before meeting, we talk about contentious issues as much 
> as possible so that, at the meeting, BoF don't have difficulty reaching 
> consensus.  

A noble aim, although we can't really make the decisions
here ourselves :)

> 
>>I wonder if the BoF is likely to get into terminology ratholes.
>>It definitely makes sense running a rat hole detector on this during
>>the meeting. The term link, e.g. as defined in RFC 2460, is
>>still correct but perhaps not very useful in distnguishing between
>>different instances of the same type of link. So perhaps "link instance"
>>is the missing term, which one or more subnet prefixes being assigned
>>to each link instance.
> 
> 
> Would you elaborate more on "link instance"? I am thinking about what 
> does it mean 'to attach a network'.  
>
> I think a network consists of three entities 1) Router, 2) Physical Medium 
> and 3) on-link Prefix. But there are some ambiguities.  
> 
> Assume there are two Routers, Router1 and Router 2 on a link like below. 
> They share one Access Point between them. 
> 
> 
>                          |                |
>                        __|____          __|____
>                       |       |        |      |
>                       |Router |        |Router|
>                       |___1__ |        |___2__|                 
>                           |                |
>                       A:: |                |  B::  
>                         __|________________|_____       
>                                     |
>                                   __|____                      
>                                   |Access|                    
>                                   | Point|                       
>                                   |___ __|  
>                       
> Two routers advertise two different prefixes on their wireless interfaces. 
> Router1 advertises the prefix A:: and Router2 advertises the the prefix B::. 
> 
> And they inject the related routes to Internet. Router1 injects route for A:: 
> and Router2 injects route for B::.  
> 
> But assume Router1 is implemented with the host-specific part of Prefix 
> Discovery. Hence it knows that the prefix B:: is assigned to the link by 
> hearing RAs from Router2. 
> 
> Then what is the Router1's on-link prefixes on the wireless link? 
> In this case, is the complete set of on-link prefixes  {Prefix A::} 
> or {Prefix A:: , Prefix B::}
> 


I think that this scenario is already allowed by RFC-2461.

That said, in many cases, we won't always be looking at
networks  where this is happening (although our lack of
ability to know this a-priori may be important).

I'm coming around to the idea that there are two classes
of detection (at least in IPv6), which require DNA.

Firstly, there's the constrained topology links (instances?),
for example, where there is a 1-to-1 correspondence between
Wireless Access Point and First Hop Default Router Interface
(no multiple routers &etc). These may be multi-access links
like WLAN, but deployed in away that hosts know that the
first DHC or RA response they receive will convey the network
identity.

Secondly, there is a class of link-instances(?) which may have
any number of link-layer access points connected to one *or more*
IP routers.   The topology here is unconstrained and may
have the multiple routers which you described.

On the first class of links, the principle value DNA can give
is guidance on link-layer triggering of detection, and speedup
of response from routers.

In the second class of systems, the host has to be sure that it
doesn't needlessly undertake configuration when it receives a
link-up trigger (because it may be moving between APs in the
link-instance(?)) or an RA (because there may be more than one
router on the link-instance).

These systems will benefit from link-triggering and router
responsiveness, but will also need heuristics or rules to
guide their behaviour.

Lets not get too tied down in particular scenarios except
if we have to describe them.  AFAIK, both sets of devices
may be amenable to DNA methods.


P.S. Was this a consistent use of 'link-instance'?

Greg