Re: [bess] draft-boutros-bess-elan-services-over-sr review
Dear Authors
To help provide some clarity on MNA, MNA (MPLS Network Actions) inherits
it’s extensibility concepts from the IPv6 data plane extension header
concept with HBH header -MPLS parity with hop by hop bSPL (base special
purpose label) which is the topmost transport label in the label stack MNA
extensibility referred to as “ISD” (in stack data)and DOH (Destination
Options Header) - MPLS parity with E2E bSPL (base special purpose label) in
the label stack MNA extensibility referred to as “PSD” (post stack data).
Hope that helps in defining the use case for this new PSD bSPL.
Cheers,
Gyan
On Mon, Oct 9, 2023 at 11:16 PM Gyan Mishra wrote:
>
> 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 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
>>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Re: [bess] draft-boutros-bess-elan-services-over-sr review
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 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
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
[bess] draft-boutros-bess-elan-services-over-sr review
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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
