Subject: draft-rosen-l3vpn-mvpn-spmsi-joins-00.txt

From: Eric Rosen <[email-masked]>
Date: Fri, 16 Apr 2010 09:34:11 -0400

At the L3VPN WG meeting in Anaheim, I proposed that the WG adopt the draft
draft-rosen-l3vpn-mvpn-spmsi-joins-00.txt as a WG document.

This draft addresses three areas:

1. Using S-PMSI Join messages to advertise GRE/IPv6 P-tunnels.

2. Sending PE-PE PIM/IPv6 messages through IPv4 P-tunnels.

3. Using S-PMSI Join messages to advertise mLDP P-tunnels.

During the IESG evaluation of draft-ietf-l3vpn-2547bis-mcast, one of the ADs
raised a DISCUSS against the fact that the draft did not have a complete
specification of how to support IPv6 using the PIM control plane, especially
with the S-PMSI Join messages.  In order to get him to lift the DISCUSS, the
editors of the draft promised to provide the missing details in a follow-on
draft.  This is covered in items 1 and 2 above, and I don't think there
should be any controversy about this part.  

In Anaheim, Rahul objected to item 3 above.  The grounds for his objection,
I think, are that this is not one of the items promised to the IESG, and it
would be better to require that any SP who wants MPLS multicast P-tunnels
should first have to deploy BGP S-PMSI A-D routes.

If this is the consensus of the WG, item 3 can be removed from the draft.
However, I think that is problematic, for the following reasons:

a. Even though I agree that the BGP S-PMSI A-D routes have some technical
   advantages over the UDP-based S-PMSI Joins, the S-PMSI Joins are useful
   (at least in the short term), as they provide an easy mechanism allowing
   a SP with an existing MVPN deployment to migrate to MPLS P-tunnels
   without first having to deploy the BGP A-D routes.

b. RFC 4834 ("Requirements for Multicast in Layer 3 Provider-Provisioned
   Virtual Private Networks (PPVPNs)" says explicitly that "the control
   plane SHALL NOT depend on which forwarding plane is used".   This
   requirement does not seem compatible with a WG decision to make the
   S-PMSI Join mechanism illegal when MPLS is used for forwarding!

c. If S-PMSI Join messages are going to be deployed with MPLS tunnels
   anyway, it is best for the code points to be properly and publicly
   allocated, assigned, and recorded.

Perhaps the best thing is to ask the WG to choose from among the following
three options:

- Accept the draft

- Accept the draft only if section 3.1 is removed

- Do not accept the draft at all.  (Though this would presumably require
  some alternative strategy that would allow the editors of
  draft-ietf-l3vpn-2547bis-mcast to keep their promise to the IESG.)

---

From: Thomas Morin <[email-masked]>
Date: Tue, 27 Apr 2010 17:09:13 +0200

Eric,

>    S-PMSI Join mechanism illegal when MPLS is used for forwarding!

RFC4834, as the input for building a standard multicast VPN solution
(not two!), should not be interpreted by abusing the fact that
draft-ietf-2547bis-mcast did not select between two alternative
mechanisms for S-PMSI signalling.  Note also that
draft-ietf-2547bis-mcast and draft-ietf-l3vpn-mvpn-considerations
together do provide a specification of a standard with a control plane
that can be used independently of the forwarding plane that is used.

-Thomas

---

From: Eric Rosen <[email-masked]>
Date: Tue, 27 Apr 2010 12:11:18 -0400

> Note also that draft-ietf-2547bis-mcast and
> draft-ietf-l3vpn-mvpn-considerations together do provide a specification
> of a standard

Please note that "considerations" is not a standards track document, and
hence is not part of the standard.  Additionally, since it is not part of
the WG charter, it cannot be used to prevent the WG from considering
proposals on their merits.  

> with a control plane that can be used independently of the forwarding
> plane that is used.

I believe that RFC 4384 requires that any standard control plane be usable
with any standard forwarding plane technology, so I think it does require
that the UDP-based S-PMSI signaling be usable with MPLS forwarding.

I do agree that the BGP S-PMSI A-D route mechanism has advantages, and we
are likely to see the industry migrate in this direction.  But as a
practical matter, failure to officially publish the code points for the
UDP-based S-PMSI Join extensions is not going to speed up that migration.

On the IPv6 issue, if the WG decides it does not want to honor the promise
made to the IESG to do the IPv6 extensions, then the WG should really
request that draft-ietf-2547bis-mcast be removed from the RFC Editors' queue
and returned to IETF last call status.  Then we can add another year of
delay while we argue with the IESG about IPv6 support.  But I find it
difficult to see how such a step would help the industry.

---

From: Thomas Morin <[email-masked]>
Date: Wed, 28 Apr 2010 10:13:23 +0200

Hi Eric,

Eric Rosen:
> hence is not part of the standard.
>   

Whether you like it or not, as any RFC coming from the work of an IETF
working group,  draft-ietf-l3vpn-mvpn-considerations is part of the IETF
process.  And this document's role is explicitly formulated as
addressing what misses from draft-ietf-2547bis-mcast to define a
specification allowing interoperability, i.e. a standard.

You insist on the IPv6 promise made during IESG review. Let me note that
the publication of draft-ietf-l3vpn-mvpn-considerations was *also* key
to have draft-ietf-2547bis-mcast get through IESG.

> that the UDP-based S-PMSI signaling be usable with MPLS forwarding.

Let me note that RFC4384 is Informational. Hence, I notice we seem to
agree on one point : that the content of an Informational RFC is
important to drive the work of an IETF working group.

Now, the intent of RFC4384 was to suggest that a control plane design
tied too closely to a specific P-tunnel type was a bad idea.   It is
abusive to try to use this argument to justify extending the UDP-based
signaling, which, even hypothetically extended to mLDP-based MPLS
P-tunnels, would still have the drawback of being designed for
leaf-initiated P-tunnels only.

-Thomas

---

From: Eric Rosen <[email-masked]>
Date: Wed, 28 Apr 2010 09:39:42 -0400

> a control plane design tied too closely to a specific P-tunnel type was a
> bad idea.

Exactly.  That's why it doesn't make any sense to say that the use of S-PMSI
Joins should be tied to the use PIM/GRE tunnels.  

> even hypothetically extended to mLDP-based MPLS P-tunnels, would still
> have the drawback of being designed for leaf-initiated P-tunnels only.

I don't know why you say that, it's easily extended to RSVP-TE P-tunnels.     

> draft-ietf-l3vpn-mvpn-considerations is part of the IETF process.

It is not a standards track document, and therefore is not part of any IETF
standard.  You should not refer to it as part of a standard.  

Even so, I'm not suggesting that anyone should fail to implement the BGP A-D
mechanisms, just pointing out that an SP should be able to migrate its data
plane to MPLS independently of migrating its MVPN control plane to BGP.
This will happen no matter what the IETF says, the only question is whether
the formats and codepoints used to do it are archived as RFCs.

While it is true, as Yakov says, that the IETF is under no obligation to
standardize everything that service providers want, it's generally a good
thing to standardize things that are useful to SPs, and one would expect
MPLS-oriented WG like this one to help make it easy to migrate to MPLS
multicast!  But then I think that the value add of the IETF is the
production of public, reviewed, interoperable standard; it's not the IETF's
job to tell SPs what to deploy, or how to build their networks.

> to have draft-ietf-2547bis-mcast get through IESG.

I don't happen to believe that, but if we grant this point for the sake of
argument, I think it's fair to say that what interests the IESG here is the
creation of a  "mandatory to implement" status for some features, not a
"mandatory to not implement"!  I don't think the spmsi-joins draft will have
any trouble making it through IESG review.