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

[Ketan Talaulikar <[e-mail]>]

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.


On Thu, Apr 16, 2026 at 9:07 PM Lancheng <[e-mail]> wrote:

> Hi Ketan,
>
> Thank you for the response. The difference here might come from looking at
> the problem from two different perspectives. We agree with you that address
> ownership is the right abstraction to reason about prefix
> advertisement/origination and routing. However, we look at the problem from
> a slightly different view, i.e., how to scope SAV deployment problems at
> domain boundaries, where SAV is enforced per interface.
>
>
> Within SAVNET WG, there has been discussion that intra-domain SAV focuses
> on external interfaces of a domain, rather than internal ones [1]. This is
> mainly because:
>
> 1) Internal routers are generally assumed to be trusted, so SAV
> enforcement inside the domain has limited benefit when we have SAV
> enforcement on the domain boundary
>
> 2) Techniques like LFA / fast reroute make SAV at internal interfaces
> technically challenging
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/savnet/jGeQ-JMdhT_GvZmVk4pZy0ZMhds/
>
>
>
KT> This aligns with what I've described. Also, I note the emphasis on what
the "edge" is in Joel's email.


> As a result, both intra-domain and inter-domain SAV are defined around
> external interfaces. During WGLC discussions, the WG explored how to better
> separate the problem space into two non-overlapping parts. One practical
> approach that emerged (and was discussed on the mailing list) is [2,3]:
>
> 1) SAV at external interfaces facing eBGP peers --> inter-domain SAV
>
> 2) SAV at external interfaces not facing eBGP peers --> intra-domain SAV
>
>
> [2]
> https://mailarchive.ietf.org/arch/msg/savnet/OcMrDLUFHgiBIRRyA4SMZr-kp6M/
>
> [3]
> https://mailarchive.ietf.org/arch/msg/savnet/5ydXaHjR2-n3jRyLOIWKIzdcNzQ/
>
>
>
KT> Does any of this contradict what I've described? The concept is the
same; I only have an issue with the BGP/non-BGP terminology used to
distinguish between inter/intra-domain SAV. I don't understand how non-BGP
customers can advertise their own IP address space (along with AS, ROA,
ASPA, etc.) to their providers. Non-BGP works easily when the provider
delegates a portion of their address space to the customer. At the same
time, not all eBGP peerings are inter-AS when the customer uses a private
AS to peer with its provider. Likely I am missing something and would
appreciate clarification or correction.


> The main reason for this distinction is not to redefine inter-domain vs
> intra-domain in a routing sense, but to reflect that:
>
> 1) Interfaces facing eBGP peers can leverage BGP UPDATE from eBGP peers
>
> 2) Interfaces not facing eBGP peers lack these signals, and therefore may
> require different SAV mechanisms
>
>
> So this classification is intended as an operational scoping tool for SAV
> mechanisms, rather than a statement about routing and prefix origination
> semantics.
>
>
> We also have some concerns about using address ownership alone to classify
> SAV problems at interfaces. For example:
>
>
> Consider an external interface connecting to a set of hosts which of
> course does not have an ASN. The operator assigns addresses to these hosts
> from its own address space. However, a host may legitimately use an address
> that is not assigned by the operator (as described in hidden prefix
> scenarios). In this case:
>
>
>   From an address ownership perspective, traffic on the same interface may
> use:
>
>     1)source addresses belonging to the operator (intra-domain address
> spacce)
>
>     2)source addresses belonging to another operator (inter-domain address
> space)
>
>   From an interface enforcement perspective, this is still a single SAV
> problem at one interface.
>

KT> This is orthogonal to BGP/non-BGP. But this covers the address space.
The operator does not manage the hidden prefix address space. So, this
scenario is still intra-domain because that is how the routing is set up.
This is why the base IP address space allocation and its routing become the
determining factor between inter/intra - not the choice of protocol.


>
> That said, this leads to ambiguity that the classification of SAV at the
> same interface would change depending on the traffic observed.
>

KT> Aren't we jumping into the solution or architecture here? This document
does not need to detail a solution. The terminologies and scenarios must be
accurate to drive the correct approaches in the architecture and solution.
By presumptively saying that SAV rules apply to an interface, is the WG
ruling out the approach where SAV rules can be applied at a border router
(e.g., DCI or ABR)?

KT> For inter-domain SAV, where we have a lot of prior art, applying SAV at
an inter-AS link makes sense. I wonder if the same approach applies to
intra-domain scenarios where the number of host-to-router links is of a
significantly higher order.

Thanks,
Ketan


>
> How do you think?
>
>
> Best,
>
> Lancheng and co-authors
>
>
>
>
> -----Original Messages-----
> *From:* "Ketan Talaulikar" <[e-mail]>
> *Send time:* Wednesday, 15/04/2026 20:52:21
> *To:* Lancheng <[e-mail]>
> *Cc:* "The IESG" <[e-mail]>,
> [e-mail],
> [e-mail], [e-mail], [e-mail]
> *Subject:* Re: [savnet] Ketan Talaulikar's Discuss on
> draft-ietf-savnet-intra-domain-problem-statement-23: (with DISCUSS and
> COMMENT)
>
> Hi Lancheng,
>
> Thanks for your quick response. Please see inline comments for
> clarifications.
>
> I seem to have some fundamental disconnects regarding some key
> terminologies and their meanings. Please correct me if I am wrong or
> missing something.
>
>
> On Wed, Apr 15, 2026 at 5:13 PM Lancheng <[e-mail]> wrote:
>
>> Hi Ketan,
>>
>> Thank you for the detailed comments. Please find our responses inline
>> below.
>>
>> Best,
>> Lancheng and co-authors
>>
>>
>> > ----------------------------------------------------------------------
>> > DISCUSS:
>> > ----------------------------------------------------------------------
>> >
>> > Thanks to the authors and the WG for their work on this document.
>> >
>> > Since this document is driving the architecture and solution work for
>> > intra-domain SAV, there are some basic premises in this document that I
>> would
>> > like to discuss. My intention is to arrive at very precise scope of
>> > intra-domain SAV and not to mix up inter-domain SAV that is using BGP
>> and
>> > between ASes.
>> >
>> > <discuss-1> What exactly is a non-BGP ISP and a non-BGP Customer?
>> >
>> > I am missing how this ties up with prefix advertisement/origination and
>> > routing. BGP has a very specific and important function for prefix
>> > advertisement and routing over the Internet. Can these functions be met
>> by
>> > "non-BGP" routing? If, so, how are these prefixes getting advertised
>> further to
>> > the Internet?
>>
>> [Lancheng:] We would like to clarify that the term "non-BGP" in this
>> document refers
>> to an interface property. Specifically, it denotes that the interface
>> between two
>> connected networks does not run eBGP (e.g., using static routing). It
>> does not imply
>> that either network does not use BGP elsewhere.
>>
>
> KT> Looking at this from an interface property seems problematic.
> Customers use BGP to connect to their ISPs because they can also advertise
> their own AS and IP space. I am not sure if this can be done through other
> (non-BGP) means. At the same time, some customers use BGP to connect to
> their ISPs even without their own AS or IP Space for dual homing and
> redundancy. So, BGP or non-BGP is not the defining aspect here. I am having
> trouble understanding why an interconnect to an ISP is an intra-domain
> problem. Simply, calling it non-BGP does not change it from inter-domain to
> intra-domain. More importantly, I want us to ensure that IETF RFCs do not
> provide incorrect ideas and concepts to readers.
>
>
>> For a domain, a non-BGP external interface may connect to:
>>
>> * a set of hosts; or
>>
>> * a customer network that does not establish an eBGP session at the
>> interconnecting
>> interface (referred to as a "non-BGP customer network" in this
>> document); or
>>
>> * an upstream network that does not establish an eBGP session at the
>> interconnecting
>> interface  (referred to as a "non-BGP ISP network" in this document).  In
>> such cases,
>> prefixes associated with this domain are advertised to the Internet by
>> the upstream network.
>>
>
> KT> It is not about the interface. It concerns the prefixes (of the hosts,
> customer, downstream network). Who owns that address space, how it is
> managed, which AS it belongs to, and how it is advertised over the Internet
> indicates whether it is intra-domain or inter-domain. For example, say I am
> an ISP and I've given some of my address space to a customer that does not
> have their own AS. This customer sets up eBGP peering with me using a
> private ASN just to get the full Internet table. Do we characterize this as
> inter-domain (just because it is eBGP) or intra-domain (since that address
> space is mine)? Another similar customer who only wants the default route
> for the Internet may use static routing or OSPF.
>
>
>>
>> >
>> > 154        Non-BGP Customer Network: A stub network (i.e., a network
>> that only
>> > 155        originates traffic) connected to its provider network for
>> Internet
>> > 156        connectivity and does not participate in eBGP peering with
>> its
>> > 157        provider network.
>> >
>> > "originates traffic" is misleading as this network is connected to the
>> > Internet, the application session maybe initiated from within or to this
>> > network. Further, once the application session starts, traffic goes
>> both ways.
>>
>> [Lancheng:] We agree that "originates traffic" is misleading and will
>> remove the text.
>>
>> > Is the intention here to characterize a network that does not have its
>> own
>> > public IP prefixes and instead it uses IP from its provider's prefix
>> pool? As
>> > such, the prefixes for this network are announced by its ISP (or
>> upstream
>> > provider).
>>
>> [Lancheng:] In general, yes. However, this is not a defining assumption
>> of the taxonomy
>> in this document. It is just based on whether an eBGP session is
>> established
>> at the interconnecting interface facing a customer network.
>>
>
> KT> Well, it seems like this is becoming the defining taxonomy for the WG
> when discussing intra-domain SAV. I had a quick glance
> at draft-ietf-savnet-intra-domain-architecture and it heavily uses these
> terminologies. Therefore, precision and correctness are very important not
> just for this document but for the work-in-progress as well.
>
>
>>
>> >
>> > 159        Non-BGP Internet Service Provider (ISP) Network: A network
>> that
>> > 160        forwards traffic from its customer network to the Internet
>> and does
>> > 161        not participate in eBGP peering with its customer network.
>> >
>> > Here as well, "forwards traffic" is misleading. Is this a network that
>> > has its own IP Prefixes but is not using eBGP peering to announce it;
>> its
>> > prefixes are instead announced to the provider via other protocols? I
>> am not
>> > sure about this and whether such a practice is prevalent. How are its
>> AS and
>> > ROAs done without BGP?
>>
>> [Lancheng:] We clarify that "forwards traffic" was intended to describe
>> that
>> the ISP provides IP connectivity between its customers and the Internet.
>> "Non-BGP"
>> refers to the absence of an eBGP session at the interconnecting interface
>> between
>> the ISP and a customer network. For example, they use static routing.
>> From the
>> perspective of the customer network, such an ISP is referred to as a
>> "non-BGP ISP"
>> in this document.
>>
>
> KT> So, there is no discussion about the IP address space of such
> customers. The space indicates the source addresses to be validated. Does
> that IP space belong to the ISP or the customer? If it is the former, this
> is intra-domain SAV for the ISP, if it is the latter, this is inter-domain
> SAV for the ISP. I would almost always expect eBGP to be the protocol used
> for the latter (otherwise things like ROAs and ASPA which we want everyone
> to adopt, could run into trouble?) while the former can be something else.
>
>
>>
>> >
>> > The "a set of hosts" or more broadly segments of a network that have
>> their own
>> > IP subnets carved out from that network operators address space (all
>> within an
>> > AS) is something that I can understand. These are "leaf or stub"
>> networks.
>> > The other two, I am not able to follow.
>>
>> [Lancheng:] We agree that the current terminology and definitions are
>> misleading,
>> and we will improve the clarity in the next revision.
>>
>
> KT> Instead of trying to define terminologies around BGP/non-BGP, please
> look at it from the perspective of AS, IP address space management, and
> prefix advertisement purposes. Ultimately, that address space is used for
> source validation. It becomes intra-domain or inter-domain depending on
> whether the IP space belongs to a single AS or if it involves an inter-AS
> peering scenario.
>
>
>>
>> >
>> > <discuss-2> What is a "timely manner"?
>> > 448     4.4.  Fast Convergence
>> >
>> > 450        If any new intra-domain SAV mechanism requires disseminating
>> SAV-
>> > 451        specific information among intra-domain routers via a
>> protocol, two
>> > 452        considerations are essential.  First, such mechanism MUST
>> allow
>> > 453        routers to learn updated SAV-specific information in a
>> timely manner.
>> > 454        Second, such mechanism MUST NOT transmit excessive
>> SAV-specific
>> > 455        information via a protocol, as this could significantly
>> increase the
>> > 456        burden on the routers’ control planes and potentially
>> degrade the
>> > 457        performance of existing protocols.
>> >
>> > Is this on the lines of normal IGP convergence which is generally order
>> of a
>> > few seconds? Or is it fast convergence in IGPs that is expected to be
>> order
>> > of sub-seconds? Or is it fast-reroute/LFA that is expected to order of
>> > sub-50msec? These timings are dependent on implementation and also to an
>> > extent the scale and other deployment aspects.
>> >
>> > How about saying something on the lines that the SAV mechanisms MUST NOT
>> > affect IGP convergence and the functioning of LFA/fast-reroute in the
>> network?
>>
>> [Lancheng:] The term “timely manner” was intended to capture the general
>> requirement
>> that SAV-specific information should be propagated sufficiently quickly
>> to reflect
>> network changes and avoid prolonged inconsistency in SAV decisions. Our
>> intention
>> was not to prescribe specific timing requirements, as these are highly
>> dependent
>> on implementation, deployment scale, and operational considerations.
>>
>> We agree with your suggestion and will revise the text to clarify that
>> any new
>> intra-domain SAV mechanism MUST NOT adversely affect IGP convergence or
>> the operation
>> of fast-reroute mechanisms (e.g., LFA).
>>
>
> KT> Thanks.
>
>
>>
>> >
>> > <discuss-3> What about the requirement that SAV solution MUST work when
>> > LFA/fast-reroute is deployed and operational in a network and MUST
>> coexist
>> > with it. This probably makes the application of the SAV rules only on
>> the
>> > edges (non-IGP adjacencies) and not on internal IGP adjacencies?
>>
>> [Lancheng:] We agree that compatibility with IGP fast convergence and
>> fast-reroute
>> (e.g., LFA) is important. WG discussions and consensus also suggested to
>> focus only
>> on domain-edge deployments, which motivates this requirement.
>>
>> However, given that the revised "fast convergence" requirement already
>> states
>> that SAV mechanisms must not adversely affect IGP convergence or
>> fast-reroute
>> mechanisms, we would like to check whether this already sufficiently
>> covers the
>> intended LFA/FRR coexistence requirement, or whether it is preferred to
>> keep an explicit separate requirement for FRR/LFA coexistence.
>>
>
> KT> The additional part (besides the change for discuss-2) would be to
> clarify that the SAV filtering and rules will not break or misbehave with
> flows while they are under fast-reroute. Capturing the WG discussion
> regarding the application of SAV rules only at the edge would greatly guide
> the solutions correctly.
>
>
>>
>> >
>> >
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> > I also have one comment.
>> >
>> > 348   3.2.  Hidden Prefix Scenario
>> >
>> > 350      The intra-domain hidden prefix scenario refers to situations
>> in which
>> > 351      a host or non-BGP customer legitimately originates traffic
>> using
>> > 352      source addresses that are not visible to the intra-domain
>> routing
>> > 353      protocol within the domain.
>> >
>> > 355      *  A host (for example, a cloud server instance operated by a
>> tenant)
>> > 356         may originate traffic using a source address not allocated
>> by the
>> > 357         AS operator.  This can occur in deployments such as Direct
>> Server
>> > 358         Return (DSR), where return traffic is sent directly from the
>> > 359         server using a service IP address that is not part of the
>> > 360         operator’s internal routing view.
>> >
>> > <major> Please provide an informative reference for DSR. I would suggest
>> > draft-ietf-sidrops-bar-sav even if it is describing this technique in
>> the case
>> > of inter-domain which AFAIK is the widely prevalent use. Is there any
>> evidence
>> > of DSR being used in non-BGP deployments?
>>
>> [Lancheng:] DSR is used by a content server (i.e., an end host) to
>> respond using
>> an anycast IP address. In the context of intra-domain deployments, such a
>> server actually
>> reside in a set of hosts that is reachable via a non-BGP external
>> interface.
>> Therefore, we believe DSR is a suitable example for the intra-domain
>> hidden prefix scenario.
>>
>> DSR is a mechanism commonly used in networking practice.
>> draft-ietf-sidrops-bar-sav
>> describes DSR rather than formally defining it. We have attempted to
>> identify a
>> document that explicitly defines DSR, but were unable to find a canonical
>> reference.
>> We would appreciate any suggestions for suitable informative references,
>> if available.
>>
>
> KT> I pointed to the bar-sav draft since it gives a better description in
> my view. That said, I will leave this to the authors.
>
> Thanks,
> Ketan
>
>
>>
>> >
>> >
>> >
>> > --
>> > savnet mailing list -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>>
>> Thanks again for your comments!
>>
>