[mpls] Re: Gunter Van de Velde's No Record on draft-ietf-mpls-msd-yang-12: (with COMMENT)

[Acee Lindem <[e-mail]>]

Hi Gunter,

> On Jul 8, 2024, at 1:27 PM, Gunter Van de Velde via Datatracker <[e-mail]> wrote:
> 
> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-mpls-msd-yang-12: No Record
> 
> 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-mpls-msd-yang/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I reviewed version draft-ietf-mpls-msd-yang-12
> 
> The draft is clear and in general i see no big issues with the yang model
> proposed.
> 
> Currently, my ballot is explicitly set to a 'No Record' position as I am
> unclear on the history behind why the MSD (Maximum SID Depth) leaves only
> provide read-only operational information. I'll update once i understand the
> philosophy of MSD model intent better.
> 
> Allow me to explain my concern. One might assume that a hardware device
> supports, for instance, the most optimal setup where Ethernet encapsulation can
> impose 10 MPLS segment SIDs. However, if such an interface is configured with a
> more complex L2 encapsulation (such as 802.1q combined with EVPN service SIDs
> and Entropy SIDs), the value that controllers can use might be reduced to 8, or
> even less, depending on the encoding and encapsulation complexity. In such
> scenarios, an operator may wish to adjust the most optimal MSD values to
> something less optimal but supported by the hardware when attempting to program
> a segment routing policy on a data packet

You're presuposing a maximum number of octets a router can examine in the data plane. That isn't what this is although it has been proposed: 


https://datatracker.ietf.org/doc/draft-liu-lsr-aggregate-header-limit/


This is the MSD as advertised in OSPF - https://datatracker.ietf.org/doc/rfc8476/

Thanks,
Acee







> 
> 
>