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

[Thomas Morin <[e-mail]>]

Hi Eric,

Eric Rosen:
>> 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.
>   

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.


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

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