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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Lancheng,

Thanks for your patience (and the gentle reminder -- BTW, never hesitate to poke an AD 😊 )

See in-line for EV>

Regards

-éric

From: Lancheng <[e-mail]>
Date: Wednesday, 29 April 2026 at 04:13
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Re: Éric Vyncke's Discuss on draft-ietf-savnet-intra-domain-problem-statement-23: (with DISCUSS and COMMENT)

Hi Éric,

Thank you again for your DISCUSS and COMMENTs on draft-ietf-savnet-intra-domain-problem-statement.

We have revised the draft based on our response to your DISCUSS. The latest working version is available at:
https://github.com/SAVNET-ProblemStatement-Architecture/Intra-domain-problem-statement/blob/address-ad-discuss/draft-ietf-savnet-intra-domain-problem-statement-23.md

Specifically, we added a description of DSR in the Terminology section:
https://github.com/SAVNET-ProblemStatement-Architecture/Intra-domain-problem-statement/commit/851fd6b737453f47a96625170e95bacae81c3086

For your other DISCUSS points, we provided clarification in our earlier response:
https://mailarchive.ietf.org/arch/msg/savnet/l20SuvsP-i5LBX6j0i7A7dK6owc/

We also revised the draft based on your COMMENTs:
https://github.com/SAVNET-ProblemStatement-Architecture/Intra-domain-problem-statement/commit/41c7fe2cef9bda3a91f2571ba8502fb31f19fafa

Could you please let us know whether these clarifications and revisions address your concerns?

Best regards,
Lancheng and co-authors


> -----Original Messages-----
> From: Lancheng <[e-mail]>
> Send time:Friday, 17/04/2026 13:07:46
> To: "Éric Vyncke" <[e-mail]>
> Cc: "The IESG" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
> Subject: Re: Éric Vyncke's Discuss on draft-ietf-savnet-intra-domain-problem-statement-23: (with DISCUSS and COMMENT)
>
> Hi Eric,
>
> Thank you for your detailed review. Please find our response inline below.
>
> For your non-blocking comments, we will incorporate the suggested wording and editorial improvements in the next revision.
>
> Thanks,
> Lancheng and co-authors
>
>
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> >
> > # Éric Vyncke INT AD comments for
> > draft-ietf-savnet-intra-domain-problem-statement-23 CC @evyncke
> >
> > Thank you for the work put into this document. As you will read below, it needs
> > some work, but I do not mind its publication as an informational RFC.
> >
> > Please find below some blocking DISCUSS points (easy to address), some
> > non-blocking COMMENT points/nits (replies would be appreciated even if only for
> > my own education).
> >
> > Special thanks to Xueyan Song for the shepherd's write-up including the WG
> > consensus and the justification of the intended status.
> >
> > I hope that this review helps to improve the document,
>
> [Lancheng:] Thank you. It is helpful.
>
> >
> > Regards,
> >
> > -éric
> >
> > Note: this ballot comments follow the Markdown syntax of
> > https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
> > a tool to create github issues.
> >
> > ## DISCUSS (blocking)
> >
> > As noted in
> > https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
> > a DISCUSS ballot is a request to have a discussion on the points below; I
> > really think that the document would be improved with a change here, but can be
> > convinced otherwise.
> >
> > ### Intra or inter domain ?
> >
> > I find the title and some of the text confusing about intra-domain and
> > inter-domain. My assumption when reading 'intra-domain' would have been to
> > enforce SAV *inside* a domain and not at the *perimeter* of a domain. The
> > introduction does not really help the reader to understand the problem scope.
>
> [Lancheng:] We would like to provide some background. The SAVNET WG has conducted extensive
> discussions on the deployment location of intra-domain SAV. Following extensive WG discussions
> across SAVNET and LSR WGs, intra-domain SAV in this document is scoped to 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
>      provides limited additional benefit when enforcement is already applied at the domain boundary
>   2. Techniques such as LFA or fast reroute make SAV at internal interfaces technically challenging
> [1] https://mailarchive.ietf.org/arch/msg/savnet/jGeQ-JMdhT_GvZmVk4pZy0ZMhds/
>

EV> the above explain the motivations for this I-D (and they are good), but the abstract
EV> and the title are still heavily confusing with "intra-domain"

> We will revise the document and try to clarify the scope more explicitly.
>

EV> Please do, and let me know when a revised I-D is submitted.


> >
> > ### Section 1
> >
> > `The goal of intra-domain SAV at such interfaces is to prevent traffic using
> > unauthorized source addresses from entering the domain` is too vague. By whom
> > is it unauthorized ? I.e., allocated to an intra host or ?
>
> [Lancheng:] Thank you for the comment. In this document, “unauthorized source addresses” refer to
> source addresses that are not authorized by the legitimate holder of the IP address space. In other words,
> authorization is defined with respect to the intended use of the address space by its address holder, and
> SAV mechanisms aim to detect and prevent the use of source addresses that are not consistent with that authorization.
>
> >
> > ### Section 3.2
> >
> > An informative reference for `This can occur in deployments such as Direct
> > Server Return (DSR)` will be useful. Honestly, I have no clue what it is about.
>
> [Lancheng:] We agree that an informative reference would be helpful for clarifying Direct Server Return (DSR).
> We are currently looking for an appropriate definition or reference. As suggested by Ketan, the description in draft-ietf-sidrops-bar-sav
> appears to be a useful reference, and we will consider aligning with it and adding a brief explanation of DSR in an appendix if appropriate.

EV> a reference to another draft would be enough.

>
> >
> > `Existing uRPF-based mechanisms (strict uRPF or loose uRPF)` but what about
> > feasible path uRPF ?
>
> [Lancheng:] We consider feasible-path uRPF and enhanced feasible-path uRPF as inter-domain SAV mechanisms because, as described in their RFCs,
> they rely on alternative routing paths learned via eBGP UPDATE messages from external BGP neighbors. Therefore, this document does not analyze them.
> In addition, based on discussions with operators and vendors during the preparation of this document, there is no consistent operational practice for their use
> for intra-domain SAV.
>

EV> this brings back to the term "intra-domain SAV", which is not clearly defined in the document though.
EV> Adding a text similar to your reply in the I-D, can be useful for the reader.

> >
> >
>