Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-reqts-03
Marshall Eubanks <marshall.eubanks@gmail.com> Wed, 18 January 2006 12:49 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzCkO-0001Xd-83; Wed, 18 Jan 2006 07:49:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzCkN-0001XT-DF for l3vpn@megatron.ietf.org; Wed, 18 Jan 2006 07:49:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07976 for <l3vpn@ietf.org>; Wed, 18 Jan 2006 07:47:41 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzCsh-00086R-KH for l3vpn@ietf.org; Wed, 18 Jan 2006 07:57:44 -0500
Received: by zproxy.gmail.com with SMTP id 9so1609911nzo for <l3vpn@ietf.org>; Wed, 18 Jan 2006 04:49:05 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WhKnZsE4ApylAxQdUxoVaoBg9J2HjmYVjP83/Vl2aPpBd/+AtFkbrXNewnj4LcVpPqdtnw9mAcgfyAS9+jO3jptKmOBrDKiUO0HuBX5y0zwf9CwuIjIbaqyAZtJmGGksdae2Cw8JecW/FxHPkJkul6okV3lDNG6kzZG+m68MfsE=
Received: by 10.36.224.9 with SMTP id w9mr6625234nzg; Wed, 18 Jan 2006 04:49:05 -0800 (PST)
Received: by 10.36.46.2 with HTTP; Wed, 18 Jan 2006 04:49:05 -0800 (PST)
Message-ID: <dcad22d80601180449l1ee6312naaa5cf47d5aff626@mail.gmail.com>
Date: Wed, 18 Jan 2006 07:49:05 -0500
From: Marshall Eubanks <marshall.eubanks@gmail.com>
To: Thomas Morin <thomas.morin@rd.francetelecom.com>
In-Reply-To: <1137417200.15352.113.camel@wintermute>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43BBE0D5.2060607@juniper.net> <dcad22d80601102236u373871a7qb6f7636e5b7bbfcd@mail.gmail.com> <1137417200.15352.113.camel@wintermute>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 544c2133b952fa264803d857bb70855b
Content-Transfer-Encoding: quoted-printable
Cc: l3vpn@ietf.org
Subject: Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-reqts-03
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l3vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
Sender: l3vpn-bounces@ietf.org
Errors-To: l3vpn-bounces@ietf.org
Hello; On 1/16/06, Thomas Morin <thomas.morin@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
- WG last call: draft-ietf-l3vpn-ppvpn-mcast-reqts-… Ron Bonica
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Yakov Rekhter
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Thomas Morin
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Marshall Eubanks
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Marshall Eubanks
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Yakov Rekhter
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Yakov Rekhter
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Thomas Morin
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Thomas Morin
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Yiqun Cai
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Marshall Eubanks
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Marshall Eubanks
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Yiqun Cai
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Thomas Morin
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… David Meyer
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Marshall Eubanks
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Yiqun Cai
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Thomas Morin
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Thomas Morin
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Marshall Eubanks
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Marshall Eubanks
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Thomas Morin
- Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-re… Marshall Eubanks