Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Brian,

> On Mar 11, 2020, at 2:30 PM, Brian E Carpenter <brian.e.carpenter@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)" <ddukes@cisco.com>
>> *Date: *Wednesday, 11 March 2020 at 22:03
>> *To: *Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
>> *Cc: *Andrew Alston <Andrew.Alston@liquidtelecom.com>, 6man WG <ipv6@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.net@dmarc.ietf.org <mailto:rbonica=40juniper.net@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-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>> *On Behalf Of *Darren Dukes (ddukes)
>>    *Sent:* Tuesday, March 10, 2020 12:07 PM
>>    *To:* EXT-Andrew.Alston@liquidtelecom.com <mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com <mailto:Andrew.Alston@liquidtelecom.com>>
>>    *Cc:* 6man WG <ipv6@ietf.org <mailto:ipv6@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.Alston@liquidtelecom.com <mailto:Andrew.Alston@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
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Attachment: signature.asc