Re: [savnet] SAVNET thoughts

[[e-mail]]

Thank Shu to move the email thread to the mailing list. Yes, if we can extend an existing routing protocol in an arbitrary way, it is actually similar as designing a new protocol. The only difference is how many levels of protocol headers are used to encapsulate the new protocol.

 

Dan

 

发件人: 杨术 <[e-mail]> 
发送时间: 2022年3月21日 19:39
收件人: [e-mail]; [e-mail]; [e-mail]
主题: RE: SAVNET thoughts

 

​Dear Dan,  

  

I have read through the meeting ​materials, and they look great.  I move the discussion in another mail thread (with Jari) to this mailing list for more comments.   

  

Best Regards,  

Shu Yang 

​

[Jari:] Gap analysis – overall good, some comments though:​ 

*	I was trying to think about the root cause situation (slide 9), and wondered about fundamentals of routing. Not that I know much about it, but … Could it be that there are actually two root causes?: 

*	One, if you do not use all the information that would be available. For instance, if you *did* have a network topology map like the one on slide 8, you *could* in theory calculate that P2 can only come from AS2, whereas P3 could come from AS1, AS3, or AS5 given their connectivity. RFC 8704 doesn’t seem to use this info.. and I’m not sure if that’s because of BGP’s nature as a distance vector/path vector protocol. 
*	The second root cause is that something happens in network part X, and this needs to be taken into account in network part Y. There doesn’t seem to be a way around this actually, it is always the case that X knows the situation before Y, so either you (a) ensure that no data plane packets get sent before you’ve confirmed that Y has learned about the change (introducing an undesirable delay) or (b) accept that before Y learns of the true situation, some packets may be improperly discarded or passed through a SAV check. 

  

Given this, it would seem to be that to improve SAV, one has to primarily ensure that enough data is shared and that all the shared data is actually used. This does not necessarily need a new network protocol, if existing routing protocols pass the necessary information. It would seem to be the case that OSPF for instance does, if I have understood things correctly. Of course, secondly you may wish to ensure that there’s less temporary glitches when something changes. However, that doesn’t fundamentally seem to be possible with introducing a delay. But one can of course reduce the delay by ensuring that either a routing protocol or new protocol communicates a change as soon as it has happened. 

  

Would appreciate comments on this. Am I missing something? 

[Dan:] OSPF is not enough. Because we need to discover the real forwarding path in the data plane, while the data-plane forwarding path may not only be determined by OSPF. Static routing, ACL-like routing redirection may also change the real data-plane forwarding path. 

The delay between routing update and SAV learning is inevitable, and we are list it as an open question. We do have some ways to mitigate the problem, but cannot fundamentally avoid it. Just like packet loss from temporal loop during routing update cannot be completely avoided. 

[Shu:] Traditional OSPF is surely not enough, but I was wondering can we use OSPF extension to deliver the addtional configuration information. Or this could be a choice to improve SAV. Just like src-dst routing have done for distributed source address filtering​ （draft-ietf-rtgwg-dst-src-routing-07​）.  

​