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 <spring-boun...@ietf.org> On Behalf Of Greg Mirsky
Sent: 17 November 2019 11:39
To: John E Drake <jdrake=40juniper....@dmarc.ietf.org>
Cc: spring@ietf.org; Alexander Vainshtein <alexander.vainsht...@ecitele.com>; 
draft-voyer-spring-sr-replication-segment.auth...@ietf.org; Robert Raszuk 
<rob...@raszuk.net>; <spring-cha...@tools.ietf.org> 
(spring-cha...@tools.ietf.org) <spring-cha...@tools.ietf.org>
Subject: Re: [spring] The SPRING WG has placed 
draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Dear All,
I concur with Sasha and John. Intended ingress replication of a particular 
flow, though using a unicast destination address, is still a multicast.

Regards,
Greg

On Thu, Nov 14, 2019 at 5:36 AM John E Drake 
<jdrake=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>> 
wrote:
Robert,

As Sasha and I have indicated, your position is your own and is not consistent 
with the majority of work on this topic.  I’m fine w/ agreeing to disagree.

John
Sent from my iPhone


On Nov 14, 2019, at 2:57 AM, Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote:

John,

> Your claim that ingress replication is not multicast is, at best, a stretch.

I use a very basic and simple rule of thumb ... if address of my packet is a 
multicast address then it is multicast if not it is unicast.

Ref: 
https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml__;!8WoA6RjC81c!QFbPjRVo7hB9622FCxHnivS8PVicSm5TCW9kaF-KRqhC3G7uLL0tCrGUUxL2sAQ$>

Solution as described in draft-voyer-spring-sr-replication-segment does not 
seems to be requiring multicast addresses hence it is applicable to pure 
unicast networks.

Thx,
Robert.


On Wed, Nov 13, 2019 at 10:20 PM John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>> wrote:
Robert,

I’m sorry for the confusion.  My only point was that MVPN provides the 
reference architecture for dealing w/ multicast using a multiplicity of tunnel 
types in a consistent manner, as Sasha alluded to in his mention of PMSI.  Your 
claim that ingress replication is not multicast is, at best, a stretch.

Yours Irrespectively,

John



Juniper Business Use Only
From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Sent: Wednesday, November 13, 2019 3:55 PM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>
Cc: Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; 
draft-voyer-spring-sr-replication-segment.auth...@ietf.org<mailto:draft-voyer-spring-sr-replication-segment.auth...@ietf.org>;
 <spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>> 
(spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>) 
<spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>>
Subject: Re: [spring] The SPRING WG has placed 
draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Hi John,

> Further, ingress replication has been part of MVPN since forever.

Just curious how is this at all relevant for this discussion ?

Do I have to roll out MVPN monster to split my unicast UDP stream to few 
receivers at selected network point ?

And last but not least who said this is at all related to "ingress replication" 
??? Ingress to p2mp segment can be at any SR midpoint in the network. Are you 
suggesting to run MVPN apparatus with manual tree building ? Whow :)

Thx,
R.






On Wed, Nov 13, 2019 at 9:40 PM John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>> wrote:
Hi,

I think Sasha has a valid point.  Further, ingress replication has been part of 
MVPN since forever.

Yours Irrespectively,

John



Juniper Business Use Only
From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On 
Behalf Of Alexander Vainshtein
Sent: Wednesday, November 13, 2019 9:26 AM
To: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Cc: spr...@ietf..org<mailto:spring@ietf.org>; 
draft-voyer-spring-sr-replication-segment.auth...@ietf.org<mailto:draft-voyer-spring-sr-replication-segment.auth...@ietf.org>;
 <spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>> 
(spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>) 
<spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>>
Subject: Re: [spring] The SPRING WG has placed 
draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Robert,
Lots of thanks for a prompt response.

You seem to imply that a multicast distribution tree that is built, say, by an 
SDN controller and used, say, to act as a PMSI in the mVPN application, is not 
really a multicast.  Personally I disagree, but this is a matter of taste and 
terminology.

What looks unambiguous to me is that:

  *   The WG charter explicitly mentions ingress replication as one of “new 
types of segments mapping to forwarding behavior” that “may require 
architectural extensions”
  *   The current architecture document does not cover any such segment type 
(whether because such segments have been considered as related to multicast by 
the authors, or for some other reason is not all that important. )
Therefore my concern remains unresolved regardless of whether ingress 
replication is or is not formally considered as multicast.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Sent: Wednesday, November 13, 2019 4:15 PM
To: Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Cc: <spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>> 
(spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>) 
<spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>>; 
draft-voyer-spring-sr-replication-segment.auth...@ietf.org<mailto:draft-voyer-spring-sr-replication-segment.auth...@ietf.org>;
 spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] The SPRING WG has placed 
draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"

Sasha,

If I have some content and I send it to you and your neighbour as two unicast 
streams am I suddenly doing multicast ?

IMHO N number of replicated unicasts is still not a multicast.

Multicast in my definition requires  multicast groups, receiver joins, tree 
building protocols etc ... and this draft does not suggest any of this. IN 
contrast it just describes how can we have p2mp unicast distribution ... call 
it fan out node.

Thx,
R.





On Wed, Nov 13, 2019 at 12:42 PM Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> 
wrote:

Hi all,

I have a question regarding adoption of 
draft-voyer-sr-spring-replication-segment as a SPRING WG document.



These concerns are based on the following:

1.       This draft (both based on its title and on its content) deals with 
local (in the Root node) ingress replication which, in its turn, is one of the 
issues that could be used for delivery of multicast.

2.       Local ingress replication is mentioned in the SPRING WG Charter as one 
of the “New types of segments mapping to forwarding behavior”. The charter 
further says that “Any of the above <Sasha: New types of segments> may require 
architectural extensions”

3.       The current (and, AFAIK, the only existing) Segment Routing 
Architecture document (RFC 
8402<https://urldefense.com/v3/__https:/clicktime.symantec.com/34qM9QogJnh1eY5nZPXYAkA6H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Frfc8402__;JSUlJSU!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUOvwkLSU$>)
 explicitly states in Section 6 that “Segment Routing is defined for unicast. 
The application of the source-route concept to Multicast is not in the scope of 
this document”.

The combinations of observations above strongly suggests to me that a document 
defining multicast-related extensions of segment routing architecture should be 
very useful (if not mandatory) for progressing the Replication Segment draft. 
From my POV the Replication Segment draft is not (and is not intended to be) 
such a document.



I wonder if there is an intention to produce such a document in the timeframe 
that could be relevant for discussion of the Replication Segment draft.



Nothing in this message should be interpreted as my objection to (or support 
of) adoption of the Replication Segment draft as a WG document per se.

Bit I find it difficult to take a position any which way without a clear and 
commonly agreed upon framework for multicast in segment routing.



Regards,

Sasha



Office: +972-39266302

Cell:      +972-549266302

Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>



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





The SPRING WG has placed draft-voyer-spring-sr-replication-segment in state 
Candidate for WG Adoption (entered by Bruno Decraene)



The document is available at

https://clicktime.symantec.com/3EMJRgfTdX6UyWKGnMPiVwZ6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-spring-sr-replication-segment%2F<https://urldefense.com/v3/__https:/clicktime.symantec.com/3EMJRgfTdX6UyWKGnMPiVwZ6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-voyer-spring-sr-replication-segment*2F__;JSUlJSUl!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUHVCWfyU$>



Comment:

IPR call:

https://clicktime.symantec.com/3KG7A2qM3Xf2eqDctGju1e66H2?u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_stJjBM5K6vr7QYw0HRKf-z0_us<https://urldefense.com/v3/__https:/clicktime.symantec.com/3KG7A2qM3Xf2eqDctGju1e66H2?u=https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fspring*2F_stJjBM5K6vr7QYw0HRKf-z0_us__;JSUlJSUlJQ!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUfVccUWU$>



_______________________________________________

spring mailing list

spring@ietf.org<mailto:spring@ietf.org>

https://clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3AtNGCKcyM5uigFH55oARZ86H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUhKjFqCs$>

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/clicktime.symantec.com/3KSi9HHVnunMDQNLd2U3Sij6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!8WoA6RjC81c!TeDGZsCZsxVU3U1A-_hQaYhZsmLZFF4oF-lGSpNnOmTa-zUl6jfGkGEUZIWr6Wk$>

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to