Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[Bernard Sales (Nokia)]

Hello,

I reviewed draft-trr-bess-bgp-srv6-args-02. I consider that this I-D is ready 
for endorsement by the BESS WG.

Many Thanks,

-- Brd

From: BESS  On Behalf Of Matthew Bocci (Nokia)
Sent: Thursday, September 28, 2023 4:49 PM
To: bess@ietf.org
Cc: draft-trr-bess-bgp-srv6-a...@ietf.org
Subject: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

This email begins a two-week WG adoption and IPR poll for 
draft-trr-bess-bgp-srv6-args-02 [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not progress 
without answers from all the authors and contributors.
Currently, there is currently no IPR disclosure against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond to the IPR poll only if you are aware of any IPR that has not yet been 
disclosed in conformance with IETF rules.

This poll for adoption closes on Thursday 12th October 2023.

[1] draft-trr-bess-bgp-srv6-args-02 - SRv6 Argument Signaling for BGP Services 
(ietf.org)
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] SRV6 for EVPN Fast Reroute

[linchangwang]

Hi Luc,

Theirs is another way of achieving the same thing - using the behavior vs. 
using the flag.
The draft link:  
https://datatracker.ietf.org/doc/draft-liu-bess-multihome-srv6-service-sid-flag/

Each egress PE advertises an additional SRv6 Service SID in BGP
routes which is called No-Further-FRR SID.

The owner of No-Further-FRR SID will not provide local FRR for it.
  When the next-hop of No-Further-FRR SID is down, like PE-CE link
  failure or CE node failure, the PE will drop packets rather than
  apply FRR.

 The No-Further-FRR SID can used by other PE as the protection of
   local PE-CE link failure, without worrying about the looping
   problem.

This draft defines no-further-FRR flag in the SRv6 Service SID Flags
   field of the SRv6 SID Information Sub-TLV [RFC9252]:



0   1   2   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | SRv6 Service  |SRv6 Service   |   |

   | Sub-TLV   |Sub-TLV|   |

   | Type=1|Length |  RESERVED1|

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  SRv6 SID Value (16 octets)  //

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Svc SID Flags |   SRv6 Endpoint Behavior  |   RESERVED2   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  SRv6 Service Data Sub-Sub-TLVs  //

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 Svc SID Flags:



  0 1 2 3 4 5 6 7

 +-+-+-+-+-+-+-+-+

 |N|A|   |

 +-+-+-+-+-+-+-+-+



   o N-flag: No-Further-FRR flag. When set, the associated SID has no

  fast reroute protection.

The differences between the draft 
[https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06]
 and the  draft
[https://datatracker.ietf.org/doc/draft-liu-bess-multihome-srv6-service-sid-flag/]
 are as follows:


*  The focus of the "evpn fast reroute" draft is solely on FRR in the EVPN 
scenario, specifically for L2VPN scenarios.

*  In contrast, this draft [draft-liu-bess-multihome-srv6-service-sid-flag] is 
applicable to both L3VPN and L2VPN networking.

*  This draft [draft-liu-bess-multihome-srv6-service-sid-flag] does not require 
any additional definition of "Flavor". It only involves local behavior and does 
not require service SID flavor expansion.

*  The "evpn fast reroute" draft requires the use of arg to solve DF 
(Designated Forwarder) problems. However, if arg is used for other applications 
in the future, it may no longer be available for use in this context.

*  This draft [draft-liu-bess-multihome-srv6-service-sid-flag] only provides a 
brief expansion on the definition of the "flag" and it is applicable to both 
L2VPN and L3VPN scenarios.

I would like to mention that there is an alternative approach to achieving the 
same objective - using a flag instead of introducing a new flavor. I believe 
that not using Fast-re-route can be considered a local action.
By notifying the ingress node through a flag, there would be no need to define 
new flavors for DT4, DT6, DT2U, and DX2.
Additional feedback and suggestions are welcome.

Thanks,
Changwang



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Luc André Burdet
Sent: Thursday, September 07, 2023 12:25 AM
To: spr...@ietf.org
Subject: [spring] SRV6 for EVPN Fast Reroute

SPRING WG,

My co-authors and myself have presented a document in BESS WG which describes 
fast convergence in EVPN networks without relying on control plane actions. In 
the latest version SRV6 support was introduced.

https://datatracker.ietf.org/doc/draft-burdet-bess-evpn-fast-reroute/

The draft specifies two forwarding behaviours which must be implemented:

  *   "Terminal disposition" to prevent loops, esp. in EVPN's All-Active (MLAG) 
case
  *   "DF-Bypass" to address the dropping of rerouted packets on blocked ports 
until control-plane catches up (BGP route withdraw)

For SRV6, these are mapped to 2 proposed new behaviours (variants of existing 
behaviours) both taking optional Args
- End.DT2U.Reroute : End.DT2U with Fast Reroute
- End.DX2.Reroute : End.DX2 with Fast Reroute

The authors would appreciate feedback and any comments on the SRV6 proposal 
contained in the document

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814

---

[bess] Protocol Action: 'MVPN/EVPN Tunnel Aggregation with Common Labels' to Proposed Standard (draft-ietf-bess-mvpn-evpn-aggregation-label-14.txt)

[The IESG]

The IESG has approved the following document:
- 'MVPN/EVPN Tunnel Aggregation with Common Labels'
  (draft-ietf-bess-mvpn-evpn-aggregation-label-14.txt) as Proposed Standard

This document is the product of the BGP Enabled ServiceS Working Group.

The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/




Technical Summary

   The MVPN specifications allow a single Point-to-Multipoint (P2MP)
   tunnel to carry traffic of multiple VPNs.  The EVPN specifications
   allow a single P2MP tunnel to carry traffic of multiple Broadcast
   Domains (BDs).  These features require the ingress router of the P2MP
   tunnel to allocate an upstream-assigned MPLS label for each VPN or
   for each BD.  A packet sent on a P2MP tunnel then carries the label
   that is mapped to its VPN or BD (in some cases, a distinct upstream-
   assigned label is needed for each flow.)  Since each ingress router
   allocates labels independently, with no coordination among the
   ingress routers, the egress routers may need to keep track of a large
   number of labels.  The number of labels may need to be as large (or
   larger) than the product of the number of ingress routers times the
   number of VPNs or BDs.  However, the number of labels can be greatly
   reduced if the association between a label and a VPN or BD is made by
   provisioning, so that all ingress routers assign the same label to a
   particular VPN or BD.  New procedures are needed in order to take
   advantage of such provisioned labels.  These new procedures also
   apply to Multipoint-to-Multipoint (MP2MP) tunnels.  This document
   updates RFCs 6514, 7432 and 7582 by specifying the necessary
   procedures.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

No issues were found in the working group on this draft and it didn't generate 
any controversy.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

There are reported implementations of this draft.

Personnel

   The Document Shepherd for this document is Stephane Litkowski. The
   Responsible Area Director is Andrew Alston.


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] I-D Action: draft-ietf-bess-evpn-ipvpn-interworking-09.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-evpn-ipvpn-interworking-09.txt is now
available. It is a work item of the BGP Enabled ServiceS (BESS) WG of the
IETF.

   Title:   EVPN Interworking with IPVPN
   Authors: J. Rabadan
A. Sajassi
E. Rosen
J. Drake
W. Lin
J. Uttaro
A. Simpson
   Name:draft-ietf-bess-evpn-ipvpn-interworking-09.txt
   Pages:   33
   Dates:   2023-10-09

Abstract:

   Ethernet Virtual Private Network (EVPN) is used as a unified control
   plane for tenant network intra and inter-subnet forwarding.  When a
   tenant network spans not only EVPN domains but also domains where BGP
   VPN-IP or IP families provide inter-subnet forwarding, there is a
   need to specify the interworking aspects between BGP domains of type
   EVPN, VPN-IP and IP, so that the end to end tenant connectivity can
   be accomplished.  This document specifies how EVPN interworks with
   VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet
   forwarding.  The document also addresses the interconnect of EVPN
   domains for Inter-Subnet Forwarding routes.  In addition, this
   specification defines a new BGP Path Attribute called D-PATH (Domain
   PATH) that protects gateways against control plane loops.  D-PATH
   modifies the BGP best path selection for multiprotocol BGP routes of
   SAFI 128 and EVPN IP Prefix routes, and therefore this document
   updates the BGP best path selection in [RFC4271], but only for IPVPN
   and EVPN families.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-ipvpn-interworking-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-ietf-bess-evpn-ipvpn-interworking-09.txt

[Jorge Rabadan (Nokia)]

FYI

This version addresses the comments from Jeff Hass about the section on route 
aggregation. Please pay close attention to it and provide any feedback you may 
have.
Also the security section has been improved based on Jeff’s feedback as well.
Big thank you to Jeff, from all the authors, for all his time and useful 
feedback.

Jorge, on behalf of the authors

From: BESS  on behalf of internet-dra...@ietf.org 

Date: Monday, October 9, 2023 at 11:07 AM
To: i-d-annou...@ietf.org 
Cc: bess@ietf.org 
Subject: [bess] I-D Action: draft-ietf-bess-evpn-ipvpn-interworking-09.txt

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Internet-Draft draft-ietf-bess-evpn-ipvpn-interworking-09.txt is now
available. It is a work item of the BGP Enabled ServiceS (BESS) WG of the
IETF.

   Title:   EVPN Interworking with IPVPN
   Authors: J. Rabadan
A. Sajassi
E. Rosen
J. Drake
W. Lin
J. Uttaro
A. Simpson
   Name:draft-ietf-bess-evpn-ipvpn-interworking-09.txt
   Pages:   33
   Dates:   2023-10-09

Abstract:

   Ethernet Virtual Private Network (EVPN) is used as a unified control
   plane for tenant network intra and inter-subnet forwarding.  When a
   tenant network spans not only EVPN domains but also domains where BGP
   VPN-IP or IP families provide inter-subnet forwarding, there is a
   need to specify the interworking aspects between BGP domains of type
   EVPN, VPN-IP and IP, so that the end to end tenant connectivity can
   be accomplished.  This document specifies how EVPN interworks with
   VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet
   forwarding.  The document also addresses the interconnect of EVPN
   domains for Inter-Subnet Forwarding routes.  In addition, this
   specification defines a new BGP Path Attribute called D-PATH (Domain
   PATH) that protects gateways against control plane loops.  D-PATH
   modifies the BGP best path selection for multiprotocol BGP routes of
   SAFI 128 and EVPN IP Prefix routes, and therefore this document
   updates the BGP best path selection in [RFC4271], but only for IPVPN
   and EVPN families.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-ipvpn-interworking-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Please send slot request for IETF 118

[Mankamana Mishra (mankamis)]

All,
Primary agenda has been posted. Please send me slot request for BESS 118.

Mankamana
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] John Scudder's No Objection on draft-ietf-bess-evpn-pref-df-12: (with COMMENT)

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--

Thanks for your work to address my discuss and comments. I have just one new
comment and a nit.

## COMMENTS

### Abstract needs to cover the update

Thanks for adding the "updates" header. You'll notice that idnits now complains:

  Checking nits according to https://www.ietf.org/id-info/checklist :
  
...
  -- The draft header indicates that this document updates RFC8584, but the
 abstract doesn't seem to mention this, which it should.

You should fix this by adding something to the abstract, along the lines of,
"This document updates RFC 8584 by modifying the definition of the DF Election
Extended Community."

## NITS

### Section 4.1

"The procedures for the used of the DP bit" -- s/used/use/



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] I-D Action: draft-ietf-bess-evpn-pref-df-13.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-evpn-pref-df-13.txt is now available. It is a
work item of the BGP Enabled ServiceS (BESS) WG of the IETF.

   Title:   Preference-based EVPN DF Election
   Authors: J. Rabadan
S. Sathappan
W. Lin
J. Drake
A. Sajassi
   Name:draft-ietf-bess-evpn-pref-df-13.txt
   Pages:   20
   Dates:   2023-10-09

Abstract:

   The Designated Forwarder (DF) in Ethernet Virtual Private Networks
   (EVPN) is defined as the Provider Edge (PE) router responsible for
   sending Broadcast, Unknown unicast and Multicast traffic (BUM) to a
   multi-homed device/network in the case of an all-active multi-homing
   Ethernet Segment (ES), or BUM and unicast in the case of single-
   active multi-homing.  The Designated Forwarder is selected out of a
   candidate list of PEs that advertise the same Ethernet Segment
   Identifier (ESI) to the EVPN network, according to the Default
   Designated Forwarder Election algorithm.  While the Default Algorithm
   provides an efficient and automated way of selecting the Designated
   Forwarder across different Ethernet Tags in the Ethernet Segment,
   there are some use cases where a more 'deterministic' and user-
   controlled method is required.  At the same time, Network Operators
   require an easy way to force an on-demand Designated Forwarder
   switchover in order to carry out some maintenance tasks on the
   existing Designated Forwarder or control whether a new active PE can
   preempt the existing Designated Forwarder PE.

   This document proposes a Designated Forwarder Election algorithm that
   meets the requirements of determinism and operation control.  This
   document updates RFC8584 by modifying the definition of the DF
   Election Extended Community.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-13

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-pref-df-13

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-pref-df-12: (with COMMENT)

[Jorge Rabadan (Nokia)]

Hi John,

Thanks again!
Both things are now fixed in version 13.

Jorge

From: John Scudder via Datatracker 
Date: Monday, October 9, 2023 at 2:08 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Stephane Litkowski 
, slitkows.i...@gmail.com 
Subject: John Scudder's No Objection on draft-ietf-bess-evpn-pref-df-12: (with 
COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-pref-df-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/



--
COMMENT:
--

Thanks for your work to address my discuss and comments. I have just one new
comment and a nit.

## COMMENTS

### Abstract needs to cover the update

Thanks for adding the "updates" header. You'll notice that idnits now complains:

  Checking nits according to https://www.ietf.org/id-info/checklist :
  
...
  -- The draft header indicates that this document updates RFC8584, but the
 abstract doesn't seem to mention this, which it should.

You should fix this by adding something to the abstract, along the lines of,
"This document updates RFC 8584 by modifying the definition of the DF Election
Extended Community."

## NITS

### Section 4.1

"The procedures for the used of the DP bit" -- s/used/use/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Gyan Mishra]

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

[Gyan Mishra]

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

[Gyan Mishra]

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