Re: Wildcard bindings for S-PMSIs

[Eric Rosen <erosen at cisco.com>]

Yakov> In draft-rekhter a (*, G) wildcard is legal when G is either in the
Yakov> ASM range, or in the Bidir range.

I don't think there is any such thing as "the Bidir range", as Bidir is just
a form  of ASM.  Draft-rekhter  seems to  allow (*,G) when  G is in  the SSM
range, which is what I think is questionable.

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

Let's  not confuse  "saying  something differently"  with "saying  something
different".

In  draft-rosen, the  procedures are  specified  in terms  of the  multicast
states of  the mVRF.  I believe this  results in the same  behavior, but the
applicability is not restricted only to  the case where BGP is used.  That's
one of  the reasons that draft-rekhter is  just a subset of  the "wild card"
specification of draft-rekhter.  

Eric> - The spec in draft-rekhter does not cover the use of wild cards with
Eric> bidirectional P-tunnels.
 
Yakov> This is because according to 6.4.4 of draft-ietf-l3vpn-2547bis-
Yakov> 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."

I don't follow  this line of reasoning; you omitted  an important topic from
one document because that topic is outside the scope of some other document?

Well, let me call your attention to section 4.3 of mcast-bgp-07:

   Usage of other values of  the Multicast Source Length and Multicast Group
   Length fields  [other than 32 for IPv4  and 128 for IPv6]  is outside the
   scope of this document.

So by  your own reasoning, the  entirety of draft-rekhter  should be omitted
;-)

> the wildcard is useful for assigning BIDIR-PIM C-flows
> to S-PMSIs that are instantiated by unidirectional P-tunnels using
> the procedures of section 11.2.

I don't think  the existing specifications are sufficient  to determine just
how this would work.  Perhaps you could say more about this.

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

I can't wait to  see all the new stuff that's going  to be hurriedly stuffed
into the -02 version! ;-)

Could you explain the use case for (C-S, C-*)?  

> Use of the 0/0 prefix encoding  to indicate the "match all semantics" well
> predates draft-rosen.

Good thing I didn't try to file a patent on it ;-) 

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

Absolutely correct.  However, some of the authors took longer than others to
appreciate the usefulness of the wild card specification.

I certainly hope that everyone who's  ever discussed MVPN will not decide to
issue a  new draft that is primarily  a paraphrase of an  existing draft.  I
think the generally accepted procedure  for someone who disagrees with a few
details  of a  draft is  to raise  the issues  on the  mailing list,  not to
pretend that the draft doesn't exist.