Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com> Wed, 22 January 2020 07:11 UTC

Return-Path: <pcamaril@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40957120048 for <spring@ietfa.amsl.com>; Tue, 21 Jan 2020 23:11:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YjIDxH8e; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IizBQxVA
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 LesYIbdHwqNp for <spring@ietfa.amsl.com>; Tue, 21 Jan 2020 23:11:54 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5009120013 for <spring@ietf.org>; Tue, 21 Jan 2020 23:11:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=119317; q=dns/txt; s=iport; t=1579677113; x=1580886713; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eAqL6UKirJq/p9ITZxFYhs3PYR2EVDGsfihJtC7KOnk=; b=YjIDxH8eacwlpOYGr5B85EghH62KT6CQDbYF0m9iOTak/jg3twkElsF6 foOYt4gYoenmqVhUO5KUegVmMHIYh4hdo0nnio4dobmw4aFSaMQRXb2B6 1qzFGPcvjrFvaY1atHOAOuBoav5fWLlsy1y8fKUx3iaxtjcN21SyGvg0L 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3Axo2aTR80Izk+Tv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaOAEjyNv/uRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAADX9Cde/5hdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkFAQELAYEkL1AFbFggBAsqCoQIg0YDiwOCX4lgji6BLhSBEAN?= =?us-ascii?q?QBAkBAQEMAQEYAQoKAgEBg3tFAheBfSQ2Bw4CAw0BAQQBAQECAQUEbYU3DIV?= =?us-ascii?q?eAQEBAQMBARAICR0BASwLAQ8CAQgOAwMBAQEhAQYDAgICHwYLFAkIAgQOBSK?= =?us-ascii?q?DBAGBfU0DLgEDC6I/AoE5iGF1gTKCfwEBBYULDQuCDAMGgTgBjBMagUE/gRE?= =?us-ascii?q?nIIIeLj6CG0kBAQKBLgESATYJDQmCWjKCLI1OgweFXIlzjm5ECoI5kgqEKRu?= =?us-ascii?q?CR4gKgQOLR4NchESKFosIkAQCBAIEBQIOAQEFgVkLJ2dxcBU7KgGCQVAYDYg?= =?us-ascii?q?BDBeDUIUUhT90AoEniiqBIgGBDwEB?=
X-IronPort-AV: E=Sophos;i="5.70,348,1574121600"; d="scan'208,217";a="410641841"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 07:11:52 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 00M7BqbS027252 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Jan 2020 07:11:52 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 01:11:51 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 01:11:51 -0600
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 22 Jan 2020 01:11:51 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qyu7zFAxOn1Dv7IPfpdfpvyn/7AvwV/jNFNPKVjWxaE3Rn+Ic+n6E4+8SLzOdUxgcjtFs1WPRfYZNfo8l1AHqoxQouYA7pLqQwrITcP1HJiHZW1YnQumSAB0Ye7VDC2jfPY3kg3+571OSr8D70ZKnqdmuLm73dka3F1luCfiXtNTrpIet/IF9RfVm6LniiVKzCsf2NVAXmALHSuQOpOKWZWPSWNiVEUZ1fAQA+1NrNDxrZLNwzW37Ql+C4MEOpuKsHya+8ArjQSmTA8ec0JqEGFoOhdU0W3HIemoPs9tq3q5u20vLWHVd67Pn6rvShIXZGpc4+qbNQzcx5gdcangEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eAqL6UKirJq/p9ITZxFYhs3PYR2EVDGsfihJtC7KOnk=; b=hm51g3metYK/MdHEniqdCDSv9os9PBVrm8Up6KlCfF+nbwUi0sTJpnodOiDoCktX+BpUCVQQXe+UGvBfUqNCwGzZ0/jwyKWJQyLS6I4EiyMRuKgnRfM7dTZhQp1G3f8ffHZoxlpxp2q2A7yUUNYytVoAW9cSEJhENaVYisvO1L5f4J935m4gd1ARNCOXyrFXfeyr42RT17brEVwGcfb0I6NywD4a4f6lPHhASYtsJl53N1IdGZK1+vv6ZwnMc5uxSilubuL58yrJp8xAyPKUULRwctc4pSKOkRxXyKiPVidJU8L5fs+D2yB/lI0UbRJ/gu/3+6NaDLG3tCT8ttdXEw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eAqL6UKirJq/p9ITZxFYhs3PYR2EVDGsfihJtC7KOnk=; b=IizBQxVAOdVTsh+Y2WyPYR2mVDWrpEUoS4PV5PiMhP4hJnCrG+d2lxREpSlw5FWD1lhcQtME5ZMx48/S8BdC/Hl0/tAQFaHbSxmPMnQ0eqxuoc9TqEtVTQXuXQXgoi/PmtV/Wgsvn3UUUQbK+hS/eDJO5Rn8Ankcm9xEf1/oc6k=
Received: from MWHPR11MB1374.namprd11.prod.outlook.com (10.169.234.8) by MWHPR11MB0013.namprd11.prod.outlook.com (10.164.204.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.25; Wed, 22 Jan 2020 07:11:48 +0000
Received: from MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::e481:a191:e31:f948]) by MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::e481:a191:e31:f948%12]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 07:11:48 +0000
From: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
To: Erik Kline <ek.ietf@gmail.com>
CC: Ron Bonica <rbonica@juniper.net>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] SRv6 Network Programming - ICMP Source Address Selection
Thread-Index: AQHVt1sjI5E9vezZDUu0pc5hCyLTq6fFADeQgBI8Q4CACFa2YIAEu/GAgAASX9CABK7rAIAAEWrAgAGEk4CAAAwPkIADH7IAgAApnoCAAMvugA==
Date: Wed, 22 Jan 2020 06:54:43 +0000
Message-ID: <831F9856-A339-44D3-9FFF-E18137FF64D6@cisco.com>
References: <B91AA98B-F605-4C6B-AFAF-C9FDEA703460@cisco.com> <BN7PR05MB5699B27F84C5E8051028D97AAE2C0@BN7PR05MB5699.namprd05.prod.outlook.com> <44F0ED35-5684-4594-BB29-BDCC193284A4@cisco.com> <BN7PR05MB39386FA6A2666370FF07FAA7AE3F0@BN7PR05MB3938.namprd05.prod.outlook.com> <CEB721B4-DA87-4838-BA6D-499D38A33936@cisco.com> <BN7PR05MB3938FEE1C2F83C919D4CFA2AAE380@BN7PR05MB3938.namprd05.prod.outlook.com> <DF0DC4A0-37D7-4943-BFC2-D152BB9E8D38@cisco.com> <BN7PR05MB39381FB65ED5B034D21267F0AE350@BN7PR05MB3938.namprd05.prod.outlook.com> <94AA5F04-2458-42B0-AA7E-7039EA795C1C@cisco.com> <BN7PR05MB3938CE48494065688C53BB86AE340@BN7PR05MB3938.namprd05.prod.outlook.com> <EAA17BE9-8EE2-43E0-B7AC-62CFCD768305@cisco.com> <CAMGpriW2Ln17x6T2z7XN3e1hHotjfJrxCN14myMJq4LtC8MTDg@mail.gmail.com>
In-Reply-To: <CAMGpriW2Ln17x6T2z7XN3e1hHotjfJrxCN14myMJq4LtC8MTDg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pcamaril@cisco.com;
x-originating-ip: [88.14.184.59]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 63c373c3-34c9-4386-64d9-08d79f0a58a1
x-ms-traffictypediagnostic: MWHPR11MB0013:
x-microsoft-antispam-prvs: <MWHPR11MB00133BFDC231177083195AEFC90C0@MWHPR11MB0013.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 029097202E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(136003)(39860400002)(396003)(199004)(189003)(6666004)(33656002)(316002)(54906003)(71200400001)(8676002)(4326008)(66574012)(81166006)(66946007)(91956017)(76116006)(8936002)(66556008)(5660300002)(66446008)(64756008)(30864003)(66476007)(81156014)(86362001)(478600001)(966005)(6916009)(6512007)(26005)(6506007)(53546011)(186003)(2906002)(36756003)(2616005)(6486002)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB0013; H:MWHPR11MB1374.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: u8RzjQD9pALrF+NyYaOHhkQppp62fkVNrL9IqY+RUg8yr5/gwVhgM+nWFq7U+FRkg2nplhiQ2hDWTLa5hFkxTWUTaNi5IkGbbDu1EhSBVRdI6r8hV8myVeYdvWX0IdnJBv93WcFaP1XrfSXAjCdnB8h8YsNdfznXYhstl9vW5sotP2YcY9kio5bEUoU3y6tpwXFwEzqOYf1IZ/c5lUi+r/1ZbN+McgadicSZT4s6sZmE7Xa9co5NcgysUuuFldFpnOfIsNwxbpSkjoEkD6YDirmeypEmeLVMJ7gOLfCa/XSooT1N25umUktFmuuqR3mXbAX3LmfSd21cD54isy2E+A3bk75nXmZ00XGxaePVOcFYrnVE8I97Xg6TbaADWJlLbKFaVlU3KoJl4UvzoZOj5kfdSQM/60fYI2mv9abRVII9XFH34IdNKxgocMNca9RSWfrSC9tIKV+Q6PCvIcy9uMgmXExCZXuFP35ucWwkAnnarNTrXVps1nApyvSPKFhKn9nO9ict0Jo1alRn1NQZIg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_831F9856A33944D39FFFE18137FF64D6ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 63c373c3-34c9-4386-64d9-08d79f0a58a1
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 07:11:48.1366 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IhH6DyjWtt2BbiuiuGR0IidOFdnjwJUi7L+bKlmJErdH9yd+zr8rBFYQIhhOfq7kisRka6ZHEqjpUcFbRQFxGA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB0013
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/XSovmJI_iJbaNDk49HHH2lSBK2w>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 07:11:57 -0000

Hi Erik,

That behavior is good, but I believe this can be formalized as:

An SRv6 SID is an IPv6 address associated with the segment.
When a router needs to generate an ICMP Problem Message, it MUST follow RFC4443 section 2.2 with respect to how to select the source address.

The logic with respect to how to choose is defined in RFC4443. This logic is followed by the SRH. Draft-ietf-spring-srv6-network-programming does not define anything new in this regard. It just follows the standard.

Thanks,
Pablo.

From: Erik Kline <ek.ietf@gmail.com>;
Date: Thursday, 16 January 2020 at 22:39
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>;
Cc: Ron Bonica <rbonica@juniper.net>;, "spring@ietf.org"; <spring@ietf.org>;
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Seems like you're saying that if the SID is not an anycast SID it is as though it were unicast and therefore 4443/2.2/a applies, i.e. the SID is the source address for the ICMP error message.

If the SID is an anycast SID, then the router must follow 4443/2.2/b and chose another unicast address associated with the node as the ICMP source address.

Is that correct, and complete?

On Thu, Jan 16, 2020 at 10:25 AM Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>> wrote:
Ron,

No, you cannot say that. As I just mentioned in my previous email: anycast SIDs.

In your implementation you need to strictly follow RFC4443 section 2.2 for selecting the ICMP Message source address. This implies that you need to develop both options introduced in RFC4443 together with the logic to be able to choose in between A and B.

Cheers,
Pablo.

From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>
Date: Tuesday, 14 January 2020 at 20:28
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Pablo,

Can we unequivocally say that all of the SIDs mentioned in the PGM document are unicast addresses?

                                                                               Ron




Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Sent: Tuesday, January 14, 2020 12:44 PM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Ron,

As a matter of fact we cannot “unequivocally state that a SID is a unicast address” always. Simple reason: RFC8402 - “3.3.  IGP-Anycast Segment (Anycast-SID)”.

Cheers,
Pablo.

From: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Date: Monday, 13 January 2020 at 20:41
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection

Pablo,

The problem isn’t a statement in the network programming draft. It is an omission in the network programming draft.

If the network programming draft unequivocally stated that a SID is a unicast address of the instantiating node, the following text from RFC 4443 would apply:


“If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be  that same address.”


If the network programming draft unequivocally stated that a SID is a not unicast address of the instantiating node, the following text from RFC 4443 would apply:


If the message is a response to a message sent to any other address, the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node.

                                                                                                            Ron



Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Sent: Monday, January 13, 2020 12:31 PM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Ron,

You cannot pre-select or enforce one of the two options you refer to below.

The ICMP behaviors/considerations for SRv6 NET-PGM are the same as in the SRH.
It boils down to: when you generate an ICMP Parameter Problem Message you follow the logic described in RFC4443 section 2.2 to choose the source address of the packet.
RFC4443 offers two options A and B.
In your implementation you need to develop both options and depending on the type of address you will choose either A or B. It is not possible to create an implementation shortcut and pre-select/enforce only one of them.

Can you please point me to the text in draft-ietf-spring-srv6-network-programming that suggests that the ICMP considerations are changed with respect to the SRH? I believe there is none.

Thank you,
Pablo.

From: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Date: Friday, 10 January 2020 at 20:09
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection

Pablo,

So, in Section 4.1, Line S03, an SRv6 node sends an ICMP Parameter Problem Message. What is the source address in that message?

Is it the destination address of the offending packet (i.e., A SID)? Or is in the address of an interface on the SRv6 node?

                                                                                         Ron




Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Sent: Friday, January 10, 2020 11:54 AM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Ron,

There is no behavior in draft-ietf-spring-srv6-network-programming that proposes to encode a SID in the source address of the IPv6 header.

If in the future someone would propose to do such thing in another I-D; it is up to those authors to justify why they would want to do this, and how to ensure that the processing does not break any other protocol. But as said, this is not in the scope of draft-ietf-spring-srv6-network-programming.

Regarding the ICMP messages:
SRH follows RFC4443 Section 2.2 with respect to how to select the ICMP Source Address.
SRv6 Network Programming does not change this (it simply follows the SRv6 rules defined by the SRH).

In your email you refer to a possibility of future protocols breaking this. I don’t think that we can guess what future protocols will do, and it is up to those future protocols to ensure compatibility with the existing standards.

Thanks,
Pablo.

From: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Date: Tuesday, 7 January 2020 at 19:07
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection

Pablo,

Let me try to ask the question another way:


1)      Is it generally acceptable for a SID to appear in the source address field of an IPv6 header?

2)      Can an exception be made for ICMP messages?

I think that the answer to the first question is “no”, because doing so would break ICMP. Think about what would happen if:


-          Node S sends a packet to Node D with a SID S as its source address.

-          Node Q is an intermediate node on the path from Node S to Node D. For some reason, Node Q cannot forward the packet.

-          Node Q sends an ICMP message to Node S. The ICMP destination address is SID S.

-          The ICMP message arrives at Node A

-          Node A discards the ICMP message, because the payload is ICMP

It might be OK to make an exception for ICMP messages. This is because RFC 4443 forbids sending an ICMP message in response to another ICMP message. However, I am not entirely sure that this is a good idea. One day in the future, some protocol other than ICMP may try send a response to the source address of the ICMP message.

                                                                                     Ron




Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Sent: Tuesday, January 7, 2020 4:18 AM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Ron,

It’s good to see agreement on the fact that SRH follows RFC4443 Section 2.2 with respect to how the ICMP Source Address is selected.

Can you please point me to the text in draft-ietf-spring-srv6-network-programming that changes the behavior below from RFC4443 Section 2.2? I believe there is no such text.

Thanks,
Pablo.

From: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Date: Saturday, 21 December 2019 at 20:59
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection

Pablo,

Section 2.2 of RFC 4443 offers the following options:

“   (a) If the message is a response to a message sent to one of the
       node's unicast addresses, the Source Address of the reply MUST be
       that same address.

   (b) If the message is a response to a message sent to any other
       address, such as

       - a multicast group address,
       - an anycast address implemented by the node, or
       - a unicast address that does not belong to the node

      the Source Address of the ICMPv6 packet MUST be a unicast address
      belonging to the node. “

So, the question boils down to whether you consider a SID to be one of the node’s unicast addresses. If so, the answer is a). If not, the answer is b).

So, which is it?

                                                    Happy Holidays,
                                                         Ron





Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Sent: Friday, December 20, 2019 12:30 PM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Ron,

I guess that draft-ietf-6man-segment-routing-header does not contain any explicit text about it because it is not needed.
Instead draft-ietf-6man-segment-routing-header contains a reference to RFC4443 that details in section 2.2 how to select it.

There is no text in draft-ietf-spring-srv6-network-programming that changes such behavior.

Happy Holidays,
Pablo.

From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>
Date: Thursday, 19 December 2019 at 14:59
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Pablo,

Can you provide a specific reference into draft-ietf-6man-segment-routing-header? I can’t find the answer to my question in there.

                                                                                         Ron





Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Sent: Thursday, December 19, 2019 6:47 AM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: SRv6 Network Programming - ICMP Source Address Selection

Ron,

This is exactly the same as in the SRH.
There is no text in draft-ietf-spring-srv6-network-programming that changes this.

Cheers,
Pablo.

From: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Date: Monday, 9 December 2019 at 23:48
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>, SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>, 6man <6man@ietf.org<mailto:6man@ietf.org>>
Subject: RE: SRv6 Network Programming - ICMP Source Address Selection

Pablo,

Section 2.2 of RFC 4443 offers two options. If you think that a SID is a unicast address, the first option is applicable. If you think that a SID is not a unicast address, the second option is applicable.

Which did you choose?

                                                                         Ron



Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <pcamaril@cisco.com<mailto:pcamaril@cisco.com>>
Sent: Monday, December 9, 2019 10:18 AM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; 6man <6man@ietf.org<mailto:6man@ietf.org>>
Subject: Re: SRv6 Network Programming - ICMP Source Address Selection

Ron,

As you pointed out in your email, RFC4443 Section 2.2 is very clear about how to select the source address.
draft-ietf-spring-srv6-network-programming does not change this.

Thanks,
Pablo.

From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>
Date: Friday, 6 December 2019 at 17:40
To: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>, 6man <6man@ietf.org<mailto:6man@ietf.org>>
Subject: SRv6 Network Programming - ICMP Source Address Selection

Authors,

When an SRv6 node sends an ICMP message, how does it select the ICMP message’s source address?

Section 2.2 of RFC 4443 offers two options. If you think that a SID is a unicast address, the first option is applicable. If you think that a SID is not a unicast address, the second option is applicable.

                                                                     Ron


Juniper Business Use Only

Please excuse any typos, sent from my 'smart'phone.

Please excuse any typos, sent from my 'smart'phone.

Please excuse any typos, sent from my 'smart'phone.

Please excuse any typos, sent from my 'smart'phone.
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring