Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators

[Tony Li <[e-mail]>]

Hi Zafar,


> The encoding in Bruno’s draft is sufficient for many, if not most use-cases


Really?  If we look at the use cases, we see:

 * entropy
 * slice id
 * nffrr
 * ioam
 * detnet
 * sfc
 * np
 * aan

I count 8.  Zero room for growth.  And we know that there will be growth.  Everything we do grows. Even some of the cases above are probably more than one network action.

Our job is to think farther ahead. To see past just the immediate need and understand what the architecture may need moving forward. So that we don’t have turn around and repeat the process the next time Yet Another Feature needs to be added. We need to anticipate the future. And that requires room to grow.

When you’re buying shoes for a child, you never buy shoes that are tight today. :)

Tony



> I would also like to point you to IETF113 PALS joint WG session minutes where many find encoding sufficient: https://datatracker.ietf.org/doc/minutes-113-pals/ <https://datatracker.ietf.org/doc/minutes-113-pals/>
>  
> Re: It (Bruno’s draft) doesn’t scale
>  
> To me the complex encoding, need for pushing additional labels (the reality is that depreciating ELI is a wishful thinking), etc. is more unscalable and requires more HW resources. Simplicity is the basis for MPLS data plane design and what makes it scalable. 
>  
> Thanks
>  
> Regards … Zafar 
>  
>  
> From: Tony Li <[e-mail]> on behalf of Tony Li <[e-mail]>
> Date: Friday, June 17, 2022 at 9:42 AM
> To: "[e-mail]" <[e-mail]>
> Cc: "Zafar Ali (zali)" <[e-mail]>, Kireeti Kompella <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, DetNet Chairs <[e-mail]>
> Subject: Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators
>  
>  
> Bruno,
>  
>> Again, my problem with Bruno’s draft is that the limited space found in the ELI/EL LSE’s is clearly insufficient to begin to capture the use cases that we already can foresee for MNA, much less provide any room for growth.  It doesn’t scale. We need more bits.
>>  
>> [Bruno] Thank you for providing a technical argument.
>> draft-decraene-mpls-slid-encoded-entropy-label-id provides 8 indicators while being backward compatible with existing egress/signaling.
>  
>  
> And, contrary to that old TV show, 8 is not enough. :)
>  
> 
> 
>> If more are required, solution can be extended to provide more indicators (and data) but at the cost of requiring new dataplane feature on the LSR egress (and new signaling). Just like the proposals using a new SPL.
>  
>  
> But then you would run afoul of extending the ELI with one or more LSEs. And that’s much more scary because now you’re risking legacy devices misinterpreting the additional LSE’s. We’ve discussed this, it’s the same problem with Jags’ draft.
>  
> 
> 
>> The net benefit is that in the short/medium term more devices/deployments can start using those 8 indicators, while waiting for the new generation to support the new proposal.
>  
>  
> So we pay twice? Why not just have one solution?
>  
> The only thing we’re really waiting for is for people to stop arguing.
>  
> Tony