Subject: WG last call: draft-ietf-l3vpn-ppvpn-mcast-reqts-03

From: Ron Bonica <[email-masked]>
Date: Wed, 04 Jan 2006 09:51:01 -0500

Folks,

This email initiates a WG last call for
draft-ietf-l3vpn-ppvpn-mcast-reqts-03. Last call ends Jan 19, 2006.

                               Ron

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 05 Jan 2006 13:39:12 -0800

Ron,

> draft-ietf-l3vpn-ppvpn-mcast-reqts-03. Last call ends Jan 19, 2006.

I suggest to add the following to either 5.1.5 or 5.2.7:

   For security reasons service providers may want to confine
   direct control traffic exchange among the providers to a combination
   of ASBRs (or even a subset of ASBRs) that connect the providers,
   and (optionally) a designated set of BGP Route Reflectors.
   For one thing, doing this would allow to MD5-key all control
   traffic exchanges among providers, while confining MD5 key
   administration to just the ASBRs (or even a subset of ASBRs),
   and Route Reflectors.

Yakov.

---

From: Thomas Morin <[email-masked]>
Date: Mon, 09 Jan 2006 10:15:12 +0100

Hi Yakov, folks, 

>    administration to just the ASBRs (or even a subset of ASBRs),

I suggest adding the following atfer penultimate sentence of 5.2.7,
rephrased as follows:
"It is RECOMMENDED that corresponding procedures require the least
possible coordination between providers; more specificaly when specific
configurations or cryptographic keys have to be deployed, this shall be
limited to ASBRs (Autonomous Systems Border Routers) or a subset of
them, and optionnaly BGP Route Reflectors (or a subset of them)." 

("corresponding procedures" refers to "means to ensure the integrity and
authenticity of multicast-related exchanges across inter-ASes or
inter-provider borders")

I think this respect the initial idea, but without making any assumption
on the implementation.  What do you think?

-Thomas

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 11 Jan 2006 01:18:18 -0500

> on the implementation.  What do you think?

s/optionnaly/optionally/

Otherwise, OK.

Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 11 Jan 2006 01:36:52 -0500

As my first attempt bounced, you can find my comments and corrections
on this document at

http://www.americafree.tv/papers/draft-ietf-l3vpn-ppvpn-mcast-reqts-03-tme.txt

I gave this document a careful read. In my opinion there are a bunch of mostly
minor things that need to be corrected before it passes last call.

Regards
Marshall Eubanks

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 15 Jan 2006 07:40:15 -0800

Ron,

> draft-ietf-l3vpn-ppvpn-mcast-reqts-03. Last call ends Jan 19, 2006.

In 5.1.7 I would suggest to add the following to the bullet list:

      A solution must allow to control an extranet multicast 
      connectivity independently from the extranet unicast 
      connectivity

Yakov.

---

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

Hi Marshall,

> minor things that need to be corrected before it passes last call.

Thank you for your review and all your relevant comments, there are very
appreciated.

See below for comments to some of your suggestions or questions, and the
changes I propose to address them.  I integrated "as is" (or mostly "as
is") all of your others comments, which were definitely reasonable.

Cheers,

-Thomas

>    VRF or VR: By this phrase, we refer to the entity defined in a PE
>       dedicated to a specific VPN instance.  "VRF" refers to [RFC2547]
>       terminology, and "VR" to the VR [I-D.ietf-l3vpn-vpn-vr]
>       terminology.
> 
> tme> I have read this several times and still don't know what "entity" is being referred
> tme> to.
> tme> VR == "Virtual Router"
> tme> VRF == "Virtual Routing and Forwarding table"
> tme> This phrase is used 4 times, not counting here. The next is
> tme> 
> tme> Moreover, the activation of multicast features SHOULD be possible:
> tme>    o  with a VRF or VR granularity
> tme> This is not really clear either.
> tme> Does it mean, for each routing table, or each entry on the routing table ?
> tme> Note that VRF and VR are both used separately
> tme> 
> tme> Here is a stab at a definition
> tme>
> tme> VRF or VR: By this phrase, we refer to the finest scale multicast routing 
> tme> information available, as maintained by the Virtual Router (VR, see [I-D.ietf-l3vpn-vpn-vr])
> tme> or the Virtual Routing and Forwarding table (VRF, see [2547bis])

Well, a VRF is a routing table (not an entry), and a VR (virtual router)
is somehow of the same level (contains protocol routing instance, and
routing tables).

So, here is the wording I propose to avoid any confusion:

"By this phrase, we refer to the entity defined in a PE dedicated to a
specific VPN instance. "VRF" refers to "VPN Routing and Forwarding
table" as defined in [I-D.ietf-l3vpn-rfc2547bis], and "VR" to "Virtual
Router" as defined in  [I-D.ietf-l3vpn-vpn-vr] terminology."

Moreover, I reworded section in 5.1.5:
"Moreover, the activation of multicast features SHOULD be possible:
      * per VRF / per VR
      * per CE interface (when multiple CE of a same VPN are connected
        to a common VRF/VR)
      * per multicast group and/or per channel
      * with a distinction between multicast reception and emission"

[about section 3.3]
> tme> Why isn't is a general requirement to interoperate with existing _multicast_
> tme> deployments ?  rfc4021 says little about multicast - shouldn't this be explicit ?

Well the idea is to highlight the focus : in a VPN deployment context,
one of the most crucial requirement is to cohabit with the existing
service (unicast VPN).

You are right in the sense that deploying a multicast VPN solution
should nicely cohabit with existing deployment of multicast on P and PE
routers, and on CE routers.  

I added two sentences:
- in 5.1.1:  "Enabling a VPN for multicast support SHOULD be possible
with no (or very limited impact) on existing multicast protocols
possibly already deployed on the CE devices."
- in 5.2 : "The deployment of a multicast VPN solution SHOULD be
possible with no (or very limited) impact on possibly existing
deployments of multicast protocols on P and PE routers."

Would that be ok ?
 
>    o  some of these applications may involve rapid changes in customer
>       multicast memberships, but this will depend on audience and
>       capillarity of provider equipments
> 
> tme> "capillarity" is a very obscure English word, and I do not know what is meant here.
> tme> could this be a typo for "capabilities" ?

No typo, but maybe the use of this term is less common in english than
"capilarit'e" is in french... :)  We sometime use it metaphorically to
refer to the number of small elements at the periphery of something,
like leaves of a tree, with the image of capillary vessels in lungs for
instance.

I rephrased as: "some of these applications may involve rapid changes in
customer multicast memberships as seen by the PE, but this will depend
on audience patterns and on the number of provider equipments deployed
close to VPN customers".

> 4.1.2.  Symetric applications
> 
> tme> nit : s/Symetric/ Symmetric /
> 
>    Some use cases exposed by the survey can be grouped under this label,
>    and include many-to-many applications such as conferencing, clusters
>    monitoring.
> 
> tme> (relative) nit : I do not know what "clusters monitoring" means in this context.
> tme> Is this for entities like beowulf clusters over VPN's ? 
> tme> An extra word to explain this would help.

Survey responses did not include such a level of detail, so I can only guess here.
I rephrased as: "server clusters monitoring". 

> 4.2.2.  Number of multicast VPNs per PE
> 
>    The majority of survey answers express a number of multicast VPNs per
>    PE of around tens (8 responses between 5 and 50); a significant
>    number of them (4) expect deployments with hundreds or thousands (1
>    response) of multicast VPNs per PE.
> 
>    A solution SHOULD support a number of multicast VPNs per PE of
>    several hundreds, and may have to scale up to thousands VPNs per PE.
> 
> tme> PE means "provider edge". Does this mean, number per edge location, or
> tme> number over all locations. I would suggest
> tme> s/scale up to thousands VPNs per PE/scale up to thousands VPNs per PE location/
> 

RFC4026 "Provider Provisioned VPN Terminology" section 5.2 precisely
suggest the use of "PE" and "CE" to refer to the devices themselves.
That actually what we are used to do in l3vpn (for brievity).

I added the following in the terminology section:
" "Provider Edge", "Customer Edge" (as defined in [RFC4026](Andersson,
L. and T. Madsen, “Provider Provisioned Virtual Private Network (VPN)
Terminology,” March 2005.)). As suggested in [RFC4026](Andersson, L. and
T. Madsen, “Provider Provisioned Virtual Private Network (VPN)
Terminology,” March 2005.), we will use these notations to refer to the
equipments/routers/devices themselves. Thus, "PE" will refer to the
router on the provider's edge, which faces the "CE", the router on the
customer's edge. "

> 5.1.2.  CE-PE Multicast routing and management protocols
>
[snip]
> 
> tme> Note that IGMP v3 and MLD v2 support means support for IGMP v1,v2 and MLD v1
> tme> So, I would suggest :
> 
> tme>   Among those protocols, the support of PIM-SM (version 2, revised, which
> tme>   includes SSM model) and either IGMP v.3 (for IPv4 solutions) and / or 
> tme>   MLD v.2 (for IPv6 solutions) are REQUIRED.

Agreed.
I also followed your implicit suggestion, by mentioning that hosts only
implementing -v1 and -v2 are implicitely supported by IGMPv3 queriers.

>    A multicast in VPN solution shall allow to define at least the same
> tme> nit : s/shall allow to define/SHALL allow definition of/

maybe "SHALL allow the definition of" ?

>    As multicast is often used to deliver high quality services such as
>    TV broadcast, the solution should have additional features to support
> tme> nit : s/should/SHOULD/
>    high QoS such as bandwidth reservation and admission control.

Since when is it MANDATORY to use CAPITALIZED version of those words ?
Here I fell it hard to use a strict wording, considering how precise the
rest of the sentence is.

>    The solution MUST support SLA monitoring capabilities, which MAY
>    possibly rely upon similar techniques (than those used by the unicast
> 
> tme> I puzzled over this - I suggest
> tme> s/similar techniques (than/different techniques than/
>    for the same monitoring purposes).
> tme> s/)//

Ok, that one indeed may be puzzling ; "which MAY possibly rely upon
techniques similar to those used for the unicast service for the same
monitoring purposes"  will be better I guess.

> 5.1.8.  Internet Multicast
> 
>    Connectivity with Internet Multicast (as a source or receiver)
>    somehow fits in the context of the previous section.
> 
> tme> Is this a stub for missing text ? This must be filled out to pass last call IMHO.

Well, this section was supposed to be complete, describing the
connectivity to/from Internet Multicast a similar to the connectivity
to/from another multicast VPN.

> 
>    It should be considered OPTIONAL given additional considerations
>    needed to fulfill requirements for Internet side, such as security
>    treatment.
>
tme> Here is some text :
[snip]

The text you propose is I think partly redundant with section 5.1.7
"Extranet".  I would like to just put in this section things that are
specific to Internet Multicast connectivity (if there are any):
- MSDP might be one of these, though I'd suspect not : MSDP is only
inter-RP, so if no RP is deployed in VRF (acceptable), then no MSDP
requirement is relevant here ; and in any case, I don't see that we'd
need to state MSDP-related requirement for the overall architecture
(same for embbeded-RP)
- we may need to state MBGP-related requirement: I'm not sure precisely
what we should say, since anything a bit precise would require
articulation with what is expected for unicast Internet Connectivity in
such a case.

Maybe adding the following would be enough : "MBGP support in VRF/VR
would be REQUIRED if a Multicast VPN solution supports connectivity with
Internet Multicast. MSDP support in VRF/VR also is REQUIRED for such a
solution, if it supports the RP functionality in VRF/VR".

Would you agree ?

>    The use of globally unique means of multicast-based service
>    identification at the scale of the domain where such services are
>    provided SHOULD be recommended.  If the ASM model is used, this
> 
> tme> SSM also has source scoping, 239/8 can be used with either SSM or ASM. Therefore
> tme> s/If the ASM model is used, this/For IPv4 multicasts, this/

I rephrased as follows:

"For IPv4 multicast, this implies the use of the multicast
administratively scoped range, (239/8 as defined by [RFC2365]) for
services which are to be used only inside the VPN, and of or SSM-range
addresses (232/8 as defined by [I-D.ietf-ssm-arch]) or globally assigned
group addresses (e.g. GLOP [RFC3180], 233/8) for services for which
traffic may be transmitted outside the VPN ."

> 5.1.13.  Minimum MTU
> 
>    For customers, it is often a serious issue whether transmitted
>    packets will be fragmented or not.  In particular, some multicast
>    applications might have different requirements than those that make
>    use of unicast, and they may expect services that guarantee available
>    packet length not to be fragmented.
> 
>    Therefore, a multicast VPN solution SHOULD let customers' devices be
>    free of any fragmentation or reassembly activity.
> 
>    A committed minimum path MTU size SHOULD be provided to customers.
>    Moreover, since Ethernet LAN segments are often located at first and
>    last hops, a minimum 1500 bytes IP MTU SHOULD be provided.
> 
> tme> There are a lot of tunnels used in multicast, and they tend to
> tme> restrict MTU's to a little below the 1500 coming from Ethernet
> tme> Are you really saying that no existing GRE or PPPoE or IP-IP multicast
>tme> tunnel can be used in multicast VPN architectures ? This seems extreme.

tme> In fact, since these tunnel types are allowed in Section 5.2.3.1.,
> tme> I do not know how they can be implemented in most networks (unless
> tme> jumbo frames are used throughout).

Encapsulation that would limit the MTU is encapsulation between PE
routers.  Those are often mutually reachable with high troughput links,
such as GE w/ Jumbo Frames, POS... for which MTU can be easily made
above 1500 I think.

What we are saying only means that:
a) if tunneling is used, then the provider should be able to commit to a minimum MTU
b) is possible (SHOULD) this MTU should be 1500, because this is what
will require the less tuning of customer application (which we expect
can initialy be used inside a LAN, without tunnels)

Consequently:
- if the Multicast VPN solution doesn't meet b), then it doesn't meet
the "SHOULD" (which may be acceptable, as soon as there is a rationale
behind it)
- it the provider's network cannot meet b), then it is less good than if
it would

Thus, a multicast VNP solution requiring the use of GRE or or IP-IP
multicast for PE to PE tunnels is completely be acceptable:
- GRE or IP-IP, by itself, doesn't I think limit the MTU 
- a provider network for which some PE-to-PE path go through a small MTU
interface (like a Fast Ethernet LAN interface) won't be able to meet
this requirement : this is not so common I think, and in any case that
may be acceptable (client will tell you)

PPPoE is intrinsicaly more limited, but I think nobody would like to use
it for PE-to-PE communication right ?

In anycase, nothing precludes any tunneling mechanism by itself, and
1500-byte minimal MTU is only a SHOULD.

> tme>
> tme> I would suggest either s/1500/1476/ or 
> tme> s/1500 bytes/1500 bytes, including any necessary tunnel headers/
> tme> but the latter is sure to be confusing.

We talk about "1500 byte IP MTU", which refers to the minimum MTU made available to the customer
(who doesn't "see" any tunnel).  Isn't this precise enough.

[section 5.2.1]
> 
> tme> This seems garbled. Do you mean "point to point, point to multipoint",
> tme> or is the first "point" just a duplicate ? As a guess,
> tme> s/point/point to point,/
> 
Yes, "point" is a duplicate.

> 
> tme> again, this seems garbled. I think this is meant :
> tme>  s/leaves/leafs/

Hmm. Isn't "leaf" like "knife", "life", or "scarf" ?

>    Unwanted multicast traffic (e.g. multicast traffic that may be sent
>    by a source located somewhere in the Internet and for which there is
>    no interested receiver connected to a given VPN infrastructure) MUST
>    NOT be propagated within a multicast-enabled VPN.
> 
> tme> Is this consistent with Section 5.2.2.3. ? It seems to me that this 
> tme> should be a SHOULD NOT to allow for sub-optimal solutions

While it might be acceptable (for provider-side scalability) that some
traffic reaches a PE even if this is not needed, it would not be
acceptable that such traffic be propagated toward the CE, inside the
customer network.

Isn't this reasonable ?

>    As an illustration, one can consider the case of a solution that
>    would use PIM-SM as a means to setup MDTunnels.  In such a case, the
>    PIM RP might be a single point of failure.  Such a solution should
>    thus be compatible with a solution implementing RP resiliency.
> 
> tme> s/./, such as is provided by anycast RP [draft-ietf-pim-anycast-rp-04]./

I also added BSR, for completeness.

---

From: Thomas Morin <[email-masked]>
Date: Mon, 16 Jan 2006 14:49:39 +0100

Hello Yakov,

>       connectivity independently from the extranet unicast 

Agreed.
I just used capitalized "MUST" instead of "must".

Cheers,

-Thomas

---

From: Yiqun Cai <[email-masked]>
Date: Mon, 16 Jan 2006 10:28:01 -0800

Yakov,  Thomas,

I have some doubt regarding this.

By "extranet multicast connectivity",  do you mean procedure of RPF  
to the
source,  the distribution of multicast data traffic to the receivers  
in different
VPNs, or something else.

Multicast RPF is built based on unicast routing information.  So  
there is a
dependancy existing today.  A solution does provide more flexibility  
if it allows
RPF to be independent of unicast routing,  but I dont see it as a  
"must".

For distribution of multicast data,  since they are controlled by  
join/prune
messages,  they are independent of unicast data distribution in nature.
So I don't see how this bullet is applicable.

If it is something else,  could you please elaborate?

Thanks a lot.

--
Yiqun

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 16 Jan 2006 21:27:42 -0500

Hello;

> RPF to be independent of unicast routing,  but I dont see it as a

For intra domain, I would agree. For interdomain multicast, MBGP allows for
different unicast and multicast routing topologies, and that would need
to be preserved.

As I read this, extranet means a situation where different unicast and
multicast routing topologies are likely, and thus I think that the
bullet is needed.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 16 Jan 2006 21:36:18 -0500

Hello;

I will read and respond when possible.

> Here I fell it hard to use a strict wording, considering how precise the
As it says,

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119.

I believe that the capitalization is required to trigger the RFC-2119
interpretations.

And, I have never seen  "capillarity" actually used in English. It's
in the dictionary, even in my spell checker, and it might be used in
botany, but it's not used metaphorically.

Regards
Marshall

On 1/16/06, Thomas Morin <[email-masked]> wrote:
> L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN)
> Terminology," March 2005.)). As suggested in [RFC4026](Andersson, L. and
> T. Madsen, "Provider Provisioned Virtual Private Network (VPN)
> Terminology," March 2005.), we will use these notations to refer to the

---

From: Yiqun Cai <[email-masked]>
Date: Mon, 16 Jan 2006 19:12:05 -0800

> multicast routing topologies are likely, and thus I think that the

Marshall,

I'm not sure that is the case.

In simple multicast term,  extranet means that the sources and the
receivers may potentially belong to different MVPNs.  Although it is
not required,  it generally implies that the sources and receivers
also belong to different unicast VPNs.   When the underlying routing
topologies are not congruent, a solution of MVPN has to deal with it.
But I don't see that as a requirement of "extranet".  It is more a  
baseline
requirement.

Thanks.

--
Yiqun

---

From: Thomas Morin <[email-masked]>
Date: Tue, 17 Jan 2006 11:04:11 +0100

Hi Yiqun,

The idea, I think, is to have the ability to have a VRF be associated to
multiple VPNs, independently for multicast and unicast, and also
independently for emission and reception.

First point : unicast is not dependent on multicast. So you may very
well want to have a VRF be associated to a VPN for unicast without
activating multicast reception from (or multicast emission to) this VPN.

Second point : as you explain, multicast reception is dependent on
unicast for RPF. However, if you want to emit mcast from a VRF to a VPN,
you don't depend on unicast (no need to have the routes of that VPN in
your VRF).  Thus, you could activate multicast emission to a VPN without
importing its routes into your VRF (just VRFs of that VPN will import
your routes).

I think its important for security aspects, to have full-control of what
routes you import/export and of which VPN you associate to for
emission/redeption.  Here, having coupling (being forced to activate a
broad scope feature, only to use a subset) would not be good I think.

Cheers,

-Thomas

---

From: David Meyer <[email-masked]>
Date: Tue, 17 Jan 2006 07:57:33 -0800

> botany, but it's not used metaphorically.

	As I was mentioning to Marshall earlier, actually, the
	term capillarity is in common use in the carrier industry
	(usually used to describe the extent and density of a
	carrier's transport network). As such, I don't find the
	fact the google doesn't know that disqualifying, and
	further, most of us who have worked in that side of the
	industry consider it common usage.

	Dave

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 17 Jan 2006 16:22:29 -0500

Well, a google on the "capillarity of carrier network" (without the
quotes) does return 653 hits, so Dave is correct in that it is used
that way at least some, and I appreciate the education.

However, note that capillarity is not (in English) the "quality or
state of being capillary" but is simply a noun describing the
phenomenon itself,  so I do not regard the above as proper English
usage and I would recommend against its use in a standards document.

Regards
Marshall

---

From: Yiqun Cai <[email-masked]>
Date: Tue, 17 Jan 2006 20:25:53 -0800

> independently for emission and reception.

Hi Thomas,

The above is a little confusing. Especially with the statement of "a VRF
be associated to multiple VPNs".   Because this can mean multiple
things.  For example,

1.  A VRF can have interfaces connected to CEs belonging to different
VPNs.

2. A VRF can source traffic to receivers in different VPNs, or  
receive traffic
from senders from different VPNs.

I think you meant #2,  but I just want to be sure.  Because I don't  
think #1
is practical deployment.

> activating multicast reception from (or multicast emission to) this  

Agree.

> importing its routes into your VRF (just VRFs of that VPN will import

Agree as well.

> broad scope feature, only to use a subset) would not be good I think.

However,  I don't 100% agree with your conclusion.  The total separation
of control is something good to have.  But to say that a solution "MUST"
support it is a bit strong.  My reasoning behind it is that MVPN  
customers
are usually enterprises.  And most of the enterprises do have a  
congruent
topology for unicast and multicast.

Maybe we should say that a solution SHOULD provide such functionality
if non-congruency exists.

Thanks.

--
Yiqun

---

From: Thomas Morin <[email-masked]>
Date: Wed, 18 Jan 2006 10:48:26 +0100

Well, I'm happy to know that my english is not so bad. Thank you,
Dave. :)

However, to make sure the draft is readable by anyone, I rephrased this
part to a more direct expression : " [some of these applications may
involve rapid changes in customer multicast memberships as seen by the
PE, but this will depend on audience patterns and on] the number of
provider equipments deployed close to VPN customers".

Cheers,

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Wed, 18 Jan 2006 11:27:37 +0100

Hi Yiqun,

Yiqun Cai: 
> > The idea, I think, is to have the ability to have a VRF be 
> > associated to multiple VPNs, independently for multicast and 
> > unicast, and also independently for emission and reception. 
> 
> I think you meant #2,  but I just want to be sure.
[...]

Yes. Definitely #2.

(I'm not sure what #1 would mean, if two interfaces are connected to a
same VRF, then for me, there are in the same VPN, because there is no
segmentation between them)

> support it is a bit strong.  

Accepting that enabling unicast-extranet with a VPN may force
multicast-extranet with that VPN, would be contradictory with other
statements in the draft (that a multicast VPN solution should not impact
unicast service).

Thus, I think its very reasonable to at least state that it is a MUST
that enabling unicast-extranet with a VPN doesn't force
multicast-extranet with that VPN.

> My reasoning behind it is that MVPN  customers are usually enterprises.  
> And most of the enterprises do have a  congruent topology for unicast and 
> multicast.

I'm not sure why we talk about non-congruency : the proposed requirement
would be about activating multicast-extranet with a VPN without having
to both import and export unicast routes of that VPN (even if these
would be congruent).

Also, one thing to keep in mind is that it is a requirement document,
not a solution design document : this means that a MUST in the
requirements impact the solution and its design, not directly
implementations of this solution.  For me this means that a MUST in the
requirement draft could be understood as "the solution designed MUST
provide means so that this is possible", not necessarily as "all
implementations MUST implement this" (this latter degree of requirement
would I think belong to solution drafts).

Maybe we can reformulate as "a multicast VPN solution SHOULD allow ...
and its design MUST NOT preclude this from being possible" ?

In any case, I'll add bullets under the sentence, precising what
"independently" means : 
" - unicast-extranet MUST NOT force multicast-extranet
- it SHOULD be possible to independently enable multicast reception
from, and emission to, a VPN.  "

Cheers,

-Thomas

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 18 Jan 2006 07:49:05 -0500

Hello;

> deployments of multicast protocols on P and PE routers."

Yes.

> I rephrased as: "server clusters monitoring".

OK

> router on the provider's edge, which faces the "CE", the router on the

OK

> Here I fell it hard to use a strict wording, considering how precise the

Already diiscussed.

> monitoring purposes"  will be better I guess.

Fine by me.

> solution, if it supports the RP functionality in VRF/VR".

OK

> services which are to be used only inside the VPN, and of or SSM-range

s/of or SSM-range/of either global SSM-range/

to correct a typo and to make it clear that 232 is intended for global
scope SSM.

> (who doesn't "see" any tunnel).  Isn't this precise enough.

This is OK.

> Hmm. Isn't "leaf" like "knife", "life", or "scarf" ?

You are correct; my error. For some reason I cannot reconstruct, I was
thinking of
the verb. (A tree leafs out, it's branches then have leaves.)

> acceptable that such traffic be propagated toward the CE, inside the

Reasonable, but in normal multicast it is common to get multiple
packets when trees switch over.

> I also added BSR, for completeness.

OK.

Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 18 Jan 2006 07:51:41 -0500

Hello;

> Well, I'm happy to know that my english is not so bad. Thank you,

Your English is pretty impeccable.

Fine by me.

Regards
Marshall

---

From: Thomas Morin <[email-masked]>
Date: Wed, 18 Jan 2006 15:11:31 +0100

Hi Marshall,

Agreed.

> packets when trees switch over.

A bit of misunderstanding here: we are just mandating that, in the same
way that traffic from a VPN doesn't reach another VPN, Internet
multicast traffic won't be routed inside a VPN that didn't make any such
multicast subscription.

In normal multicast, you are not supposed to route @G traffic to
somebody who only subscribed to @G' and @G'', right ?

-Thomas

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 18 Jan 2006 09:32:48 -0500

Hello;

> somebody who only subscribed to @G' and @G'', right ?

Yes, I agree. I was misunderstanding your meaning.

I think it is necessary to see the whole document again with the
various corrections to be sure these are all correct.

Marshall