Re: [Pals] draft-zzhang-intarea-generic-delivery-functions

Stewart Bryant <> Tue, 23 February 2021 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4727E3A0890; Tue, 23 Feb 2021 07:34:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BQczeIeA2C7K; Tue, 23 Feb 2021 07:34:23 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD5473A2C74; Tue, 23 Feb 2021 07:33:51 -0800 (PST)
Received: by with SMTP id o82so2833559wme.1; Tue, 23 Feb 2021 07:33:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VJMUMSOKsUH6mERwJOTYR/BOemsJ9TjKG4tiIzgOzeE=; b=Gv+J/gJK/w2+fuUFSdSHoK7Jd3Cw/da6qaUtkeVSCCM+tgg00Q5ItzKWERs2IzeKGt mFZdpuPq7cQusdVBSYazlVxrq5CP1uFnL6JiGuZIwcXj4n0GlNOgUbDFMJBH/0NeyrEj j/FePNynEBBQnDFBFBH3J1gfvHZPRtWg72cV5Xij5wddfU7ELOhFEEllwMuHSB2I24af kqY4RMa5m6kAvCJ8jfWv+6gTVRrtemLFnEnKvq1iYIGDnizO40zqVQv8KC02vO6vUCtl U+g8NlQ8kZSTsWziuAIYDpVL+Jzpea+/2VQIo+pb+mUP9yq6+M/QdAqOEIVConFvlCHu L6sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VJMUMSOKsUH6mERwJOTYR/BOemsJ9TjKG4tiIzgOzeE=; b=rheX3vYd1mLIbdB2+EdgHAASX3cdTijVhmKPV8nG0YBcbBpw4H5XB53ElNU9PeysEH SzLi4Ybe6Gb/oaa2VJT2wFG/j0Nv4UPeQL3DyYdoE9Mh8CZl+hW3Z11sxB4ggRw+UjE+ dAACC7hV7VU5GqqezUW6R+k46PsfKkkuOqbVsM2SMzkMwgkv406ql76JA1Txd1QSZs2L 4+8XcvajhTIip+vqCxfdHv9BoehVfWY7VOHr2mOvTgLJ08k5tlWonpMPansS3gfaHn64 Snt1EMOie31vHzdd18vBvTTGxzYK4IrpG8BTWzURoYJeloIlhmgGbCbvvRRjY0UsDJCW uI8A==
X-Gm-Message-State: AOAM530KtDu/dX/2XtOMtzRIQjYXEWBhgym1GRmLS9/Fg2LiemrQk8mT yvabUDqdJYPkDFU4AxOEpj8=
X-Google-Smtp-Source: ABdhPJw9vuVC3UE9kBbrOeIIJSBJmNJvD9iPcrS3ppMYGlnP1q0OoNUscnWj6hv1J7SwK7u6qnrQIQ==
X-Received: by 2002:a05:600c:203:: with SMTP id 3mr26191780wmi.187.1614094429589; Tue, 23 Feb 2021 07:33:49 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id y6sm3058159wma.10.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 07:33:49 -0800 (PST)
From: Stewart Bryant <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_830B8B63-6087-4E2F-975D-F100EBE1E8E1"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 23 Feb 2021 15:33:47 +0000
In-Reply-To: <>
Cc: Stewart Bryant <>, Rakesh Gandhi <>, "" <>, mpls <>, "" <>, Kireeti Kompella <>, Ronald Bonica <>, "<>" <>
To: "Jeffrey (Zhaohui) Zhang" <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Pals] draft-zzhang-intarea-generic-delivery-functions
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Feb 2021 15:34:24 -0000

> On 23 Feb 2021, at 15:18, Jeffrey (Zhaohui) Zhang <> wrote:
> I am not sure if that is a good idea:
> RFC 5586 says “The G-ACh MUST NOT be used to transport user traffic”. To me IOAM traffic is user traffic with OAM information.

Correct on both counts. Though we could change the 5586 restriction. It would only be a problem for receiving LSRs that needed to do this and not on path LSRs, and if you need to do this function you need to change the forwarder anyway.

> It puts one G-Ach header after another G-Ach header. As far as I understand it, G-Ach does not have a “next header” concept and using 0001b to indicate that another G-Ach header follows is not safe.

The PW label says that what follows is a CW

The CW may preceded PW payload, or precede stuff defined by the ACH type.

An ACH (A1)  followed by an ACH (A2) is only defined if the A1 tells the forwarder to expect another ACH. We could change that definition, but I am concerned we rapidly enter extension header hell which may be OK if it is where we want to go.

> In case PW payload, the above will put the PW label before the IOAM label. Having those extra IOAM/G-Ach headers between the PW+IOAM label and PW payload adds complexity to the fast path processing.

Yes and you forgot any entropy labels that may be hanging about in the stack.

- Stewart

> Jeffrey