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

[Marshall Eubanks <marshall.eubanks at gmail.com>]

Hello;

On 1/16/06, Thomas Morin <thomas.morin at rd.francetelecom.com> wrote:
> 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 ?

Yes.

>
> >    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".
>

OK

>
> > 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. "
>

OK

>
> > 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.
>

Already diiscussed.

>
> >    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.
>

Fine by me.

>
> > 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 ?
>

OK

> >    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

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.

> 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.
>

This is OK.


> [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" ?

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.)

>
>
> >    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 ?

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

>
>
> >    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.
>
>

OK.

>
>
>
>

Marshall