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

[Loa Andersson <[e-mail]>]

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 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://www.ietf.org/mailman/listinfo/mpls
> 

-- 

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