Re: [spring] Updating the SPRING WG Charter

[<[e-mail]>]

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:[e-mail]] On Behalf Of Voyer, Daniel
Sent: Wednesday, June 06, 2018 10:20 PM
To: Zafar Ali (zali); Rob Shakir; Michael McBride
Cc: Xiejingrong; [e-mail]
Subject: Re: [spring] Updating the SPRING WG Charter

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)" <[e-mail]>
Date: Wednesday, June 6, 2018 at 3:14 PM
To: Rob Shakir <robjs=[e-mail]>, Michael McBride <[e-mail]>
Cc: Xiejingrong <[e-mail]>, "[e-mail]" <[e-mail]>, "Zafar Ali (zali)" <[e-mail]>
Subject: Re: [spring] Updating the SPRING WG Charter

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 <[e-mail]> on behalf of Rob Shakir <robjs=[e-mail]>
Date: Monday, June 4, 2018 at 12:45 PM
To: Michael McBride <[e-mail]>
Cc: Xiejingrong <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [spring] Updating the SPRING WG Charter

Michael,

Thanks for the comment.
On Mon, Jun 4, 2018 at 9:42 AM Michael McBride <[e-mail]<mailto:[e-mail]>> 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.

_________________________________________________________________________________________________________________________

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.