I should say "BGP messages propagate much slower" instead of "BGP converges
much slower", since SAV over BGP does not rely on BGP's convergence.
Xingang
-----原始邮件-----
发件人:Xingang <[email protected]>
发送时间:2022-05-06 19:55:50 (星期五)
收件人: "Lancheng Qin" <[email protected]>
抄送: [email protected], [email protected]
主题: Re: [savnet] Regarding reusing existing routing protocols for SAV//RE:
SAVNET WG charter
Hi Lancheng,
My concerns are specifically related to using BGP to propagate SAV information
in inter-domain, which is proposed in the WG charter.
"When the next hop to a destination node changes, the node will generate a
triggered notification message. The triggered notification message will update
SAV tables and SAV graphs in nodes along the new path.
-- It seems that you are talking about another signaling protocol other than
BGP. If this signaling protocol can update all nodes along the new path fast
enough (i.e., like IGP in intra-domain), there will be less problems. But I'm
talking about using BGP to convey SAV info. As we know, BGP converges much
slower, and this magnifies possible inconsistency.
" Just like packet loss from temporal loop during routing update cannot be
completely avoided."
-- I think the problem caused by inconsistency in SAV is greater than in
routing/forwarding, and is even greater when using BGP for SAV in inter-domain.
You can check the reasoning in my last email. On the other hand, the churn
caused by SAV over BGP may also be more severe than the churn in BGP. This is
why I would like to see some evaluation results on actually using BGP under
real BGP update load, rather than using a fast signaling protocol.
Thx.
Xingang
-----原始邮件-----
发件人:"Lancheng Qin" <[email protected]>
发送时间:2022-05-06 17:31:17 (星期五)
收件人:
抄送: [email protected], [email protected]
主题: Re: [savnet] Regarding reusing existing routing protocols for SAV//RE:
SAVNET WG charter
Hi Xingang,
Thank you for your advice. As we discussed in the BoF, convergence is an
important issue, especially in the inter-domain scenario. When updating, there
may be a gap between the change of FIB table and the update of SAV table, which
may cause improper block problems. The gap is inevitable, but the triggered
updating procedures in SAVNET architecture can allow SAV tables to converge as
quickly as possible. IOW, we can mitigate the problem of convergence but cannot
fundamentally avoid it. Just like packet loss from temporal loop during routing
update cannot be completely avoided.
We introduce a new terminology, “SAV graph”, which stores the forwarding path
from each origin node to the local node. The notification message should record
the passed nodes on the propagated path in sequence, like the AS Path attribute
in the BGP announcement. In this way, the node can generate a SAV graph based
on the propagated path information of received notification messages.
When the next hop to a destination node changes, the node will generate a
triggered notification message. The triggered notification message will update
SAV tables and SAV graphs in nodes along the new path. When receiving a
triggered notification message, the node first updates its SAV graph. Then, it
not only maps the source prefixes of the origin node to the incoming port but
also maps the source prefixes of the origin node’s descendant nodes in the SAV
graph to the same incoming port. In this way, the node immediately updates the
incoming port for both the origin node as well as its descendant node. The
descendant node will not generate triggered notification message if it still
has the same next hop to the destination node. In this way, we can enable a
faster convergence and reduce the number of triggered notification messages
when updating.
We are also considering introducing an aging mechanism for SAV tables and SAV
graphs. They can expire unless updated with repeated notification messages.
This operation can mitigate inconsistency problem in the case of transient
route behaviors.
Best,
Lancheng
-----原始邮件-----
发件人:Xingang <[email protected]>
发送时间:2022-05-06 12:46:15 (星期五)
收件人: "Dan Li" <[email protected]>
抄送: [email protected], [email protected]
主题: Re: [savnet] Regarding reusing existing routing protocols for SAV//RE:
SAVNET WG charter
Glad to see the SAVNET WG charter.
One particular concern of mine is about the performance difference of using
routing protocols to distribute SAV information between intra- and
inter-domain. IMHO, in inter-domain, there is not only a scalability issue
(e.g., more prefixes, more updates, etc.) , but also an even more serious and
fundamental issue - consistency.
SAV needs more accurate dataplane information than forwarding, since the former
cares about which interface data packets enter, while the latter often does not
care which interface data packets leave. So the consequence caused by
information inconsistency is greater for SAV than for forwarding. Many normal
path changes, even before their convergence, will not cause a connectivity
problem in forwording packets to their destinations, but will/may cause
filtering problems. This inconsistency will be magnified in the inter-domain
environment, where we have more frequent path changes, but slower protocol
convergence (w.r.t BGP/IGP). Is it possible that the information distribution
of SAV info via BGP will never catch up with path changes, and always lead to a
wrong filtering? Is it better to use SAV over BGP for more specific scenarios
or in a more limited scope? Maybe the emulation platform can take this factor
(as well as realworld statistics) into account and give us some preliminary
results.
Thx.
Xingang
-----原始邮件-----
发件人:"Dan Li" <[email protected]>
发送时间:2022-05-06 08:58:11 (星期五)
收件人: "'虞红芳'" <[email protected]>,
[email protected]
抄送: [email protected], [email protected]
主题: Re: [savnet] Regarding reusing existing routing protocols for SAV//RE:
SAVNET WG charter
Thank Hongfang for the work. Actually, the idea of prefix notification based
control-plane solution is not new. Prof. Lixia Zhang’s group had proposed such
a solution before and published the paper in INFOCOM. The basic idea is that
each router sends a notification packet to every destination prefix in its FIB
table. We can imagine that the potential number of protocol messages is huge,
which made the protocol not scalable. And this solution requires modifying the
data-plane behavior of intermediate routers, because each router has to deliver
the packet to the control plane and updates the SAV table.
In our currently proposed control-plane solution, we use a different way. Every
router/AS only sends the notification message to its neighboring router/AS,
while containing the destination prefixes in its FIB as the payload, which we
call the “propagation scope” field. The “propagation scope” field will be
changed hop-by-hop to control the scope of the notification message. This
method not only significantly improves the scalability of the prefix
notification based approach (theoretically every router/AS only receives O(N)
messages if there are N routers/ASes in the network), but also works only in
control plane, without changing the data-plane behavior of the routers.
The results from your emulation platform echoes our design rationale. We also
hope that you can publish it to the community, or show them in the meeting of
this potential WG.
Best,
Dan
发件人: [email protected] <[email protected]> 代表 虞红芳
发送时间: 2022年5月5日 20:12
收件人: [email protected]
抄送: [email protected]; [email protected]
主题: Re: [savnet] Regarding reusing existing routing protocols for SAV//RE:
SAVNET WG charter
This is Hongfang Yu from University of Electronic Science and Technology of
China. I agree with forming a working group by focusing on the control-plane
solution. It would be a good idea to start from intra-domain case and then go
to inter-domain case, because the inter-domain solution may depend on
intra-domain solution.
My team in UESTC has developed a platform for large-scale network emulations.
Our preliminary results show that the currently proposed approach by Tsinghua
team has high scalability. The algorithm design can significantly reduce the
number of protocol messages.We also plan to make our emulation platform public
to the community in the near future.
Best,
Hongfang
-----原始邮件-----
发件人:Lizhenbin <[email protected]>
发送时间:2022-05-05 00:42:09 (星期四)
收件人: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
抄送:
主题: [savnet] Regarding reusing existing routing protocols for SAV//RE: SAVNET
WG charter
Hi Dan and all,
In order for convenience, I directly put the text of the charter in the mail.
I understand the importance of reusing existing routing protocols for SAV which
is described in the charter. But I truly have doubt about it. The following is
some thinking:
1. SAV in inter-domain networks: because BGP is the only existing routing
protocol for inter-domain networks, does it mean BGP is determined for SAV in
inter-domain networks? Because the information distributed for SAV is different
from the existing information distributed by BGP, is it appropriate to take use
of BGP for SAV? If it is necessary to evaluate it, where is the work to be
done, in the SAVNET WG or in the IDR WG?
2. SAV in intra-domain networks: 1) The first issue is the similar as BGP. Are
the existing IGPs appropriate for SAV in intra-domain networks? How to evaluate
and where to evaluate? 2) There are multiple types of IGPs, ISIS, OSPFv2 and
OSPFv3. If IGP can be used for the SAV, do we extend all these IGPs or only
choose one? 3) There is also RIFT and BGP SPF as IGPs. Will RIFT WG and LSVR WG
also be involved besides LSR WG?
3. For both SAV in inter-domain networks and in intra-domain network, how many
existing routing protocols should be extended? BGP + One or more IGPs? BGP for
both inter-domain and intra-domain since BGP-SPF can also be used for
intra-domain?
Best Regards,
Robin
Charter for SAVNET Working Group:
Source address validation (SAV) is important to mitigate source address
spoofing attacks. To improve the effectiveness, SAV mechanisms should be
applied as close to the source as possible. Therefore, it is desired to deploy
SAV in both intra-domain and inter-domain networks. However, existing SAV
mechanisms like uRPF-related technologies may improperly permit spoofed traffic
or improperly block legitimate traffic.
The “Source Address Validation in Intra-domain and Inter-domain Networks
(SAVNET)” working group will define a protocol-independent architecture and
procedures to overcome the limitations of existing SAV mechanisms.
Specifically, the SAVNET WG will define procedures that allow nodes to
accurately determine valid incoming ports for specific source prefixes taking
into account information not currently included in routing protocols.
The scope of the SAVNET WG includes the SAV function in both intra-domain and
inter-domain networks, and the validation of both IPv4 and IPv6 addresses. The
WG is expected to address intra-domain solutions first. SAVNET should avoid
packet modification in the data plane. Where possible, existing control and
management plane protocols must be used within existing architectures to
implement the SAV function. Any modification of or extension to existing
architectures, or control or management plane protocols, must be done in
coordination with the working groups responsible for the architecture, or
control or management plane protocol.
The SAVNET WG is chartered for the following list of items:
1) Description of problem statement and use cases for SAVNET, including the
requirements that need to be taken into account by the SAVNET architecture.
2) Definition of SAVNET architecture and new procedures. This includes both
intra-domain and inter-domain networks.
3) Definition of operation and management mechanisms needed to operate and
manage SAV-related configurations.
4) Solutions to implementing SAVNET architecture by defining extensions of
existing routing protocols. These will be done in coordination with the WGs
supervising those protocols.
The SAVNET WG will coordinate and collaborate with other WGs as needed.
Specific expected interactions include (but may not be limited to): lsr and idr.
From: Dan Li [mailto:[email protected]]
Sent: Monday, May 2, 2022 11:30 PM
To:[email protected]
Cc: Lizhenbin <[email protected]>; [email protected]
Subject: RE: [savnet] SAVNET WG charter
Thank Robin for the remind. I am sending this email to colleagues in the RTGWG
to introduce the SAVNET work.
In IETF 113, we held the SAVNET BOF in the INT Area , with a focus on
intra-domain and inter-domain source address validation (SAV) technologies. The
basic motivation is to overcome the problem of improper block or improper
permit in uRPF-based SAV mechanisms. A control-plane solution was presented in
the BoF. The basic idea is: 1) each node notifies its attached source prefixes
along the real forwarding path, and the routers along the path accordingly
build the correct SAV table; 2) the notification messages are processed in the
control-plane via a hop-by-hop manner, and various methods are used to reduce
the message overhead; 3) following the routing architecture, the notification
is divided into an intra-domain part and an inter-domain part. Given that this
solution is highly related to routing architecture, after the BoF it was
suggested to apply for a WG in the Routing Area.
More materials of the BOF can be found from
https://datatracker.ietf.org/meeting/113/materials/agenda-113-savnet-01.
Enclosed please find the drafted WG charter, which will be improved based on
the feedback we get from the community.
I also hope that RTGWG colleagues who have interest in this topic can join the
SAVNET mailing list (https://www.ietf.org/mailman/listinfo/savnet), which will
be the main channel for future discussions.
Best,
Dan
发件人: Lizhenbin <[email protected]>
发送时间: 2022年5月2日 17:34
收件人: Dan Li <[email protected]>; [email protected]
主题: RE: [savnet] SAVNET WG charter
Hi Dan,
Since the BOF was held in the INT area, maybe not all of the experts from the
RTG area register the mailing list of SAVNET and they are not aware of the work.
I suggest you could forward it to the mailing list of RTGWG and briefly
introduce the design concept and progress of the SAVNET work.
Best Regards,
Zhenbin (Robin)
From: savnet [mailto:[email protected]] On Behalf Of Dan Li
Sent: Thursday, April 28, 2022 4:50 PM
To:[email protected]
Subject: [savnet] SAVNET WG charter
Dear colleagues,
One month has passed since the SAVNET BOF in IETF 113. In the IESG/IAB meeting,
it was concluded that the problem is well-defined and was suggested that SAVNET
be moved to the Routing Area.
After discussing with the ADs in the Routing Area, we decide to apply for
forming a WG with a relatively narrower scope. Specifically, the potential WG
will focus on intra-domain and inter-domain SAV mechanisms by extending
existing routing protocols.
Enclosed please find the drafted WG charter. We would like to get the feedback
from our community.
Best,
Dan
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
