Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt

[Jari Arkko <jari.arkko@piuha.net>]

I would be fine with referencing 3704. But the draft that
I referenced was merely an example. Perhaps it would
be best if you adding a little bit detail to the work-in-progress
warning that you already have in Section 4.7. For instance,

   Multihoming and renumbering remain technically challenging with IPv6
   (see the Gap Analysis below).  However, IPv6 was designed to allow
   sites and hosts to run with several simultaneous CIDR allocated
   prefixes, and thus with several simultaneous ISPs.  An address
   selection mechanism [10] is specified so that hosts will behave
   consistently when several addresses are simultaneously valid.  The
   fundamental difficulty that IPv4 has in regard to multiple addresses
   therefore does not apply to IPv6.  IPv6 sites can and do run today
   with multiple ISPs active, and the processes for adding, removing,
   and renumbering active prefixes at a site have been documented in
   [13] and [20].

=>

   IPv6 was designed to allow
   sites and hosts to run with several simultaneous CIDR allocated
   prefixes, and thus with several simultaneous ISPs.  An address
   selection mechanism [10] is specified so that hosts will behave
   consistently when several addresses are simultaneously valid.  The
   fundamental difficulty that IPv4 has in regard to multiple addresses
   therefore does not apply to IPv6.  IPv6 sites can and do run today
   with multiple ISPs active, and the processes for adding, removing,
   and renumbering active prefixes at a site have been documented in
   [13] and [20]. However, multihoming and renumbering remain technically
   challenging even with IPv6 with regards to, for instance, session
   continuity across multihoming events or interactions with
   ingress filtering (but see the Gap Analysis below).

Or words to that effect. You might considering moving some
of the discussion to Section 6.4, for intance.

--Jari

Tony Hain wrote:

>The ID is essentially more detail on how to work around the ingress filters
>with tunnels and source routing, but the outcome is already covered in 3704.
>
>
>Tony
>
>  
>
>>-----Original Message-----
>>From: Fred Baker [mailto:fred@cisco.com]
>>Sent: Wednesday, July 26, 2006 5:30 PM
>>To: Tony Hain
>>Cc: 'Jari Arkko'; v6ops@ops.ietf.org
>>Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-
>>02.txt
>>
>>
>>On Jul 26, 2006, at 11:42 AM, Tony Hain wrote:
>>
>>    
>>
>>>>The one remaining thing that I would suggest you add here is
>>>>a warning about the issues in multihoming and ingress filtering.
>>>>If I read Section 4.7, I get the feeling that multiple prefixes and
>>>>multiple ISPs works fine today, which may not be exactly correct,
>>>>see e.g. draft-huitema-shim6-ingress-filtering. Do not add a lot
>>>>of text, just mention that there are issues in some cases in the
>>>>multiple-ISP model.
>>>>        
>>>>
>>>Does this work for you:
>>>Additional considerations are being documented as multihoming work
>>>evolves
>>>xref  ---  draft-bagnulo-shim6-ingress-filtering-00.txt
>>>      
>>>
>>I eonfder how many of these are discussed in RFC 3704?
>>    
>>
>
>
>
>  
>