Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04

[Stewart Bryant <[e-mail]>]

Yes that would work, but it means that you have to do three lookups at every hop and push three labels, and that is without searching for the ELI.

Those extra two labels reduce the number of SR labels you can push. If you need an EL that would mean that the legacy nodes that can only push 4 labels just burned their way through their limit without saying where the packet was going. 

We can obviously do this, but I worry that the number of SPLs on packets is getting out of hand.

When MPLS was first introduced there was a fundamental philosophy not to push any more labels than you needed and not to look further down the stack than you needed. We seem to have lost sight of that, and I am worried where it ends.

- Stewart



> On 7 Jan 2021, at 08:08, Mach Chen <[e-mail]> wrote:
> 
> Hi Loa,
> 
> It depends where to put the (e)SPL and how to process the eSPL. If we define an eSPL and always put the eSPL on the top of the label stack. It means when sending a packet to next LSR, an eSPL will be put on the top of the stack, when the next LSR received the packet, the eSPL indicates iOAM related process needed, then pop off eSPL and process the next label that will result in forwarding the packet to the next LSR. When sending the packet to next LSR, an eSPL will be put back on the top of the stack. It just likes popping off two labels and pushing one label back. But this requires that all the LSRs along the packet MUST know how to process the eSPL, otherwise, the packet may be discarded.
> 
> Best regards,
> Mach
> 
>> -----Original Message-----
>> From: Loa Andersson [mailto:[e-mail]]
>> Sent: Thursday, January 7, 2021 1:13 PM
>> To: Mach Chen <[e-mail]>; Greg Mirsky
>> <[e-mail]>
>> Cc: Stewart Bryant <[e-mail]>; Rakesh Gandhi (rgandhi)
>> <rgandhi=[e-mail]>; mpls <[e-mail]>;
>> [e-mail]; mpls-chairs <[e-mail]>
>> Subject: Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
>> 
>> Maach,
>> 
>> If it is a requirement from iOAM to do hop by hop processing, then the SPL/eSPL
>> is a very blunt tool, there is is always a risk that the (e)SPL label that indicate
>> the special behavior is below the maximum stack depth that can be scanned.
>> 
>> Right?
>> 
>> If we create a FEC that says "this packet has a hop by hop processing
>> requirement, go find the ACH-header immediately after the label stack to see
>> what you need to do." That would not solve the immediate problem but also be
>> useful for the future.
>> 
>> /Loa
>> 
>> 
>> On 07/01/2021 11:50, Mach Chen wrote:
>>> Hi all,
>>> 
>>> IMHO, I think the key issue is that there is no hop-by-hop option in
>>> MPLS, but the iOAM requires that.
>>> 
>>> There are three potential options:
>>> 
>>> 1)Scan the stack and find the (e)SPL label that indicate the special
>>> behavior;
>>> 
>>> 2)Introduce an (e)SPL and always keep it on the top of the label
>>> stack;
>>> 
>>> 3)Use the way as Stewart suggested, a new FEC, just like the SFL;
>>> 
>>> Best regards,
>>> 
>>> Mach
>>> 
>>> *From:*Greg Mirsky [mailto:[e-mail]]
>>> *Sent:* Thursday, January 7, 2021 11:30 AM
>>> *To:* Loa Andersson <[e-mail]>
>>> *Cc:* Stewart Bryant <[e-mail]>; Rakesh Gandhi
>>> (rgandhi) <rgandhi=[e-mail]>; mpls <[e-mail]>;
>>> [e-mail]; mpls-chairs <[e-mail]>
>>> *Subject:* Re: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
>>> 
>>> Hi Loa, et al.,
>>> 
>>> RFC 8169 uses TTL expiration to achieve processing at each RTM-capable
>>> node. That approach creates a state in transient nodes and may not fit
>>> with the "no state" paradigm of the Segment Routing.
>>> 
>>> And I've got a question. AFAIK, the presence of ACH in an MPLS LSP is
>>> indicated by GAL. Is there an intention to introduce another (E)SPL
>>> for that?
>>> 
>>> Regards,
>>> 
>>> Greg
>>> 
>>> On Wed, Jan 6, 2021 at 7:20 PM Loa Andersson <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>> 
>>>    Stewart,
>>> 
>>>    If we want to make sure that packets are processed at evey node, is the
>>>    new FEC complementary to the ACH-header or an alternative?
>>> 
>>>    /Loa
>>> 
>>>    On 05/01/2021 00:30, Stewart Bryant wrote:
>>>> 
>>>> 
>>>>> On 4 Jan 2021, at 14:38, Rakesh Gandhi (rgandhi)
>>>>> <rgandhi=[e-mail]
>> <mailto:[e-mail]>
>>>>> <mailto:rgandhi <mailto:rgandhi>=[e-mail]
>>>    <mailto:[e-mail]>>> wrote:
>>>>> 
>>>>> <RG> Yes, this is similar to the entropy label where a mid-point node
>>>>> needs to scan the label stack to find the indicator label. We can add
>>>>> some text to clarify this. There is already an optimization to use a
>>>>> different indicator label for HbH compared to E2E case to
>>>>> unnecessarily avoid parsing the IOAM data fields.
>>>> 
>>>> The EL is entirely optional to process. It is no more than a hint to use
>>>> in ECMP and there is no architectural requirement to find it to operate
>>>> correctly.
>>>> 
>>>> If iOAM is purely a option then you could scan the stack and hope that
>>>> you can reach down far enough to find it. Though there is a fight to
>> see
>>>> who gets to be the lowest label in range of the forwarding parser.
>>>> 
>>>> If you want to be sure that iOAM is processed HxH then you really
>> need
>>>> to run it on a new FEC with that behaviour built into the FEC. That
>>>> would be the architected way of doing this in MPLS.
>>>> 
>>>> - Stewart
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>    <https://www.ietf.org/mailman/listinfo/mpls>
>>>> 
>>> 
>>>    --
>>> 
>>>    Loa Andersson                        email: [e-mail]
>> <mailto:[e-mail]>
>>>    Senior MPLS Expert [e-mail]
>> <mailto:[e-mail]>
>>>    Bronze Dragon Consulting             phone: [phone]
>>> 
>>>    _______________________________________________
>>>    mpls mailing list
>>>    [e-mail] <mailto:[e-mail]>
>>>    https://www.ietf.org/mailman/listinfo/mpls
>>>    <https://www.ietf.org/mailman/listinfo/mpls>
>>> 
>> 
>> --
>> 
>> Loa Andersson                        email: [e-mail]
>> Senior MPLS Expert                          [e-mail]
>> Bronze Dragon Consulting             phone: [phone]