Re: [mpls] Some thoughts on BoS and ACH. U

[Tarek Saad <[e-mail]>]

Hi Loa,

Thanks for reaching out. See some comments from me inline..

On 3/14/21, 12:19 AM, "Loa Andersson" <[e-mail]> wrote:

    Kireeti, Tarek, et.al.

    I’m not really done digesting your draft and slides.

    One corner stone in MPLS has been that there is no semantics to the bits in the 20 bit label value.
[TS]: The idea here is to embed an "identifier" in the MPLS label stack with a proper alert mechanism that enables LSRs to know of the presence of such ID. This is very similar to embedding a per-flow identifier (entropy) in the label stack and using ELI as the alert mechanism.

    I’m not sure I want to change that, but would be prepared to discuss.

    You say that TC field and TTL is not acted upon other than for the top label. Doesn’t RFC 3443 do that?

    All,

    One other thing that is that I see a number of new solutions, that if they are all progressed will create a very complicated set of interdependencies.
[TS]: Indeed, there are multiple requests today from the MPLS WG for such "alert" special purpose labels -- i.e. if SPL1 then action1, if SPL2 then action2, etc.
Kireeti presented a single "alert" SPL that can potentially indicate multiple actions action1, action2, etc... IMO, this superior to bloating the MPLS label stack with multiple (SPL1, action1) , (SPL2, action2), (SPL2, action3), etc. when the multiple actions are needed need for the same packet.

    I would like to see one method to find multiple ACH’s after the BoS.

[TS]: I agree any metadata after the BoS need to be carefully considered (as was discussed in the JOINT meeting). Ideally, I see two potential efforts -
- Carrying ID(s) in the label stack with a proper "alert" SPL
- Carrying metadata after BoS

    My straw man.

    What if?

    We create a two new FECs.

    That first FEC says
    - use this label for FIB LOOK-up
    - this is for end node processing
    - be aware that there is a special ACH after the BoS.

    The second FEC says
    - use this label for the FIB look-up
    - this is for hop by hop processing
    - be aware that there is a special ACH after the BoS
[TS]: Embedding context within the FEC is always an option. However, it comes with toll on the amount of control plane and dataplane states. For example, if you there are 1000 nodes in a network with 1000 slices, a node may have to store up to 1000x1000 FECs (1M labels) - in addition to the control plane state. BTW, we described this scale concern in section 2 of I-D. draft-bestbar-spring-scalable-ns.


    The Special ACH would give you the number of ACH’es after the BoS and their length, in the order you’d find them, including the Special ACH itself.

    The old methods to find one ACH after the BoS would work, since they are not using the new FEC. And could gradually fade out.

[TS]: Yes, I think the ACH/metadata discussion after the BoS can contrinuee to progress among its own group (open meeting).

Regards,
Tarek

    /Loa

    Sent from my iPhone


Juniper Business Use Only