[savnet] Re: Ketan Talaulikar's Discuss on draft-ietf-savnet-intra-domain-problem-statement-23: (with DISCUSS and COMMENT)

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Ketan, Joel, and all,

This is an updated version my previous post. It benefits from a side discussion with Joel.

Upon further reflection, the concept of 'interface' has remained a cornerstone of SAV work within this Working Group, consistent with its historical role in SAV development. I think that Joel and Lancheng were also pointing this out.

Hence, I would like to suggest the following further refinement of Ketan’s definitions:

-----------
Intra-domain SAV: The AS validates source addresses in data traffic it originates directly or indirectly (e.g., from a subnet of a customer with no AS). Intra-domain SAV is applied on traffic originating on interfaces (on AS border routers) on which (a) a single host or a set of hosts are connected, or (b) a customer with no AS or without a public AS – managing one or more subnets – is connected.
-----------
Inter-domain SAV: The AS validates the source addresses of data traffic received from a neighboring AS, whether that traffic originated within the neighbor's network or is being transited through it. Inter-domain SAV is applied to incoming traffic on external interfaces (on AS border routers) that interface directly with a neighboring AS.
-----------

In the above, a subnet means a set of endpoints (users, servers) served with addresses in an IP prefix.

I think these refined definitions are consistent with Ketan’s advice for making the definitions protocol agnostic and at the same time do not impact (or minimally impact) the current structure of the two PS drafts. Do these definitions seem reasonable?

Sriram
----------------------------

From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Friday, April 17, 2026 2:18 AM
To: Lancheng <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] [savnet] Re: Ketan Talaulikar's Discuss on draft-ietf-savnet-intra-domain-problem-statement-23: (with DISCUSS and COMMENT)

Hi Lancheng/SAVNET WG,

This document covers Gap Analysis, Problem Statement and Requirements. The WG is working on a separate document for the Architecture.

Therefore, framing the problem space around interfaces to which SAV rules should be applied for intra-domain seems problematic and suggests a preconceived solution or approach.

Let me offer an alternative view for your and the WG consideration:

Networks on the Internet are organized as Autonomous Systems (ASes); each AS has its own allocated IP address space. Routing handles advertising reachability between IP endpoints within and across these ASes.

Intra-domain SAV: These are techniques and mechanisms where an operator validates the source address for traffic originating from their AS. Here, the source address validation applies to the IP address space of that operator's AS.

Inter-domain SAV: These are techniques and mechanisms where an operator validates the source address for traffic originating from other ASes and either transiting their AS or terminating within their AS. Here, the source address validation applies to the IP address space of other ASes on the Internet.

This definition is protocol agnostic. Do you agree with this?

Next is the description of Intra-domain SAV scenarios. This can also be defined in a protocol agnostic manner as follows:
a) Internal Use: A portion of the IP address space can be allocated to a set of servers (e.g., in a data center), to a department within an Enterprise network, or to a region within a Service Provider network
b) Customer Use: A portion of the IP address space allocated or delegated for use by a customer receiving Internet connectivity service; this could be via various designs
    * Connected via broadband, Ethernet, or such service
    * The routing on the Customer-Provider interface could be static, an IGP, or eBGP with a private AS

For intra-domain, the SAV rules are expected to be applied at a suitable edge in the network. Where this edge lies depends on the demarcation boundary that is picked based on various factors and is perhaps something for the architecture.

For (b), it may be the UNI interface between the customer and the provider. For (a), the approach could vary based on the design. For servers in DC, this could be done at the server-to-TOR interface or at the DCI nodes, depending on the security and scaling requirements. For between departments/regions, it could again be at every host-to-router interface or could be done at IGP domain boundaries when the regions and departments are organized as separate IGP domains (or OSPF areas or ISIS L1s). The "edge" varies; it could be a host-to-router link or border routers. But hopefully not within the IGP domain as that can become very problematic and challenging.

Much of the design approach belongs in the architecture document.

Similarly, the source of the SAV rules for complex cases (e.g., hidden prefixes) may involve various mechanisms, such as a management interface, BGP Internet Routing info, or others. However, the presence of a hidden prefix from a different address space does not change the scenario from intra-domain to inter-domain.

In summary, I find the association of everything BGP to be inter-domain and everything non-BGP to be intra-domain to be very problematic and, in my opinion, flawed.

Please check inline below for more specific responses, and I hope the above provides a clearer overview.

…. snip ….