Subject: [mif] #15: use case #1 does not justify standardization of this option

From: "mif issue tracker" <[email-masked]>
Date: Thu, 01 Nov 2012 08:46:33 -0000

#15: use case #1 does not justify standardization of this option

 Use case #1 should remove the reference to walled gardens as a motivation
 (see RFC 3002, section 4.2.1 and other tickets on this theme).

 This option does not obviate the need for customer edge routers (CPEs) to
 route ("to avoid routing on the CPE").  Why should we not expect a router
 to route?

 Furthermore, this use case does not justify why customer edge routers
 would need this.  Instead, this use case documents a need for a protocol
 to provision network provider edge routers, which is something different.

 Recommendation: remove this use case.

-- 
-------------------------+-------------------------------------------------
 Reporter:  ek@…         |      Owner:  draft-ietf-mif-dhcpv6-route-
     Type:  defect       |  option@…
 Priority:  major        |     Status:  new
Component:  dhcpv6       |  Milestone:
  -route-option          |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/mif/trac/ticket/15>
mif <http://tools.ietf.org/mif/>

---

From: "mif issue tracker" <[email-masked]>
Date: Thu, 01 Nov 2012 08:49:10 -0000

Comment (by ek@…):

 Furthermore, the reference to the BBF document should be remove.
 http://www.broadband-forum.org/technical/download/TR-124_Issue-3.pdf does
 not seem to cite the draft as a "work in progress", which may simply have
 been an oversight.  However, since the text at the top of the document
 clearly says "[i]t is inappropriate to use Internet-Drafts as reference
 material or to cite them other than as 'work in progress'" it does not
 seem valid to construct what is essentially a self-referential motivating
 use case.

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/mif/trac/ticket/15#comment:1>
mif <http://tools.ietf.org/mif/>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 02 Nov 2012 16:39:11 +0100

Hello,

Le 01/11/2012 09:46, mif issue tracker a écrit :
> Use case #1 should remove the reference to walled gardens as a
> motivation (see RFC 3002, section 4.2.1 and other tickets on this
> theme).
>
> This option does not obviate the need for customer edge routers
> (CPEs) to route ("to avoid routing on the CPE").  Why should we not
> expect a router to route?
>
> Furthermore, this use case does not justify why customer edge
> routers would need this.  Instead, this use case documents a need for
> a protocol to provision network provider edge routers, which is
> something different.
>

I am not in a position to comment on the relevance of this use-case 1
"In Broadband network environment where the CPE is multi-homed to two
upstream edge routers and each router provides connectivity for
different..."

I think authors of this use-case have a reason for having suggested it.

On another hand, there are a number of other use cases that may need
this DHCP route-option behaviour.  Some specific to the default route
aspect of a general route are described in
draft-mouton-mif-dhcpv6-drlo-02.txt ("Large Mobile Network Use Case",
"Mi-Fi Coverage Extension Use Case", "M2M Constrained Device Use Case").

Alex

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 6 Nov 2012 04:38:24 +0900

Agree with Alex.

The BBF document might have made a mistake on how to cite an I-D,
but it does not change the fact that BBF wants it.

2012/11/3 Alexandru Petrescu <[email-masked]>

> draft-mouton-mif-dhcpv6-drlo-**02.txt ("Large Mobile Network Use Case",
> ______________________________**_________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mif<https://www.ietf.org/mailman/listinfo/mif>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2012 06:49:41 +0900

I'm sorry, but you can't draft an option and then claim that the option
needs to be standardized because the BBF needs it.

The BBF cannot assume that an option will be standardized until it becomes
an RFC, and referring to any particular IETF solution, including this one,
before it is standardized is premature. That is the meaning of the text at
the top of the draft, which says:

It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."

Just because the BBF didn't read that text, or chose to ignore it, doesn't
mean we have to standardize this option.

If the BBF has a problem statement or a use case for this option, then
that's fair game to include in the draft. Saying "we have to standardize it
because they cite it already" or "we have to standardize it because they
want it" is not.

On Tue, Nov 6, 2012 at 4:38 AM, Arifumi Matsumoto <[email-masked]> wrote:

> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Nov 2012 22:05:39 +0000

On Nov 5, 2012, at 4:49 PM, Lorenzo Colitti <[email-masked]>
 wrote:
> I'm sorry, but you can't draft an option and then claim that the option needs to be standardized because the BBF needs it.

This is a misrepresentation of the point to which you are responding.   Arifumi's point is that BBF has a use case for this option.   The point of advancing the option is not because OMG they've already adopted it.  It's because they need it.   We discussed this back in Prague, and you were there.  Why are we discussing it again?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2012 07:36:18 +0900

On Tue, Nov 6, 2012 at 7:05 AM, Ted Lemon <[email-masked]> wrote:

> This is a misrepresentation of the point to which you are responding.
> Arifumi's point is that BBF has a use case for this option.   The point of
> advancing the option is not because OMG they've already adopted it.  It's
> because they need it.   We discussed this back in Prague, and you were
> there.  Why are we discussing it again?
>

But do they? I can't read WT-124 issue 4 because I'm not a BBF member, but
if WT-124 issue 3 is simply the working title for TR-124 issue 3 (since
published), then there is no use case. TR-124 issue 3 only says that the
gateway should be able to request this option and, if it has multiple WAN
interfaces, use it. It doesn't say why.

Since their document doesn't say why they want it, we can't know if the
reason they want it is a reason that we would consider an acceptable reason
to standardize it.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Nov 2012 23:18:45 +0000

On Nov 5, 2012, at 5:36 PM, Lorenzo Colitti <[email-masked]> wrote:
> Since their document doesn't say why they want it, we can't know if the reason they want it is a reason that we would consider an acceptable reason to standardize it.

Roberta Maglione was present at the meeting I spoke of, and has been present in each working group meeting since then where this has been discussed, and has explicitly stated what the BBF's needs are and why.   There's probably even a liason statement lying around somewhere.

If you genuinely feel that this has not been sufficiently documented, I guess we can track it down, but this is the first time I've heard you dispute the point that the BBF has a need for this functionality.   Previously when we've talked about it you've said that it doesn't matter that they have this need, not that they don't in fact have this need.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2012 09:04:14 +0900

On Tue, Nov 6, 2012 at 8:18 AM, Ted Lemon <[email-masked]> wrote:

> Roberta Maglione was present at the meeting I spoke of, and has been
> present in each working group meeting since then where this has been
> discussed, and has explicitly stated what the BBF's needs are and why.
> There's probably even a liason statement lying around somewhere.
>
> If you genuinely feel that this has not been sufficiently documented, I
> guess we can track it down, but this is the first time I've heard you
> dispute the point that the BBF has a need for this functionality.
> Previously when we've talked about it you've said that it doesn't matter
> that they have this need, not that they don't in fact have this need.
>

Can we stop talking about me and take it back to the use case and the issue
specified in the tracker? I think it's fair to say that the use case:

   1. Is poorly documented ("in order to avoid routing on the CPE, we're
   specifying a protocol to configure routing on it" - seriously?)
   2. Is poorly justified (why do we need a protocol to configure routing
   beyond the one we already have? is this case common enough that a vendor
   option is not enough? if the problem is provisioning the edge router, why
   can't we solve that problem instead?)
   3. Has an incorrect statement about the BBF (TR-124 does not call for
   this draft or say why it's needed).
   4. Violates the strong IAB recommendations made in RFC 3002 that the
   IETF not design for walled gardens.

The "it doesn't matter that they have this need" is mostly captured in #4.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Nov 2012 00:30:00 +0000

If you are advocating for a clean-up of the requirements, I am 100% in agreement, but it seems to me that you are advancing a complete misrepresentation of the BBF requirement.   Since we already agree that the requirements need clean-up, talking about how one requirement indicates a problem with another is moot—let's just advocate a careful review and cleanup, and see if the authors will do that.   If not, there is no way to make forward progress, and in that case it would make the most sense to just discontinue the work.

But assuming the authors are willing to clean up the requirements, it would be better to postpone discussion of the problems with the requirements section until that work has been done.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2012 09:49:45 +0900

On Tue, Nov 6, 2012 at 9:30 AM, Ted Lemon <[email-masked]> wrote:

> If you are advocating for a clean-up of the requirements, I am 100% in
> agreement, but it seems to me that you are advancing a complete
> misrepresentation of the BBF requirement.

It's not just a clean-up. Points 2, 3, and 4 in the email (especially 4)
are issues that need to be dealt with in in order for this requirement to
be valid at all. The IAB guidance on walled gardens is quite substantive to
many of the use cases for this draft, and is therefore a serious concern.

>   Since we already agree that the requirements need clean-up, talking
> about how one requirement indicates a problem with another is moot—let's
> just advocate a careful review and cleanup, and see if the authors will do
> that.   If not, there is no way to make forward progress, and in that case
> it would make the most sense to just discontinue the work.
>
> But assuming the authors are willing to clean up the requirements, it
> would be better to postpone discussion of the problems with the
> requirements section until that work has been done.
>

Ack. http://trac.tools.ietf.org/wg/mif/trac/ticket/18

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Nov 2012 01:09:12 +0000

On Nov 5, 2012, at 7:49 PM, Lorenzo Colitti <[email-masked]>
 wrote:
> It's not just a clean-up. Points 2, 3, and 4 in the email (especially 4) are issues that need to be dealt with in in order for this requirement to be valid at all. The IAB guidance on walled gardens is quite substantive to many of the use cases for this draft, and is therefore a serious concern.

It's an interesting point, but what we're talking about here is dedicated routing for streaming services like VoIP and video, not a walled garden in the old sk00l AOL/Compuserve sense.   You could get to the service over the best-effort routing as well, but you will do better getting to that service over the custom route.   This is an application which seems to be quite popular among various ISPs—the Wifi Alliance is working on it, I know of at least one customer of my own employer who wants to do something like this, and apparently BBF considers it useful.

Is this what the IAB meant when they said that we shouldn't support walled gardens?   This is a serious question—it is not my impression that this is what they meant, but I honestly don't know.

Of course, that opens up the question of why not use existing QoS mechanisms, and I honestly don't know the answer to that—I'm not an expert on existing solutions to that problem.  I suspect the goal is to avoid expensive, specialized switching gear near the provider edge, but that's just a guess.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Nov 2012 02:38:17 +0000

On 06/11/2012 01:09, Ted Lemon wrote:
> On Nov 5, 2012, at 7:49 PM, Lorenzo Colitti
> <[email-masked]> wrote:
>> It's not just a clean-up. Points 2, 3, and 4 in the email
>> (especially 4) are issues that need to be dealt with in in
>> order for this requirement to be valid at all. The IAB
>> guidance on walled gardens is quite substantive to many of
>> the use cases for this draft, and is therefore a serious
>> concern.
> 
> It's an interesting point, but what we're talking about here
> is dedicated routing for streaming services like VoIP and
> video, not a walled garden in the old sk00l AOL/Compuserve
> sense.   You could get to the service over the best-effort
> routing as well, but you will do better getting to that
> service over the custom route.   This is an application which
> seems to be quite popular among various ISPs—the Wifi
> Alliance is working on it, I know of at least one customer of
> my own employer who wants to do something like this, and
> apparently BBF considers it useful.
> 
> Is this what the IAB meant when they said that we shouldn't
> support walled gardens?   This is a serious question—it is
> not my impression that this is what they meant, but I
> honestly don't know.

Speaking as a participant at the IAB workshop that led to RFC
3002 (and with no authority beyond that of a participant):

Firstly, please read section 3.1 of that RFC. Perhaps the key
quote is this:

'The term "walled garden" was coined to describe the resulting
captive customer economic and service model. That is, the user
is constrained within the limits of the service provided by the
carrier with limited ability to extend features or access
services outside the provider.'

and a bit later:

'Some discussion focused on whether cellular carriers could be
persuaded to transition toward the Internet "open" service
model. Responses indicated that there was little hope of this as
carriers will always fight being reduced to a "bit pipe",
fearing they cannot sustain sufficient revenues without the
value added services.'

It's also worth reading section 4.2 'Recommendations for Dealing
with "Walled Garden" Model.' This is written constructively on
the assumption that there will be walled gardens, so the IETF
should live with it despite not liking it. The dislike is very
explicit: 'It was strongly recommended that independent of the
ubiquity of the "walled garden" deployment scenario that
protocols and architectural decisions should not target this model.'

I think it's a bit of a stretch to say that
draft-ietf-mif-dhcpv6-route-option explicitly targets this
model; it's actually a generic mechanism, even if some of the
use cases do fit the walled garden model.

> Of course, that opens up the question of why not use existing
> QoS mechanisms, and I honestly don't know the answer to
> that—I'm not an expert on existing solutions to that problem.
> I suspect the goal is to avoid expensive, specialized
> switching gear near the provider edge, but that's just a
> guess.

The main existing QoS mechanism is known as "throw bandwidth at
the problem", and providing a dedicated route on a path known to
have adequate bandwidth is exactly that. But there are people
considering other approaches including diffserv or the flow
label. There is yet another approach about which
draft-sun-semantic-usecase and draft-jiang-semantic-prefix will
enlighten you.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Nov 2012 02:55:12 +0000

On Nov 5, 2012, at 9:38 PM, Brian E Carpenter <[email-masked]> wrote:
> There is yet another approach about which

Yes, I'm familiar with this work.   Thanks for the detailed explanation—that was very helpful.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 6 Nov 2012 10:41:33 -0500

Hi,

rereading RFC 3002 walled garden treatment in IETF,
it also describes like follows,

"Recognition that the "walled garden" model has some perceived

   benefits led to recommendations to better integrate it into the
   Internet architecture.  These focused on service location and escape
   from the "walled garden"."

" It was recommended to investigate standard protocols for service and
   proxy discovery within the "walled garden" domain."

"It was recommended to investigate standard methods to transport

   through the garden wall (e.g., escape to the Internet)."

So, it does not recommend targeting this model of walled garden,

but it looks recommending to standardize better co-existence method of

open model and closed model.

The model that the current dhcp route option draft describes seems me

to fall into the matter of co-existence.

Thanks.

2012/11/5 Brian E Carpenter <[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2012 00:55:28 +0900

> to fall into the matter of co-existence.
I think you're reading the text wrong. I don't see the word coexistence
anywhere in the text; the sentences you quote are all about "escaping" the
walled garden. In fact, the text says: These focused on service location
and escape from the "walled garden" - i.e., when you are in a walled
garden, figure out how to access the Internet instead.

So it seems to me that the IAB is saying:

1. Don't target the walled garden model with protocols and architectural
decisions.
2. Investigate standard ways that make it easier to escape from the walled
garden.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2012 01:02:18 +0900

On Tue, Nov 6, 2012 at 10:09 AM, Ted Lemon <[email-masked]> wrote:

> It's an interesting point, but what we're talking about here is dedicated
> routing for streaming services like VoIP and video, not a walled garden in
> the old sk00l AOL/Compuserve sense.   You could get to the service over the
> best-effort routing as well, but you will do better getting to that service
> over the custom route.   This is an application which seems to be quite
> popular among various ISPs—the Wifi Alliance is working on it, I know of at
> least one customer of my own employer who wants to do something like this,
> and apparently BBF considers it useful.
>

I don't see where you read that it should be possible to get to the service
via best-effort routing  as well. All the walled gardens I've seen (and I
have one at home, as Arifumi well knows) don't allow this.

The use case is undocumented, so we can't say for sure, but I suspect that
in this use case, the provisioning of a separate router to specific
customers serves *precisely* to ensure that only paying customers will get
the specific routing option via DHCPv6 that allows them to connect to the
router that provides access to the walled garden.

This seems to be exactly what Brian means by "captive customer economic and
service model".

Of course, that opens up the question of why not use existing QoS
> mechanisms, and I honestly don't know the answer to that—I'm not an expert
> on existing solutions to that problem.  I suspect the goal is to avoid
> expensive, specialized switching gear near the provider edge, but that's
> just a guess.
>

Yes, the motivation here is not particularly clear.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2012 01:08:06 +0900

> use cases do fit the walled garden model.

That was not the assertion made in this ticket. I believe that (part of)
the assertion was that use cases that target walled gardens should be
removed as justification, because IAB guidance is that protocol and
architecture development should not target walled gardens.

If there are other use cases, then we should decide on the merits of those,
but the use cases that are targeting walled gardens should be removed.

Does that make sense? Do you agree?

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 6 Nov 2012 11:11:50 -0500

The RFC says "integrate". So I understand the co-existence is recommended.

Service location and escape is focused in that RFC. I think delivering
correct routing information for both internet connecting service, and
walled garden
service should be service location and escape mechanism.

2012/11/6 Lorenzo Colitti <[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2012 01:14:21 +0900

> The RFC says "integrate". So I understand the co-existence is recommended.

Yes, but as in "integrate the walled garden into the Internet", not the
other way around :)

>From the text I think their intention was to make it easy for users in
walled gardens to access the Internet properly, not to make it easy to
allow Internet users to access walled gardens properly.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Nov 2012 16:16:49 +0000

> 2. Investigate standard ways that make it easier to escape from the walled

I assume we want the MIF client system to be able to take control of its
routing choices, for example to ignore a more specific route from one
provider because the client would prefer its traffic to go via another
provider. But that's a more general question than how the specific route
reaches the client in the first place. One way or another, the specific route
will arrive, won't it?

    Brian

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 6 Nov 2012 11:17:08 -0500

I don't see the difference.

> On Wed, Nov 7, 2012 at 1:11 AM, Arifumi Matsumoto <[email-masked]>wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Nov 2012 16:18:53 +0000

> Does that make sense? Do you agree?

I agree, but I'm prejudiced because I was in the IAB at the relevant time ;-).

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2012 02:51:06 +0900

> I don't see the difference.

The difference is in which system should be changed to conform to the
other.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Nov 2012 18:07:57 +0000

On Nov 6, 2012, at 12:51 PM, Lorenzo Colitti <[email-masked]>
 wrote:
> The difference is in which system should be changed to conform to the other. 

As I mentioned previously, the use of the term "walled garden" here is, as far as I understand it, inaccurate.   I agree that it should be taken from the document, and if in fact a documented use case _is_ a walled garden, that use case should be eliminated.   However, it seems pretty clear from the discussion up to this point that supplying fat pipes to differentiated services is not what "walled garden" means.

To me, "walled garden" means that you can't get out.   An advertised route that gives you a fast path to an otherwise reachable resource can be argued to be anti-competitive, but it's not a walled garden.   And despite the competitive environment in the U.S., there are competitive environments in Europe where the pipe would be made available to any provider of the same service, by law.   So this is not a reason to consider such a use case to be in any sense analogous to a walled garden.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2012 06:55:00 +0900

On Wed, Nov 7, 2012 at 3:07 AM, Ted Lemon <[email-masked]> wrote:

> As I mentioned previously, the use of the term "walled garden" here is, as
> far as I understand it, inaccurate.   I agree that it should be taken from
> the document, and if in fact a documented use case _is_ a walled garden,
> that use case should be eliminated.   However, it seems pretty clear from
> the discussion up to this point that supplying fat pipes to differentiated
> services is not what "walled garden" means.
>

AIUI based on our in-person conversations in Taipei it's not about fat
pipes, it's about access to premium content. But since the use case is
undocumented, there's no way to verify that.

To me, "walled garden" means that you can't get out.   An advertised route
> that gives you a fast path to an otherwise reachable resource can be argued
> to be anti-competitive, but it's not a walled garden.   And despite the
> competitive environment in the U.S., there are competitive environments in
> Europe where the pipe would be made available to any provider of the same
> service, by law.   So this is not a reason to consider such a use case to
> be in any sense analogous to a walled garden.
>

AIUI the use case is:

- We want to provide video content to my subscribers
- The content is hosted on my our network, not on the Internet, and we want
to provide our subscriber with a route to that network
- We provide DSL services by purchasing wholesale access on an incumbent's
BNG
- We can't use RAs because we don't control the BNG

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 6 Nov 2012 17:29:16 -0500

Then, this route option can serve as both ways. It makes walled garden
user/device to access the internet, and vice versa.

I think it's just a matter of viewpoint or start point.

> On Wed, Nov 7, 2012 at 1:17 AM, Arifumi Matsumoto <[email-masked]>wrote:
>