Re: [spring] IPv6 Addresses and SIDs

On Mon, 14 Oct 2019, 16:45 Wang, Weibin (NSB - CN/Shanghai), <
weibin.wang@nokia-sbell.com> wrote:

> Hi Ron:
>
>
>
> Make sense, If there is a dedicated IPv6 block for SRv6 SID within SRv6
> domain, then trouble situation you described does NOT occur, because the
> IPv6 address covered within SRv6 SID prefix does not be involved ICMPv6 ND
> protocol, because they are not configured under IP interfaces connected to
> “Link”.
>

That does not comply with the IPv6 Addressing Architecture RFC.

(I think this is the 4th time SPRING have or are ignoring IPv6
specifications.)

I also think that the authors of NET-PGM draft have indicated that SRv6 SID
> has a separate IPv6 block in their Draft, but they don’t yet clearly stated
> which IPv6 block will be used for it.
>
>
>
>
>
> --------------------------------------
>
> *Cheers !*
>
>
>
>
>
> *WANG Weibin  *
>
>
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Ron Bonica
> *Sent:* 2019年10月14日 9:23
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* SPRING WG List <spring@ietf.org>
> *Subject:* Re: [spring] IPv6 Addresses and SIDs
>
>
>
> Robert,
>
>
>
> Yeah, there were a few typos in my original message. What I meant to say
> was:
>
>
>
>    - If a /64 contains a SID, it MUST NOT contain any addresses that
>    represent interfaces.
>    - If a /64 contains an address that represents an interface, it MUST
>    NOT contain SIDs.
>
>
>
> If we don’t do this, we have to specify how nodes behave when they receive
> ICMPv6 NS messages in which the target is:
>
>
>
>    - A locally instantiated SID
>    - A SID learned from the IGP
>
>
>
>                                                                       Ron
>
>
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Sunday, October 13, 2019 6:57 PM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* SPRING WG List <spring@ietf.org>
> *Subject:* Re: IPv6 Addresses and SIDs
>
>
>
> Hi Ron,
>
>
>
> /64 prefix is a pile of addresses ... if someone would be to follow your
> suggestion I could not allocate some blocks of that prefix on R1, then some
> other blocks on R2 then yet more on my servers.
>
>
>
> You said:
>
>
>
> *“With a /64, if one /128 represents an IPv6 interface, as described in
> RFC 4291, all /128 MUST either:*
>
>
>
>    - *Represent an IPv6 interface, as described in RFC 4291, or*
>    - *Be unassigned”*
>
>
>
> Maybe you meant to say something else:
>
>
>
> *“When a /64 is used as SRv6 locator prefix, if one /128 represents an
> IPv6 interface, as described in RFC 4291, all /128 MUST either:*
>
>
>
>    - *Represent an IPv6 interface, as described in RFC 4291, or*
>    - *Be unassigned”*
>
> But then you sent this to SPRINT indicating that 6MAN should be the
> audience :).
>
>
>
> Best,
> R.
>
>
>
>
>
> On Mon, Oct 14, 2019 at 12:45 AM Ron Bonica <rbonica@juniper.net> wrote:
>
> Robert,
>
>
>
> I’m having a hard time understanding exactly how I have violated the
> longest match principle. Could you provide:
>
>
>
>    - A pointer to a statement of the longest match principle
>    - A few words regarding how I have violated it
>
>
>
>                                                               Ron
>
>
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Sunday, October 13, 2019 5:24 PM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* SPRING WG List <spring@ietf.org>
> *Subject:* IPv6 Addresses and SIDs
>
>
>
> Hi Ron,
>
>
>
> I disagree.
>
>
>
> Your suggestion violates longest prefix match principle in routing.
>
>
>
> It is huge waist of address space and is not specific to IPv6 at all.
>
>
>
> Let me describe the deployment case where your suggestion would cause it
> to break:
>
>
>
> I have /64 prefix where a few  /128s from that space I allocate to local
> interfaces making it a local v6 destinations on those nodes.
>
>
>
> However in the spirit of CIDR I still want to to use some blocks of that
> space - say  /126 or /124 as blocks which I only use to trigger local NAT
> as per rfc6296. And NAT does not require local address to be a destination
> address so it would be a big disservice to kill such deployment option.
>
>
>
> Many thx,
> R.
>
>
>
>
>
> On Sun, Oct 13, 2019 at 10:59 PM Ron Bonica <rbonica=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> Folks,
>
>
>
> I think that we need a global rule that says:
>
>
>
> “With a /64, if one /128 represents an IPv6 interface, as described in RFC
> 4291, all /128 MUST either:
>
>
>
>    - Represent an IPv6 interface, as described in RFC 4291, or
>    - Be unassigned”
>
>
>
> The 6man WG will need to make such a statement since it owns RFC 4291.
>
>
>
>                                                              Ron
>
>
>
> Juniper Business Use Only
>
>
>
> Juniper Business Use Only
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>