Re: [spring] IPv6 Addresses and SIDs

On Mon, Oct 14, 2019 at 4:31 PM Mark Smith <markzzzsmith@gmail.com> wrote:

>
>
> On Tue, 15 Oct 2019, 04:19 Ron Bonica, <rbonica@juniper.net> wrote:
>
>> Mark,
>>
>>
>>
>> Clearly, this does not comply with the addressing architecture. But I
>> think that the best we can do is to limit the damage.
>>
>
> Has SPRING tried?
>
> Assigning this address space to a virtual interface in the device would
> make it comply with the RFC 4291 architecture, and also provide a handle
> within the device for any other functions that could be operationally
> useful..
>
> For example, the SNMP MIB traffic counters for that virtual interface
> could show SR traffic volumes as distinct from other IPv6 traffic to, from
> or through the device. If there a different SR address spaces on the
> device, the could be attached to different virtual interfaces, providing
> more discrete SR traffic counters.
>
> Having a virtual SR interface would also provide a handle to attach a
> packet filter ACL to, which may be useful.
>
> Having used IP encryption implementations that both did and didn't
> represent traffic encryption paths as virtual tunnel interfaces, the tunnel
> virtual interfaces implementations (also eventually adopted by the
> non-virtual interface implementations) far more obvious and intuitive to
> work with.
>
> Regards,
> Mark..
>
> [Gyan]. Since we are requiring IPv6 encapsulation anyway on the ingress
> origin source node adding the  SRH EH in flight we could make it a GRE
> tunnel interface which would add 4 extra GRE bytes but would provide an
> interface for traffic statistics and mib counters depicting the IPv6 data
> plane identical to a 6in6 tunnel.
>

 Other even simpler option is to use a loopback with the dedicated SID /64
> prefix defines so its decoupled from any physical interface.
>

Since the traffic for SRv6 reuses the same IPv6 data plane the traffic
would go normally over the IGP routed enabled path to the next hop SID in
the SID list so the only gain from using GRE tunnel is if you want to be
able to decouple the SRv6 traffic from other IPv6 traffic since both share
the same data plane.

>
>>
>>
>> Ron
>>
>>
>>
>>
>>
>> *From:* Mark Smith <markzzzsmith@gmail.com>
>> *Sent:* Monday, October 14, 2019 4:08 AM
>> *To:* Wang, Weibin (NSB - CN/Shanghai) <weibin.wang@nokia-sbell.com>
>> *Cc:* Ron Bonica <rbonica@juniper.net>; Robert Raszuk <robert@raszuk.net>;
>> SPRING WG List <spring@ietf.org>
>> *Subject:* 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  *
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *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
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!SEkBOAmRsYlBjRKWx1gZ4eegKkzZOKQgTtZuXxMv5TgCiZMT9xl0OH0Q8pbdZee9$>
>>
>> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com

www.linkedin.com/in/networking-technologies-consultant