Hi Robert,
OK, so I understand this a bit more.
Yes, we could introduce a m/c tree in the middle of the network and have
the leaves terminate in anything. That would include an SR unicast path
and/or a new m/c tree or any combination thereof. What you have to do is
to place the correct binding SID at the leaf of the tree which of course
would be unique to that leaf, and identified by the m/c tree it arrived on.
So by adding in state through a generalised Binding SID mechanism we can
build a full multicast system strictly within SR.
Sounds like it needs to be in charter.
- Stewart
On 19/06/2018 14:39, Robert Raszuk wrote:
Hi Stewart,
Nope that would be incorrect assumption.
Replication anchors would be where topologically it makes sense. And
there may not be at all any multicast trees those subject flows would
need to traverse. It is just about efficiency in content distribution.
Regards,
R.
On Tue, Jun 19, 2018 at 3:36 PM, Stewart Bryant
<[email protected] <mailto:[email protected]>> wrote:
For clarification:
Can I assume that we are talking about replication at ingress to a
series of unicast SR paths each to an installed multicast tree
close to egress?
- Stewart
On 10/06/2018 10:58, Robert Raszuk wrote:
Hey Sasha,
100% agree with your last post. Very glad to see your support for
spray/fan-out or if you will
static MDTs to be in scope of SPRING.
Based on number of WG members input expressed both at the meeting
and on the list I hope
proposed SPRING charter will be updated soon to reflect that.
Cheers,
R.
PS. Btw - I am also ok that ingress replication is not relevant
to SPRING as it essentially happens at the
ingress to the domain.
On Sun, Jun 10, 2018 at 7:39 AM, Alexander Vainshtein
<[email protected]
<mailto:[email protected]>> wrote:
Robert,
First of all, I did not say that your quote was inaccurate. I
apologize for possible misperception.
Second, I believe that spray or fan-out (meaning support of
externally computed static MDTs) in SR-MPLS is a relevant
focus area for the future WG work. Of course the solution
must be aligned with the SPRING and MPLS architecture, and
this imposes additional restrictions on how such a solution
would look.
Last but not least, I have differentiated (from my first
email on this thread) */ingress replication/* *in SR* from
the more generic *multicast support *in SR:
-The latter is quite acceptable to me
-The former, IMHO, should be left out of scope.
Hope this helps to clarify my position.
Regards, and, again, apologies for possible misinterpretation.
Sasha
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
