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