Hi Lancheng,
I know you are presenting this tomorrow in LSR. I finally reviewed this draft
and have the following comments.
1. The concept of "sub network" is confusing. Why don't you just use "IGP
routing domain"? Also, why do you say that a "sub network" cannot carry transit
traffic? I know transit traffic (not tunneled) is uncommon but isn't prohibited
- is this just not a use case that isn't addressed since it isn't that common?
2. I think the problem statement should indicate that any solution
including IGP extensions should make them optional and allow for incremental
deployment.
3. I didn't fully understand the "hidden prefix" use case - I reviewed the
document on a plane w/o Internet access so I didn't try too hard.
With the respect to solutions, the draft only talks about the existing "strict
RPF" and "loose RPF". I think there could also be a combination of solutions to
address various use cases.
Thanks,
Acee
> On Jul 7, 2025, at 10:27 AM, Lancheng
> <[email protected]> wrote:
>
> Dear all,
>
> Jim wrote in [1]:
>> Additionally, we might want to consider splitting the document into two
>> parts:
>> 1. An informational document that outlines the use cases and identifies
>> technology gaps.
>> 2. A standards-track document that clearly defines the normative
>> requirements for solutions.
>> This separation could help clarify the document’s intent and ensure that any
>> future protocol work based on it has a solid and well-understood foundation,
>> without running into issues like downrefs or misinterpretation.
>
> To address this concern raised by Jim, we have added a clarification in
> Section 5 of this document to make it explicit that “These informational
> requirements can not be used to initiate standards-track protocol changes.
> Any protocol changes would require a standards-track requirements document,
> not a non-normative reference to this informational document.”.
>
> We believe this clarification resolves the concern raised, and we appreciate
> further review from the working group.
>
> Thanks,
> Lancheng
> (on behalf of the authors)
>
> [1] https://mailarchive.ietf.org/arch/msg/savnet/FppvNBPuodY84SFD5b6S-rGixKk/
>
>
>
>
>> -----Original Messages-----
>> From: [email protected]
>> Send time:Monday, 07/07/2025 22:05:50
>> To: [email protected]
>> Cc: [email protected]
>> Subject: [savnet] I-D Action:
>> draft-ietf-savnet-intra-domain-problem-statement-17.txt
>>
>> Internet-Draft draft-ietf-savnet-intra-domain-problem-statement-17.txt is now
>> available. It is a work item of the Source Address Validation in Intra-domain
>> and Inter-domain Networks (SAVNET) WG of the IETF.
>>
>> Title: Source Address Validation in Intra-domain Networks Gap Analysis,
>> Problem Statement, and Requirements
>> Authors: Dan Li
>> Jianping Wu
>> Lancheng Qin
>> Mingqing Huang
>> Nan Geng
>> Name: draft-ietf-savnet-intra-domain-problem-statement-17.txt
>> Pages: 16
>> Dates: 2025-07-07
>>
>> Abstract:
>>
>> This document provides a gap analysis of existing intra-domain source
>> address validation mechanisms, describes the fundamental problems,
>> and defines the basic requirements for technical improvements.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-savnet-intra-domain-problem-statement/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-savnet-intra-domain-problem-statement-17.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-savnet-intra-domain-problem-statement-17
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
>> --
>> savnet mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
> --
> savnet mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
