Re: Poll to adopt initial milestones for the new L3VPN charter

[Yakov Rekhter <[e-mail]>]

Hi,

> I don't think IETF has the power to mandate what vendors will implement or
> what a provider will deploy.   Furthermore, fearing of "fragmentation of
> standards and implementation" is not a technical reason for defining WG
> charters and milestones.  FWIW, I had the same fear a few years ago on the
> exact same subject.  Today, the different solutions do exist and are
> deployed.  They are not going away whether we like it or not.
> 
> I'm not sure whether it is realistic to ask every WG member to work on
> everything.  Maybe I'm being naive. But if we are serious about the role of
> the WG (or any IETF WG) and interested in contributing,  we should be trying
> to help each other on improving the solutions instead of trying to come up
> with new reasons to stop each other from discussing and advancing them.

Having few members of the WG interested in working on a particular
item is *not* sufficient for accepting this item as the WG item.
The set of items that a WG is working on is determined by the
*consensus* of the WG.

Moreover, in deciding which items to accept as the WG items, we
need to keep in mind that the WG has limited resources, which may
place limits on the number of items that the WG is working on.

Yakov.

> 
> Have a good weekend.
> 
> 
> 
> On 9/14/10 4:22 AM, "Thomas Morin" <[e-mail]> wrote:
> 
> >   Eric, Working Group,
> > 
> > Eric Rosen:
> >> [...] the milestones [S-PMSI Wilcard] and [MVPN Extranet]
> >> should be accepted if, and only if, the milestones [Bidir P-tunnels] and
> >> [PIM without MI-PMSI] are also accepted.
> > 
> > 
> > Are there technical arguments for adopting these two pairs of items only
> > as an all-or-nothing bundle ?
> > (or are you suggesting some kind of "bargaining" ?!?)
> > 
> > Let me claim that, until we hear arguments, the proposal above is just
> > bogus.
> > 
> > Let's keep in mind that:
> > - RFC4834 asks for "Extranet mVPN" : this provides good rationale for
> > adopting "Extranet mVPN" as a charter item -- independently of other
> > subjects.
> > - the subject of "S-PMSI A-D route wilcards" is also relevant
> > independently of whether we think that we need further specifications
> > for Bidir P-tunnels, or whether we think it is a good idea to pursue the
> > "PIM without MI-PMSI" track. Just look at the two drafts currently
> > proposed for S-PMSI Wildcards (including yours) : the drivers put
> > forward for introducing "S-PMSI wildcards" are not at all related to
> > "Bidir P-tunnels" or "PIM without MI-PMSI".
> > 
> > 
> > 
> >> Sep-11 Submit specification of using Bi-directional P-tunnels for MVPN to
> >>          IESG as PS.
> >> 
> >> Nov-11 Submit specification for using PE-PE PIM in the absence of MI-PMSI 
to
> >>         IESG as PS.
> >> [...] I think the WG should either accept these milestones, or
> >> should close down (for a few years at least, until implementation and
> >> deployment considerations are clearer)
> > 
> > (Your statement is not very well supported, to say the least.)
> > 
> > As we have seen during last meeting, even without these two items as
> > milestones, it seems that the working group has a solid set of items
> > identified, with good rationale (requirements, well identified gains
> > hard to obtain with other means, no identified drawback), many of them
> > with one or more drafts in the pipe, and contributors from vendors and
> > providers ready to contribute.
> > 
> > I would agree with you partially : a clearer view on implementations
> > (e.g. full support for draft-ietf-l3vpn-mvpn-considerations
> > <http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-considerations-06.txt>)
> > would 
> > be a pre-requisite before considering the adoption of "PIM without
> > MI-PMSI" as a milestone (even though not necessarily sufficient) but
> > there is no reason why the WG should close if this item is not made a
> > milestone...
> > 
> > 
> >> -  Bidirectional P-tunnels.
> >> 
> >>     The MVPN architecture explicitly accommodates the use of bidirectional
> >>     P-tunnels.  Even the "considerations" document appears to look favorab
ly
> >>     at the use of MP2MP LSPs for support of C-bidir, using the "partitione
d"
> >>     model.  MP2MP LSPs can also be used in support of the migration from
> >>     GRE/PIM-SM shared P-tunnels to MPLS.
> >> 
> >>     I don't really see any grounds for excluding this work, unless there i
s a
> >>     consensus that bidirectional P-tunnels are not useful for anything.
> >>     Given that IP bidirectional multicast tunnels are already standardized
,
> >>     and that MPLS bidirectional multicast tunnels are covered in an MPLS W
G
> >>     document, I don't see why the L3VPN WG would come to a consensus that
> >>     bidirectional tunnels have no possible use.
> > 
> > Nobody is arguing against the use for bidir P-tunnel, as far as I have
> > seen/heard.
> > However, you possibly need to convince people than a *new* document is
> > needed for Bidir P-tunnels.
> > 
> > So, instead of beating a poor strawman, it would be more useful to
> > clarify a few points:
> > - what is missing in the base specifications for using bidir P-tunnels
> > (let me insist that I pointed out the need to explain what would be
> > missing in the base specs months ago)
> > - what extensions of P-tunnels are needed to do "PIM over MS-PMSI"
> > (because there seem to be specific dependencies)
> > 
> > Doing so would help the working group understand what part (or parts)
> > may be important to adopt as a working group item.
> > 
> > Until this is made clearer, I don't think we should add the proposed
> > item as a milestone, because the goal is too vague (complete the
> existing specs ? extend them to allow new things ? both ?).
> > 
> > 
> > 
> > 
> >> - New option for using PE-PE PIM without MI-PMSI.
> >> 
> >>   
> >>    [... ]Providers who migrate to MPLS multicast in their
> >>    core networks without also migrating to BGP C-Multicast routing at the
> >>    same time may find this work particularly useful.
> >> 
> > 
> > 
> > The issue with a new option for PIM-based C-multicast routing is that it
> > would encourage further fragmentation of the mVPN standards and worsen
> > mVPN interop issues (given the state of the market, by putting pressure
> > onto vendors to choose between implementing this option and follow the
> > recommendations in draft-ietf-l3vpn-mvpn-considerations
> > <http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-considerations-06.txt>).
> > To paraphrase you, I would reformulate this as: providers and vendors
> > who expect the IETF to define standards may find this particularly
> > counter productive.
> > 
> > I object to adopting this as a milestone.
> > 
> > -Thomas
> 
> 
> -- 
> Yiqun
> 
>