Re: WG LAST CALL: draft-ietf-l3vpn-ppvpn-mcast-reqts-05

[Thomas Morin <[e-mail]>]

Hi Tom,

Thank your for reviewing the draft.
A few answers, comments and questions below...


Thomas D. Nadeau: 
> 
> 	0) The formatting of section "2.1.  Terminology"
> 		is inconsistent.

Is it just the missing ":" after "L3VPN, VPN"  (now fixed) or is there
something else that bothers you ?


> 	1) This draft's OAM section should reference
> 		rfc4176.txt and ensure that it is inline
> 		with the framework.

That is indeed relevant. We'll reference section 2 and 3 of rfc4176 in
next revision, in sections 5.1 and 5.2 of the mvpn requirements.



> 	2) You might want to make sure that these
> 		requirements are aligned with those presented
> 		in draft-ietf-mpls-p2mp-oam-reqs-01.txt

Agreed.
We'll reference this draft in section 5.2.12.


> 	3) Section 5.1.2 should explicitly mention that
> 		the ipv6 variants in the MIBs and OAM
> 		tools related to those protocols should
> 		also be supported.
> 		
> 
> 	   When a multicast VPN solution is built on a VPN solution supporting
>     IPv6 unicast, it MUST also support v6 variants of the above
>     protocols, including MLD v.2, and PIM-SM IPv6 specific procedures.
>     For a multicast VPN solution built on a unicast VPN solution
>     supporting only IPv4, it is RECOMMENDED that the design favors the
>     definition of procedures and encodings that will provide an easy

There may be some confusion here: this section is about "CE-PE Multicast
routing and management protocols", but "management" is related to group
management (the 'M' in IGMP) not to OAM. I'll fix section title to say
"group management".

Moreover, I'll add a general requirement in section 3.2 stating all
requirements in the draft are equally applicable to IPv4 and IPv6.


> 	4) Section 5.1.4 states that SLA measurement tools "MAY"
> 		be similar to those present for the unicast
> 		versions of L3VPN.  If this is a requirements
> 		document it should at least use "SHOULD" here.

Agreed.

> 	5) Some ideas of specifics of what to monitor are
> 		referred to in RFC2432 later. There are some
> 		others indicated in draft-ietf-mpls-p2mp-oam-reqs-01.txt
> 

I agree this make sense to refer to the above draft, though it would
belong to section 5.2, on provider-side matter. We'll do this in next
revision.


> 	6) Section 5.1.4 does not state any requirements WRT the impact
> 		of the SLA monitoring. Is it then assumed to be okay
> 		that the monitoring solution utilize %50 of the available
> 		mVPN bandwidth, for instance?  Might be advisable to
> 		be a little more specific here.

Let's keep in mind that the multicast VPNs requirements are not
exhaustive, in the sense that many requirements already are captured as
unicast-related requirements or as multicast requirements in a non-VPN
context, most of which we don't want to restate here.  What you say
above is true already for unicast, right ?


> 	7) Is there any required management interfaces to mcast VPN
> 		(i.e.: the MIB we were working on) or are you going
> 		to be happy with 3 or 4 different CLIs?

Obviously not.... But do we need to say anything more than what is said
in RFC4176 ?  (also, this section only talks about the customer side, so
no MVPN MIB here)


> 	8) In this section, are there any appropriate references
> 		or requirements to be taken from the work in
> 		the IPFIX?

We weren't pointed at a particular IPFIX-related document yet.
Don't hesitate to point us to the documents you'd find relevant.

Anyway, section 5.1.4 could indeed formulate a general requirement like
"having SLA-related metrics SHOULD be available through some
standardized interface like SNMP or IPFIX". What do you think ?


> 	9) 5.1.10 Is the "should" in the first paragraph consistent
> 		with the rest of the document?  There are other
> 		places where should is capitalized where its used
> 		in the same spirit as here.

Agreed.


> 	10) In section 5.1.6 I am not sure what you mean by
> 		"standard management platforms".  Is there such
> 		a thing?  I think you mean "standard management
> 		interfaces" and then you might reference RFC4382
> 		here.

I agree on the fact that this requirement is perhaps defined in a too
fuzzy way. We'll try to improve this by referencing proper document.
(but, in section 5.1, we only examine customer-side related
requirements, VPN-related MIB would not make a lot of sense)


> 	11) This paragraph seems to be way too general to include
> 		anything of substance. Specifically, what are
> 		the requirements here?
> 
> 	   Service management should also include the "FCAPS" functionalities:
>     Fault management, Configuration, Accounting, Performance, and
>     Security.


See below my response to 28).


> 	12) Later in this section you refer to the "state" of the
> 		service. Can you be specific? Is this connectivity
> 		status, the state of some state machine, etc...?

Number of multicast routing states, I'll rephrase.


> 	13) I think in the next sentence (shown below), you
> 		want to say that the OAM functions should still
> 		work, despite any rate limiting the SP might be
> 		doing, although I personally think this is going
> 		to be a tall order:
> 
> 	Indeed, as mentioned in
>     Section 5.2.5, for scalability purposes, a service provider may  
> limit
>     the number (and/or throughput) of multicast streams that are  
> received
>     and produced at a client site, and so a multicast VPN solution  
> SHOULD
>     allow customers to find out their current resource usage (state and
>     throughput), and to receive some kind of feedback if their usage
>     exceeds the agreed bounds.

The sentence above is not really saying that: it says that if regular
traffic/routing is limited, then the customer should be notified
(through some OAM).


> 	14) I find the OAM section to be rather on the thin side, given
> 		that the majority of l3vpn has to do with a service
> 		offering, and guaranteeing that service is working
> 		based on some SLA.  

See below my response to 28).

>                 I suggest improving this section
> 		with more meaty requirements (or cucumbery if you are
> 		a vegetarian).
Yeah, not everybody is a "boeuf bourguignon" addict. :)


> 		Also, WRT to the above, there are things that are left
> 		out that are probably important to the solutions
> 		this WG will work on. For example, is it important that
> 		the OAM tools produced by this WG be the same for all mcast
> 		approaches or can they be different?  There is also no
> 		specific discussion of important issues like configuration
> 		requirements, which in large deployments, might be something
> 		you want to put forth some concrete requirements for.

See below my response to 28).
Such requirements are actually formulated in section 5.2.10 and 5.2.12.
They are there because they relate more to VPN provider matters.



> 	15) Section "5.2.2.  Scalability"  has no discussion of the scale  
> requirements
> 		for the OAM/mgmt tools/solutions.

I agree that it is useful to formulate some requirement about
scalability of OAM, for which multicast issues are specific.
We will add something in 5.2.10.


> 	16) Section "5.2.3.2.  Trade-off and tuning" seems more appropriate
> 		for a BCP document rather than a requirements document.

We found that it was particularly relevant because multicast VPN issues
are specific and justify formulating requirements related to tuning wrt
state/bandwidth-optimality tradeof: a multicast VPN solution designed
without taking into account the need for knobs to tune a multicast VPN
deployment, wouldn't meet the providers requirements.  Saying this in a
BCP once a solution is designed could be too late... aren't requirements
the place where needs are identified ?  Then a BCP document, talking
about a particular L3 MVPN solution, will be able to suggest different
ways to use some particular knobs to adapt to some particular
deployments.


> 	17) Section "5.2.3.3.  Traffic engineering" should refer to
> 		draft-ietf-mpls-p2mp-oam-reqs-01.txt

Its unclear to me why it should. Could you elaborate ?


> 	18) Section 5.2.8 makes the following statement which seems
> 		like it at least should refer to the security section
> 		of RFC4364  ,

1) the requirements not only target 4364 VPNs, but PP L3VPNs in general.
2) I'm not sure it is useful to be exhaustive in referring to all
security sections of different PPL3VPNs solutions

I think the goal is to identify key requirements specific to both
multicast and VPNs.


>                 and at best should give specifics about
> 		what it means. 
>                 I see one example given in the next
> 		sentence, but nothing else.
> 
> 	   "The solution shall provide the same level of security for
> 	   the service provider as what currently exist for unicast VPNs."

Well this first sentence essentially introduce the section, with a
general comment on general expectations. The rest of the paragraph gives
explicit examples of particular things which would require particular
care.


> 	19) What do you mean by "interested receiver" in the following
> 		sentence?  If I am trying to hack the mVPN I might be
> 		"interested", but not be authorized! *)
> 
> 	   "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."

The text above is supposed to refer to traffic that wasn't requested to
the PE by the CE (through multicast routing or group management
protocols).  Whether or not the receiver is "authorized" by the sender
is out of scope here: multicast (VPN or not) doesn't provide anything to
control this.

I'll reformulate to avoid the confusion: "Traffic of a multicast channel
for which there are no members in a given multicast VPN MUST NOT be
propagated within this multicast VPN, most particularly if this traffic
comes from another VPN or from the Internet."


> 	20) The last sentence in section 5.2.9 has only a period. I think
> 		you should carry over the last word in the sentence
> 		to the next line.
Fixed...


> 	21) I find the statement "light as possible" in section 5.2.10
> 		a bit too open-ended for my liking.  Too often recently,
> 		marketing has used this term to mean a number of things;
> 		lets please be specific.  The next sentence that
> 		states:
> 
> 		Particularly the operational cost of setting up
> 		   multicast on a PE SHOULD be as low as possible.
> 
> 		seems to only cover part of what "light as possible"
> 		means to me.

The section also illustrate the opening sentence with requirements about
"providing automatic configuration and discovery" and "carefully
consider the number of protocols within the core network". 

Feel free to propose other points that you'd find would improve the
lightness of the solution.


> 	22) The next sentence seems to be an interesting guiding principle
> 		for the L3VPN WG, but doesn't really contain any
> 		requirements:
> 
> 	   Also, as far as possible, the design of a solution should carefully
>     consider the number of protocols within the core network: if any
>     additional protocols are introduced compared with the unicast VPN
>     service, the balance between their advantage and operational burden
>     should be examined thoroughly.

This indeed is a guideline to remind that this is an important point for
providers, maybe we can reword this into a "SHOULD"  ?


> 	23) Should you mention IPFX (netflow) type requirements here?
> 		you mention IPPM.

IPPM is the definition of metrics, isn't IPFX more like a media for
them ?  We can consider adding IPFIX along with SNMP as a possible mean
to access monitoring/performance related infos. 


> 	24) In the following sentence, "total traffic conveyed" seems to
> 		be the same as "outgoing" to me, so I would drop the
> 		former.
> 	"Multicast traffic statistics (total traffic conveyed, incoming,
>        outgoing, dropped, etc., by period of time) - Information about
>        client multicast resource usage (state and throughput)"
conveyed would be incoming+outgoing

> 		
> 	In fact, to simplify, just say: sent, received, dropped.
> 	Also, do you care about any packets that were a) delivered out of
> 	order, or b) how they were dropped (i.e.: out of queue space, vs.
> 	queued-out by other preferred traffic)?

Its not that I don't myself care, but section 5.2 is more about about
tools that can be deployed on the provider-side, and I'm not sure what
you suggest would make sense on a PE (even less on a P) router.


> 	25) The following seem like two different requirements:
> 
> 	Alarms when limits are reached on such resources - Statistics on
>        decisions related to how client traffic is carried on  
> distribution
>        tunnels (e.g. "traffic switched onto a multicast tree  
> dedicated to
>        such groups or channels")

That was a typo. Thanks for spotting it.



> 	26) This sentence should refer to RFC4382, and perhaps
> 		RFC3811/12/13/14:
> 
> 	   All or part of this information SHOULD be made available through
> 	   standardized SNMP ([RFC1441], [RFC3411]) MIBs (Management  
> Information
> 	   Bases).

Are you suggesting we should require modifications RFC4382 and
RFC3811/12/13/14 to integrate MVPN aspects ?
I would tend to believe that a multicast VPN solution would require
dedicated MIB definitions. Not withstanding


> 	27) The following sentence from section 5.2.11 seems to be
> 		like a guideline more relevant in a BCP than in
> 		a requirements document:
> 
>     Likewise, the introduction of IP multicast VPN capabilities in
>     devices that participate in the deployment and the maintenance of a
>     multicast VPN SHOULD be as smooth as possible, i.e. without  
> affecting
>     the overall quality provided with the services that are already
>     supported by the underlying infrastructure.

Agreed. We'll reformulate to insist on the requirement aspect:
"Likewise, a multicast VPN solution SHOULD be designed so that its
activation in devices that participate in the deployment and the
maintenance of a multicast VPN be as smooth as possible, i.e. without
affecting the overall quality provided with the services that are
already supported by the underlying infrastructure."


> 	28) To me at least, the sprinkling of mgmt/oam sections
> 		around the document rather than a single one
> 		leads to a bit of confusion. For example, in
> 		section 5.2.5, there is a 'troubleshooting'
> 		subsection after some discussion of management.  This
> 		follows the discussion of other management requirements
> 		that are present at the top of the document. I suggest
> 		combining all of these together, which will avoid
> 		some of the redundancy that I can see, and also make
> 		it a bit easier/straight-forward to read.

I agree that the document would gain consistency by merging 5.2.10 "OAM"
and 5.2.12 "Troubleshooting". Sections 5.1.4 "SLA parameters
measurement" and 5.1.6 "Monitoring and Troubleshooting" could also maybe
be merged.  I'll discuss this with other contributors, but that would
help address many of your first comments I think ( 1) 4) 6) 7) 8) 10)
11) 14) ).

On the other hand I think it make sense to separate things that relate
to the provider scope, and things that relate to the customer scope, as
done e.g in RFC4176.  So it make sense I think to keep 5.1.x and 5.2.x
separated including for OAM issues.


> 	29)  The last word of this sentence should be plural:
> 
> 6.  Security Considerations
> 
>     This document does not by itself raise any particular security  
> issue.

Agreed...


> 	30) I would say that "a set of security issues have been identified
> 		with regard to multicast layer-3 vpn..."
> 
>     A set of security issues have been identified that MUST be addressed
>     when considering the design and deployment of multicast-enabled VPN
>     networks.  Such issues have been described in Section 5.1.5 and
>     Section 5.2.8.

Do you want to drop the "MUST" or just the text to be more specifically
worded and target L3VPN and not all VPNs ? 
(the latter I'm going to fix anyways)

Cheers,

-Thomas