Re: [GROW] draft-ietf-grow-simple-va

Hi Jakob,

> draft-ietf-grow-simple-va-04 needs another deployment consideration.
>
> Routes in the RIB (not the FIB) are sometimes used
> to resolve BGP nexthops and nexthops for static routes.

Not sometimes .. Pretty much every time !

> There is a rule not to resolve such nexthops using the default
> route.

That is an option - true.

> If routes are removed from the RIB, they will no
> longer be able to resolve nexthops.

Disconnect ! Simple-va does not remove routes from RIB. It suppresses 
overlapping less specific one.

An option is to suppress all by injecting the default, but this would be 
configurable. Clearly if you allow that you should not disable next hop 
resolution via default. Those two would be mutually exclusive.

> Also, when resolving
> nexthops, the resolving routes sometimes carry attributes
> that are important to the resolving process. If the
> default route is used to resolve nexthops, such attributes
> would be lost. Examples of such attributes are
> IGP distance (it may be the same as the default) and
> whether it is on a tunnel.

Again ... default is the special case as described above. Other then 
that the less specific would have the same next hop as potentially 
suppressed more specific hence IGP distance would be the same.

An implementation may consider not to suppress routes with AIGP 
attribute being significantly different but again I do not find it 
necessary for routing correctness since the main assumption is identical 
next hop.

> The reason for that rule is this:
> A non default route says: I can reach the advertised
> network and all IP addresses covered by it. If any
> IP address covered by this prefix is unreachable,
> then it doesn't exist.
> A default route says: I can reach many IP addresses,
> but obviously not all of them. I can not tell you
> which I can actually reach and which I can't.

Nothing guarantees that you can reach all destinations covered by a 
subnet. (We have been working on negative routes in the past however 
that effort has been shelved).

But I think you are missing the applicability of suppressing to the 
default versus suppressing to the less specific.

1. Suppression to the default(s):

- Applicable to the edge routers in the POP when default route is 
injected from all POP to core boundary routers into the POP.

Note: This mode could be also applicable to AS wide suppression only if 
we could guarantee the exact symmetry of ASBR received BGP updates in 
the AS.

2. Suppression to the less specific:

- Applicable in all cases.

> Routes in the RIB may also be redistributed to other
> protocols. If they no longer exist in the RIB, they
> will not be redistributed.

In the default case - you are correct.

In the suppression by less specific redistribution will work just fine 
routing wise.

The local implementation may tag routes to be suppressed at the BGP to 
RIB boundary and only suppress tagged at the RIB to FIB to address 
redistribution case. However redistribution of BGP to other protocols is 
usually not that good of an idea hence we decided to leave it for now.

> These considerations do not break the technique,
> but they need to be stated.

I am happy to add above clarification to the text in the draft.

Many thx,
R.

>
> --
> Jakob Heitz.
>
> -----Original Message-----
> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of Ronald Bonica
> Sent: Monday, April 30, 2012 9:52 AM
> To: robert@raszuk.net
> Cc: grow@ietf.org; iesg@ietf.org
> Subject: Re: [GROW] draft-ietf-grow-simple-va
>
> Robert,
>
> This sounds reasonable to me. Please issue a new version of the draft, as the current version has expired. When you issue a new version, change the filename, so that it won't look like a WG submission. Also, ping me so that I can send the document on for IETF Last Call.
>
>                                                               Ron
>
>> -----Original Message-----
>> From: Robert Raszuk [mailto:robert@raszuk.net]
>> Sent: Monday, April 30, 2012 1:49 AM
>> To: Ronald Bonica
>> Cc: grow@ietf.org; iesg@ietf.org
>> Subject: Re: [GROW] draft-ietf-grow-simple-va
>>
>> Ron,
>>
>>>> So, how do we proceed? If you want to demonstrate WG support of
>>   >>  draft-ietf-grow-simple-va, let the WG LC proceed. If you want to
>>>> publish without demonstrating WG support, I would be glad to AD
>>>> sponsor that draft.
>>
>> Please proceed with AD sponsorship on this draft.
>>
>> In my view the idea and the draft have already received sufficient
>> support within this group, other IETF and IRTF groups as well as
>> outside of IETF in various public forums.
>>
>> Thx,
>> R.
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
>