Review: draft-ietf-l3vpn-ppvpn-mcast-reqts

[benjamin.niven-jenkins at bt.com]

Thomas,
Cc Colleagues,

I've finally found time to read the second half of
draft-ietf-l3vpn-ppvpn-mcast-reqts and have the following
comments/corrections.  These are based on the -04 version of the draft.

Ben


Section 5.1.7, 4th paragraph states:
"Moreover, a solution MUST allow to control an extranet multicast
connectivity independently from the extranet unicast connectivity."

MUST allow who? to control this.

Suggest "Moreover, a solution MUST allow service providers to control an
extranet's multicast connectivity independently from the extranet's
unicast connectivity."

Section 5.2.1 - remove extraneous 'possibly' so "impact on possibly
existing deployments" becomes "impact on existing deployments".

Section 5.2.2 8th bullet, change "required on PE and P to add or remove
a customer site" to "required on PE and P routers to add or remove a
customer site".

Section 5.2.2 last paragraph: "but a multicast in VPNs solution" should
this be "but a multicast VPN solution"?

Section 5.2.3.1 2nd paragraph: change "(when same data travels twice or
more on a same link, e.g. when doing ingress PE replication)" to "(when
the same data travels twice or more on the same link, e.g. when doing
ingress PE replication)".

Section 5.2.3.3 2nd paragraph: change "Thus a multicast VPN solution
SHOULD offer the service providers appropriate" to "Thus a multicast VPN
solution SHOULD offer service providers appropriate".  Also on the 4th
line of this paragraph I don't think you mean 'peculiar' but rather you
mean 'particular'?

Section 5.2.3.3 3rd paragraph: change "a NP-hard" to "an NP-hard"

Section 5.2.4.1 2nd paragraph states "In a multicast VPN solution
extending a unicast L3 PPVPN solution, consistency in the tunneling
technology has to be privileged" I don't understand what this means
especially your use of the word privileged in this context.

Section 5.2.4.1 4th paragraph states "and may help improve bandwidth
efficiency in our multicast VPN context." I don't know what you mean by
"our multicast VPN context", do you really mean "a multicast VPN
context"?

Section 5.2.4.2 1st paragraph: change "e.g., to discover MTU, to tell
MTU with signaling," to "e.g., to discover MTU, to communicate MTU via
signaling,".

Section 5.2.4.2 2nd bullet: change "if packets too big for" to "if
packets that are too big for".

Section 5.2.6 last paragraph: change "penalty" to "penalties"?

Section 5.2.8 5th paragraph: change "In a such perspective," to "In such
cases,"

Section 5.2.8 6th paragraph: change "Last" to "Lastly".

Section 5.2.10 2nd paragraph: change "VPN" to "VPNs" and change
"operation" to "operational".

Section 5.2.11 2nd paragraph: change "participate to the deployment" to
"participate in the deployment".

Section 5.2.11 4th paragraph: change "Ideally a solution would have be
the ability to offer multicast VPN services across a network containing
some legacy routers not supporting any multicast VPN specific features."
to "Ideally a solution would have the ability to offer multicast VPN
services across a network containing some legacy routers that do not
support any multicast VPN specific features."

Section 5.2.11 5th paragraph: replace "from possibly" with "for".

Section 5.2.12 2nd paragraph: change "a solution MAY usefully provide
some mechanism letting network operators check that all VPN sites" to "a
solution MAY usefully provide some mechanism to allow network operators
to check that all VPN sites" and change "Providing the operators with
means" to "Providing operators with means".

-- 
Ben Niven-Jenkins
Network Architect, BT Exact
  
E-mail: benjamin.niven-jenkins at bt.com 
Office: +44 (0)1473 648225
Mobile: +44 (0)7918 077205
   Fax: +44 (0)1332 578827