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

["Yuji KAMITE" <y.kamite at ntt.com>]

Hi Pekka,

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

Yes,  it is definitely worth considering common viewpoints,
which would give us good opportunities to take similar approaches.
That's why l2vpn mcast requriment tries to borrow some l3vpn reqt's wording
and ideas that has common points (Actually l3vpn work item was preceding
l2vpn a little recently).

However, that's not enough yet.  Most other parts are needed to be
considered spearately in detail because they are dealing with different
layer protocols.  In l3vpn, there are lots of IP routing layer consideration, that is 
not needed in l2vpn, while l3vpn does not need to MAC address consideration.
We should avoid having just too generic and vague requirements.

Regards,

-Yuji


> -----Original Message-----
> From: l3vpn-bounces at ietf.org [mailto:l3vpn-bounces at ietf.org] 
> On Behalf Of Pekka Savola
> Sent: Saturday, January 14, 2006 11:24 PM
> To: l3vpn at ietf.org
> Subject: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03
> 
> 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
>