Wildcard bindings for S-PMSIs

[Eric Rosen <erosen at cisco.com>]

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.