Re: Wildcard bindings for S-PMSIs

[Yakov Rekhter <yakov at juniper.net>]

Eric,

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

Just for the record, the authors of MVPN and BGP-MVPN specs discussed
the use of wildcards well before you published draft-rosen-l3vpn-mvpn-msmsi.
  
> 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
  
Yes, draft-rekhter specifies only a subset of what is specified in
draft-rosen, as the latter specifies not just the use of wild cards,
but plenty of other stuff as well.

However, if we focus on just the wildcard part of draft-rosen, then
your claim that draft-rekhter "specifies only a subset of what is
specified" in draft-rosen is incorrect. More on this below.
  
> 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-rekhter a (*, G) wildcard is legal when G is either in the
ASM range, or in the Bidir range. Both are useful.
  
> - - 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.  
  
You just provided an example that shows that contrary to your claim,
what is in draft-rekhter is *more* than "only a subset" of what is
in draft-rosen.
  
> - - 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.  
  
Now you provided yet another example that shows that contrary to
your claim, what is in draft-rekhter is *more* than "only a subset"
of what is in draft-rosen.

Yet another example that shows that contrary to your claim, what is
in draft-rekhter is *more* than "only a subset" of what is in
draft-rosen is the ability to bind (C-S, C-G) flows flowing on C-SPT
to a (C-*, C-G) S-PMSI.

Moreover, (C-S, C-*) S-PMSI in the -01 version of the draft is yet
another example that shows that contrary to your claim, what is in
draft-rekhter is *more* than "only a subset" of what is in 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.  
  
So, we agreed on that.
  
>                                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.
  
While you "don't think it would be useful if BIDIR-PIM is supported
using the procedures of section 11.2", I think to the contrary.
Namely that the wildcard is useful for assigninng BIDIR-PIM C-flows
to S-PMSIs that are instantiated by unidirectional P-tunnels using
the procedures of section 11.2.
  
> 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.
  
Your claim about "a subset", as illustrated above, is incorrect.
  
> 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. 
  
Wrt the encoding, both draft-rekhter and draft-rosen rely on the
encoding specified in BGP-MVPN. Both draft-rosen and draft-rekhter
use the 0/0 prefix encoding to indicate the "match all" semantics.  Use
of the 0/0 prefix encoding to indicate the "match all semantics" well
predates draft-rosen.
  
>                          The main difference is that draft-rekhter has a
> much more limited scope:

Your claim that "draft-rekhter has a much more limited scope", is
incorrect, as draft-rekhter covers quite a few cases that are not in
draft-rosen.
  
> - - 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.
 
This is because according to 6.4.4 of draft-ietf-l3vpn-2547bis-mcast-08.txt:

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

> 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.  
  
Wrt "doesn't seem to say anything significantly different", I disagree,
as the text in draft-rekhter is specified in terms of the changes to the
currently specified procedures in BGP-MVPN for handling S-PMSI, while the
text in draft-rosen does *not*.

Yakov.