Subject: RE: Advancing the Protocol and Morin Drafts

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Fri, 10 Oct 2008 10:41:43 -0400

When there is substantial deployment in the field with the existing
approach, making a newer proposal a must and the exiting one an optional
is business/operation/customer impacting. Many folks spoke out here are
running live networks, this is not a theoretical debate. I don't see we
can get consensus here. 

Could we still proceed with the two protocol drafts, like we did for
L2VPN - both LDP signaling and BGP signaling became standards? I think
that would be useful comparing with no standards for MVPN at all. 

Thanks,
Luyuan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of Marshall Eubanks
> Sent: Wednesday, October 01, 2008 10:04 AM
> To: [email-masked]
> Cc: Ross Callon
> Subject: Advancing the Protocol and Morin Drafts
> 
> This email starts a 3 week call for input, to expire October 23, 2008,

> for the following steps:
> 
> 1.) To accept draft-morin-l3vpn-mvpn-considerations-03 as a working 
> group document;  and
> 
> 2.) To turn this document into a requirements draft, with mandatory to

> implement features for an interoperable implementation. The authors 
> have indicated that they are willing to do this.
> 
> Our intention is, if this approach is accepted, to then begin WG last 
> call to submit to the IESG for publication:
> 
> draft-ietf-l3vpn-2547bis-mcast
> draft-ietf-l3vpn-2547bis-mcast-bgp
> 
> We expect that these two documents will be submitted more or less as 
> is (i.e., certainly with any new bug fixes or other necessary 
> corrections and improvements, but without specific mandatory to 
> implement feature description in those drafts).
> 
> Please respond to the list with your recommendations for these two 
> courses of action.
> 
> Regards
> Marshall & Danny

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 10 Oct 2008 17:24:23 +0100

Luyuan,

I think you may be presupposing the final output.  If draft-morin is
accepted as a WG draft it comes under WG change control.  It is not asking
to send draft-morin to IESG as-is but whether to use draft-morin as the
initial basis for a document to describe a set of mandatory mechanisms for
mVPN.

There are more components to mVPN than just BGP Vs PIM for C-multicast
routing (although that would appear to be the most contentious).  The
current solution specifications make no stance on any of them.  It may be
that if consensus truly cannot be reached on a specific area of the mVPN
solution then we may need to leave that specific area open (ala L2VPN
signalling) but sending the specifications drafts as they stand today to
IESG and then calling it a day and leaving the whole solution space open is
IMO (as an operator) not an acceptable way forward.

Personally, I believe some of the AT&T comments to be somewhat irrelevant to
this specific poll because although they are extremely valid comments in
their own right they are not specific to draft-morin but to the whole mVPN
solution space (i.e. the current mVPN WG solution drafts also do not address
them) and then the question to my mind becomes do we want to progress the
current solutions drafts in the best way now and address the additional
items later or hold up progression of the whole mVPN solution space while we
address the additional items.  I am not in favour of the latter and that is
not the question currently being asked by the WG chairs AFAICT.

Ben

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Fri, 10 Oct 2008 13:48:22 -0400

Ben,

Thanks for the clarification, a lot of helpful thought. But I do think
all comments, including AT&T folks', are relevant. The Morin draft
cannot be separated from the whole mVPN solution issues/debate as it
is...

One suggestion, would it work if the authors of the Morin draft, and
Maria, and other interested SP folks get together to re-cook a new
draft, which include a large commonly agreed portion from the Morin
draft, as well as the requirements/considerations from Maria's draft,
then asking for becoming WG doc? Not sure if this is even possible or
necessary, just a thought, we stuck now anyway. 

As for one protocol vs. two, one of the key points is timing. CR-LDP
could be killed 8 years ago in the debate against RSVP-TE, because there
was no deployment. Cannot do that when there are large production
networks out there. 

Thanks,
Luyuan

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: 10 October 2008 12:24
To: Luyuan Fang (lufang); [email-masked]
Subject: Re: Advancing the Protocol and Morin Drafts

Luyuan,

I think you may be presupposing the final output.  If draft-morin is
accepted as a WG draft it comes under WG change control.  It is not
asking to send draft-morin to IESG as-is but whether to use draft-morin
as the initial basis for a document to describe a set of mandatory
mechanisms for mVPN.

There are more components to mVPN than just BGP Vs PIM for C-multicast
routing (although that would appear to be the most contentious).  The
current solution specifications make no stance on any of them.  It may
be that if consensus truly cannot be reached on a specific area of the
mVPN solution then we may need to leave that specific area open (ala
L2VPN
signalling) but sending the specifications drafts as they stand today to
IESG and then calling it a day and leaving the whole solution space open
is IMO (as an operator) not an acceptable way forward.

Personally, I believe some of the AT&T comments to be somewhat
irrelevant to this specific poll because although they are extremely
valid comments in their own right they are not specific to draft-morin
but to the whole mVPN solution space (i.e. the current mVPN WG solution
drafts also do not address
them) and then the question to my mind becomes do we want to progress
the current solutions drafts in the best way now and address the
additional items later or hold up progression of the whole mVPN solution
space while we address the additional items.  I am not in favour of the
latter and that is not the question currently being asked by the WG
chairs AFAICT.

Ben 

On 10/10/2008 15:41, "Luyuan Fang (lufang)" <[email-masked]> wrote:

> approach, making a newer proposal a must and the exiting one an 
> optional is business/operation/customer impacting. Many folks spoke 
> out here are running live networks, this is not a theoretical debate. 
> I don't see we can get consensus here.
>

---

From: "Ross Callon" <[email-masked]>
Date: Fri, 10 Oct 2008 14:39:13 -0400

> As for one protocol vs. two, one of the key points is timing.
> CR-LDP could be killed 8 years ago in the debate against 
> RSVP-TE, because there was no deployment. Cannot do that when
> there are large production networks out there. 
>
> Thanks,
> Luyuan

Speaking as the AD overseeing this working group (but understanding that
there are limits to what an AD can or should do), I think that it might
be useful to think about the context of where L3VPN and our current
range of options came from.

L3VPN of course was created when PPVPN working group was split into two
(the layer 2 part, and the layer 3 part). PPVPN was itself started quite
a few years ago. At the time there was considerable friction between the
people who wanted CE-based VPNs (using IPsec), people who wanted virtual
router based solutions (and there were at least two and possibly more
quite different virtual router based proposals), and people who wanted
BGP/MPLS based solutions. After a fair amount of argument, much of which
preceded the chartering of the PPVPN working group, it was agreed to
work on all three approaches. 

As such there have always been multiple layer 3 approaches that could be
used to support virtual private networks (not even mentioning the layer
2 approaches). To me it looks as if we are well past the point where we
expect that we will end up with only one single solution. 

On the other hand, we are working on standards for a reason: There is a
huge advantage to the industry as a whole, and to any users of
networking technology, if it is possible to build networks out of
equipment from many different manufacturers. Also, the technology used
is likely to be significantly better or at least more broadly applicable
if it has been reviewed by many people from multiple different
backgrounds and multiple different points of view. 

Thus, if we end up with 20 different solutions, or five solutions each
of which has four or five fundamentally different major subsets, and if
no two vendors implement overlapping subsets of these 20 different
solutions, then we have failed as a standards setting organization. 

If we end up with two or three options, and if each of the two or three
options has a single subset which is clearly defined and is implemented
by a wide range of vendors, then we have been relatively successful (and
probably as successful as we can hope to be in this particular space). 

Thus, the question of whether to accept as a working group document a
document that will define one proposed profile (or a small number of
profiles) for a hopefully interoperable solution, seems to me to be
orthogonal to the question of whether to accept a new set of
requirements which are likely to lead to a different solution (which
might in the future lead to an additional profile). 

Ross

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Fri, 10 Oct 2008 19:22:04 -0400

Ross,
regarding
>[..] whether to accept a new set of
>might in the future lead to an additional profile)

if the MVPN solution does not lay out the correct foundation to support
basic multicast capabilities in VPN context like PIM-Bidir, Anycast-RP,
or anycast sourcing then those capabilities cannot be just added on
after the fact. They have to be an integral part of the solution.
Otherwise we will have to revisit the MVPN for the third time and such
opportunity will not come any time soon, if ever. This will ultimately
decide about the success (or lack of it) of this technology. 
And an IETF recommendations or requirements draft should not ignore such
capabilities.

Maria

---

From: Thomas Morin <[email-masked]>
Date: Mon, 13 Oct 2008 10:14:40 +0200

Hi Luyuan,

Luyuan Fang :
> is business/operation/customer impacting. 

The statement above doesn't match the reality of the documents being
discussed: draft-ietf-l3vpn-2547bis-mcast does *NOT* include the
existing draft-rosen deployments ; *whatever* option is chosen inside
draft-ietf-l3vpn-2547bis-mcast -- including the one closest to
draft-rosen -- any draft-rosen deployment will have to go through a
migration phase to become in line with the current IET specs.

> Many folks spoke out here are running live networks, this is not a 
> theoretical debate. 

Believe me, the many operators co-authoring
draft-morin-l3vpn-mvpn-considerations are not taking this issue by the
theoretical side...

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Mon, 13 Oct 2008 10:25:20 +0200

Hi Maria,

NAPIERALA, MARIA H, ATTLABS :
> after the fact. 

*If* you believe that the solutions specified do not include what you
need or have limitations limiting their applicability, then you should
make statements about what need to be changed in these drafts, now, or
during their last call.

This is _unrelated_ to choosing, inside the solution draft, a set of
options mandatory to implement.

(Now, the solution drafts -- independently of the approach used for the
different building blocks --  do completely support PIM-Bidir,
Anycast-RP, and anycast sourcing)

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Mon, 13 Oct 2008 17:57:37 +0200

Hi Luyuan,

> necessary, just a thought, we stuck now anyway. 

Well, as previously explained, Maria's draft contains requirements that
would call for an evolution of solutions, while our draft describe a set
of mandatory procedures for multicast VPN.  These are orthogonal
directions and "merging" would not make much sense.  Both can happen
independently. 

But, in fact, most requirements (if not all) in
draft-mnapierala-mvpn-part-reqt are already covered in the existing
solution drafts, independently of the approach chosen. Thus,
draft-mnapierala-mvpn-part-reqt is not very helpful today to help define
a standard among the different approaches proposed and help solve the
current deadlock, which is the goal of our draft.

> was no deployment. Cannot do that when there are large production

Again, let me reiterate that current draft-rosen deployments will have,
whatever alternative set of options is chosen, to go through some form
of migration to deploy the current solution. This is well identified by
operators co-authoring draft-morin-l3vpn-mvpn-considerations, which also
have multicast vpn deployments.

Besides, as stated by Ben, we are not in a situation with only two
things to choose between. Just looking at inter-AS and S-PMSI trigger
signaling, you end up with 4 different combinations. 

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Mon, 13 Oct 2008 18:21:23 +0200

Hi again Maria,

> after the fact. They have to be an integral part of the solution.

Let's try to be pragmatic...

Anycast schemes

        Anycast-RP is a requirement formulated in RFC4834 ("SHOULD work
        transparently through a multicast VPN"). Is is true that the
        type of anycast sourcing that you described is not specifically
        covered.
        
        Let's go to the most important point for an operator: both are
        fully supported by draft-ietf-2547bis-mcast. A specific UMH
        selection algorithm that is common to BGP-based and PIM-based
        C-multicast routing, is defined as a "SHOULD" in section 5.1.3.

        If there were to be, at some point in the future, multiple
        proposals to support anycast schemes (pure hypothesis), we could
        certainly cover this in draft-morin-l3vpn-mvpn-considerations,
        and try to define which one to privilege.
        
        (If you think that solution drafts are lacking in some way to
        properly support anycast schemes, or do not have the proper
        SHOULD/MUST/MAY level, then I think that you should make
        comments  to amend draft-ietf-2547bis-mcast )

Bidir-PIM

        Customer Bidir-PIM is already defined as a SHOULD in RFC4834. It
        is already supported by draft-ietf-2547bis-mcast, by both the
        PIM-based and BGP-based C-multicast routing approaches.  There
        happen to be two approaches defined to support Bidir-PIM
        ("outsourced RPL" in section 11.1, and "partitioned sets of PEs"
        section 11.2).
        
        I note that no contribution what yet proposed by the working
        group to implement in priority one of these approach, and since
        you are interested in the subject, we will certainly welcome a
        contribution on the matter from you.  This is totally 100% in
        the scope of the document evolution that can be expected from
        the document once adopted (obviously we would have welcome a
        contribution before too).
        
Does this address your comments ?

-Thomas