Dear All, I concur with Sasha and John. Intended ingress replication of a particular flow, though using a unicast destination address, is still a multicast.
Regards, Greg On Thu, Nov 14, 2019 at 5:36 AM John E Drake <jdrake= 40juniper....@dmarc.ietf.org> wrote: > Robert, > > As Sasha and I have indicated, your position is your own and is not > consistent with the majority of work on this topic. I’m fine w/ agreeing > to disagree. > > John > > Sent from my iPhone > > On Nov 14, 2019, at 2:57 AM, Robert Raszuk <rob...@raszuk.net> wrote: > > > John, > > > Your claim that ingress replication is not multicast is, at best, a > stretch. > > I use a very basic and simple rule of thumb ... if address of my packet is > a multicast address then it is multicast if not it is unicast. > > Ref: > https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml > <https://urldefense.com/v3/__https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml__;!8WoA6RjC81c!QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ$> > > > Solution as described in draft-voyer-spring-sr-replication-segment does > not seems to be requiring multicast addresses hence it is applicable to > pure unicast networks. > > Thx, > Robert. > > > On Wed, Nov 13, 2019 at 10:20 PM John E Drake <jdr...@juniper.net> wrote: > >> Robert, >> >> >> >> I’m sorry for the confusion. My only point was that MVPN provides the >> reference architecture for dealing w/ multicast using a multiplicity of >> tunnel types in a consistent manner, as Sasha alluded to in his mention of >> PMSI. Your claim that ingress replication is not multicast is, at best, a >> stretch. >> >> >> >> Yours Irrespectively, >> >> >> >> John >> >> >> >> >> >> Juniper Business Use Only >> >> *From:* Robert Raszuk <rob...@raszuk.net> >> *Sent:* Wednesday, November 13, 2019 3:55 PM >> *To:* John E Drake <jdr...@juniper.net> >> *Cc:* Alexander Vainshtein <alexander.vainsht...@ecitele.com>; >> spring@ietf.org; >> draft-voyer-spring-sr-replication-segment.auth...@ietf.org; < >> spring-cha...@tools.ietf.org> (spring-cha...@tools.ietf.org) < >> spring-cha...@tools.ietf.org> >> *Subject:* Re: [spring] The SPRING WG has placed >> draft-voyer-spring-sr-replication-segment in state "Candidate for WG >> Adoption" >> >> >> >> Hi John, >> >> >> >> > Further, ingress replication has been part of MVPN since forever. >> >> >> >> Just curious how is this at all relevant for this discussion ? >> >> >> >> Do I have to roll out MVPN monster to split my unicast UDP stream to few >> receivers at selected network point ? >> >> >> >> And last but not least who said this is at all related to "ingress >> replication" ??? Ingress to p2mp segment can be at any SR midpoint in the >> network. Are you suggesting to run MVPN apparatus with manual tree building >> ? Whow :) >> >> >> >> Thx, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Nov 13, 2019 at 9:40 PM John E Drake <jdr...@juniper.net> wrote: >> >> Hi, >> >> >> >> I think Sasha has a valid point. Further, ingress replication has been >> part of MVPN since forever. >> >> >> >> Yours Irrespectively, >> >> >> >> John >> >> >> >> >> >> Juniper Business Use Only >> >> *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Alexander >> Vainshtein >> *Sent:* Wednesday, November 13, 2019 9:26 AM >> *To:* Robert Raszuk <rob...@raszuk.net> >> *Cc:* spring@ietf.org; >> draft-voyer-spring-sr-replication-segment.auth...@ietf.org; < >> spring-cha...@tools.ietf.org> (spring-cha...@tools.ietf.org) < >> spring-cha...@tools.ietf.org> >> *Subject:* Re: [spring] The SPRING WG has placed >> draft-voyer-spring-sr-replication-segment in state "Candidate for WG >> Adoption" >> >> >> >> Robert, >> >> Lots of thanks for a prompt response. >> >> >> >> You seem to imply that a multicast distribution tree that is built, say, >> by an SDN controller and used, say, to act as a PMSI in the mVPN >> application, is not really a multicast. Personally I disagree, but this is >> a matter of taste and terminology. >> >> >> >> What looks unambiguous to me is that: >> >> - The WG charter explicitly mentions ingress replication as one of >> “new types of segments mapping to forwarding behavior” that “may require >> architectural extensions” >> - The current architecture document does not cover any such segment >> type (whether because such segments have been considered as related to >> multicast by the authors, or for some other reason is not all that >> important. ) >> >> Therefore my concern remains unresolved regardless of whether ingress >> replication is or is not formally considered as multicast. >> >> >> >> Regards, >> >> Sasha >> >> >> >> Office: +972-39266302 >> >> Cell: +972-549266302 >> >> Email: alexander.vainsht...@ecitele.com >> >> >> >> *From:* Robert Raszuk <rob...@raszuk.net> >> *Sent:* Wednesday, November 13, 2019 4:15 PM >> *To:* Alexander Vainshtein <alexander.vainsht...@ecitele.com> >> *Cc:* <spring-cha...@tools.ietf.org> (spring-cha...@tools.ietf.org) < >> spring-cha...@tools.ietf.org>; >> draft-voyer-spring-sr-replication-segment.auth...@ietf.org; >> spring@ietf.org >> *Subject:* Re: [spring] The SPRING WG has placed >> draft-voyer-spring-sr-replication-segment in state "Candidate for WG >> Adoption" >> >> >> >> Sasha, >> >> >> >> If I have some content and I send it to you and your neighbour as two >> unicast streams am I suddenly doing multicast ? >> >> >> >> IMHO N number of replicated unicasts is still not a multicast. >> >> >> >> Multicast in my definition requires multicast groups, receiver joins, >> tree building protocols etc ... and this draft does not suggest any of >> this. IN contrast it just describes how can we have p2mp unicast >> distribution ... call it fan out node. >> >> >> >> Thx, >> R. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Nov 13, 2019 at 12:42 PM Alexander Vainshtein < >> alexander.vainsht...@ecitele.com> wrote: >> >> Hi all, >> >> I have a question regarding adoption of >> draft-voyer-sr-spring-replication-segment as a SPRING WG document. >> >> >> >> These concerns are based on the following: >> >> 1. This draft (both based on its title and on its content) deals >> with local (in the Root node) ingress replication which, in its turn, is >> one of the issues that could be used for delivery of multicast. >> >> 2. Local ingress replication is mentioned in the SPRING WG Charter >> as one of the “New types of segments mapping to forwarding behavior”. >> The charter further says that “Any of the above <*Sasha: New types of >> segments*> may require architectural extensions” >> >> 3. The current (and, AFAIK, the only existing) Segment Routing >> Architecture document (RFC 8402 >> <https://urldefense.com/v3/__https:/clicktime.symantec.com/34qM9QogJnh1eY5nZPXYAkA6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Frfc8402__;JSUlJSU!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUOvwkLSU$>) >> explicitly states in Section 6 that “Segment Routing is defined for >> unicast. The application of the source-route concept to Multicast is not in >> the scope of this document”. >> >> The combinations of observations above strongly suggests to me that a >> document defining multicast-related extensions of segment routing >> architecture should be very useful (if not mandatory) for progressing the >> Replication Segment draft. From my POV the Replication Segment draft is not >> (and is not intended to be) such a document. >> >> >> >> I wonder if there is an intention to produce such a document in the >> timeframe that could be relevant for discussion of the Replication Segment >> draft. >> >> >> >> Nothing in this message should be interpreted as my objection to (or >> support of) adoption of the Replication Segment draft as a WG document *per >> se*. >> >> Bit I find it difficult to take a position any which way without a clear >> and commonly agreed upon framework for multicast in segment routing. >> >> >> >> Regards, >> >> Sasha >> >> >> >> Office: +972-39266302 >> >> Cell: +972-549266302 >> >> Email: alexander.vainsht...@ecitele.com >> >> >> >> -----Original Message----- >> From: spring <spring-boun...@ietf.org> On Behalf Of IETF Secretariat >> Sent: Tuesday, November 12, 2019 7:06 PM >> To: draft-voyer-spring-sr-replication-segm...@ietf.org; >> spring-cha...@ietf..org; spring@ietf.org >> Subject: [spring] The SPRING WG has placed >> draft-voyer-spring-sr-replication-segment in state "Candidate for WG >> Adoption" >> >> >> >> >> >> The SPRING WG has placed draft-voyer-spring-sr-replication-segment in >> state Candidate for WG Adoption (entered by Bruno Decraene) >> >> >> >> The document is available at >> >> >> https://clicktime.symantec.com/3EMJRgfTdX6UyWKGnMPiVwZ6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-spring-sr-replication-segment%2F >> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3EMJRgfTdX6UyWKGnMPiVwZ6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-voyer-spring-sr-replication-segment*2F__;JSUlJSUl!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUHVCWfyU$> >> >> >> >> Comment: >> >> IPR call: >> >> >> https://clicktime.symantec.com/3KG7A2qM3Xf2eqDctGju1e66H2?u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_stJjBM5K6vr7QYw0HRKf-z0_us >> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3KG7A2qM3Xf2eqDctGju1e66H2?u=https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fspring*2F_stJjBM5K6vr7QYw0HRKf-z0_us__;JSUlJSUlJQ!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUfVccUWU$> >> >> >> >> _______________________________________________ >> >> spring mailing list >> >> spring@ietf.org >> >> >> https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUhKjFqCs$> >> >> >> >> ___________________________________________________________________________ >> >> This e-mail message is intended for the recipient only and contains >> information which is >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have >> received this >> transmission in error, please inform us by e-mail, phone or fax, and then >> delete the original >> and all copies thereof. >> >> ___________________________________________________________________________ >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3KSi9HHVnunMDQNLd2U3Sij6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUZIWr6Wk$> >> >> >> >> ___________________________________________________________________________ >> >> This e-mail message is intended for the recipient only and contains >> information which is >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have >> received this >> transmission in error, please inform us by e-mail, phone or fax, and then >> delete the original >> and all copies thereof. >> >> ___________________________________________________________________________ >> >> _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring