Re: [bess] draft-boutros-bess-elan-services-over-sr review

[Gyan Mishra <[e-mail]>]

Dear authors

Slight correction on SRv6 uSID service sid.

So the F3216 uSID format 32 bit block with 16 bit uSID entry in the uSID
carrier, you can have different types or “service sid” which comes out of
the expanded WLIB  wide LIB local SID block allocation.

Nice thing about SRv6 is sky is the limit of ideas for SRv6 uSID forwarding
plane service sid use case extensibility and SRv6 endpoint instantiation
and what you want to encode into the service sid field.

Kind Regards

Gyan
On Mon, Oct 9, 2023 at 10:52 PM Gyan Mishra <[e-mail]> wrote:

>
> Dear authors
>
> I would like to provide some feedback on this draft follow up from the
> presentation given at IETF 117.
>
> After reviewing this draft it seems this draft is trying apply the concept
> of “service sid” to both SR-MPLS and SRv6 uSID forwarding planes.
> Interesting idea.
>
> This draft seems to overlap or conflict with the important concept of
> “service sid” used by RFC 9252 SRv6 BGP service overlay which defines the
> BGP prefix SID encoding schema for SRv6 L2
> service TLV encoding of SRv6 service  SID for SRv6 based L2 services
> functionally equivalent to EVPN MPLS label routes types for L2 service and
> SRv6 L3 service TLV encoding of SRv6 service  SID for SRv6 based L3
>  services functionally equivalent to L3 VPN MPLS label service routes types
> for L3 services.
>
> Segment Routing has the concept of topological sid and service sid where
> the topological sid is equivalent to the MPLS label stack topmost label and
> the service sid is equivalent to the BOS S bit set bottom of stack service
> label where with SRv6 is analogous to a a single level label stack with the
> locator acting as the topmost label and the SRv6 SID  IPv6 address IID FUNC
> field encoding the L2 L3 VPN  service label.  Thus the single level label
> stack trickery optimization in the SRv6 forwarding plane encoding schema
> and as is a different forwarding plane paradigm shift requires the concept
> of service sid for the L2 L3 VPN label encodings.
>
> AFAIK this concept of service sid does not apply to SR-MPLS as it reuses
> the label stack of the MPLS data plane and with MNA extensibility is
> further extended.  SR-MPLS use ISD for its framework identical to MPLS RFC
> 6790 or SR-MPLS RFC 8662 Entropy label {TL,ELI,EL} where now with SR-MPLS
> with ISD the topological SIDs are now stacked representing the transport
> label layer of the label stack followed by the BOS S bit set L2 / L3 VPN
> service labels.  Adding an additional special purpose service label as this
> draft describes sounds like would be a possible use case for PSD
> extensibility of the bottom of stack with post stack data.  Overall for MNA
> most of the existing ancillary data use cases as described have been for
> ISD and not yet any for PSD, however there are some use cases in the works
> and maybe this would be another possibility of a use case.
>
> The service SID concept used in this draft for L2 VPN EPN does talk about
> a bit mapping and possible aggregation or some sort of optimizations maybe
> even network slicing using bits for services slice selector could be an
> idea for use of the service sid and there could be many other
> possibilities.
>
> I believe the below draft maybe what you are trying to accomplish with the
> EVPN service sid from an optimization perspective.
>
> MVPN EVPN tunnel aggregation with common labels
>
> This draft takes advantage of upstream assigned context labels RFC 5331.
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-aggregation-label-14
>
> I would be happy to collaborate on this draft.
>
> Kind Regards
>
> Gyan
>