RE: Advancing the Protocol and Morin Drafts

[Thomas Morin <[e-mail]>]

Hi Luyuan,

Luyuan Fang (lufang) :
>
> 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. 

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.


> 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. 

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



> -----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
> > 
> > 
>