Subject: What should we do next?

From: Ron Bonica <[email-masked]>
Date: Mon, 21 Jul 2008 16:04:14 -0400

Folks,

The purpose of this message is to summarize WG status and begin a 
discussion of ways to proceed. The following comments are offered as an 
individual contributor.

For the last several years, the working group has been ruminating over 
multicast VPN architectures. So far the WG produced the following documents:

- draft-ietf-l3vpn-2547bis-mcast
- draft-ietf-l3vpn-2547bis-mcast-bgp

These documents offer a plethora of possible MVPN options, without 
specifying which MUST be implemented, which SHOULD be implemented, and 
which are MAY be implemented.

Thomas Morin attempted to fill the void by introducing 
draft-morin-l3vpn-mvpn-considerations. This document specifies *single* 
subset of options that all vendors MUST implement. It also specifies a 
subset that vendors SHOULD and MAY implement. Although this document was 
generally well received by the working group, it was not adopted as a 
working group item because approval was not unanimous.

Later, Eric Rosen introduced draft-rosen-l3vpn-mvpn-profiles. This draft 
specified a set of MVPN profiles drawn from the two documents mentioned 
above. Other, possibly non-interoperable profiles also may be developed. 
draft-rosen-l3vpn-mvpn-profiles was never proposed as a working group item.

In the interest of making progress I would suggest that it is time for 
the WG to decide whether to accept draft-morin-l3vpn-mvpn-considerations 
as the WG document, or to follow the profile approach, as outlined in 
draft-rosen-l3vpn-mvpn-profiles (with the end result of multiple 
possibly non-interoperable profiles).

With this in mind I would like to ask the WG chairs for a consensus call 
on either (a) accepting  draft-morin-l3vpn-mvpn-considerations as the 
WG, or (b) following the profile approach, as outlined in 
draft-rosen-l3vpn-mvpn-profiles

                                        Ron

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 21 Jul 2008 14:20:05 -0700

>-----Original Message-----
>From: Ron Bonica [mailto:[email-masked]] 
>Sent: Monday, July 21, 2008 1:04 PM
>To: [email-masked]
>Subject: What should we do next?
>
>Folks,
>
>The purpose of this message is to summarize WG status and 
>begin a discussion of ways to proceed. The following comments 
>are offered as an individual contributor.
>
>For the last several years, the working group has been 
>ruminating over multicast VPN architectures. So far the WG 
>produced the following documents:
>
>These documents offer a plethora of possible MVPN options, 
>without specifying which MUST be implemented, which SHOULD be 
>implemented, and which are MAY be implemented.
>
>draft-morin-l3vpn-mvpn-considerations. This document specifies 
>*single* subset of options that all vendors MUST implement. It 
>also specifies a subset that vendors SHOULD and MAY implement. 
>Although this document was generally well received by the 
>working group, it was not adopted as a working group item 
>because approval was not unanimous.

JD:  Why was unanimity required?

>
>Later, Eric Rosen introduced draft-rosen-l3vpn-mvpn-profiles. 
>This draft specified a set of MVPN profiles drawn from the two 
>documents mentioned above. Other, possibly non-interoperable 
>profiles also may be developed. 
>In the interest of making progress I would suggest that it is 
>time for the WG to decide whether to accept 
>draft-morin-l3vpn-mvpn-considerations
>as the WG document, or to follow the profile approach, as 
>outlined in draft-rosen-l3vpn-mvpn-profiles (with the end 
>result of multiple possibly non-interoperable profiles).
>
>With this in mind I would like to ask the WG chairs for a 
>consensus call on either (a) accepting  
>draft-morin-l3vpn-mvpn-considerations as the WG, or (b) 
>following the profile approach, as outlined in 

JD:  If and when such a consensus call is issued, I will express my
support for a).  The problem of having two completely different designs
will not be fixed with the approach described in b).  Rather, b) would
codify it.

---

From: ycai <[email-masked]>
Date: Thu, 24 Jul 2008 11:25:16 -0700

Here is what I think.

1. There are many pieces that an SP can use to build a network offering MVPN
services,  ranging from PE-PE signaling, the transport (and its signaling)
mechanism in the core, to the various optimization schemes suitable for the
above.   I personally don't believe there will be *one* solution that can
fit all the requirements, or even the representative ones.

As such,  I support the approach using profiles to describe, within each
profile, the minimum interop requirement.  The WG will indeed be challenged
to figure out the interop between certain profiles, or between certain
elements of the relevant profiles.  But this can't possibly be a surprise to
anyone.  The challenge is already in front of us with or without the
profiles.   

This leads to my second comment.

2. One reason we are here today is because between when MVPN started in
1999/2000 (or maybe earlier, but I can only go back that far;) and 2004,
IETF effectively ignored it and let the SPs/vendors do their best, and on
their own, to come up with a solution (hopefully interoperable). As a
result, when IETF comes up with a different mechanism than the one deployed,
we will end up dealing with three, instead of one (as some would hope).
Because we all have to deal with the deployed base, the new one, and the
path from the deployed to the new.

However, my point is not that we should stop developing BGP based
mechanisms.  Rather,  I want to point out that we should be realistic of
what will happen which is eventually determined by the market place.  More
importantly,  I want to point out that we can't  ignore new requirement
(e.g., one from Maria) just because the WG already has the plates full.  SPs
and vendors can rarely afford to wait for the next solution coming out of
IETF.  For new requirement, the WG should try our best to evaluate and
accommodate so that an interoperable solution can be produced as early as
possible.  Otherwise,  we will be stuck in this perpetual spiral of catching
up and creating three instead of one solution to a single problem.

Have fun in Dublin and travel safely.

-- 
Yiqun

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jul 2008 17:28:37 -0700

Could it be we are here today because the solution space is way too  
complex?

Dino

On Jul 24, 2008, at 11:25 AM, ycai wrote:

>> *single*

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 25 Jul 2008 08:25:05 -0400

Dear Dino;

> Could it be we are here today because the solution space is way too  

Do you mean "complex, because this is a very complex problem" or  
"unnecessarily complex" ?

Regards
Marshall

>>> consensus call

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 25 Jul 2008 09:41:58 -0700

> "unnecessarily complex" ?

Grant it, the problem is hard, not impossible, but hard. But maybe the  
working group should just draw a line and say we are only going to  
support SSM over the core and make that work. Rather than having so  
many profiles, modes, options, etc. That just makes interoperability  
really hard.

If you make one simple option for a solution and try to not go hog- 
wild on so many optimizations, they maybe first phase both Juniper and  
cisco will agree on *same* option, that is the only option.

You've heard the phrase "there are standards, too many of them, just  
pick one and you can claim being standard".  ;-)

Dino

>>>> This draft
>>>> time for
>>>> outlined in

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 25 Jul 2008 14:09:36 -0700 (PDT)

On Fri, 25 Jul 2008, Dino Farinacci wrote:

-) > Dear Dino;
-) > 
-) > On Jul 24, 2008, at 8:28 PM, Dino Farinacci wrote:
-) > 
-) > > Could it be we are here today because the solution space is way too
-) > > complex?
-) > 
-) > Do you mean "complex, because this is a very complex problem" or
-) > "unnecessarily complex" ?
-) 
-) Grant it, the problem is hard, not impossible, but hard. But maybe the
-) working group should just draw a line and say we are only going to support
-) SSM over the core and make that work. Rather than having so many profiles,
-) modes, options, etc. That just makes interoperability really hard.
-) 

Because ASM in the core is not the problem in MVPNs.  In Internet mcast, 
ASM is problematic.  In MVPNs, an argument could be made that ASM is 
actual ideal in the P-instance since it is a many-to-many device discovery 
app with relatively few, known, trusted sources (PEs).  This is the one 
(only) app where ASM is actually ideal.

-) If you make one simple option for a solution and try to not go hog-wild on so
-) many optimizations, they maybe first phase both Juniper and cisco will agree
-) on *same* option, that is the only option.
-) 
-) You've heard the phrase "there are standards, too many of them, just pick one
-) and you can claim being standard".  ;-)
-) 

But VPNs are not one-size-fits-all.  Some VPNs have many sites with low 
data, some with few sites and high data, some with lots of state, etc.  No 
one solution will address.  I think the current MVPN spec does a good job 
of providing enough tools in the toolbox to address each problem.  The 
problem is in determining which of these tools should be MAY/SHOULD/MUST.

---

From: David Ward <[email-masked]>
Date: Sat, 26 Jul 2008 16:06:11 -0500

Ron -

Another approach the WG could consider is advancing:

draft-ietf-l3vpn-2547bis-mcast-07.txt
draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt

and stopping all work on any profiles or considerations documents.

We could get the protocol specifications through the standardization  
process asap as there is precedence that the IESG will move the  
protocol specifications forward (upstream-label is already in the RFC  
Editor's queue) . Also, there is  wide deployment of many operational  
variants of mcast-l3vns such that continued discussion over the  
profiles/considersations docs is not a productive exercise for  
operators or implementors. The market has moved on and in the end,  
everyone was right.

Please note that  these two protocol documents were frozen on  a  
particular date, and the result is that there are some things needed  
to meet current or recently discussed requirements and are either  
not  in them, or not fully specified in  them.  Thus the need for  
follow-on  work does not  depend entirely on  any decision to  adopt  
new requirements and is a separate consideration.

Thanks

-DWard

On Jul 21, 2008, at 3:04 PM, Ron Bonica wrote:

> discussion of ways to proceed. The following comments are offered  
> as an individual contributor.
>
> For the last several years, the working group has been ruminating  
> over multicast VPN architectures. So far the WG produced the  
> following documents:
>
> specifying which MUST be implemented, which SHOULD be implemented,  
> and which are MAY be implemented.
>
> Thomas Morin attempted to fill the void by introducing draft-morin- 
> l3vpn-mvpn-considerations. This document specifies *single* subset  
> of options that all vendors MUST implement. It also specifies a  
> subset that vendors SHOULD and MAY implement. Although this  
> document was generally well received by the working group, it was  
> not adopted as a working group item because approval was not  
> unanimous.
>
> Later, Eric Rosen introduced draft-rosen-l3vpn-mvpn-profiles. This  
> draft specified a set of MVPN profiles drawn from the two documents  
> mentioned above. Other, possibly non-interoperable profiles also  
> may be developed. draft-rosen-l3vpn-mvpn-profiles was never  
> proposed as a working group item.
>
> In the interest of making progress I would suggest that it is time  
> for the WG to decide whether to accept draft-morin-l3vpn-mvpn- 
> considerations as the WG document, or to follow the profile  
> approach, as outlined in draft-rosen-l3vpn-mvpn-profiles (with the  
> end result of multiple possibly non-interoperable profiles).
>
> With this in mind I would like to ask the WG chairs for a consensus  
> call on either (a) accepting  draft-morin-l3vpn-mvpn-considerations  
> as the WG, or (b) following the profile approach, as outlined in

---

From: Thomas Morin <[email-masked]>
Date: Sun, 27 Jul 2008 01:05:52 +0200

Hi David,

David Ward :
> Editor's queue).

Can you tell us how draft-ietf-l3vpn-2547bis-mcast-07, in its current
state, is a "protocol specification".  It is in fact very frequently
called, including by its authors, as the mvpn "framework" or
"architecture draft". The reason is that it currently doesn't define a
set of procedures that would allow implementers to write interoperable
implementations. Do you really think this would be acceptable by the
IESG ?

-Thomas

---

From: David Ward <[email-masked]>
Date: Sun, 27 Jul 2008 00:33:45 -0500

Thomas -

I think that the drafts in conjunction with the other related and  
referenced drafts (some of which aren't in l3vpn for example):

draft-ietf-mpls-multicast-encaps-10.txt

have enough detail to allow interoperable implementations. Given the  
long history of mcast-l3vpns and the multi-WG nature of the work it  
should be expected that an implementor will have to be fully aware of  
where the required specifications located. This is common in many  
other technologies.

Thanks

-DWard

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 27 Jul 2008 19:03:54 +0100

Dave, Colleagues,

As an operator with >1 multi-vendor MPLS networks that have mcast L3VPN
requirements my preference (and motivation for co-authoring draft-morin) is
for whatever the group specifies/standardises to have wherever possible an
identified minimum set of mechanisms within the WG mcast L3VPN
specifications.

Experience tells me that even relatively simple specifications are often
implemented differently by different vendors/products and that causes me
significant pain.  The more complex the specification and the more options
there are the larger the chance that implementations won't interoperate and
the longer the time (and therefore the longer my pain) until they do
interoperate. The 2547bis-mcast specifications are extremely complex - some
of this is the problem space itself and some is the sheer number of options
that the specifications include.

I believe there is benefit to the WG specifying a subset of the
2547bis-mcast specifications as mandatory and it is my hope that the WG can
achieve some agreement towards that.  My alternative is to do the same work
directly with my vendors but I would much rather have that work done in the
WG than on a per-operator<->vendor basis.

Ben

---

From: Thomas Morin <[email-masked]>
Date: Sun, 27 Jul 2008 22:49:43 +0100

Hi David,

My question was not related to whether or not it is doable to find the
required information needed to implement the different procedures
described in draft-ietf-l3vpn-2547bis-mcast. I agree that this is
certainly the case.

My question is about whether or not it is acceptable for the IESG to
progress to Standard Track a document that does not define a set of
MANDATORY mechanisms that would allow interoperability.

Just to reformulate what Ben just expressed: *if* it was considered
acceptable, it would mean that the work needed to ensure that two
different implementations will work together will have to be done by
each operator on a per-vendor basis; I don't think that this matches the
expectations that operators have from the IETF and from a standard,
hence our contribution to suggest a way to have the working group
produce something usable as a standard.

-Thomas

---

From: David Ward <[email-masked]>
Date: Sun, 27 Jul 2008 16:50:57 -0500

Ben -

Given the length of the time required to discuss and document these  
specifications,  there are now multiple deployments of mcast-l3vpns  
that use fundamentally different technologies. Given this how can  
there be a single, mandatory set of technology that must be  
implemented? How would it be used as something other than an  
exclusion set for service providers dependent on "the other"  
technology? The protocol specs currently allow for the different  
technologies to exist and we are caught in an OSPF v ISIS situation  
of the mid-80s. I think in this case we may have to come to the same  
conclusion that both core technologies must exist.

If  profiles or description of necessary components for specific  
deployments are desired, I strongly suggest these are taking on the  
individual submission track vs private negotiation with vendors. The  
scenarios can be documented and would not be blocking the WG and  
accomplish what you need.

HIH

-DWard

---

From: David Ward <[email-masked]>
Date: Sun, 27 Jul 2008 17:06:53 -0500

Thomas -

Given the core foundations of both solutions are standards track (see  
referenced docs) and define what is possible to implement, the choice  
of which technology is desired leaves an implementor enough awareness  
on how to design and develop the software (there is evidence of this  
as there are multiple interoperable implementations and deployments  
of the technology).

This leaves an operator in the same decision when asking themselves  
"I need to deploy an IGP." There are choices of what to deploy, each  
with pros and cons. Given there are examples of mcast-l3vpn related  
documents moving through the IESG, and there are examples where there  
had to be multiple solutions for a variety of historical reasons; it  
is worthwhile to move the two docs along in the standardization process.

Again, the goal here is not to stop all work ... ever ... on  
describing mcast-l3vpn deployments but, to move them out of the WG to  
individual submissions.

-DWard

On Jul 27, 2008, at 4:49 PM, Thomas Morin wrote:

>>>>> consensus

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 28 Jul 2008 01:32:16 +0100

Dave, Colleagues,

I take your point on OSPF Vs ISIS, however mcast for L3VPN is different
because we are not talking about a single protocol/mechanism but rather a
there are several mechanisms that can be combined in multiple ways making
interoperability much harder.

Currently the mcast L3VPN drafts leave specify a number of mechanisms for
each function all of which are optional. While my hope would be a single set
of mandatory mechanisms that implementations must include, I accept that,
unfortunately, this may not be possible to achieve, however I do not accept
that it is not possible for some of the mechanisms. For example, I do not
believe there is any dissent in the WG to make BGP the mandatory option for
auto-discovery and see no reason why the draft cannot reflect that.

It seems to me that discussion on some mechanisms (e.g. Protocol for PE-PE
route distribution) is unnecessarily blocking the mandating of other
mechanisms that provide different functions within the mcast L3VPN problem
space. Let's not unnecessarily throw the baby out with the bath water.

I believe the WG should look at each function individually and decide
whether there is consensus to mandate the implementation of one of the
possible mechanisms for that function (which doesn't preclude it also
specifying alternative optional mechanisms).  It may be that for some
functions it is not possible to achieve consensus and in those cases maybe
the WG leaves both to co-exist but at least the WG will have eased the pain
and improved the chance of interoperability for some of the functions.

Ben

---

From: David Ward <[email-masked]>
Date: Mon, 28 Jul 2008 00:58:49 -0500

Ben -

I believe your proposal (simplified) is tantamount to splitting  
'draft-ietf-l3vpn-2547bis-mcast-07'  3 documents: a BGP based  
solution, a PIM based solution and common document and attempting to  
get consensus on all three simultaneously. Do you feel this is worth  
the time and effort vs taking the profiles and/or considerations  
specs and moving them forward as individual submissions and leaving  
the protocol specs as is? The goal is to take a snapshot of what has  
been worked on for many, many years in the WG and allow refinement of  
the technology to progress.

I hope my proposal allow for easy adoption and success of each  
technology without precluding the other and trapping any operator  
without a suitable standard to deploy their network.

-DWard

---

From: Thomas Morin <[email-masked]>
Date: Mon, 28 Jul 2008 08:16:06 +0100

Hi David,

David Ward :
> get consensus on all three simultaneously. 

The proposal is certainly not to split or restructure existing
documents, but to clearly indicate for as many building blocks as
possible, an approach that is mandatory to implement (keeping the others
as optional).

> without a suitable standard to deploy their network.

Our proposal does not preclude the implementation of the mechanisms that
are not part of the set of mandatory procedures.

Your text above suggests that there would be a risk to end up with a
solution not fitting some deployments needs, but I don't think that this
matches the reality, as it seems that many implementors would implement
or have implemented not only the mechanisms that we propose as
mandatory, but also some optional ones).

-Thomas

---

From: David Ward <[email-masked]>
Date: Mon, 28 Jul 2008 02:33:01 -0500

Thomas -

If an operator using variant of mcst-l3vpn technology differs than   
what you are declaring mandatory as we know is the case; then they  
are trapped by "non-compliance" into the future. As you mention these  
providers use "optional" bits that already happen to be implemented  
and deployed. Therefore we are caught in the question of mandatory vs  
optional for whom? I know we are going in a circular argument here  
but, there has been no consensus for years on "the" mandatory set. I  
think the WG has to admit that there are in fact multiple mandatory  
sets depending on what you are deploying. I know this isn't perfect  
by any means but, pragmatically there appears to be no other obvious  
conclusion.

-DWard

On Jul 28, 2008, at 2:16 AM, Thomas Morin wrote:

>>>>> of this is the problem space itself and some is the sheer  
>>>>> number of
>>>>> options
>>>>>>> begin a
>>>>>>> ruminating
>>>>>>> without
>>>>>>> This
>>>>>>> time

---

From: Thomas Morin <[email-masked]>
Date: Mon, 28 Jul 2008 08:33:36 +0100

Hi David again,

> conclusion that both core technologies must exist.

I'm surprised to hear you, as an AD, describe things in such "binary"
terms. There are not "two protocols" currently described in
draft-ietf-2547bis-mcast. There are essentially 4 building blocks, each
with two options fully specified (this is more choice than ISIS vs
OSPF).

This is also not PIM vs. BGP as you suggested in another email:
- BGP, as the autodiscovery mechanism, is in practice needed for any
implementation
- S-PMSI switching signaling is about BGP vs. a UDP-based protocol
- segmented or non-segmented inter-AS has not much to do with PIM vs BGP

Where we could start to see more binarity, is in the
vendor/implementation realm, where we can see vendors focusing on two
different sets of procedures : was it what you were talking about ?  

Even in this area, this is no real cut frontier into "two options":
- some parts will be common to all implementations : the use of BGP for
autodiscovery 
- in fact multiple alternative mechanism can (and do) coexist inside a
same implementation.

-Thomas

---

From: David Ward <[email-masked]>
Date: Mon, 28 Jul 2008 02:44:52 -0500

Thomas -

earlier portion snipped and reply down below ...

> different sets of procedures : was it what you were talking about ?

DW: No. Implementations get deployed and networks are built off those  
implementations.  Any vendor disagreement isn't of any concern of mine.

> - in fact multiple alternative mechanism can (and do) coexist inside a

DW: My comment here would be the same reply to Ben. Although not  
required to split the doc ,the exercise would be the same: define  
common mandatory and then the mandatory bits of the differing  
procedures and attempt to achieve consensus simultaneously. Seems  
easier to take the variants as individual specs and continue.

-DWard

---

From: Thomas Morin <[email-masked]>
Date: Mon, 28 Jul 2008 08:45:58 +0100

Hi David,

> describing mcast-l3vpn deployments but, to move them out of the WG to  

Our draft proposing a set of mechanisms is not about "deployments" (if
that is what you meant).  If it was applicable to only specific
deployments or operators, wouldn't we hear many operators against the
draft, and would it have easily gathered 5 operators to co-author it ?

-Thomas

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 28 Jul 2008 09:58:04 +0200

Thomas,

> possible, an approach that is mandatory to implement (keeping the  

That is part of the problem, you are comparing building blocks to  
decide what is mandatory or optional. Comparing is a very tricky  
business and has not produced any consensus for the last 2 years.  
There are also many examples, like IS-IS vs OSPF, PIM vs DVMRP vs  
MOSPF, where the IETF was not successful in getting consensus on a  
single solution. I think we should not be comparing building blocks  
but describe which blocks together form a solution, like what is done  
in the profiles draft. Then as a customer you can choose the solution  
set that solves your problem best and talk you your vendor for an  
implementation.

Thx,

Ice.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 28 Jul 2008 09:11:48 +0100

Dave,

I agree we are being somewhat circular in our arguments.  I guess my
position is that while I recognise it may not be possible to reach consensus
on all the mechanisms it should be possible to reach consensus on some.
Maybe that is not even possible but if so it would be disappointing.

Ben

---

From: Shane Amante <[email-masked]>
Date: Mon, 28 Jul 2008 02:40:10 -0600

Dave,

David Ward wrote:
> Thomas -
> 
> If an operator using variant of mcst-l3vpn technology differs than  what 
> you are declaring mandatory as we know is the case; then they are 
> trapped by "non-compliance" into the future. As you mention these 
> providers use "optional" bits that already happen to be implemented and 
> deployed. Therefore we are caught in the question of mandatory vs 
> optional for whom? I know we are going in a circular argument here but, 
> there has been no consensus for years on "the" mandatory set. I think 
> the WG has to admit that there are in fact multiple mandatory sets 
> depending on what you are deploying. I know this isn't perfect by any 
> means but, pragmatically there appears to be no other obvious conclusion.

This approach seems to just continue delaying (to a future date) a 
solution to a single, clearly defined, mandatory-to-implement set of 
procedures for interoperable mcast-l3vpn implementations. 
Unfortunately, this will only proliferate the number of 
non-interoperable deployments in the mean time.  IMO, we might as well 
take our medicine *now* by making the hard choices, rather than making 
our lives more difficult down the road.

-shane

---

From: "Leymann, Nicolai" <[email-masked]>
Date: Mon, 28 Jul 2008 10:45:18 +0200

Hi, 

> Von: [email-masked] [mailto:[email-masked]] Im Auftrag
von Ben Niven-Jenkins
> Gesendet: Montag, 28. Juli 2008 10:12
> An: David Ward; Thomas Morin
> Cc: Ross Callon; [email-masked]; Danny McPherson
> Betreff: Re: What should we do next?
> 
> Dave,
> 
> I agree we are being somewhat circular in our arguments.  
> I guess my position is that while I recognise it may not be 
> possible to reach consensus on all the mechanisms it should 
> be possible to reach consensus on some.
I think it is necessary to reach consensus at least on 
those points which are not under "heavy discussion". One goal
of the WG should be to come up with a solution which is supported 
by more than a single implementation or vendor (btw: I think 
that this is also a major task of any standardization body). 

Many ISPs (inclusing us) are building networks based on a 
multivendor equipment but this assumes that an interoperable
solution is available. Looking on the mVPN problem space and 
the existing implementation the only possibility today is to use
a mVPN solution based on an outdated draft which does not fulfil 
the existing requirements. 

> I believe there is benefit to the WG specifying a subset of 
> the 2547bis-mcast specifications as mandatory and it is my 
> hope that the WG can achieve some agreement towards that.  

> My alternative is to do the same work directly with my vendors 
> but I would much rather have that work done in the WG than 
> on a per-operator<->vendor basis.
Right, there might be no other way if we do not reach consensus.
>From my experience this causes a lot of work and/or pain and
long delays for all involved parties because vendors might end up 
with the need to implement more than a single option based on the 
bi-lateral discussions with the ISPs. In this case I guess the
result will be a bunch of more or less interoperable implemen-
tations.

Therefor I'm also in favour of an WGs agreement on a set of
mandatory procedures.

  regards

     Nic

Ben

On 28/07/2008 08:33, "David Ward" <[email-masked]> wrote:

> what you are declaring mandatory as we know is the case; then they are

> sets depending on what you are deploying. I know this isn't perfect by

> any means but, pragmatically there appears to be no other obvious 
> conclusion.
> 
> 
> -DWard
> 
> 
> 
> 

>> possible, an approach that is mandatory to implement (keeping the 
>> others as optional).
>> 
>> Our proposal does not preclude the implementation of the mechanisms 
>> that are not part of the set of mandatory procedures.
>> 
>> solution not fitting some deployments needs, but I don't think that 
>> this matches the reality, as it seems that many implementors would 
>> implement or have implemented not only the mechanisms that we propose

>> as mandatory, but also some optional ones).
>> 
>> -Thomas
>> 
>> 
>>>> I take your point on OSPF Vs ISIS, however mcast for L3VPN is 
>>>> different because we are not talking about a single 
>>>> protocol/mechanism but rather a there are several mechanisms that 
>>>> can be combined in multiple ways making interoperability much 
>>>> harder.
>>>> 
>>>> Currently the mcast L3VPN drafts leave specify a number of 
>>>> mechanisms for each function all of which are optional. While my 
>>>> hope would be a single set of mandatory mechanisms that 
>>>> implementations must include, I accept that, unfortunately, this 
>>>> may not be possible to achieve, however I do not accept that it is 
>>>> not possible for some of the mechanisms. For example, I do not 
>>>> believe there is any dissent in the WG to make BGP the mandatory 
>>>> option for auto-discovery and see no reason why the draft cannot 
>>>> reflect that.
>>>> 
>>>> It seems to me that discussion on some mechanisms (e.g. Protocol 
>>>> for PE-PE route distribution) is unnecessarily blocking the 
>>>> mandating of other mechanisms that provide different functions 
>>>> within the mcast L3VPN problem space. Let's not unnecessarily throw

>>>> the baby out with the bath water.
>>>> 
>>>> I believe the WG should look at each function individually and 
>>>> decide whether there is consensus to mandate the implementation of 
>>>> one of the possible mechanisms for that function (which doesn't 
>>>> preclude it also specifying alternative optional mechanisms).  It 
>>>> may be that for some functions it is not possible to achieve 
>>>> consensus and in those cases maybe the WG leaves both to co-exist 
>>>> but at least the WG will have eased the pain and improved the 
>>>> chance of interoperability for some of the functions.
>>>> 
>>>> Ben
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Given the length of the time required to discuss and document 
>>>>> these specifications,  there are now multiple deployments of 
>>>>> mcast-l3vpns that use fundamentally different technologies. Given 
>>>>> this how can there be a single, mandatory set of technology that 
>>>>> must be implemented? How would it be used as something other than 
>>>>> an exclusion set for service providers dependent on "the other"
>>>>> technologies to exist and we are caught in an OSPF v ISIS 
>>>>> situation of the mid-80s. I think in this case we may have to come

>>>>> to the same conclusion that both core technologies must exist.
>>>>> 
>>>>> deployments are desired, I strongly suggest these are taking on 
>>>>> the individual submission track vs private negotiation with
vendors.
>>>>> The
>>>>>> As an operator with >1 multi-vendor MPLS networks that have mcast

>>>>>> L3VPN requirements my preference (and motivation for co-authoring

>>>>>> draft-
>>>>>> morin) is
>>>>>> for whatever the group specifies/standardises to have wherever 
>>>>>> possible an identified minimum set of mechanisms within the WG 
>>>>>> mcast L3VPN specifications.
>>>>>> 
>>>>>> Experience tells me that even relatively simple specifications 
>>>>>> are often implemented differently by different vendors/products 
>>>>>> and that causes me significant pain.  The more complex the 
>>>>>> specification and the more options there are the larger the 
>>>>>> chance that implementations won't interoperate and the longer the

>>>>>> time (and therefore the longer my pain) until they do 
>>>>>> interoperate. The 2547bis-mcast specifications are extremely 
>>>>>> complex - some of this is the problem space itself and some is 
>>>>>> the sheer number of options that the specifications include.
>>>>>> 
>>>>>> 2547bis-mcast specifications as mandatory and it is my hope that 
>>>>>> the WG can achieve some agreement towards that.  My alternative 
>>>>>> is to do the same work directly with my vendors but I would much 
>>>>>> rather have that work done in the WG than on a 
>>>>>> per-operator<->vendor basis.
>>>>>> 
>>>>>> Ben
>>>>>> 
>>>>>> 
>>>>>>> We could get the protocol specifications through the 
>>>>>>> standardization process asap as there is precedence that the 
>>>>>>> IESG will move the protocol specifications forward 
>>>>>>> (upstream-label is already in the RFC Editor's queue) . Also, 
>>>>>>> there is  wide deployment of many operational variants of 
>>>>>>> mcast-l3vns such that continued discussion over the 
>>>>>>> operators or implementors. The market has moved on and in the 
>>>>>>> end, everyone was right.
>>>>>>> 

>>>>>>> particular date, and the result is that there are some things 
>>>>>>> needed to meet current or recently discussed requirements and 
>>>>>>> are either not  in them, or not fully specified in  them.  Thus 
>>>>>>> the need for follow-on  work does not  depend entirely on  any 
>>>>>>> decision to adopt new requirements and is a separate 
>>>>>>> consideration.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> -DWard
>>>>>>> 
>>>>>>>> The purpose of this message is to summarize WG status and begin

>>>>>>>> a discussion of ways to proceed. The following comments are 
>>>>>>>> offered as an individual contributor.
>>>>>>>> 
>>>>>>>> l3vpn-mvpn-considerations. This document specifies *single* 
>>>>>>>> subset of options that all vendors MUST implement. It also 
>>>>>>>> specifies a subset that vendors SHOULD and MAY implement. 
>>>>>>>> draft specified a set of MVPN profiles drawn from the two 
>>>>>>>> profiles also may be developed. draft-rosen-l3vpn-mvpn-profiles

>>>>>>>> was never proposed as a working group item.
>>>>>>>> 
>>>>>>>> draft-morin-l3vpn-mvpn- considerations as the WG document, or 
>>>>>>>> to follow the profile approach, as outlined in 
>>>>>>>> draft-rosen-l3vpn-mvpn-profiles (with the end result of 
>>>>>>>> multiple possibly non-interoperable profiles).
>>>>>>>> 
>>>>>>>> consensus call on either (a) accepting  draft-morin-l3vpn-mvpn-

>>>>>>>> considerations as the WG, or (b) following the profile 
>>>>>>>> approach, as outlined in draft-rosen-l3vpn-mvpn-profiles
>>>>>>>> 
>>>>>>>>                                        Ron
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

---

From: Thomas Morin <[email-masked]>
Date: Mon, 28 Jul 2008 10:34:41 +0100

Hi David,

David Ward :
> are trapped by "non-compliance" into the future.

In practice, it is already well identified that deployments of early
implementation won't be "compliant" with the current specs : even when
considering the approaches that are the one closer to draft-rosen, there
have been evolutions (e.g. BGP autodiscovery has evolved to more generic
encodings, and how the upstream PE selection is done is also
different).  

I don't think there is any "trap" as you suggest.  Operators quite
expect such things to happen when deploying early implementations.

This is in practice resolved by encouraging vendors to provide the
required features to ease migration from implementations of early
proposals,

-Thomas

> > others
> > that
> > this
> >>> different
> >>> mechanisms for
> >>> option for
> >>> for PE-PE
> >>> decide
> >>>>> L3VPN
> >>>>> possible an
> >>>>> complex - some
> >>>>> the WG can
> >>>>>> standardization
> >>>>>> end,
> >>>>>> needed
> >>>>>>> subset
> >>>>>>> documents
> >>>>>>> (with the

---

From: David Ward <[email-masked]>
Date: Mon, 28 Jul 2008 05:14:01 -0500

The issue is here we aren't talking about a -00 draft that got  
dropped, changed or modified. We are talking about technology under  
development and deployment for many years. If we weren't so far down  
the path, I'd agree with you. At this point, it would do damage to  
existing deployments.

-DWard

On Jul 28, 2008, at 4:34 AM, Thomas Morin wrote:

>>>>> of mandatory mechanisms that implementations must include, I  
>>>>> accept
>>>>> that,
>>>>>> these
>>>>>> situation
>>>>>>> requirements my preference (and motivation for co-authoring  
>>>>>>> draft-
>>>>>>> morin) is
>>>>>>> Experience tells me that even relatively simple  
>>>>>>> specifications are
>>>>>>> often
>>>>>>> significant pain.  The more complex the specification and the  
>>>>>>> more
>>>>>>> options
>>>>>>> achieve some agreement towards that.  My alternative is to do  
>>>>>>> the
>>>>>>> same work

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 28 Jul 2008 10:54:57 -0400

David,

	I support your proposal to move things forward.

	--Tom

> been worked on for many, many years in the WG and allow refinement  
> of the technology to progress.
>

---

From: Thomas Morin <[email-masked]>
Date: Thu, 31 Jul 2008 16:19:11 +0100

Hi David,

David Ward :
> development and deployment for many years.

No, the technology we are talking about (draft-ietf-2547bis-mcast and
draft-ietf-2547bis-mcast-bgp) has *not* been deployed for many years. 

What has been deployed "for years" differs by a few significant points
from the current specs, from what has been deployed (e.g. BGP
autodiscovery has evolved to more generic encodings, and how the
upstream PE selection is done is also different, and there are other
differences).

> If we weren't so far down the path, I'd agree with you. 
> At this point, it would do damage to existing deployments.

I'm can't see what the "it" in your sentence precisely refers to.
What exactly would "damage existing deployments" ?

The proposal made through our considerations draft does not change the
situation wrt. to existing deployments.  It clearly indicates what can
be optionally implemented to be as close as possible to them, without
changing anything to the fact that some migration will be needed so that
they fit exactly procedures described in draft-ietf-2547bis-mcast.

-Thomas