Re: [addr-select-dt] meeting at san francisco

[Suresh Krishnan <[e-mail]>]

Hi Tim,
  I am not sure.  I do not think we can do anything about this 
specifically. The only thing we need to ensure is that the dynamic 
update mechanism we come up with must be able to support his scenario.

Cheers
Suresh

Tim Chown wrote:
> So we need to consider the questions raised by draft-denis-v6ops-nat-addrsel
> as well - as raised by Fred's recent mail.
>
> Your comments on that are welcome too :)
>
> Tim
>
> On Mon, Mar 23, 2009 at 11:41:49PM +0000, Tim Chown wrote:
>   
>> Hi,
>>
>> Here are some notes from this morning's meeting, combined with
>> a few lines to describe where we are with the -02 draft.
>>
>> I think the important input from you chaps is to look at the 
>> questions we should be asking the 6man WG and commenting on 
>> these.   Are they appropriate?   Any missing?   Any unnecessary?
>>
>> If you can give me feedback today I will convert the notes into
>> slides to pass to Brian/Bob to upload to the agenda page.
>>
>> --- General status ---
>>
>>
>> General scope is site/enterprise network, where
>> administrator wishes to convey policy to hosts
>> - may be different to 'RFC3484 default' policy
>> - may vary across site (with topology and/or time)
>> - may change for a host as it moves within site
>>
>> New address selection DT draft issued:
>> - draft-chown-addr-select-considerations-02
>>
>> Design Team is looking at:
>> - frequency of updates - how dynamic are they?
>> - approaches given the identified frequency of changes
>> - host detection of polciy changes
>> - whether an RFC3484 update is required
>>
>>
>> Main changes since -01:
>> - included nomadic nodes within a site
>> - noted the multiple interface (mif) issue, e.g. VPN
>> - possible policy conflicts (multiple admin domains)
>> - should we have a 'priority' interface for conflicts?
>> - initial notes on push vs pull solutions (pull = dhc = per host config)
>> - note that indicator of default policy in effect is useful?
>> - note that routing hints may be of value to a host
>>
>>
>> Frequency:
>> - most triggers are administrative (application of new policy)
>> - higher if many nomadic hosts
>> - higher if (changing) traffic engineering in use
>>
>>
>> --- Questions for the 6man WG ---
>>
>> 1) Overlap with mif
>> - the DT is focused on site/enterprise networks which may have nomadic
>>   nodes and may have multiple uplinks
>> - mif is focused on mobile nodes
>> - the DT should ensure all relevant scenarios are identified, the question
>> is where solutions are progressed, and how collaboration with mif happens
>> - what about a device in the site with an external VPN?
>> - what about nodes that might 'accidentally' have multiple interfaces up?
>>
>> 2) 3484 update how/when
>> - some clear issues, like Rule 9, ULAs
>> - can we proceed now independently of any requirements emerging from the DT?
>> - it seems there is nothing affecting progress in parallel now?
>>
>>
>> 3) Do we consider just one administrative domain?
>> - simplifies considerations - because conflicts in policies unlikely
>> - but what about one site with two uplinks from different providers? 
>> - what about hosts in the site network that 'accidentally' or deliberately
>>   attach to other networks (VPN, wireless, etc)?
>> - solution we choose may affect the impact of being in multiple domains  
>>
>> 4) Handling conflicts?
>> - if we encounter them, how do we prioritise?
>> - or do/can we merge?
>> - perhaps one interface has higher priority?
>> - perhaps fall back to default policy if conflicting policies received?
>>
>> 5) Are we ready to move towards solution space?
>> - push vs pull solutions
>> - DHCP options seem preferable, allowing different policy per host
>>
>> 6) Information from routing state?
>> - pass routing information to host to assist decision?
>> - some early mif draft(s) seem to be doing this (pushing routing info
>>   rather than RFC3484 policy)
>>
>> 7) Should 3484 be just node-specific?
>> - or interface specific?
>> - mif issue?
>>
>> 8) What about application-specific limitations, e.g. firewalls?
>> - assume out of scope
>>
>> _______________________________________________
>> addr-select-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>     
>
>