Re: [pim] [EXTERNAL] Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Rishabh Parekh <[e-mail]>]

Sasha,

*[[Sasha]] My reading of your response is as following: *

*In principle It is possible to create MP2MP SR Policies by including
Downstream Replication SID in the Replication State of multiple Replication
SIDs defined in different upstream nodes.  However, such usage is
intentionally left out of scope of this draft as well as the PIM SR P2MP
draft and the BESS MVPN/EVPN draft.*



*If this reading is correct, I suggest adding a corresponding clarification
in the text of the corresponding drafts, especially in the text of the BESS
MVPN/EVPN one because at least MVPN deals with MP2MP P-tunnels from Day 1
(not sure about EVPN). *

None of the above drafts are about MP2MP trees, but we can keep the
behavior of multiple upstream replication segments sending packets with
same downstream Replication SID as out of scope of Replication Segment
draft and maybe explicitly keep MP2MP trees out of scope of PIM WG draft.
BESS MVPN/EVPN draft should follow because it is based on the Replication
Segment and PIM SR P2MP drafts.

-Rishabh

On Mon, Dec 12, 2022 at 1:12 AM Alexander Vainshtein <
[e-mail]> wrote:

> Rishabh,
>
> Lots of thanks for a prompt and very encouraging response.
>
> Please see more inline below marked *[[Sasha]].*
>
>
>
> Regards,
>
> Sasha
>
>
>
> *From:* Rishabh Parekh <[e-mail]>
> *Sent:* Sunday, December 11, 2022 9:04 PM
> *To:* Alexander Vainshtein <[e-mail]>
> *Cc:* [e-mail];
> [e-mail]; [e-mail]; SPRING WG <[e-mail]>; James
> Guichard <[e-mail]>; Nitsan Dolev <
> [e-mail]>; Michael Gorokhovsky <[e-mail]>;
> Ron Sdayoor <[e-mail]>
> *Subject:* [EXTERNAL] Re: [spring] WGLC for
> draft-ietf-spring-sr-replication-segment
>
>
>
> Sasha,
>
> Inline @ [RP]
>
>
>
> On Sun, Dec 11, 2022 at 3:43 AM Alexander Vainshtein <
> [e-mail]> wrote:
>
> Hi all,
>
> More questions regarding the definition of the Replication State of a
> Replication Segment:
>
>
>
> The draft states that:
>
>
>
> If a Downstream Node is an egress (aka leaf) of the multi-point service,
> i.e. no further replication is needed, then that leaf node's Replication
> segment will not have any Replication State…
>
>
>
> IMHO this is not aligned with the definition of the elements of the
> Replication Segment (already quoted below) and Replication State. It would
> be more appropriate to express the behavior of a Leaf node by stating that
> its Replication state (defined as quoted below) is *an empty list of
> branches*.
>
>
>
> With this approach a Replication SID of a bud node of a service could be
> defined as  an SID with the Replication state including,  as one of the
> branches – but not the only branch in the list - a Replication SID with
> itself as the Node-ID and with an empty list of branches.
>
>
>
> [RP] The text " leaf node's Replication segment will not have any
> Replication State…" effectively means an empty list of branches with an
> indicator of Leaf role in a Replication Segment.
>
> *[[Sasha]]** My reading of the above is that we agree on the actual
> meaning of the text of the draft. From my POV, explicitly stating this
> meaning would help the readers, but this is a matter of taste.*
>
> A bud node is a combination
>
> My question is:
>
>
>
> Can the same "Downstream Replication ID in a given "Downstream Node"  be
> included/ in the Replication state of multiple Replication segments,
> especially of Replication segments identified by different Node IDs?
>
>
>
> [RP] I assume you meant to ask  "Can the same Downstream Replication *SID*
> in a given ...." .
>
> *[[Sasha]]** Yes, of course I meant SID. *
>
>
>
>
>
> I have not found any answer to this question in the text of the draft. At
> the same time I think that a positive answer to my question would
> contradict the definitions in Section 3.1 of the MVPN and EVPN with SR
> P2MP and Ingress Replication draft
> <https://clicktime.symantec.com/15t5ZsGQy3PKVC5rnKF2J?h=0xFR-Lib2WgWUxY77NS9dntWdLj3ZVPPXNXYgwA0hG0=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp-06%23name-mpls-label>
> because these definitions assume that the Replication SID can be used as
> the "context label" for resolving the context label space space for looking
> up the upstream allocated label advertised in the PTA attribute of the
> suitable Mutlicast VPN route (in the case of aggregated P-tunnels).
>
>
>
> IMHO and FWIW an explicit and unambiguous answer to my question should be
> provided by the authors in order to advance the draft.
>
>
>
> [RP] The answer is theoretically yes, but that would be like trying to
> share a Replication Segment across different SR-P2MP trees (described in
> PIM WG SR P2MP draft). This requires a complex set of conditions that have
> to be met to make it work and hence we have kept it out of scope of this
> draft, PIM SR P2MP draft and the BESS MVPN/EVPN draft.
>
>
>
> Just to clarify, Section 3.1 of BESS MVPN/EVPN covers the case where a
> *single* SR-P2MP tree is shared across two or more MPVNs and hence an
> upstream (or centrally) assigned "context" is required in packet encoding
> to resolve the MVPN in which payload is processed. When a SR-P2MP tree is
> associated with only one MPVN, this upstream "context" not required in
> packet; the Replication SID at Leaf/Bud is sufficient to provide the MVPN
> context in which payload is processed.
>
>
>
> *[[Sasha]] My reading of your response is as following: *
>
> *In principle It is possible to create MP2MP SR Policies by including
> Downstream Replication SID in the Replication State of multiple Replication
> SIDs defined in different upstream nodes.  However, such usage is
> intentionally left out of scope of this draft as well as the PIM SR P2MP
> draft and the BESS MVPN/EVPN draft.*
>
>
>
> *If this reading is correct, I suggest adding a corresponding
> clarification in the text of the corresponding drafts, especially in the
> text of the BESS MVPN/EVPN one because at least MVPN deals with MP2MP
> P-tunnels from Day 1 (not sure about EVPN). *
>
>
>
> I hope I have answered your questions,
>
> -Rishabh
>
>
>
>
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
>