[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Wildcard bindings for S-PMSIs
I agree with this assessment. The wildcard encoding in
draft-rekhter-mvpn-wildcard-spmsi is identical to that already defined
in draft-rosen-l3vpn-mvpn-mspmsi, along with its most significant usage.
Also, it is not necessary to restrict the usage of the wildcard bindings
for S-PMSIs to BGP-only MVPN signaling, which is what
draft-rekhter-mvpn-wildcard-spmsi does, quote: "The procedures specified
in this document assume that BGP is used for transmission of MVPN
customers' routing information within the service provider(s)
infrastructure."
The draft-rosen-l3vpn-mvpn-mspmsi does not impose such a restriction.
It is very confusing for network operators if multiple drafts exist that
define the same functionality in exactly the same way. This does not
promote the interoperability of the same functionality between router
vendors.
Maria
> -----Original Message-----
> From: l3vpn-bounces at ietf.org [mailto:l3vpn-bounces at ietf.org] On Behalf
> Of Eric Rosen
> Sent: Thursday, July 23, 2009 11:21 AM
> To: l3vpn at ietf.org
> Subject: Wildcard bindings for S-PMSIs
>
> I have read draft-rekhter-mvpn-wildcard-spmsi-00.txt with interest. I
> am
> glad to see others in the WG show interest in the use of "wild cards",
> as
> this capability has been documented for quite some time in
> draft-rosen-l3vpn-mvpn-mspmsi, sections 4, 5, and 6.
>
> Mostly draft-rekhter is compatible with draft-rosen, though the former
> specifies only a subset of what is specified in the latter. There are
> a
> couple of substantive, though minor, differences which should be
> discussed
> by the WG.
>
> - In draft-rosen, a (*,G) wild card is only legal when G is in the ASM
> group
> address range. In draft-rekhter, this restriction is not imposed,
>
> My thinking here is that if G is not an ASM group, there is no real
> use
> for (*,G) and its appearance is most likely an error. However, if
> anyone
> knows of a practical application for (*,G) wild card when G is an
SSM
> group, it would be interesting to learn of it.
>
> - In draft-rosen, procedures are defined for using the (*,*) wild card
> only
> when the S-PMSI is instantiated by a bidirectional P-tunnel. In
> draft-rekhter, the (*,*) wild card is allowed when the S-PMSI is
> instantiated by a unidirectional P-tunnel.
>
> On reflection, this does seem like it could be useful, especially if
> there is no I-PMSI and one is using a BGP control plane.
>
> - In draft-rekhter, it is suggested (though not stated explicitly)
that
> the
> wild cards are useful for assigning BIDIR-PIM C-flows to S-PMSIs
that
> are
> instantiated by unidirectional P-tunnels. This is omitted from
> draft-rosen. Perhaps the use of wild cards in this manner may be
> useful
> if BIDIR-PIM is supported using the procedures of section 11.1 of
> draft-
> ietf-l3vpn-2547bis-mcast-08. I don't think it would be useful if
> BIDIR-PIM is supported using the procedures of section 11.2 of
draft-
> ietf-
> l3vpn-2547bis-mcast-08. This needs to be clarified.
>
> These are good points to discuss, but generally if one publishes a
> draft
> that is largely a subset of an existing draft, one is expected at
least
> to
> reference the existing draft, to point out the differences, and to
> explain
> why a new draft might be needed.
>
> I don't see any other substantive differences, or indeed any major
> disagreement. Draft-rehkter has copied the encoding for the S-PMSI
A-D
> routes from draft-rosen. The main difference is that draft-rekhter
has
> a
> much more limited scope:
>
> - The spec in draft-rekhter only covers the case where BGP is the
PE-PE
> control plane, while the spec in draft-rosen covers both that case
> and the
> case where PIM is the PE-PE control plane. (And for the case where
> PIM is
> the PE-PE control plane, also covers the use of the S-PMSI Join
> messages.)
>
> - The spec in draft-rekhter does not cover the use of wild cards with
> bidirectional P-tunnels.
>
> The text in draft-rekhter that justifies the use of wild cards is not
> cut-and-pasted from draft-rosen, but doesn't seem to say anything
> significantly different.
>
>
>