Subject: Re: L3vpn Digest, Vol 49, Issue 25

From: "Bruno De Troch" <[email-masked]>
Date: Mon, 28 Jul 2008 09:58:12 +0100

--------------------------
Sent from my Wireless Handheld

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Mon Jul 28 09:45:39 2008
Subject: L3vpn Digest, Vol 49, Issue 25

Send L3vpn mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/l3vpn
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of L3vpn digest..."

Today's Topics:

   1. Re: What should we do next? (Ben Niven-Jenkins)
   2. Re: What should we do next? (Shane Amante)
   3. RE: What should we do next? (Leymann, Nicolai)
   4. (no subject)

----------------------------------------------------------------------

Message: 1
Date: Mon, 28 Jul 2008 09:11:48 +0100
From: Ben Niven-Jenkins <[email-masked]>
Subject: Re: What should we do next?
To: David Ward <[email-masked]>,	Thomas Morin
	<[email-masked]>
Cc: Ross Callon <[email-masked]>, [email-masked],	Danny McPherson
	<[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="US-ASCII"

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

On 28/07/2008 08:33, "David Ward" <[email-masked]> 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.
> 
> 
> -DWard
> 
> 
> 
> 
> On Jul 28, 2008, at 2:16 AM, Thomas Morin wrote:
> 
>> Hi David,
>> 
>> David Ward :
>>> 
>>> 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.
>> 
>> 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).
>> 
>>> 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.
>> 
>> 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
>> 
>> 
>>> On Jul 27, 2008, at 7:32 PM, Ben Niven-Jenkins wrote:
>>> 
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 27/07/2008 22:50, "David Ward" <[email-masked]> wrote:
>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jul 27, 2008, at 1:03 PM, Ben Niven-Jenkins wrote:
>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> On 26/07/2008 22:06, "David Ward" <[email-masked]> wrote:
>>>>>> 
>>>>>>> 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:
>>>>>>> 
>>>>>>>> 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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

------------------------------

Message: 2
Date: Mon, 28 Jul 2008 02:40:10 -0600
From: Shane Amante <[email-masked]>
Subject: Re: What should we do next?
To: David Ward <[email-masked]>
Cc: Ross Callon <[email-masked]>,	Ben Niven-Jenkins
	<[email-masked]>,	Thomas Morin
	<[email-masked]>, [email-masked],	Danny McPherson
	<[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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

------------------------------

Message: 3
Date: Mon, 28 Jul 2008 10:45:18 +0200
From: "Leymann, Nicolai" <[email-masked]>
Subject: RE: What should we do next?
To: <[email-masked]>, <[email-masked]>,
	<[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="US-ASCII"

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.
> Maybe that is not even possible but if so it would be 
> disappointing.
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.

------------------------------

Message: 4
Message-ID: <[email-masked]>

long delays for all involved parties because vendors might end up=20
with the need to implement more than a single option based on the=20
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:

> Thomas -
>=20
> If an operator using variant of mcst-l3vpn technology differs than=20
> 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=20
> providers use "optional" bits that already happen to be implemented=20
> and deployed. Therefore we are caught in the question of mandatory vs=20
> optional for whom? I know we are going in a circular argument here=20
> but, there has been no consensus for years on "the" mandatory set. I=20
> think the WG has to admit that there are in fact multiple mandatory=20
> 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=20
> conclusion.
>=20
>=20
> -DWard
>=20
>=20
>=20
>=20
> On Jul 28, 2008, at 2:16 AM, Thomas Morin wrote:
>=20
>> Hi David,
>>=20
>> David Ward :
>>>=20
>>> I believe your proposal (simplified) is tantamount to splitting=20
>>> 'draft-ietf-l3vpn-2547bis-mcast-07'  3 documents: a BGP based=20
>>> solution, a PIM based solution and common document and attempting to

>>> get consensus on all three simultaneously.
>>=20
>> The proposal is certainly not to split or restructure existing=20
>> documents, but to clearly indicate for as many building blocks as=20
>> possible, an approach that is mandatory to implement (keeping the=20
>> others as optional).
>>=20
>>> I hope my proposal allow for easy adoption and success of each=20
>>> technology without precluding the other and trapping any operator=20
>>> without a suitable standard to deploy their network.
>>=20
>> Our proposal does not preclude the implementation of the mechanisms=20
>> that are not part of the set of mandatory procedures.
>>=20
>> Your text above suggests that there would be a risk to end up with a=20
>> solution not fitting some deployments needs, but I don't think that=20
>> this matches the reality, as it seems that many implementors would=20
>> implement or have implemented not only the mechanisms that we propose

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

>>>> the baby out with the bath water.
>>>>=20
>>>> I believe the WG should look at each function individually and=20
>>>> decide whether there is consensus to mandate the implementation of=20
>>>> one of the possible mechanisms for that function (which doesn't=20
>>>> preclude it also specifying alternative optional mechanisms).  It=20
>>>> may be that for some functions it is not possible to achieve=20
>>>> consensus and in those cases maybe the WG leaves both to co-exist=20
>>>> but at least the WG will have eased the pain and improved the=20
>>>> chance of interoperability for some of the functions.
>>>>=20
>>>> Ben
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 27/07/2008 22:50, "David Ward" <[email-masked]> wrote:
>>>>=20
>>>>> Ben -
>>>>>=20
>>>>> Given the length of the time required to discuss and document=20
>>>>> these specifications,  there are now multiple deployments of=20
>>>>> mcast-l3vpns that use fundamentally different technologies. Given=20
>>>>> this how can there be a single, mandatory set of technology that=20
>>>>> must be implemented? How would it be used as something other than=20
>>>>> an exclusion set for service providers dependent on "the other"
>>>>> technology? The protocol specs currently allow for the different=20
>>>>> technologies to exist and we are caught in an OSPF v ISIS=20
>>>>> 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.
>>>>>=20
>>>>> If  profiles or description of necessary components for specific=20
>>>>> deployments are desired, I strongly suggest these are taking on=20
>>>>> the individual submission track vs private negotiation with
vendors.
>>>>> The
>>>>> scenarios can be documented and would not be blocking the WG and=20
>>>>> accomplish what you need.
>>>>>=20
>>>>> HIH
>>>>>=20
>>>>> -DWard
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Jul 27, 2008, at 1:03 PM, Ben Niven-Jenkins wrote:
>>>>>=20
>>>>>> Dave, Colleagues,
>>>>>>=20
>>>>>> 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=20
>>>>>> possible an identified minimum set of mechanisms within the WG=20
>>>>>> mcast L3VPN specifications.
>>>>>>=20
>>>>>> Experience tells me that even relatively simple specifications=20
>>>>>> are often implemented differently by different vendors/products=20
>>>>>> and that causes me significant pain.  The more complex the=20
>>>>>> specification and the more options there are the larger the=20
>>>>>> chance that implementations won't interoperate and the longer the

>>>>>> time (and therefore the longer my pain) until they do=20
>>>>>> interoperate. The 2547bis-mcast specifications are extremely=20
>>>>>> complex - some of this is the problem space itself and some is=20
>>>>>> the sheer number of options that the specifications include.
>>>>>>=20
>>>>>> I believe there is benefit to the WG specifying a subset of the=20
>>>>>> 2547bis-mcast specifications as mandatory and it is my hope that=20
>>>>>> the WG can achieve some agreement towards that.  My alternative=20
>>>>>> is to do the same work directly with my vendors but I would much=20
>>>>>> rather have that work done in the WG than on a=20
>>>>>> per-operator<->vendor basis.
>>>>>>=20
>>>>>> Ben
>>>>>>=20
>>>>>>=20
>>>>>> On 26/07/2008 22:06, "David Ward" <[email-masked]> wrote:
>>>>>>=20
>>>>>>> Ron -
>>>>>>>=20
>>>>>>> Another approach the WG could consider is advancing:
>>>>>>>=20
>>>>>>> draft-ietf-l3vpn-2547bis-mcast-07.txt
>>>>>>> draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt
>>>>>>>=20
>>>>>>> and stopping all work on any profiles or considerations=20
>>>>>>> documents.
>>>>>>>=20
>>>>>>> We could get the protocol specifications through the=20
>>>>>>> standardization process asap as there is precedence that the=20
>>>>>>> IESG will move the protocol specifications forward=20
>>>>>>> (upstream-label is already in the RFC Editor's queue) . Also,=20
>>>>>>> there is  wide deployment of many operational variants of=20
>>>>>>> mcast-l3vns such that continued discussion over the=20
>>>>>>> profiles/considersations docs is not a productive exercise for=20
>>>>>>> operators or implementors. The market has moved on and in the=20
>>>>>>> end, everyone was right.
>>>>>>>=20
>>>>>>> Please note that  these two protocol documents were frozen on  a

>>>>>>> particular date, and the result is that there are some things=20
>>>>>>> needed to meet current or recently discussed requirements and=20
>>>>>>> are either not  in them, or not fully specified in  them.  Thus=20
>>>>>>> the need for follow-on  work does not  depend entirely on  any=20
>>>>>>> decision to adopt new requirements and is a separate=20
>>>>>>> consideration.
>>>>>>>=20
>>>>>>> Thanks
>>>>>>>=20
>>>>>>> -DWard
>>>>>>>=20
>>>>>>> On Jul 21, 2008, at 3:04 PM, Ron Bonica wrote:
>>>>>>>=20
>>>>>>>> Folks,
>>>>>>>>=20
>>>>>>>> The purpose of this message is to summarize WG status and begin

>>>>>>>> a discussion of ways to proceed. The following comments are=20
>>>>>>>> offered as an individual contributor.
>>>>>>>>=20
>>>>>>>> For the last several years, the working group has been=20
>>>>>>>> ruminating over multicast VPN architectures. So far the WG=20
>>>>>>>> produced the following documents:
>>>>>>>>=20
>>>>>>>> - draft-ietf-l3vpn-2547bis-mcast
>>>>>>>> - draft-ietf-l3vpn-2547bis-mcast-bgp
>>>>>>>>=20
>>>>>>>> These documents offer a plethora of possible MVPN options,=20
>>>>>>>> without specifying which MUST be implemented, which SHOULD be=20
>>>>>>>> implemented, and which are MAY be implemented.
>>>>>>>>=20
>>>>>>>> Thomas Morin attempted to fill the void by introducing draft-
>>>>>>>> morin-
>>>>>>>> l3vpn-mvpn-considerations. This document specifies *single*=20
>>>>>>>> subset of options that all vendors MUST implement. It also=20
>>>>>>>> specifies a subset that vendors SHOULD and MAY implement.=20
>>>>>>>> Although this document was generally well received by the=20
>>>>>>>> working group, it was not adopted as a working group item=20
>>>>>>>> because approval was not unanimous.
>>>>>>>>=20
>>>>>>>> Later, Eric Rosen introduced draft-rosen-l3vpn-mvpn-profiles.
>>>>>>>> This
>>>>>>>> draft specified a set of MVPN profiles drawn from the two=20
>>>>>>>> documents mentioned above. Other, possibly non-interoperable=20
>>>>>>>> profiles also may be developed. draft-rosen-l3vpn-mvpn-profiles

>>>>>>>> was never proposed as a working group item.
>>>>>>>>=20
>>>>>>>> In the interest of making progress I would suggest that it is=20
>>>>>>>> time for the WG to decide whether to accept=20
>>>>>>>> draft-morin-l3vpn-mvpn- considerations as the WG document, or=20
>>>>>>>> to follow the profile approach, as outlined in=20
>>>>>>>> draft-rosen-l3vpn-mvpn-profiles (with the end result of=20
>>>>>>>> multiple possibly non-interoperable profiles).
>>>>>>>>=20
>>>>>>>> With this in mind I would like to ask the WG chairs for a=20
>>>>>>>> consensus call on either (a) accepting  draft-morin-l3vpn-mvpn-

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

------------------------------

_______________________________________________
L3vpn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l3vpn

End of L3vpn Digest, Vol 49, Issue 25
*************************************

---

From: "Bruno De Troch" <[email-masked]>
Date: Mon, 28 Jul 2008 09:58:36 +0100

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Mon Jul 28 09:45:39 2008
Subject: L3vpn Digest, Vol 49, Issue 25

Today's Topics:

Message: 1

Dave,

Ben

Message: 2

Dave,

-shane

Message: 3

Hi, 

von Ben Niven-Jenkins

Message: 4

  regards

     Nic

Ben

vendors.

---

From: "Bruno De Troch" <[email-masked]>
Date: Mon, 28 Jul 2008 09:58:20 +0100

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Mon Jul 28 09:45:39 2008
Subject: L3vpn Digest, Vol 49, Issue 25

Today's Topics:

Message: 1

Dave,

Ben

Message: 2

Dave,

-shane

Message: 3

Hi, 

von Ben Niven-Jenkins

Message: 4

  regards

     Nic

Ben

vendors.