Subject: Re: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Tue, 21 May 2013 07:29:20 +0000

> Q: Does the WG agree? In particular, if you don't agree, please speak up.

I tend to agree with the draft's -00 version. 

           Corrected Text:

           The lower-order four bits of the Attribute Flags octet are
           unused.  They MUST be zero when originated.  When received, any
           value MUST be accepted.  When a BGP speaker propagates an
           attribute, it MUST propagate these flags as received.

I don't agree with the draft's -01 version for the following reasons: 

1. I don't see why it is considered more pragmatic/easier to be able to upgrade all the "propagating-routers" and "receiving-routers" with this draft-01 text, rather than upgrade just the "receiving-routers" with the right behavior (accept/ignore wrong bits) mentioned in draft-00 version?

2. the -01 version approach basically presumes that the Reserved bits won't/can't be used in future, so why bother. With this presumption, the -01 approach appears to be OK. But for genuine/regular reserved-fields, -00 behavior is the right approach. IOW, IMHO, Reserved-fields used else-where (other protocols, other BGP PDUs) should not follow as example, the direction this draft-01 version is taking. i.e. we may be at risk of setting a wrong example of "how to handle reserved flag/fields while propagating them"

3. Upgrading the "receiving-routers" to a s/w-version with the right behavior(draft-00) - this is a "necessary and sufficient" step to fix this problem. And this step is required irrespective of whether we follow draft-00 or -01 version. 
   Upgrading the "propagating-routers" to a s/w-version with draft-01 behavior - this appears to be an extraneous step, and causes the confusion mentioned in 2 above. So not required, IMHO. 

Thanks
Kaliraj

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 21 May 2013 14:57:07 +0000

Because some vendors interpreted what to do when receiving low bits that are set differently the ability to filter those bits on propagating routers is a requirement. Does that mean we would filter forever? No. But until we know what would happens to routers and their peering connections on receipt we would filter (remove any announcement with the low order bits set).

There are at least 3 major vendors that all interpreted (ignore/accept) differently.

Some drop the peer, others clear the bits automatically before propagating the announcement, others can if configured for it clear the bits before propagating or propagate them!

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: [email-masked] [[email-masked]] on behalf of Kaliraj Vairavakkalai [[email-masked]]
Sent: Tuesday, May 21, 2013 1:29 AM
To: John Scudder; idr wg
Subject: Re: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01

           Corrected Text:

Thanks
Kaliraj

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

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Wed, 22 May 2013 17:18:24 +0000

>Because some vendors interpreted what to do when receiving low bits that are set differently the ability to filter those bits on propagating routers is a requirement. 

IMHO, Because some vendors interpreted what to do when receiving low bits that are set differently, fixing the vendor software is the requirement. 

>Does that mean we would filter forever? No. But until we know what would happens to routers and their peering connections on 
>receipt we would filter (remove any announcement with the low order bits set).

I don't see why protocol-spec (for propagating-routers) should change, that too "temporarily", until a vendor-software comes up with a bug-fix (for receiving-router role). IMHO, this is unnecessary churn and confusion (ref: point 2 in my previous mail about risk of setting wrong example) in the standards space.

Also, I see the use of "ability to filter" in your above statements suggests it is optional, i.e. not a MUST, unlike what is stated in the -01 text; viz. "They MUST be zero when originated or sent". 

> Some drop the peer, others clear the bits automatically before propagating the announcement, others can if configured for it clear the bits before propagating or propagate them!
 
I fully agree the text should be clarified, as in -00 version of this draft. 
 
Thanks
Kaliraj