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

[Gyan Mishra <[e-mail]>]

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