IETF Logo Mail Archive

Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 24 March 2021 19:51 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD18D3A3461; Wed, 24 Mar 2021 12:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hObxxwtMCCFT; Wed, 24 Mar 2021 12:51:07 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF5D3A3460; Wed, 24 Mar 2021 12:51:07 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id gb6so78587pjb.0; Wed, 24 Mar 2021 12:51:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kxLYNTOPESIAJn2h5jHFRIQvuvq/Mx76fbpVPgTMM28=; b=Se+PCHzek1C4MSzJrnXLT/LZeeHNeUP5qBsAnb2f4Idr2IV4sz0Mfpwfa3K4b/vDeR 60j2sesnob9bVkW1qCtEJQFhgX/RuNOsJvBIcuDC0XniT0EPg6WUuWBqR0R9+nGZUikK vKinQlC8pBt1zbdpwwudvuZhEHDFu6ll+hIhFbbqewjaozarZavaYXBxR+lJ3crCodzR aNLuabdEX0d8+qSgRQyLsOG+DCtGDqbM7urveQekQStWWyfVw4SXLSrlAyxURzoFiYw2 k5bcvqAdJALg115jzpEoh2ShrZ5NChgTiUw/2sjAFLh+h4BhpNIAefWh4wsg5+n6/qmh RmYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kxLYNTOPESIAJn2h5jHFRIQvuvq/Mx76fbpVPgTMM28=; b=KInFsCAMDkWHdPm1o/0PzXm9ImVMOSP2/0ur4NEsAivmm1j5OZuRRfdOObkfTLzR3O GTUx61f+aYDTFh/9no0nlmUQl7ql8zsN4N5jKjDTzNTIJ0kiT/MSh3526NEsOGRF0cn/ 2pXbDlmDLKlsaz0jj5vPjaDsZTP5IxH7wLrXI9XE+Gcmc05aaA5GCLM0C8jHU/UCzA/p Taridi4qZ5hxnit7VSgLevGoRqbmqJVxanolZHHYHDbTN6Y7Q92gBb0TobYO7Bc/fMFH UQaQMxJ2tUhPC9ee7wswzBm6SIaQyLhSYD1MzvpoeAmN2MczvCxHHkfCOZ+GPcznIwLj ZY/Q==
X-Gm-Message-State: AOAM530y8jIq5Qsy9BM7imamBjTwPc1q0ToRPyhh5eKovFMsxYA5jFYJ VWqeiTD40ybFNaB41W7IJgwwwxM/NBWNlg==
X-Google-Smtp-Source: ABdhPJxDTediI6QFtYyQ2gzdZyBl/zneEnk1uer1THRiA/zlPlE8bkBDE8CuZVdVEfRQvJyiL9SF1w==
X-Received: by 2002:a17:90a:458b:: with SMTP id v11mr4920865pjg.189.1616615466638; Wed, 24 Mar 2021 12:51:06 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.131.14]) by smtp.gmail.com with ESMTPSA id b186sm3486182pfb.170.2021.03.24.12.51.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Mar 2021 12:51:05 -0700 (PDT)
To: Joseph Touch <touch@strayalpha.com>
Cc: Mark Smith <markzzzsmith@gmail.com>, Vasilenko Eduard <vasilenko.eduard@huawei.com>, v6ops list <v6ops@ietf.org>, int-area <int-area@ietf.org>
References: <0b61deabe8f3420eba1b5794b024e914@huawei.com> <A063E98C-0D6C-49B2-B871-E2B39A097FD5@strayalpha.com> <37059faadd6e441cb98f6ec7e01ecef9@huawei.com> <9D23C833-46C5-4B93-A204-D2D4F54689DF@strayalpha.com> <1e6ecd3b468d4255bda65d519190135d@huawei.com> <3B48413C-A47D-4F3F-B9E4-7ED4D33AA66B@strayalpha.com> <22bb7bf129694ccfbbad441d8d22e05c@huawei.com> <A5F62B47-DBA3-457D-89CD-D570EA2EA886@strayalpha.com> <eb63d427f4d34e44908ccee2c2d14073@huawei.com> <F158C443-6E73-4FC6-ADCA-6D28EE8F0A30@strayalpha.com> <d1c8a80b387847a3b00566e3dc0768ab@huawei.com> <D87C00F7-2902-48C4-9DCA-E1019EF32CAA@strayalpha.com> <46be60a38c0f4bc08f352dc8ed353c6a@huawei.com> <4E4C25CB-561C-4BF1-B99B-14E26D00009B@strayalpha.com> <4415086a1b734313b383307a27eb3fb2@huawei.com> <CAO42Z2zbOv2Ut3otn8H-DiQSo33vujC4uCsVDNmHK_TxP4R49w@mail.gmail.com> <cd4088e5-055f-9b51-3b34-82518021e9c5@gmail.com> <5FECDB95-5334-4AA6-B8F5-39948F3592C3@strayalpha.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <8348bf69-5fb8-7bcc-cec7-1a08cc762814@gmail.com>
Date: Thu, 25 Mar 2021 08:51:01 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5FECDB95-5334-4AA6-B8F5-39948F3592C3@strayalpha.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/DlSAO3cRphZAqqxcEaG8RIPwXCA>
Subject: Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Mar 2021 19:51:12 -0000

On 25-Mar-21 03:41, Joseph Touch wrote:
>> On Wed, 24 Mar 2021, 07:53 Vasilenko Eduard, <vasilenko.eduard@huawei.com <mailto:vasilenko.eduard@huawei.com> <mailto:vasilenko.eduard@huawei.com>> wrote:
> ...
>> On Mar 23, 2021, at 8:47 PM, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>>
>>> Tunnel packets *are* explicitly addressed to a node, so tunnel endpoints are performing host functions on packets. If those host functions being performed on tunnel packets at the tunnel endpoints require buffers, then buffers need to be available.
>>
>> Yes, and tunnel entry points are hosts when they send an encapsulated packet.
> 
> Viewed from inside a tunnel, the tunnel endpoints are both hosts.
> 
>> There's a subtlety though, which is that the device that contains the tunnel entry point on the downstream side of the packet flow is indeed a router on the upstream side. Conversely,
>> the device that contains the tunnel exit point is a host on the upstream side and a router on the downstream side.
> 
> I disagree; a tunnel is a link. That link can easily be host-host.

Agreed. In that case, the prefixes reachable by the tunnel will show up in the host's route table, and the tunnel offers whatever MTU it can. In the general case the devices containing the TEPs will be routers and they will usually participate in a routing protocol for the prefixes reachable via the tunnel. 

> A host that is router-capable (many OSes have a flag to ‘forward IP’ or not) can have forwarding disabled (host-only mode) and use tunnels just fine.
> 
>> Which is why the MTU for packets inside the tunnel is no business of anyone upstream or downstream of the tunnel.
> 
> Agreed…
> 
> Though I would appreciate your thoughts on how to handle the errors in RFC2473 as noted in draft-tunnels.

As they say in the British Parliament, I require notice of that question. I need to re-read the draft.

   Brian
> 
> Joe
> 
>>
>>   Brian
>

v2.23.0 | Report a Bug | By Email