MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network
RFC 4562

Note: This ballot was opened for revision 04 and is now closed.

(Thomas Narten) Yes

(Harald Alvestrand) No Objection

Comment (2005-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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).

(Brian Carpenter) No Objection

Comment (2005-03-31 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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).

(Margaret Cullen) (was Discuss) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

Comment (2005-03-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Mark Townsley) (was Discuss) No Objection

Comment (2005-03-31)
No email
send info
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.

(Bert Wijnen) No Objection

(Alex Zinin) No Objection

Comment (2005-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
A fine document, useful for the Internet community.