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

[Thomas Morin <[e-mail]>]

Hi Marshall,

Marshall Eubanks:
> 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.

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.