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

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 7 Jan 2020 09:17:33 +0000

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 <[email-masked]>
Date: Saturday, 21 December 2019 at 20:59
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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) <[email-masked]>
Sent: Friday, December 20, 2019 12:30 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Date: Thursday, 19 December 2019 at 14:59
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 19, 2019 6:47 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>
Date: Monday, 9 December 2019 at 23:48
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, SPRING WG <[email-masked]<mailto:[email-masked]>>, 6man <[email-masked]<mailto:[email-masked]>>
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) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, December 9, 2019 10:18 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Date: Friday, 6 December 2019 at 17:40
To: SPRING WG <[email-masked]<mailto:[email-masked]>>, 6man <[email-masked]<mailto:[email-masked]>>
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

---

From: Ron Bonica <[email-masked]>
Date: Tue, 7 Jan 2020 18:07:04 +0000

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) <[email-masked]>
Sent: Tuesday, January 7, 2020 4:18 AM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>
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.

Thanks,
Pablo.

From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Date: Saturday, 21 December 2019 at 20:59
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] SRv6 Network Programming - ICMP Source Address Selection

Pablo,

"   (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.

      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) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 20, 2019 12:30 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Ron,

Happy Holidays,
Pablo.

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

Ron,

Cheers,
Pablo.

Pablo,

Which did you choose?

                                                                         Ron

Ron,

Thanks,
Pablo.

Authors,

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

                                                                     Ron

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 10 Jan 2020 16:53:57 +0000

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.

Date: Tuesday, 7 January 2020 at 19:07

Pablo,

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

                                                                                     Ron

Ron,

Thanks,
Pablo.

Pablo,

So, which is it?

                                                    Happy Holidays,
                                                         Ron

Ron,

Happy Holidays,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Cheers,
Pablo.

Pablo,

Which did you choose?

                                                                         Ron

Ron,

Thanks,
Pablo.

Authors,

                                                                     Ron

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

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

---

From: Ron Bonica <[email-masked]>
Date: Fri, 10 Jan 2020 19:08:51 +0000

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

Sent: Friday, January 10, 2020 11:54 AM

Ron,

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.

Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>

Pablo,

                                                                                     Ron

Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>

Ron,

Thanks,
Pablo.

Pablo,

So, which is it?

                                                    Happy Holidays,
                                                         Ron

Ron,

Happy Holidays,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Cheers,
Pablo.

Pablo,

Which did you choose?

                                                                         Ron

Ron,

Thanks,
Pablo.

Authors,

                                                                     Ron

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 13 Jan 2020 17:30:45 +0000

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.

Date: Friday, 10 January 2020 at 20:09

Pablo,

                                                                                         Ron

Ron,

Thanks,
Pablo.

Pablo,

                                                                                     Ron

Ron,

Thanks,
Pablo.

Pablo,

So, which is it?

                                                    Happy Holidays,
                                                         Ron

Ron,

Happy Holidays,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Cheers,
Pablo.

Pablo,

Which did you choose?

                                                                         Ron

Ron,

Thanks,
Pablo.

Authors,

                                                                     Ron

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jan 2020 13:29:10 -0500

Let me try asking the question a different way.  (I hope I understand 
Ron;s question.)

RFC 4443 clearly allows the ICMP source to be the destination address of 
the offending packet.  You seem to be saying that sometimes that is okay 
for SRH  / network programming.

At the same time, the SRH document and the network programming document 
are both quite clear that SRv6 SIDs are not IPv6 addresses.  They are 
other kinds of things that can be prefix routed.
If SRv6 SIDs are NOT IPv6 addresses, then there would seem to be a 
problem with putting them in the source address field of an ICMP 
message.  There is no document that describes or allows anything other 
than an IPv6 address as the source address of an IPv6 ICMP.

It seems like it ought to be possible to clarify this with some text. 
It does seem that something ought to be said.

Yours,
Joel

On 1/13/2020 12:30 PM, Pablo Camarillo (pcamaril) wrote:
> 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.
> 
> 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 <[email-masked]>
> *Date: *Friday, 10 January 2020 at 20:09
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *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
> 
> *From:*Pablo Camarillo (pcamaril) <[email-masked]>
> *Sent:* Friday, January 10, 2020 11:54 AM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* [email-masked]
> *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.
> 
> 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 <[email-masked] <mailto:[email-masked]>>
> *Date: *Tuesday, 7 January 2020 at 19:07
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked] 
> <mailto:[email-masked]>>
> *Cc: *SPRING WG <[email-masked] <mailto:[email-masked]>>
> *Subject: *RE: [spring] SRv6 Network Programming - ICMP Source Address 
> Selection
> 
> Pablo,
> 
> 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
> 
> *From:*Pablo Camarillo (pcamaril) <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Tuesday, January 7, 2020 4:18 AM
> *To:* Ron Bonica <[email-masked] <mailto:[email-masked]>>
> *Cc:* SPRING WG <[email-masked] <mailto:[email-masked]>>
> *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 <[email-masked] <mailto:[email-masked]>>
> *Date: *Saturday, 21 December 2019 at 20:59
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked] 
> <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Subject: *RE: [spring] SRv6 Network Programming - ICMP Source Address 
> Selection
> 
> Pablo,
> 
> 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
> 
> *From:*Pablo Camarillo (pcamaril) <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Friday, December 20, 2019 12:30 PM
> *To:* Ron Bonica <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *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.
> 
> *From: *spring <[email-masked] 
> <mailto:[email-masked]>> on behalf of Ron Bonica 
> <rbonica=[email-masked] 
> <mailto:rbonica=[email-masked]>>
> *Date: *Thursday, 19 December 2019 at 14:59
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> *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
> 
> *From:*Pablo Camarillo (pcamaril) <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Thursday, December 19, 2019 6:47 AM
> *To:* Ron Bonica <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* Re: SRv6 Network Programming - ICMP Source Address Selection
> 
> Ron,
> 
> *From: *Ron Bonica <[email-masked] <mailto:[email-masked]>>
> *Date: *Monday, 9 December 2019 at 23:48
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked] 
> <mailto:[email-masked]>>, SPRING WG <[email-masked] 
> <mailto:[email-masked]>>, 6man <[email-masked] <mailto:[email-masked]>>
> *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
> 
> *From:*Pablo Camarillo (pcamaril) <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Monday, December 9, 2019 10:18 AM
> *To:* Ron Bonica <[email-masked] <mailto:[email-masked]>>; 
> SPRING WG <[email-masked] <mailto:[email-masked]>>; 6man 
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* Re: SRv6 Network Programming - ICMP Source Address Selection
> 
> Ron,
> 
> *From: *ipv6 <[email-masked] <mailto:[email-masked]>> on 
> behalf of Ron Bonica <rbonica=[email-masked] 
> <mailto:rbonica=[email-masked]>>
> *Date: *Friday, 6 December 2019 at 17:40
> *To: *SPRING WG <[email-masked] <mailto:[email-masked]>>, 6man 
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *SRv6 Network Programming - ICMP Source Address Selection
> 
> Authors,
> 
> 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
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 13 Jan 2020 19:41:37 +0000

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

Sent: Monday, January 13, 2020 12:31 PM

Ron,

Thank you,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Thanks,
Pablo.

Pablo,

                                                                                     Ron

Ron,

Thanks,
Pablo.

Pablo,

So, which is it?

                                                    Happy Holidays,
                                                         Ron

Ron,

Happy Holidays,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Cheers,
Pablo.

Pablo,

Which did you choose?

                                                                         Ron

Ron,

Thanks,
Pablo.

Authors,

                                                                     Ron

---

From: Mark Smith <[email-masked]>
Date: Tue, 14 Jan 2020 08:43:58 +1100

On Tue, 14 Jan 2020, 05:29 Joel M. Halpern, <[email-masked]> wrote:

> message.

I'd say if SRv6 SIDs are stated not to be IPv6 addresses, then I think
there is a problem with using their values anywhere with and in the IPv6
protocol, including packets' DA fields, unless there is a translation
function between SRv6 SIDs and IPv6 addresses.

The translation function might be nothing more than a simple copy of the
128 bit SID value into the place where it will be used in IPv6, and I
understand this would be the motivation for having 128 bit SIDs in SRv6 and
20 bit SIDs in SR-MPLS.

However that then means SID values always have to comply with IPv6 address
requirements and formats, regardless of SR context. Otherwise, the
translation function needs to be a transform between SRv6 SIDs and IPv6
addresses.

  There is no document that describes or allows anything other

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 14 Jan 2020 17:43:07 +0000

Joel,

I think you might be mistaken.

RFC8402: 
	SRv6 SID: an IPv6 address explicitly associated with the segment.

SRH: 
	Segment List[n]: 128 bit IPv6 addresses representing the nth
     	 segment in the Segment List.

NET-PGM:
	   RFC8402 defines an SRv6 Segment Identifier as an IPv6 address
   	explicitly associated with the segment.

Thanks,
Pablo.

-----Original Message-----
From: "Joel M. Halpern" <[email-masked]>
Date: Monday, 13 January 2020 at 19:29
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

    

    Yours,
    Joel

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 14 Jan 2020 17:43:51 +0000

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.

Date: Monday, 13 January 2020 at 20:41

Pablo,

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

“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.”

                                                                                                            Ron

Ron,

Thank you,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Thanks,
Pablo.

Pablo,

                                                                                     Ron

Ron,

Thanks,
Pablo.

Pablo,

So, which is it?

                                                    Happy Holidays,
                                                         Ron

Ron,

Happy Holidays,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Cheers,
Pablo.

Pablo,

Which did you choose?

                                                                         Ron

Ron,

Thanks,
Pablo.

Authors,

                                                                     Ron

---

From: Ron Bonica <[email-masked]>
Date: Tue, 14 Jan 2020 19:28:10 +0000

Pablo,

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

                                                                               Ron

Sent: Tuesday, January 14, 2020 12:44 PM

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.

Pablo,

                                                                                                            Ron

Ron,

Thank you,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Thanks,
Pablo.

Pablo,

                                                                                     Ron

Ron,

Thanks,
Pablo.

Pablo,

So, which is it?

                                                    Happy Holidays,
                                                         Ron

Ron,

Happy Holidays,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Cheers,
Pablo.

Pablo,

Which did you choose?

                                                                         Ron

Ron,

Thanks,
Pablo.

Authors,

                                                                     Ron

---

From: Ron Bonica <[email-masked]>
Date: Tue, 14 Jan 2020 19:55:11 +0000

Pablo,

Can we disregard Robert's claim, quoted below?

- https://mailarchive.ietf.org/arch/msg/spring/u1AzYFpDe-AhIxXdih2BEIz65Bk

                                                                         Ron

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: Tuesday, January 14, 2020 12:43 PM
To: [email-masked]; Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Joel,

RFC8402: 

SRH: 

NET-PGM:

Thanks,
Pablo.

-----Original Message-----
From: "Joel M. Halpern" <[email-masked]>
Date: Monday, 13 January 2020 at 19:29
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

    

    Yours,
    Joel
    
    On 1/13/2020 12:30 PM, Pablo Camarillo (pcamaril) wrote:
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!XsYfcsn8zylD2GA3gujyjC3w_XX073_GCkqQ8B3M6Fzb6qTPXsJmdRw-gEvAT9Mj$ 
    >

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 16 Jan 2020 18:09:13 +0000

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 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Tuesday, 14 January 2020 at 20:28
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Pablo,

                                                                               Ron

Ron,

Cheers,
Pablo.

Pablo,

                                                                                                            Ron

Ron,

Thank you,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Thanks,
Pablo.

Pablo,

                                                                                     Ron

Ron,

Thanks,
Pablo.

Pablo,

So, which is it?

                                                    Happy Holidays,
                                                         Ron

Ron,

Happy Holidays,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Cheers,
Pablo.

Pablo,

Which did you choose?

                                                                         Ron

Ron,

Thanks,
Pablo.

Authors,

                                                                     Ron

---

From: Erik Kline <[email-masked]>
Date: Thu, 16 Jan 2020 13:38:09 -0800

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) <
[email-masked]> wrote:

> 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 <[email-masked]> on behalf of Ron Bonica <rbonica=
> [email-masked]>
> *Date: *Tuesday, 14 January 2020 at 20:28
> *From:* Pablo Camarillo (pcamaril) <[email-masked]>
> *Sent:* Tuesday, January 14, 2020 12:44 PM
> 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.
>
>
>
> *Date: *Monday, 13 January 2020 at 20:41
> 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
>
>
>
>
>
> *From:* Pablo Camarillo (pcamaril) <[email-masked]>
> *Sent:* Monday, January 13, 2020 12:31 PM
> 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.
>
> 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
>
>
>
>
>
>
>
> *From:* Pablo Camarillo (pcamaril) <[email-masked]>
> 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
> 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.
>
>
>
> *Cc: *SPRING WG <[email-masked]>
> -          Node Q is an intermediate node on the path from Node S to Node
> D. For some reason, Node Q cannot forward the packet.
>
> 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
>
>
>
>
>
>
>
> *From:* Pablo Camarillo (pcamaril) <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>
> 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.
>
>
>
> 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
>
>
>
>
>
>
>
>
>
> *From:* Pablo Camarillo (pcamaril) <[email-masked]>
> *From: *spring <[email-masked]> on behalf of Ron Bonica <
> rbonica=[email-masked]>
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> *From:* Pablo Camarillo (pcamaril) <[email-masked]>
> *To:* Ron Bonica <[email-masked]>; [email-masked]
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked]>, SPRING WG <
> [email-masked]>, 6man <[email-masked]>
> 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
>
>
>
>
>
> *From:* Pablo Camarillo (pcamaril) <[email-masked]>
> *To:* Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>; 6man
> <[email-masked]>
> *From: *ipv6 <[email-masked]> on behalf of Ron Bonica <
> rbonica=[email-masked]>
> *To: *SPRING WG <[email-masked]>, 6man <[email-masked]>
> unicast address, the first option is applicable. If you think that a SID is
> not a unicast address, the second option is applicable.
>
>
>
>                                                                      Ron
>
>
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 22 Jan 2020 06:54:43 +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 <[email-masked]>
Date: Thursday, 16 January 2020 at 22:39
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Ron Bonica <[email-masked]>, "[email-masked]" <[email-masked]>
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.

On Thu, Jan 16, 2020 at 10:25 AM Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:
Ron,

Cheers,
Pablo.

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>

Pablo,

                                                                               Ron

Ron,

Cheers,
Pablo.

Pablo,

                                                                                                            Ron

Ron,

Thank you,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Thanks,
Pablo.

Pablo,

                                                                                     Ron

Ron,

Thanks,
Pablo.

Pablo,

So, which is it?

                                                    Happy Holidays,
                                                         Ron

Ron,

Happy Holidays,
Pablo.

Pablo,

                                                                                         Ron

Ron,

Cheers,
Pablo.

Pablo,

Which did you choose?

                                                                         Ron

Ron,

Thanks,
Pablo.

Authors,

                                                                     Ron

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