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

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to