Hi Adrian, You are very welcome to restate that point. Sorry if it felt like your point was not taken into consideration.
I see 2 points. 1) IPv6 address to interfaces only Ø RFC 8200 defers to RFC 4291 for the definition of an IPv6 address. RFC 4291 has a somewhat simplistic and possibly historic definition of an IPv6 address... Ø IPv6 addresses are 128-bit identifiers for interfaces and sets of Ø interfaces (where "interface" is as defined in Section 2 of [IPV6]). Ø ...where the reference was to RFC 2460 which (of course) is obsoleted by RFC 8200. RFC 8200 has... Ø interface a node's attachment to a link. Ø address an IPv6-layer identifier for an interface or a set of interfaces. [...] Ø The challenge, as far as I see it, is purely semantic. That is, we propose to place in the DA field of an IPv6 header a value which is routable but which does not identify an interface. I agree with your quote and would also add "IPv6 addresses of all types are assigned to interfaces, not nodes. " Such definitions indeed do not seem to allow for the use of an IPv6 address for a node nor for non-interface. On the other hand, IP/MPLS routing/signalling heavily uses an IP address to represent a node (aka "Loopback"), at least for routing nodes. I don't recall that the IPv6 addressing architecture had/is been seen as a blocking point. Would you like to equally raise that point in the routing area? It also seem to me that RFC 6052 or RFC 7599 use IPv6 addresses for non-interfaces. https://tools.ietf.org/html/rfc6052 https://tools.ietf.org/html/rfc7599 And there are probably other usages of IPv6 addresses. 2) SPRING use of IPv6 address For the IPv6 data plane (aka SRv6), SPRING uses IPv6 address to represent a segment from day one. I think that this is clearly indicated in RFC 8402 https://tools.ietf.org/html/rfc8402 including in the abstract. Plus that a segment can represent a relatively broad semantic (an "instruction"), much broader than an interface. It seems to me that draft-ietf-6man-segment-routing-header makes it clear that that RFC 8402 is the SR architecture, in particular for SRv6, and it normatively references RFC 8402. In addition, draft-ietf-6man-segment-routing-header -which is a 6MAN WG document, under WG last call for some months- specifically indicates that distinction between an IPv6 address representing a local interface and an IPv6 address representing an SRv6 SID: When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match lookup on the packets destination address. This lookup can return any of the following: A FIB entry that represents a locally instantiated SRv6 SID A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID A FIB entry that represents a non-local route No Match https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-18#section-4.3 This point has also been presented during IETF 102 https://datatracker.ietf..org/meeting/102/proceedings#6man (cf slide 19) Finally, I see that you have specifically raised that question to the 6MAN WG, during draft-ietf-6man-segment-routing-header Working Group Last Call, and that nobody seemed to share your concern on this specific point. https://mailarchive.ietf.org/arch/msg/ipv6/90Jrc7D5deFAOT2JPaCPzw_fBJk In conclusion, I don't think that the SPRING use of IPv6 address for SRv6 SID has been hidden or even not clearly mentioned to the 6MAN working group. Best regards, --Bruno From: Adrian Farrel [mailto:[email protected]] Sent: Saturday, April 27, 2019 11:41 AM To: [email protected] Cc: 'SPRING WG' Subject: RE: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming Hi chairs, I hate to sound like a broken record. I just want to get this issue clarified before we get to a late stage and risk being forced to start again. RFC 8200 defers to RFC 4291 for the definition of an IPv6 address. RFC 4291 has a somewhat simplistic and possibly historic definition of an IPv6 address... IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces (where "interface" is as defined in Section 2 of [IPV6]). ....where the reference was to RFC 2460 which (of course) is obsoleted by RFC 8200. RFC 8200 has... interface a node's attachment to a link. address an IPv6-layer identifier for an interface or a set of interfaces. Now, during the adoption poll, I suggested that the chairs might like to ping 6man to check that the proposed work in this draft is an acceptable modification to this definition. The challenge, as far as I see it, is purely semantic. That is, we propose to place in the DA field of an IPv6 header a value which is routable but which does not identify an interface. I am not clear whether this represents an Update to RFC 8200 or to RFC 4291, but I do strongly recommend that the chairs check with 6man that this approach is not going to be rejected during IETF last call. Thanks, Adrian From: spring <[email protected]> On Behalf Of [email protected] Sent: 24 April 2019 13:13 To: SPRING WG <[email protected]>; [email protected] Subject: Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming Hi authors, WG, This document has been accepted as a new WG document. Authors, please: · update email address of authors · republish current/same draft (reviewed and accepted by the WG) as draft-ietf-spring-srv6-network-programming-00 · publish -01 to reflect comments and agreement made on the mailing list · reply to unanswered WG comments and engage resolution on open points raised so far, in particular during WG adoption call. E.g. (1), (2) As an additional point, this document is not intended to update RFC 8200. If a behavior needs to update RFC 8200, it should be defined in a 6MAN draft in the 6MAN WG and normatively referenced. Thank you, --Bruno, Rob 1. https://mailarchive.ietf.org/arch/msg/spring/ulYVHKfb6h4fOtM8kqLmeGnVNlY 2. https://mailarchive.ietf.org/arch/msg/spring/G_1ZqvInpZ9N2TX7TK8zOLa-e9I From: spring [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, March 13, 2019 7:50 PM To: SPRING WG Cc: [email protected] Subject: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming Hi SPRING WG, This email initiates a three week call for working group adoption for draft-filsfils-spring-srv6-network-programming. (Three weeks to account for the IETF week) Please indicate your support, comments, or objection, for adopting this draft as a working group item by April, 3rd, 2019 (aka 2019-04-03) We are particularly interested in hearing from working group members that are not co-authors of this draft. We are also looking for volunteers who would be ready to perform a technical review of this work at some later stage, such as before or during WG the last call. In parallel to this adoption call, I will send an IPR call for this document. We will need all authors and contributors to confirm their IPR position on this document. There is currently 1 IPR filled (2) (1) https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07 (2) https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-network-programming&submit=draft Thank you, --Bruno & Rob. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
