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

[[e-mail]]

Hi Greg,

Thank you for the much needed clarification.

Could you also clarify your position with regards to draft-decraene-mpls-slid-encoded-entropy-label-id? Do you believe that it breaks RFC 6790 nor RFC8662? If so, please cites the sentences from both draft-decraene-mpls-slid-encoded-entropy-label-id and RFC/6790/8662 that would contradict each other or would be incompatible.

> draft-jags-mpls-ext-hdr is not backward compatible with RFC 6790 and RFC 8662.
To progress, could you please cites the sentences from both draft-jags-mpls-ext-hdr and RFC/6790/8662 that would contradict each other or would be incompatible.
Thank you,
Regards,
--Bruno



From: Greg Mirsky <[e-mail]>
Sent: Wednesday, June 8, 2022 5:52 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>; Loa Andersson <[e-mail]>
Subject: Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators

Hi Bruno,
thank you for pointing that out to me. I recall our earlier discussion about this, and I feel that I need to clarify my position:
*         draft-decraene-mpls-slid-encoded-entropy-label-id, by itself, does not address the MNA requirements listed in draft-ietf-mpls-miad-mna-requirements
*         to address the MNA requirements using ELI, one needs to use draft-jags-mpls-ext-hdr
*         draft-jags-mpls-ext-hdr is not backward compatible with RFC 6790 and RFC 8662.
I hope that makes my point clearer. I greatly appreciate your questions and comments.

Regards,
Greg

On Wed, Jun 8, 2022 at 8:44 AM <[e-mail]<mailto:[e-mail]>> wrote:
Greg,

Extending the ELI as per draft-decraene-mpls-slid-encoded-entropy-label-id does not break RFC 6790 nor RFC8662.
If you believe that it does, please cites the sentences from both draft-decraene-mpls-slid-encoded-entropy-label-id and RFC/6790/8662 that would contradict each other or would be incompatible.

Thank you,
--Bruno

From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of Greg Mirsky
Sent: Tuesday, May 31, 2022 4:44 PM
To: Loa Andersson <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; DetNet Chairs <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators

Dear Loa, MPLS WG Chairs, Open DT, et al.,
I believe that re-using ELI to address the requirements listed in draft-ietf-mpls-miad-mna-requirements will definitely break implementations of RFC 6790 and RFC 8662. Thus I oppose re-using ELI to indicate the presence of an MNA in a packet. I think that the specifics of the mechanism indicating the presence of an MNA should be discussed separately from the framework document.

Regards,
Greg

On Mon, May 30, 2022 at 2:21 PM Loa Andersson <[e-mail]<mailto:[e-mail]>> wrote:
MPLS Working Group, MPLS Open DT,

The MPLS Network Actions (MNA) framework requires a method of indicating
the presence of a Network Action and any Ancillary Data.

Is the consensus of the working group that we do this by:

   (1) allocating a new SPL for Network Action Indicators?

   (2) re-purposing the ELI SPL?

   (3) using some other method of indicating this such as making it an
       additional property of an ordinary label?

Please respond to the MPLS WG mail list.

Loa Andersson
for the Open DT wg chairs

--
Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
Bronze Dragon Consulting             phone: [phone]

_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls


Orange Restricted


Orange Restricted

_________________________________________________________________________________________________________________________



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.