Re: [mpls] Indicators in the stack and ancillary data after the BoS

[[e-mail]]

Hi Haoyu,

Thanks for replying.
Please see inline [Bruno]

> -----Original Message-----
> From: Haoyu Song [mailto:[e-mail]]
> Sent: Monday, June 21, 2021 7:44 PM
> To: DECRAENE Bruno INNOV/NET <[e-mail]>; Loa
> Andersson <[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]>;
> Alexander Vainshtein <[e-mail]>; Stewart Bryant
> <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: RE: [mpls] Indicators in the stack and ancillary data after the BoS
> 
> Hi Bruno,
> 
> Thanks for the clarification. We might have some issues using the forced binding
> in some cases.
[Bruno] I'm not familiar with this 'forced binding' term.

>  For example, in our EH architecture, we allow an EH to be inserted
> or removed at any nodes on an LSP.

[Bruno] As the thread is about EH _indicator_ I'll focus on the indicator. Draft [1] does not forbid the indicator to be modified en route.
[1] https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id-01#section-2 

> Also, ELI+EI are two labels, which is more
> expensive than one SPL solution.

[Bruno]
It would be more expensive only in the case that EL is not needed/useful AND that one SPL be allocated for signaling the EH.
In all other cases, it's less expensive. 


> Having said this, I could list your proposal as a
> possible solution.
 
[Bruno] OK. I believe it should, as per the abstract of draft-song-mpls-eh-indicator


> BTW, Kireeti and I have discussed a possible option working in a different way.
> We would use a new SPL to indicate multiples things (also by encoding the unused
> TTL/CoS bits): the existence of other special labels in the label stack (e.g., ELI+EL)
> and the existence/location of extension headers after the label stack. Since we
> have a new SPL, we have more freedom to define its behavior.

[Bruno] Sure it also works. Different tradeoffs.

Best regards,
--Bruno 

> 
> Best,
> Haoyu
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Monday, June 21, 2021 9:49 AM
> To: Haoyu Song <[e-mail]>; Loa Andersson <[e-mail]>; Jeffrey
> (Zhaohui) Zhang <[e-mail]>; Alexander Vainshtein
> <[e-mail]>; Stewart Bryant <[e-mail]>;
> [e-mail]
> Cc: [e-mail]
> Subject: RE: [mpls] Indicators in the stack and ancillary data after the BoS
> 
> Hi Haoyu,
> 
> > From: Haoyu Song [mailto:[e-mail]]
> >
> > Hi Bruno,
> >
> > For clarification, does it mean an entropy label must be present in the packet?
> 
> Yes. (Both ELI and EL.)
> 
> > What if it doesn't have such a label?
> 
> The node requiring the indicator adds the Entropy Label (ELI, EL). I guess same
> principle as the other options discussed in the Figure 5 of draft-song-mpls-eh-
> indicator.
> In which case you get Entropy information for free (I mean no extra label). But from
> the entropy standpoint, it would be better to have the EL, ELI pushed by the
> ingress as this is the node which should have the most entropy information.
> 
> Thanks,
> --Bruno
> 
> > Thanks!
> >
> > Haoyu
> >
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Monday, June 21, 2021 1:50 AM
> > To: Loa Andersson <[e-mail]>; Jeffrey (Zhaohui) Zhang
> > <[e-mail]>; Alexander Vainshtein
> > <[e-mail]>; Stewart Bryant
> > <[e-mail]>; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [mpls] Indicators in the stack and ancillary data after
> > the BoS
> >
> > [+ authors of draft-song-mpls-eh-indicator]
> >
> > > From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
> > >
> > > Jeffrey,
> > >
> > >
> > > On 17/06/2021 17:01, Jeffrey (Zhaohui) Zhang wrote:
> > > > Hi Loa,
> > > >
> > > >> but I'd like to see the DT address multiple indicators in the
> > > >> stack and multiple
> > > sets of ancillary data after the BoS.
> > > >
> > > > I think the earlier emails of this email thread were talking about
> > > > multiple indicators
> > > in the stack; for multiple set of ancillary data after the BoS,
> > > either the extended ACH or the proposed MPLS/generic extension
> > > headers or a merge of those proposals should be able to handle it.
> > > This is alluded to the DataAfterBOS wiki page.
> > >
> > > hmm - yes partly, but there are several indicators proposed in
> > > several drafts
> > >
> > >   draft-gandhi-mpls-ioam-sr has an E"E indicaor and an HBH indicator
> > >
> > >   draft-kompella-mpls-mspl4fa make use of TC field and TTL of a
> > > special purpose label (FAI) as indicators
> > >
> > >   there has also been discussion about putting more than one GAL in
> > > the stack, i.e. differerent GALs pointing to different ACHs.
> > >
> > >   draft-many-mpls-multiple-gal proposes to add a copy of the GAL
> > > higher uop the stack so that LSRs with a too shallow maximun
> > > readable depth might reach the GAL
> > >
> > >   there has also been discussion about putting more than one GAL in
> > > the stack, i.e. differerent GALs pointing to different ACHs.
> > >
> > >   draft-song-mpls-eh-indicator have a list of potential indicators,
> > > that is also telling if the EH should be processed on every EH
> > > capable node or "just" at ingress and egress
> >
> > The following draft proposes a way to carry indicators.
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker
> > .ietf.org%2Fdoc%2Fhtml%2Fdraft-decraene-mpls-slid-encoded-entropy-labe
> > l-
> > id%23section-
> >
> 2&amp;data=04%7C01%7Chsong%40futurewei.com%7C08d7220727794b6895f808
> >
> d934919550%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C63759862217
> >
> 6314998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=VR7DCVMaNM8cGK
> > 0XuDLugXG6yP6jRYIlgbDuYrh%2B7uM%3D&amp;reserved=0
> >
> > It's short (less than one page) and backward compatible for LSR & LER.
> >
> > Referring to table 5 of draft-song-mpls-eh-indicator it also
> > -  does not require additional label assuming Entropy Label is already
> > used for load balancing
> > -  does not require an additional scarce resource (Special-Purpose
> > MPLS Label
> > value)
> > - allows location freedom
> > - does not need control plane extension
> >
> > Could the authors of draft-song-mpls-eh-indicator update their table 5
> > in order to include the above draft?
> >
> > Thanks,
> > Regards,
> > --Bruno
> >
> > >
> > > The FAI might put ancillary data after the BoS.
> > >
> > > I think we need to have a comprehensive discussion
> > >
> > > - first what we want to have
> > > - second how when re-direct by an indicator we find the
> > >    ancillary data that belongs to that indicator.
> > >
> > > /Loa
> > >
> > >
> > >
> > >
> > > >
> > > > Thanks.
> > > >
> > > > Jeffrey
> > > >
> > > > -----Original Message-----
> > > > From: Loa Andersson <[e-mail]>
> > > > Sent: Thursday, June 17, 2021 10:46 AM
> > > > To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Alexander
> > > > Vainshtein
> > > <[e-mail]>; Stewart Bryant
> > > <[e-mail]>
> > > > Cc: [e-mail]
> > > > Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and
> > > > ancillary data after
> > > the BoS
> > > >
> > > > [External Email. Be cautious of content]
> > > >
> > > >
> > > > DT,
> > > >
> > > > Responded to Jeffrey's mail, but it is intended to address the
> > > > entire discussion.
> > > >
> > > > There seem to be enough issues to sort out around the GAL/ACH
> > > > pair, and I was worried about a set of other indicators and the
> > > > data that they might want to put "after the BoS". So far I have
> > > > seen no real effort to address the interference's this might lead to.
> > > >
> > > > Further inline
> > > >
> > > >
> > > > On 17/06/2021 16:15, Jeffrey (Zhaohui) Zhang wrote:
> > > >> Hi,
> > > >>
> > > >> It's not clear how we could put a GAL not at a BoS:
> > > >>
> > > >>
> > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >>
> > > >>      |                              ACH                              |
> > > >>
> > > >>
> > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >>
> > > >>      |                         ACH TLV Header                        |
> > > >>
> > > >>
> > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >>
> > > >>      |                                                               ~
> > > >>
> > > >>      ~                     zero or more ACH TLVs                     ~
> > > >>
> > > >>      ~                                                               |
> > > >>
> > > >>
> > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >>
> > > >>      |                                                               ~
> > > >>
> > > >>      ~                        G-ACh Message                          ~
> > > >>
> > > >>      ~                                                               |
> > > >>
> > > >>
> > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >>
> > > >>                         Figure 2: G-ACh Packet Payload
> > > >>
> > > >> If the GAL does not have S-bit set, wouldn't a transit LSR treat
> > > >> any 4-ocet field (i.e. those in the above Figure) after that GAL
> > > >> as a
> > > >> label+TOS+S+TTL? If that 4-octet field has the S-bit set, the
> > > >> label+TOS+S+transit
> > > >> LSR will think the label stack ends there even though that's just
> > > >> part of the ACH.
> > > >>
> > > >> Or are you saying that a GAL not at the BoS will not have the ACH
> > > >> following it?
> > > >
> > > > Well, as far as I understand a GAL which does not have the NoS-bit
> > > > set will have other labels after itself. The BoS-bit will be found
> > > > deeper down stack and the ACH will immediately fo9llow the BoS.
> > > >
> > > > Yes there are issues here, but I'd like to see the DT address
> > > > multiple indicators in the stack and multiple sets of ancillary
> > > > data after the
> > BoS.
> > > >
> > > > I think we need to nail down the relevant questiuons first, and
> > > > start working on solutions after that.
> > > >
> > > > /Loa
> > > >>
> > > >> Jeffrey
> > > >>
> > > >> *From:*mpls <[e-mail]> *On Behalf Of *Alexander
> > > >> Vainshtein
> > > >> *Sent:* Thursday, June 17, 2021 5:07 AM
> > > >> *To:* Stewart Bryant <[e-mail]>
> > > >> *Cc:* [e-mail]
> > > >> *Subject:* Re: [mpls] [EXTERNAL] Indicators in the stack and
> > > >> ancillary data after the BoS
> > > >>
> > > >> *[External Email. Be cautious of content]*
> > > >>
> > > >> Stewart,
> > > >>
> > > >> I fully agree with your statement that "an old implementation
> > > >> that received a ToS GAL not at BoS would at best throw an
> > > >> exception or worst be unpredictable".
> > > >>
> > > >> Regarding your statement "it is OK to have multiple GALs and GALs
> > > >> not at BoS IFF the creator of the LSP ensured that all LSRs on
> > > >> the LSP, including ECMP and FRR paths that found the GAL at ToS
> > > >> were known to be able to process it correctly":
> > > >>
> > > >>   1. I fully agree with this statement as a general restriction
> > > >>   2. Quite a lot of things have to be done in order to make this
> > > >>      restriction work including at least:
> > > >>
> > > >>       1. The definition of correct processing of GAL at ToS but not at
> > > >>          BoS must be provided
> > > >>       2. Advertisement of ability to process GAL not at BoS correctly in
> > > >>          IGP and BGP must be defined
> > > >>       3. Ability to set up network-wide paths that only cross nodes that
> > > >>          process GAL correctly must be provided for different techniques
> > > >>          (RSVP-TE, SR-TE, FlexAlgo. BGP-LU etc.)
> > > >>
> > > >> It is still possible that, after all this work, we shall find out
> > > >> that the benefits of supporting GAL at ToS but not BoS will be
> > > >> only available in the networks where all the nodes support the
> > > >> new functionality because presence of non-supporting nodes
> > > >> imposes too many restrictions on connectivity and/or resilience.
> > > >>
> > > >> Regards,
> > > >>
> > > >> Sasha
> > > >>
> > > >> Office: [phone]
> > > >>
> > > >> Cell:      [phone]
> > > >>
> > > >> Email: [e-mail]
> > > <mailto:[e-mail]>
> > > >>
> > > >> *From:*Stewart Bryant <[e-mail]
> > > >> <mailto:[e-mail]>>
> > > >> *Sent:* Thursday, June 17, 2021 10:36 AM
> > > >> *To:* Alexander Vainshtein <[e-mail]
> > > >> <mailto:[e-mail]>>
> > > >> *Cc:* Stewart Bryant <[e-mail]
> > > >> <mailto:[e-mail]>>; [e-mail]
> > > >> <mailto:[e-mail]>; [e-mail]
> > > >> <mailto:[e-mail]>
> > > >> *Subject:* Re: [mpls] [EXTERNAL] Indicators in the stack and
> > > >> ancillary data after the BoS
> > > >>
> > > >>      On 17 Jun 2021, at 07:45, Alexander Vainshtein
> > > >>      <[e-mail]
> > > >>      <mailto:[e-mail]>> wrote:
> > > >>
> > > >>      While that might be the case, I think that the Open DT may give it a
> > > >>      try and investigate how the existing systems will handle GAL being
> > > >>      not the BoS label.
> > > >>
> > > >>      */[[Sasha]] Great minds think alike! One useful step could be
> > > >>      collecting the known actual behavior of popular implementations in
> > > >>      this case, say, by running a survey among the vendors - what do you
> > > >>      think?/*
> > > >>
> > > >> That is actually a considerable amount of work that will take a while.
> > > >>
> > > >> It seems to me that an old implementation that received a ToS GAL
> > > >> not at BoS would at best throw an exception or worst be unpredictable.
> > > >>
> > > >> The original assumed processing model is to take the context of
> > > >> the PW label or PW+FAT label, discover the GAL and then process
> > > >> the GAL in the context of the PW label.
> > > >>
> > > >> When we extended GAL to apply to LSPs we again had the model that
> > > >> the GAL operated in the context of the LSP label that preceded it
> > > >> for context. It was still BoS.
> > > >>
> > > >> Putting the GAL further up the stack is a new behaviour.
> > > >>
> > > >> If it arrives at an LSR that knows the new semantic all is good.
> > > >>
> > > >> If it arrives at an LSR that does not know the new semantic then
> > > >>
> > > >> a) An error has occurred either in setting up the LSP, or in forwarding.
> > > >>
> > > >> b) The behaviour at the receiving node is unpredictable, but in
> > > >> any well written implementation should just result in the packet
> > > >> being dropped and counted as with any other Mal-formed packet.
> > > >>
> > > >> So I would think that it is OK to have multiple GALs and GALs not
> > > >> at BoS IFF the creator of the LSP ensured that all LSRs on the
> > > >> LSP, including ECMP and FRR paths that found the GAL at ToS were
> > > >> known to be able to process it correctly.
> > > >>
> > > >> A GAL not at BoS and not at ToS should not be inspected or
> > > >> processed by any LSR that did not know what it was doing, and to
> > > >> attempt to precess it would be a violation of the normal MPLS
> > > >> processing
> > model.
> > > >>
> > > >> - Stewart
> > > >>
> > > >>
> > > >> Notice: This e-mail together with any attachments may contain
> > > >> information of Ribbon Communications Inc. and its Affiliates that
> > > >> is confidential and/or proprietary for the sole use of the
> > > >> intended recipient. Any review, disclosure, reliance or
> > > >> distribution by others or forwarding without express permission
> > > >> is strictly prohibited. If you are not the intended recipient,
> > > >> please notify the sender immediately and then delete all copies, including
> any attachments.
> > > >>
> > > >>
> > > >> Juniper Business Use Only
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> mpls mailing list
> > > >> [e-mail]
> > > >>
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
> > > ld
> > >
> >
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%
> > 2F
> > >
> >
> mpls__%3B!!NEt6yM&amp;data=04%7C01%7Chsong%40futurewei.com%7C08d72
> > 2072
> > >
> >
> 7794b6895f808d934919550%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%
> > 7C6
> > >
> >
> 37598622176314998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > JQIjoi
> > >
> >
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=zE3QHyImI86j
> > 7K
> > > zn9PKE5qasAU01YKm%2FbbpXg6g4hAc%3D&amp;reserved=0
> > > aO-gk!RVgTGVbknjgIjv3x-
> > > q8ob1JglFKOP6qKkgAcCSPbeBMMj2AnexFnPevXopeK1a6u$
> > > >>
> > > >
> > > > --
> > > >
> > > > Loa Andersson                        email: [e-mail]
> > > > Senior MPLS Expert                          [e-mail]
> > > > Bronze Dragon Consulting             phone: [phone]
> > > >
> > > > Juniper Business Use Only
> > > >
> > >
> > > --
> > >
> > > Loa Andersson                        email: [e-mail]
> > > Senior MPLS Expert                          [e-mail]
> > > Bronze Dragon Consulting             phone: [phone]
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > >
> >
> ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chsong%40futur
> > e
> > >
> >
> wei.com%7C08d7220727794b6895f808d934919550%7C0fee8ff2a3b240189c753a1
> > d5
> > >
> >
> 591fedc%7C1%7C1%7C637598622176324952%7CUnknown%7CTWFpbGZsb3d8e
> > yJWIjoiM
> > >
> >
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&am
> > p;s
> > >
> >
> data=b7TztzRbKspQdyrJ8%2Btps6IeLQlCl3E0mrgvJRydlTk%3D&amp;reserved=0
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.


_________________________________________________________________________________________________________________________

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.