Brian, > On Mar 11, 2020, at 2:30 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > On 12-Mar-20 09:53, Andrew Alston wrote: >> Hi Spring WG >> >> >> >> On the basis of the below – I must conclude that the issues relating the >> SID/IPv6 semantics have indeed not been dealt with by the spring working >> group in the context of the network programming draft – and I would now like >> to raise those issues in the context of that draft – and the fact that >> draft-ietf-spring-network-programming violates the address semantic >> specifications of RFC4291. > > I really think that this is subsidiary to RFC 8402 (a Proposed Standard): > > SR can be applied to the IPv6 architecture with a new type of routing > header called the SR Header (SRH) [IPv6-SRH]. An instruction is > associated with a segment and encoded as an IPv6 address. An SRv6 > segment is also called an SRv6 SID. An SR Policy is instantiated as > an ordered list of SRv6 SIDs in the routing header. > > I don't see anything in the SRH draft or the network-programming draft > that is not within that definition. Whether RFC 8402 contravenes RFC 4291 > is worth discussing, I guess. The latter says: > > IPv6 addresses of all types are assigned to interfaces, not nodes. > An IPv6 unicast address refers to a single interface. Since each > interface belongs to a single node, any of that node's interfaces' > unicast addresses may be used as an identifier for the node. > > However, I can't find anything in RFC 4291 that forbids addresses > having semantic meanings rather than being pure locators. It goes > against one of my design prejudices, but I can't find anything > resembling "Encoding semantics in address bits considered harmful" > in the RFCs.
RFC4291 in Section 2.5.4 does say: Except for the knowledge of the subnet boundary discussed in the previous paragraphs, nodes should not make any assumptions about the structure of an IPv6 address. Bob > In reality, there are lots of operational practices that amount to > giving semantic meanings to address bits. > > Brian > >> >> >> >> Can we please have a proper discussion on this >> >> >> >> Thanks >> >> >> >> Andrew >> >> >> >> >> >> *From: *"Darren Dukes (ddukes)" <ddu...@cisco.com> >> *Date: *Wednesday, 11 March 2020 at 22:03 >> *To: *Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> >> *Cc: *Andrew Alston <andrew.als...@liquidtelecom.com>, 6man WG >> <i...@ietf.org> >> *Subject: *Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, >> IPv6 Addressing Architecture? >> >> >> >> Hi Ron, I made no comment in this thread on >> draft-ietf-spring-network-programming. >> >> >> >> Darren >> >> >> >> On Mar 11, 2020, at 2:55 PM, Ron Bonica >> <rbonica=40juniper....@dmarc.ietf.org >> <mailto:rbonica=40juniper....@dmarc.ietf.org>> wrote: >> >> >> >> Darren, >> >> >> >> Didn’t we agree to close issue 66 because draft-ietf-6man-segment-routing >> header contains no text regarding SID/IPv6 address semantics. If that’s the >> case, how can you say that closing issue 66 implies WG consensus around >> SID/IPv6 address semantic proposed in draft-ietf-6man-network-programming? >> >> >> >> >> Ron >> >> >> >> >> >> >> >> Juniper Business Use Only >> >> *From:* ipv6 <ipv6-boun...@ietf.org <mailto:ipv6-boun...@ietf.org>> *On >> Behalf Of *Darren Dukes (ddukes) >> *Sent:* Tuesday, March 10, 2020 12:07 PM >> *To:* ext-andrew.als...@liquidtelecom.com >> <mailto:ext-andrew.als...@liquidtelecom.com> >> <andrew.als...@liquidtelecom.com <mailto:andrew.als...@liquidtelecom.com>> >> *Cc:* 6man WG <i...@ietf.org <mailto:i...@ietf.org>> >> *Subject:* Re: draft-ietf-6man-segment-routing-header-26 violating >> RFC4291, IPv6 Addressing Architecture? >> >> >> >> Hi Andrew please see issue #66 for the closure record. >> >> >> >> https://trac.ietf.org/trac/6man/ticket/66 >> <https://urldefense.com/v3/__https:/trac.ietf.org/trac/6man/ticket/66__;!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_$> >> >> >> >> Darren >> >> >> >> On Mar 9, 2020, at 3:18 PM, Andrew Alston >> <andrew.als...@liquidtelecom.com <mailto:andrew.als...@liquidtelecom.com>> >> wrote: >> >> >> >> Hi Darren >> >> >> >>> Hi Mark, the working group discussed the >> >> > association with RFC4291 and closed it with >> >> > the text in the document. >> >> >> >> Can we get a reference to these discussions please - would just be >> useful to back and refresh memories and wasn’t able to find them >> >> >> >> Thanks >> >> >> >> Andrew >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> i...@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
