Subject: Re: draft-mnapierala-mvpn-part-reqt-02

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Thu, 24 Jul 2008 23:46:31 -0400

Yakov,

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Thursday, July 24, 2008 9:13 PM
To: NAPIERALA, MARIA H, ATTLABS
Cc: [email-masked]
Subject: Re: draft-mnapierala-mvpn-part-reqt-02 

Maria,

> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[email-masked]] 
> > Sent: Thursday, July 24, 2008 12:52 PM
> > To: NAPIERALA, MARIA H, ATTLABS
> > Cc: Leonard Giuliano; [email-masked]
> > Subject: Re: draft-mnapierala-mvpn-part-reqt-02 
> > 
> > Maria,
> > 
> > > Lenny,
> > > the requirements in my document are derived from a (large)
production
> > > MVPN deployment and represent the actual needs of layer 3 VPN
customers.
> > > I would hope that addressing them would be considered important by
the
> > > WG.
> > 
> > Your list of requirements seems to be changing fairly rapidly.
> > E.g., just a year ago (July 2007) you listed the following
requirement:
> > 
> >    The amount of customer multicast control messages carried across
SP
> >    network should be minimized. Inter-PE C-multicast traffic should
not 
> >    be sent via shared tree (RPT's) before being switched to shortest

> >    path tree (SPT). 
> > 
> > yet this requirement is no longer listed in
> > draft-mnapierala-mvpn-part-reqt-02. 
> > Why ?
> > 
> > <maria> This is not a text from either -00 or -01 of
> > draft-mnapierala-mvpn-part-reqt.
> 
> The text is from draft-mnapierala-mvpn-rev-02.txt (which you published
> just a year ago). One problem with that document was that it was a
> combination of requirements and solutions. To address this problem
> you essentially extracted *some* of the requirements from that
> document, and put them into draft-mnapierala-mvpn-part-reqt.  So,
> my question to you is why did not you put *all* of the requirements
> that were present in draft-mnapierala-mvpn-rev-02.txt into
> draft-mnapierala-mvpn-part-reqt.
> 
> <maria>  Yes, my solution draft initially contained also the
> requirements it was addressing, since those requirements were not
> covered by any other document. As you know it was suggested to me that
I
> write a requirements document corresponding to the solution I proposed
> (in order to allow other solutions to address those requirements),
which
> I did. I tried to keep the requirements in mnapierala-mvpn-part-reqt
at
> the level high enough that would not presuppose any solutions, while
my
> solution draft contained much more detailed requirements precisely
> because it was a combination of both the requirements and the
solution.
> When I issued the requirements draft, in parallel I cleaned the
solution
> draft from sentences that were requirements. 
> This discussion is about accepting the requirements draft
> draft-mnapierala-mvpn-part-reqt-02 as a WG document, and not my
solution
> draft.

And as part of this discussion I'd like you to explain why some of 
the requirements that you had a year ago are not in
draft-mnapierala-mvpn-rev.

<maria> OK. Specifically, you asked about the following requirement from
the -00 version of solution draft (i.e., the solution draft version
published before the draft-mnapierala-mvpn-part-reqt was issued):

    	"The amount of customer multicast control messages carried
across SP
    	network should be minimized. Inter-PE C-multicast traffic should
not 
    	be sent via shared tree (RPT's) before being switched to
shortest 
    	path tree (SPT)."

This text was replaced by the section which is not a requirement anymore
but rather a solution statement, namely the section 3.1 of
draft-mnapierala-mvpn-rev-04 (which is the solution draft version
published after the requirements draft was issued) states:

	"We observe further that it is not necessary to perform customer
initiated RPT-to-SPT 	switchover across provider's network. The
procedures defined in this document discover 	customer sources by
observing the (C-S, C-G) Join messages from the C-RP. Such C-source
discovery mechanism does not depend on receiving SPT Joins from sites
attached to receivers 	and thus avoids customer-initiated inter-PE
RPT-to-SPT switchover. According to the 	procedure defined in
this document, inter-PE C-multicast traffic is being sent either only
on SPT's or on shared trees, regardless of whether it was or wasn't
switched to SPT's in 	customer domain. This avoids significant shifts
of traffic in provider's network and leads 	to simplification of
PE-to-PE multicast routing. The following PIM messages are eliminated
between PE's: (C-S, C-G, rpt) Prunes and customer initiated (C-S, C-G)
Joins associated 	with C-RPT to C-SPT switchover. The latter
elimination has only one exception associated 	with dually homed
receiver sites where C-RPT and C-SPT diverge (defined in section 5.1.1).

You also quoted the following text from -00 version of the solution
draft:

	"There should be an out-of-band mechanism that would allow
constrained
	distribution of tunnel information, constrained distribution of 
	information about active VPN sources, and constrained
distribution of
	customer multicast control messages."

This was replaced by the actual solution statement in section 4 of
draft-mnapierala-mvpn-rev-04:

	"The following information elements are required in support of
the multicast signaling 	procedures defined in this document:
	- active C-source announcements
	- P-tunnel announcements and withdrawals for (C-*, C-G) traffic
	- P-tunnel announcements and withdrawals for (C-S, C-G) traffic.
	When BGP is used as an auto-discovery mechanism in MVPN, a new
BGP NLRI (MCAST-VPN) is 	already defined in [viii] to handle
different route types in MVPN. For active C-source 	announcements,
Source Active auto-discovery route defined in [viii] can be used. The P-
tunnel announcements and withdrawals for (C-S, C-G) traffic can use
S-PMSI auto-discovery 	route also defined in [viii]. The S-PMSI
auto-discovery route for P-tunnel announcements 	and withdrawals
for (C-*, C-G) traffic is defined is section 5.3 of this document.
	Optionally, there can be an additional route type defined for
active C-group announcements. 	This route type and its purpose are
defined in section 9.2.2 of the document."

Maria

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 25 Jul 2008 04:29:21 -0700

Maria,

> > > > Lenny,
> > > > the requirements in my document are derived from a (large) production
> > > > MVPN deployment and represent the actual needs of layer 3 VPN customers.
> > > > I would hope that addressing them would be considered important by the
> > > > WG.
> > > 
> > > E.g., just a year ago (July 2007) you listed the following requirement:
> > > 
> > >    The amount of customer multicast control messages carried across SP
> > >    network should be minimized. Inter-PE C-multicast traffic should not 
> > covered by any other document. As you know it was suggested to me that I
> > (in order to allow other solutions to address those requirements), which
> > I did. I tried to keep the requirements in mnapierala-mvpn-part-reqt at
> > the level high enough that would not presuppose any solutions, while my
> > because it was a combination of both the requirements and the solution.
> > When I issued the requirements draft, in parallel I cleaned the solution
> > <yakov> This discussion is about accepting the requirements draft
> > draft-mnapierala-mvpn-part-reqt-02 as a WG document, and not my solution
> > draft.
> 
>     	"The amount of customer multicast control messages carried across SP
>     	network should be minimized. Inter-PE C-multicast traffic should not 

That still does not answer my question. Do you think that the following 
is no longer a requirement:

    "The amount of customer multicast control messages carried across SP
    network should be minimized. Inter-PE C-multicast traffic should not 
    be sent via shared tree (RPT's) before being switched to shortest 
    path tree (SPT)."
  
> 	"There should be an out-of-band mechanism that would allow constrained
> 	information about active VPN sources, and constrained distribution of

Again, this does not answer my question. Do you think that the following 
is no longer a requirement:

  "There should be an out-of-band mechanism that would allow constrained
  distribution of tunnel information, constrained distribution of 
  information about active VPN sources, and constrained distribution of
  customer multicast control messages."

Yakov.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Fri, 25 Jul 2008 12:08:11 -0400

Yakov,

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Friday, July 25, 2008 7:29 AM
To: NAPIERALA, MARIA H, ATTLABS
Cc: [email-masked]
Subject: Re: draft-mnapierala-mvpn-part-reqt-02 

Maria,

production
customers.
shortest
which
at
my
solution.
solution
solution
across SP
not 
shortest 

  
constrained
distribution of

<maria>   The draft-mnapierala-mvpn-rev was never intended as a
requirements draft. Some statements in draft-mnapierala-mvpn-rev-00 were
not "requirements" but rather the "properties" of the specific solution
proposed in the document.  When I was asked to issue a separate
requirements draft, I included in it only the "real" requirements (not
covered by RFC483) and not those that were the properties of the
proposed solution. This was done in order not to presuppose any
particular solution (in particular, my solution in
draft-mnapierala-mvpn-rev). There are different ways to achieve for
example scaling or to reduce complexity of a solution meeting a high
level requirement. That is why the statements you listed are not
requirements but were stated in draft-mnapierala-mvpn-rev as good
properties of the proposed solution, and as such could not have been
lifted to the level of main requirements in a requirement document. If
any particular solution has good scaling properties, reduces complexity,
or eases SP's network provisioning and maintenance, then obviously it
will be a better solution.  Such high level requirements related to
scale or OA&M are already included in RFC4834.

Yakov.