Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

[Greg Mirsky <[e-mail]>]

Hi Ketan,
thank you for your suggestion. As you've pointed out, the draft in
discussion introduces a new segment type, Replication Segment, to realize
p2mp behavior in an SR domain. Looking into RFC 8402, I find the following
statement regarding multicast:
6.  Multicast

   Segment Routing is defined for unicast.  The application of the
   source-route concept to Multicast is not in the scope of this
   document.

Hence, I believe, is the valid question to where the possible impact of
multicast on the architecture of segment routing should be discussed,
described.
I hope that clarifies what has been the topic of discussion on this thread.

Regards,
Greg

On Sun, Nov 17, 2019 at 12:09 PM Ketan Talaulikar (ketant) <[e-mail]>
wrote:

> Hi Greg/Sasha/All,
>
>
>
> I really wonder whether we are talking about the same document anymore.
> The subject of this thread is
> https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-00
>
>
>
> It is indeed possible that you and others are referring to some other
> document(s)?
>
>
>
> From reading of the draft, one can see that :
>
>    - It does not deal with multicast group joins/receivers or senders
>    - It does not build multicast trees
>    - It does not talk about multicast flows
>    - It simply introduces a new type of segment called Replication
>    Segment (p2mp) for a specific local node forwarding behaviour that is in
>    line with the Spring Charter (see below)
>
>
>
> o New types of segments mapping to forwarding behaviour (e.g., local
> ingress replication, local forwarding resources, a pre-existing
> replication structure) if needed for new usages.
>
>
>
> Can you please take another quick read over the draft with the above
> context in mind? I am positive that you will see that this is not getting
> multicast work in Spring – that is being worked on in other WGs.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* spring <[e-mail]> *On Behalf Of *Greg Mirsky
> *Sent:* 17 November 2019 11:39
> *To:* John E Drake <jdrake=[e-mail]>
> *Cc:* [e-mail]; Alexander Vainshtein <
> [e-mail]>;
> [e-mail]; Robert Raszuk
> <[e-mail]>; <[e-mail]> (
> [e-mail]) <[e-mail]>
> *Subject:* Re: [spring] The SPRING WG has placed
> draft-voyer-spring-sr-replication-segment in state "Candidate for WG
> Adoption"
>
>
>
> 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=
> [e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Wednesday, November 13, 2019 3:55 PM
> *To:* John E Drake <[e-mail]>
> *Cc:* Alexander Vainshtein <[e-mail]>;
> [e-mail];
> [e-mail]; <
> [e-mail]> ([e-mail]) <
> [e-mail]>
> *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 <[e-mail]> 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 <[e-mail]> *On Behalf Of *Alexander
> Vainshtein
> *Sent:* Wednesday, November 13, 2019 9:26 AM
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* spring@ietf..org <[e-mail]>;
> [e-mail]; <
> [e-mail]> ([e-mail]) <
> [e-mail]>
> *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: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Wednesday, November 13, 2019 4:15 PM
> *To:* Alexander Vainshtein <[e-mail]>
> *Cc:* <[e-mail]> ([e-mail]) <
> [e-mail]>;
> [e-mail];
> [e-mail]
> *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 <
> [e-mail]> 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: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> -----Original Message-----
> From: spring <[e-mail]> On Behalf Of IETF Secretariat
> Sent: Tuesday, November 12, 2019 7:06 PM
> To: [e-mail];
> spring-chairs@ietf..org; [e-mail]
> 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
>
> [e-mail]
>
>
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
>