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

From: IETF Secretariat <[email-masked]>
Date: Tue, 12 Nov 2019 09:06:08 -0800

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://datatracker.ietf.org/doc/draft-voyer-spring-sr-replication-segment/

Comment:
IPR call:
https://mailarchive.ietf.org/arch/msg/spring/_stJjBM5K6vr7QYw0HRKf-z0_us

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 13 Nov 2019 11:42:10 +0000

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://tools.ietf.org/html/rfc8402>) 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:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]; [email-masked]; [email-masked]
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)

https://clicktime.symantec.com/3EMJRgfTdX6UyWKGnMPiVwZ6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-spring-sr-replication-segment%2F

Comment:

IPR call:

https://clicktime.symantec.com/3KG7A2qM3Xf2eqDctGju1e66H2?u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_stJjBM5K6vr7QYw0HRKf-z0_us

_______________________________________________

spring mailing list

[email-masked]<mailto:[email-masked]>

https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

___________________________________________________________________________

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Nov 2019 15:14:50 +0100

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 <
[email-masked]> wrote:

> Hi all,
>
> I have a question regarding adoption of
> draft-voyer-sr-spring-replication-segment as a SPRING WG document.
>
>
>
> 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://tools.ietf.org/html/rfc8402>)
> 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
>
> To: [email-masked];
> spring-chairs@ietf..org; [email-masked]
> 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)
>
>
>
> [email-masked]
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 13 Nov 2019 14:25:48 +0000

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

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, November 13, 2019 4:15 PM
To: Alexander Vainshtein <[email-masked]>
Cc: <[email-masked]> ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]
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 ?

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

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/34qM9QogJnh1eY5nZPXYAkA6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402>) 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”.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/3KSi9HHVnunMDQNLd2U3Sij6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring>

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Nov 2019 20:40:14 +0000

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 <[email-masked]> On Behalf Of Alexander Vainshtein
Sent: Wednesday, November 13, 2019 9:26 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]; <[email-masked]> ([email-masked]) <[email-masked]>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Robert,

  *   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

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 13, 2019 4:15 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Sasha,

Thx,
R.

Hi all,

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

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

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

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Nov 2019 21:54:48 +0100

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 <[email-masked]> wrote:

> *From:* spring <[email-masked]> *On Behalf Of *Alexander
> Vainshtein
> *Sent:* Wednesday, November 13, 2019 9:26 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* [email-masked];
> [email-masked]; <
> [email-masked]> ([email-masked]) <
> [email-masked]>
> *Subject:* Re: [spring] The SPRING WG has placed
> 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.
>
>
>
>    - 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
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, November 13, 2019 4:15 PM
> *To:* Alexander Vainshtein <[email-masked]>
> *Cc:* <[email-masked]> ([email-masked]) <
> [email-masked]>;
> [email-masked];
> [email-masked]
> *Subject:* Re: [spring] The SPRING WG has placed
> 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.
>
>
>
>
>
>
>
>
>
>
>
> 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$>)
> <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://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$>
>
>
>
> <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$>
>
>
> <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$>
>
>

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Nov 2019 21:19:51 +0000

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 <[email-masked]>
Sent: Wednesday, November 13, 2019 3:55 PM
To: John E Drake <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; [email-masked]; [email-masked]; <[email-masked]> ([email-masked]) <[email-masked]>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi John,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Yours Irrespectively,

John

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Alexander Vainshtein
Sent: Wednesday, November 13, 2019 9:26 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Nov 2019 22:26:46 +0100

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

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 <[email-masked]> 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
>
>
>
>
>
> *Sent:* Wednesday, November 13, 2019 3:55 PM
> *To:* John E Drake <[email-masked]>
> *Cc:* Alexander Vainshtein <[email-masked]>;
> [email-masked];

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Nov 2019 21:36:44 +0000

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 <[email-masked]> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 13, 2019 3:55 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

  *   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

Sasha,

Thx,
R.

Hi all,

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

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 17 Nov 2019 11:39:24 +0800

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=
[email-masked]> 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
>
> <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.
>
>
>> 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

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sun, 17 Nov 2019 04:09:15 +0000

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 <[email-masked]> On Behalf Of Greg Mirsky
Sent: 17 November 2019 11:39
To: John E Drake <jdrake=[email-masked]>
Cc: [email-masked]; Alexander Vainshtein <[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>; <[email-masked]> ([email-masked]) <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> wrote:
Robert,

John
Sent from my iPhone

On Nov 14, 2019, at 2:57 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

John,

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

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Cc: spring@ietf..org<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 17 Nov 2019 13:13:47 +0800

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) <[email-masked]>
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 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)
>
>
>
> 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 <[email-masked]> *On Behalf Of *Greg Mirsky
> *Sent:* 17 November 2019 11:39
> *To:* John E Drake <jdrake=[email-masked]>
> *Cc:* [email-masked]; Alexander Vainshtein <
> [email-masked]>;
> [email-masked]; Robert Raszuk
> <[email-masked]>; <[email-masked]> (
> [email-masked]) <[email-masked]>
> <https://urldefense.com/v3/__https:/www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml__;!8WoA6RjC81c!QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ$>
>
>
>
>
> *Cc:* spring@ietf..org <[email-masked]>;

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 17 Nov 2019 05:54:59 +0000

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.

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.

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.

What, if anything, did I miss?

Regards,
Sasha

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Greg Mirsky <[email-masked]>
Sent: Sunday, November 17, 2019, 07:14
To: Ketan Talaulikar (ketant)
Cc: John E Drake; [email-masked]; Alexander Vainshtein; [email-masked]; Robert Raszuk; <[email-masked]> ([email-masked])
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

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) <[email-masked]<mailto:[email-masked]>> 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://clicktime.symantec.com/3AvJoi4kZMCSL1EhyDMKMh36H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-voyer-spring-sr-replication-segment-00>

Thanks,
Ketan

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Mirsky
Sent: 17 November 2019 11:39
To: John E Drake <jdrake=[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Ref: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml<https://clicktime.symantec.com/3De6CReeZywpiq7GCkqUmyN6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.iana.org%2Fassignments%2Fmulticast-addresses%2Fmulticast-addresses.xhtml__%3B%218WoA6RjC81c%21QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ%24>

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

3.       The current (and, AFAIK, the only existing) Segment Routing Architecture document (RFC 8402<https://clicktime.symantec.com/3RCcYJTQUoix9rL8CmszPQ16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F34qM9QogJnh1eY5nZPXYAkA6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Ftools.ietf.org%2A2Fhtml%2A2Frfc8402__%3BJSUlJSU%218WoA6RjC81c%21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUOvwkLSU%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”.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

https://clicktime.symantec.com/3EMJRgfTdX6UyWKGnMPiVwZ6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-spring-sr-replication-segment%2F<https://clicktime.symantec.com/35c32GQPzeBU6WDDFaDNg3R6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3EMJRgfTdX6UyWKGnMPiVwZ6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fdatatracker.ietf.org%2A2Fdoc%2A2Fdraft-voyer-spring-sr-replication-segment%2A2F__%3BJSUlJSUl%218WoA6RjC81c%21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUHVCWfyU%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/327SVFAhGtwEJZy7ns9pJN16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3KG7A2qM3Xf2eqDctGju1e66H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fmailarchive.ietf.org%2A2Farch%2A2Fmsg%2A2Fspring%2A2F_stJjBM5K6vr7QYw0HRKf-z0_us__%3BJSUlJSUlJQ%218WoA6RjC81c%21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUfVccUWU%24>

spring mailing list

https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://clicktime.symantec.com/3UtBbCsdVBPwVthRzL1jB8u6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3AtNGCKcyM5uigFH55oARZ86H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%218WoA6RjC81c%21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUhKjFqCs%24>

https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/3QEWS5DMsSm3TeWhdvxL5op6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3KSi9HHVnunMDQNLd2U3Sij6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%218WoA6RjC81c%21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUZIWr6Wk%24>

https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/3PbPdEjZDSp26Px1FhZU7Wk6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sun, 17 Nov 2019 09:17:01 +0000

Hi Sasha,

Thanks for your clarifications and it helps a lot.

It might help further if you could share your thoughts on what content you find missing from an architecture POV beyond what is already in the draft-voyer-spring-sr-replication-segment.

I note that we, as the WG, have recently introduced a new Path Segment via draft-ietf-spring-mpls-path-segment.

Thanks,
Ketan

From: Alexander Vainshtein <[email-masked]>
Sent: 17 November 2019 13:55
To: Greg Mirsky <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Cc: John E Drake <jdrake=[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>; <[email-masked]> ([email-masked]) <[email-masked]>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Dear colleagues,

Regards,
Sasha

________________________________
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, November 17, 2019, 07:14
To: Ketan Talaulikar (ketant)
Cc: John E Drake; [email-masked]<mailto:[email-masked]>; Alexander Vainshtein; [email-masked]<mailto:[email-masked]>; Robert Raszuk; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>)
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi Ketan,

Regards,
Greg

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sun, 17 Nov 2019 09:21:22 +0000

Hi Greg,

Please check inline.

From: Greg Mirsky <[email-masked]>
Sent: 17 November 2019 13:14
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: John E Drake <jdrake=[email-masked]>; [email-masked]; Alexander Vainshtein <[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>; <[email-masked]> ([email-masked]) <[email-masked]>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi Ketan,

Hence, I believe, is the valid question to where the possible impact of multicast on the architecture of segment routing should be discussed, described.
[KT] Sure and I think I understand your point. Multicast in SR networks is for the WG to discuss and the chairs/AD to guide. However, I believe this is not related or blocking for the document in the subject line (as also echoed by Sasha). Just wanted to clarify this part.

Thanks,
Ketan

Regards,
Greg

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

---

From: John E Drake <[email-masked]>
Date: Sun, 17 Nov 2019 09:26:47 +0000

It appears that we are putting the cart before the horse and trying to pretend otherwise

Sent from my iPhone

On Nov 17, 2019, at 5:21 PM, Ketan Talaulikar (ketant) <[email-masked]> wrote:

Hi Greg,

Please check inline.

Hi Ketan,

Thanks,
Ketan

Regards,
Greg

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://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-00__;!8WoA6RjC81c!SPTbQciVplX-N_5XL7RVV2GtQKPNoQqLISzhsg-_Rvd07Dt_96a-GHekVfESn_Q$>

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!SPTbQciVplX-N_5XL7RVV2GtQKPNoQqLISzhsg-_Rvd07Dt_96a-GHekS1LUvq4$>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 17 Nov 2019 09:30:02 +0000

Ketan,
Lots of thanks for a prompt and encouraging response.

I will try to provide additional inputs missing architectural issues related to the Replication Segment draft.

Regarding Path Segment that has been recently  introduced by the WG – I am fully aware of this work.
From my POV this draft did not require any architectural extensions. E.g. it is a local Segment and the node where it is instantiated  performs NEXT  operation on it. The fact that the node where it is instantiated also notes this Segment and uses it for binding the received packets with a specific path does not have serious architectural implications IMHO.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: Sunday, November 17, 2019 11:17 AM
To: Alexander Vainshtein <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: John E Drake <jdrake=[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>; <[email-masked]> ([email-masked]) <[email-masked]>
Subject: RE: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi Sasha,

Thanks,
Ketan

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: 17 November 2019 13:55
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Dear colleagues,

Regards,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/3SNQqgvMLK41aG2EQ8XX4pn6H2?u=https%3A%2F%2Faka.ms%2Fghei36>

Hi Ketan,

Regards,
Greg

·  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)

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

---

From: John E Drake <[email-masked]>
Date: Sun, 17 Nov 2019 10:03:48 +0000

Hi,

Given that this draft, gratuitously, ignores all of the aspects of SR multicast that need to be considered, it would be ill-advised to consider advancing it.

John

Sent from my iPhone

Hi Greg,

Please check inline.

Hi Ketan,

Thanks,
Ketan

Regards,
Greg

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 17 Nov 2019 21:37:10 +0800

Hi Ketan,
thank you for your thoughtful consideration of my comment. In
the draft-voyer-spring-sr-replication-segment I find the following
statement:
   A Replication segment at ingress node of Multi-point
   service replicates packets directly to each egress node of the
   service, without need for any state in the core of SR domain.
   Multiple Replication segments can be stitched together to build a
   tree in SR domain for Multi-point service; this is outside the scope
   of this document.
confusing. Firstly, what is the definition of  "core of SR domain"?
Secondly, isn't the suggestion of the potential stitching of Replication
segments, an acknowledgment that the Replication Segment introduces the
state to internal nodes of a single SR domain in order to realize a
scalable Multi-point service within an SR domain?

Regards,
Greg

On Sun, Nov 17, 2019 at 5:21 PM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Hi Greg,
>
>
>
> Please check inline.
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* 17 November 2019 13:14
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* John E Drake <jdrake=[email-masked]>; [email-masked];
> Alexander Vainshtein <[email-masked]>;
> *[KT] Sure and I think I understand your point. Multicast in SR networks
> is for the WG to discuss and the chairs/AD to guide. However, I believe
> this is not related or blocking for the document in the subject line (as
> also echoed by Sasha). Just wanted to clarify this part.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> On Sun, Nov 17, 2019 at 12:09 PM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi Greg/Sasha/All,
>
>
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 17 Nov 2019 19:23:05 +0000

Hi,

Please see some clarifications below.

-----Original Message-----
From: Alexander Vainshtein <[email-masked]> 
Sent: Wednesday, November 13, 2019 5:12 PM
To: <[email-masked]> ([email-masked]) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi all,

Zzh> The draft deals with replication at ANY node: an incoming packet is replicated to a few downstream nodes.
Zzh> If that is used on a root node (of a replication tree) and all the downstream nodes are leaves of the replication tree, then it is "ingress replication", e.g. the ingress replication used for MVPN/EVPN.

Zzh> It's not clear what "local ingress replication" means exactly. I can understand "ingress replication" as used for MVPN/EVPN, and I can understand "local replication" (I interpret it as what this draft tries to define).
Zzh> This draft is indeed about architecture extension on replication (or "local replication"), and "ingress replication" is a special kind of replication as I mentioned above.

3.       The current (and, AFAIK, the only existing) Segment Routing Architecture document (RFC 8402<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8402__;!8WoA6RjC81c!R5uaL0FFboU6ryB3g53QkJpHP6nLdJ_YH6_lnAt0_THeoVW8aF3qEAlMXaVpdJiY$ >) 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".

Zzh> That's fine; that document is about unicast, and in this document we're trying to extend the architecture to multicast/replication, focusing on basic building block "replication segment".

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

Zzh> I see that people have different interpretation about "multicast". I suppose we don't have different interpretation about "replication". This document is about "replication segment" as the basic building block for replication trees (whether it is IP multicast, mLDP/RSVP-TE P2MP tunnel or anything equivalent, or ingress replication).

Zzh> There is indeed a separate document "draft-voyer-pim-sr-p2mp-policy" about how to use the basic building block to build replication trees. In fact, the two documents, "draft-voyer-spring-sr-replication-segment" and "draft-voyer-pim-sr-p2mp-policy" were split from "draft-voyer-spring-sr-p2mp-policy-03" based on the input we received, so that in Spring WG we focus on the basic building block "replication segment", while leaving tree building to other WGs.
Zzh>
Zzh> Thanks.
Zzh> Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 17 Nov 2019 19:44:02 +0000

Hi Sasha, Ketan, Greg, John, all,

I hope my email (attached) in response to Sasha’s original email, answers many questions brought up in this thread.

Thanks.
Jeffrey

From: Alexander Vainshtein <[email-masked]>
Sent: Sunday, November 17, 2019 3:00 PM
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: John E Drake <jdrake=[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>; [email-masked]; Greg Mirsky <[email-masked]>; Rob Shakir <[email-masked]>; [email-masked]
Subject: RE: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Ketan,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, November 17, 2019 11:17 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi Sasha,

Thanks,
Ketan

Dear colleagues,

Regards,
Sasha

Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/3SNQqgvMLK41aG2EQ8XX4pn6H2?u=https*3A*2F*2Faka.ms*2Fghei36__;JSUlJQ!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23bjuSQwd$>

Hi Ketan,

Regards,
Greg

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/3AvJoi4kZMCSL1EhyDMKMh36H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-voyer-spring-sr-replication-segment-00__;JSUlJSU!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23Wjh_Ns4$>

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Ref: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml<https://urldefense.com/v3/__https:/clicktime.symantec.com/3De6CReeZywpiq7GCkqUmyN6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.iana.org*2Fassignments*2Fmulticast-addresses*2Fmulticast-addresses.xhtml__*3B*218WoA6RjC81c*21QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ*24__;JSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23R2v9BTO$>

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

3.       The current (and, AFAIK, the only existing) Segment Routing Architecture document (RFC 8402<https://urldefense.com/v3/__https:/clicktime.symantec.com/3RCcYJTQUoix9rL8CmszPQ16H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F34qM9QogJnh1eY5nZPXYAkA6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Ftools.ietf.org*2A2Fhtml*2A2Frfc8402__*3BJSUlJSU*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUOvwkLSU*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23cHzDX-v$>) 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”.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

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/35c32GQPzeBU6WDDFaDNg3R6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3EMJRgfTdX6UyWKGnMPiVwZ6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fdatatracker.ietf.org*2A2Fdoc*2A2Fdraft-voyer-spring-sr-replication-segment*2A2F__*3BJSUlJSUl*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUHVCWfyU*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23ZI8tAQG$>

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/327SVFAhGtwEJZy7ns9pJN16H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3KG7A2qM3Xf2eqDctGju1e66H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fmailarchive.ietf.org*2A2Farch*2A2Fmsg*2A2Fspring*2A2F_stJjBM5K6vr7QYw0HRKf-z0_us__*3BJSUlJSUlJQ*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUfVccUWU*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23dKAlkdP$>

spring mailing list

https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3UtBbCsdVBPwVthRzL1jB8u6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3AtNGCKcyM5uigFH55oARZ86H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Fspring__*3BJSUlJSUl*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUhKjFqCs*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23b-IK2fY$>

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3QEWS5DMsSm3TeWhdvxL5op6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3KSi9HHVnunMDQNLd2U3Sij6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Fspring__*3BJSUlJSUl*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUZIWr6Wk*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23W1FpqHq$>

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3PbPdEjZDSp26Px1FhZU7Wk6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23falfQwL$>

Subject: RE: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"
From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
To: Alexander Vainshtein <[email-masked]>, "<[email-masked]> ([email-masked])" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Sun, 17 Nov 2019 19:23:05 +0000

Hi,

-----Original Message-----
From: Alexander Vainshtein <[email-masked]> 
Sent: Wednesday, November 13, 2019 5:12 PM
To: <[email-masked]> ([email-masked]) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi all,

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 17 Nov 2019 20:03:41 +0000

Hi Sasha,

Please see zzh> below.

Sent: Sunday, November 17, 2019 11:25 AM

Dear colleagues,

Zzh> It is intended for instantiation on any node of a replication tree – root, leaves, and intermediate replication nodes.

Zzh> On the intermediate replication node, a CONTINUE or NEXT 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).
Zzh> On the root node, a PUSH is done on each replicated copy. On the leaf node, a NEXT is done.
Zzh> The replication-segment draft does not currently explicitly use those terms but I see we can/should add them.

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).
Zzh> Thanks.
Zzh> Jeffrey

Regards,
Sasha

Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEi4RbBA$>

Hi Ketan,

Regards,
Greg

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/3AvJoi4kZMCSL1EhyDMKMh36H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-voyer-spring-sr-replication-segment-00__;JSUlJSU!8WoA6RjC81c!XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOz05MDt$>

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Ref: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml<https://urldefense.com/v3/__https:/clicktime.symantec.com/3De6CReeZywpiq7GCkqUmyN6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.iana.org*2Fassignments*2Fmulticast-addresses*2Fmulticast-addresses.xhtml__*3B*218WoA6RjC81c*21QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ*24__;JSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOQHQk7P$>

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

3.       The current (and, AFAIK, the only existing) Segment Routing Architecture document (RFC 8402<https://urldefense.com/v3/__https:/clicktime.symantec.com/3RCcYJTQUoix9rL8CmszPQ16H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F34qM9QogJnh1eY5nZPXYAkA6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Ftools.ietf.org*2A2Fhtml*2A2Frfc8402__*3BJSUlJSU*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUOvwkLSU*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HCjtMYud$>) 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”.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

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/35c32GQPzeBU6WDDFaDNg3R6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3EMJRgfTdX6UyWKGnMPiVwZ6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fdatatracker.ietf.org*2A2Fdoc*2A2Fdraft-voyer-spring-sr-replication-segment*2A2F__*3BJSUlJSUl*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUHVCWfyU*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HPAf8tqe$>

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/327SVFAhGtwEJZy7ns9pJN16H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3KG7A2qM3Xf2eqDctGju1e66H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fmailarchive.ietf.org*2A2Farch*2A2Fmsg*2A2Fspring*2A2F_stJjBM5K6vr7QYw0HRKf-z0_us__*3BJSUlJSUlJQ*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUfVccUWU*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEOgBqq0$>

spring mailing list

https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3UtBbCsdVBPwVthRzL1jB8u6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3AtNGCKcyM5uigFH55oARZ86H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Fspring__*3BJSUlJSUl*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUhKjFqCs*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HMOgrGEQ$>

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3QEWS5DMsSm3TeWhdvxL5op6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3KSi9HHVnunMDQNLd2U3Sij6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Fspring__*3BJSUlJSUl*218WoA6RjC81c*21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUZIWr6Wk*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HGNAFyXn$>

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3PbPdEjZDSp26Px1FhZU7Wk6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!8WoA6RjC81c!XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HKEOvPpz$>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 17 Nov 2019 20:25:42 +0000

Hi Greg, all,

Please see zzh> below.

Sent: Sunday, November 17, 2019 7:07 PM

Hi Ketan,
thank you for your thoughtful consideration of my comment. In the draft-voyer-spring-sr-replication-segment I find the following statement:

zzh> We can change the wording, but the intention is “internal routers”.

Secondly, isn't the suggestion of the potential stitching of Replication segments, an acknowledgment that the Replication Segment introduces the state to internal nodes of a single SR domain in order to realize a scalable Multi-point service within an SR domain?

Zzh> If one does not care about efficient replication, then one can use Ingress Replication (which has been used before SR and continue to apply in SR networks) and that does not have any state inside the network (you still have per-flow/tree state on the edge). Let me call that option 1.
Zzh> If you do care about efficient replication, then you either use BIER (which does not have per-flow state inside the network, though it does require new or programmable ASIC so that the new encapsulation and forwarding algorithm required by BIER can be handled) or introduce/keep per-flow/tree state inside the network. Let me call the two as option 2 and 3 respectively.
Zzh> The replication segment is intended for option #1 and #3. As I explained in another thread (of the same subject line), the replication segment can be used for both #1 and #3, and #1 is really just a special form of #3.
Zzh> BTW – traditional mLDP/RSVP-TE P2MP tunnels and PIM trees can all be considered as #3. In the SR era, (some) people don’t want to use PIM/mLDP/RSVP-TE P2MP anymore but as long as you want efficient replication w/o using BIER (option #2), then you still have to keep state on internal routers.

Zzh> So why we’re doing this replication segment?
Zzh> I see two important aspects of SR – a) no per-flow state on internal routers b) use of controllers to steer traffic.
Zzh> When it comes to efficient replication/multicast we can’t achieve a) w/o using BIER, but we can still achieve b), and the replication segment is the building block to achieve b). The separate “draft-voyer-pim-sr-p2mp-policy” describes how the building block can be used to achieve b).
Zzh> Thanks.
Zzh> Jeffrey

Regards,
Greg

On Sun, Nov 17, 2019 at 5:21 PM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Please check inline.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: 17 November 2019 13:14
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <jdrake=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi Ketan,

Thanks,
Ketan

Regards,
Greg

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:/tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-00__;!8WoA6RjC81c!XeZJtRzefFgiJLe2wLYn90cJp25eXTwbA0DX8pxmJctNWhRTkFfbtETOZZB2nDCK$>

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!XeZJtRzefFgiJLe2wLYn90cJp25eXTwbA0DX8pxmJctNWhRTkFfbtETOZWB2K7_O$>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 18 Nov 2019 09:16:36 +0000

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.

Please see also some specific comments inline below.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Sunday, November 17, 2019 10:04 PM
To: Alexander Vainshtein <[email-masked]>; Greg Mirsky <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Cc: John E Drake <jdrake=[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>; <[email-masked]> ([email-masked]) <[email-masked]>
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.

Dear colleagues,

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

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) [[Sasha]] Don’t you think that the bud node deserves more explanation in the draft?
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.
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.

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.
Zzh> Thanks.
Zzh> Jeffrey

Regards,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/3DMZgKRcy5iz8AKBGXy2vYx6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Faka.ms%2Fghei36__%3B%218WoA6RjC81c%21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEi4RbBA%24>

Hi Ketan,

Regards,
Greg

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://clicktime.symantec.com/3KY7RjLZXLr1rkewXkXxck56H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3AvJoi4kZMCSL1EhyDMKMh36H2%3Fu%3Dhttps%2A3A%2A2F%2A2Ftools.ietf.org%2A2Fhtml%2A2Fdraft-voyer-spring-sr-replication-segment-00__%3BJSUlJSU%218WoA6RjC81c%21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOz05MDt%24>

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Ref: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml<https://clicktime.symantec.com/3FyMakEGDw4BoNAsgMaGjoa6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3De6CReeZywpiq7GCkqUmyN6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fwww.iana.org%2A2Fassignments%2A2Fmulticast-addresses%2A2Fmulticast-addresses.xhtml__%2A3B%2A218WoA6RjC81c%2A21QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ%2A24__%3BJSUlJSUlJSUlJSUlJSU%218WoA6RjC81c%21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOQHQk7P%24>

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

3.       The current (and, AFAIK, the only existing) Segment Routing Architecture document (RFC 8402<https://clicktime.symantec.com/3N81UkhX23XoNwsjuzVd3zR6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3RCcYJTQUoix9rL8CmszPQ16H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F34qM9QogJnh1eY5nZPXYAkA6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Ftools.ietf.org%2A2A2Fhtml%2A2A2Frfc8402__%2A3BJSUlJSU%2A218WoA6RjC81c%2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUOvwkLSU%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJQ%218WoA6RjC81c%21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HCjtMYud%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”.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

https://clicktime.symantec.com/3EMJRgfTdX6UyWKGnMPiVwZ6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-spring-sr-replication-segment%2F<https://clicktime.symantec.com/3DuXuB4dDSakmFezxqptsdT6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F35c32GQPzeBU6WDDFaDNg3R6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3EMJRgfTdX6UyWKGnMPiVwZ6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Fdatatracker.ietf.org%2A2A2Fdoc%2A2A2Fdraft-voyer-spring-sr-replication-segment%2A2A2F__%2A3BJSUlJSUl%2A218WoA6RjC81c%2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUHVCWfyU%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU%218WoA6RjC81c%21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HPAf8tqe%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/3H2BHZnEFX386Kd1WLrwWdu6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F327SVFAhGtwEJZy7ns9pJN16H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3KG7A2qM3Xf2eqDctGju1e66H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Fmailarchive.ietf.org%2A2A2Farch%2A2A2Fmsg%2A2A2Fspring%2A2A2F_stJjBM5K6vr7QYw0HRKf-z0_us__%2A3BJSUlJSUlJQ%2A218WoA6RjC81c%2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUfVccUWU%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl%218WoA6RjC81c%21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEOgBqq0%24>

spring mailing list

https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://clicktime.symantec.com/37GEaAYiYHcmqR1PWa26db66H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3UtBbCsdVBPwVthRzL1jB8u6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3AtNGCKcyM5uigFH55oARZ86H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Fwww.ietf.org%2A2A2Fmailman%2A2A2Flistinfo%2A2A2Fspring__%2A3BJSUlJSUl%2A218WoA6RjC81c%2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUhKjFqCs%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU%218WoA6RjC81c%21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HMOgrGEQ%24>

https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/3GPbeSEHLNv95j2PUuMWiWK6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3QEWS5DMsSm3TeWhdvxL5op6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3KSi9HHVnunMDQNLd2U3Sij6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Fwww.ietf.org%2A2A2Fmailman%2A2A2Flistinfo%2A2A2Fspring__%2A3BJSUlJSUl%2A218WoA6RjC81c%2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUZIWr6Wk%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU%218WoA6RjC81c%21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HGNAFyXn%24>

https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/3sBzygqGpymg8hapXD7DPL6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3PbPdEjZDSp26Px1FhZU7Wk6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%218WoA6RjC81c%21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HKEOvPpz%24>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 18 Nov 2019 09:42:09 +0000

Hi Sasha,

Please see zzh2> below.

From: Alexander Vainshtein <[email-masked]>
Sent: Monday, November 18, 2019 1:17 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: John E Drake <jdrake=[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>; <[email-masked]> ([email-masked]) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Greg Mirsky <[email-masked]>
Subject: RE: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Jeffrey,

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 😊

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, November 17, 2019 10:04 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
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.

Dear colleagues,

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

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?

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 😊

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

Regards,
Sasha

Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/3DMZgKRcy5iz8AKBGXy2vYx6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEi4RbBA*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHkEWy2zY$>

Hi Ketan,

Regards,
Greg

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/3KY7RjLZXLr1rkewXkXxck56H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3AvJoi4kZMCSL1EhyDMKMh36H2*3Fu*3Dhttps*2A3A*2A2F*2A2Ftools.ietf.org*2A2Fhtml*2A2Fdraft-voyer-spring-sr-replication-segment-00__*3BJSUlJSU*218WoA6RjC81c*21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOz05MDt*24__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHmiqR2CG$>

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Ref: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml<https://urldefense.com/v3/__https:/clicktime.symantec.com/3FyMakEGDw4BoNAsgMaGjoa6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3De6CReeZywpiq7GCkqUmyN6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fwww.iana.org*2A2Fassignments*2A2Fmulticast-addresses*2A2Fmulticast-addresses.xhtml__*2A3B*2A218WoA6RjC81c*2A21QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ*2A24__*3BJSUlJSUlJSUlJSUlJSU*218WoA6RjC81c*21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOQHQk7P*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHrLSrcU0$>

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

3.       The current (and, AFAIK, the only existing) Segment Routing Architecture document (RFC 8402<https://urldefense.com/v3/__https:/clicktime.symantec.com/3N81UkhX23XoNwsjuzVd3zR6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3RCcYJTQUoix9rL8CmszPQ16H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fclicktime.symantec.com*2A2F34qM9QogJnh1eY5nZPXYAkA6H2*2A3Fu*2A3Dhttps*2A2A3A*2A2A2F*2A2A2Ftools.ietf.org*2A2A2Fhtml*2A2A2Frfc8402__*2A3BJSUlJSU*2A218WoA6RjC81c*2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUOvwkLSU*2A24__*3BJSUlJSUlJSUlJSUlJSUlJSUlJQ*218WoA6RjC81c*21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HCjtMYud*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHuHPlt49$>) 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”.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

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/3DuXuB4dDSakmFezxqptsdT6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F35c32GQPzeBU6WDDFaDNg3R6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fclicktime.symantec.com*2A2F3EMJRgfTdX6UyWKGnMPiVwZ6H2*2A3Fu*2A3Dhttps*2A2A3A*2A2A2F*2A2A2Fdatatracker.ietf.org*2A2A2Fdoc*2A2A2Fdraft-voyer-spring-sr-replication-segment*2A2A2F__*2A3BJSUlJSUl*2A218WoA6RjC81c*2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUHVCWfyU*2A24__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU*218WoA6RjC81c*21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HPAf8tqe*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHi7osh4b$>

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/3H2BHZnEFX386Kd1WLrwWdu6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F327SVFAhGtwEJZy7ns9pJN16H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fclicktime.symantec.com*2A2F3KG7A2qM3Xf2eqDctGju1e66H2*2A3Fu*2A3Dhttps*2A2A3A*2A2A2F*2A2A2Fmailarchive.ietf.org*2A2A2Farch*2A2A2Fmsg*2A2A2Fspring*2A2A2F_stJjBM5K6vr7QYw0HRKf-z0_us__*2A3BJSUlJSUlJQ*2A218WoA6RjC81c*2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUfVccUWU*2A24__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl*218WoA6RjC81c*21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEOgBqq0*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHrA7AgaY$>

spring mailing list

https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/37GEaAYiYHcmqR1PWa26db66H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3UtBbCsdVBPwVthRzL1jB8u6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fclicktime.symantec.com*2A2F3AtNGCKcyM5uigFH55oARZ86H2*2A3Fu*2A3Dhttps*2A2A3A*2A2A2F*2A2A2Fwww.ietf.org*2A2A2Fmailman*2A2A2Flistinfo*2A2A2Fspring__*2A3BJSUlJSUl*2A218WoA6RjC81c*2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUhKjFqCs*2A24__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU*218WoA6RjC81c*21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HMOgrGEQ*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHgJhY156$>

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3GPbeSEHLNv95j2PUuMWiWK6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3QEWS5DMsSm3TeWhdvxL5op6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fclicktime.symantec.com*2A2F3KSi9HHVnunMDQNLd2U3Sij6H2*2A3Fu*2A3Dhttps*2A2A3A*2A2A2F*2A2A2Fwww.ietf.org*2A2A2Fmailman*2A2A2Flistinfo*2A2A2Fspring__*2A3BJSUlJSUl*2A218WoA6RjC81c*2A21TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUZIWr6Wk*2A24__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU*218WoA6RjC81c*21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HGNAFyXn*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHigHV9i2$>

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3sBzygqGpymg8hapXD7DPL6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3PbPdEjZDSp26Px1FhZU7Wk6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Fwww.ietf.org*2A2Fmailman*2A2Flistinfo*2A2Fspring__*3BJSUlJSUl*218WoA6RjC81c*21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HKEOvPpz*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHs6hrev2$>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 19 Nov 2019 06:02:57 +0000

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

________________________________
From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: Monday, November 18, 2019, 11:42
To: Alexander Vainshtein
Cc: John E Drake; [email-masked]; [email-masked]; Robert Raszuk; <[email-masked]> ([email-masked]); 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.

Jeffrey,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Please see zzh> below.

Dear colleagues,

Zzh> Thanks.
Zzh> Jeffrey

Regards,
Sasha

Get Outlook for Android<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>

Hi Ketan,

Regards,
Greg

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://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>

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Ref: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml<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>

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

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

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

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

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>

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>

https://www.ietf.org/mailman/listinfo/spring<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>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 19 Nov 2019 20:26:17 +0000

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

Sent: Monday, November 18, 2019 10:03 PM

Jeffrey,

Regards,
Sasha

Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nZKz-U1v$>

Cc: John E Drake; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>); Ketan Talaulikar (ketant); Greg Mirsky

Hi Sasha,

Please see zzh2> below.

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 18, 2019 1:17 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Jeffrey,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Please see zzh> below.

Dear colleagues,

Zzh> Thanks.
Zzh> Jeffrey

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

Hi Ketan,

Regards,
Greg

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

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

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

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 20 Nov 2019 07:50:36 +0000

Jeffrey and all,
I have looked up the diff between the -00 and -01 versions.

Clarification of actions on the Replication Segment look good and very useful, lots of thanks for that.

One thing that looks problematic to me is that there are now two places (both in Section 2) that define where the Replication segment is instantiated:
In the list of definitions:

   o  Node-ID: The address of a node at which a Replication segment is
      instantiated.  Replication segment is instantiated at Downstream
      nodes and at the replication nodes.  Note that the root of a
      Multi-point service is also a replication node.

And towards the end of Section 2:

   Replication segments are instantiated for both a replication node
   itself and the downstream nodes of the Replication segment.

I.e., the replication node appears in singular in one fragment and in plural in the other one.

My guess until now has been that a given Replication Segment has one Replication node (a.k.a. root), is it really so?

There is also a mix of capitalized vs. non-capitalized terms  (Replication node vs. replication node , Downstream Nodes vs. downstream nodes) that does not help.

I assume that these  are nits stemming from the desire to provide a quick update to the draft.

One technical thing that should be clarified IMHO is which segments can appear in the lists of SIDs to which each Downstream Node is expanded.
The draft says that such a list may comprise just a Node SID of the Downstream node, and seems to suggest that any of the Segments defined in RFC 8402 can be used – but it does not explicitly say so.

The key question is, of course, whether such a list can contain another Replication Segment (with its own list of Downstream nodes), and, if so, what would this mean. If this is not allowed, it would be good to say so.

I also think that the need for Replication-ID should be clarified. This terms appears 3 times in the draft (once with a typo), and its usage is not clear to me.

I will try to join the call set up by Rishabh later today, and we can discuss all these points.
Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Tuesday, November 19, 2019 10:26 PM

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://clicktime.symantec.com/3Y1a6r33DkH5cuNTGxWtkJK6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-voyer-spring-sr-replication-segment-01__%3B%218WoA6RjC81c%21TX4tn3fMRIetXZFyREiqmjUai215tIQtO_j3c6ZmDwVmYj6QUpqfJYuIb3lwkfbk%24>.

Jeffrey

Jeffrey,

Regards,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/374UTsLBNTdzxnj1R4XiQd26H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Faka.ms%2Fghei36__%3B%218WoA6RjC81c%21UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nZKz-U1v%24>

Hi Sasha,

Please see zzh2> below.

Jeffrey,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Please see zzh> below.

Dear colleagues,

Zzh> Thanks.
Zzh> Jeffrey

Regards,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/3GyUYLo4qTShum6d2crqEa96H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3HZ94Phv2QhbtXoreQVTC9B6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3DMZgKRcy5iz8AKBGXy2vYx6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Faka.ms%2A2A2Fghei36__%2A2A3B%2A2A218WoA6RjC81c%2A2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEi4RbBA%2A2A24__%2A3BJSUlJSUlJSUlJSUl%2A218WoA6RjC81c%2A21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHkEWy2zY%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU%218WoA6RjC81c%21UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nSzmE3hb%24>

Hi Ketan,

Regards,
Greg

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://clicktime.symantec.com/3Pn2FDgiMgXeMByLcq5swNN6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3Rcp2jcNWQ9SLG9T2yC6JLg6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3KY7RjLZXLr1rkewXkXxck56H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F3AvJoi4kZMCSL1EhyDMKMh36H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Ftools.ietf.org%2A2A2A2Fhtml%2A2A2A2Fdraft-voyer-spring-sr-replication-segment-00__%2A2A3BJSUlJSU%2A2A218WoA6RjC81c%2A2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOz05MDt%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJQ%2A218WoA6RjC81c%2A21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHmiqR2CG%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl%218WoA6RjC81c%21UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nWBUKuOu%24>

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Ref: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml<https://clicktime.symantec.com/3Qz7TrCDricVrwtUvuTRbUU6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F37J7RuunsmPAvjiocyn4xJP6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3FyMakEGDw4BoNAsgMaGjoa6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F3De6CReeZywpiq7GCkqUmyN6H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Furldefense.com%2A2A2A2Fv3%2A2A2A2F__https%2A2A2A3A%2A2A2A2Fwww.iana.org%2A2A2A2Fassignments%2A2A2A2Fmulticast-addresses%2A2A2A2Fmulticast-addresses.xhtml__%2A2A2A3B%2A2A2A218WoA6RjC81c%2A2A2A21QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ%2A2A2A24__%2A2A3BJSUlJSUlJSUlJSUlJSU%2A2A218WoA6RjC81c%2A2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HOQHQk7P%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%2A218WoA6RjC81c%2A21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHrLSrcU0%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl%218WoA6RjC81c%21UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nUVodfvQ%24>

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://clicktime.symantec.com/3LJHZ2GTydV5nnjN32QeVHv6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3D5PYyStWgHPHQo5jdwCtjb6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3sBzygqGpymg8hapXD7DPL6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F3PbPdEjZDSp26Px1FhZU7Wk6H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Fwww.ietf.org%2A2A2A2Fmailman%2A2A2A2Flistinfo%2A2A2A2Fspring__%2A2A3BJSUlJSUl%2A2A218WoA6RjC81c%2A2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HKEOvPpz%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJSU%2A218WoA6RjC81c%2A21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHs6hrev2%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%218WoA6RjC81c%21UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nYsJx52x%24>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 21 Nov 2019 12:37:52 +0800

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 <[email-masked]>
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$>
> .
>
>
>
> *From:* Alexander Vainshtein <[email-masked]>
> *Sent:* Monday, November 18, 2019 10:03 PM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> [email-masked]) <[email-masked]>; Ketan
> Talaulikar (ketant) <[email-masked]>; Greg Mirsky <[email-masked]
> >
> 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.
>
>
>
> Get Outlook for Android
> <https://urldefense.com/v3/__https:/aka.ms/ghei36__;!8WoA6RjC81c!UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nZKz-U1v$>
>
>
> ------------------------------
>
> *From:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Sent:* Monday, November 18, 2019, 11:42
> *To:* Alexander Vainshtein
> *Cc:* John E Drake; [email-masked];
> [email-masked]; Robert
> Raszuk; <[email-masked]> ([email-masked]);
> Ketan Talaulikar (ketant); Greg Mirsky
> *Subject:* RE: [spring] The SPRING WG has placed
> *From:* Alexander Vainshtein <[email-masked]>
> *Sent:* Monday, November 18, 2019 1:17 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> [email-masked]) <[email-masked]>; Ketan
> Talaulikar (ketant) <[email-masked]>; Greg Mirsky <[email-masked]
> >
> *Subject:* RE: [spring] The SPRING WG has placed
> 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: +972-39266302
>
> Cell:      +972-549266302
>
> *From:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Sent:* Sunday, November 17, 2019 10:04 PM
> *To:* Alexander Vainshtein <[email-masked]>; Greg
> Mirsky <[email-masked]>; Ketan Talaulikar (ketant) <
> [email-masked]>
> *Subject:* RE: [spring] The SPRING WG has placed
> *From:* Alexander Vainshtein <[email-masked]>
> *Sent:* Sunday, November 17, 2019 11:25 AM
> *To:* Greg Mirsky <[email-masked]>; Ketan Talaulikar (ketant) <
> [email-masked]>
> 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>*
>
> *<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?*
>
> *[[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.*
>
> *[[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. *
>
> 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
>
> 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. *
>
> 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$>
>
>
> ------------------------------
>
> *Sent:* Sunday, November 17, 2019, 07:14
> *To:* Ketan Talaulikar (ketant)
> *Cc:* John E Drake; [email-masked]; Alexander Vainshtein;
> [email-masked]; Robert
> Raszuk; <[email-masked]> ([email-masked])
> <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$>
>
>
>
> <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$>
>
>
>
>
> <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>)
> <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/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>
>
>
>
> <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>
>
>
> <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>
>
>
> <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$>
>
>
>
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 27 Nov 2019 18:27:27 +0000

Hi Sasha, Greg,

We have posted the -02 revision, which addresses Sasha’s comments below and one comment from Greg.

Thanks!
Jeffrey

Sent: Wednesday, November 20, 2019 2:51 AM

Jeffrey and all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

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:/clicktime.symantec.com/3Y1a6r33DkH5cuNTGxWtkJK6H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Frfcdiff*3Furl2*3Ddraft-voyer-spring-sr-replication-segment-01__*3B*218WoA6RjC81c*21TX4tn3fMRIetXZFyREiqmjUai215tIQtO_j3c6ZmDwVmYj6QUpqfJYuIb3lwkfbk*24__;JSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!UGjpfUp5sKrlj33jeHeqTKz1xhj59Kwz4HgXCjxLiGyZ3Xh5PrfxBVSXE7E9x3Dp$>.

Jeffrey

Jeffrey,

Regards,
Sasha

Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/374UTsLBNTdzxnj1R4XiQd26H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Faka.ms*2Fghei36__*3B*218WoA6RjC81c*21UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nZKz-U1v*24__;JSUlJSUlJSUlJSUl!8WoA6RjC81c!UGjpfUp5sKrlj33jeHeqTKz1xhj59Kwz4HgXCjxLiGyZ3Xh5PrfxBVSXEz6JDs0Z$>

Hi Sasha,

Please see zzh2> below.

Jeffrey,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Please see zzh> below.

Dear colleagues,

Zzh> Thanks.
Zzh> Jeffrey

Regards,
Sasha

Get Outlook for Android<https://urldefense.com/v3/__https:/clicktime.symantec.com/3GyUYLo4qTShum6d2crqEa96H2?u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fclicktime.symantec.com*2F3HZ94Phv2QhbtXoreQVTC9B6H2*3Fu*3Dhttps*2A3A*2A2F*2A2Furldefense.com*2A2Fv3*2A2F__https*2A3A*2A2Fclicktime.symantec.com*2A2F3DMZgKRcy5iz8AKBGXy2vYx6H2*2A3Fu*2A3Dhttps*2A2A3A*2A2A2F*2A2A2Furldefense.com*2A2A2Fv3*2A2A2F__https*2A2A3A*2A2A2Faka.ms*2A2A2Fghei36__*2A2A3B*2A2A218WoA6RjC81c*2A2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEi4RbBA*2A2A24__*2A3BJSUlJSUlJSUlJSUl*2A218WoA6RjC81c*2A21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHkEWy2zY*2A24__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU*218WoA6RjC81c*21UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nSzmE3hb*24__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!UGjpfUp5sKrlj33jeHeqTKz1xhj59Kwz4HgXCjxLiGyZ3Xh5PrfxBVSXE91Vwsp9$>

Hi Ketan,

Regards,
Greg

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 29 Nov 2019 08:10:20 +0000

Jeffrey and all,
I am on vacation now, will review the -02 revision after coming back to the office in the week of 09-Dec-19.

Apologies for the delay,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Wednesday, November 27, 2019 8:27 PM

Hi Sasha, Greg,

Thanks!
Jeffrey

Jeffrey and all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

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://clicktime.symantec.com/33ieyra7j9kPmpASBTqTpeZ6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3Y1a6r33DkH5cuNTGxWtkJK6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fwww.ietf.org%2A2Frfcdiff%2A3Furl2%2A3Ddraft-voyer-spring-sr-replication-segment-01__%2A3B%2A218WoA6RjC81c%2A21TX4tn3fMRIetXZFyREiqmjUai215tIQtO_j3c6ZmDwVmYj6QUpqfJYuIb3lwkfbk%2A24__%3BJSUlJSUlJSUlJSUlJSU%218WoA6RjC81c%21UGjpfUp5sKrlj33jeHeqTKz1xhj59Kwz4HgXCjxLiGyZ3Xh5PrfxBVSXE7E9x3Dp%24>.

Jeffrey

Jeffrey,

Regards,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/3HzP1BMANacJPc2GfRcgPHx6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F374UTsLBNTdzxnj1R4XiQd26H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Faka.ms%2A2Fghei36__%2A3B%2A218WoA6RjC81c%2A21UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nZKz-U1v%2A24__%3BJSUlJSUlJSUlJSUl%218WoA6RjC81c%21UGjpfUp5sKrlj33jeHeqTKz1xhj59Kwz4HgXCjxLiGyZ3Xh5PrfxBVSXEz6JDs0Z%24>

Hi Sasha,

Please see zzh2> below.

Jeffrey,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Sasha,

Please see zzh> below.

Dear colleagues,

Zzh> Thanks.
Zzh> Jeffrey

Regards,
Sasha

Get Outlook for Android<https://clicktime.symantec.com/3X8D72ZR47J6qSq2mxWzs836H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3GyUYLo4qTShum6d2crqEa96H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3HZ94Phv2QhbtXoreQVTC9B6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F3DMZgKRcy5iz8AKBGXy2vYx6H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Furldefense.com%2A2A2A2Fv3%2A2A2A2F__https%2A2A2A3A%2A2A2A2Faka.ms%2A2A2A2Fghei36__%2A2A2A3B%2A2A2A218WoA6RjC81c%2A2A2A21XO1YXY6DxdOii7owD9drGm0dmL2XORkOEDc7SKBZ1WM9V1-p0ITi7SK3HEi4RbBA%2A2A2A24__%2A2A3BJSUlJSUlJSUlJSUl%2A2A218WoA6RjC81c%2A2A21Q3PCnq3OFt_F_FDYzrAnJems0c-jnwK6TAvgPQfHqdMAmfIU2TIxoNvvHkEWy2zY%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU%2A218WoA6RjC81c%2A21UCCj2CRO68blqHtrH3ql5xEKDs38u3J5OY263fSOOb7ou7tnBvTThZk5nSzmE3hb%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%218WoA6RjC81c%21UGjpfUp5sKrlj33jeHeqTKz1xhj59Kwz4HgXCjxLiGyZ3Xh5PrfxBVSXE91Vwsp9%24>

Hi Ketan,

Regards,
Greg

Thanks,
Ketan

Dear All,

Regards,
Greg

John
Sent from my iPhone

John,

Thx,
Robert.

Yours Irrespectively,

John

Hi John,

Thx,
R.

Yours Irrespectively,

John

Robert,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Thx,
R.

Hi all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of IETF Secretariat
Sent: Tuesday, November 12, 2019 7:06 PM
To: [email-masked]<mailto:[email-masked]>; spring-chairs@ietf..org<mailto:spring-chairs@ietf..org>; [email-masked]<mailto:[email-masked]>
Subject: [spring] The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Comment:

IPR call:

spring mailing list