Re: What should we do next?

[Thomas Morin <[e-mail]>]

Hi David,

David Ward :
>
> 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.

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


> On Jul 27, 2008, at 4:49 PM, Thomas Morin wrote:
> 
> > 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
> >
> >
> > David Ward :
> >>
> >> 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
> >>
> >> On Jul 26, 2008, at 6:05 PM, Thomas Morin wrote:
> >>
> >>> Hi David,
> >>>
> >>> David Ward :
> >>>>
> >>>> 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).
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>>> 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
> >>>>>
> >>>>
> >>>
> >>
> >
>