Subject: Review of draft-ietf-l3vpn-ppvpn-mcast-reqts-03

From: [email-masked]
Date: Sat, 14 Jan 2006 16:58:24 -0000

Colleagues,

I have started to review draft-ietf-l3vpn-ppvpn-mcast-reqts-03,
unfortunately due to other commitments I have only had time to get as
far as section 5.1.9 (and appendix A as far as the requirements in
section 5.1.9) and I won't have time for several weeks to review the
rest of the document.

Anyway, here are my comments and suggestions so far.  I have formatted
my e-mail as RTF so that I can highlight my proposed changes.  Deletions
are shown as strikethrough and additions are in bold.

General - The document appears to use L3VPN, L3 VPN, PP L3VPN and L3
PPVPN interchangeably.  I would suggest standardising on either one term
(say L3VPN) or two terms if the fact the VPN is provider provisioned
needs to be emphasied (say L3VPN and PPL3VPN).

Section 1:
1st paragraph: "VPN services satisfying the requirement defined in" and
"need not be aware of the VPN"

4th paragraph: "It clarifies the needs from of both VPN clients and
providers standpoints and formulates the problems that should be
addressed by technical solutions with as a the key objective being to
stay remain solution agnostic."

Section 2.1:
2nd paragraph: "Moreover we also propose here generic terms for concepts
that naturally appears when multicast in VPNs is discussed."

3rd paragraph: The definition of ASM isn't very helpful.  Maybe a more
descriptive definition of what ASM actuall is would be helpful.

4th paragraph: "whose core architecture supports"

8th paragraph: "multicast traffic will be conveyed transported across
the SP network.  This is meant in a generic way: such tunnels can be
either point-to-point or point-to-multipoint.  Although this definition
may seems to assume that distribution tunnels are unidirectional, but
the wording also encompasses bi-directional tunnels as well."

11th paragraph: "Refers to any network device that not only participates
to constitutes part of the deployment and the contributes to the
maintenance of the VPN"

Section 3.1:
4th paragraph: "(that is, with a scalable impact"

Section 3.2:
1st paragraph: Suggest changing favor for characteristics.

Section 3.3
1st paragraph: "since the latter is likely to requires maintaining"

Section 4:
2nd paragraph: "Most of the content of these sections"

The text as it stand implies to me that the deployments it talks about
are expected in summer 2005, is that correct, or was it that the survey
was done in summer 2005.  If it's the latter I would suggest rewording
the first sentence as follows: "Most of the content of these sections
originates from a survey done in summer 2005 among institutions and
providers that expect to deploy such solutions, in summer 2005."

3rd paragraph: "expressed in only in a few"

Section 4.1:
1st paragraph, 1st line: "mutlicast" => "multicast" and "can be done
over"

2nd paragraph: "to impact most of the design"

Section 4.1.1:
1st paragraph: "A tTypical applications are"

4th bullet: "can be as high as hundreds"

5th bullet: "bandwidth will depend on the application, but may vary
between a few tens/hundreds of Kb/s"

6th bullet: "QoS requirements include"

8th bullet: "delay sensitivity will depend on the applications"

9th bullet: I don't think you mean "capillarity", I think you mean
"capability"

Section 4.1.2:
Title: "Symetric" => "Symmetric"

2nd paragraph: "Theyir are characterisedtics is by the relatively"

4th paragraph: "it may significantly impact a lot how the
bandwidth/state is managed, because of:"

2nd bullet: "and possibly significantly"

5th paragraph: "indicate that oOptimizing bandwidth for this case may
require"

6th paragraph: "Lastly, some of these applications may involve"

Section 4.1.3:
1st paragraph: "multicast VPNs are non-realtime applications aimeding at
distributing data from a few sources and to many receivers."

Section 4.2:
1st paragraph: "scope to the mere current deployments"

Section 4.2.1:
1st paragraph: "we see an broad range"

Section 4.2.2:
2nd paragraph: "have to scale up to thousands of VPNs per PE."

Section 4.2.3:
2nd paragraph: "A solution SHOULD thus support"

Section 4.2.4:
1st paragraph: "number of PEs per multicast VPNs in"

Section 4.2.4.1:
1st paragraph: "The number of PEs, per VPNs, that would be connected to
sources, seems to be significantly lower than the number of PEs per
VPNs. This is obviously related to the fact that many respondents
mentioned"

Section 4.2.4.2:
1st paragraph: "same order of magnitude than as the number"

Section 4.2.5:
1st paragraph: "A solution SHOULD scale up to thousands of PEs having
multicast service enabled." This reads like a requirement but I can't
find it in the summary of requirements in appendix A.

Section 5:
2nd paragraph: "have taken two different the standpoints of two"

3rd paragraph: "document, we mean by "a solution" or "a multicast VPN
solution", we mean a solution that allows to perform multicast in an L3"

Section 5.1.1:
1st paragraph: "SHALL NOT require customer's devices (CEs) to".  These
edits also need to be made to the copy of the requirement in Appendix A.

Section 5.1.2:
1st paragraph: "Consequently to Section 3.1, the CEs and PEs CE-PE
protocol SHOULD employ existing multicast protocols." These edits also
need to be made to the copy of the requirement in Appendix A.  Also do
you really mean to refer to Section 3.1?

Section 5.1.3:
1st paragraph: "Firstly, the general considerations about regarding QoS
in L3 VPNs as developed described in section"

2nd paragraph: "In some cases, provided the agreed SLA may be different
between unicast and multicast, which will need service differentiation
mechanisms as such in order to monitor both SLAs."

3rd paragraph: "For instance the same traffic"

4th paragraph: "A multicast in VPN solution shall allow to define at
least the same level of quality of service than what as exists for
unicast, and than what as exists for multicast in a non-VPN context."
Also, who shall define the level of QoS, the provider?  In which case I
suggest "A multicast in VPN solution shall allow an ISP to define"

5th paragraph: "the solution should" should the should be in capitals.
Is this paragraph a requirement that also needs to be included in
appendix A?

7th paragraph: "is close to the bandwidth of a PE-CE link"

8th paragraph: "Lastly, a multicast VPN"

Section 5.1.4:
2nd paragraph: "which MAY possibly rely upon similar techniques (than to
those used by the unicast for unicast the same monitoring purposes)."

Section 5.1.5:
2nd bullet: "(when multiple CEs of a in the same VPN"

Section 5.1.6:

3rd paragraph: Suggest rewording/reorganising as follows: "The
monitoring of multicast specific parameters and statistics SHOULD MUST
include :

   o  multicast traffic statistics: total traffic conveyed, incoming,
      outgoing, dropped, etc., by period of time (as a MUST)

The monitoring of multicast specific parameters and statistics MAY
include 
   o  IP Performance Metrics related information (IPPM, [RFC2330]) that
      is relevant to the multicast traffic usage: such information
      includes the one-way packet delay, the inter-packet delay
      variation, etc. (as a MAY)"

4th paragraph: "if their usage exceeds the agreed bounds". These edits
also need to be made to the copy of the requirement in Appendix A.

Section 5.1.7:
5th paragraph: "participating to in a BGP/MPLS"

Section 5.1.8:
1st paragraph: "somehow fits in the context"

2nd paragraph: "It should be considered OPTIONAL given the additional
considerations, such as security, needed to fulfill the requirements for
providing Internet Multicast side, such as security treatment."

Section 5.1.9:
1st paragraph: "and VRs [I-D.ietf-l3vpn-vpn-vr] define the "Carrier's
Carrier" model, where a "carrier's carrier" service provider supports
one or more customer ISPs, or "sub-carriers"."

3rd paragraph: "such as BGP/MPLS VPNs [I-D.ietf-l3vpn-rfc2547bis], this
means that some MPLS label distribution" to align it weith the
requirement in appendix A.

Appendix A:
Security requirements, 1st bullet: "same level of security both for both
unicast"

Extranet requirements, 1st bullet: "MUST support deployments where VRFs
or VRs are"

-- 
Ben Niven-Jenkins
Network Architect, BT Exact
  
E-mail: [email-masked] 
Office: +44 (0)1473 648225
Mobile: +44 (0)7918 077205
   Fax: +44 (0)1332 578827

---

From: Thomas Morin <[email-masked]>
Date: Mon, 16 Jan 2006 21:41:33 +0100

Benjamin,

First, thank you for your careful review and sending all these
comments. 
(I'm implicitly agreeing to and integrating the comments to which I am
not responding below.)

> PPVPN interchangeably.  I would suggest standardising on either one
> term (say L3VPN) or two terms if the fact the VPN is provider
> provisioned needs to be emphasied (say L3VPN and PPL3VPN).

Ok, I did the following:
- replaced the few  "L3 VPN" left, by "L3VPN"
- added an item in terminology definitions: 
  
     L3VPN, VPN:  Throughout this document, "L3VPN" or even just "VPN"
will refer to "Provider-Provisioned Layer 3 Virtual Private Network" (PP
L3VPNs), and will be prefered for readability."

> Section 1:
> 
> 1st paragraph: "VPN services satisfying the requirement defined in" 
> 

In fact, a plural was missing.

> Section 2.1:

[...] 

> 3rd paragraph: The definition of ASM isn’t very helpful.  Maybe a more

Agreed. Here is the updated text:
"Any Source Multicast. One of the two multicast service models, in which
a terminal suscribes to a multicast group to receive data sent to the
group by any source."
Also updated SSM:
"Source Specific Multicast. One of the two multicast service models,
where a terminal subscribes to a multicast group to receive data sent to
the group by a specific source."

> 11th paragraph: "Refers to any network device that not only
> participates to constitutes part of the deployment and the contributes
> to the maintenance of the VPN"

Somebody already contributed the following: "Refers to any network
device that not only participates in the deployment and the maintenance
of the VPN infrastructure, but also in the establishment and the
maintenance of the MD Tunnel" 

> Section 4:

[...]

> are expected in summer 2005, is that correct, or was it that the
> survey was done in summer 2005.  If it's the latter I would suggest
> rewording the first sentence as follows: "Most of the content of these
> sections originates from a survey done in summer 2005 among
> institutions and providers that expect to deploy such solutions, in
> summer 2005."

Ack.

> Section 4.1:

[...]

> 2nd paragraph: "to impact most of the design"

The goal is to talk about things thay have a greater impact on the
design.
Would that be better english: "scenarios that are expected to impact the
most the design of a multicast VPN solution".

> 
> 9th bullet: I don’t think you mean "capillarity", I think you mean
> "capability"

See my answer to Marshall. That was an adventurous export from
french. :)

> Section 4.1.2:
>  
> 
> 4th paragraph: "[...] managed, because of:"
> 
>  
> 

That was supposed to be bullets inside a sentence. I reshaped this as:

"Because of:
- small groups, and low predictability of the location of participants
("sparse groups")
- possibly significantly high bandwidth (a few Mb/s per participant)
...optimizing bandwidth may require introducing dedicated states in the
core network (typically as much as the number of groups)."

> find it in the summary of requirements in appendix A.

True, requirement summary was not updated for -03.

> need to be made to the copy of the requirement in Appendix A.  

Misunderstanding here: we can't reduce to one "CE-PE protocol"; there
can be many, e.g IGMP or PIM; and we don't want either to invent a new
CE-PE protocol that would reuse an exisiting mcast protocol.

> Also do you really mean to refer to Section 3.1?

Well spotted, it doesn't make much sense indeed. I guess it should be
5.1.1.

> Section 5.1.3:
> 
> 1st paragraph: "Firstly, the general considerations about regarding
> QoS in L3 VPNs as developed described in section"

ok with s/as described/expressed/

> 2nd paragraph: "In some cases, provided the agreed SLA may be
> different between unicast and multicast, which will need service
> differentiation mechanisms as such in order to monitor both SLAs."
> 

What about : " In some cases, the agreed SLA may be different between
unicast and multicast, and that will require differentiation mechanisms
in order to monitor both SLAs."

> Is this paragraph a requirement that also needs to be included in

As already suggested, I changed it to a MAY.
Requirement summary will be updated soon.

>       variation, etc. (as a MAY)"

Made it one paragraph, as bullet lists with one item looks weird.
But reshaping the thing was a good suggestion.

Thank you again for your attention to detail !

Cheers,

-Thomas

[email-masked]: 

> Thomas Morin RD-CORE <mailto:[email-masked]> wrote:
> > Hi,
> > 
> > [email-masked]:
> >> I recently sent the e-mail below to the L3VPN mailing list but it
> >> appears that the list server converted it to plain text and therefore
> >> mangled it a bit so I am forwarding it to you as RTF so that you can
> >> see my proposed comments and edits as originally intended.
> > 
> > That's still appearing as plain text in my mailer.
> > Would you mind sending us an attached file, or HTML ?
> 
> OK.  See attached for word & HTML documents with the original e-mail in.
> 
> Ben