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

From: [email-masked]
Date: Tue, 17 Jan 2006 09:35:33 -0000

Thomas,
 
See in-line, my comments are marked [BPN].
 
Ben

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomas Morin
	Sent: Monday, January 16, 2006 8:42 PM
	To: L3VPN
	Subject: RE: Review of draft-ietf-l3vpn-ppvpn-mcast-reqts-03

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

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

	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."
	 
	[BPN] OK, that's fine. 

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

	In fact, a plural was missing.
	 
	[BPN] Then it should be "VPN services satifying the requirements
defined in" 

		Section 2.1:

	[...] 

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

	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."
	
	[BPN] OK, that's fine.

		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" 
	
	 [BPN] I prefer the text already contributed by somebody so go
with that and ignore my proposed edit.

		Section 4:

	[...]

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

	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".
	 
	[BPN] I believe my original proposal is the best English and is
in line with your goal to talk about things that have a large impact on
the design. 

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

		2nd bullet: "and possibly significantly"

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

	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)."
	 [BPN] OK, that's fine.

		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.

	True, requirement summary was not updated for -03.

		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.

	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.
	 
	[BPN] OK.  My concern is that by saying "CEs and PEs SHOULD
employ existing multicast protocols" implies that it is more than the
CE-PE protocol that you are referring to - i.e. that you are implying
that the PE-PE and MDT tunnel establishment protocols SHOULD also use
existing protocols.  How about something like "the CEs and PEs SHOULD
employ existing multicast protocols for communication with each other"?

		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/
	
	[BPN] OK, that's fine.

		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."
	[BPN] OK, that's fine.

		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?

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

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

	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

---

From: Thomas Morin <[email-masked]>
Date: Tue, 17 Jan 2006 10:47:46 +0100

Hi Benjamin,

[email-masked]:

>         [BPN] Then it should be "VPN services satifying the
>         requirements defined in" 

Ok.

>         [BPN] I believe my original proposal is the best English and
>         is in line with your goal to talk about things that have a
>         large impact on the design. 

I'm not sure. 
Maybe "scenarios are expected to have a greater impact on the design of
a solution" ?

>         > 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.  
>         > 
>         
>         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.
>          
>         employ existing multicast protocols" implies that it is more
>         than the CE-PE protocol that you are referring to - i.e. that
>         you are implying that the PE-PE and MDT tunnel establishment
>         protocols SHOULD also use existing protocols.  How about
>         something like "the CEs and PEs SHOULD employ existing
>         multicast protocols for communication with each other"?

I see your point now.
Maybe "[..] multicast-related protocol exchanges between a CE and its
directly connected PE should happen via existing multicast
protocols:"  ?

Thanks,

-Thomas