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

Hi Andrew,

Please kindly observe that SID can be 16-bit ... how could it be an IP
address as defined today ?

REF:
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-04

Please also notice that SID can be of variable length too. How could it be
an IP address ?

REF: https://tools.ietf.org/html/draft-decraene-spring-srv6-vlsid-03

And to your complete surprise let me point out that the text:

When an SRv6 SID *is in the* Destination Address field of an IPv6 header of
a packet,

simply says that SID can be part of DA, not necessarily need to be a
complete DA therefore SR architecture still holds pretty well :)

Cheers,

R.

On Thu, Mar 12, 2020 at 9:26 AM Andrew Alston <
Andrew.Alston@liquidtelecom.com> wrote:

> Brian,
>
>
>
> Let me clarify a few things – for my own understanding – I am happy to be
> wrong here, and if I am just let me know (while what I am writing may come
> across as statements, it was easiest to write that way, consider the
> statements clarification questions) –
>
>
>
> Firstly – let us consider the RFC8402 argument for a second – though I
> think we should probably consider this separately.  In reference to RFC8402
> this draft states – in section 3:
>
>
>
> When an SRv6 SID is in the Destination Address field of an IPv6
>
>    header of a packet, it is routed through an IPv6 network as an IPv6
>
>    address.
>
>
>
> So – we establish that indeed – SRv6 SID’s are IPv6 addresses – there is
> no two ways about it – they go into the destination field.  This is
> contrary to what Robert argued in an email found at
> https://mailarchive.ietf.org/arch/msg/spring/u1AzYFpDe-AhIxXdih2BEIz65Bk/
>
>
>
> Now, lets look at this draft specifically in reference to RFC4291.
>
>
>
> Section 2 of RFC4291 states that IPv6 addresses are identifiers for
> interfaces and sets of interfaces – where an interface is defined in
> RFC2460 as a “node’s attachment to a link”.  This document creates SID’s
> that have no binding to any interface.  Section 3 of the NP draft
> explicitly refers to lookups that lookup SID’s (which we have already
> established are addresses) that have no interface bindings.
>
>
>
> In section 3.1 – this talks about the Locator – this is entirely compliant
> with section 2.5 of RFC4291 – however – the function and arguments section
> of this – have no relation to interface ID’s – it is debatable if this is
> as a result of problems in RFC8402 or indeed, potentially both drafts –
> since it is this document that explicitly creates these function and
> argument sections independently of RFC8402 in section 3.1.
>
>
>
> Indeed RFC3587 states in section 3:
>
>
>
> [ARCH] also requires that all unicast addresses, except those that
>
>    start with binary value 000, have Interface IDs that are 64 bits long
>
>    and to be constructed in Modified EUI-64 format.  The format of
>
>    global unicast address in this case is:
>
>
>
>
>
> I fail to see how defining a function and arguments in the way this
> document describes are compliant with this.  Now, it can also be argued
> that there are many implementations that violate these specifications –
> Linux allows you to bind entire /64s to loopback addresses, however, I
> would argue that it is a very different case for an implementation to
> violate the specification as for an RFC to violate the specification and
> make it into a standard.
>
>
>
> I will also note and acknowledge that some may think that I am being
> pretty pedantic here – but considering the context and the claims floating
> around about what other RFC’s say and don’t say – perhaps its time to start
> examining this whole thing with a fine tooth comb so that we can end up
> with a better result that works for everyone and doesn’t lead to unintended
> consequences.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
> *From:* Brian E Carpenter <brian.e.carpenter@gmail.com>
> *Sent:* Thursday, 12 March 2020 00:30
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com>; Darren Dukes
> (ddukes) <ddukes@cisco.com>; Ron Bonica <rbonica=
> 40juniper.net@dmarc.ietf.org>
> *Cc:* spring@ietf.org; 6man WG <ipv6@ietf.org>
> *Subject:* Re: Draft-ietf-spring-network-programming ipv6 addressing
> architecture - was draft-ietf-6man-segment-routing-header-26 violating
> RFC4291, IPv6 Addressing Architecture?
>
>
>
> 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.
>
> 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
> <EXT-Andrew.Alston@liquidtelecom.com>> <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.Alston@liquidtelecom.com
> <Andrew.Alston@liquidtelecom.com%20%3cmailto: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
>