Re: [spring] RFC8200 update?

["Wang, Weibin (NSB - CN/Shanghai)" <[e-mail]>]

In the bearer of srv6 traffic, srv6 domain is only one part of the whole packet journey. Because the srv6 domain is trusted by single operator, it is no necessary for the outer IPv6 header (for performing SRH function) to inherit all IPv6 extension headers specially designed for the initial end-to-end IPv6 communication, for example, the AH is not must for outer IPv6 header and its SRH. Therefore, the outer IPv6 processing of srv6 traffic can appropriately relax the restrictions, that is to say, the outer IPv6 encapsulation only inherits a part of IPv6 spec. For example, it is allowed to perform functions such as PSP within SRv6 domain;  Could we treat IPv6 headers function of internal and external layers differently, after all, their purposes are different.


Cheers!

Wang Weibin

-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Sander Steffann
Sent: Friday, February 28, 2020 8:51 PM
To: Andrew Alston <[e-mail]>
Cc: SPRING WG List <[e-mail]>; 6man WG <[e-mail]>
Subject: Re: [spring] RFC8200 update?

Hi Andrew,

> This is certainly an interesting idea - and I'd probably need to give this a whole lot more thought before commenting properly, but the first thought that comes to mind is - would we be able to standardize a way to instruct like this.
> 
> What I would not want to see is every extension header out there having a separate method of instructing the network to allow this behavior whenever they feel like it, because it would create a nightmare both in terms of seeing if something was requesting it, and I would imagine, implementing it.

Well, it depends on what you deploy in your network. If you deploy SRv6 NP then nodes sending traffic over your network can use the NP functions you provide. If you don't provide any functions then there is nothing a sender can do. This obviously only works when sender and network cooperate. Otherwise the NP instruction will make no sense. And AFAIK source-routing, segment-routing etc are not enabled by default these days, so packets using them will be dropped unless the network is specifically configured to allow them.

> So - my question is - what would be the standard way to introduce this - and to this I would say - if you wanted to do this you'd almost want to add a very short extension header that contains this instruction, that is easy to see and easy to parse - since I don't see anywhere in the v6 header itself that we could add this functionality as a flag of sorts.

That might be useful for many things besides this. Let's talk.

> Interesting ideas - but as I said - I'd argue that if we went this route - I'd want a standard shared way to do this by anything coming tomorrow - to avoid still further divergence.

I'm not sure a standard way is needed. Maybe limit the scope to "if the sender of the packet explicitly asked for that using a routing header"?

Cheers,
Sander