Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd)

At 11:23 PM 07/07/04 +0200, Iljitsch van Beijnum wrote:
>On 7-jul-04, at 22:39, Fred Baker wrote:
>>When a company changes providers, it is common to institute an overlap 
>>period, during which it is served by both providers.  By definition, the 
>>network is multihomed during such a period.  While this document is not 
>>about multihoming per se, problems can arise as a result of ingress 
>>filtering policies applied by the upstream provider or one of its 
>>upstream providers, so the user of this document need also be cognizant 
>>of these issues.  This is discussed in detail, and approaches to dealing 
>>with it are described, in [RFC2827] and [RFC3704].
>
>These references outline ingress filtering, but there is only about half a 
>page in the second one about how to route traffic with certain addresses 
>to a certain provider, and this half page provides very little actual guidance.
>
>A few paragraphs along the lines of "ask one ISP to temporarily accept 
>packets with the other's addresses and use that one for outgoing traffic 
>or use policy routing to match ISPs to the source addresses in outgoing 
>packets, or if these approaches aren't possible, implement a flag-day type 
>of transition" would be very helpful, I think.

In a word, no.

There was a serious attempt last fall to turn this document, which is about 
"how to renumber a network", into "how to configure ingress filtering and 
route traffic within multihomed networks". the problem is, there exist a 
lot of multihomed networks that are not periodically renumbered, and the 
issues of multihoming apply in them, and (believe it or not) not all 
networks that get renumbered are multihomed. Yes, a network might be 
multihomed temporarily while being renumbered, but that doesn't make 
renumbering==multihoming. They are in fact very different discussions.

In the interest of ever getting a chance to actually do anything useful 
with "how to renumber a network", Pekka and I put the entire BCP 38 
discussion into a separate document, which is now RFC 3704. This working 
group looked at that document, decided it was sufficient to describe those 
issues, and published it as an RFC. If it is not sufficient, fixing RFC 
3704 is the task of the day, and should be part of the recharter effort 
that is currently under discussion. Alternatively, Multi6 could produce 
something useful on the topic.

May I suggest that, by 12 July, you post an updated version of RFC 3704?