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

Hi Bruno,
you've said that your proposal allows for up to 8 MNA indicators. How do
you envision the encoding of data associated with these indicators? Re-use
the EL space? Or these can be only no-data MNAIs?

Regards,
Greg

On Fri, Jun 17, 2022 at 2:03 AM <bruno.decraene@orange.com> wrote:

> Tony,
>
>
>
>
>
> Orange Restricted
>
> *From:* Tony Li <tony1athome@gmail.com> *On Behalf Of *Tony Li
> *Sent:* Friday, June 17, 2022 5:26 AM
> *To:* Zafar Ali (zali) <zali@cisco.com>
> *Cc:* Kireeti Kompella <kireeti.ietf@gmail.com>; DECRAENE Bruno INNOV/NET
> <bruno.decraene@orange.com>; mpls@ietf.org; pals-chairs@ietf.org;
> mpls-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
> *Subject:* Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying
> Network Action Indicators
>
>
>
>
>
> Zafar,
>
>
>
> 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.
>
> 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.
>
> 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.
>
>
>
> Regards,
>
> --Bruno
>
>
>
>
>
>
>
>
>
> For that reason alone, Bruno’s draft is not a tenable solution to MNA and
> discussing it further is pointless.
>
>
>
> Tony
>
>
>
>
>
> On Jun 16, 2022, at 7:32 PM, Zafar Ali (zali) <zali@cisco.com> wrote:
>
>
>
> Tony, Kireeti,
>
>
>
> So “I do not want to modify my current implementation” is the argument to
> stop people interested in Bruno’s draft from using it?
>
> If such HW can/ need be modified to implement the new complex encoding
> scheme you proposed, why it cannot implement simple encoding in Bruno’s
> draft?
>
>
>
> Please also look at
> https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id-04#section-4.4
>  and
> https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id-04#section-4.5
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *Tony Li <tony1athome@gmail.com> on behalf of Tony Li <
> tony.li@tony.li>
> *Date: *Thursday, June 16, 2022 at 3:10 PM
> *To: *"Zafar Ali (zali)" <zali@cisco.com>
> *Cc: *Kireeti Kompella <kireeti.ietf@gmail.com>, "
> bruno.decraene@orange.com" <bruno.decraene@orange.com>, "mpls@ietf.org" <
> mpls@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "
> mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, DetNet Chairs <
> detnet-chairs@ietf.org>
> *Subject: *Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying
> Network Action Indicators
>
>
>
>
>
>
>
>
>
>
> The draft has been implemented for the exact (SLID) use-case on hardware
> platforms based on Broadcom Jericho2 family of ASIC
> Please take a look at
> https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id-04#section-7
>
> No such issue was noted
>
>
>
>
>
> And Jericho2 is the only thing that counts in the entire world?
>
>
>
> T
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>