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

[Thomas Morin <[e-mail]>]

  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