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

Hi Bruno,
thank you for the clarification, that helps a lot. From the perspective of
MNA requirements, I'd imagine that supporting the association of meta-data
with MNAI is essential and any proposal we adopt must have it. If that is
the case, what is the role of a stand-alone document that is limited to EL
and Slice-ID? Why wouldn't it be a section of a document that addresses all
the MNA requirements?

Regards,
Greg

On Mon, Jun 20, 2022 at 8:38 AM <bruno.decraene@orange.com> wrote:

> Hi Greg,
>
>
>
> Please see inline [Bruno]
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Friday, June 17, 2022 9:56 PM
>
>
>
> Hi Bruno,
>
> thank you for the expedient response. If I understand you correctly, PSD
> can be used as part of draft-decraene-mpls-slid-encoded-entropy-label-id.
>
> [Bruno] I would phrase it differently:
>
> - draft-decraene-mpls-slid-encoded-entropy-label-id can be used to carry
> 8 indicators in the stack while being usable with existing LSP Egress (more
> indicators would require extension on the LSP egress)
>
> - one of these indicators may be used to indicate the presence of PSD. The
> format/solution for PSD is orthogonal; one example being
> https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-hdr-00#section-5
>
>
>
> Regards,
>
> --Bruno
>
>
>
> If that is the case, I think adding more information on how PSD can be
> used by the mechanism described
> in draft-decraene-mpls-slid-encoded-entropy-label-id would be helpful.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
>
>
> On Fri, Jun 17, 2022 at 9:54 AM <bruno.decraene@orange.com> wrote:
>
> Hi Greg,
>
>
>
> Please see inline [Bruno]
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Friday, June 17, 2022 5:46 PM
> *To:* DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
> *Cc:* Tony Li <tony.li@tony.li>; Zafar Ali (zali) <zali@cisco.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
>
>
>
> 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?
>
>
>
> [Bruno] Two paths :
>
> - post stack data.
>
> - in-stack data located after the ELI, EL e.g. as proposed in
> draft-jags-mpls-ext-hdr (but different encoding would also work)
>
>
>
> At this point, post-stack data is probably my preference as the use of the
> label stack is already specified/used hence brings constraints.
>
>
>
> Regards,
>
> --Bruno
>
>
>
>
>
>
>
> 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
>
>
>
> Orange Restricted
>
>
>
> 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
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>