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

[Acee Lindem <[e-mail]>]

Hi Gunter, 

I have some ideas on your the scenario cite but I’ll defer to Jeff since he was the original editor/author of the MSD drafts. 
The comment is actually more relevant to these drafts than the YANG model.  

Thanks,
Acee

> On Jul 8, 2024, at 18:33, Gunter van de Velde (Nokia) <[e-mail]> wrote:
> 
> Hi Acee,
> 
> See inline: GV>
> 
> 
> -----Original Message-----
> From: Acee Lindem <[e-mail]> 
> Sent: Monday, July 8, 2024 9:15 PM
> To: Gunter van de Velde (Nokia) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; MPLS Working Chairs <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: Gunter Van de Velde's No Record on draft-ietf-mpls-msd-yang-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.
> 
> 
> 
> 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-posi
>> tions/ 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:
> 
> GV> The described observation is not about the depth a router can look into the SID label stack (i assume you are suggesting the MSD ERLD, while i am more concerned about the MSD BMI)
> 
> https://datatracker.ietf.org/doc/draft-liu-lsr-aggregate-header-limit/
> 
> GV> This is not what i was referring towards. I did not even realise the existence of this draft. It addresses a different aspect.
> 
> This is the MSD as advertised in OSPF - https://datatracker.ietf.org/doc/rfc8476/
> 
> GV> yes, i was/am talking about this work. My assumption is that operators use the MSD-BMI to know how many SIDs a controller can push for SR policies.  
> 
> GV> Based upon suggested rfc8476 i found MSD BMI description in rfc8491:
> 
>   BMI:  Base MPLS Imposition is the number of MPLS labels that can be
>         imposed inclusive of all service/transport/special labels.
> 
> GV> The most optimal number of SR-MPLS labels a router can push appears to be a property determined by the line card and central (network) processing units. These values are often by an OS encoded as constants. My concern is that these constants may not align with the needs of network controllers. What controllers typically need to know is the maximum number of labels a router can push within the context of an SR policy.
> 
> GV> Ideally, the router would autonomously calculate the node and link MSD BMI based on the complexity of the L2 encapsulation and the services running on the interface, considering these constant values. However, this calculation is not straightforward for hardware. Such an assumption requires the router to have advanced capabilities to understand the SID stack depth impact of services and L2 encapsulation, and then compute the MSD BMI accordingly.
> 
> GV> Given these complexities, making this field read-write (RW) could be more operationally optimal. This approach would provide operators with the flexibility to configure an MSD BMI value that is lower than the maximum possible value derived for specific hardware, ensuring better alignment with operational needs.
> 
> GV> If the controller calculates an SR-policy with a label stack within the limit of the advertised MSD BMI, but is not aware of the services or the exact L2 encapsulation, the resulting data plane traffic may encounter encapsulation failures. Would it not be simpler, in such situations, to provide operators with the capability to manually configure an MSD BMI value that is less than the most optimal hardware-derived value? This would alleviate the need for the controller to understand every aspect of L2/L3/L4 (service, transport, and special) labels. 
> 
> Brgds,
> G/
> 
> Thanks,
> Acee
> 
> 
> 
> 
> 
> 
> 
>> 
>> 
>> 
>