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
On Sat, Apr 2, 2022 at 3:32 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> Hi Bruno
>
> Responses in-line
>
> On Fri, Apr 1, 2022 at 1:56 PM <bruno.decraene@orange.com> 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.
> 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.  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.  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.  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.  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.
>
> “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.
>>
>> 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.”
>>
>
>     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.
>
>
> 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.
>
>

    Gyan> There could be a possible implementation specific recirculation
issue or the sort that causes the ELI and EL to get separated and I am
guessing that feedback from implementations prior to WGLC that maybe was
found and it was then required to make the EL set TTL to 0 and verbiage
added so it’s not used for forwarding.

>
>
>>
>> Regards,
>>
>> --Bruno
>>
>>
>>
>>
>>
>> Orange Restricted
>>
>> *From:* Gyan Mishra <hayabusagsm@gmail.com>
>>
>> *Sent:* Thursday, March 31, 2022 4:58 PM
>> *To:* DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
>> *Cc:* Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>;
>> John E Drake <jdrake@juniper.net>; detnet WG <detnet@ietf.org>; mpls <
>> mpls@ietf.org>; pals@ietf.org
>> *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 <hayabusagsm@gmail.com>
>> 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=
>> 40juniper.net@dmarc.ietf.org> 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) <wim.henderickx@nokia.com>
>> *Sent:* Wednesday, March 30, 2022 3:21 PM
>> *To:* John E Drake <jdrake@juniper.net>; bruno.decraene@orange.com
>> *Cc:* mpls <mpls@ietf.org>; detnet WG <detnet@ietf.org>; pals@ietf.org
>> *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 <mpls-bounces@ietf.org> on behalf of John E Drake <
>> jdrake=40juniper.net@dmarc.ietf.org>
>> *Date: *Wednesday, 30 March 2022 at 19:13
>> *To: *bruno.decraene@orange.com <bruno.decraene@orange.com>
>> *Cc: *mpls <mpls@ietf.org>, detnet WG <detnet@ietf.org>, pals@ietf.org <
>> pals@ietf.org>
>> *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, bruno.decraene@orange.com wrote:
>>
>> 
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>>
>>
>>
>>
>> *From:* Tony Li <tony1athome@gmail.com> *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
>> Pals@ietf.org
>>
>> 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
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>> *M 301 502-1347*
>>
>>
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>> *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 gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*