Re: [Pals] [Detnet] [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

[Gyan Mishra <[e-mail]>]

Hi  Bruno

Please see in-line Gyan2>

I agree with the idea and concepts of being able to reuse the existing
fields such as TTL which  provides flexibility for SPL and ancillary data
indicators and ease of time to market for deployments.  Agreed.

I am also in agreement on the idea of being able to use the 20 bit EL label
field for both entropy and possibly IETF Network slice aggregate.

We should make this an agenda topic for the next DT meeting and come to
hash this subject out and come consensus with the MPLS experts on the reuse
of TTL as well as other fields and impact and feasibility statement as well
as path forward so we can all make progress.

On Mon, Apr 4, 2022 at 9:26 AM <[e-mail]> wrote:

> Hi Gyan,



Please see inline [Bruno]





Orange Restricted

*From:* Gyan Mishra <[e-mail]>
*Sent:* Saturday, April 2, 2022 9:33 PM
*To:* DECRAENE Bruno INNOV/NET <[e-mail]>
*Cc:* Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>; John
E Drake <[e-mail]>; detnet WG <[e-mail]>; mpls <
[e-mail]>; [e-mail]
*Subject:* Re: [Detnet] [mpls] [Pals]
draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review
the PALS/MPLS/DetNet Joint Session minutes)





Hi Bruno



Responses in-line



On Fri, Apr 1, 2022 at 1:56 PM <[e-mail]> wrote:

Hi Gyan,



Thanks for the clarifications questions.

I’ll take the liberty to top post to re-organize in two distinct points.



   1. RFC 6790 specification of the use the EL’s TTL field.



You have correctly highlighted the two relevant text:

On the receiver side, §4.1 says “The EL's TTL MUST be ignored.”

On the sender side, §4.2 says “The TTL for the EL MUST be zero”



“a” So do we agree that RFC 6790 says “MUST be sent as zero and MUST
ignored on receipt” ?

    Gyan Yes…but ..RFC 6790 defines the value of the TTL, however RFC 3032
defines the rules for processing all the fields of the label stack
encoding.  RFC 3032 Section 2.4.2 describes the processing when TTL is set
to 0 which means the TTL has expired and the packet must not be forwarded.
RFC 6790 section 4.2 bullet 4 states “The TTL for the EL MUST be zero to ensure
that it is not used inadvertently for forwarding.”  My interpretation of
that is even though the specification states the label stack is {TL,ELI,EL}
and that at the PHP node when the TL is popped in the case of implicit null
packets is forwarded to the egress LER which pops both ELI and EL.

[Bruno] Agreed.

 Gyan2> Ack

  However, the sentence is stating the TTL must be 0 for EL so the packet
cannot be inadvertently used for forwarding which I am interpreting as
there is a possibility that the EL could be exposed at the top of the
stack.  If hypothetically the case where the EL were not exposed were not
possible then it would have been sufficient to state that the TTL is
ignored on receipt and not worry about TTL processing which is a concern it
seems as stated in RFC 6790.

[Bruno] I agree that your interpretation may be seem as logical. IMHO,
authors of 6790 have added the EL TTL set to zero as an additional  safe
guard in case of buggy LSR, and because that this decision cost was zero.
(not because it was technically needed for correct operation).

      Gyan2> Agreed for safeguard for corner case related to implementation
where EL may get exposed from a technical standpoint and for correct
operation to work, so the EL if exposed is not inadvertently used for
forwarding.  Agreed.

> On this, I guess that the reference would be Kireeti.
>
      Gyan2> I see his draft reuses TTL as well.  We would have the same
concern with Kireeti mspl4fa draft or any other draft repurpose of TTl
fields for a new use case.  We should take this topic up on reuse of TTL
and other fields for SPLs and indicators .

> That been said, let’s agree that so far nobody has found a text in a spec
that would lead a compliant LSR to forward based on an exposed EL. Quite
the contrary, we both agree that RFC 6790 is quite explicit on the behavior
(pop both labels ELI, EL)

 Gyan2> The way I read RFC 6790 the issue is not about buggy code or an LSR
being 100% compliant to tbe specification.  The issue is about a potential
corner case that exists could occur with vendor compliant code where the EL
could inadvertently get exposed as TL and used for forwarding and for that
reason the TTL must be set to 0.  This is more a physics issue not
compliance.


  I think we have to understand why RFC 6790 is requiring the TTL of EL
> MUST be set to 0.  So based on implementations of MPLS their maybe
> possibilities that that even though the ELI must proceed the EL, maybe they
> are corner cases where the ELI is missing label imposition on the LER and
> thus the EL is exposed and required the EL to have its TTL set to 0.
>
> [Bruno] “May be there are corner cases” looks like FUD to me. If there is
> a corner case causing problem, somebody should state it. Otherwise, it
> seems a bit to easy to block a proposal. E.g. “May be there are corner
> cases where an LSR looks at the Label Stack and may be unhappy with the
> ancillary data inserted in the stack (because clearly, as per MPLS
> architecture, the label stack is intended to be a stack of labels, not
> whatever we want)
>
>      Gyan2> Agreed.  We definitely don’t want to use fud by any means to
block a valuable proposal as this one and others that reuse the TTL and
other fields.

>   I think for this we would have to dig into implementations of MPLS label
> stack and see what implementations have done and if they are setting the
> TTL to 0 or not.
>
> [Bruno] A compliant implementation MUST set the EL TTL to zero.
>

     Gyan2> Agreed

> Is there anyone having an implementation not setting the TTL to zero?
> Please speak now.
>
>  Gyan2> I don’t know of any.  We would have to research the vendor
> implementations.
>
>   If we find that most all implementations of RFC 6790 are not setting the
> EL TTL to 0 then it’s possible we can reuse the TTL field as entropy label
> control field.
>
> [Bruno] Agreed.  So far we have not found out that.
>
>  Gyan2> Agreed
>
>   We would have to really understand the corner case with missing ELI and
> how the EL can possibly be exposed and that possibility as reasons the
> authors of RFC 6790 stated the verbiage that has drawn my attention.
>
> “b” Do we agree that this how reserved field are defined at the IETF (e.g.
> https://datatracker.ietf.org/doc/html/rfc7176#section-2.1.1) ?
>
>    Gyan> So this I am guessing in RFC 7176 is an example of how Reserved
> field is encoded with TRILL.  I don’t see the TTL field being marked as
> reserved in RFC 3032.  I am missing your point here.
>
> [Bruno] I have not said that the EL TTL has been defined as reserved per
> RFC 6790. I’m saying that it’s semantic is the one of an IETF reserved
> field (MUST be sent as zero, MUST be ignored on receipt). What matters is
> the behavior specified, not really the name.
>
>  Gyan2> Understood
>
> “c” Do we agree that the way this field is specified (cf “a”) has always
> allowed the IETF to further extend this field?
>
>  Gyan> RFC 3032 defines the label stack and RFC 6790 defines an entropy
> label for load balancing two new 4 byte label shims ELI and EL which use
> the same label stack encoding and processing rules defined in RFC 3032
> MPLS-SHIM.  I don’t see anywhere in RFC 3031 or 3032 that states that the
> TTL field can be further extended or repurposed for other uses.  I am
> afraid that if we use the field repurposed for something else it may have
> dire consequences with load balancing.
>
> [Bruno] As per the above, you should be more concerned with
> draft-kompella-mpls-mspl4fa which is happy repurpose many more TTL in the
> label stack.
> https://datatracker.ietf.org/doc/html/draft-kompella-mpls-mspl4fa-02#section-2.2
>
>
       Gyan> We need to review with the MPLS experts on the DT and discuss
reuse of TTL and other fields for extension header semantics for path
forward and come to a consensus with the team.

> 2)    Implicit null /PHP
>
> In case of PHP, the transport label is removed by the PHP and the ultimate
> node (egress LER) receives a label stack with the ELI, EL as top two labels.
>
> As per MPLS architecture, LER looks at the top label (ELI) and either:
>
> - supports RFC 6790 and then applies “Y then recognizes the ELI and pops two labels: the ELI and the EL.” In no way the EL is exposed and used for forwarding.
>
> - does not support RFC 6790 and hence will drop the packet as per RFC 3031
> (§3.18). In no way the EL is exposed and used for forwarding.
>
>
>
> So in summary, the EL is never exposed (as top label) and can never be
> used for forwarding.
>
>  Gyan>  Please see my first long comment related to RFC 6790 section 4.2
> bullet 4 states “The TTL for the EL MUST be zero to ensure that it is not
> used inadvertently for forwarding.”
>
> [Bruno] ack. And please see my answer.
>
>     Gyan2> Ack
>
>     Gyan> Section 3.5 of NS packet draft mentions how a IETF network
> slices map to a slice flow aggregate.
>
> “ the routers correlate markers
>
> present in the packets that belong to the Slice-Flow Aggregate.
>
>
>
> So is the idea that you would split the 20 bit EL label carve out
>
> bits to be used for slice flow aggregate and remaining bits to be
>
> preserved for LB function.  The common size that has been used for flow
>
> identifier has been a 20 bit field which is the size of MPLS label used
>
> as well for IPv6 flow label where the 5 tuple header hash keys are used
>
> to generate the 20 bit flow label which is an input key to hashing
>
> function for stateless uniform load balancing.  VXLAN source port entropy uses
>
> a 5 tuple header hash to generate a 16 bit source port input key to hashing function.
>
> I think the tradeoff here is how many bits to use for slice aggregate without
>
> diminishing the load balancing functionality.
>
>
>
> [Bruno] OK. Note that even with the slice ID in the entropy label (which is orthogonal to the Indicators that we were discussing above), the size of the entropy field is still 20 bits as the slice ID is an information specific (constant) to a flow, and that will vary according to flow (otherwise we would only have a single slice). So we still have 20 bits for the entropy field. That been said, I agree that the N bits of the slice ID is, in general, less likely to carry the same entropy than the one of a good crypto hash. So there is possible degradation depending on the size of the slice ID (and assuming that the Entropy is currently generated by a good crypto hash, although RFC 6790 is silent on this (any function is compliant)
>
>  Gyan2> Ack
>
> Gyan> RFC 8662 SR entropy refers to RFC 6790 on the ELI, EL semantics and does not
>
> get into the details described in RFC 6790. So as far as what I mentioned above
>
> related to discussion that TTL Must be ignored and be set to 0 is not mentioned in RFC 8662.  So there
>
> maybe a gray areas as to RFC 8662 implementations as to what was actually done.
>
>
>
> [Bruno] RFC 8662 “examines and describes how ELs are to be applied to Segment Routing MPLS.” It does not re-specify ELI, EL semantics
>
>  Gyan2> Ack
>
> Regards
>
> --Bruno
>
>
>
>
>
>
>
> Regards,
>
> --Bruno
>
>
>
>
>
> Orange Restricted
>
> *From:* Gyan Mishra <[e-mail]>
>
> *Sent:* Thursday, March 31, 2022 4:58 PM
> *To:* DECRAENE Bruno INNOV/NET <[e-mail]>
> *Cc:* Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>;
> John E Drake <[e-mail]>; detnet WG <[e-mail]>; mpls <
> [e-mail]>; [e-mail]
> *Subject:* Re: [Detnet] [mpls] [Pals]
> draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review
> the PALS/MPLS/DetNet Joint Session minutes)
>
>
>
> Hi Bruno
>
>
>
> Please provide clarification on how existing implementations using Entropy
> Label ELI/EL RFC 6790 with your proposal to reuse the entropy label.
>
>
>
> In section 2 you talk about the new entropy label control field in your
> proposal to reuse the TTL field as the entropy label control field.
>
>
>
> I have some questions related below that are concerning with your proposal.
>
>
>
> RFC 6790 section 4 talks about the TTL processing below excerpt.
>
>
>
>    If an ingress LSR X chooses to impose an EL, then Y will receive a
>
>    tunnel termination packet with label stack <TL, ELI, EL> <remaining
>
>    packet header>.  Y recognizes TL as the label it distributed to its
>
>    upstreams for the tunnel and pops it.  (Note that TL may be the
>
>    implicit null label, in which case it doesn't appear in the label
>
>    stack.)  Y then recognizes the ELI and pops two labels: the ELI and
>
>    the EL.  Y then processes the remaining packet header as normal; this
>
>    may require further processing of tunnel termination, perhaps with
>
>    further ELI+EL pairs.  When processing the final tunnel termination,
>
>    Y MAY enqueue the packet based on that tunnel TL's or ELI's TC value
>
>    and MAY use the tunnel TL's or ELI's TTL to compute the TTL of the
>
>    remaining packet header.  The EL's TTL MUST be ignored.
>
>
>
>
>
> So the TL or ELI is used to compute the TTL of the remaining packet
> header.  States that EL’s TTL is ignored.
>
>
>
> Section 4.2 mentions that the TTL for the EL MUST be set to 0 so it’s not
> used for forwarding.  The issue here is related to implicit null PHP case
> where the TL is popped and ELI,EL are exposed and to ensure that the EL is
> not used for forwarding the EL MUST be set to 0.
>
>
>
>    4.  If, for the chosen tunnel, Y has not indicated that it can
>
>        process ELs, push <TL> onto the packet.  If Y has indicated that
>
>        it can process ELs for the tunnel, push <TL, ELI, EL> onto the
>
>        packet.  X SHOULD put the same TTL and TC fields for the ELI as
>
>        it does for TL.  X MAY choose different values for the TTL and TC
>
>        fields if it is known that the ELI will not be exposed as the top
>
>        label at any point along the LSP (as may happen in cases where
>
>        PHP is used and the ELI and EL are not stripped at the
>
>        penultimate hop (see Section 4.4 <https://datatracker.ietf.org/doc/html/rfc6790#section-4.4>).  The BoS bit for the ELI MUST
>
>        be zero (i.e., BoS is not set).  The TTL for the EL MUST be zero
>
>        to ensure that it is not used inadvertently for forwarding.  The
>
>        TC for the EL may be any value.  The BoS bit for the EL depends
>
>        on whether or not there are more labels in the label stack.
>
>
>
> The EL is not used for forwarding as long as the field is set to 0 which
> is a MUST.  However if you reuse the TTL field as the entropy label control
> field it will not be set to 0 and thus that could break implementations in
> the PHP case where the ELI/EL are exposed.
>
>
>
> Also the TTL being set to 0 is different then the field being actually a
> Reserved or not applicable field.
>
>
>
> I disagree with sentence below in section 2.
>
>
>
>    Hence essentially the TTL field of the EL behaves as a reserved field
>
>    which must be set to zero when sent and ignored when received.
>
>
>
> The TTL field as I stated MUST be set to 0 so it’s not used for
> forwarding.  So it’s not reserved and it’s read by the LSR looking for the
> field to be set to 0 so it’s not used for forwarding.  I can’t see how that
> won’t break existing implementations.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Thu, Mar 31, 2022 at 12:30 AM Gyan Mishra <[e-mail]>
> wrote:
>
>
>
> I like Bruno’s idea of reusing the entropy label as indicator of MEH in
> the label stack and is backwards compatibility for devices not supporting
> can continue to use for ECMP load balancing.
>
>
>
> I think this is a solid interim solution to get the ball rolling with
> minimal software updates and being able to support ancillary data in the
> label stack and as other solutions are progressed that may take longer or
> implement and deploy at least in the near term we have a quick solution
> that could be promising for operators.
>
>
>
> I think we do have to vett out the backwards compatibility and scenario I
> can think of is if you want to be able to use the entropy label for ECMP
> load balancing and simultaneously want to also use as ancillary data
> indicator I am guessing won’t work and that is something we would have to
> be cognizant of if deployed.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Wed, Mar 30, 2022 at 4:04 PM John E Drake <jdrake=
> [e-mail]> wrote:
>
> Wim,
>
>
>
> I think I would term it a thought experiment.  An RFC 6790 compliant node
> will take the value in the EL label field and use it to select an outgoing
> interface.  If the value in the EL field is a slice ID, such an node will
> select an outgoing interface which is not necessarily part of the slice in
> question and that outgoing interface will be to a node which is not
> necessarily part of the slice in question.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>
> *Sent:* Wednesday, March 30, 2022 3:21 PM
> *To:* John E Drake <[e-mail]>; [e-mail]
> *Cc:* mpls <[e-mail]>; detnet WG <[e-mail]>; [e-mail]
> *Subject:* Re: [mpls] [Pals]
> draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review
> the PALS/MPLS/DetNet Joint Session minutes)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> John, do you have evidence of this or is this a theoretical claim ?
>
>
>
> *From: *mpls <[e-mail]> on behalf of John E Drake <
> jdrake=[e-mail]>
> *Date: *Wednesday, 30 March 2022 at 19:13
> *To: *[e-mail] <[e-mail]>
> *Cc: *mpls <[e-mail]>, detnet WG <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: [mpls] [Pals]
> draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review
> the PALS/MPLS/DetNet Joint Session minutes)
>
> Except that putting a slice ID in the Entropy Label field will break
> existing  ELI/EL Implementations because their hashing of the slice ID
> won’t necessarily place a packet on the correct outgoing I/F
>
> Sent from my iPhone
>
>
>
> On Mar 30, 2022, at 1:00 PM, [e-mail] wrote:
>
> 
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
> *From:* Tony Li <[e-mail]> *On Behalf Of *Tony Li
> *Sent:* Wednesday, March 30, 2022 4:08 PM
>
> > [Kireeti]: suggest attending talk by Tony on danger of reusing ELI
> before making any decision.
>
> https://notes.ietf.org/notes-ietf-113-pals
> <https://urldefense.com/v3/__https:/notes.ietf.org/notes-ietf-113-pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcqrP3gOo$>
>
>
>
> Done. The talk raised no “danger of reusing ELI” for draft
> draft-decraene-mpls-slid-encoded-entropy-label-id; quite the contrary.
>
> I quote: “claims of backward compatibility apply to
> draft-decraene-mpls-slid-encoded-entropy-label-id-03”. With more details on
> slide 18
>
>
> https://datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcNEC7QKk$>
>
>
>
>
>
> Yes, the issue with this proposal is that it has no space for in-stack
> data and not enough space for possible expansion of additional actions.
>
>
>
> [Bruno] There are two steps:
>
> - This proposal allows for carrying 8 Indicators and a slice ID while been
> backward compatible with egress LER hance providing faster deployment with
> incremental benefit.
>
> - If more in-stack data is required the proposal is extensible (e.g.
> draft-jags-mpls-ext-hdr) but at the cost of losing the above benefits for
> the ASes & uses-cases requiring more than 8 Indicators per AS or In-Stack
> Data.
>
> So we can have both worlds: simple first step and extensibility for those
> who need it.
>
>
>
> Independently, we also/already have the post stack data option to carry
> ancillary data, which may limit the need for In-Stack data extension.
>
>
>
> --Bruno
>
>
>
> Tony
>
>
>
>
>
>
>
> 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.
>
> _______________________________________________
> Pals mailing list
> [e-mail]
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcSqI60Zo$
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcSqI60Zo$>
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*