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

Erik Kline <ek.ietf@gmail.com> Thu, 16 January 2020 21:38 UTC

Return-Path: <ek.ietf@gmail.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 12C5D1200DB for <spring@ietfa.amsl.com>; Thu, 16 Jan 2020 13:38:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 of_M7wdGm90u for <spring@ietfa.amsl.com>; Thu, 16 Jan 2020 13:38:23 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 8E5A612013A for <spring@ietf.org>; Thu, 16 Jan 2020 13:38:22 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id v28so20275129edw.12 for <spring@ietf.org>; Thu, 16 Jan 2020 13:38:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fb3hUgat5ia/3bvq6marlKuMei1xfyl/jOIJNMSSQVE=; b=bzXx/1cNhMeixd7Sn7cNR5r7vrvz1PYvZmj2mlJzRUHsdXxrV6XZ/IdaqeejqcmKdi qii1Q6K8J7ICynwLisRnXwF1k3RhD0oexMKk2GZ7PTQlnJKk5C3a6VLx9Mswso6Xv+aY /0ZTOOxUZAy4D2BPzAk4x5tFMjREJxLlUhhlLMg6OEa5eDXxMKJ4a4I5tyyJyZT1L554 HWoY3dyYlTG7LIkwmMlboFlGusTYu3gXTSZqARGF1Gv3zLaljdb+K2EvWAgtjZ6RHna0 nwGQQLYGVOuWbWE9BtjzC2dOWe3c9zYqRJ2w0oVVtX6sXXDjNppV2RHSOInMybntYWBA rPrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fb3hUgat5ia/3bvq6marlKuMei1xfyl/jOIJNMSSQVE=; b=SZ4LwHz1sfb2fNh65SBU8hzMkxVr4bOs626f0JVUQJwxWqJ3YtcbYqIhk0MP5TS4xP VxjTVCdsHEDCNjFfYczol5he6GF9eNA+7itcqssjQ5I9u1BPbyZ97UyDsff+XnwWTc2x SI06xpWZMJbHoTbs2zQuioyiNVxmjVKyfEzmU0Tey0yu4CC/MPBpnosLjXmcce/Ov9pf vHZxZi8ghQspHNJ7PQ9FxJ1I55eGhWar8gfuHQyjt1NOeDnSOaUVvXyt7TrzM973V1+W +74rWstx55GzflGh93u7XD7fpvGFq9aKtDtqM7XYSrOaG7+RA3kFPnAdY9sDiQpheSlu lHwQ==
X-Gm-Message-State: APjAAAVk9+w0zWizxNjDzuwp9TsrL3OVDTzBTADeNZ3XQ2W5JqpVUwnt WOtBU/68LJ9zNzeY0IFjn/ZbqLFJSOALSnROtPeNyg==
X-Google-Smtp-Source: APXvYqycpd6Fo7HsDmoiuf4RKjd4SAf9bJWfJWdQre06UW1Ycx9CzLj152TP7q5u6aKOk3Dg/bT+r1HPUaALpNphEYs=
X-Received: by 2002:a50:fb0b:: with SMTP id d11mr496922edq.252.1579210700734; Thu, 16 Jan 2020 13:38:20 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <EAA17BE9-8EE2-43E0-B7AC-62CFCD768305@cisco.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Thu, 16 Jan 2020 13:38:09 -0800
Message-ID: <CAMGpriW2Ln17x6T2z7XN3e1hHotjfJrxCN14myMJq4LtC8MTDg@mail.gmail.com>
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
Cc: Ron Bonica <rbonica@juniper.net>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d7c578059c48a4ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/xJsKNS9oTZqzmfQxq_lcgk9iebs>
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: Thu, 16 Jan 2020 21:38:31 -0000

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> 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> on behalf of Ron Bonica <rbonica=
> 40juniper.net@dmarc.ietf.org>
> *Date: *Tuesday, 14 January 2020 at 20:28
> *To: *"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
> *Cc: *"spring@ietf.org" <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>
> *Sent:* Tuesday, January 14, 2020 12:44 PM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* 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>
> *Date: *Monday, 13 January 2020 at 20:41
> *To: *"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
> *Cc: *"spring@ietf.org" <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>
> *Sent:* Monday, January 13, 2020 12:31 PM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* 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>
> *Date: *Friday, 10 January 2020 at 20:09
> *To: *"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
> *Cc: *"spring@ietf.org" <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>
> *Sent:* Friday, January 10, 2020 11:54 AM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* 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>
> *Date: *Tuesday, 7 January 2020 at 19:07
> *To: *"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
> *Cc: *SPRING WG <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>
> *Sent:* Tuesday, January 7, 2020 4:18 AM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* SPRING WG <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>
> *Date: *Saturday, 21 December 2019 at 20:59
> *To: *"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
> *Cc: *"spring@ietf.org" <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>
> *Sent:* Friday, December 20, 2019 12:30 PM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* 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> on behalf of Ron Bonica <
> rbonica=40juniper.net@dmarc.ietf.org>
> *Date: *Thursday, 19 December 2019 at 14:59
> *To: *"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>om>, "spring@ietf.org"
> <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>
> *Sent:* Thursday, December 19, 2019 6:47 AM
> *To:* Ron Bonica <rbonica@juniper.net>et>; 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>
> *Date: *Monday, 9 December 2019 at 23:48
> *To: *"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>om>, SPRING WG <
> spring@ietf.org>gt;, 6man <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>
> *Sent:* Monday, December 9, 2019 10:18 AM
> *To:* Ron Bonica <rbonica@juniper.net>et>; SPRING WG <spring@ietf.org>rg>; 6man
> <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> on behalf of Ron Bonica <
> rbonica=40juniper.net@dmarc.ietf.org>
> *Date: *Friday, 6 December 2019 at 17:40
> *To: *SPRING WG <spring@ietf.org>rg>, 6man <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
> https://www.ietf.org/mailman/listinfo/spring
>