[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03 (fwd)
Re-sending as this was probably accidentally rejected by the list
administrator (for the policy, see
http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt).
---------- Forwarded message ----------
Date: Mon, 16 Jan 2006 18:02:17 +0200 (EET)
From: Pekka Savola <pekkas at netcore.fi>
To: Thomas Morin <thomas.morin at rd.francetelecom.com>
Cc: l3vpn at ietf.org
Subject: Re: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03
Inline (I've cut off some parts which we agree on),
On Mon, 16 Jan 2006, Thomas Morin wrote:
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.
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.
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... ;-)
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). Certainly not in
such a manner that it would be visible to the VPN sites at least?
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.
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.
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)
[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
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...
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...)
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.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings