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

[Greg Mirsky <[e-mail]>]

Hi Jeffrey,
thank you for your kind consideration of my comments and
thoughtfully addressing them. The updates did the job for me, thank you.
You may consider just provide the reference leaving "out of the scope" out
like:
OLD TEXT:
   The latter is outside the scope of
   this document but specified in [I-D.voyer-pim-sr-p2mp-policy].
NEW TEXT:
   The latter is specified in [I-D.voyer-pim-sr-p2mp-policy].
Obviously, this is a purely editorial comment.

Regards,
Greg

On Wed, Nov 20, 2019 at 4:26 AM Jeffrey (Zhaohui) Zhang <[e-mail]>
wrote:

> Hi Sasha, all,
>
>
>
> We posted -01 revision:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-voyer-spring-sr-replication-segment-01__;!8WoA6RjC81c!TX4tn3fMRIetXZFyREiqmjUai215tIQtO_j3c6ZmDwVmYj6QUpqfJYuIb3lwkfbk$
> <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-voyer-spring-sr-replication-segment-01__;!8WoA6RjC81c!TX4tn3fMRIetXZFyREiqmjUai215tIQtO_j3c6ZmDwVmYj6QUpqfJYuIb3lwkfbk$>
> .
>
>
>
> Hopefully this addresses the comments raised in this thread.
>
>
>
> Thanks for all your input and suggestions to make the document better.
>
>
>
> Jeffrey
>
>
>
> *From:* Alexander Vainshtein <[e-mail]>
> *Sent:* Monday, November 18, 2019 10:03 PM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* John E Drake <jdrake=[e-mail]>; [e-mail];
> [e-mail]; Robert Raszuk
> <[e-mail]>; <[e-mail]> (
> [e-mail]) <[e-mail]>; Ketan
> Talaulikar (ketant) <[e-mail]>; Greg Mirsky <[e-mail]
> >
> *Subject:* Re: [spring] The SPRING WG has placed
> draft-voyer-spring-sr-replication-segment in state "Candidate for WG
> Adoption"
>
>
>
> Jeffrey,
>
> Lots of thanks for a prompt response and my sincere apologies for the
> delayed response.
>
>
>
> Your latest answers indicate that we are converging. I believe that once
> these changes are done, the document would indeed provide the architectural
> extensions I had in mind for this kind of segments.
>
>
>
> Personally I would prefer these changes to appear before WG adoption, but
> this is for the WG to decide.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nZKz-U1v$>
>
>
> ------------------------------
>
> *From:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Sent:* Monday, November 18, 2019, 11:42
> *To:* Alexander Vainshtein
> *Cc:* John E Drake; [e-mail];
> [e-mail]; Robert
> Raszuk; <[e-mail]> ([e-mail]);
> Ketan Talaulikar (ketant); Greg Mirsky
> *Subject:* RE: [spring] The SPRING WG has placed
> draft-voyer-spring-sr-replication-segment in state "Candidate for WG
> Adoption"
>
>
>
> Hi Sasha,
>
>
>
> Please see zzh2> below.
>
>
>
> *From:* Alexander Vainshtein <[e-mail]>
> *Sent:* Monday, November 18, 2019 1:17 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* John E Drake <jdrake=[e-mail]>; [e-mail];
> [e-mail]; Robert Raszuk
> <[e-mail]>; <[e-mail]> (
> [e-mail]) <[e-mail]>; Ketan
> Talaulikar (ketant) <[e-mail]>; Greg Mirsky <[e-mail]
> >
> *Subject:* RE: [spring] The SPRING WG has placed
> draft-voyer-spring-sr-replication-segment in state "Candidate for WG
> Adoption"
>
>
>
> Jeffrey,
>
> Lots of thanks for a detailed response.
>
> You response seems to indicate that the Replication Segment draft defines
> the architectural extensions associated with the new type of segment. If
> so, it does not, from my POV,  introduce them as such in a sufficiently
> clear and unambiguous way.
>
>
>
> Zzh2> We certainly do want to improve the document, with the input and
> help from the WG, and you’re helping us already with your comments and
> questions. Thank you 😊
>
>
>
> Please see also some specific comments *inline below*.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Sent:* Sunday, November 17, 2019 10:04 PM
> *To:* Alexander Vainshtein <[e-mail]>; Greg
> Mirsky <[e-mail]>; Ketan Talaulikar (ketant) <
> [e-mail]>
> *Cc:* John E Drake <jdrake=[e-mail]>; [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"
>
>
>
> Hi Sasha,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Alexander Vainshtein <[e-mail]>
> *Sent:* Sunday, November 17, 2019 11:25 AM
> *To:* Greg Mirsky <[e-mail]>; Ketan Talaulikar (ketant) <
> [e-mail]>
> *Cc:* John E Drake <jdrake=[e-mail]>; [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 colleagues,
>
> I would like to clarify why, from my POV, the Replication Segment
> introduces in this draft requires extensions to SR Architecture as defined
> in RFC 8402.
>
>
>
> 1. RFC 8402 states that segments can be global (to an SR Dimain) or local
> (to a single node that instantiates it), and all segments defined in this
> document fall into one of these categories. But Replication Segment is
> neither local nor global: it is instanciated in the Root node and may be
> instanciated also in the Downstream nodes - but not anywhere else in the SR
> domain.
>
>
>
> Zzh> It is intended for instantiation on any node of a replication tree –
> root, leaves, and intermediate replication nodes.
>
> *[[Sasha]] Sorry, but I do not see that in the draft. The text in Section
> 2 says:*
>
> *<quote>*
>
> Replication segment is instantiated at Downstream
>
> nodes and at the Replication node.
>
> *<end quote>*
>
> *I admit that the draft uses the term “Replication Node” and not Root
> node. But, to the best of my understanding, it does not ever mention “*intermediate
> replication nodes*”. *
>
>
>
> *Zzh2> A root could be a “Replication node” as well. We will make it more
> explicit that the replication node can be the root and “intermediate
> replication nodes”.*
>
>
>
> *And in any case segments that are instantiated at some, but not all nodes
> of the SR domain is something that the current SR architecture does not
> cover. *
>
>
>
> Zzh2> This is an extension though. Besides, even with existing unicast SR,
> some segments do not need to be instantiated on all nodes (as long as they
> can be reached via some SR paths (“tunnels”) over those nodes not
> instantiating the segments), right?
>
>
>
> 2. RFC 8402 defines 3 operations on the active segment that a node can
> perform: PUSH, NEXT and CONTINUE. But the operation that is performed by
> the Root node on the Replication Segment is neither. What's more, it is not
> even clear to me which operation is performed on this segment by the Root
> node for each replica of the original packet.
>
>
>
> Zzh> On the intermediate replication node*[[Sasha]] Please see above* , a
> CONTINUE or NEXT *[[Sasha]] From my POV this requires some clarification.
> E.g., how does the Replication node differentiate between these two
> possibilities? Can the same Replication Segment be associated with CONTINUE
> on some branches and with NEXT on some other ones? Can a Replication
> Segment appear in the list of SIDs to which a Downstream Node is expanded?.
>  *is done on each replicated copy (if the node itself is both a
> replication node and a leaf node (some people call that a bud node), then
> NEXT is done on one of the copies)
>
> *Zzh2> The replication segment includes a “replication state”:*
>
>
>
> *   Replication state is a list of Replication branches to the Downstream*
>
> *   nodes.*
>
> *Zzh2> The intention is that one of the branches will be for this “local
> leaf” node (with NEXT operation) and other branches will be for downstream
> nodes (with CONTINUE operation). I admit that the text is not explicit
> about that and needs to be improved.*
>
>
>
> *[[Sasha]] Don’t you think that the bud node deserves more explanation in
> the draft?*
>
> Zzh2> Sure we can do that.
>
>
>
> Zzh> On the root node, a PUSH is done on each replicated copy. On the leaf
> node, a NEXT is done.
>
> *[[Sasha]] If PUSH is done on each replicated copy, then the Replication
> Segment will be instantiated in each Downstream Node. But the draft does
> not say that this is always so IMHO.*
>
> Zzh2> We will make it explicit.
>
>
>
> Zzh> The replication-segment draft does not currently explicitly use those
> terms but I see we can/should add them.
>
> *[[Sasha]] As I have said already, if the draft introduces extensions to
> the SR architecture as defined in RFC 8402, it SHOULD build on it
> explicitly. *
>
> Zzh2> I had agreed that this needs to be explicitly added 😊
>
>
>
> As Ketan has noted, the SPRING WG Charter states that the WG can define "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".
>
>
>
> And goes on saying that this "may require architectural extensions". Which
> is exactly what I have been looking for - regardless of whether Replication
> Segment is or is not related to multicast.
>
>
>
> Zzh> The replication segment draft is intended for architecture extensions
> so that replication/multicast can be achieved, but it only focuses on the
> basic building block (replication segment).
>
> *[[Sasha]] This is exactly my problem with the draft: it introduces a new
> notion that is out of scope of the current SR architecture, but does not
> explicitly deal with the required architectural extensions. This makes it
> very difficult to me to reach a clear position with regard to this draft.
> Architecture extensions can be done in this draft, or in another document,
> but they should be done explicitly IMHO. *
>
> Zzh2> Not specifying with CONTINUE/PUSH/NEXT is an oversight/mistake that
> will be corrected.
>
> Zzh2> Thanks!
>
> Zzh2> Jeffrey
>
>
>
> Zzh> Thanks.
>
> Zzh> Jeffrey
>
>
>
> What, if anything, did I miss?
>
>
>
> Regards,
>
> Sasha
>
>
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3HZ94Phv2QhbtXoreQVTC9B6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3DMZgKRcy5iz8AKBGXy2vYx6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Faka.ms*2A2Fghei36__*2A3B*2A218WoA6RjC81c*2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEi4RbBA*2A24__*3BJSUlJSUlJSUlJSUl*218WoA6RjC81c*21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHkEWy2zY*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nSzmE3hb$>
>
>
> ------------------------------
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Sunday, November 17, 2019, 07:14
> *To:* Ketan Talaulikar (ketant)
> *Cc:* John E Drake; [e-mail]; Alexander Vainshtein;
> [e-mail]; Robert
> Raszuk; <[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 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
> <https://urldefense.com/v3/__https:/clicktime.symantec.com/3Rcp2jcNWQ9SLG9T2yC6JLg6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3KY7RjLZXLr1rkewXkXxck56H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fclicktime.symantec.com*2A2F3AvJoi4kZMCSL1EhyDMKMh36H2*2A3Fu*2A3Dhttps*2A2A3A*2A2A2F*2A2A2Ftools.ietf.org*2A2A2Fhtml*2A2A2Fdraft-voyer-spring-sr-replication-segment-00__*2A3BJSUlJSU*2A218WoA6RjC81c*2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOz05MDt*2A24__*3BJSUlJSUlJSUlJSUlJSUlJSUlJQ*218WoA6RjC81c*21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHmiqR2CG*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nWBUKuOu$>
>
>
>
> 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:/clicktime.symantec.com/37J7RuunsmPAvjiocyn4xJP6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3FyMakEGDw4BoNAsgMaGjoa6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fclicktime.symantec.com*2A2F3De6CReeZywpiq7GCkqUmyN6H2*2A3Fu*2A3Dhttps*2A2A3A*2A2A2F*2A2A2Furldefense.com*2A2A2Fv3*2A2A2F__https*2A2A3A*2A2A2Fwww.iana.org*2A2A2Fassignments*2A2A2Fmulticast-addresses*2A2A2Fmulticast-addresses.xhtml__*2A2A3B*2A2A218WoA6RjC81c*2A2A21QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ*2A2A24__*2A3BJSUlJSUlJSUlJSUlJSU*2A218WoA6RjC81c*2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOQHQk7P*2A24__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ*218WoA6RjC81c*21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHrLSrcU0*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nUVodfvQ$>
>
>
>
>
> 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://clicktime.symantec.com/3WS35oFMNStFx2sdM7dKvFr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3N81UkhX23XoNwsjuzVd3zR6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3RCcYJTQUoix9rL8CmszPQ16H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F34qM9QogJnh1eY5nZPXYAkA6H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Ftools.ietf.org%2A2A2A2Fhtml%2A2A2A2Frfc8402__%2A2A3BJSUlJSU%2A2A218WoA6RjC81c%2A2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUOvwkLSU%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJQ%2A218WoA6RjC81c%2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HCjtMYud%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl%218WoA6RjC81c%21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHuHPlt49%24>)
> 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://clicktime.symantec.com/3P7Zn9CnpCik7JCchYzNWa6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3DuXuB4dDSakmFezxqptsdT6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F35c32GQPzeBU6WDDFaDNg3R6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F3EMJRgfTdX6UyWKGnMPiVwZ6H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Fdatatracker.ietf.org%2A2A2A2Fdoc%2A2A2A2Fdraft-voyer-spring-sr-replication-segment%2A2A2A2F__%2A2A3BJSUlJSUl%2A2A218WoA6RjC81c%2A2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUHVCWfyU%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJSU%2A218WoA6RjC81c%2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HPAf8tqe%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%218WoA6RjC81c%21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHi7osh4b%24>
>
>
>
> Comment:
>
> IPR call:
>
>
> https://clicktime.symantec.com/3KG7A2qM3Xf2eqDctGju1e66H2?u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_stJjBM5K6vr7QYw0HRKf-z0_us
> <https://clicktime.symantec.com/3Jes4LqrZVHwvsj1YU5vJK46H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3H2BHZnEFX386Kd1WLrwWdu6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F327SVFAhGtwEJZy7ns9pJN16H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F3KG7A2qM3Xf2eqDctGju1e66H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Fmailarchive.ietf.org%2A2A2A2Farch%2A2A2A2Fmsg%2A2A2A2Fspring%2A2A2A2F_stJjBM5K6vr7QYw0HRKf-z0_us__%2A2A3BJSUlJSUlJQ%2A2A218WoA6RjC81c%2A2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUfVccUWU%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl%2A218WoA6RjC81c%2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEOgBqq0%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU%218WoA6RjC81c%21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHrA7AgaY%24>
>
>
>
> _______________________________________________
>
> spring mailing list
>
> [e-mail]
>
>
> https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> <https://clicktime.symantec.com/36ZswpVvTe644pzGZkzaLfA6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F37GEaAYiYHcmqR1PWa26db66H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3UtBbCsdVBPwVthRzL1jB8u6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F3AtNGCKcyM5uigFH55oARZ86H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Fwww.ietf.org%2A2A2A2Fmailman%2A2A2A2Flistinfo%2A2A2A2Fspring__%2A2A3BJSUlJSUl%2A2A218WoA6RjC81c%2A2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUhKjFqCs%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJSU%2A218WoA6RjC81c%2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HMOgrGEQ%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%218WoA6RjC81c%21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHgJhY156%24>
>
>
> ___________________________________________________________________________
>
> 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://clicktime.symantec.com/3DZZM5X8XKCuot2w48BtGGt6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3GPbeSEHLNv95j2PUuMWiWK6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3QEWS5DMsSm3TeWhdvxL5op6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F3KSi9HHVnunMDQNLd2U3Sij6H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Fwww.ietf.org%2A2A2A2Fmailman%2A2A2A2Flistinfo%2A2A2A2Fspring__%2A2A3BJSUlJSUl%2A2A218WoA6RjC81c%2A2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUZIWr6Wk%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJSU%2A218WoA6RjC81c%2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HGNAFyXn%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%218WoA6RjC81c%21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHigHV9i2%24>
>
>
> ___________________________________________________________________________
>
> 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/3D5PYyStWgHPHQo5jdwCtjb6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3sBzygqGpymg8hapXD7DPL6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fclicktime.symantec.com*2A2F3PbPdEjZDSp26Px1FhZU7Wk6H2*2A3Fu*2A3Dhttps*2A2A3A*2A2A2F*2A2A2Fwww.ietf.org*2A2A2Fmailman*2A2A2Flistinfo*2A2A2Fspring__*2A3BJSUlJSUl*2A218WoA6RjC81c*2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HKEOvPpz*2A24__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU*218WoA6RjC81c*21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHs6hrev2*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nYsJx52x$>
>
>
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
>
>
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
>