Subject: Re: [savi] draft-bi-savi-problem-00

From: Fred Baker <[email-masked]>
Date: Mon, 30 Jan 2012 10:07:13 -0800

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 implemented in access lists can be difficult to maintain operationally.

3) BCP 38 implemented in unicast RPF using 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 all of the above 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 concerns about BGP are the same concerns you would have with EIGRP or RIP/RIPng/RIPv2 in an environment in which systems sharing a link disagree on the metric they advertise. 

As we said privately, one could imagine an existing OSPF or IS-IS implementation calculating a uRPF table using the reverse metric. That doesn't address the ECMP problem, and doesn't address the other issues. I think the right place for your other concerns is in deployment or in an IRTF Research Group such as RRG.

---

From: Bingyang LIU <[email-masked]>
Date: Tue, 31 Jan 2012 00:06:09 -0500

Dear Fred, Joel and all,

I've revised the draft according to your comments. Please check the new
version here http://www.ietf.org/id/draft-bi-savi-problem-02.txt.

best regards
Bingyang

On Mon, Jan 30, 2012 at 1:07 PM, Fred Baker <[email-masked]> wrote:

> 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.
>
> 3) BCP 38 implemented in unicast RPF using 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 don't think you have a valid inter-AS vs intra-AS distinction; both
> classes of networks have asynchronous routes. Your concerns about BGP are
> the same concerns you would have with EIGRP or RIP/RIPng/RIPv2 in an
> environment in which systems sharing a link disagree on the metric they
> advertise.
>
> As we said privately, one could imagine an existing OSPF or IS-IS
> implementation calculating a uRPF table using the reverse metric. That
> doesn't address the ECMP problem, and doesn't address the other issues. I
> think the right place for your other concerns is in deployment or in an
> IRTF Research Group such as RRG.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Jan 2012 11:07:42 -0500

The document seems now to say that SAVI-BF can be done only if 
inter-domain routing changes to carry significantly more information. 
Is that the intent?
If so, the inevitable conclusion seems to be that SAVI-BF can not be 
done, since changing inter-domain routing information is way beyond 
anything practically deployable.

Yours,
With apologies if I have misunderstood the document,
Joel M. Halpern

On 1/31/2012 12:06 AM, Bingyang LIU wrote:
> On Mon, Jan 30, 2012 at 1:07 PM, Fred Baker <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>     3) BCP 38 implemented in unicast RPF using 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?
>
>     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 don't think you have a valid inter-AS vs intra-AS distinction;
>     both classes of networks have asynchronous routes. Your concerns
>     about BGP are the same concerns you would have with EIGRP or
>     RIP/RIPng/RIPv2 in an environment in which systems sharing a link
>     disagree on the metric they advertise.
>
>     implementation calculating a uRPF table using the reverse metric.
>     That doesn't address the ECMP problem, and doesn't address the other
>     issues. I think the right place for your other concerns is in
>     deployment or in an IRTF Research Group such as RRG.
>
>
>
>
> --
> Bingyang Liu

---

From: Bingyang LIU <[email-masked]>
Date: Tue, 31 Jan 2012 12:04:40 -0500

Dear Joel,

Thanks for your reply.

We think that in the inter-domain scenario, a node couldn't predict the
route from a remote node to itself with only the BGP information.

However, we observed that there are papers describing how to distribute the
required information for source address validation. For example, [SAVE:
Source Address Validity Enforcement Protocol], introduces a protocol
to propagate the currently routing states.

And there might be other ways rather than route-based anti-spoofing. For
example, [spoofing prevention method], associate each pair of ASes with a
key, and uses the key to verify the source addresses.

Nevertheless, even without those complicated techniques, a stub AS can
regulate itself by enforce "egress filtering" at the exit point to its
provider, perhaps using a simple "Ingress Access List" technique since a
stub AS has a relatively stable set of IP prefixes. However this method is
self-regulation, not protective, so it may not be attractive or incentive
to the stub ASes.

best
Bingyang

On Tue, Jan 31, 2012 at 11:07 AM, Joel M. Halpern <[email-masked]>wrote:

> inter-domain routing changes to carry significantly more information. Is
> that the intent?
> If so, the inevitable conclusion seems to be that SAVI-BF can not be done,
> since changing inter-domain routing information is way beyond anything
> practically deployable.
>
> Yours,
>> version here http://www.ietf.org/id/draft-**bi-savi-problem-02.txt<http://www.ietf.org/id/draft-bi-savi-problem-02.txt>
>> .
>>
>> best regards
>> Bingyang
>>
>> Home Page: http://netarchlab.tsinghua.**edu.cn/~liuby<http://netarchlab.tsinghua.edu.cn/~liuby>
>>
>