[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03
Hi Pekka,
(inline)
Pekka Savola:
> >> ==> 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.
>
> 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.
> > 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".
>
> 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.
> >> 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
>
> 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 [...]".
> >> 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 ?]
>
> 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) ?
> >> 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...
>
> 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. :)
> >
> > RFC2629 is referred to in the appendix
> > RFC3978 is BCP 78, referred to in IPR boilerplate
>
> 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.