Subject: Re: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03 (fwd)

From: Pekka Savola <[email-masked]>
Date: Tue, 17 Jan 2006 10:36:14 +0200 (EET)

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 <[email-masked]>
To: Thomas Morin <[email-masked]>
Cc: [email-masked]
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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 17 Jan 2006 10:36:32 +0200 (EET)

---------- Forwarded message ----------
Date: Mon, 16 Jan 2006 18:58:43 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: Thomas Morin <[email-masked]>
Cc: [email-masked]
Subject: Re: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03

On Mon, 16 Jan 2006, Thomas Morin wrote:
> 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.

It'd be interesting to hear more comments on 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) ?

When the RP receives a Register message, it will (basically) send a 
Register-Stop immediately, see section 4.4.2 of the new PIM-SM spec. So, we're 
talking about 1 RTT between the DR and the RP.  I doubt this is a major problem 
-- the other RP engineering decisions are probably much more pressing.