SAVNET-ProblemStatement-Architecture/Inter-domain-SAVNET-Architecture

42. Comments on the trustworthiness of communicated SAV-specific information

41. Comments on the guidance for conducting new potential SAV solutions

41. Comments on the guidance for conducting new potential SAV solutions

40. Comments on SAV-specific information and communication mechanism

40. Comments on SAV-specific information and communication mechanism

39. Comments on comparisons of different SAV-related information

39. Comments on comparisons of different SAV-related information

38. Comments on priority recommendations of SAV information sources

Aijun: In the architecture document, we should only provide some requirements for the solution to cover more specific scenarios in one general manner. (After IETF 120)

36. Aijun: Suggest the following revisions to make the descriptions understood more easily (Aijun): SAVNET operation /s SAVNET performance analysis, Inter-domain SAVNET provisioning /s Inter-domain SAVNET deployment provisioning, and explain them with detailed illustrations. (After IETF 120)

35. Aijun: There are proposals to use the controllers, but there is no such descriptions within the current architecture document. Should we consider to add the controller component within the architecture document? Then we can encompass all the possible solution together. (After IETF 120)

34. Alvaro: A neighbor discovery mechanism that is independent of existing protocols might be a non-starter in an inter-domain scenario...specially in cases where others may glean the information (IXPs, for example).

33. Alvaro: Using "effortlessly" to describe a technical outcome is not ideal: the amount of effort is relative to the operator's abilities, experience, the protocol, etc.

32. Alvaro: What does it mean to "ensure support for partial/incremental deployment"? I'm sure it doesn't mean that all the functions have to be supported (as we discussed above), so you might want to s/.../solution should consider partial/incremental deployments...

31. Alvaro: Assuming the cases above, how would AS1 become aware of a failure, for example, in the connectivity between the AS parallel to AS2 and ASX? It needs this information to update its SAV-specific messages.

30. Alvaro: As you well know, the operator can manually override the BGP decision. It is also possible to install a static route (which has no path information) pointing towards AS2. In this case, the path information could still be derived from BGP. You don't need a solution (yet) -- for this document all you need is to recognize that some cases may not work as expected until a wider deployment is achieved.

29. Alvaro: Figure 9 in Section 7.1 shows SAV-specific messages ("(P1, AS 2), (P6, AS 2)") that indicate <Prefix, Incoming Direction>. For the sample topology, how does AS1 know that AS2 will be the incoming direction from ASX's point of view? In the simple topology, it is relatively straight forward and AS2 is connected to both AS1 and ASX. But in more complex topologies it is not as easy; for example, consider another AS between AS1 and AS2, or between AS2 and ASX -- neither implementing the

29. Alvaro: Figure 9 in Section 7.1 shows SAV-specific messages ("(P1, AS 2), (P6, AS 2)") that indicate <Prefix, Incoming Direction>. For the sample topology, how does AS1 know that AS2 will be the incoming direction from ASX's point of view? In the simple topology, it is relatively straight forward and AS2 is connected to both AS1 and ASX. But in more complex topologies it is not as easy; for example, consider another AS between AS1 and AS2, or between AS2 and ASX -- neither implementing the

28. Alvaro: Figure 9 in Section 7.1 shows SAV-specific messages ("(P1, AS 2), (P6, AS 2)") that indicate <Prefix, Incoming Direction>. For the sample topology, how does AS1 know that AS2 will be the incoming direction from ASX's point of view? In the simple topology, it is relatively straight forward and AS2 is connected to both AS1 and ASX. But in more complex topologies it is not as easy; for example, consider another AS between AS1 and AS2, or between AS2 and ASX -- neither implementing the

26. Keyur: Does this cover a man-in-the-middle attack who can generate a prefix inside BGP With the right AS origin, but can hijack the path? I can take it to the mailing list for discussion.

25. Ben: Raise the same issue again. It uses RPKI based objects which is similar but not the same. That doesn't exist today. If this is deployed, it will jeopardize the use of RPKI in routing security. This is a big problem but not addressed. We need new signed objects. I'm happy to help but no one proposes it.

24. Aijun Wang: We need a component on the receiver to validate the received SAV-specific information.

23. Joel Halpern: A suggestion, not refer MD5.

22. Antoin Verschuren: How you can trust the ASes which send you information.

21. Yangyang Wang: As I understood, the SAV-specific messages are used to propagate the next incoming hops along real forwarding paths. In Section 4.2, in the statement "The SAV-specific message processor also checks the destination addresses of the SAV-specific messages...". What are the destination addresses of SAV-specific messages. Are they the destination addresses included in the SAV-specific messages, or the destination addresses of the IP headers of the SAV-specific messages? If they are