Subject: [Gen-art] Re: Gen-art review of draft-bberry-pppoe-credit-04.txt

From: Mark Townsley <[email-masked]>
Date: Mon, 02 Jan 2006 11:38:22 -0600

Focusing on one point (authors, please respond to the other issues directly)

Elwyn Davies wrote:

>  Even were it to be published I am unclear why this document should be
>  Informational. It is documenting a proposed extension to a standard
>  (although, if the authors wished, it could have made use of the
>  existing Vendor-specific tag and then it would legitimately have been
>  an Informational document on that front - the new message types are
>  another matter) and as such ought to be aiming for PS.

This document is extending PPPoE, which by no means is a standard of any 
kind. I'm not sure what status other than Informational I could ask for 
here.

>
>  Assuming this document is approved, it needs an IANA considerations
>  section. I think that it effectively creates two registries for
>  PPPoE discovery message ids and discovery option tags which (AFAICS)
>  weren't setup by RFC2516 although the TAG registry is implicit in the
>  wording of RFC2516.
>

We intend to ask for an IANA space for the PPPoE tag registry. For this, 
and other PPPoE extensions.

draft-arberg-pppoe-iana-00.txt

- Mark

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Jan 2006 14:54:57 +0100

> kind. I'm not sure what status other than Informational I could ask for 

You can't, but that leads to another question - why isn't PPoE a standards
track protocol? I blinked back when that happened, apparently. It seems
to me we need to address that question before thinking about PPoE extensions.
(As far as I understand it, this draft extendes the PPoE code number space,
not a general PPP code space.)
>>  weren't setup by RFC2516 although the TAG registry is implicit in the

I don't know the history of 2516 but it seems to be a poster child for why
we require IANA Considerations sections now.
> draft-arberg-pppoe-iana-00.txt

That covers the tags but not the codes. RFC 2516 defines 8-bit codes
like 0x09 and draft-bberry adds several more like 0x0A. So I think that
field needs a registry too.

In any case, since you agree that this needs an IANA registry, it can't be
an RFC Editor submission, period.

     Brian

---

From: James Carlson <[email-masked]>
Date: Tue, 3 Jan 2006 09:29:23 -0500

Brian E Carpenter writes:
> track protocol? I blinked back when that happened, apparently.

Partly because L2TP is on Standards Track (and thus PPPoE isn't and
wasn't needed), and partly because PPPoE wasn't written in the IETF at
all.

> field needs a registry too.

That's a pretty good point.  The Code values should have been
considered.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 03 Jan 2006 17:43:59 +0000

Mark Townsley wrote:

> This document is extending PPPoE, which by no means is a standard of 
> any kind. I'm not sure what status other than Informational I could 
> ask for here.

As has been said elsewhere it isn't entirely clear why PPPoE is 
Informational.  Be that as it may, the mechanism in section 5 is 
actually an extension to PPP if it were done properly (as I said in the 
review the contents of s5 is IMO unaccpetable - it avoids defining a new 
PPP packet format by hacking in an extra field).

> We intend to ask for an IANA space for the PPPoE tag registry. For 
> this, and other PPPoE extensions.
>

This doesn't cover the new (pseudo-)discovery phase message id codes for 
PADG, PADC and PADQ.
The document also misses the normative reference to drft-arberg that is 
needed.

Happy New Year,
Elwyn

---

From: James Carlson <[email-masked]>
Date: Tue, 3 Jan 2006 12:57:19 -0500

Elwyn Davies writes:
> Informational.

It duplicates L2TP and wasn't an IETF effort.

>  Be that as it may, the mechanism in section 5 is 

I don't think an extension to PPP would be acceptable to the folks
proposing this PPPoE extension, as that would require changes to the
remote PPP nodes (which are _not_ connected via PPPoE).

PPP intentionally doesn't do any sort of flow control.  But if you
were to do it there, an extension of RFC 1663 would probably be the
best way to do it.

Just for reference, the deployment scenario that the draft authors
employ (not that I personally agree that this is at _all_ a good idea,
and thus the warning proposed):

	Server <-- PPPoE ---> Gateway <--- async ---> Client

In this scenario, "Server" and "Gateway" are using PPPoE as though it
were a pseudo-wire protocol.  In using it as a wire-like protocol,
they feel they need a flow control mechanism comparable to the flow
control present on the comparatively regular async link between
"Gateway" and "Client."

The right answer, of course, is to just terminate plain old PPP in the
"Gateway" device and route (or bridge or otherwise forward) IP
everywhere, but the draft authors are not interested in that solution
and we (in the working group) have been unsuccessful in arguing them
away from it.

(And since the IETF operates an Informational RFC vanity press ...)

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 03 Jan 2006 19:03:57 +0000

>remote PPP nodes (which are _not_ connected via PPPoE).
I am not sure I follow the logic here: Either the modified form of 
packets defined in s5 gets to the remote node or it doesn't..  In the 
former case, something around the bottom of PPP has to be modified - in 
the latter case, conventional PPP works.  If something has to be 
modified IMHO it would be better done 'properly'.  However whether it is 
done properly or not, the credit tag effectively needs a previously 
unused value from the PPP DLL protocol space to distinguish it from any 
PPP packets that might be carried without credit tags.  If it is not 
allocated properly there is a risk down the line that the value will be 
allocated for a 'real' PPP protocol and things then break. Whether you 
call this a modification to PPP or not is hair splitting.

>were to do it there, an extension of RFC 1663 would probably be the
Indeed: but I am not qualified to judge the relevance or effectiveness 
of the scheme - for the purposes of this review I have only to decide if 
I think one could build interoperable implementations for the spec here.

>(And since the IETF operates an Informational RFC vanity press ...)
I am sure I couldn't comment on this.. but I have to believe that we 
should avoid offering to advertise the Emperor's New Clothes.

---

From: James Carlson <[email-masked]>
Date: Tue, 3 Jan 2006 14:13:35 -0500

Elwyn Davies writes:
> packets defined in s5 gets to the remote node or it doesn't..

View the diagram again:

The proposed protocol runs between Server and Gateway alone.  It does
_not_ affect the PPP session that runs between Server and Client.

The draft author is able to change Server and Gateway to add this new
feature.  He cannot change Client.  Those messages do not go to the
Client, so there's no problem there.

>  In the 
> modified IMHO it would be better done 'properly'.

Indeed.

>  However whether it is 
> PPP packets that might be carried without credit tags.

No; see above.  It does *not* affect the end-to-end PPP connection;
merely the leg of that connection that traverses PPPoE.

The author is using PPPoE as if it were a wire emulation protocol and
he wants flow control in it for that reason.

>  If it is not 

No, that's not what I was saying at all.

PPPoE and PPP are independent protocols.  PPP tunnels over PPPoE.

> should avoid offering to advertise the Emperor's New Clothes.

It's not exactly "Emporer's New Clothes."

It's a rough solution to a manufactured problem.  The "problem" would
not exist if any of the following were true:

  - If the author simply ran regular PPP to the Gateway device,
    terminated PPP there (turning "Gateway" into an access router,
    rather than just a concentrator device), and routed the IP packets
    normally, then there'd be no need for PPPoE in this picture at
    all.

  - If the author just gave up on flow control over the link, because
    flow control is really a problem for higher-layer (transport and
    above) protocols, then the problem would not exist.

  - If RFC 1663 reliable were used, then link level flow (and error)
    control would exist.

  - If the linkage between Server and Gateway were something that
    allowed for flow control and multiple sessions (something other
    than Ethernet; say, Frame Relay), then that would potentially
    provide the solution.

There are probably other ways to accomplish the goal.  The reason it's
a problem is the essentially ad-hoc nature of the "required"
deployment architecture.

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 03 Jan 2006 19:45:08 +0000

>he wants flow control in it for that reason.
OK - I (now) understand what is being proposed.

>PPPoE and PPP are independent protocols.  PPP tunnels over PPPoE.
That's fine and dandy but I think the problem is that as drafted, some 
of the PPP packets would not have any credit tag on them so you have to 
distinguish between the ones with a credit tag plus a PPP packet and 
those that just have a PPP packet. A strange form of tunnel!

>It's not exactly "Emporer's New Clothes."
There certainly appear to be a few rents leaving the naughty bits 
showing ;-)

>a problem is the essentially ad-hoc nature of the "required"
I think we know where we stand on this one and we don't need to expend 
any more cycles on it.  Let's see what happens...

Happy New Year,
Elwyn

---

From: James Carlson <[email-masked]>
Date: Tue, 3 Jan 2006 14:57:12 -0500

> those that just have a PPP packet. A strange form of tunnel!

I don't see that in the draft.  They do make a distinction between
PPPoE control and data messages -- control messages don't contain
embedded PPP data and don't employ the credit scheme, and data
messages *do* carry the PPP data and do use credits.  I see no
opportunity here for a problem.

I suspect you're referring to the ability to piggyback credit grants
atop PPPoE data messages.  That's not a problem because even messages
without grants consume credit space and are thus metered.

As best I can tell, it works.

(Even if it didn't work, I wouldn't be too worked up about it.  It's
"only" PPPoE ... and likely only affects this one vendor's recommended
baroque deployment.)

> There certainly appear to be a few rents leaving the naughty bits 

Hardly the biggest ones.  PPPoE itself has holes fit for a truck --
including security (none), MTU (non-standard), and session ID
assignment (unidirectional).  It's a tough neighborhood.

> any more cycles on it.  Let's see what happens...

OK; sounds good.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jan 2006 14:15:37 +0100

James Carlson wrote:
...
> (And since the IETF operates an Informational RFC vanity press ...)

Not quite. Independent submissions to the RFC Editor are by definition
not part of the IETF process.

    Brian

---

From: James Carlson <[email-masked]>
Date: Wed, 4 Jan 2006 08:46:07 -0500

> not part of the IETF process.

True ... but my point is that no all readers of RFCs manage to notice
the difference, so the effect is that the review status isn't clear
(and may well be "none").

The original PPPoE RFC 2516 was just such an independent submission
(draft-carrel-info-pppoe-02) and was primarily designed in the ADSL
Forum, not the pppext working group.