Subject: [savi] Problem Statement of SAVI Beyond the First Hop

From: Bingyang LIU <[email-masked]>
Date: Sun, 29 Jan 2012 13:24:48 -0500

Dear all,

Attached please find the draft of "Problem Statement of SAVI Beyond the
First Hop" (SAVI-BF), in which we discuss about the problems of RPF and
relevant issues about SAVI-BF.

We welcome any comments and hope to discuss it in IETF83.

best regards
Bingyang Liu
-- 
Bingyang Liu
Network Architecture Lab, Network Center,Tsinghua Univ.
Beijing, China
Home Page: http://netarchlab.tsinghua.edu.cn/~liuby

---

From: Bingyang LIU <[email-masked]>
Date: Sun, 29 Jan 2012 13:40:14 -0500

Hi all,

This is the web url for the draft:
http://www.ietf.org/id/draft-bi-savi-problem-00.txt

best
Bingyang

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 30 Jan 2012 07:12:01 +0800

Hi All,

At IETF82 SAVI meeting, I was suggested to make a draft of “Problem Statement of SAVI Beyond the First Hop“.
In this draft, the problem of intra-AS and inter-AS are combined, some examples are illustrated. In the design challenge session,
“fast reroute” issue raised at IETF82 SAVI meeting is included.

We would like to continue the discussion at IETF 83 SAVI meeting.

thanks,
Jun Bi

From: Bingyang LIU 
Sent: Monday, January 30, 2012 2:40 AM
To: [email-masked] 
Subject: Re: [savi] Problem Statement of SAVI Beyond the First Hop

Hi all,  

This is the web url for the draft: http://www.ietf.org/id/draft-bi-savi-problem-00.txt

best
Bingyang

  Dear all, 

  Attached please find the draft of "Problem Statement of SAVI Beyond the First Hop" (SAVI-BF), in which we discuss about the problems of RPF and relevant issues about SAVI-BF. 

  best regards

  Bingyang Liu

--------------------------------------------------------------------------------
_______________________________________________
savi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/savi

---

From: Fred Baker <[email-masked]>
Date: Sun, 29 Jan 2012 15:36:06 -0800

On Jan 29, 2012, at 10:24 AM, Bingyang LIU wrote:

> <draft-bi-savi-problem-00.txt>_______________________________________________
> savi mailing list
> [email-masked]

Was there a reason to not use the internet draft repository?

Personally, I think you have six problems.

1) The standard problem with any new specification: RFCs (and in this case internet drafts) don't perform operational functions; deployed-and-configured software and hardware do. LAN SAVI won't accomplish anything until it is deployed.

2) BCP 38 as access lists is difficult to operationally maintain

3) BCP 38 based on a FIB is based on how a given system routes to another system, not how the other system routes to it.

4) SPF-based routing protocols have complete information, but to develop uRPF tables from it, one has to use the reverse metric, not the forward metric - not how do I route to him, but how does he route to me?

5) any other known routing algorithm - bellman-ford/distance vector, static routing, whatever - loses information. In an environment where a given system is trying to predict what another system will do, a protocol or algorithm that loses information isn't analyzable by any system other than the system making the forwarding decisions.

6) ECMP - even with perfect information, if the system forwarding packets has more options than the system checking them can check for, you lost information. See #5.

Fast reroute is a special case of #4 and #5; instead of working on the present routing decision, it tries to predict with reasonably high confidence what the next routing decision will be.

I believe that we agreed to that at IETF 82.

I don't think you have a valid inter-AS vs intra-AS distinction; both classes of networks have asynchronous routes. Your complaints about BGP are the same complaints you would have with EIGRP or RIP/RIPng/RIPv2 in an environment in which system sharing a link disagree on the metric they advertise. 

As we said privately, I think the argument made in the abstract ("we wrote the drafts but subnet SAVI isn't yet widely deployed, therefore we need to fix filter/uRPF SAVI") is weak. I agree that there are cases, noted above, in which there are false positives and false negatives in routing-based SAVI. I'm not sure you have the needed theoretical underpinning to fix them anywhere other than SPF, and then only if ECMP uses all possible routes, not a subset.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Jan 2012 00:24:44 -0500

I have looked at this draft, and have two general areas of concern, both 
similar to comments Fred Baker made.

1) The draft notes that there is a significant lack of deployment of BCP 
38.  I see nothing in the draft that explains why any future techniques 
would be more deployed.  The arguments in the draft for deployment of 
something new are basically equally applicable to BCP 38.  And the new 
work will be more complicated.
1') As the draft notes, the best protection si for sites to use the 
developed SAVI techniques in conjunction with BCP 38.  Given that, I 
would think we would be better served trying to get the work adopted, 
rather than trying to develop a new partial solution to the non-adoption 
of the first and second solutions.

2) The draft outlines significant technical obstacles to any effort to 
solve this problem from this angle.  And indicates that some of these 
issues are intractable.  I am loath to take on technical work that is 
somewhere between unlikely and impossible to succeed.

Yours,
Joel M. Halpern

On 1/29/2012 6:12 PM, Jun Bi wrote:
> In this draft, the problem of intra-AS and inter-AS are combined, some
> examples are illustrated. In the design challenge session,
> *From:* Bingyang LIU <mailto:[email-masked]>
> *Sent:* Monday, January 30, 2012 2:40 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [savi] Problem Statement of SAVI Beyond the First Hop
> Hi all,
> On Sun, Jan 29, 2012 at 1:24 PM, Bingyang LIU <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear all,
>     Attached please find the draft of "Problem Statement of SAVI Beyond
>     the First Hop" (SAVI-BF), in which we discuss about the problems of
>     RPF and relevant issues about SAVI-BF.

---

From: Bingyang LIU <[email-masked]>
Date: Mon, 30 Jan 2012 00:48:00 -0500

> Was there a reason to not use the internet draft repository?
[A] We used the I-D repository later. Sorry for confusing. And we uploaded
v01, updated according to your comments.

> 1) The standard problem with any new specification: RFCs (and in this case
> internet drafts) don't perform operational functions;
> deployed-and-configured software and hardware do. LAN SAVI won't accomplish
> anything until it is deployed.
>
[A] We deleted the sentences related with the deployment of SAVI in the new
version (v01).

> 2) BCP 38 as access lists is difficult to operationally maintain
[A] Yes, we agree.

>
> 3) BCP 38 based on a FIB is based on how a given system routes to another
> system, not how the other system routes to it.
>
[A] Yes, we agree.

>
> 4) SPF-based routing protocols have complete information, but to develop
> uRPF tables from it, one has to use the reverse metric, not the forward
> metric - not how do I route to him, but how does he route to me?
>
[A] Yes, we agree. And we briefly summarize it in section 3.1 in the new
version.

>
> 5) any other known routing algorithm - bellman-ford/distance vector,
> static routing, whatever - loses information. In an environment where a
> given system is trying to predict what another system will do, a protocol
> or algorithm that loses information isn't analyzable by any system other
> than the system making the forwarding decisions.
>
[A] Yes, we agree.  We also briefly explain it in section 3.1 in the new
version.

>
> 6) ECMP - even with perfect information, if the system forwarding packets
> has more options than the system checking them can check for, you lost
> information. See #5.
>
[A] Yes, we agree.

>
> Fast reroute is a special case of #4 and #5; instead of working on the
> present routing decision, it tries to predict with reasonably high
> confidence what the next routing decision will be.
>
[A] Yes, we agree.
Actually in the draft, we claim that all the problems are caused by
"asynchronous routing information", so that routers are lack of sufficient
routing information to predict the incoming direction of a packet. We also
list five examples that produce this "asynchronous routing information",
i.e. asymmetric link metrics, ECMP, static routing and local routing
policy, fast reroute, and inter-domain route aggregation. In a
distance-vector routing protocol, a router doesn't have enough information
to solve any of the five issues. While in a link-state protocol, a router
can use the reverse link metrics to solve the "asymmetric link metrics"
issue, but not the other four.

> I don't think you have a valid inter-AS vs intra-AS distinction; both
> classes of networks have asynchronous routes. Your complaints about BGP are
> the same complaints you would have with EIGRP or RIP/RIPng/RIPv2 in an
> environment in which system sharing a link disagree on the metric they
> advertise.
>
[A] We think that an ISP is an benefit unit on the Internet. We think that
an ISP won't deploy inter-domain SAVI if it could get enough benefit from
it. However, in the intra-domain scenario, the deployment incentive may
come from security, accountability and manageability concerns.

> As we said privately, I think the argument made in the abstract ("we wrote
> the drafts but subnet SAVI isn't yet widely deployed, therefore we need to
> fix filter/uRPF SAVI") is weak. I agree that there are cases, noted above,
> in which there are false positives and false negatives in routing-based
> SAVI. I'm not sure you have the needed theoretical underpinning to fix them
> anywhere other than SPF, and then only if ECMP uses all possible routes,
> not a subset.

[A] Yes. We removed the sentences about the deployment of SAVI in the new
version.

[A] We'd like to state that, this document is not to propose a solution to
the SAVI-BF. We raise several problems with the current practices and
possible challenges. And in the future people may consider to propose
solutions to solve a subset of the challenges if they couldn't solve all of
them, of course if the WG is eventually chartered to do so.

---

From: Bingyang LIU <[email-masked]>
Date: Mon, 30 Jan 2012 01:06:08 -0500

Dear Joel,

Thank you very much for your comments. Some replies to your comments can be
found in the email I just replied to Fred. We also updated the draft in v01
to address some issues you talked about (
http://www.ietf.org/id/draft-bi-savi-problem-01.txt).

And inline please find further explanation.

best
Bingyang

On Mon, Jan 30, 2012 at 12:24 AM, Joel M. Halpern <[email-masked]>wrote:

> something new are basically equally applicable to BCP 38.  And the new work
> will be more complicated.
> developed SAVI techniques in conjunction with BCP 38.  Given that, I would
> think we would be better served trying to get the work adopted, rather than
> trying to develop a new partial solution to the non-adoption of the first
> and second solutions.
>
[A] We do respect the work of Ingress Filtering and SAVI solutions. What we
present in this document, is the possible scenarios in which Ingress
Filtering may not be able to work perfectly. We didn't intend to propose
any solutions here. We just want to reveal the issues which do exist in
practice and create a discussion on some subjects, e.g. Do these issues
really matter? Is it possible to solve them all? What is practical to do?
etc.

> somewhere between unlikely and impossible to succeed.
[A] We do agree with you on that finding out a solution to conquer all
the illustrated issues is quite challenging and maybe impossible. But if we
can solve a subset of them, we may improve the current practice. However,
again, proposing a solution is not a goal of this document :)

>> http://www.ietf.org/id/draft-**bi-savi-problem-00.txt<http://www.ietf.org/id/draft-bi-savi-problem-00.txt>
>> best
>> Bingyang
>>
>>    Home Page: http://netarchlab.tsinghua.**edu.cn/~liuby<http://netarchlab.tsinghua.edu.cn/~liuby>
>>
>>
>>
>> --
>> Bingyang Liu
>> Home Page: http://netarchlab.tsinghua.**edu.cn/~liuby<http://netarchlab.tsinghua.edu.cn/~liuby>
>>
>> ______________________________**_________________
>> savi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/savi<https://www.ietf.org/mailman/listinfo/savi>
>>
>>
>> ______________________________**_________________
>> savi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/savi<https://www.ietf.org/mailman/listinfo/savi>
>>
>