MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network
draft-melsen-mac-forced-fwd-04

[Note]: 'After a long delay and associated apology, I responded to email from
Torben on 6/14 addressing 4 issues. One requires action from David
Kessens to review IPv6 issues. Two require some editing. One requires
me to followup (VRRP issue). Moving to Revised ID needed while these
issues are dealt with.' added by Mark Townsley

[Ballot comment]
These are responses to Margaret's DISCUSS points from the document author:

IPv6: What kind of problems are foreseen? We have made a study at Ericsson,
showing that the MFF concept is practically directly applicable to IPv6. But
that doesn't mean that it MUST be used with IPv6. Some of the fundamental
problems solved with MFF is solved by IPv6 in another way.

Upstream multicast: If operators are interested in enabling end-users to
distribute multicast within the aggregation network, they will of course not use
MFF. Enabling this type of multicast distribution implies that end-users will
have direct layer-2 visibility of each other, which is exactly what MFF tries to
avoid.

VLAN provisioning complexity: By experienced RFC submitters I was encouraged to
remove arguments that criticized existing mechanisms. I think we can easily
provide additional arguments against the VLAN-per-User scenario, e.g. poor
support for multicast, and scalability (only 4K VLANs).

Address learning:
- AN learning end-user addresses: The exact mechanism is not important for MFF.
A straightforward solution is for the AN to snoop the upstream traffic from
end-users, and register their corresponding IP/MAC addresses. IP addresses may
also be provisioned manually, e.g. for static IP address assignment, but that
will mean extra provisioning compared to the snooping method. However, any other
method would have to do the same to ensure anti-spoofing for hosts with static
IP addresses.
- AN learning AR address: This is described in section 3.1 ("Obtaining the IP
and MAC addresses of the Access Router")

"IEEE mischaracterizing": In what way? I don't understand this point.

Redundant AR: The two ARs in the figure are not necessarily in a redundant
configuration. It just illustrates that some end-users can have MFF towards one
AR and others towards another AR. Redundant AR can be supported with VRRP.

[Ballot discuss]
Overall, I think the document is well-written and the motivation for something like this within the contest of residential ethernet is well articulated. However, there are some pretty strong issues with respect to whether this breaks existing protocols that need further attention.

While there may still be issues with IPv6 (posted by Margaret), the concerns I list here are with (1) VRRP, (2) overlap with IEEE (something that is becoming a common theme), and (3) applicability in an L2 wholesale environment.

1. From RFC2338 (VRRP):

> 8.2  Host ARP Requests
>
>    When a host sends an ARP request for one of the virtual router IP
>    addresses, the Master virtual router MUST respond to the ARP request
>    with the virtual MAC address for the virtual router.  The Master
>    virtual router MUST NOT respond with its physical MAC address.  This
>    allows the client to always use the same MAC address regardless of
>    the current Master router.
>
> 8.3 Proxy ARP
>
>    If Proxy ARP is to be used on a VRRP router, then the VRRP router
>    must advertise the Virtual Router MAC address in the Proxy ARP
>    message.  Doing otherwise could cause hosts to learn the real MAC
>    address of the VRRP router

The mechanism at the AN (Access Node) described in the draft requires the AN to discover the MAC address of the AR (Access Router) via ARP. If VRRP is running on the ARs, then only the Virtual Router MAC is going to be advertised. The filtering mechanisms described in the document would then cause the AN to drop any traffic sourced by the AR's physical MAC (which I believe is a common requirement). I don't see an obvious solution to this which does not require a significant change to VRRP.

2. There may be ways to do something similar here within existing IEEE specifications using interface specific forwarding tables, even with shared VLANs to subscribers. I have not researched all of the details, but I believe it should be investigated.

3. The draft suggests two methods for determining the IP addresses of the ARs, either via manual provisioning or DHCP snooping. The latter is preferable for L2 Wholesale environments, as requiring shared configuration access to the DSLAM can become problematic in these situations. DHCP snooping avoids this, but disallows subscribers static IP address assignment (which may be OK for this environment, but perhaps should be spelled out).

In summary, while I think this mechanism probably works for some specific deployments, I think a little more work needs to be done to point out that it is not a generic solution and could break some IETF protocols.

[Ballot comment]
Since Margaret has placed a DISCUSS, I won't, but the Gen-Art reviewer wonders if there is overlap with IETF work on VPNs. Also Harald thought it should
be Experimental - I am not sure about that.

Document: draft-melsen-mac-forced-fwd-03.txt
Trigger: IESG Tele-chat, 3 February 2005
Reviewer: Elwyn Davies
AD: Thomas Narten
Review Date: 31 January 2005

Intended status: Informational (Private Submission)

Review: As a document, this draft is in excellent shape and I would have few
qualms about it being accepted as an Informational RFC.  The target networks are
(broadband) access networks using Ethernet as a transport. The document seeks to
provide a form of VPN somewhere between L2 and L3 by combining Proxy ARP and
specially adapted filtering Ethernet bridges, with the object a providing a more
readily provisioned and more scalable form of VLAN on such Ethernet networks
without requiring the use of Ethernet VLAN tags.  The filtering bridges serve to
constrain the Ethernet traffic to travel between customer premises and an Access
Router which can then act as a security, access and routing controller for all
traffic in the access network, ensuring that traffic from different customers is
separated and is not visible to all connected hosts as it would be in a
conventional bridged Ethernet environment.

I have two concerns, one technical and the other regarding existing IETF work:
- (technical) Further thought ought to be given to limiting the dissemination of
multicast traffic - other customers could potentially join a multicast group
intended for a particular customer  - this is obviously a general issue with
multicast, but the accessibility of the common AR makes it relatively easy in
the suggested network.  Additional authorization may be needed.
- (IETF VPN work) There is some overlap with existing VPN work in the IETF
although it is addressing a somewhat different scenario and does not propose the
use of MPLS.  Personally I don't see this as a big problem and the solution
seems eminently useful in the particular scenario envisioned (primarily
SOHO/branch office situations, probably over limited geographic areas).

[Ballot comment]
Comment from the Ops directorate by Pekka Savola (Mar 30 17:47:13 PST 2005):

I wouldn't have a huge problem publishing this document, _if_ it
sufficiently clearly specified only a mechanism which only applies to
IPv4 traffic (and hopefully, would not harm multicast).  For example,
v6 could work alongside with v4 mac-forced forwarding.  Currently,
this is not possible AFAICS but just filtering (for example) the mac
addresses with ipv4 ethertype might be worth exploring.

[Ballot comment]
Since Margaret has placed a DISCUSS, I won't, but the Gen-Art reviewer wonders if there is overlap with IETF work on VPNs:

Document: draft-melsen-mac-forced-fwd-03.txt
Trigger: IESG Tele-chat, 3 February 2005
Reviewer: Elwyn Davies
AD: Thomas Narten
Review Date: 31 January 2005

Intended status: Informational (Private Submission)

Review: As a document, this draft is in excellent shape and I would have few
qualms about it being accepted as an Informational RFC.  The target networks are
(broadband) access networks using Ethernet as a transport. The document seeks to
provide a form of VPN somewhere between L2 and L3 by combining Proxy ARP and
specially adapted filtering Ethernet bridges, with the object a providing a more
readily provisioned and more scalable form of VLAN on such Ethernet networks
without requiring the use of Ethernet VLAN tags.  The filtering bridges serve to
constrain the Ethernet traffic to travel between customer premises and an Access
Router which can then act as a security, access and routing controller for all
traffic in the access network, ensuring that traffic from different customers is
separated and is not visible to all connected hosts as it would be in a
conventional bridged Ethernet environment.

I have two concerns, one technical and the other regarding existing IETF work:
- (technical) Further thought ought to be given to limiting the dissemination of
multicast traffic - other customers could potentially join a multicast group
intended for a particular customer  - this is obviously a general issue with
multicast, but the accessibility of the common AR makes it relatively easy in
the suggested network.  Additional authorization may be needed.
- (IETF VPN work) There is some overlap with existing VPN work in the IETF
although it is addressing a somewhat different scenario and does not propose the
use of MPLS.  Personally I don't see this as a big problem and the solution
seems eminently useful in the particular scenario envisioned (primarily
SOHO/branch office situations, probably over limited geographic areas).

[Ballot discuss]
I've put in a discuss (even though we maybe aren't expected to put discusses on these documents), because I want to talk about this on the telechat...

This proposal seems to be very incomplete and to have a few technical problems.

It tries to declare both IPv6 and multicast streams originating within a customer premise to be out-of-scope, but the fact is that use of this mechanism would cause significant problems for both IPv6 and customer-premise-originated multicast.  Can we object to the publication of this mechanism on the grounds that it is incompatible with existing IETF protocols?

Also, one basic assumption of this document is the VLAN will not work properly for this environment, so an alternative is needed.  The only argument in this draft for why VLANs would not work is "provisioning complexity", but the exact mechanism by which the AN will become aware of the IP addresses in use on the customer network is not defined, and there is no explanation of how the AN will find the address of the AR.  So, I am not sure how/if this mechanism will lower the provisioning complexity.  I am concerned about publishing an IETF document (which is how all RFCs are perceived) that mischaracterizes an IEEE protocol.

There is no explanation of how redundant ARs (as shown in the diagram) would be supported.  The "proxy ARP" mechanism described would cause a one-to-one dependency of a particular customer premise on a particular AR.

[Ballot comment]
Reviewed by Elwyn Davies, Gen-ART.
Question from me (Harald): Why isn't this Experimental?

Review: As a document, this draft is in excellent shape and I would have few
qualms about it being accepted as an Informational RFC.  The target networks are
(broadband) access networks using Ethernet as a transport. The document seeks to
provide a form of VPN somewhere between L2 and L3 by combining Proxy ARP and
specially adapted filtering Ethernet bridges, with the object a providing a more
readily provisioned and more scalable form of VLAN on such Ethernet networks
without requiring the use of Ethernet VLAN tags.  The filtering bridges serve to
constrain the Ethernet traffic to travel between customer premises and an Access
Router which can then act as a security, access and routing controller for all
traffic in the access network, ensuring that traffic from different customers is
separated and is not visible to all connected hosts as it would be in a
conventional bridged Ethernet environment.

I have two concerns, one technical and the other regarding existing IETF work:
- (technical) Further thought ought to be given to limiting the dissemination of
multicast traffic - other customers could potentially join a multicast group
intended for a particular customer  - this is obviously a general issue with
multicast, but the accessibility of the common AR makes it relatively easy in
the suggested network.  Additional authorization may be needed.
- (IETF VPN work) There is some overlap with existing VPN work in the IETF
although it is addressing a somewhat different scenario and does not propose the
use of MPLS.  Personally I don't see this as a big problem and the solution
seems eminently useful in the particular scenario envisioned (primarily
SOHO/branch office situations, probably over limited geographic areas).