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

From: Ron Bonica <[email-masked]>
Date: Mon, 06 Mar 2006 10:22:58 -0500

Folks,

This email begins a WG last call for
draft-ietf-l3vpn-ppvpn-mcast-reqts-05. Last call will end on March 20, 2006.

                                Ron

---

From: Thomas Morin <[email-masked]>
Date: Mon, 06 Mar 2006 16:29:04 +0100

Hello,

> draft-ietf-l3vpn-ppvpn-mcast-reqts-05. Last call will end on March 20, 2006.

FYI, The revision integrates all the comments made during last call,
with many editorial changes and the following more significant changes:
- CE-PE Multicast routing and management protocols: clarified IPv6
related statements  
- More precisions in 5.1.7. "Extranet"  
- Revamped section 5.1.11 "RP Engineering" : separated text about
different issues "RP Outsourcing", "RP Availability", "RP  Location".
Updated 5.1.10 accordingly.  
- Updated 5.2.10 about proactive monitoring of tunnels  
- Removed requirements summary 

Detailed diff:
http://tools.ietf.org/wg/l3vpn/draft-ietf-l3vpn-ppvpn-mcast-reqts/draft-ietf-l3vpn-ppvpn-mcast-reqts-05-from-04.diff.html

Regards,

-Thomas

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 6 Mar 2006 13:09:45 -0500

> draft-ietf-l3vpn-ppvpn-mcast-reqts-05. Last call will end on March  

	Here are my comments:

	0) The formatting of section "2.1.  Terminology"
		is inconsistent.

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

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

	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

	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.

	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

	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.

	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?

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

	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.

	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.

	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.

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

	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.

	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.  I suggest improving this section
		with more meaty requirements (or cucumbery if you are
		a vegetarian).

		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.

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

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

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

	18) Section 5.2.8 makes the following statement which seems
		like it at least should refer to the security section
		of RFC4364  , 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.

	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.

	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.

	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.

	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.

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

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

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

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

	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.

	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.

	29)  The last word of this sentence should be plural:

6.  Security Considerations

    This document does not by itself raise any particular security  
issue.

	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.

---

From: Thomas Morin <[email-masked]>
Date: Fri, 10 Mar 2006 16:04:16 +0100

Hi Tom,

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

> 	0) The formatting of section "2.1.  Terminology"

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

> 		rfc4176.txt and ensure that it is inline

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.

> 		in draft-ietf-mpls-p2mp-oam-reqs-01.txt

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

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

> 		document it should at least use "SHOULD" here.

Agreed.

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

> 		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 ?

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

> 		or requirements to be taken from the work in

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 ?

> 		in the same spirit as here.

Agreed.

> 		interfaces" and then you might reference RFC4382

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)

>     Fault management, Configuration, Accounting, Performance, and

See below my response to 28).

> 		status, the state of some state machine, etc...?

Number of multicast routing states, I'll rephrase.

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

> 		based on some SLA.  

See below my response to 28).

>                 I suggest improving this section
Yeah, not everybody is a "boeuf bourguignon" addict. :)

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

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

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

> 		draft-ietf-mpls-p2mp-oam-reqs-01.txt

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

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

> 	   "Unwanted multicast traffic (e.g. multicast traffic that may be sent
>     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."

> 		you should carry over the last word in the sentence
Fixed...

> 		seems to only cover part of what "light as possible"

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.

>     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?

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. 

> 	"Multicast traffic statistics (total traffic conveyed, incoming,
>        client multicast resource usage (state and throughput)"
conveyed would be incoming+outgoing

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

>        such groups or channels")

That was a typo. Thanks for spotting it.

> 	   standardized SNMP ([RFC1441], [RFC3411]) MIBs (Management  

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

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

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

>     This document does not by itself raise any particular security  

Agreed...

>     networks.  Such issues have been described in Section 5.1.5 and

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 10 Mar 2006 13:03:52 -0500

> something else that bothers you ?

	The indentation isn't consistent.

> above is true already for unicast, right ?

	Yes, but I think its worth mentioning here that they are the
same explicitly. Since mcast poses all sorts of new and interesting
scaling challenges, we need to make sure folks have thought through
them in detail. If the conclusion from operators that scale on the order
of unicast is in order, then I am cool with that.

> in RFC4176 ?  (also, this section only talks about the customer  

	Again, its along the same lines of my response to #6; its
probably worth either explaining that the requirements are the same
(or referring to RFC4176) just so there is no confusion.  I find that
having even the most obvious stuff written down (even if sometimes
duplicated) is helpful especially for folks new to the area.

> Don't hesitate to point us to the documents you'd find relevant.

	The IPFIX solution itself as defined in the IPFIX WG
is worth referencing. I think they also have a requirements
draft there too.

> standardized interface like SNMP or IPFIX". What do you think ?

	Yes, agreed.

> requirements, VPN-related MIB would not make a lot of sense)

	Depends if you are running MPLS all the way to the CE.
Also, there might be a hidden requirement for MIB access on
the CE device for managed CEs?

> traffic/routing is limited, then the customer should be notified

	Ahh, ok. Can you please rephrase the sentence then?
I read this for the first time, and that was the impression I
got from reading it.

> Yeah, not everybody is a "boeuf bourguignon" addict. :)

	Exactement! *)

> ways to use some particular knobs to adapt to some particular

	I am not saying that such a statement is not useful. As you say,
its a way of guiding how people will deploy the solution, which is
quite useful. I just don't think it belongs in a requirements draft.
BTW, this was the sort of feedback I received during the recent
IESG review of rfc4377.  I am not speaking for the IESG, nor can I
guarantee they will disagree with the above statement, but that was
the type of comments I received.

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

	In retrospect, I take back the request. You are
right, it doesn't apply here.

> I think the goal is to identify key requirements specific to both

	Yes, precisely. I think we should refer to the ones that
apply.  One thing that would be useful would be to state that
this document as you say, doesn't exhaustively re-define all
requirements, but instead tries to build upon or refine
existing ones whenever possible, and in essence, only discusses
the differences between the two.  Although as I stated above, it
is sometimes useful to overlap.  In this case, I think the security
requirements is important enough to stipulate what you guys
think WRT RFC4364's security.

> comes from another VPN or from the Internet."

	Cool.

> lightness of the solution.

	What I am requesting is that you be more specific about
what "light" means, or at least how something could be considered
"light" versus "heavy". More often that not, we assume that people
in the WG will know this distinction, but in practice, it seems
to only invite confusion. If you can't or don't want to be
more specific, I suggest simply removing the "light as possible"
portion of that sentence.  Similarly, the second sentence describes
a required about the cost of setting up the mcast feature should
be as "low as possible".  Again, there is a lot of ambiguity in
that sentence, and so please either be more explicit or strike
it.

	Actually after re-reading the first sentence, I am further
confused.  What do you mean by "should be prioritized"?  This could
mean a number of things. Do you mean during operation of the LSR?
During development of the OAM tools?

> providers, maybe we can reword this into a "SHOULD"  ?

	I am not sure if the addition of a should is going to
help. This sentence seems to belong more in the WG's charter
statement than anything.  It seems obvious that we should
make things as simple as possible, and no simpler. Conversely,
we should make things as complicated as required to solve
the problem, but no more complex.

> to access monitoring/performance related infos.

	Agreed with the last suggestions (SNMP/IPFIX).  I
wanted to know if you were interested in using IPFIX for
SLA measurements, as that was not clear.

> conveyed would be incoming+outgoing

	Can you add that explicitly?  Again, after an initial
read or two, its not obvious (or I am just too thick).

> you suggest would make sense on a PE (even less on a P) router.

	If not, that it might be worth stating as a non-requirement.

> RFC3811/12/13/14 to integrate MVPN aspects ?

	Yes.

> dedicated MIB definitions. Not withstanding
	
	Yes.

> already supported by the underlying infrastructure."

	K

> help address many of your first comments I think ( 1) 4) 6) 7) 8) 10)

	Yes, I think so given that this document is a L3 VPN document
so it wouldn't for example, cover the L2 mcast VPN work.  At least
as far as I can tell.

	--Tom