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

[Huub van Helvoort <[e-mail]>]

Hi Stewad, Sasha,

I second that.

Cheers, Huub.

=====

On 17/06/2021 17:07, Stewart Bryant wrote:
> Hi Sasha
> 
> I completely agree on all points.
> 
> Stewart
> 
>> On 17 Jun 2021, at 10:06, Alexander Vainshtein 
>> <[e-mail] <mailto:[e-mail]>> 
>> wrote:
>>
>> 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:
>> a.The definition of correct processing of GAL at ToS but not at BoS 
>> must be provided
>> b.Advertisement of ability to process GAL not at BoS correctly in IGP 
>> and BGP must be defined
>> c.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.
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 


-- 
================================================================
Always remember that you are unique...just like everyone else...