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

From: Pekka Savola <[email-masked]>
Date: Sat, 14 Jan 2006 16:24:27 +0200 (EET)

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

---

From: "Yuji KAMITE" <[email-masked]>
Date: Mon, 16 Jan 2006 20:47:19 +0900

Hi Pekka,

> 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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Pekka Savola
> Sent: Saturday, January 14, 2006 11:24 PM
> To: [email-masked]
> Subject: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03
> 
> Hi,
> 
> 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.
> 
> 
> ==> 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.)
> 
> ==> 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
> 
> ==> 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
> 
> ...
> 
> 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.
> 
> ==> 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..?
> 
> ==> 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:
> ==> 1157 is no longer standardized, as it has been made 
> Historic.  Refer to the later SNMPv2/SNMPv3 RFCs?
> 
> ==> you should probably use RFC2003 instead, as RFC1853 just 
> informational while 2003 is standards track.
> 
> 
> ==> 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.
> ==> 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. 
> If either of these is a "yes", then the reference should 
> likely be normative.
> 
> ....
> 
> ==> 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)
> 
> 
> --

---

From: Thomas Morin <[email-masked]>
Date: Mon, 16 Jan 2006 16:36:28 +0100

Hi Pekka,

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

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

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

> and then back.  I.e., there should not be two times traffic once the 

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

> 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 !  ;)

> different vendors, operators, etc. could be interoperable..?

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

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

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

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

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

> the later SNMPv2/SNMPv3 RFCs?

Agreed.

> while 2003 is standards track.

Agreed.

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

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

Agreed.

> degree of autogeneration of these using xref format=title  (see RFC 3871 appendix A for

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

---

From: Thomas Morin <[email-masked]>
Date: Mon, 16 Jan 2006 17:42:19 +0100

Hi Pekka,

(inline)

Pekka Savola:
> Good point, I missed this nuance of the text because I assumed that 1) 
> all the existing VPN solutions already support IPv6 (is there one that 
> doesn't?) or 2) the multicast VPN solutions might not depend on 
> the unicast VPN solutions.

Well, AFAIK, IPv6 support for PPVPN solution seems to be more the
exception than the rule: v6 support is in l3vpn charter,
draft-ietf-l3vpn-bgp-ipv6 is in "IESG Evaluation" state. Dunno about VR.

> Are there standards track unicast VPN solutions that don't support 
> IPv6?  If not, the language could probably be greatly simplified. If 
> yes, let me summon a lynching party... ;-)

See above.

> I do not know RSVP-TE well enough to know whether this is true or not, 
> but at least my impression is that even RSVP-TE does not support (at 
> least) _admission control_ (that seems something you'll need to set up 
> first).

RSVP-TE does admission control on its path.

>   Certainly not in such a manner that it would be visible to 
> the VPN sites at least?

True.

But if the provider does RSVP-TE (in its core) for the P2MP tunnels used
by his clients, that may will be an advantage for QoS related aspects.

> In other documents, lower-case keywords may sometimes be interpreted 
> as even stronger than uppercase, so unless the unicast mechanisms 
> really exist and have bene widely deployed, I'd still suggest a MAY or 
> rewording.

Ok, this would avoid any ambiguity: "a multicast VPN solution MAY
provide additional features [...]".

> I should have been more specific.  I agree that the "RP engineering" 
> problem exists: deciding where to put the RP has many different 
> tradeoffs to consider -- there isn't a one-size-fits-all approach.
> 
> I was commenting on the double traffic issue specifically, 1) above. 
> I don't think it really exists for valid configurations.  RPs tend to 
> send Register-Stop *immediately* so you shouldn't see even a transient 
> peak (longer than less than a second that is) due to this.

Sorry, but isn't "a second" (even a very short one), transient ? 
Also, what does "immediately" mean (especially across a multicast VPN
and a provider core) ?

> That's a rather recent addition, so it isn't in any RFC, but it can be 
> found here:
> 
> http://www.ietf.org/ID-Checklist.html (see Changelog under Revision 
> 0.4)

Okay then. :)

> But RFC3978/BCP78 hasn't been referred in [square brackets], and 
> moreover, this is a bit against the spirit (as this is a _symbolic_ 
> reference) of ID-Checklist section 2.1 point:
> 
> "7. Do not add a numbered reference in the I-D boilerplate to RFC 3978 
> or RFC 3979 (or to RFC 2026, RFC 3667 or RFC 3668 for older 
> documents). If you do, it makes it harder for the RFC editor to 
> process the document when they strip off the I-D boilerplate."
> 
> In any case, the reference would be stripped off when publishing as 
> RFC, so...

Okay then.

---

From: Thomas Morin <[email-masked]>
Date: Mon, 16 Jan 2006 17:42:24 +0100

Hi folks,

Pekka Savola:
> I'm OK with leaving it in if that's what the WG thinks is appropriate. 
> However, the document is already pretty long, and any means to reduce 
> the length should be considered.

Anyone opinion on this is welcome...
I can live without the burden of updating this "Requirements summary"
section, but I would also understand if people that find it useful ask
for keeping it: raise your voice if you are one of them.

-Thomas