Hi Brian, Comments inline.....
> -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Tuesday, September 04, 2012 12:18 PM > To: Internet Area; [email protected] > Subject: draft-bonica-v6-multihome > > Hi, > > As far as I understand it without seeing a complete "life cycle" of a > multihoming failover, this proposal only works because of a three-way > collaboration between both ISPs concerned and the site. Unless I've > misunderstood something, that is almost the same as is required to make > the draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat solution work > too. > > In both cases, something is needed to avoid packets with ISP A's prefix > being discarded by ISP B's ingress filters. The fact that their > internal prefix has been translated in one case is beside the point. Yes! There is significant commonality between draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat and draft-bonica-v6-multihome. Both drafts set out to satisfy the requirements of RFC 3582. In both drafts, a mechanism is required to prevent outbound packets from being discarded by ISP uRPF filters. In both drafts, that mechanism requires collaboration among the site and its ISPs. > > If that is correct, this common aspect should be in its own draft. Then > we can see a straight comparison between the two approaches. > > I'd also like to see a detailed goal-by-goal comparison with the goals > defined in RFC 3582. Back in the MULTI6 WG, that was the approach we > took in comparing proposed solutions. I agree that a compare-and-contrast draft would be helpful! Maybe you, a couple of the authors of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat and I could collaborate on such a draft. Let's discuss this possibility off line. > > The multihoming-without-ipv6nat draft notes that e2e address > transparency wasn't listed as a goal in RFC 3582. Having been co-chair > of that WG, I'm pretty sure that's because we never imagined anyone > proposing anything else for IPv6. That was obviously a failure of the > imagination. But apart from that, I don't think it's reasonable to > sweep it (and the referral problem that derives from it) under the > carpet. It's a problem faced by essentially every distributed app. So I > think all proposals for multihoming that affect e2e address > transparency need to analyse their impact on referrals. Also agreed. We might also want to reinvigorate your work on referrals. Ron > > Regards > Brian _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
