Subject: Wildcard bindings for S-PMSIs

From: Eric Rosen <[email-masked]>
Date: Thu, 23 Jul 2009 11:21:15 -0400

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.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Thu, 23 Jul 2009 16:48:04 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eric Rosen
> Sent: Thursday, July 23, 2009 11:21 AM
> To: [email-masked]
> Subject: Wildcard bindings for S-PMSIs
> 
> - 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
>   BIDIR-PIM is supported using the procedures of section 11.2 of
draft-
> ietf-
> that is largely a subset of an existing draft, one is expected at
least
> to
> routes from draft-rosen.  The main difference is that draft-rekhter
has
> a

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 28 Jul 2009 22:51:00 -0700

Eric,

> 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.
  
> 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.
  
> - - In draft-rosen, a (*,G) wild card is only legal when G is in the ASM group
  
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
  
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
>   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
>   ietf-l3vpn-2547bis-mcast-08.  
  
So, we agreed on that.
  
>                                I don't think it would be useful if
  
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.
  
> why a new draft might be needed.
  
Your claim about "a subset", as illustrated above, is incorrect.
  
> 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
> - - 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.

> cut-and-pasted from draft-rosen, but doesn't seem to say anything
  
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.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 31 Jul 2009 14:47:12 -0400

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

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

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

---

From: [email-masked]
Date: Fri, 31 Jul 2009 16:25:45 -0400

Hello,

> pretend that the draft doesn't exist.

Extremely well said.

In fact it is clear that unlike it was alluded to me by Area Director  
this week there are no personal issues ... it is Juniper Networks  
which tries to continue to ride on other's ideas, fit it to their  
needs/internal politics and issue a new drafts which are just a subset  
of already existing drafts and what it worse claim that those are  
novel. This practice seems to become a standard between various IETF  
WGs.

In this particular topic a correct comment of Ice during an L3VPN WG  
meeting to at least make a comparison of existing draft-rosen to  
draft-rekhter was said to be a "moot point" by Rahul and "not needed"  
by Yakov. I for that matter agree 100% with comments made by Ice that  
such comparison should be made to this WG before proceeding any further.

And Yakov's reply on the list to the posted questions few hours before  
the WG meeting just not to give Eric a chance to comment is IMHO just  
bad taste (to say at least). It is unfortunate, but so easy to observe.

Such practice of Juniper Networks is unfortunately not unique to L3VPN  
WG. The IDR WG just heard the same issue where proposal has been made  
to define a subset of already proposed RFC (RT-Constrain) in the form  
of RT-Constrain-Lite which in fact does contradicts with the original  
RFC.

There are more examples but I will not mention them at this point.

I do hope that mvpn and L3VPN will have a chance to work on real  
practical solution which would provide some real benefit to service  
providers rather then trying to fit the believes of single vendor view  
and their internal political goals.

Cheers,
R.