[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wildcard bindings for S-PMSIs

Hello,


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.


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.




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.