Re: [mpls] Reference Augmented Forwarding - MPLS RAF

Robert Raszuk <rraszuk@gmail.com> Thu, 28 April 2022 22:50 UTC

Return-Path: <rraszuk@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 617DAC15E6E1 for <mpls@ietfa.amsl.com>; Thu, 28 Apr 2022 15:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 7fd4yWfwbcKC for <mpls@ietfa.amsl.com>; Thu, 28 Apr 2022 15:50:04 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 E2A78C15E419 for <mpls@ietf.org>; Thu, 28 Apr 2022 15:50:04 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id e15so4593657qtp.3 for <mpls@ietf.org>; Thu, 28 Apr 2022 15:50:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BRyYyniEjt0uUgh3apeSeRqKmdwFamQ/woCzMFbNw6s=; b=f3FxZgtb1GQtKhqycTIRSI9MJr6/LoNnWph1w3t7F4U7uuDMjxFg67UWUVnpIRMlVp iqvMldZcxeBWUgbIpMWEeaY8UFn0qD41gZ9SCWZPmpq6FnwFdk3aLTwSf80n8a6SOE/A 3YnfTjznG1gj8GHdAoSswIaecEVGotflPPIcPcGPNvk9noExP6b/kiPpqU42N/N14/GE ctDhPE/dvDKh+Ua9bW9vECA7ycaNCInjFgBmU9E9zk2P8BPV+iM658uK28auJ41W3+Rs uiul2mqxnu0DB3TqH0M4dUx6lk2dTnLVHom4OzORsGI1Y0ESk9DaUAXM4VXKMwn98R/b SkBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BRyYyniEjt0uUgh3apeSeRqKmdwFamQ/woCzMFbNw6s=; b=7I9aIvM+zB6B7lXw6o9Z/msuvc01pFVu3HiplDKm7HmCznUhLMO7zZCED/7vC18pFJ w68xIPaJlcuUo9v/G4r0+16ZwjIoBqw2WPouiEMuN5EOE7TDm5AjF3mzLcWs9e6YzTBo RuwSwffvhyfXw4UGYrnRRk0yoE+cafIV/xxYu2252zIA78o5ACy4YK8MEcABb3k1vzPy QIXU4RfVr0xMlzyh6klnweDtjW8xZyEkcpsgqNpNRq3RX96o+kOBPEf6uSG5uEuK1yyQ Q9dla9gskZFqulzsJCZEsd0CjPNfkB51e28Z0uLWbVYyhU57DHGwAS6Ikx3rjfgthalf Ovlw==
X-Gm-Message-State: AOAM530L2jxjGIGOtxFpdkMhDk+c3mJOHrRHqkLdyxQ2jYl9J5UdU+31 j4zPSuB4uAh01HMeTDEJWDtEzFyxRqE7RXCt2X8=
X-Google-Smtp-Source: ABdhPJyJVHtZNGqf1a1Nzajr0Lv0oghzmQbIuTCbHlFdguVKfG0ccWFBsujNQYmexCd9dNJGhf5+s7kNQ6xObF9BpyU=
X-Received: by 2002:a05:622a:54d:b0:2f2:b558:b91b with SMTP id m13-20020a05622a054d00b002f2b558b91bmr24683287qtx.162.1651186203698; Thu, 28 Apr 2022 15:50:03 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <D796E8A7-22A5-40F3-8F9D-69B659240C8D@tony.li>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Fri, 29 Apr 2022 00:49:59 +0200
Message-ID: <CA+b+ERnD_wKfoSp+a7nYaJND0go_njxva-ttpAK8z9eocuKESw@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
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>
Content-Type: multipart/alternative; boundary="000000000000212b5105ddbebf26"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/kjxKga9ugwQxScU_CCk3-jKDfws>
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: Thu, 28 Apr 2022 22:50:05 -0000

Hi Tony,


> I was assuming that you were supporting all of the actions that MNA is
> planning on supporting.  My bad. What are you supporting?
>

My goal was to support selective (in few network nodes) processing on
packets, ideally all operator's defined -  more or less like in SFC
manner, but OAM postcard, trace with separate responses, .

I noticed that where MNA and RAF differ it was not only in the model of
data plane vs control plane action messaging. Fundamentally I was not
really focusing on supporting anything which needs to be executed on all
nodes.

Where support of ECMP or slices needs to be executed on all LSRs my
assumption was (and still is) that is it much better to use existing
encoding for it.

So I do admit I wrote this draft as an alternative to MNA. However now
after our discussion on the list (for good or for bad :) I think we have
different objectives and honestly MNA and RAF are (or can be) complimentary
and independent.

MNA could be used as an envelope to carry actions which are needed to be
executed on all LSRs. RAF can focus on action chains which need to be
executed selectively on few nodes (of a given type ex: ABR), differ from
area to area etc ...

Assuming that ECMP is one of our network actions, then we want some entropy
>> label (or similar value) to be considered when forwarding so that we
>> achieve multi-path traffic separation.
>>
>
> IMO network programming is not really aiming for such usecase(s).
>
>
>
> If our 5G brethren are correct, and carrying a GISS is important, then it
> seems painful to carry MNA and EL separately.
>

Yes I see this now. I also now realize why you reacted to encoding slice ID
into EL the way you did. By "you" I mean group of people - nothing about
personally yourself Tony.


But the same scaling question exists even if you’re just doing GISS.  Let’s
> assume that I need 8 slices in my network.  Do I need 8 RSVs?
>

Sorry I do not know what is GISS ... geographic information systems  ? But
yes if you really want to classify packets into a slice at hop you need to
carry it explicitly (in ISD via RFV pointer or embed it somewhere in the
stack).

But for slices I would rather take a network wide view, focus on slice to
slice forwarding difference and build end to end slice plane - not a hop by
hop classification based mapping. But this is just me.

Kind regards,
R.














>
> Tony
>
>
>
>