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

[Thomas Morin <thomas.morin at rd.francetelecom.com>]

Hi Pekka,

Thank your for having reviewed the draft and for your comments.

Pekka Savola:
> 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.

Well, the draft aims at being v4/v6 generic, and is not supposed to let
the reader think that IPv6 support is optional for a multicast VPN
solution.  It aims at saying that IPv6 multicast support is required for
a _VPN_solution_ (e.g. a unicast VPN solution like VR) that supports v6
and is extended to support multicast.

Maybe the text could be a little clearer, what about : 
"When a multicast VPN solution is built on a VPN solution supporting
IPv6 unicast, it MUST also support v6 variants of the above protocols,
including  MLD v.2, and PIM-SM IPv6 specific procedures."
?

And we can even push a little further: "For a multicast VPN solution not
built on a unicast VPN solution supporting IPv6, it is RECOMMENDED that
the design favors the definition of procedures and encodings that will
provide an easy adaptation to IPv6".



> 
> 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/

Well, I would argue that:
- things like this exist for unicast (think RSVP-TE tunnels between PEs)
- it is worded "should" not "SHOULD" : the wording of the rest of the
sentence is vague enough to no let us make a strict requirement


> 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.

Well...
1) even such transient peaks may not be something that you'll want
2) what if you lose connectivity to the remote site hosting the RP, are
you happy to lose local multicast on every other site?
3) what if you want to stick with RPT ? 
   [okay, maybe not so relevant, but what if the VPN customer wants to
    do this ?]


> 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.

Thank you to provide this one: I was just looking for a
usefull-and-non-expired reference about MTU issues !  ;)

> 
>     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..?

Yes, it would indeed be nice.
Still, today its unclear which one we would chose as mandatory.



> 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.  
[snip]

You are right.

I propose to move this sentence to previous section "Management tools,
OAM", at the end of the paragraph saying "The operation of a multicast
VPN solution SHALL be as light as possible and providing automatic
configuration and discovery SHOULD be prioritized. Particularly the
operational cost of setting up multicast on a PE SHOULD be as low as
possible.".


> editorial
> ---------
> 
> ==> you should add a dummy IANA considerations section

Sorry, to nit-pick, but where is it stated that all document should do
this ? (where is the MUST in RFC2434?). Since this would be particularly
irrelevant for a requirement document such as this one, I'd prefer not
adding one more paragraph...


>     Service management should also include the TMN 'FCAPS'
>     functionalities, as follows: Fault, Configuration, Accounting,
>     Provisioning, and Security.
> 
> ==> 'P' stands for Performance, I think.

Yep. That one is in fact already corrected in my copy.


> 
>     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?

Agreed.

> 
>     [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.

Agreed.


> 
> 
>     [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.


RFC2629 is referred to in the appendix
RFC3978 is BCP 78, referred to in IPR boilerplate

2026 actually is not referred to

> (not sure if there are more of these)

There were some, now fixed.


> 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.

Agreed.


> 
> ....
> 
> 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)

Well, this was suggested by a reviewer, and I think it can be useful.
I am open to other inputs, it is true that is requires particular
care... its somehow a matter of benefit/risk trade-off.

(the feature you quote is interesting indeed, but looks only useful with
one requirement item per sub-section, and subsection title chosen to
match there use in the resulting summary...)

Cheers,

-Thomas