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

[Jeff Tantsura <[e-mail]>]

Gunter,

Many thanks for the great discussion! 

While MSD signaling allows to to signal at IGP adjacency granularity (per interface), known as node and link MSDs, and this has been done to address cases where there are multiple HW generation on the same system, and/or more specifically to the use case you have described - outgoing encapsulation is more complex and hence affects port/LC’ ability to impose labels. The is however but straightforward - the way processing and encapsulation is done in a multi LC systems (ingress/egress/recirculation/etc) varies drastically from implementation to implementation (sometimes even across SW releases).

Most implementations however only use node MSD, and the approach taken is to have system’ lowest value signaled (trade-offs are computaional complexity vs loss of information/granularity/related performance ), read-only is a much more safe approach in this case. 
I don’t dismiss your use case, however, as you rightfully said - for the current use cases, it is good enough, if/when the need for “semi-dynamic” MSD arises - we will update the MSD RFCs as well as relevant YANG models.

Hope this clarifies the logic.

Thanks,
Jeff

> On Jul 9, 2024, at 07:42, Gunter van de Velde (Nokia) <[e-mail]> wrote:
> 
> Another consideration for making the leaf read-write instead of read-only is that future MSDs may emerge that benefit more significantly from write capabilities, unlike existing ERLD and BMI. With the currently proposed yang model, updating would be necessary. While this change appears to be backward compatible and should not pose major issues, it will nonetheless require processing.
> 
> I agree with you that my observation pertains more to the current MSD drafts than to the proposed YANG model.
> 
> I'll change my ballot to No Objection, because the current model will work with currently existing MSDs. I do still believe RW seems more future proof, but that is a discussion i'll leave in the hands of the WG and document authors.
> 
> G/
> 
> 
> 
> -----Original Message-----
> From: Acee Lindem <[e-mail] <mailto:[e-mail]>> 
> Sent: Tuesday, July 9, 2024 2:22 PM
> To: Gunter van de Velde (Nokia) <[e-mail] <mailto:[e-mail]>>; Jeff Tantsura <[e-mail] <mailto:[e-mail]>>
> Cc: The IESG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; MPLS Working Chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[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 <http://nok.it/ext> for additional information.
> 
> 
> 
> 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-pos
>>> i 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 
>> GV> into the SID label stack (i assume you are suggesting the MSD 
>> GV> 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