Re: [mpls] Reference Augmented Forwarding - MPLS RAF

Tony Li <tony.li@tony.li> Fri, 29 April 2022 14:27 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2258C15E41B for <mpls@ietfa.amsl.com>; Fri, 29 Apr 2022 07:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.502
X-Spam-Level:
X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxSJ9YJq4kG4 for <mpls@ietfa.amsl.com>; Fri, 29 Apr 2022 07:27:36 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D6DC159A25 for <mpls@ietf.org>; Fri, 29 Apr 2022 07:27:36 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id l6so913081pls.10 for <mpls@ietf.org>; Fri, 29 Apr 2022 07:27:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6di9F6xOFsfmkQ2JksicUOy3zf78ZS+1HjCwd/4s5hs=; b=J0T1ptQ6OnZnjf0vtM75BsBcO5VIHcYPDqkQxGiOo7wX24O5PNvGIbQ9HgXKK96uk8 Iipq/9526b54O1fdrOPxazubH19srCXdxvMlGpl7KIHKPvwDR25NQ3/dMRiMwvtzaDdw COcXNOLbQJV2fZwgMGL/HSeNg8aM3DpaFz4O6iIxq9Lp/NuFV+xXMo3K7C+wdqVBu+// uj0hrigqNgwCJnvctT9FDjSMQqM5zCihuN/5Pgo3+xXnB9D8sZIn2Rs9MN3/jSuUW3Y7 jGQn2Hunc0DaiONP2a9GrZwdZBz5LIQNvXmOalgwx6/5aXpc4LQycQyfB3NBT+CYEkmh BB0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6di9F6xOFsfmkQ2JksicUOy3zf78ZS+1HjCwd/4s5hs=; b=0/eQZix2uUaxzSFQ5DX5Sg4rnicQWtiJQdJGHGvp6AGU+L1h5mdZFkZHL2jIAlbOa0 cTrv1UeuGeElQzzK20z/C6MWrysQdgtsr18lxxl1rEW+8iQQ5eR09Jo7U+JBJSLBjngF keYEbjuZlTrAt34iwsRU5Y6NqKQCykOwHcLtyjoAjGXZRYFpwF7b9n1NRVfW6y8JpoXC keS2qd6acaLEAONJ/hBx2xORyw0HyNM2n8jHULEoDzF118sN7c3q6OT6731HykMOUmhr eIWKJi0WX6Z405sqG3uJafkcoEt36Gdu3kbP4jt3+qjGf2EMeZ98qFi06nYzFV2lV6SQ P+Iw==
X-Gm-Message-State: AOAM530Go0FyVdJB+sMjkuGjDu71aHC9wGkKa9vwAv3pG+4bsOav/myo vzPsSQEUCBEtGLScqK7Nx9A=
X-Google-Smtp-Source: ABdhPJz0vOpIzbhYV9cXHrAr3XWGX3ntMGuhGK+Pglrl9s/mdjcWp2dC1h1n+L55cEvIg6QCqdBDkg==
X-Received: by 2002:a17:90a:31cf:b0:1c9:f9b8:68c7 with SMTP id j15-20020a17090a31cf00b001c9f9b868c7mr4337136pjf.34.1651242455824; Fri, 29 Apr 2022 07:27:35 -0700 (PDT)
Received: from smtpclient.apple (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id q12-20020a63f94c000000b003c14af50635sm6321510pgk.77.2022.04.29.07.27.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Apr 2022 07:27:35 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <676395A9-CF1A-4B17-B95F-95D4310F2AB3@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D46B2665-1632-4D90-A4E3-2131078A439A"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Fri, 29 Apr 2022 07:27:33 -0700
In-Reply-To: <CA+b+ERnv30a8xLGifDQnCMK8TfB3jEwzbZy6n23zShNvujw+bA@mail.gmail.com>
Cc: John E Drake <jdrake@juniper.net>, Haoyu Song <haoyu.song@futurewei.com>, mpls <mpls@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, Kireeti Kompella <kireeti.ietf@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, Tarek Saad <tsaad.net@gmail.com>, "zhoutianran@huawei.com" <zhoutianran@huawei.com>
To: Robert Raszuk <rraszuk@gmail.com>
References: <CA+b+ER=87-UZSoR3ke6ikFiemna9TaNpDMgVGkNO3xMUm-t8zQ@mail.gmail.com> <BY3PR13MB47879D50B05FD35BC142BCB19AFA9@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+b+ERmn=DcWHGajN93au+SspTtMfzJx=oHu3oTANCPebc_zkQ@mail.gmail.com> <BY3PR13MB4787FE24458727D4CCA625E09AFA9@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+b+ERmCFt-hpPNRSYM1fvGoDDeOdh7z=TxRjeGu9oob6aOFuw@mail.gmail.com> <BY3PR05MB8081E320C21630DA6E972AE3C7FA9@BY3PR05MB8081.namprd05.prod.outlook.com> <CA+b+ERnY3CgFB4ZpFk+W=MUq=OPwSMHPJtYYLPLxVdi+AapPLw@mail.gmail.com> <7C7BE94C-CCB1-40B4-9B38-B0A8CA052458@tony.li> <CA+b+ERmO4sVXAdM7aG-GwJnSBAJRatzfx-73NyGgp2tRGA++OA@mail.gmail.com> <8C4F1AD7-EE46-44AA-B30D-F83119A4F1D1@tony.li> <CA+b+ERn26FrHRKnbn31O4jV7L5yxeJTX8gEHwcOQz+eJbYA4VQ@mail.gmail.com> <63FF335A-A850-411E-B09A-0EBD960B4C45@tony.li> <CA+b+ERmr4FE3kq8J9j_5tk1TGf986XF61Wpm8C-WR1yO+NZWGA@mail.gmail.com> <AB8879C8-6318-4C01-B30A-937860EEC1E0@tony.li> <CA+b+ERkiuPE8t08Z2fDUL0Ah=Knii-yz_M1JUUFhehiP+vDMRw@mail.gmail.com> <1B3C6837-3483-483D-B4F6-62A68B4A01CF@tony.li> <CA+b+ERmN96E+FYhWMzXscxPDCC5M=zBUDRd5C0hOKF9+nkTsvg@mail.gmail.com> <47F48072-AFF1-4A7E-9082-F6FF8B8116E8@tony.li> <CA+b+ERmEEMqrm0dY9FFzU0yaOnregkB-Deco42xOGd41OX2VDg@mail.gmail.com> <873A0E8D-DDD2-43D6-BC9F-F5A218E58769@tony.li> <CA+b+ERnBHp7ht5TExtxs+qLibnYYyy8AjxGSCzhiLmnBwhG+nw@mail.gmail.com> <2396206C-2DE7-475C-B492-AC33212B1606@tony.li> <CA+b+ERkMd31JQpCEvT_LfD6nbbh3uSxTUH-eHny2MGxe=DS3hg@mail.gmail.com> <D796E8A7-22A5-40F3-8F9D-69B659240C8D@tony.li> <CA+b+ERnD_wKfoSp+a7nYaJND0go_njxva-ttpAK8z9eocuKESw@mail.gmail.com> <5953795E-6EF6-458D-B3B6-E5C47AA90C87@tony.li> <CA+b+ERnv30a8xLGifDQnCMK8TfB3jEwzbZy6n23zShNvujw+bA@mail.gmail.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/PE-RVaNS4EucNl8ZzAAJryycV-E>
Subject: Re: [mpls] Reference Augmented Forwarding - MPLS RAF
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2022 14:27:37 -0000

Hi Robert,


> So since we are again on the "slice" topic can you tell me from edge and core routers points of view what is the real forwarding difference from the way one slice is handled vs another 2^10 (I saw such numbers on this list) slices ?


I am no expert on slicing and I cannot tell you all of the ways that GISS might be used.  I can speculate some for you:

- One might have a mapping from GISS to FlexAlgo topology.
- One might want to ensure that package for a given slice only leaves the underlay on an exit link for the same slice. 
  This would be an authentication check only on the exit router.
- Some combination of the above.
- One might just use GISS as ’security theatre’ and carry overhead in every packet without any check. All cost, no benefit.

One of these seem much more likely than the others.  If you’re suggesting that there will not be 2^10 different topologies, I would concur. That’s not sustainable.


> My point is that identifying slice hop by hop is not enough if you want to treat slices seriously. End to end TE should be applied of some form. It can be SR-MPLS, it can be flex-algo or it can be MT/MI.


Agreed.


> Just marking packets and recognizing that mark hop by hop does not make the forwarding unique (and if it does again let's understand what is the unique part). I saw somewhere that slice is just about separation - Well we have L3VPN (or even L2VPNs) which do separation in a pretty decent way. But P routers are not involved. 


Again, this is more of a conversation for TEAS.  Yes, some view a slice as simply an overlay. Some argue that it’s just a VPN. 


> Is the idea that we are yet one more time resurrecting the concept of Virtual Routers this time boldly going into 2^10 scale on each P node ? 


Virtual routers go hand in hand with VPNs and virtual topology.


> I agree that RAF and MNA as defined are complementary and that an alternate way of approaching this is to have RAF be a network action in and of itself.  It would be carried inside of the NAS and the RFV would then become ancillary data for the function.  The default operation for any RFV value would then be NOP and the management and/or control plane could install non-default actions as necessary.  I would propose that this network action be called ’select’. 
> 
> Thoughts?
> 
> Well when Tarek brought up the topic of user defined actions (considering action as action aggregate) for MNA it came apparent that the scheme only would differ from RAF in few elements: 
> 
> * distribution model of such actions:  domain wide vs per dst node;
> 
> * collisions handling with other actions in the same ISD/PSD
> 
> * ordering of actions (ordered list in ISD/PSD) as opposed to completely define it by control/mgmt plane
> 
> * location of RFV on the stack (ISD can be anywhere and there can be multiple of them, RAF can be only after top most label or instead of one)
> 
> * You said: "RFV would then become ancillary data for the function" - that means that we either cut the RFV size or use two LSE to signal it


No, I’m suggesting that you could expand RFV to 31 bits.


> Yes I get that the degenerated case of ISD with meaning of actions programmed by control/mgmt could pretend to be functionally similar to RAF. But I defined RAF to offer new network programming not to redo what today already is deployed. 


?  What I’m suggesting does nothing to diminish that.  It just makes for an efficient way to have both MNA and RAF in the same packet.  It allows us to carry both hop-specific actions and ubiquitous actions efficiently.


> To me honestly speaking MNA is way too complex, has too many moving parts for practically questionable use case(s). I am afraid that MNA instead of fueling MPLS to new altitudes can have exactly the opposite effect. 


That is not without merit.  


> So for now I would like to keep it as a separate document. The cost of doing so is by asking for a new bSPL type. And if that would be denied then perhaps I am cool using eSPL and burning one more LSE for it. After all, you are apparently planning on the same overhead if RFV would be used as ancillary data. 


I was not suggesting merging documents.  I was suggesting that your document become a network action specification.

Having it as a separate feature is a detriment to both, especially when both would occur in the same packet. Encoding them together would be lower overhead.

Tony