[savnet] 答复: SAVNET thoughts

[Changxiangqing <[e-mail]>]

Agreed. For intra domain SAV, it is theoretically feasible to use IGP protocol to carry source address information, but it should be considered that the flooding range of IGP protocol is limited to the region. If the whole network synchronization in the domain is achieved, the problem of cross region propagation should be considered.At the same time, because the source address information is almost equal to the routing information, the use of IGP protocol may bring too much transmission pressure to the routing protocol.

Xiangqing

发件人: savnet [mailto:[e-mail]] 代表 [e-mail]
发送时间: 2022年3月21日 20:08
收件人: '杨术' <[e-mail]>cn>; [e-mail]; [e-mail]
主题: Re: [savnet] SAVNET thoughts

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]<mailto:[e-mail]>>
发送时间: 2022年3月21日 19:39
收件人: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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​）.
​
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!