[mpls] Re: Issue #1, MNA Versioning

[Haoyu Song <[e-mail]>]

WG,

I have a proposal to support MNA versioning if it's needed. We can simply reuse the TC field in the LSE Format A (i.e., the MNA sub-stack indicator) as the version number. This way, we can avoid the use of eSPL. 
TC has no other use in this LSE format and the field has been reused in all the other LSE formats anyway. 

Best,
Haoyu

-----Original Message-----
From: Loa Andersson <[e-mail]> 
Sent: Saturday, May 24, 2025 4:29 AM
To: Joel Halpern <[e-mail]>; Dongjie (Jimmy) <jie.dong=[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: [mpls] Re: Issue #1, MNA Versioning

Working Group,

I have only found two comments on the MNA versioning issue, one that says that (conditionally) that we don't need it, and another that says that we have not called consensus.

Since we now have both header drafts under the working group purview it might be time to try to agree if we need versioning or not.

/Loa

Den 17/04/2025 kl. 21:58, skrev Joel Halpern:
> If the question is "do we need to add something to support possible 
> evolution in functionality", I think the answer is know. My longer 
> comment was to provide explanation for why I consider the answer to be 
> no.  If you mean something else by "versioning" then I would want to 
> know what you think it means before answering.
> 
> Because the bSPL comment in the original email was closely coupled 
> with this ostensible need, I thought it sensible to comment at the same point.
> 
> Yours,
> 
> Joel
> 
> On 4/17/2025 2:51 AM, Loa Andersson wrote:
>> Working Group,
>>
>> If the list leads to any amount of discussion, I proposewe separate 
>> the discussion of each numbered issues in separate thread.
>>
>> SO I named this thread "Issue #1, MNA Versioning"
>>
>> Second, a small comment on Joel's response.
>>
>>
>>> 1) You express concern about MNA versioning.
>>>
>>> Response 1) There is no problem with MNA versioning.  First, we 
>>> actually are reasonably confident that this approach can address the 
>>> need, without needing to change the base header.  The ability to add 
>>> flags and opcodes gives us a tremendous amount of flexibility for 
>>> evolution. Second, if we find it is completely wrong we can indeed 
>>> assign a new special label with a new initial structure.  Whether we 
>>> use the half- empty bSPL space or decide at that point that 
>>> uncertainty suggests the use of eSPL can be determined at that time.
>>
>> If "we gt it wrong, and we decide to not encode the version in the 
>> header, but use the MNA Label for verssining, we would use up one 
>> quarter of the free bSPL space. I would have been way more 
>> comfortable if we said eSPL.
>>
>> However, why not go about in an orderly way
>>
>> - discuss if we need versioning
>>   -- call the consensus
>>      --- if we don't need versioning, no problem
>>      --- if do, let's discuss the best way of doing it
>>
>> I'm not convinced that either bSPL, eSPL or a combination is the 
>> correct answer. Nor am I convinced that OpCodes are the correct, the 
>> unknown handling only allow for 2 actions, skip or drop. If we use 
>> OpCodes for versioning, it is conceivavle that we might need as 
>> response. Same for flags.
>>
>> /Loa
>>
>>
>>
>>>
>>>> 1.  MNA Versioning
>>>>
>>>>      It has been stated that MNA versioning is needed.
>>>>
>>>>      There are obviously more one than way to solve this.  It has 
>>>> been
>>>>      said that it would be possible to use a separate eSPL for each
>>>>      version, but other ways have been proposed.
>>>>
>>>>      Versioning can obviously be done with an bSPL, but we can't 
>>>> use
>>>>      multiple bSPL (one for each version), since that would risk to
>>>>      deplete the available bSPL quickly.
>>>>
>>>>      Two obvious ways to solve the "version with bSPL" that have 
>>>> been
>>>>      suggested are:
>>>>
>>>>      *  (1) insert a version field in the NAS
>>>>
>>>>      *  (2) use an OpCode to indicate the version
>>>>
>>>>      *  (3) using two bit in the flag field to create a small 
>>>> version
>>>>         field
>>>>
>>>>      (1) and (2) can be viewed as suboptimal since adding a field 
>>>> to the
>>>>      NAS would consume available data bits, and using an OpCode 
>>>> first
>>>>      decreases the available number of OpCodes and secondly because
>>>>      OpCodes are used for something they were not intended for. It 
>>>> should
>>>>      also be noted that opcode cannot be used to indicate the 
>>>> change to the
>>>>      fixed fields of MNA LSE formats (e.g. NSAL or NAL).
>>>>
>>>>      (3) is probably a trade-off between the number of flags and 
>>>> how many
>>>>      flags we need, but there is no available flag in the MNA LSE 
>>>> format B.
>>>>
>>>>      If an unknown OpCode is encountered it is not certain that in 
>>>> general
>>>>      should trigger the same response as an unknown version number.
>>>>
>>>>      There has also been opinions raised that versioning is not needed.
>>>>      Currently the argument against using versioning seem to that 
>>>> it has
>>>>      never been done in MPLS before.
>>>>
>>>>      If we decide that versioning is required, we can also see that 
>>>> there
>>>>      ways of doing it, regardless if the MNA Label is a bSPL or an 
>>>> eSPL.
>>>>
>>>>      Anyhow, we should not progress the drafts before deciding on
>>>>      versioning.
>>

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]

_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]