Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Dec 2011 14:21:43 +1300

Hi Ole and Mark,

I'm not sure where this should be discussed, so I picked v6ops for now.

>    MH-2:  An IPv6 CE router MUST create an SRIB containing entries for
>           associated delegated prefixes.  Each entry points to one or
>           more DRIBs.  An entry points to multiple DRIBs only in the
>           case where an identical delegated prefix is associated with
>           multiple WAN interfaces.

I am quite bothered by the second sentence. It seems to assume that
ingress filtering is inevitable, but this is very restrictive as far
as seamless multihoming goes. If we can one day get to a situation
where ingress filtering is automatically tailored for multihomed customers,
we will need each SRIB entry to point to multiple DRIBs accordingly.
At least, qualify it by saying something like

   A prefix is considered to be associated with a WAN interface either
   if it is delegated via that interface, or if it is known that it is
   accepted by complete ingress filtering applied to that interface
   (section 4.2 of [RFC3704]).

Regards
   Brian Carpenter

On 2011-12-08 03:06, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Basic Requirements for IPv6 Customer Edge Routers - multihoming and transition
> 	Author(s)       : Mark Townsley
>                           Ole Troan
> 	Filename        : draft-townsley-troan-ipv6-ce-transitioning-00.txt
> 	Pages           : 5
> 	Date            : 2011-12-07
> 
>    This document specifies general IPv6 multihoming and specific 6rd
>    transitioning requirements for an IPv6 Customer Edge (CE) router.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-townsley-troan-ipv6-ce-transitioning-00.txt

---

From: Ole Troan <[email-masked]>
Date: Wed, 14 Dec 2011 09:50:11 +0100

Brian,

> I'm not sure where this should be discussed, so I picked v6ops for now.

probably as good as anything. one of homenet, intarea, 6man, v6ops... ;-)

>   (section 4.2 of [RFC3704]).

perhaps we should qualify that this applies to PA addressing, and multi-homing without the ISP's involvement?

if the ISPs exchanged routing information/RFC2260 (required for the return-path) and opened up for ingress filtering for each others prefixes... is there a use case for that, or are we in PI territory?

in the case of a link to ISP A was down, the CPE could of course forward traffic with SA = ISP A out ISP B's link. if it was stopped by ingress filtering the host would get an ICMP back from the PE instead of the CPE.

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Wed, 14 Dec 2011 11:06:24 +0100

Hi,

> in the case of a link to ISP A was down, the CPE could of course forward traffic with SA = ISP A out ISP B's link. if it was stopped by ingress filtering the host would get an ICMP back from the PE…

Would it?

ISP B's PE has no route to send ISP A's prefix to that CPE, so how would
the ICMP reach the host?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Ole Troan <[email-masked]>
Date: Wed, 14 Dec 2011 14:40:50 +0100

Gert,

> ISP B's PE has no route to send ISP A's prefix to that CPE, so how would

good point.

OK, for auto-detection of ingress filtering. we could use "BFD echo mode". like what we do for 6rd BR reachability check.
the CPE generates a packet with SA = DA = one of its own addresses from ISP A. this packet it forwards to the ISP B.

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Wed, 14 Dec 2011 14:50:23 +0100

Hi,

> the CPE generates a packet with SA = DA = one of its own addresses from ISP A. this packet it forwards to the ISP B.

Yep, that would work (just don't call it "BFD anything" as people - like 
me, before re-reading - would assume that it needs BFD to be enabled on 
the ISP side).

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Dec 2011 08:57:05 +1300

> me, before re-reading - would assume that it needs BFD to be enabled on 

I found it quite interesting to read RFC3704 again. There are quite a few
things needed to make PA multihoming work properly, but my point was to
ensure that the ce-transitioning draft doesn't unintentionally break
this completely.

Incidentally, draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat
doesn't have a reference to RFC3704, and maybe it should.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Sat, 17 Dec 2011 19:59:49 -0800

On Dec 13, 2011, at 5:21 PM, Brian E Carpenter wrote:

> It seems to assume that

To be really honest, I think you need to demonstrate that there is interest in achieving the nirvana you desire. Generally speaking, a service provider will do what you pay him to do, and anything that he can't describe in generic "service" terms will be generally offered, if at all, at a high price. Couple that with the general behavior of markets - seeking the lowest price for a reasonable set of services, and...

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Dec 2011 09:58:15 +1300

> To be really honest, I think you need to demonstrate that there is interest in achieving the nirvana you desire. Generally speaking, a service provider will do what you pay him to do, and anything…

Well yes, the market does what it does. If small users come to care
deeply about multihoming, the incentive for ISPs to support flexible
ingress filtering will arise and a solution will emerge. If the users
don't care, there will be no incentive.

My point is that we shouldn't write specs that unnecessarily constrain
things that might be desirable. I think a tiny change will do that:

   MH-2:  An IPv6 CE router MUST create an SRIB containing entries for
          associated delegated prefixes.  Each entry points to one or
          more DRIBs.  An entry points to multiple DRIBs only in the
          case where an identical delegated prefix is known to be
          routeable via multiple WAN interfaces.

 Brian

   Brian

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 19 Dec 2011 08:39:23 +0100

Small Q: so you consider "BFD-support" to be mandatory on the CPE ?

regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: woensdag 14 december 2011 14:41
To: Gert Doering
Cc: IPv6 Operations; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-townsley-troan-ipv6-ce-transitioning-00.txt

Gert,

> ISP B's PE has no route to send ISP A's prefix to that CPE, so how 
> would the ICMP reach the host?

good point.

cheers,
Ole
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Dec 2011 10:20:25 +0100

> To be really honest, I think you need to demonstrate that there is interest in achieving the nirvana you desire. Generally speaking, a service provider will do what you pay him to do, and anything…

The demonstration of interest is the overwhelming operator support of the scope laid out in 6204-bis which includes coexistence of 6rd, Native IPv6 and IPv4, and DS-Lite. That, and on the 6rd side at least, the largest 6rd deployment (and largest IPv6 deployment for that matter) in the world letting us know that this is how they would like to bring up IPv6 alongside 6rd (re: 6rd-sunsetting).  

Please don't confuse this work as primarily motivated by a "nirvana" of multiple ISP support on CE Routers. The solution laid out by Ole and I only happens to use multihoming techniques because that is in fact what you largely end up needing to tackle when you build a CE that supports 6rd, Native and DS-Lite together. Whether a CE router decides to include multiple physical WAN interfaces and market it as what is today referred to as "Dual-WAN" is up to its product management team. 

The issue at hand is that as of a few months ago we have 6204-bis that plainly outlines that a CE router needs to be able to support 6rd, native, and DS-Lite together. When it comes to running code, it's an observable fact that a 6rd IPv6 interface next to a native IPv6 interface looks like two IPv6 interfaces to the routing system. Similarly. a Native IPv4 interface next to a DS-Lite IPv4 over IPv6 tunnel looks like two CE IPv4 WAN interfaces. 

So, 6204-bis stepped into this, though perhaps it is more fair to say softwires did even before with the definition of 6rd and DS-Lite at all. It's incumbent upon us to at least state how these can be made to work together in a way that operates. 

- Mark

---

From: Ole Troan <[email-masked]>
Date: Mon, 19 Dec 2011 17:49:56 +0700

Carl,

> Small Q: so you consider "BFD-support" to be mandatory on the CPE ?

as Gert pointed out this isn't really BFD.
it is whatever packet you'd like to send yourself forwarded through the PE.

with regards to your question, too early to say.

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Mon, 19 Dec 2011 11:56:25 +0100

Hi,

> Small Q: so you consider "BFD-support" to be mandatory on the CPE ?

Well, I'd love to see BFD supported, but given that the PE usually doesn't
properly support BFD for large-scale deployments either, I'm not putting
much hopes into it.

Regarding Ole's proposal - that's "operating like BFD in echo mode", but
(I think) it is not BFD-as-a-protocol, just the way it works.

Gert Doering
        -- NetMaster