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

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Mar 2020 11:17:50 -0300

IAB & Folks,

These are yet more architectural changes taking place, without proper 
oversight. In this case, the document being the "IPV6 Addressing 
Architecture".

Just felt like raising it, like I did for others, IMHO without much success.

Thanks,
Fernando

-------- Forwarded Message --------
Subject: Re: [spring] Draft-ietf-spring-network-programming ipv6 
addressing architecture - was draft-ietf-6man-segment-routing-header-26 
violating RFC4291, IPv6 Addressing Architecture?
Date: Wed, 11 Mar 2020 17:39:30 -0700
From: Bob Hinden <[email-masked]>
To: Brian Carpenter <[email-masked]>
CC: Ron Bonica <rbonica=[email-masked]>, [email-masked] 
<[email-masked]>, Bob Hinden <[email-masked]>, IPv6 List 
<[email-masked]>

Brian,

> On Mar 11, 2020, at 2:30 PM, Brian E Carpenter <[email-masked]> 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)" <[email-masked]>
>> *Date: *Wednesday, 11 March 2020 at 22:03
>> *To: *Ron Bonica <rbonica=[email-masked]>
>> *Cc: *Andrew Alston <[email-masked]>, 6man WG <[email-masked]>
>> *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=[email-masked] <mailto:rbonica=[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> *On Behalf Of *Darren Dukes (ddukes)
>>    *Sent:* Tuesday, March 10, 2020 12:07 PM
>>    *To:* [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
>>    *Cc:* 6man WG <[email-masked] <mailto:[email-masked]>>
>>    *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 <[email-masked] <mailto:[email-masked]>> 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
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Mar 2020 15:30:25 -0700

Hi Fernando,
At 07:17 AM 12-03-2020, Fernando Gont wrote:
>These are yet more architectural changes taking place, without 
>proper oversight. In this case, the document being the "IPV6 
>Addressing Architecture".
>

The IAB does not do architecture oversight of documents intended to 
be "standards".  I just noticed that an IAB member is not advocating 
for a position which the IAB took.  Anyway, that is not what you 
asked about.  Please see below.

The Area Directors responsible for ensuring that the working groups 
falling within their Area produced architecturally consistent 
output.  My guess is that it happens when the Area Director(s) is an 
expert on the working group topic.  It can be controversial if an 
Area Director is too insistent about architectural purity.

Regards,
S. Moonesamy