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

[Thomas Morin <[e-mail]>]

  Hello Maria,

NAPIERALA, MARIA H (ATTLABS):
> actually, you have listed a technical reason for coupling acceptance of "Wildcard S-PMSIs" with acceptance of "PIM without MI-PMSI", namely that Wildcard S-PMSI, quote, “is a key building block of the ‘PIM over MS-PMSI’ approach”.

First, what you say above is incorrect : even though adopting a ‘PIM 
over MS-PMSI’ draft would require a solution for signaling wildcard 
S-PMSI, there are self-supporting drivers for having "Wildcard S-PMSI 
signaling", independently on some kind of ‘PIM without an MI-PMSI’ approach.

Also, let's keep in mind that we are talking about *milestones* : 
assuming we would adopt "PIM without an MI-PMSI" as a milestone, it does 
not imply we would necessarily adopt the "PIM over MS-PMSI" draft: we 
could, but nothing a priori prevents another solution to be adopted, 
including one not depending on Wildcard S-PMSI signaling.

So no, I don't think there is any reason to support that adopting 
Wildcard S-PMSI as a milestone would mandate also having "PIM without an 
MI-PMSI" as a milestone.


> One or two people cannot decide which MVPN documents/improvements are to be worked on by the WG and which are not, because the latter improvements do not fit those people “strategy”.

You are taking words out of my mouth.

-Thomas




>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Thomas Morin
>> Sent: Wednesday, September 22, 2010 10:00 AM
>> To: L3VPN
>> Subject: Re: Poll to adopt initial milestones for the new L3VPN charter
>>
>>
>>    Hi Eric,
>>
>> Eric Rosen:
>>> Thomas Morin:
>>>> There are absolutely no technical reasons to couple acceptance of
>> the
>>>> Wildcard and the Extranet documents with either using PE-PE PIM in
>> the
>>>> absence of MI-PMSI or a new document on using Bidir P-Tunnels.
>>> [...] I think the real decision to be made is whether the WG really
>> wants to finish
>>> the work and tie up all the loose ends, or whether the WG wants to
>> continue
>>> its dormancy and wait to see what gets implemented and deployed
>> ("rough
>>> consensus and running code").
>> I don't think you really answered the question I asked, but based on
>> your previous emails, I will still try to interpret your answer as a
>> reply addressing my question : are you implying that if, beyond
>> "Extranet mVPN" and "Wildcard S-PMSI", we do not also adopt some
>> milestone on "bidir P-tunnel" and "PIM without an MI-PMSI", then we
>> would not "tie up all loose ends" ?
>>
>> If, so let me disagree, and try to be a bit more nuanced than
>> categorizing each item as being a "loose end" or not :
>> - Extranet mVPN: this is a requirement of RFC4834, and the mVPN base
>> specs do not document how this can be done, (i.e. can be seen as a
>> "loose end")
>> - Wildcard S-PMSI: there are two aspects to this subject, on the one
>> hand it is an improvement on how S-PMSI bindings are advertised, on the
>> other hand it is a key building block of the "PIM over MS-PMSI"
>> approach
>> you propose  (ie. *not* a "loose end")
>> - mVPN fast-failover: targets improving convergence times for mVPN PE
>> failures (i.e. targets an "improvement")
>> - bidir P-tunnels: although the precise subject may not be fully
>> defined
>> yet, it seems to be (a) can be a possible P-tunnel scaling improvement
>> in the general case but that the base specs may not fully cover (that
>> part is in the gray zone between a "loose end" and an "improvement"),
>> and (b) something at the core the core of the "PIM over MS-PMSI"
>> approach (/that/ part is *not* a "loose end", but totally in the
>> category of what targets an "improvement")
>> - PIM without an MI-PMSI: based on the claims of your draft
>> corresponding to this subject, it seems clear that this proposal
>> targets
>> an "improvement" of the number of P-tunnel states (i.e. not a "loose
>> end")
>>
>> It seems to me that:
>> * fixing "loose ends" should certainly be part of the work the working
>> group should tackle (and as such, it makes sense to make Extranet mVPN
>> a
>> milestone)
>> * we shall not sleep and wait for extensive feedback on all deployment
>> variants to decide to work on improvements; if we do so, we'll be 3 or
>> 5
>> years too late when some operator wants to deploy such an improvements;
>> we should instead anticipate, but "anticipating" does not mean that
>> each
>> proposed/claimed improvement needs to become a milestone, or a standard
>> track working group document, or even become a working group document
>> at
>> all; it does not mean either that these statuses have to be decided all
>> at once today : this can very much be decided on a case by case basis
>> (...this is what is done most of the time in the IETF !!)
>> * if there is a need to make the working group charter more explicit,
>> then we can certainly adopt milestones related to stuff that people
>> seem
>> to agree they are valid subjects (that includes the "Wildcard S-PMSI"
>> idea)
>>
>> Said differently, I think that the milestones in Ben Niven-Jenkins'
>> "Poll to adopt initial milestones for the new L3VPN charter" form a
>> good
>> set of milestones.
>>
>> -Thomas