Subject: Re: [spring] Updating the SPRING WG Charter

From: Xiejingrong <[email-masked]>
Date: Mon, 4 Jun 2018 02:44:24 +0000

Hi Bob,

Will SPRING consider multicast/BIER being included ? These are some reasons I am thinking about:
(1) multicast/multipoint-transfer is always a requirement for internet service, and is always requiring some unicast technology as a precursor.
(2) there is already a similar WG BIER to considering the similar stateless solution for multicast for long-term.
(3) there is already some consideration about multipoint SR in segment-routing-policy draft for a long time.
(4) there is already some consideration about combining BIER and SR in bier-6man-encapsulation draft.
(5) it had been mentioned in ietf101 London to consider cooperating with BIER for some purpose.

Thanks,
Jingrong

From: spring [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Friday, June 01, 2018 9:06 AM
To: SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Updating the SPRING WG Charter

Hi SPRING,

After the discussions on the list and in London relating to the charter, Bruno and I have been working to propose a new charter for the WG with Martin, and the other routing ADs. The text for this suggested charter is below. We would like to solicit WG feedback on the charter text prior to Martin taking to the IESG. We'd like to try and get the charter agreed prior to IETF 102 in Montréal.

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as
a forum to discuss SPRING networks operations, define new applications, and
specify extensions of Segment Routing technologies.

The SPRING WG defines procedures that allow a node to steer a packet through an
SR Policy instantiated as an ordered list of instructions called segments and
without the need for per-path state information to be held at transit nodes.
Full explicit control (through loose or strict path specification) can be
achieved in a network comprising only SPRING nodes, however SPRING nodes must
inter-operate through loose routing in existing networks and may find it
advantageous to use loose routing for other network applications.

The scope of the SPRING WG work includes both single Autonomous System (AS) and
multi-AS environments. Segment Routing operates within a trusted domain; as
described in the architecture, a node imposing a segment list is assumed to be
allowed to do so. Nonetheless, the SPRING WG must strive to identify and
address security considerations brought up by the technologies it defines.  The
technologies SPRING WG defines may be applicable to both centralised and
distributed path computation.

SPRING WG should avoid modification to existing data planes that would make
them incompatible with existing deployments. Where possible, existing control
and management plane protocols must be used within existing architectures to
implement the SPRING function. Any modification of - or extension to - existing
architectures, data planes, or control or management plane protocols should be
carried out in the WGs responsible for the architecture, data plane, or control
or management plane protocol being modified and in coordination with the SPRING
WG, but may be done in SPRING WG after agreement with all the relevant WG
chairs and responsible Area Directors.

The SPRING WG will manage its specific work items by milestones agreed with the
responsible Area Director.

The work-items of the SPRING WG include functional specifications for:

o Segment Routing policies and the associated steering and traffic engineering
  mechanisms.

o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes.

o SRv6 network programming for the underlay networks and overlay services, and
  including data plane behavior and functions associated with SIDs

o Operation, Administration and Management (OAM), and traffic accounting in
  networks with SR-MPLS and SRv6 data planes in the case where SR introduces
  specificities compared to MPLS or IPv6 technologies.

o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6
  data planes in the case where SR introduces specificities compared to MPLS or
  IPv6 technologies.

o The inter-working between SRv6 and SR-MPLS.

o Using SR as the mechanism to identify sets of resources in networks with
  SR-MPLS and SRv6 dataplanes.

Any of the above may require architectural extensions.

The work-items of SPRING WG also include:

o Specification of management models (YANG) for Segment Routing applications,
  services and networks with SR-MPLS and SRv6 dataplanes.

The SPRING WG will coordinate and collaborate with other WGs as needed. Specific
expected interactions include (but may not be limited to):

     * mpls on the MPLS dataplane and OAM extensions,
     * 6man on the IPv6 dataplane for SR and associated OAM extensions
     * lsr on OSPF and IS-IS extensions to flood SPRING-related information
        * idr for BGP extensions
     * bess for VPN control plane
     * pce on extensions to communicate with an external entity to compute and program SPRING paths
     * teas on generic traffic engineering architecture

Please comment on the contents of the charter text on the list.

Thanks,
Bruno & Rob

---

From: Rob Shakir <[email-masked]>
Date: Mon, 4 Jun 2018 09:12:07 -0700

Hi Jingrong,

On Sun, Jun 3, 2018 at 7:44 PM Xiejingrong <[email-masked]> wrote:

> (1) multicast/multipoint-transfer is always a requirement for internet
> service, and is always requiring some unicast technology as a precursor.
>
> (2) there is already a similar WG BIER to considering the similar
> stateless solution for multicast for long-term.
>
> (3) there is already some consideration about multipoint SR in
> segment-routing-policy draft for a long time.
>

robjs> IMHO, if BIER leverages SR work this should be in liaison with
SPRING, but I do not expect there to be any BIER related work in SPRING
itself. If this needs changes to dataplanes, then the relevnat working
group (mpls, or 6man) should be involved too.

robjs> It is my personal opinion that the SR-TE policy draft needs to be a
constrained set of problems. It had become a collect-your-use-case
document. Part of the ask of breaking the document down is so that we can
produce a clear, succinct set of documents. Until such time as there are
concrete proposals on multicast in SR that SPRING needs to consider (i.e.,
require a new functional specification, ratheror architectural extension)
then I would aim to err on the side of keeping the charter clear, rather
than collecting all possible use cases in it.

robjs> Please disagree with me if there is a benefit to having this in the
charter that I'm missing.

Thanks,
r.

---

From: Michael McBride <[email-masked]>
Date: Mon, 4 Jun 2018 16:41:43 +0000

Hi Rob,

It would be helpful, while updating the charter, to state whether multicast in SR is in/out of scope in order to know which wg to take our future work.

Thanks,
mike

From: spring [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Monday, June 04, 2018 9:12 AM
To: Xiejingrong <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Jingrong,
On Sun, Jun 3, 2018 at 7:44 PM Xiejingrong <[email-masked]<mailto:[email-masked]>> wrote:

robjs> IMHO, if BIER leverages SR work this should be in liaison with SPRING, but I do not expect there to be any BIER related work in SPRING itself. If this needs changes to dataplanes, then the relevnat working group (mpls, or 6man) should be involved too.

robjs> It is my personal opinion that the SR-TE policy draft needs to be a constrained set of problems. It had become a collect-your-use-case document. Part of the ask of breaking the document down is so that we can produce a clear, succinct set of documents. Until such time as there are concrete proposals on multicast in SR that SPRING needs to consider (i.e., require a new functional specification, ratheror architectural extension) then I would aim to err on the side of keeping the charter clear, rather than collecting all possible use cases in it.

robjs> Please disagree with me if there is a benefit to having this in the charter that I'm missing.

Thanks,
r.

---

From: Rob Shakir <[email-masked]>
Date: Mon, 4 Jun 2018 09:44:58 -0700

Michael,

Thanks for the comment.

On Mon, Jun 4, 2018 at 9:42 AM Michael McBride <[email-masked]>
wrote:

> It would be helpful, while updating the charter, to state whether
> multicast in SR is in/out of scope in order to know which wg to take our
> future work.
>

I think this is impractical. If we state everything that is in or out of
scope, we'll end up with a laundry list. The aim of the charter is to
define clearly the work that the WG should focus on. It does not mean that
we can never host discussion of individual drafts if they are relevant. If
there are requirements, we can always recharter if something new becomes
the highest priority for the industry w.r.t SR.

Kind regards,
r.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 6 Jun 2018 19:14:16 +0000

Hi Rob,

The multicast in SR belongs to the same category as I highlighted in my last email. Just to repeat …

At IETF101, you and Bruno presented a slide based on the WG feedback on the mailing list (https://datatracker.ietf.org/meeting/101/materials/slides-101-spring-00-chairs-slides-01). During the Spring meeting, the WG agreed to add milestones to those items. In general, I see some milestones are not included in the proposed chartered text.

Specifically, multicast in SR is included in that list with the "Ingress replication SID (Tree SID /spray)" bullet (and support during the WG meeting) but is missing in the proposed charter text. So, I agree with Xiejingrong and Michael highlighting the same. There is already interest and agreement shown by the WG to include multicast in SR in the charter.

In the light of the above, please add a milestone for the WG to specify architecture, and the required protocol extensions for multicast in SR with MPLS and IPv6 data planes, including specification of the ingress replication SIDs (e.g., Tree SID, Spray). Nonetheless, I wholeheartedly agree that the actual protocol extension work should be done at the WG that owns the protocol.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of Rob Shakir <robjs=[email-masked]>
Date: Monday, June 4, 2018 at 12:45 PM
To: Michael McBride <[email-masked]>
Cc: Xiejingrong <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Michael,

Thanks for the comment.
On Mon, Jun 4, 2018 at 9:42 AM Michael McBride <[email-masked]<mailto:[email-masked]>> wrote:
It would be helpful, while updating the charter, to state whether multicast in SR is in/out of scope in order to know which wg to take our future work.

I think this is impractical. If we state everything that is in or out of scope, we'll end up with a laundry list. The aim of the charter is to define clearly the work that the WG should focus on. It does not mean that we can never host discussion of individual drafts if they are relevant. If there are requirements, we can always recharter if something new becomes the highest priority for the industry w.r.t SR.

Kind regards,
r.

---

From: "Voyer, Daniel" <[email-masked]>
Date: Wed, 6 Jun 2018 20:20:01 +0000

Hi all,

I support and agree w/ Zafar.

Multicast in SR is much needed and there is lots of development that needs to happen, whether for SRv6 or with SR-MPLS. The core architecture and development need to be included in this working group.

Thanks,
dan

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wednesday, June 6, 2018 at 3:14 PM
To: Rob Shakir <robjs=[email-masked]>, Michael McBride <[email-masked]>
Cc: Xiejingrong <[email-masked]>, "[email-masked]" <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

Thanks

Regards … Zafar

Michael,

Thanks for the comment.

Kind regards,
r.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 7 Jun 2018 14:47:59 +0000

Hi all,
I do not think that SPRING WG should deal with MC – possibly, excluding use of ingress replication for multicast.

This is based on what I see as the key element (highlighted) in definition of SPRING activities in the proposed charter:

To the best of my understanding, the only way for SR to provide this functionality forf multicast (be it SR-MPLS or SRV6) is ingress replication using unicast SR paths. In particular, the framework defined in draft-allan<https://tools.ietf.org/html/draft-allan-spring-mpls-multicast-framework-03> explicitly requires per-path state in the replication points.

From my POV the only technology that allows MC traffic to traverse the transit nodes without per-path state in the transit nodes and without multiple copies of the packet crossing the same link is BIER.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: spring [mailto:[email-masked]] On Behalf Of Voyer, Daniel
Sent: Wednesday, June 6, 2018 11:20 PM
To: Zafar Ali (zali) <[email-masked]>; Rob Shakir <robjs=[email-masked]>; Michael McBride <[email-masked]>
Cc: Xiejingrong <[email-masked]>; [email-masked]
Subject: Re: [spring] Updating the SPRING WG Charter

Hi all,

Thanks,
dan

From: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 6, 2018 at 3:14 PM
To: Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>, Michael McBride <[email-masked]<mailto:[email-masked]>>
Cc: Xiejingrong <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

Thanks

Regards … Zafar

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>
Date: Monday, June 4, 2018 at 12:45 PM
To: Michael McBride <[email-masked]<mailto:[email-masked]>>
Cc: Xiejingrong <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Updating the SPRING WG Charter

Michael,

Thanks for the comment.

Kind regards,
r.

___________________________________________________________________________

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: Thu, 7 Jun 2018 16:55:00 +0200

Hi Sasha,

I think there is technology to allow that.

Imagine a segment with embedded meaning that packets received with such
value X should be replicated to interfaces  Y & Z. Such decision can be
configured from controller or locally computed.

Nothing there is per-path as well as nothing there is per flow or per
multicast group. It is a local function.

Some folks call it SR-spray, I call it SR-fanout - but it does seems very
useful so I support keeping it in the proposed charter.

Many thx,
Robert,

On Thu, Jun 7, 2018 at 4:47 PM, Alexander Vainshtein <
[email-masked]> wrote:

> Hi all,
>
> I do not think that SPRING WG should deal with MC – possibly, excluding
> use of ingress replication for multicast.
>
>
>
> This is based on what I see as the key element (highlighted) in
> definition of SPRING activities in the proposed charter:
>
>
>
> To the best of my understanding, the only way for SR to provide this
> functionality forf multicast (be it SR-MPLS or SRV6) is ingress replication
> using unicast SR paths. In particular, the framework defined in
> draft-allan
> <https://tools.ietf.org/html/draft-allan-spring-mpls-multicast-framework-03>
> explicitly requires per-path state in the replication points.
>
>
>
> From my POV the only technology that allows MC traffic to traverse the
> transit nodes without per-path state in the transit nodes and without
> multiple copies of the packet crossing the same link is BIER.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> *From:* spring [mailto:[email-masked]] *On Behalf Of *Voyer,
> Daniel
> *Sent:* Wednesday, June 6, 2018 11:20 PM
> *To:* Zafar Ali (zali) <[email-masked]>; Rob Shakir <robjs=
> [email-masked]>; Michael McBride <[email-masked]>
> *Cc:* Xiejingrong <[email-masked]>; [email-masked]
>
> *Subject:* Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi all,
>
>
>
> Multicast in SR is much needed and there is lots of development that needs
> to happen, whether for SRv6 or with SR-MPLS. The core architecture and
> development need to be included in this working group.
>
>
>
> Thanks,
>
> dan
>
>
>
>
>
> *From: *"Zafar Ali (zali)" <[email-masked]>
> *Date: *Wednesday, June 6, 2018 at 3:14 PM
> *To: *Rob Shakir <robjs=[email-masked]>, Michael McBride <
> [email-masked]>
> *Cc: *Xiejingrong <[email-masked]>, "[email-masked]" <
> [email-masked]>, "Zafar Ali (zali)" <[email-masked]>
> *Subject: *Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi Rob,
>
>
>
> At IETF101, you and Bruno presented a slide based on the WG feedback on
> the mailing list (https://datatracker.ietf.org/
> meeting/101/materials/slides-101-spring-00-chairs-slides-01). During the
> Spring meeting, the WG agreed to add milestones to those items. In general,
> I see some milestones are not included in the proposed chartered text.
>
>
>
> Specifically, multicast in SR is included in that list with the "Ingress
> replication SID (Tree SID /spray)" bullet (and support during the WG
> meeting) but is missing in the proposed charter text. So, I agree with
> Xiejingrong and Michael highlighting the same. There is already interest
> and agreement shown by the WG to include multicast in SR in the charter.
>
>
>
> In the light of the above, please add a milestone for the WG to specify
> architecture, and the required protocol extensions for multicast in SR with
> MPLS and IPv6 data planes, including specification of the ingress
> replication SIDs (e.g., Tree SID, Spray). Nonetheless, I wholeheartedly
> agree that the actual protocol extension work should be done at the WG that
> owns the protocol.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *spring <[email-masked]> on behalf of Rob Shakir <
> robjs=[email-masked]>
> *Date: *Monday, June 4, 2018 at 12:45 PM
> *To: *Michael McBride <[email-masked]>
> *Cc: *Xiejingrong <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [spring] Updating the SPRING WG Charter
>
>
>
> Michael,
>
>
>
> Thanks for the comment.
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 7 Jun 2018 11:52:45 -0400

On 6/7/2018 10:55 AM, Robert Raszuk wrote:
> Imagine a segment with embedded meaning that packets received with 
> such value X should be replicated to interfaces  Y & Z. Such decision 
> can be configured from controller or locally computed.
>

How can you say "nothing there per-path"?  The label X represents a 
multicast tree, and thus constitutes per-path state.    If some packets 
need to go to Y and Z, some need to go to Y, Z, and W, some need to go 
to Y, U, and V, etc., you obviously need a different label for each 
different multicast tree, and appropriate per-tree state.

Using a controller to set up multicast paths may be a good idea in some 
scenarios, but let's not pretend it doesn't create per-path state in the 
router.  Per-path (per-tree) is not the same as per-flow or per-group, 
of course, but that's true of any technique that aggregates flows into 
multicast tunnels.

Note also that if the label X is domain-wide unique and there is no RPF 
check, there is the possibility of nasty multicast loops.  These is some 
discussion of this in draft-zzhang-bess-bgp-multicast-controller-00.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Jun 2018 18:04:18 +0200

Hi Eric,

The way I look at this is really not from the perspective of true dynamic
multicast with tree building etc .. .I look at this as anchor points to
replicate unicast flows into two or more endpoints maybe once or twice in
entire domain.

So for sure if you would try to apply this technique to distribute
traditional multicast there is tons of things which can go wrong and you
are better off with BIER.

But there are applications which on one side do not really require full
multicast yet they would benefit with content to be send once from server
and arrived at two or more caches. Maybe we just don't have the right name
for it in networking yet :)

Cheers,
R.

On Thu, Jun 7, 2018 at 5:52 PM, Eric C Rosen <[email-masked]> wrote:

> need to go to Y and Z, some need to go to Y, Z, and W, some need to go to
> Y, U, and V, etc., you obviously need a different label for each different
> multicast tree, and appropriate per-tree state.
>
> router.  Per-path (per-tree) is not the same as per-flow or per-group, of
> course, but that's true of any technique that aggregates flows into
> multicast tunnels.
>

---

From: Rob Shakir <[email-masked]>
Date: Thu, 7 Jun 2018 09:43:20 -0700

Zafar,

I intentionally left the list of milestones out of the mail. Clearly, we
need to agree the areas of work before we can break this down into
milestones. Equally, we have more flexibility in defining these since they
do not need to be reviewed by the IESG.

On Wed, Jun 6, 2018 at 12:14 PM Zafar Ali (zali) <zali=
[email-masked]> wrote:

> the mailing list (
> https://datatracker.ietf.org/meeting/101/materials/slides-101-spring-00-chairs-slides-01).
> During the Spring meeting, the WG agreed to add milestones to those items.
> In general, I see some milestones are not included in the proposed
> chartered text.
>
>
>

This list was a recap of what had been discussed on the mailing list. It
was not the proposed exhaustive list. The preference in the charter text
(after much discussion) is to ensure that SPRING has a set of focus areas
to work on. This does not preclude interested individuals doing other work
- and even bringing it to SPRING. We can change the charter in the future
if new work comes up that isn't within the charter.

I would point out that the narrow scope that we (the SPRING WG) initially
had to deliver on has taken almost five years since we initially discussed
it (see this thread
<https://www.ietf.org/mail-archive/web/status/current/msg00242.html>
regarding chartering STATUS as it was at the time). In this period of time,
real deployments of SR have happened, and the standards that they rely on
have not yet been published.  This is unfortunate for those that have
shipping implementations, or are relying on behaviours in their network.

I'd encourage us to focus on defining the problem spaces that are most
important and then work on those, deliver a standard, and then move on to
the next area. We can usually determine the importance/relevance of the
work to networks based on the number of interested parties - so the
intention of the list in the charter is to capture those elements which we
perceived to have widest interest in the charter. At some point, there will
be a line that is either "in the charter" or not, and some things below it
at the current time - yes, that might mean that one's favourite SR
application is not currently in the charter, but if there is significant
discussion on the list, and work items being brought as individual drafts,
we can always address this with Martin.

Thanks,
r.

---

From: David Allan I <[email-masked]>
Date: Thu, 7 Jun 2018 17:06:26 +0000

Would not the existence of SRLB’s be an existence proof of per-path state at transit nodes in the SPRING architecture?

Dave

From: spring <[email-masked]> On Behalf Of Alexander Vainshtein
Sent: Thursday, June 07, 2018 7:48 AM
To: Voyer, Daniel <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Rob Shakir <robjs=[email-masked]>; Michael McBride <[email-masked]>
Cc: Xiejingrong <[email-masked]>; [email-masked]
Subject: Re: [spring] Updating the SPRING WG Charter

Hi all,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: spring [mailto:[email-masked]] On Behalf Of Voyer, Daniel
Sent: Wednesday, June 6, 2018 11:20 PM
To: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>; Michael McBride <[email-masked]<mailto:[email-masked]>>
Cc: Xiejingrong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi all,

Thanks,
dan

Hi Rob,

Thanks

Regards … Zafar

Michael,

Thanks for the comment.

Kind regards,
r.

---

From: Rob Shakir <[email-masked]>
Date: Thu, 7 Jun 2018 10:10:18 -0700

On Thu, Jun 7, 2018 at 10:06 AM David Allan I <[email-masked]>
wrote:

> Would not the existence of SRLB’s be an existence proof of per-path state
> at transit nodes in the SPRING architecture?
>

No - SRLBs are just label block allocations on that node. The labels
allocated from an SRLB continue to be per-forwarding behaviour, not
per-path. In the degenerate case, we might have a 1:1 mapping of forwarding
behaviour to path, but this is implementation specific.

To demonstrate: consider the case that some programming entity creates a
SID that means forward to SR label stacks 1, 2, 3 -- this can be used by
any number of TE paths that are within that network.

r.

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 8 Jun 2018 05:11:08 +0000

Dave, Rob and all,
I concur with Rob on this point.

Thumb typed by Sasha Vainshtein

________________________________
From: Rob Shakir <[email-masked]>
Sent: Thursday, June 7, 2018 8:10:18 PM
To: David Allan I
Cc: Alexander Vainshtein; Voyer, Daniel; Zafar Ali (zali); Michael McBride; Xiejingrong; [email-masked]
Subject: Re: [spring] Updating the SPRING WG Charter

On Thu, Jun 7, 2018 at 10:06 AM David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
Would not the existence of SRLB’s be an existence proof of per-path state at transit nodes in the SPRING architecture?

No - SRLBs are just label block allocations on that node. The labels allocated from an SRLB continue to be per-forwarding behaviour, not per-path. In the degenerate case, we might have a 1:1 mapping of forwarding behaviour to path, but this is implementation specific.

To demonstrate: consider the case that some programming entity creates a SID that means forward to SR label stacks 1, 2, 3 -- this can be used by any number of TE paths that are within that network.

r.

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 8 Jun 2018 14:53:00 +0000

Robert,
I concur with Eric.

I also think that the scenarios you describe as relevant for SR-fan-out/SR-spray (“applications which on one side do not really require full multicast yet they would benefit with content to be send once from server and arrived at two or more caches”) strongly resembles IGMP/MLD Proxy applications (RFC 4605<https://tools.ietf.org/html/rfc4605>). Is such an analogy correct?

Last but not least, it seems that your description of SR-fan-out mandates usage of domain-wide labels (mentioned by Eric as well_. If this is indeed so, I consider this as a stopper because usage of domain-wide labels has been discussed many times in the past and rejected by the MPLS WG.

Regards,
Sasha

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 7, 2018 7:04 PM
To: Eric C Rosen <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; [email-masked]; Xiejingrong <[email-masked]>; Michael McBride <[email-masked]>; Rob Shakir <robjs=[email-masked]>; Zafar Ali (zali) <[email-masked]>; Voyer, Daniel <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Eric,

The way I look at this is really not from the perspective of true dynamic multicast with tree building etc .. .I look at this as anchor points to replicate unicast flows into two or more endpoints maybe once or twice in entire domain.

So for sure if you would try to apply this technique to distribute traditional multicast there is tons of things which can go wrong and you are better off with BIER.

But there are applications which on one side do not really require full multicast yet they would benefit with content to be send once from server and arrived at two or more caches. Maybe we just don't have the right name for it in networking yet :)

Cheers,
R.

On Thu, Jun 7, 2018 at 5:52 PM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:
On 6/7/2018 10:55 AM, Robert Raszuk wrote:

Imagine a segment with embedded meaning that packets received with such value X should be replicated to interfaces  Y & Z. Such decision can be configured from controller or locally computed.

Nothing there is per-path as well as nothing there is per flow or per multicast group. It is a local function.

How can you say "nothing there per-path"?  The label X represents a multicast tree, and thus constitutes per-path state.    If some packets need to go to Y and Z, some need to go to Y, Z, and W, some need to go to Y, U, and V, etc., you obviously need a different label for each different multicast tree, and appropriate per-tree state.

Using a controller to set up multicast paths may be a good idea in some scenarios, but let's not pretend it doesn't create per-path state in the router.  Per-path (per-tree) is not the same as per-flow or per-group, of course, but that's true of any technique that aggregates flows into multicast tunnels.

Note also that if the label X is domain-wide unique and there is no RPF check, there is the possibility of nasty multicast loops.  These is some discussion of this in draft-zzhang-bess-bgp-multicast-controller-00.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 Jun 2018 16:59:09 +0200

Sasha,

> because usage of domain-wide labels has been discussed many times in the
past and rejected by the MPLS WG.

That comment I quite do not follow. Entire concept of SR-MPLS  is based on
domain wide labels (distributed via IGP or OOB) and my description applies
to SR based networks with both MPLS as well as v6 encap.

In other words we already have domain wide MPLS labels to indicate various
types of segments. What I proposed would at most require perhaps new type
which would embed node + replication function.

Thx,
R.

On Fri, Jun 8, 2018 at 4:53 PM, Alexander Vainshtein <
[email-masked]> wrote:

> Robert,
>
> I concur with Eric.
>
>
>
> I also think that the scenarios you describe as relevant for
> SR-fan-out/SR-spray (“applications which on one side do not really
> require full multicast yet they would benefit with content to be send once
> from server and arrived at two or more caches”) strongly resembles
> IGMP/MLD Proxy applications (RFC 4605
> <https://tools.ietf.org/html/rfc4605>). Is such an analogy correct?
>
>
>
> Last but not least, it seems that your description of SR-fan-out mandates
> usage of domain-wide labels (mentioned by Eric as well_. If this is indeed
> so, I consider this as a stopper because usage of domain-wide labels has
> been discussed many times in the past and rejected by the MPLS WG.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, June 7, 2018 7:04 PM
> *To:* Eric C Rosen <[email-masked]>
> *Cc:* Alexander Vainshtein <[email-masked]>;
> [email-masked]; Xiejingrong <[email-masked]>; Michael McBride <
> [email-masked]>; Rob Shakir <robjs=[email-masked]>;
> Zafar Ali (zali) <[email-masked]>; Voyer, Daniel <[email-masked]>

---

From: Paul Mattes <[email-masked]>
Date: Fri, 8 Jun 2018 19:02:47 +0000

We don’t have domain-wide labels. We have domain-wide indices. The same index is represented with different label values by different hosts, depending on their SRGBs.

        pdm

From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Friday, June 8, 2018 9:59 AM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; Xiejingrong <[email-masked]>; Michael McBride <[email-masked]>; Rob Shakir <robjs=[email-masked]>; Zafar Ali (zali) <[email-masked]>; Eric C Rosen <[email-masked]>; Voyer, Daniel <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Sasha,

> because usage of domain-wide labels has been discussed many times in the past and rejected by the MPLS WG.

That comment I quite do not follow. Entire concept of SR-MPLS  is based on domain wide labels (distributed via IGP or OOB) and my description applies to SR based networks with both MPLS as well as v6 encap.

In other words we already have domain wide MPLS labels to indicate various types of segments. What I proposed would at most require perhaps new type which would embed node + replication function..

Thx,
R.

On Fri, Jun 8, 2018 at 4:53 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Robert,
I concur with Eric.

I also think that the scenarios you describe as relevant for SR-fan-out/SR-spray (“applications which on one side do not really require full multicast yet they would benefit with content to be send once from server and arrived at two or more caches”) strongly resembles IGMP/MLD Proxy applications (RFC 4605<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4605&data=02%7C01%7Cpamattes%40microsoft.com%7C555c978a313441d9e0f508d5cd506e42%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636640667691087492&sdata=I1uK8l1aISD61f8E%2BH2Mt10v8RQ1W%2Bh2bS4pl%2BB%2BgOw%3D&reserved=0>). Is such an analogy correct?

Regards,
Sasha

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, June 7, 2018 7:04 PM
To: Eric C Rosen <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Xiejingrong <[email-masked]<mailto:[email-masked]>>; Michael McBride <[email-masked]<mailto:[email-masked]>>; Rob Shakir <robjs=[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Voyer, Daniel <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Eric,

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 Jun 2018 21:48:25 +0200

​The below sentence I am going to frame next to the best quotes ever ....
Thank you Paul !

We don’t have domain-wide labels. We have domain-wide indices. The same
> index is represented with different label values by different hosts,
> depending on their SRGBs.
>
>
>
>         *pdm*
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 8 Jun 2018 20:21:32 +0000

Robert, Paul and all,
I concur with Paul.
Domain-wide labels have been successfully purged from SR-MPLS for quite some time now, and, from my POV this purge is irreversible now.

My 2c.

________________________________
From: Paul Mattes <[email-masked]>
Sent: Friday, June 8, 2018 10:02:47 PM
To: Robert Raszuk; Alexander Vainshtein
Cc: [email-masked]; Xiejingrong; Michael McBride; Rob Shakir; Zafar Ali (zali); Eric C Rosen; Voyer, Daniel
Subject: RE: [spring] Updating the SPRING WG Charter

        pdm

Sasha,

Thx,
R.

Regards,
Sasha

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

Hi Eric,

Cheers,
R.

---

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 8 Jun 2018 20:23:35 +0000

Inline [DV]

This list was a recap of what had been discussed on the mailing list. It was not the proposed exhaustive list.
[DV] I thought this was a list proposed by the working group as a response to AD’s request ? Didn’t we debate this list in our last wg meeting ?!

The preference in the charter text (after much discussion) is to ensure that SPRING has a set of focus areas to work on. This does not preclude interested individuals doing other work - and even bringing it to SPRING. We can change the charter in the future if new work comes up that isn't within the charter.

I would point out that the narrow scope that we (the SPRING WG) initially had to deliver on has taken almost five years since we initially discussed it (see this thread<https://www.ietf.org/mail-archive/web/status/current/msg00242.html> regarding chartering STATUS as it was at the time). In this period of time, real deployments of SR have happened, and the standards that they rely on have not yet been published..
[DV] hence my point of pushing for P2MP like trees (ingress replication SID) in SR-MPLS/SRv6 network. This is a critical requirement for Bell Canada, at least ..
[DV] Also, noticed that the work is already going on in the working group, as it is part of the SR policy architecture-draft – section 9.2 – which is an now a working group document.

This is unfortunate for those that have shipping implementations, or are relying on behaviours in their network.
[DV] yep, unfortunate, indeed. We don’t want to repeat the same mistake for ingress replication SID, don’t we ?

[..sniff]

Thanks,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 Jun 2018 22:43:40 +0200

Folks,

The only reason why SR-MPLS architecture is using indexes as opposed to
domain wide labels is a claim from few folks that possibly in some networks
deployed platforms would not be able to use the same global label block for
SR.

So SR-MPLS architecture agreed to use index to offset possible per platform
label block.

That said number of real deployment do use global (domain wide) identical
block on all nodes and that is the actual recommendation from section 3.1.2
of SR architecture

"Where possible, it is recommended that identical SRGBs be configured on
all nodes in an SR Domain."

But none of this really matters for the discussion at hand. Embedding
instruction for specific function can be easily done within programmed
domain wide index offset.

Best,
R.

On Fri, Jun 8, 2018 at 10:21 PM, Alexander Vainshtein <
[email-masked]> wrote:

> Robert, Paul and all,
> I concur with Paul.
> Domain-wide labels have been successfully purged from SR-MPLS for quite
> some time now, and, from my POV this purge is irreversible now.
>
> My 2c.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 9 Jun 2018 18:53:54 +0000

Robert,
I think that you have cut the quoted text from the Segment Routing Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> draft a bit too short. The complete fragment says:

   Where possible, it is recommended that identical SRGBs be configured
   on all nodes in an SR Domain.  This simplifies troubleshooting as the
   same label will be associated with the same prefix on all nodes.  In
   addition, it simplifies support for anycast as detailed in
   Section 3.3<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.3>.

In other words,  the Segment Routing Architecture draft:

-          Does not consider identical SRGBs on all nodes in an SR domain as a requirement.

-          Explains that such configuration, if used, simplifies troubleshooting and support of anycast segments. With regard to the latter, please note that the Anycast Segments<https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-02> draft defines a mechanism that facilitates usage of anycast segments in an environment with different SRGBs on different nodes.

Therefore, from my POV, domain-wide labels have been purged (for quite some time now) from the SR-MPLS architecture. I do not think that they should be re-introduced.

My 2c,
Sasha

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, June 8, 2018 11:44 PM
To: Alexander Vainshtein <[email-masked]>
Cc: Paul Mattes <[email-masked]>; [email-masked]; Xiejingrong <[email-masked]>; Michael McBride <[email-masked]>; Rob Shakir <robjs=[email-masked]>; Zafar Ali (zali) <[email-masked]>; Eric C Rosen <[email-masked]>; Voyer, Daniel <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Folks,

The only reason why SR-MPLS architecture is using indexes as opposed to domain wide labels is a claim from few folks that possibly in some networks deployed platforms would not be able to use the same global label block for SR.

So SR-MPLS architecture agreed to use index to offset possible per platform label block.

That said number of real deployment do use global (domain wide) identical block on all nodes and that is the actual recommendation from section 3.1.2 of SR architecture

"Where possible, it is recommended that identical SRGBs be configured on all nodes in an SR Domain."

But none of this really matters for the discussion at hand. Embedding instruction for specific function can be easily done within programmed domain wide index offset.

Best,
R.

On Fri, Jun 8, 2018 at 10:21 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Robert, Paul and all,
I concur with Paul.
Domain-wide labels have been successfully purged from SR-MPLS for quite some time now, and, from my POV this purge is irreversible now.
My 2c.
Thumb typed by Sasha Vainshtein

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Jun 2018 21:50:26 +0200

Sasha,

1. Where did I say it is a requirement ? My quote was precise and it
clearly said that this is recommended.

2. Nothing in this thread requires use of domain-wide labels. All required
functionality will work just fine with domain-wide indexes - so even we I
or anyone one else said here anything about "domain-wide labels" fell free
to substitute it with "domain-wide index" if this will make you happy.

3. To constructively move fwd let me propose we drop SR-MPLS all together
from support of spray or fan-out functionality in the charter and just make
sure charter reflect such support for SRv6 only. Now let's sit and watch
how the proponents of index based offset instead of global SRGB will react
if MPLS based network will miss such useful functionality :)

Cheers,
R.

On Sat, Jun 9, 2018 at 8:53 PM, Alexander Vainshtein <
[email-masked]> wrote:

> Robert,
>
> I think that you have cut the quoted text from the Segment Routing
> Architecture
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> draft
> a bit too short. The complete fragment says:
>
>
>
>    Section 3.3
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.3>
> .
>
>
>
> -          Explains that such configuration, if used, simplifies
> troubleshooting and support of anycast segments. With regard to the latter,
> please note that the Anycast Segments
> <https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-02>
> draft defines a mechanism that facilitates usage of anycast segments in an
> environment with different SRGBs on different nodes.
>
>
>
> Therefore, from my POV, domain-wide labels have been purged (for quite
> some time now) from the SR-MPLS architecture. I do not think that they
> should be re-introduced.
>
>
>
> My 2c,
>
> Sasha
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 10 Jun 2018 05:39:35 +0000

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

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Saturday, June 9, 2018 10:50 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; Xiejingrong <[email-masked]>; Michael McBride <[email-masked]>; Rob Shakir <robjs=[email-masked]>; Paul Mattes <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Eric C Rosen <[email-masked]>; Voyer, Daniel <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Sasha,

1. Where did I say it is a requirement ? My quote was precise and it clearly said that this is recommended.

2. Nothing in this thread requires use of domain-wide labels. All required functionality will work just fine with domain-wide indexes - so even we I or anyone one else said here anything about "domain-wide labels" fell free to substitute it with "domain-wide index" if this will make you happy.

3. To constructively move fwd let me propose we drop SR-MPLS all together from support of spray or fan-out functionality in the charter and just make sure charter reflect such support for SRv6 only. Now let's sit and watch how the proponents of index based offset instead of global SRGB will react if MPLS based network will miss such useful functionality :)

Cheers,
R.

On Sat, Jun 9, 2018 at 8:53 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Robert,
I think that you have cut the quoted text from the Segment Routing Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> draft a bit too short. The complete fragment says:

My 2c,
Sasha

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 10 Jun 2018 11:58:18 +0200

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

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

---

From: Loa Andersson <[email-masked]>
Date: Mon, 18 Jun 2018 10:48:49 +0200

Rob,

Two things

- do we have an available current state of the charter-to-bu-updated
   text.
- inline plz

On 2018-06-04 18:44, Rob Shakir wrote:
> Michael,
> 
> Thanks for the comment.
> 
> On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     multicast in SR is in/out of scope in order to know which wg to take
>     our future work.
> 
> 
> I think this is impractical. 

Yes, I agree that it is impractical have "everything" out of scope
listed. However for things being brought up for discussion we need
clear decisions/consensus documented on the mailing list.

Does your statement mean that "multicast in SR" is out of scope for
SPRING?

/Loa

If we state everything that is in or out of
> define clearly the work that the WG should focus on. It does not mean 
> that we can never host discussion of individual drafts if they are 
> relevant. If there are requirements, we can always recharter if 
> something new becomes the highest priority for the industry w.r.t SR.
> 
> Kind regards,
> r.
> 
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: <[email-masked]>
Date: Mon, 18 Jun 2018 16:40:46 +0000

Hi Daniel,

Could you clarify what you mean by “Multicast in SR”?
I could think of four different things:
a) locally allocating a SID to some existing replication structures, such as tree installed in the FIB (PIM, mLDP, P2MP RSVP-TE…), tree defined in the packet (BIER), ingress replication on interfaces/tunnels. The latter been called “Spray” in some documents.
b) a new way to signal and install tree in FIB across the networks
c) a new way to install tree in FIB across the networks without explicit signaling of the trees
d) a new way to encode tree in the packet without creating states in the network.
e) others?

On my side, “a” seems a reasonable, short and constraint extension(s), “d” seems like a duplication of BIER.

Regards,
--Bruno

From: spring [mailto:[email-masked]] On Behalf Of Voyer, Daniel
Sent: Wednesday, June 06, 2018 10:20 PM
To: Zafar Ali (zali); Rob Shakir; Michael McBride
Cc: Xiejingrong; [email-masked]
Subject: Re: [spring] Updating the SPRING WG Charter

Hi all,

Thanks,
dan

Hi Rob,

Thanks

Regards … Zafar

Michael,

Thanks for the comment.

Kind regards,
r.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Voyer, Daniel" <[email-masked]>
Date: Mon, 18 Jun 2018 20:44:45 +0000

Hi Bruno,
Yes, I agree that option “a” seems reasonable to me as well.

Thanks
dan

From: Bruno Decraene <[email-masked]>
Date: Monday, June 18, 2018 at 12:40 PM
To: "Voyer, Daniel" <[email-masked]>
Cc: Xiejingrong <[email-masked]>, "[email-masked]" <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, Rob Shakir <robjs=[email-masked]>, Michael McBride <[email-masked]>
Subject: RE: [spring] Updating the SPRING WG Charter

Hi Daniel,

Regards,
--Bruno

Hi all,

Thanks,
dan

Hi Rob,

Thanks

Regards … Zafar

Michael,

Thanks for the comment.

Kind regards,
r.

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 19 Jun 2018 14:36:33 +0100

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:
> Based on number of WG members input expressed both at the meeting and 
> on the list  I hope
> ​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-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Robert,
>
>     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.
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Jun 2018 15:39:27 +0200

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-masked]>
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
>
> spring mailing [email-masked]://www.ietf.org/mailman/listinfo/spring
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 19 Jun 2018 17:06:06 +0100

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:
> 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-masked] <mailto:[email-masked]>> wrote:
>
>     For clarification:
>
>     series of  unicast SR paths each to an installed multicast tree
>     close to egress?
>
>     - Stewart
>
>
>>     Based on number of WG members input expressed both at the meeting
>>     and on the list  I hope
>>     ​PS. Btw - I am also ok that ingress replication is not relevant
>>     to SPRING as it essentially happens at the
>>     ingress to the domain. ​
>>
>>
>>
>>         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:
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/spring>
>
>