Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive

From: Paul Jakma <[email-masked]>
Date: Wed, 15 Apr 2009 14:56:26 +0100 (BST)

Hi,

I have a question nagging me, possibly just philosophical. The text 
(of 01) says:

    "In the case of an optional transitive attribute which has no
     effect on route
     selection or installation, the malformed attribute MAY instead be
     discarded and the UPDATE message continue to be processed. "

my question is, to what extent (if any) can a speaker simply assume 
that any Partial-bit attribute automatically "has no effect on route 
selection".

I.e. an optional attribute by definition contains either optional 
data unrelated to route-selection, or else information that 
supplements route-selection while still allowing speakers to make 
safe (if perhaps sub-optimal) route selections if they ignore that 
attribute.

Right?

If so, why isn't the correct behaviour for a speaker that recognises 
a partial, optional attribute as malformed to simply fallback to the 
same behaviour as a BGP speaker that doesn't recognise the attribute?

I.e. can we reduce the numbers of possible different classes of 
behaviours from:

1. speakers that don't recognise the attribute
- speakers that recognise and attribute is:
   2. well-formed
   3. malformed, error behaviour attribute specific

to:

1. speakers that don't recognise the attribute
2. speakers that recognise the attribute (well-formed being implied)

+

Generalised error behaviour for optional attrs on input processing:
if partial: discard
else: notify

??

I'm probably tilting at windmills as usual, but is there perhaps some 
value to trying to generalise things a bit more and reduce the number 
of attribute-specific behaviours?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
   I never liked you, and I always will. -Samuel Goldwyn

---

From: Paul Jakma <[email-masked]>
Date: Wed, 15 Apr 2009 15:02:52 +0100 (BST)

Oh..

The point being, that much thought will have gone into the 
backward-compatibility issues for new attributes, so why not re-use 
that effort by having the error-case be fallback to that 
compatibility mode (a deployment that should see much more testing 
and use than error-cases)?

--paulj

On Wed, 15 Apr 2009, Paul Jakma wrote:

> Hi,
>
> I have a question nagging me, possibly just philosophical. The text (of 01) 
> says:
>
> my question is, to what extent (if any) can a speaker simply assume that any 
> Partial-bit attribute automatically "has no effect on route selection".
>
> I.e. an optional attribute by definition contains either optional data 
> unrelated to route-selection, or else information that supplements 
> route-selection while still allowing speakers to make safe (if perhaps 
> sub-optimal) route selections if they ignore that attribute.
>
> Right?
>
> If so, why isn't the correct behaviour for a speaker that recognises a 
> partial, optional attribute as malformed to simply fallback to the same 
> behaviour as a BGP speaker that doesn't recognise the attribute?
>
> I.e. can we reduce the numbers of possible different classes of behaviours 
> from:
>
> I'm probably tilting at windmills as usual, but is there perhaps some value 
> to trying to generalise things a bit more and reduce the number of 
> attribute-specific behaviours?
>
> regards,
>

-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
When you're dining out and you suspect something's wrong, you're probably right.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 15 Apr 2009 07:14:28 -0700

Hi Paul,

> sub-optimal) route selections if they ignore that attribute.

Not always ... Let take an example Route Target extended communities 
attribute in L3VPNs.

While those indeed are not part of best path selection in the same time 
thore are critical to the route importing and therefor propagating 
updates without them is quite pointless if not harmful. (Harmful case 
would be when best path is selected for those nets which do not have a 
valid RTs attached as opposed to those which do).

Cheers,
R.

---

From: Paul Jakma <[email-masked]>
Date: Wed, 15 Apr 2009 15:21:15 +0100 (BST)

On Wed, 15 Apr 2009, Robert Raszuk wrote:

> While those indeed are not part of best path selection in the same 
> time thore are critical to the route importing and therefor 
> propagating updates without them is quite pointless if not harmful. 
> (Harmful case would be when best path is selected for those nets 
> which do not have a valid RTs attached as opposed to those which 
> do).

Hmm, so what happens if a route with this attribute transits a 
speaker that doesn't recognise them?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Photographing a volcano is just about the most miserable thing you can do.
 		-- Robert B. Goodman
 	[Who has clearly never tried to use a PDP-10.  Ed.]

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 15 Apr 2009 07:26:09 -0700

Paul,

In theory it should be fine. Example: RR passing it .. they will get to 
the other side PE just fine and PE will use them for import. RR does not 
perform any import action of L3VPN routes, but it does perform best path 
selection.

Cheers,
R.

>> (Harmful case would be when best path is selected for those nets which 
>> do not have a valid RTs attached as opposed to those which do).
> 
> Hmm, so what happens if a route with this attribute transits a speaker 
> that doesn't recognise them?
> 
> regards,

---

From: Paul Jakma <[email-masked]>
Date: Wed, 15 Apr 2009 15:58:03 +0100 (BST)

On Wed, 15 Apr 2009, Robert Raszuk wrote:

> Paul,
>
> In theory it should be fine. Example: RR passing it .. they will get to the 
> other side PE just fine and PE will use them for import. RR does not perform 
> any import action of L3VPN routes, but it does perform best path selection.

So what's the correct action for the receiving PE to take if the 
extended-community attribute is malformed? What about if it's not 
present?

Some specific technology may have interesting requirements - it can 
always override general behaviours in its own RFCs. But why can't a 
general-case BGP RFC just specify fallback for partials?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Thou hast seen nothing yet.
 		-- Miguel de Cervantes