Gen-ART Review of draft-ietf-l2vpn-vpls-mcast-reqts-05

[Christian Vogt <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.


Document..........:  draft-ietf-l2vpn-vpls-mcast-reqts-05
Reviewer..........:  Christian Vogt
Review date.......:  Nov 15, 2007
IESG Telechat date:  --


Summary:  This draft is basically ready for publication, but has nits
           that should be fixed before publication.

Comments:

(1)  Section 4.1.2, "Multicast Packet Types", says:

                                             Since the mapping between
    IPv4 multicast addresses and Ethernet layer multicast addresses is
    ambiguous (i.e., multiplicity of 1 Ethernet address to 32 IP
    addresses), MAC-based multicast forwarding is not ideal for IP
    multicast.

Would be good to provide some rationale here.  It seems that the
non-injective mapping from IP addresses to MAC addresses does not limit
scalability, provided the solution tracks IP addresses rather than MAC
addresses.  It also does not seem to have an impact on security.  The
worst that could happen would be that some hosts receive packets they
are not interested in.  Another undesired feature might be that network
administration becomes slightly more complicated.  But the reader is
left out in the rain here.  Giving some rationale would certainly help.


(2)  Section 4.3, "Backward Compatibility", says:

    A solution SHOULD be backward compatible with the existing VPLS
    solution.  It SHOULD allow a case where a common VPLS instance is
    composed of both PEs supporting the solution and PEs not supporting
    it, and the multicast forwarding enhancement is partially achieved by
    the compliant PEs.

The last sentence here should be "achieved *between* the compliant PEs"
because coordination will probably be required between the forwarding
side and the receiving side, thus requiring upgrades on both sides.  The
current text talks about the forwarding side only and so makes the
requirement more (IMO too much) ambitious.


(3)  Section 5.10, "Fate-Sharing...":

I don't see a reason for this section's claim that unicast and multicast
should always be either both up or both down.

The section currently calls for deliberate de-activation of one
transmission method in case the other transmission method fails.  Is
there any reason why a customer or a provider might benefit from such
policy? -- I think section 5.10 be removed from the draft.


(4)  Section 5.6, "Access Connectivity", should IMO be split into an
"Access Connectivity" section comprising the currently first paragraph,
and a "Multi-Homing" section comprising the rest.


(5)  Editorial

Section 1.1., 6th paragraph:  "VPLS PEs" is an unknown acronym at this
point.

Section 2.1:  "- Multicast Channel:  (S,G) in the SSM model" -- So
"multicast channel" is an SSM-specific term and is undefined for ASM?

Section 3.2, 1st paragraph:  "ingress PE" -- Is this the U-PE or the N-PE?

Section 3.3.1, "Native Ethernet service aspect":  s/Their main interest
is how to deal with the issue/Their main interest is solve the issue/

Section 3.3.1, "IP multicast service aspect":  s/Their main interest is
how to provide/Their main interest is to provide/

Section 4.1.1.1:  "Issues A and B" appeared long before, so better add a
page/section number in parentheses as a reference.


Hope this helps.
- Christian