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

[Joel Halpern <[e-mail]>]

One other way of looking at this discussiomn.

What I wrote up is, as far as I can tell, a generic requirement implicit 
in our current definitions for what an MNA-aware node must do when 
pushing new labels onto a label stack with existing MNA sub-stacks.  We 
need to include that in the base definition.

If you think there is some specific action that needs to include in its 
definition reaching down and modifying the label stack, write up how 
that works, including what happens if the starting stack has no MNA 
sub-stacks or doesn't have one on its final label.   And explain clearly 
why the action needs that very complicated behavior.
Then the "operator choice" becomes which action they want implemented, 
not variation in how an action behaves.

Yours,

Joel

On 6/24/2023 4:59 PM, Joel Halpern wrote:
>
> 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
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls