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 <alexander.vainsht...@ecitele.com>
Sent: Sunday, November 17, 2019 3:00 PM
To: Ketan Talaulikar (ketant) <ket...@cisco.com>
Cc: John E Drake <jdrake=40juniper....@dmarc.ietf.org>; spring@ietf.org;
draft-voyer-spring-sr-replication-segment.auth...@ietf.org; Robert Raszuk
<rob...@raszuk.net>; bruno.decra...@orange.com; Greg Mirsky
<gregimir...@gmail.com>; Rob Shakir <ro...@google.com>; pengshup...@huawei.com
Subject: RE: [spring] The SPRING WG has placed
draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"
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
Email:
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>
From: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>
Sent: Sunday, November 17, 2019 11:17 AM
To: Alexander Vainshtein
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>;
Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: John E Drake
<jdrake=40juniper....@dmarc.ietf.org<mailto:jdrake=40juniper....@dmarc.ietf.org>>;
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>;
Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>;
<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 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
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Sent: 17 November 2019 13:55
To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>; Ketan
Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>
Cc: John E Drake
<jdrake=40juniper....@dmarc.ietf.org<mailto:jdrake=40juniper....@dmarc.ietf.org>>;
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>;
Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>;
<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"
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://urldefense.com/v3/__https:/clicktime.symantec.com/3SNQqgvMLK41aG2EQ8XX4pn6H2?u=https*3A*2F*2Faka.ms*2Fghei36__;JSUlJQ!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23bjuSQwd$>
________________________________
From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Sent: Sunday, November 17, 2019, 07:14
To: Ketan Talaulikar (ketant)
Cc: John E Drake; spring@ietf.org<mailto:spring@ietf.org>; Alexander
Vainshtein;
draft-voyer-spring-sr-replication-segment.auth...@ietf.org<mailto:draft-voyer-spring-sr-replication-segment.auth...@ietf.org>;
Robert Raszuk;
<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 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)
<ket...@cisco.com<mailto:ket...@cisco.com>> wrote:
Hi Greg/Sasha/All,
I really wonder whether we are talking about the same document anymore. The
subject of this thread is
https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-00<https://urldefense.com/v3/__https:/clicktime.symantec.com/3AvJoi4kZMCSL1EhyDMKMh36H2?u=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-voyer-spring-sr-replication-segment-00__;JSUlJSU!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23Wjh_Ns4$>
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<mailto:spring-boun...@ietf.org>> On
Behalf Of Greg Mirsky
Sent: 17 November 2019 11:39
To: John E Drake
<jdrake=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; Alexander Vainshtein
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>;
draft-voyer-spring-sr-replication-segment.auth...@ietf.org<mailto:draft-voyer-spring-sr-replication-segment.auth...@ietf.org>;
Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>;
<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"
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:/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$>
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/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”.
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/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
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/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$>
___________________________________________________________________________
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/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$>
___________________________________________________________________________
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/3PbPdEjZDSp26Px1FhZU7Wk6H2?u=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspring__;JSUlJSUl!8WoA6RjC81c!SV87OXuIgeMMS-tlFbRNVCWiIT-X-G_sGAxIZK3VcBvXreZ8FRP1y5I23falfQwL$>
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
___________________________________________________________________________
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
___________________________________________________________________________
--- Begin Message ---
Hi,
Please see some clarifications below.
-----Original Message-----
From: Alexander Vainshtein <alexander.vainsht...@ecitele.com>
Sent: Wednesday, November 13, 2019 5:12 PM
To: <spring-cha...@tools.ietf.org> (spring-cha...@tools.ietf.org)
<spring-cha...@tools.ietf.org>;
draft-voyer-spring-sr-replication-segment.auth...@ietf.org
Cc: spring@ietf.org
Subject: RE: [spring] The SPRING WG has placed
draft-voyer-spring-sr-replication-segment in state "Candidate for WG Adoption"
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.
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.
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"
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".
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
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
--- End Message ---
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring