RE: Advancing the Protocol and Morin Drafts

["Luyuan Fang (lufang)" <[e-mail]>]

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:[e-mail]] 
Sent: 10 October 2008 12:24
To: Luyuan Fang (lufang); [e-mail]
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)" <[e-mail]> wrote:

>  
> 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: [e-mail] [mailto:[e-mail]] On 
>> Behalf
> 
>> Of Marshall Eubanks
>> Sent: Wednesday, October 01, 2008 10:04 AM
>> To: [e-mail]
>> 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
> 
>