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

From: Thomas Morin <[email-masked]>
Date: Tue, 14 Sep 2010 13:22:19 +0200

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

---

From: ycai <[email-masked]>
Date: Fri, 17 Sep 2010 16:31:59 -0700

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.

-- 
Yiqun

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 20 Sep 2010 07:18:40 -0700

Hi,

> that for many of us the reason we are working on them is not to kill time

Agreed. And moreover, inclusuion of these items (as listed in Ben's
email) in the charter should not be conditioned on inclusion of
other items. Specifically, I strongly object Eric's proposal to
couple acceptance of S-PMSI Wildcard and MVPN Extranet with acceptance
of PIM without MI-PMSI and a new document on using Bidir P-Tunnels.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 20 Sep 2010 07:37:48 -0700

Eric,

> > Can you please respond with
> 
> > a) "accept all" or "do not accept all" indicating you are either
> >    happy(/unhappy) with all the milestones.
> 
> > b) yes/accept or no/do not accept on a per milestone basis if you feel we
> >    should adopt some but not all of the milestones.
> 
> > The proposed milestones are:

[clipped...]

> With regard to additional milestones, for which there are as yet no WG
> documents, I think the WG has to decide whether it wants to complete the
> MVPN work, or whether it wants to shut down and wait to see what actually
> gets deployed before it decides what specs are worth working on.
> 
> So I would say that the milestones
> 
> May-11 Submit S-PMSI A-D route Wildcard selection specification to IESG as
>         PS.
> 
> Nov-11 Submit MVPN Extranet specification to IESG as PS.
> 
> should be accepted if, and only if, the milestones
> 
> are also accepted.

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.

Moreover, wrt a new document on using Bidir P-tunnels, before starting
discussion on accepting a new document on using Bidir P-tunnels, you
first need to document what is missing in the current spec wrt using
Bidir P-tunnels.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 20 Sep 2010 07:49:29 -0700

Hi,

> everything.  Maybe I'm being naive. But if we are serious about the role of

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.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 21 Sep 2010 09:13:05 -0400

> absence of MI-PMSI or a new document on using Bidir P-Tunnels.

Given the low level of activity in the WG over the past two years or so, 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 believe we should continue the
current situation where the WG is mostly used for marketing and posturing
rather than for technical discussion.  

> wrt a new document on using Bidir P-tunnels, before starting

Sure, I can answer this in two ways:

1. Please look at draft-rosen-l3vpn-mvpn-bidir-01.txt.  In it you will find
   about 15 pages of material that is absent from the working group
   documents.

2. The WG documents themselves state in multiple places that they do not
   completely specify the use of bidirectional P-tunnels.  I.e., the WG has
   already achieved consensus that further specification is needed.  I call
   you attention to the following passages:

>From draft-ietf-l3vpn-2547bis-mcast-10:

Section 2.2.5 (page 13):

   The specification for aggregating traffic of multiple MVPNs onto a
   single multipoint-to-multipoint LSP or onto a single bidirectional
   multicast distribution tree is outside the scope of this document.

   The specifications for using as selective trees multicast
   distribution trees that support the ASM service model is outside the
   scope of this document.  The specification for using
   multipoint-to-multipoint LSPs as selective trees is outside the scope
   of this document.

Section 3.2.2 (page 17):

       The use of shared trees (including bidirectional trees) to
       instantiate S-PMSIs is outside the scope of this document.

Section 3.2.2 (page 18):

       The use of MP2MP LSPs to instantiate S-PMSIs is outside the scope
       of this document.

       Section 11.2.3 discusses a way of using a partial mesh of MP2MP
       LSPs to instantiate a PMSI.  However, a full specification of the
       necessary procedures is outside the scope of this document.

Section 6.3.3 (page 39)

   A full specification of the procedures to support aggregation on
   shared trees or on MP2MP LSPs is outside the scope of this document.

Section 6.4.2 (page 43)

   Specification of the full set of procedures for using bidirectional
   PIM trees to instantiate S-PMSIs are outside the scope of this
   document.

Section 6.4.4 (page 43)

   Specification of the procedures for assigning C-flows to mLDP MP2MP
   LSPs that serve as P-tunnels is outside the scope of this document.

Section 12.3.1 (page 81)

   A full specification of the procedures for advertising and for using
   the PE Distinguisher Labels in this case is outside the scope of this
   document.

Section 12.3.2 (page 81)

   A full specification of the procedures for advertising PE
   Distinguisher Labels is out of the scope of this document.

Section 12.3.2 (page 82)

   procedures for advertising and using PE Distinguisher Labels when the
   encapsulation is LDP-based MP2P MPLS is outside the scope of this
   specification.

>From draft-ietf-l3vpn-2547bis-mcast-bgp:

Section 5 (page 14)

   The use of mLDP MP2MP LSPs as Provider tunnels (P-tunnels) requires
   procedures which are outside the scope of this document.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 21 Sep 2010 09:40:31 -0400

> rather than for technical discussion.  

Or the WG could just be shut down; if there is new energy later for add-ons, there is a mechanism
for creating new WG.

Regards
Marshall

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 21 Sep 2010 10:03:04 -0400

> Or the WG could just be shut down; if there is new energy later for add-ons, there is a mechanism

	I'd totally agree. This is the same suggestion I made when Ben first published the revised agenda. If there is minimal interest to work on items in this WG, then move the remaining 1 or 2 things to MPLS and shut the WG down. If we do decide to carry on with the WG and this charter, we should rename the working group to "L3 Multicast VPN", since that seems to be all we are working on here for the past 3+ years. *)

	--Tom

---

From: Thomas Morin <[email-masked]>
Date: Wed, 22 Sep 2010 15:59:50 +0200

Hi Eric,

Eric Rosen:
> Thomas Morin:
> [...] I think the real decision to be made is whether the WG really wants to finish
> 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

---

From: Thomas Morin <[email-masked]>
Date: Wed, 22 Sep 2010 16:07:43 +0200

Hi Thomas,

Thomas Nadeau :
> 	I'd totally agree. This is the same suggestion I made when Ben first published the revised agenda. If there is minimal interest to work on items in this WG, then move the remaining 1 or 2 things to MPLS and shut the WG down.

(I'm not sure if the MPLS WG has any room for *any* additional work, but...)
this suggestion you make seems to miss the fact that there are valid 
identified subjects with people working on them and corresponding 
individual drafts published !

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Fri, 24 Sep 2010 17:57:53 +0200

Hi Eric,

On bidir P-tunnels: your replies are so elusive that I'm wondering if 
you really intend to convince people that a new doc would be useful...

>     about 15 pages of material that is absent from the working group

Well, "War and Peace" by Leo Tolstoy also has many pages of material 
that is absent from the working group documents.
Note that noone is arguing that this story is really "missing in the 
current mVPN specs"... ;-)

Obviously, the length of the document is not an argument in itself. To 
support the idea that something is "missing" in the current specs, we 
need to see why this something needed or useful in the context of these 
specs.

Now, looking *in* the document was unfortunately not that helpful for 
me. The problem statement is quite expedited and the rest of the 
document does not make it explicit either where the improvement or need 
is, compared to the *base* specs.

For instance, a large part of the document is about meshes of bidir 
P-tunnels and how to bind them to wildcard S-PMSI: I understand that 
this provide basis for the other "PIM over MS-PMSI" proposal that you 
have, but (a) this goes beyond the base specs, and (b) it is not obvious 
how relevant/useful it is apart from the "PIM over MS-PMSI" approach.

>     completely specify the use of bidirectional P-tunnels.

Yes, and to be exact, for some uses of bidir P-tunnels, the current 
specs do not even imply to provide a *partial* specification.

>   I.e., the WG has already achieved consensus that further specification is needed.

No, because "out of scope" is different than "will be specified in a 
further document".
Sometimes "out of scope" is what it chosen to avoid saying "we don't 
know yet what exactly to do with that".

I'm not saying I'm opposed to anything on bidir P-tunnels, but I think 
that if we want a milestone on this it should be clear what 
requirement/improvement this will address.  As far as I understand, this 
is not the case yet.

-Thomas

---

From: Eric Rosen <[email-masked]>
Date: Fri, 24 Sep 2010 12:47:38 -0400

One of the reasons I think it might be best to shut down the WG is that so
much of the mailing list activity is absolutely ridiculous.  Not to mention
repetitive. I will be brief.

Eric> Please look at draft-rosen-l3vpn-mvpn-bidir-01.txt.  In it you will
Eric> find about 15 pages of material that is absent from the working group
Eric> documents.

Thomas> Well, "War and Peace" by Leo Tolstoy also has many pages of material
Thomas> that is absent from the working group documents.

Sigh.  I guess I should have been more explicit, and said "15 pages of MVPN
control plane and data plane specification".

Thomas> a large part of the document is about meshes of bidir P-tunnels and
Thomas> how to bind them to wildcard S-PMSI

Since we have S-PMSI A-D routes that can be used to bind wildcard selectors
to bidirectional P-tunnels, we should also have the specs that say just what
it means to do so.  Failure to specify the use of various combinations of
options will certainly lead to interoperability problems in the future.

Thomas> "out of scope" is different than "will be specified in a  further
Thomas> document"

The WG documents provide explicit methods for specifying bidirectional
P-tunnels, they contain explicit discussions of the use of bidirectional
P-tunnels (e.g., for handling customer bidir flows), and they explicitly say
that further specifications are needed but are "out of scope" (i.e., not
included) in the WG documents.  Really, I don't know how things could be any
clearer.

Thomas> Sometimes "out of scope" is what it chosen to avoid saying "we don't
Thomas> know yet what exactly to do with that".

In this particular case, saying "out of scope" allowed the documents to be
closed before a consensus on the use of bidirectional P-tunnels was
obtained. Now it's time to work on achieving that consensus.

Thomas> I think that if we want a milestone on this it should be clear what
Thomas> requirement/improvement this will address

See previous messages.

---

From: Thomas Morin <[email-masked]>
Date: Mon, 27 Sep 2010 11:20:33 +0200

Working group, Eric,

Eric Rosen:
> [...] so much of the mailing list activity is absolutely ridiculous.  Not to mention

I will be brief too.

It is not ridiculous to make sure, when a charter milestone is added, 
that we know what question will be solved.

I think the explanations on why a charter item would be needed on "bidir 
P-tunnels" are insufficient: only indirect rationale has been proposed, 
such  as "the base specifications said that it is 'out of scope'" or 
"read this draft" (said draft not being explicit either on the 
motivations).

I think that, before having an item on "bidir P-tunnels", we want 
*explicit* rationale on the improvement it brings or on the requirements 
it addresses. If we don't have this, it means we are just creating the 
basis for misunderstanding and future arguments.

(yes, I find it repetitive to ask, but the answer does not need to be 
repeteadly elusively non-explicit)

Thank you,

-Thomas

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 27 Sep 2010 11:54:06 -0700

Eric,

Let's look at page 5 (section 3.1) of draft-rosen-l3vpn-mvpn-bidir-01.txt:

> 3.1. BIDIR-PIM P-Tunnels
> 
>    A BIDIR-PIM P-tunnel may be advertised in the PTA of an Intra-AS
>    I-PMSI A-D route or in the PTA of an S-PMSI A-D route.

That is already specified.

>    As is the case with other PIM-created P-tunnels, to transmit packets
>    on a BIDIR-PIM P-tunnel, one uses the GRE encapsulation as specified
>    in [MVPN] section 12.

Ditto.

>    Each BIDIR-PIM P-Tunnel is identified by a unique P-group address
>    [MVPN, section 3.1].  (The P-group address is called a "P-Multicast
>    Group" in [MVPN-BGP]).  A BIDIR-PIM P-group address is always
>    associated with a unique "Rendezvous Point Address" (RPA).

Ditto.

>    Every PE that needs to join a particular BIDIR-PIM P-tunnel must be
>    able to determine the RPA that corresponds to the P-tunnel's P-group
>    address.  PIM Join/Prune messages are sent along the path from the PE
>    to the RPA.  Any P routers along that path must also be able to
>    determine the RPA, so that they too can send PIM Join/Prune messages
>    towards the RPA.  The method of mapping a P-group address to an RPA
>    may be static configuration, or some automated means of RPA discovery
>    that is outside the scope of this specification.

This is part of "vanilla" PIM Bidir.

>    If a BIDIR-PIM P-tunnel is to be used, the path from each PE in the
>    tunnel to the RPA MUST consist entirely of point-to-point links.  (On
>    a point-to-point link, there is no ambiguity in determining which
>    router is upstream towards a particular RPA.)

That seems like a restriction on the service provider infrastructure.
In fact, none of the other L3VPN documents impose such a restriction.
  
>    When a BGP A-D route's PTA specifies a BIDIR-PIM P-Tunnel, the PE
>    Distinguisher Labels attribute SHOULD NOT be included; if it is
>    included, it MUST be ignored.

Why ?

>    If a BIDIR-PIM P-Tunnel is being used to instantiate an MI-PMSI for a
>    particular  MVPN, all PEs in that MVPN that send Intra-AS I-PMSI
>    routes MUST identify the same P-tunnel.  The identity of this
>    P-tunnel is known by provisioning.

The "MUST" in the above contradicts the current spec, as the current spec 
(see section 6 of draft-ietf-l3vpn-2547bis-mcast-bgp) said "SHOULD":

   When the type is set to PIM-SM or PIM-Bidir tree, then the P-
   Multicast group element of the Tunnel identifier of the Tunnel
   attribute SHOULD be the same multicast group address for all Intra-AS
   I-PMSI A-D routes for the same MVPN originated by PEs within a given
   AS.  

So, to sum things up this page contains either (a) material that is 
already covered elsewhere, or (b) new and unnecessary restrictions, 
or (c) material that contradicts the current spec.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 27 Sep 2010 12:02:19 -0700

Eric,

>    you attention to the following passages:

Let's look at section 3.2.1 (Partial Mesh of MP2MP LSPs) of
draft-rosen-l3vpn-mvpn-bidir-01.txt:

>    When this method is being used:
> 
>      - Each PE that is participating in the mesh MUST advertise, in the
>        PTA of an S-PMSI A-D route, a MP2MP LSP of which it is the root.
>        (The LSP root address is part of the P-tunnel identifier field
>        carried in the PTA.)  A PE MUST "participate in the mesh" if any
>        of the following conditions holds:
> 
>          * The "Partitioned Sets of PEs" method of supporting C-BIDIR
>            traffic is being used, and the PE's address is the same as
>            the Rendezvous Point Address (RPA) for one or more C-BIDIR
>            groups.

If PE's address is the same as the RPA, that means that the customer
outsourced the RPA/RPL functionality to the SP. In this case the
current specs already specify a solution. Moreover, that solution
does not involve the "partitioned sets of PEs".

It is certainly true that the "partitioned sets of PEs" method in
the scenario where the PE's address is the same as the RPA is absent
from the current specs. But it is absent for a good reason, as the
current specs already specify a solution.

And the WG has not already achieved consensus that we need yet
another method when the customer outsourced the RPA/RPL functionality
to the SP.

Yakov.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 27 Sep 2010 15:40:07 -0400

Yakov, thank you for making substantive comments that are actually based on
the content of the draft.

You have identified three paragraphs that summarize what the current WG docs
say about bidir P-tunnels.  The presence of these paragraphs seems perfectly
appropriate, and does not indicate that the draft contains no new material.

I suppose I can be taken to task for saying that the draft contains 15 pages
of new material, when perhaps only 13 or 14 pages are really new.

The draft does have a paragraph that makes some statements about how the RPA
for a bidir group is known.  That seems appropriate in the context.

>    router is upstream towards a particular RPA.)

Yakov> That seems like a restriction on the service provider infrastructure.

The infrastructure is not restricted, but the support of BIDIR-PIM P-tunnels
is restricted to a certain type of infrastructure.  The purpose of that
restriction is to simplify the procedures that need to be supported, as
BIDIR-PIM becomes more complex when LANs are included in the infrastructure.
The value of this restriction is certainly something the WG could discuss.

Yakov> In fact, none of the other L3VPN documents impose such a restriction.

None of the other documents talk in detail about the use of BIDIR-PIM
P-tunnels.

>    included, it MUST be ignored.

Yakov> Why ?

Per section 5.4, there is no role for PE Distinguisher Labels inside the GRE
header, because the GRE contains an IP source address field.  This is
perhaps a mistake, that's also something the WG could discuss.

>    P-tunnel is known by provisioning.

Yakov> The "MUST" in the above contradicts the current spec,

"updates the current spec", you mean ;-)

Yakov> as the current spec (see section 6 of
Yakov> draft-ietf-l3vpn-2547bis-mcast-bgp) said "SHOULD":

I don't really understand how things are supposed to work if an MI-PMSI is
being used but the PEs don't agree on how to instantiate it.  However, this
point is discussable.

I am happy to further discuss the details of this draft, but perhaps another
thread should be started.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 27 Sep 2010 15:55:36 -0400

Yakov> Let's look at section 3.2.1 (Partial Mesh of MP2MP LSPs) of

>            the Rendezvous Point Address (RPA) for one or more C-BIDIR

Yakov> If PE's address is the same as the RPA, that means that the customer
Yakov> outsourced the RPA/RPL functionality to the SP. In this case the
Yakov> current specs already specify a solution. Moreover, that solution
Yakov> does not involve the "partitioned sets of PEs".

Yes indeed, the quoted passage does not make sense, and is obviously the
result of a cut and paste error for which I must apologize.  Obviously one
does not use the "outsource the RPA/RPL" scheme and the "partitioned sets of
PEs" scheme at the same time.

What the passage should say is:

>            traffic is being used, and the PE's route to the Rendezvous
>            Point Address (RPA) for one or more C-BIDIR groups is via a VRF
>            interface.

Thank you for finding this error.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 27 Sep 2010 13:50:33 -0700

Eric,

>    about 15 pages of material that is absent from the working group
  
Let's continue exploring what new material draft-rosen-l3vpn-mvpn-bidir-01.txt 
brings to the table, and whether this material represents an
improvement over what is already in the current specs...

>From section 3.2.3:

> 3.2.3. Single MP2MP LSP with PE Distinguisher Labels
> 
>    In this method, the MP2MP LSP MUST be advertised in the PTA of an
>    Intra-AS I-PMSI A-D route or an S-PMSI A-D route originated by the
>    root of the LSP.  That route MUST include a "PE Distinguisher Labels"
>    Attribute.  Violation of these conditions MUST cause the route to be
>    ignored.
> 
>    The PE at the root of the LSP MUST use the PE Distinguisher Labels
>    Attribute to bind an upstream-assigned MPLS label to the IP address
>    of each other PE that attaches to the same MVPN (as determined by the
>    RTs of the A-D route).  That is, the PE at the root of the P-tunnel
>    assigns a distinct label to each of the other PEs attaching to the
>    same MVPN. This set of PEs is learned via the reception of Intra-AS
>    I-PMSI A-D routes.
> 
>    When this method is in use, the MP2MP LSP can be used to instantiate
>    an MI-PMSI.  This method can also support the "Partitioned Set of
>    PEs" method discussed in [MVPN] section 11.2 and [CONSID] section
>    3.6.

The current specs makes it very clear that mp2mp LSPs with PE
Distinguisher Labels are applicable only when supporting C-Bidir.
The above text does not say anything on this.

The current specs does not require the root of mp2mp LSP to assign
a distinct label to each of the other PEs. The above text does.

So, the above section does not seem to be an improvement 
over what is already covered by the current specs.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 27 Sep 2010 13:59:38 -0700

Eric,

> options will certainly lead to interoperability problems in the future.

Just because S-PMSI A-D routes can be used to bind wildcard selectors
to bidirection P-tunnels is not a sufficient justification to include
this into the specs. One has to explicitly spell out the improvements 
(as well as possible drawbacks) it would bring to the table.

Yakov.

---

From: Thomas Morin <[email-masked]>
Date: Tue, 28 Sep 2010 09:55:50 +0200

Working group,

> the content of the draft.
[...]
> thread should be started.

Indeed, identifying why a milestone would be wanted on bidir P-tunnels 
and reviewing a draft on the subject, are different discussions.

-Thomas

---

From: Eric Rosen <[email-masked]>
Date: Tue, 28 Sep 2010 11:24:10 -0400

> Distinguisher Labels are applicable only when supporting C-Bidir.

The current specs place no restrictions on the applicability of PE
Distinguisher Labels.

> a distinct label to each of the other PEs.

There are indeed a couple of places in draft-ietf-l3vpn-2547bis-mcast that
specify a proper subset of the PEs in a VPN, and say that a given PE must
assign PE Distinguisher Labels (e.g., sections 6.4.1 and 11.2.2) only to
that subset.  The context there is the use of PE Distinguisher Labels in
P2MP LSPs.  The current specs do not address the details of PE Distinguisher
Labels usage in MP2MP LSPs.

If you are trying to support C-bidir using a single MP2MP LSP with PE
Distinguisher Labels, the root of the LSP must assign a label to each PE
that can be selected by any other PE (in the VPN) as the upstream PE for
some C-RPA.  I don't think there is any way for the PE at the root to know
which of the other PEs fall into this subset.  That is why I proposed that
it assign a label to all the other PEs in the VPN.  When the P-tunnels are
unidirectional, the situation is a bit different, as only the PE at the root
can transmit on it; in that case it only has to know what PEs it may itself
select as the upstream PEs for the C-RPAs.  That's the reason for the
difference.  

> this into the specs.

It's going to be somewhat difficult to ensure interoperability if there are
perfectly legal and valid control messages whose interpretation is not fully
specified.    

> One has to explicitly spell out the improvements 

I certainly disagree with this.  In general, the WG has taken the stance
that it's up to each SP to decide on the sort of multicast infrastructure it
has to have (i.e., what sort of P-tunnels to use).  The specs should make it
clear how MVPN will work over whatever infrastructure the SP may decide to
use.  I do not think it is in the charter of this WG to do a comparison of
different multicast infrastructures, or to tell SPs which multicast
infrastructures to use.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 28 Sep 2010 11:27:12 -0700

Eric,

> The current specs place no restrictions on the applicability of PE

The architecture spec describes the use of PE Distinguisher Labels
in section 11.2.2. 11.2.2 is part of section 11. And the title
of section 11 is "11. Support for PIM-BIDIR C-Groups".

> Labels usage in MP2MP LSPs.

Disagree. The current specs does address the details of PE Distinguisher
Labels usage in sufficient level of details.

> which of the other PEs fall into this subset.  

There is a way for that PE to know this - just look at the (unicast)
VPN-IP routes to C-RPA. Only the PEs that advertise such routes
need to have Distinguisher Labels.

> That is why I proposed that

Yakov.

---

From: "NAPIERALA, MARIA H (ATTLABS)" <[email-masked]>
Date: Wed, 29 Sep 2010 08:02:34 -0400

Thomas,
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”. 
In addition, there is no technical reason to develop, for example, Extranet or Wildcard documents but not to develop PIM without MI-PMSI or bidirectional P-tunnels documents.
We should be solving the real needs of Service Providers. I have responded as such already to Ben’s poll. 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”.

Maria

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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:

---

From: Thomas Morin <[email-masked]>
Date: Wed, 29 Sep 2010 15:36:58 +0200

Hello Maria,

> 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…

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