Subject: Re: [spring] WG adoption call for draft-voyer-spring-sr-replication-segment

From: Rishabh Parekh <[email-masked]>
Date: Wed, 1 Jul 2020 09:18:29 -0700

Huaimo,
Responses inline below.

On Tue, Jun 30, 2020 at 7:46 AM Huaimo Chen <[email-masked]> wrote:
>
> Hi Authors,
>
>     I have a few of questions.
>
>     Should a replication-segment be generalized to be a special SID (say a multicast SID allocated from a multicast SID block)?
,
[RP] This is a good question. We have left this unspecified in draft
because the Replication SID can be assigned either from SRGB, in which
case it would be same on all nodes of Replication segment, or from
SRLB where it could be different on the nodes.
>
>     Should a replication-segment be associated with just a set of downstream SIDs without the  node-IDs? Where the downstream SIDs may be replication-segments or normal SIDs in some cases (for example when the downstream nodes are egresses).

[RP] I don't understand the question. Can you clarify what you mean by
"... without Node-IDs"? Note that Node-IDs are part of the Replication
segment state, but only Replication SIDs are in the label stack.
>
>     Should a state in a node for a replication-segment be removed? If a state is stored in a node (each node) for a (each) replication segment of a (each) SR P2MP path, there may be some scalability issue. This seems not consistent with the principles of the segment routing, in which no state is stored in the core of the network.

[RP] As mentioned in Introduction of the draft, there is no state
required on intermediate nodes that are not part of a Replication
segment.

>
> Best Regards,
> Huaimo
> -----Original Message-----
> From: spring <[email-masked]> On Behalf Of Stone, Andrew (Nokia - CA/Ottawa)
> Sent: Monday, June 22, 2020 2:44 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [spring] WG adoption call for draft-voyer-spring-sr-replication-segment
>
> Hi Spring WG
>
> Support adoption.
>
> Willing to work on the document, and already participating in related documents in PCE and IDR.
>
> Thanks
> Andrew
>
>
> On 2020-06-22, 10:46 AM, "spring on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:
>
>     Hi SPRING WG,
>
>     Authors of draft-voyer-spring-sr-replication-segment [1] have asked for WG adoption.
>
>     Please indicate your support, comments, or objection, for adopting this draft as a working group item by July 6th 2020.
>
>     Could those who are willing to work on this document, please notify the list. That gives us an indication of the energy level in the working group to work on this.
>
>     As a reminder, the call for IPR has been done last November. [2]
>
>     Thanks,
>     Regards,
>     Bruno, Jim, Joel
>
>     [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-voyer-spring-sr-replication-segment&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce48fdc087ead47f7a46e08d816fe4085%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637284628562490951&amp;sdata=0yc%2BfZ4uA72ldbCIevjFKvFQA%2BSp2Wh7%2BOdCZsM4yaI%3D&amp;reserved=0
>     [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2FtW-HHK7QzCw3ZBbFD0Dl7Eszd3k%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce48fdc087ead47f7a46e08d816fe4085%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637284628562490951&amp;sdata=2e1JSoFWYpZfLe9ODWtGjI%2B82O0Y4cFCeKDGo8%2Fe%2FIs%3D&amp;reserved=0
>
>
>     _________________________________________________________________________________________________________________________
>
>     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.
>
>     _______________________________________________
>     spring mailing list
>     [email-masked]
>     https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce48fdc087ead47f7a46e08d816fe4085%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637284628562490951&amp;sdata=2hoiiN9lCan74sNUI8WNQnpBEDTVH8QK0RA1Y47yP7Y%3D&amp;reserved=0
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce48fdc087ead47f7a46e08d816fe4085%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637284628562490951&amp;sdata=2hoiiN9lCan74sNUI8WNQnpBEDTVH8QK0RA1Y47yP7Y%3D&amp;reserved=0
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce48fdc087ead47f7a46e08d816fe4085%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637284628562490951&amp;sdata=2hoiiN9lCan74sNUI8WNQnpBEDTVH8QK0RA1Y47yP7Y%3D&amp;reserved=0
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 6 Jul 2020 16:57:43 +0000

Hi Rishabh,

    My responses are inline below.

Best Regards,
Huaimo
________________________________
From: Rishabh Parekh <[email-masked]>
Sent: Wednesday, July 1, 2020 12:18 PM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [spring] WG adoption call for draft-voyer-spring-sr-replication-segment

Huaimo,
Responses inline below.

,

[HC]: Why do you need Node-IDs? When you have a special SID, say a multicast SID, which is associated with a set of downstream (or next hop nodes) SIDs, you can replicate the packet received from an incoming interface and send the duplicated the packet to each of the downstream nodes according to the set of downstream SIDs.

[HC]: Can you show an example of this (one SR point-to-multipoint path transports a packet from its ingress via some core nodes to its egresses without any state stored in the core nodes for this SR P2MP path) ?

>     [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-voyer-spring-sr-replication-segment&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C2061c4b4596e4647737d08d81dda6dbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637292171267645261&amp;sdata=ZQa9%2FFgjYwePEyXWeNlOvekIvv1DB1f1hJDUecS9iKU%3D&amp;reserved=0
>     [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2FtW-HHK7QzCw3ZBbFD0Dl7Eszd3k%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C2061c4b4596e4647737d08d81dda6dbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637292171267645261&amp;sdata=BjE9TjNEqXZPEOXrF86Zt68XX5K93dRai%2F%2B1AwSu3CU%3D&amp;reserved=0
>
>
>     https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C2061c4b4596e4647737d08d81dda6dbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637292171267645261&amp;sdata=Aok48niQK46yMdvAWh%2FsJa01E0U%2BfBJ%2BePOlk3BvGFs%3D&amp;reserved=0
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C2061c4b4596e4647737d08d81dda6dbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637292171267645261&amp;sdata=Aok48niQK46yMdvAWh%2FsJa01E0U%2BfBJ%2BePOlk3BvGFs%3D&amp;reserved=0
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C2061c4b4596e4647737d08d81dda6dbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637292171267650230&amp;sdata=jrulBMnoHAUduH5S20XS5G6BeU8M2ym3AdIv48TV7tM%3D&amp;reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C2061c4b4596e4647737d08d81dda6dbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637292171267650230&amp;sdata=jrulBMnoHAUduH5S20XS5G6BeU8M2ym3AdIv48TV7tM%3D&amp;reserved=0

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 6 Jul 2020 21:01:43 +0000

Hi Huaimo,

if I may, responding to “[HC]: Can you show an example of this (one SR point-to-multipoint path transports a packet from its ingress via some core nodes to its egresses without any state stored in the core nodes for this SR P2MP path) ? “

Section 2 states:

Alternatively, a Downstream Node
could be represented by a SID-list or a Segment Routing Policy
[I-D.ietf-spring-segment-routing-policy] that partially/fully
specifies the explicit path from the Replication Node to the
Downstream Node, or even represented by another Replication segment.

Take the following example topology:

A ---- B  ---- C  --- D --- E
         \
          \ --  X  --- Y --- Z

Topology supports segment routing, advertised via IGP.
Let's say every node has a node SID and each edge has an adjacency SID.

A is a root.
B is a transit node performing replication.
E & Z are leaves.
C,D,X,Y could be considered core/non replicating nodes.

A contains the P2MP Policy and appropriate Replication Segment to egress replicate to B.
B contains a replication segment. B replication segment has 2 downstream nodes (E, Z).

Replication Segment on B has 2 egress SID lists. For each SID list, the SID list contains the appropriate SIDs to make the traffic reach the downstream [E:(B,C,D)] and [Z:(X,Y,Z)] using any combination of adjacency and/or node. The bottom SID in the list is equal to the ingress replication SID defined on the appropriate E and Z replication segment. So the stack contains downstreamIngressReplicationSid and SID Path. E and Z are configured with appropriate replication segments with the expected ingress replication SID. Therefore C,D,X,Y do not need replication segment state information and forward using existing SR mechanisms.

Cheers
Andrew

From: spring <[email-masked]> on behalf of Huaimo Chen <[email-masked]>
Date: Monday, July 6, 2020 at 12:58 PM
To: Rishabh Parekh <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] WG adoption call for draft-voyer-spring-sr-replication-segment

Hi Rishabh,

Best Regards,
Huaimo

Huaimo,
Responses inline below.

,

> On 2020-06-22, 10:46 AM, "spring on behalf of [email-masked]" <[email-masked] on behalf of bruno.decraene@orange..com> wrote:
>
>     Hi SPRING WG,
>