Re: [spring] Understanding the replication draft

Hi WG,

Reading the I-D and based on the discussion on this thread I believe
more description is required. As Joel pointed out, clarity on what is
legal/illegal (or out of scope for now) is needed.

I have no strong opinion if that needs to be done before or after adoption!

I do not follow PIM closely and just realized that the SR P2MP Policy
in the PIM I-D [1] is adopted by the PIM WG, but not yet posted [2].
I wanted to make sure that it has been decided that PIM is the right
place to define SR P2MP policy (discussed either in the WG and/or
between chairs/AD)?

Thanks!
Dhruv

[1] https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/
[2] https://mailarchive.ietf.org/arch/msg/pim/YyF7I02aaRtpZngf7uTno69IB90/

On Thu, Jul 2, 2020 at 12:05 PM Rishabh Parekh <rishabhp@gmail.com> wrote:
>
> Jeff,
> Your explanation of distinct Transport SIDs and service labels (which
> appear at BoS) applies to Point-to-Point services. Same model can be
> applied when a Point-to-Multipoint service is realized by one
> end-to-end replication segment; "Downstream Replication SID" as
> specified in draft is effectively the service label at a specific
> downstream node of a Replication segment with Transport SIDs imposed
> on top to take replicated packet to that node.
>
> However, when a Point-to-Multipoint service is over replication
> segments stitched together to form a P2MP tree, as described in PIM WG
> draft, this model no longer holds since all service egress nodes would
> have to agree on one common service label. So  P2MP services
> implicitly map the P2MP transport label (Replication SID at BoS in
> this case) to the P2MP service. Of course, this implies one-to-one
> association between a P2MP service and a P2MP transport. There are
> techniques to share one P2MP transport across different P2MP services
> using either upstream assigned label or a global context from
> "Domain-wide Common Block"
> (draft-ietf-bess-mvpn-evpn-aggregation-label). These and other gory
> details are described in Section 2 of PIM WG draft and to some extent
> in BESS MVPN-EVPN draft.
>
> -Rishabh
>
> On Wed, Jul 1, 2020 at 5:50 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
> >
> > Rishabh,
> >
> > Transport SID with a service on top can’t be a BoS label, there’s s service label below, since a service is associated with a particular node, there would be at least a N-SID associated with the service node.
> > It seems like B-SID behavior is the correct one, when R-SID is looked up and popped, it would yield: replication  (as programmed by a controller, since there’s no state) + new label stack associated with the new, post replication/branching path that is imposed on top of existing label stack, so service label ( + optionally more transport labels) are preserved.
> >
> > Cheers,
> > Jeff
> > On Jul 1, 2020, 12:40 PM -0700, Rishabh Parekh <rishabhp@gmail.com>, wrote:
> >
> > Robert,
> >
> > A) Firmly state that replication SID MUST be the last one on the stack
> > B) Instead of real SID after the replication SID provide a binding SID which locally will be mapped to a different SID list imposed to each replicated flow.
> >
> >
> > We would be fine with A), but we don't want to exclude possibility of
> > something like what you describe in B.
> >
> > -Rishabh
> >
> > On Wed, Jul 1, 2020 at 12:27 PM Robert Raszuk <robert@raszuk.net> wrote:
> >
> >
> > Hi Rishabh,
> >
> > Of course, care must be
> > taken to avoid the "explosion" as you describe it. G-SID-2 has to map
> > to a unique node; for example, it may be an Anycast-SID that takes
> > packet to distinct nodes from each of the downstream node, or the
> > downstream nodes can be border nodes connecting to other segment
> > routing domains where G-SID-2 resolves to distinct nodes in each
> > domain.
> >
> >
> > I think you are stretching it too thin.
> >
> > See even if G-SID-2 is anycast SID you have zero assurance that physical nodes packets will land on would be at all diverse.
> >
> > Likewise crossing domains yet providing identical global SID now to be a different node in each such domain to me is not a realistic example.
> >
> > I think we have two options:
> >
> > A) Firmly state that replication SID MUST be the last one on the stack
> >
> > B) Instead of real SID after the replication SID provide a binding SID which locally will be mapped to a different SID list imposed to each replicated flow.
> >
> > What is currently in the draft seems to be very counterintuitive and IMHO will result in operational difficulties.
> >
> > Thx a lot,
> > R.
> >
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.org
> > https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring