comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03

[Pekka Savola <pekkas at netcore.fi>]

Hi,

On MBONED WG, folks were asked to take a look at 
draft-ietf-l3vpn-ppvpn-mcast-reqts-03, so here goes.

> From the external point of view, what's the relation to 
draft-ietf-l2vpn-vpls-mcast-reqts-xx?  It'd seem to me that it'd be 
HIGHLY desirable that at least the bulk of the solutions used could be 
the same...  Operators shouldn't need to deploy two completely 
different solutions for both L2 and L3VPNs.


more or less substantial comments
---------------------------------

5.1.2.  CE-PE Multicast routing and management protocols

   When IPv6 is supported by a VPN solution, relevant IPv6 corresponding
   protocols MUST also be supported, e.g.  Multicast Listener Discovery
   Protocol (MLD) (v1 [RFC2710]], v2 [RFC3810]]).

==> The IPv6 part requires wordsmithing.  The IETF will *NOT* allow 
specification of a standards track solution which does not support 
IPv6.  This text seems to imply that IPv6 support could be optional.

(you might also clarify which IGMP/MLD versions should be supported 
and which not.)

5.1.3.  Quality of Service (QoS)

....

   As multicast is often used to deliver high quality services such as
   TV broadcast, the solution should have additional features to support
   high QoS such as bandwidth reservation and admission control.

==> are these available for unicast?  Seems like you're asking more of a
multicast solution than from unicast.  I'd remove these kind of
"nice-to-have" reqs, or rephrase s/should/MAY/


5.1.11.  RP Engineering

   When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer
   side, the location of the RP has to be chosen.  In some cases this
   engineering problem is not trivial: for instance, if sources and
   receivers are located in VPN sites that are different than that of
   the RP, then traffic may flow twice through the SP network and the
   CE-PE link of the RP (from source to RP, and then from RP to
   receivers) ; this is obviously not ideal.  A multicast VPN solution
   SHOULD propose a way to help on solving this RP engineering issue.

==> I'm not sure if this specific problem exists in practice.  If the 
RP sends Register-Stop, the multicast traffic is forwarded natively, 
and the data will short-cut inside the site without going to the RP 
and then back.  I.e., there should not be two times traffic once the 
forwarding is native.

5.1.13.  Minimum MTU

...

   It SHOULD also be compatible with Path MTU discovery mechanisms, such
   as those defined in [RFC1191] or [I-D.mathis-frag-harmful].

==> you may be interested in looking at 
draft-savola-mtufrag-network-tunneling-05.txt which was just recently 
approved for publication.  Depending on the MDT solution, this may 
have relevant discussion on MTU handling methods.

   For MDTunnels (multicast distribution tunnels, the means used to
   carry VPNs' multicast traffic over the provider's network), a
   solution SHOULD be able to use a range of tunneling technologies,
   including point-to-point and point-to-multipoint, such as GRE
   [RFC2784] (including GRE in multicast IP trees), MPLS [RFC3031]
   (including P2P or MP2P tunnels, and multipoint tunnels signaled with
   MPLS P2MP extensions to RSVP [I-D.ietf-mpls-rsvp-te-p2mp] or LDP
   [I-D.leroux-mpls-mp-ldp-reqs][I-D.minei-wijnands-mpls-ldp-p2mp]),
   L2TP (including L2TP for multicast [RFC4045]), IPsec [RFC2401], IP-
   in-IP [RFC1853], etc.

==> you should probably also a) specify, or b) require that the 
solution will specify one or two mandatory to implement tunneling 
mechanisms, so that there would be ways how MDTunnels between 
different vendors, operators, etc. could be interoperable..?

5.2.10.  Architectural Considerations

   As far as possible, the design of a solution should carefully
   consider the number of protocols within the core network.  If any
   additional protocols are introduced compared with unicast VPN, the
   balance between their advantage and operation burden should be
   examined thoroughly.

==> these are not "Architectural Considerations", maybe rather 
Operational Considerations, IMHO.  Let's take an example:  ISP is 
unicast-only and solution A proposed using standards-track multicast 
protocols to offer a service, and solution B would imply reinventing 
multicast signalling inside the unicast protocols.

In my opinion, solution A is clear architecturally a best solution.  The
above paragraph makes this sound like B would be favorable from the
*architectural* point-of-view.  Perhaps this section needs to be generalized
to bring out the different tradeoffs better, for example:
 - the benefits of using existing multicast technologies
 - the drawbacks of deploying the existing multicast technologies
 - the benefits of shorning multicast protocols into commonly deployed unicast
   protocols
 - the drawbacks of reinventing the wheel
 - etc.

editorial
---------

==> you should add a dummy IANA considerations section

   Service management should also include the TMN 'FCAPS'
   functionalities, as follows: Fault, Configuration, Accounting,
   Provisioning, and Security.

==> 'P' stands for Performance, I think.

   Resiliency is also crucial to infrastructure security, thus a
   multicast VPN solution SHOULD whether avoid single points of failures
   or propose some technical solution making possible to implement a
   fail-over mechanism.

==> s/whether/either/

   All or part of this information SHOULD be made available through
   standardized SNMP ([RFC1157]) MIBs (Management Information Base).

==> 1157 is no longer standardized, as it has been made Historic.  Refer to
the later SNMPv2/SNMPv3 RFCs?

   [RFC1853]  Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

==> you should probably use RFC2003 instead, as RFC1853 just informational
while 2003 is standards track.


   [RFC3978]  Bradner, S., "IETF Rights in Contributions", BCP 78,
              RFC 3978, March 2005.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

  [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

==> these are not referred to in the body of the draft (when the document
gets published by the RFC editor), so they can be removed.
(not sure if there are more of these)

8.2.  Informative references

   [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
              March 1999.

   [I-D.ietf-l3vpn-rfc2547bis]
              Rosen, E., "BGP/MPLS IP VPNs",
              draft-ietf-l3vpn-rfc2547bis-03 (work in progress),
              October 2004.

   [I-D.ietf-l3vpn-vpn-vr]
              Knight, P., Ould-Brahim, H., and B. Gleeson, "Network
              based IP VPN Architecture using Virtual Routers",
              draft-ietf-l3vpn-vpn-vr-02 (work in progress), April 2004.

==> these and many more are referred to in so many places of the drafts in a
very normative way, and should really be under the normative references. 
Some others as well -- please consider each with the following question in
mind:

 - is reading this reference required to understand this document?
   (rather than providing some optional additional information)
 - if the reference changed radically before publication, would this
   document need to be reflected as well?

If either of these is a "yes", then the reference should likely be
normative.

....

Appendix A.  Requirements summary

==> I'd consider removing this, because these should be extractable from the
body of the document, and these could get out of date easily if the editors
are not really, really careful.  Recent xml2rfc includes support for some
degree of autogeneration of these using xref format=title  (see RFC 3871 appendix A for
example)


--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings