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

[ycai <[e-mail]>]

Since the weekend is coming I will try to keep the email short and upbeat.

First of all,  I support the decision to include the items and milestones in
the charter as proposed by Ben.  I hope that we all have the understanding
that for many of us the reason we are working on them is not to kill time
over the weekends.

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 naïve. 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.

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 favorably
>>     at the use of MP2MP LSPs for support of C-bidir, using the "partitioned"
>>     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 is 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 WG
>>     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