Re: [mpls] AI: Multiple ISD instances in a packet

[Joel Halpern <[e-mail]>]

Care to elaborate?  Why would MRT LDP Fast Reroute need stop-rerouting 
to apply after the merge point?

Yours,

Joel

On 6/24/2023 4:53 PM, Stewart Bryant wrote:
> I think RFC 7811 would need it.
>
> Stewart
>
>> On 23 Jun 2023, at 11:10 am, jmh.direct <[e-mail]> 
>> wrote:
>>
>> 
>> Is there any draft where such a requirement is described?
>> Yours,
>> Joel
>>
>>
>>
>> Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
>>
>>
>> -------- Original message --------
>> From: Stewart Bryant <[e-mail]>
>> Date: 6/23/23 1:46 AM (GMT-05:00)
>> To: Joel Halpern <[e-mail]>
>> Cc: mpls <[e-mail]>
>> Subject: Re: [mpls] AI: Multiple ISD instances in a packet
>>
>> Joel
>>
>> I am not conflating anything. Some FRR strategies require NFRR to the 
>> domain egress.
>>
>> Stewart
>>
>>> On 23 Jun 2023, at 7:35 am, Joel Halpern <[e-mail]> wrote:
>>>
>>> 
>>>
>>> Stewart, you appear to be conflating two very different behaviors.  
>>> NFFRR, preventing failure-based rerouting while traversing a 
>>> failure-based rerouting path, is easy to mark in the packet.  It is 
>>> a natural step to avoid acccidentally returning to the failure, as 
>>> the packet can easily be in a region where a second failure would 
>>> cause such reversion.
>>>
>>> Stop-Rerouting is a different behavior.  You describe wanting 
>>> something that applies after exiting the repair path.  That is not a 
>>> matter of operator choice.  It is a different function.  I strongly 
>>> expect that if presented with a draft that required that, I would 
>>> argue that it is a bad idea, solving a non-problem.  I also note 
>>> that it would actually require some interesting surgery on the MPLS 
>>> label stack.  In the worst case, if there are no other MNA 
>>> sub-stacks in the label stack, the node inserting Stop-Reroute 
>>> indication would have to examine the stack, decide how often it 
>>> needs to insert sub-stacks, and insert potentially several 
>>> substacks. Not that this would be required even if you put the 
>>> Stop-Reroute indication into post-stack data, as there would be no 
>>> indications in the remaining label stack of the presence of 
>>> post-stack data.
>>>
>>> Please, lets not create an extremely difficult case of little or no 
>>> value. NFFRR over the repair path has clear value and fits with the 
>>> MPLS paradigms.
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>> On 6/23/2023 12:36 AM, Stewart Bryant wrote:
>>>> I think NFRR may need  to apply to the whole of the routing domain 
>>>> over which the FRR instance applies.
>>>>
>>>> I further think that this is a matter of operator preference.
>>>>
>>>> Say we have failure A, which FRRa repairs. Say we also have failure 
>>>> B, which FRRb repairs. If FRRb uses resource A then a loop can form.
>>>>
>>>> The most common strategy is to say that in any multiple failure 
>>>> case we “abandon all hope” and revert to normal (slow) convergence. 
>>>> That implies that NFRR should be sticky over the repair domain.
>>>>
>>>> I can imagine that some operators may place their bets one way and 
>>>> some the other, because if there is no repair loop clearing NFRR 
>>>> allows productive forwarding to continue.
>>>>
>>>> The interesting case is what happens when we leave that repair 
>>>> domain? I think that we can usefully release the NFRR constraint at 
>>>> that point since as far as I know no one is doing inter domain FRR.
>>>> Thus I think to clear or not is going to have to be an operator 
>>>> preference.
>>>>
>>>> Stewart
>>>>
>>>>
>>>> Sent from my iPad
>>>>
>>>>> On 23 Jun 2023, at 01:56, Joel Halpern <[e-mail]> wrote:
>>>>>
>>>>> 
>>>>>
>>>>> My assumption is that the no further fast reroute constraint is 
>>>>> only intended to apply over the reroute path.  In that case, the 
>>>>> flag is set in any MNAs that are added for the reroute.    It is 
>>>>> fine for the flag to disappear once the merge point is reached.
>>>>>
>>>>> If we want a meaning that prevents reroute even after the merge, 
>>>>> things get more interesting.  After all, there may not be any MNA 
>>>>> further down the stack.  From where I sit, what happens with a 
>>>>> second failure after the merge seems to be a non-issue, since 
>>>>> until convergence the shortest path from the merge point to the 
>>>>> destination has to avoid the failed node inherently.  So repairs 
>>>>> there will also avoid it.  One can, I suppose, construct 
>>>>> pathalogical cases.  So be it.  They break.
>>>>>
>>>>> Yours,
>>>>>
>>>>> Joel
>>>>>
>>>>> On 6/22/2023 7:42 PM, Haoyu Song wrote:
>>>>>>
>>>>>> I’m still confused.
>>>>>>
>>>>>> Take  NFFRR as an example. Let’s assume it is implemented as a 
>>>>>> flag-based action. If the flag bit is set, it means “no more RR”. 
>>>>>>  The default value is 0, meaning FRR is allowed.
>>>>>>
>>>>>> In case we have multiple copies of the ISD in the stack, then at 
>>>>>> some node, if we want to set the flag, then it’s not enough to 
>>>>>> only set the flag in the top ISD. Because if we do so, once the 
>>>>>> top ISD is popped, the lower copies all show the FRR is allowed.
>>>>>>
>>>>>> This may not be a perfect example, but such kind of thing may 
>>>>>> happen. The multiple copies need to remain in sync. If there are 
>>>>>> writable actions in the copies, we can lose the synchronization.
>>>>>>
>>>>>> Haoyu
>>>>>>
>>>>>> *From:* Joel Halpern <[e-mail]>
>>>>>> *Sent:* Thursday, June 22, 2023 1:24 PM
>>>>>> *To:* Tony Li <[e-mail]>; Tarek Saad <[e-mail]>
>>>>>> *Cc:* Haoyu Song <[e-mail]>; mpls <[e-mail]>
>>>>>> *Subject:* Re: [mpls] AI: Multiple ISD instances in a packet
>>>>>>
>>>>>> If the new MNA hop-by-hop sub-stack includes all the elements 
>>>>>> from the lower one, then the examining node only needs to look at 
>>>>>> / act on the top one, and there is no need to modify things lower 
>>>>>> in the stack.
>>>>>>
>>>>>> Yours,
>>>>>>
>>>>>> Joel
>>>>>>
>>>>>> On 6/22/2023 4:13 PM, Tony Li wrote:
>>>>>>
>>>>>>     I think that the ISD draft says that a forwarding node only
>>>>>>     needs to look at the top most ISD header of a given scope.
>>>>>>
>>>>>>     Tony
>>>>>>
>>>>>>
>>>>>>
>>>>>>         On Jun 22, 2023, at 12:47 PM, Tarek Saad
>>>>>>         <[e-mail]> <mailto:[e-mail]> wrote:
>>>>>>
>>>>>>         I agree with Joel.
>>>>>>
>>>>>>         If we ensure ISD2 (closer to top) >= ISD1 (lower), then
>>>>>>         it can cater for the two cases:
>>>>>>
>>>>>>           * ISD1 is always executed end-to-end
>>>>>>           * (ISD2 - ISD1) is applicable to subset nodes
>>>>>>             (downstream of node introducing ISD2)
>>>>>>
>>>>>>         Regards,
>>>>>>
>>>>>>         Tarek
>>>>>>
>>>>>>         *From:*mpls <[e-mail]>
>>>>>>         <mailto:[e-mail]> on behalf of Joel Halpern
>>>>>>         <[e-mail]> <mailto:[e-mail]>
>>>>>>         *Date:*Thursday, June 22, 2023 at 3:41 PM
>>>>>>         *To:*Haoyu Song <[e-mail]>
>>>>>>         <mailto:[e-mail]>, Tony Li
>>>>>>         <[e-mail]> <mailto:[e-mail]>, mpls
>>>>>>         <[e-mail]> <mailto:[e-mail]>
>>>>>>         *Subject:*Re: [mpls] AI: Multiple ISD instances in a packet
>>>>>>
>>>>>>         As far as I can tell, there is no currently defined
>>>>>>         circumstance when a
>>>>>>         node pushing actions on the stack needs to modify the
>>>>>>         ones deeper down.
>>>>>>         It does need to make sure that the new top MNA includes
>>>>>>         all the
>>>>>>         hop-by-hop actions of the hop-by-hop MNA below it.  (By
>>>>>>         recursion, taht
>>>>>>         will include those from all further down.)
>>>>>>
>>>>>>         Yours,
>>>>>>
>>>>>>         Joel
>>>>>>
>>>>>>         On 6/22/2023 3:32 PM, Haoyu Song wrote:
>>>>>>         > Hi Tony,
>>>>>>         >
>>>>>>         > You said " a node may choose to modify an ISD header.
>>>>>>         If it is modifying a repeated header, it SHOULD update
>>>>>>         all copies of the header, unless that's not the semantics
>>>>>>         that are intended by its modification."
>>>>>>         > The problem is: the reason for having multiple
>>>>>>         replications is to cope with the reachability issue. If
>>>>>>         the other replications except the top one is unreachable
>>>>>>         at an intermediate node, how can it be modified?
>>>>>>         >
>>>>>>         > Thanks,
>>>>>>         > Haoyu
>>>>>>         >
>>>>>>         >
>>>>>>         > -----Original Message-----
>>>>>>         > From: mpls <[e-mail]>
>>>>>>         <mailto:[e-mail]> On Behalf Of Tony Li
>>>>>>         > Sent: Thursday, June 22, 2023 7:44 AM
>>>>>>         > To: mpls <[e-mail]> <mailto:[e-mail]>
>>>>>>         > Subject: [mpls] AI: Multiple ISD instances in a packet
>>>>>>         >
>>>>>>         >
>>>>>>         > Hi,
>>>>>>         >
>>>>>>         > This is an attempt to address an open action item on
>>>>>>         our list:
>>>>>>         >
>>>>>>         > * LSR's behavior when multiple ISDs are in the packet *
>>>>>>         Should ISD (above) be a superset of ISD (below)?
>>>>>>         > * If ISD is repeated in the stack (due to readable
>>>>>>         depth) - modifying only the (above) ISD can lead to
>>>>>>         inconsistency
>>>>>>         >
>>>>>>         > Please see draft-ietf-mpls-mna-hdr-02. I believe that
>>>>>>         all of these questions have been answered in the draft.
>>>>>>         >
>>>>>>         > Multiple ISD headers are allowed in a single packet for
>>>>>>         two reasons:
>>>>>>         >
>>>>>>         > 1) A packet may contain ISD header for multiple scopes
>>>>>>         (HBH, I2E, Select). The contents of an ISD header for one
>>>>>>         scope cannot be combined with another scope without
>>>>>>         changing the intended semantics.
>>>>>>         > 2) A packet may repeat an ISD header because of the
>>>>>>         readable stack depth.
>>>>>>         >
>>>>>>         > In the first case, the contents of the various ISD
>>>>>>         headers are independent and one should not be a superset
>>>>>>         of any other.
>>>>>>         >
>>>>>>         > In the second case, where a header has been repeated,
>>>>>>         each repeated header should be identical, initially.
>>>>>>         >
>>>>>>         > In the case that we discussed last week, a node may
>>>>>>         choose to modify an ISD header. If it is modifying a
>>>>>>         repeated header, it SHOULD update all copies of the
>>>>>>         header, unless that's not the semantics that are intended
>>>>>>         by its modification. More specifically, we spoke about
>>>>>>         injecting NFFRR. It was suggested that this should be
>>>>>>         injected with Select scope. If there is an existing
>>>>>>         Select scope header in the desired location in the stack,
>>>>>>         then the node should modify the existing header. If there
>>>>>>         are additional replications of the Select header, then
>>>>>>         NFFRR should NOT be added to them, as that would not
>>>>>>         provide the semantics that NFFRR requires.
>>>>>>         >
>>>>>>         > A modification of a HBH ISD header is more likely to
>>>>>>         require modification of each replication.  I'm sorry, I
>>>>>>         don't have a good example of a HBH action that would be
>>>>>>         applied mid-path.
>>>>>>         >
>>>>>>         > Yes, in this case, a node that only modified the first
>>>>>>         HBH ISD header would be in error.
>>>>>>         >
>>>>>>         > I hope that this addresses the AI and that we can now
>>>>>>         close it. I welcome any discussion or questions on this.
>>>>>>         >
>>>>>>         > Regards,
>>>>>>         > Tony
>>>>>>         >
>>>>>>         > _______________________________________________
>>>>>>         > mpls mailing list
>>>>>>         > [e-mail]
>>>>>>         >https://www.ietf.org/mailman/listinfo/mpls
>>>>>>         >
>>>>>>         > _______________________________________________
>>>>>>         > mpls mailing list
>>>>>>         > [e-mail]
>>>>>>         >https://www.ietf.org/mailman/listinfo/mpls
>>>>>>
>>>>>>         _______________________________________________
>>>>>>         mpls mailing list
>>>>>>         [e-mail]
>>>>>>         https://www.ietf.org/mailman/listinfo/mpls
>>>>>>
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mpls