Subject: [Idr] Questions on draft-scudder-idr-optional-transitive-01

From: Dong Jie <[email-masked]>
Date: Thu, 09 Apr 2009 12:09:37 +0800

This draft said that optional transitive attributes with Partial bit set
"have been propagated without being checked by intermediate routers that do
not recognize the attribute", so if error-handling rules of RFC4271 is used,
the session that is reset is not associated with the router that is at
fault.

But the rules of setting Partial bit are complex and sometimes may not meet
the condition the draft based on.

Section 5 of RFC4271 specifies the rules of Partial bit in optional
transitive attributes:

-"If a path with an unrecognized transitive optional attribute is accepted
and passed to other BGP peers, then the unrecognized transitive optional
attribute of that path MUST be passed, along with the path, to other BGP
peers with the Partial bit in the Attribute Flags octet set to 1.  If a path
with a recognized, transitive optional attribute is accepted and passed
along to other BGP peers and the Partial bit in the Attribute Flags octet is
set to 1 by some previous AS, it MUST NOT be set back to 0 by the current
AS."

-"New, transitive optional attributes MAY be attached to the path by the
originator or by any other BGP speaker in the path.  If they are not
attached by the originator, the Partial bit in the Attribute Flags octet is
set to 1." 

Based on these rules, receiving optional transitive attributes with partial
bit set does not mean the peering BGP speaker cannot recognize the
attributes and does not check them, because Partial bit can be set by some
previous BGP speakers, and it MUST NOT be set back to 0. In some cases,
Partial bit is set by some previous BGP speaker, but the fault is done by
the peering BGP speaker, then the procedures of RFC4271 SHOULD be followed.

In some other cases, Partial bit is set because the attribute is attached by
some intermediate BGP speaker, and all of the BGP speakers along the path
can recognize it. Then the procedures of RFC4271 SHOULD also be followed.

IMO, Partial bit of optional transitive attribute is not fit for identifying
whether the fault is done by the peering BGP speaker. It only indicates that
the optional transitive attribute is *not recognized* or *not seen* by all
the BGP speakers in the path. 

Best regards,
Jie

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 9 Apr 2009 11:11:50 -0400

You're right in your analysis of exactly what the Partial bit  
communicates, and we'll revise the next version of the draft to  
correct the inaccurate characterization.  It would have been more  
accurate to note that if the Partial bit is *not* set, then the fault  
*can* be imputed to the direct neighbor.  A set Partial bit means that  
we don't know -- and when we don't know, we have to assume innocence  
on the part of the direct neighbor.

The unfortunate fact is that there is no certain way with optional  
transitive attributes of determining whether the "at fault" speaker is  
the direct neighbor or not, thus I don't think there should be any  
other change to the draft -- Partial is admittedly an imperfect  
heuristic, but it's the best one we have available.  The only other  
supportable alternative I can see is to apply the procedures of the  
draft to all optional transitives, whether Partial is set or not --  
but that option seems even less desirable.

Regards,

--John

---

From: Dong Jie <[email-masked]>
Date: Fri, 10 Apr 2009 10:50:06 +0800

> the direct neighbor or not
That's right. And we should find a way to make it clear.

Does anybody know the intention of designing Partial bit? I don't know if
there are some other usages of Partial bit at present. When a BGP router
receives an attribute with Partial bit set, does the router process the
attribute specially?

If not, maybe we can change the rules of setting Partial bit (and also the
meaning of it). Each speaker SHOULD reset Partial bit before advertising the
updates, and this bit is set to 1 if the speaker recognizes the attribute
and has checked its correctness. Then Partial bit can be used to determine
whether the "at fault" speaker is the direct neighbor or not.

If Partial bit has some other usages and cannot be modified, we can define a
new *Check bit* from the reserved bits of Attribute Flags Octet. The Check
bit is set to 1 if the speaker recognizes the attribute and has checked its
correctness. Each speaker SHOULD reset this bit before advertising the
updates. Based on this Check bit, a speaker can determine whether the
attribute has been checked by the direct neighbor, and knows whether it is
at fault.

Either of the two modifications can guarantee that accurate error handling
procedures are used.

Best regards,
Jie

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Thursday, April 09, 2009 11:12 PM
> To: Dong Jie
> Cc: 'idr List'
> Subject: Re: Questions on draft-scudder-idr-optional-transitive-01
>

---

From: Mach Chen <[email-masked]>
Date: Tue, 14 Apr 2009 10:30:27 +0800

Hi John and others,

Happy Easter! maybe a little bit late:)

Pls see inline...

--------------------------------------------------
From: "John G. Scudder" <[email-masked]>
Sent: Thursday, April 09, 2009 11:11 PM
To: "Dong Jie" <[email-masked]>
Cc: "'idr List'" <[email-masked]>
Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01

> communicates, and we'll revise the next version of the draft to  correct 
> the inaccurate characterization.  It would have been more  accurate to 
> note that if the Partial bit is *not* set, then the fault  *can* be 
> imputed to the direct neighbor.  A set Partial bit means that  we don't 
> know -- and when we don't know, we have to assume innocence  on the part 
> of the direct neighbor.

But sometime(for whatever reason), if it happens to the direct neighbor at 
fault, then we will mistake to assume that the direct neighbour is 
innocence, and hence to result in route inconsistent or any other underlying 
aftereffects no matter what we drop or accept the update with malformed 
transitive optional attribute.

> the direct neighbor or not,

Actually, without a dedicated flag for judging whether the direct neighbor 
is innocence is the key point. Using the Partial bit for judging is somtimes 
a better than none choice, but as I said above, it will bring side effects.

So, since we want to resolve this malformed transitive optional attribute 
issue, why don't we think out a more downright method?

IMO, Dong's suggestion in another email may be a good idea, that is if the 
Partial bit has not any essential usage (I have not seen any application of 
it, or someone please educate me), we may change the usage of Partial bit to 
indicate whether a BGP speaker recognizes the transitive optional attribute 
attached on a route, if we can't change the usage of the Partial bit, we 
could assign a new bit(may called Check bit)from the reserved bits of 
attribute for such purpose.

>thus I don't think there should be any  other change to the draft --  
>Partial is admittedly an imperfect  heuristic, but it's the best one we 
>have available.  The only other  supportable alternative I can see is to 
>apply the procedures of the  draft to all optional transitives, whether 
>Partial is set or not --  but that option seems even less desirable.
>
> Regards,
>
> --John

Best regards,
Mach Chen

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 14 Apr 2009 10:58:56 -0700

Hi Mach & Dong,

I think your suggestion for better way to determine the router at fault 
is very valuable and would indeed be very helpful.

But in my opinion what this draft focuses on is the least expensive and 
as safe as possible while in the same time actually doable way to 
address issue in existing networks deployed today. In those we can not 
rely on the fact that all of my peers and peers of my peers will migrate 
and deploy either new semantics for partial bit setting and treatment or 
introduce some other form of malformation signaling.

So I would suggest to continue the draft as is and in the same time 
start the work on exploring possibilities on better way to signal the 
peer if I am at fault or some box few routers down. The real issue (and 
perhaps only one) is that the content of the opaque transitive attribute 
is unknown to the router not supporting it. Therefor unless it contains 
some form of well known per transitive attribute based checksum it may 
be difficult to set any flag based on it's content.

Cheers,
R.

>> *can* be imputed to the direct neighbor.  A set Partial bit means 
>> that  we don't know -- and when we don't know, we have to assume 
>> innocence  on the part of the direct neighbor.
> 
> But sometime(for whatever reason), if it happens to the direct neighbor 
> at fault, then we will mistake to assume that the direct neighbour is 
> innocence, and hence to result in route inconsistent or any other 
> underlying aftereffects no matter what we drop or accept the update with 
> malformed transitive optional attribute.
> 
>>
> Actually, without a dedicated flag for judging whether the direct 
> neighbor is innocence is the key point. Using the Partial bit for 
> judging is somtimes a better than none choice, but as I said above, it 
> will bring side effects.
> 
> So, since we want to resolve this malformed transitive optional 
> attribute issue, why don't we think out a more downright method?
> 
> IMO, Dong's suggestion in another email may be a good idea, that is if 
> the Partial bit has not any essential usage (I have not seen any 
> application of it, or someone please educate me), we may change the 
> usage of Partial bit to indicate whether a BGP speaker recognizes the 
> transitive optional attribute attached on a route, if we can't change 
> the usage of the Partial bit, we could assign a new bit(may called Check 
> bit)from the reserved bits of attribute for such purpose.
> 
>> Partial is admittedly an imperfect  heuristic, but it's the best one 
>> we have available.  The only other  supportable alternative I can see 
>> is to apply the procedures of the  draft to all optional transitives, 
>> whether Partial is set or not --  but that option seems even less 
>> desirable.
>>
>> Regards,
>>
>> --John
> 
> 
> Best regards,
> Mach Chen
> 
> 
>>

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 14 Apr 2009 15:55:06 -0400

Folks,

I think Robert expresses it well when he points out that an important  
goal of the draft is to be deployable in current networks.  It is  
important that it not rely on the collaboration of peers in order to  
be deployed, thus the current flags and their semantics are a given.

IMO it would be a fine idea to start a separate conversation on the  
suggestion to change the semantics of Partial or standardize a new flag.

Regards,

--John

P.S.:  It could also be early to wish a Happy Easter if you're  
following the Orthodox calendar. :-)

On Apr 14, 2009, at 1:58 PM, Robert Raszuk wrote:

> Hi Mach & Dong,
>
> I think your suggestion for better way to determine the router at  
> fault is very valuable and would indeed be very helpful.
>
> But in my opinion what this draft focuses on is the least expensive  
> and as safe as possible while in the same time actually doable way  
> to address issue in existing networks deployed today. In those we  
> can not rely on the fact that all of my peers and peers of my peers  
> will migrate and deploy either new semantics for partial bit setting  
> and treatment or introduce some other form of malformation signaling.
>
> start the work on exploring possibilities on better way to signal  
> the peer if I am at fault or some box few routers down. The real  
> issue (and perhaps only one) is that the content of the opaque  
> transitive attribute is unknown to the router not supporting it.  
> Therefor unless it contains some form of well known per transitive  
> attribute based checksum it may be difficult to set any flag based  
> on it's content.
>
> Cheers,
> R.
>
>
>> Hi John and others,
>>> accurate to note that if the Partial bit is *not* set, then the  
>>> fault  *can* be imputed to the direct neighbor.  A set Partial bit  
>>> means that  we don't know -- and when we don't know, we have to  
>>> assume innocence  on the part of the direct neighbor.
>> But sometime(for whatever reason), if it happens to the direct  
>> neighbor at fault, then we will mistake to assume that the direct  
>> neighbour is innocence, and hence to result in route inconsistent  
>> or any other underlying aftereffects no matter what we drop or  
>> accept the update with malformed transitive optional attribute.
>>>
>>> transitive attributes of determining whether the "at fault"  
>>> speaker is the direct neighbor or not,
>> judging is somtimes a better than none choice, but as I said above,  
>> it will bring side effects.
>> IMO, Dong's suggestion in another email may be a good idea, that is  
>> if the Partial bit has not any essential usage (I have not seen any  
>> usage of Partial bit to indicate whether a BGP speaker recognizes  
>> the transitive optional attribute attached on a route, if we can't  
>> change the usage of the Partial bit, we could assign a new bit(may  
>> called Check bit)from the reserved bits of attribute for such  
>> purpose.
>>> thus I don't think there should be any  other change to the draft  
>>> --  Partial is admittedly an imperfect  heuristic, but it's the  
>>> best one we have available.  The only other  supportable  
>>> alternative I can see is to apply the procedures of the  draft to  
>>> all optional transitives, whether Partial is set or not --  but  
>>> that option seems even less desirable.
>>>
>>> Regards,
>>>
>>> --John
>> Best regards,
>> Mach Chen
>>>

---

From: Mach Chen <[email-masked]>
Date: Wed, 15 Apr 2009 12:59:25 +0800

Hi Robert,

> Hi Mach & Dong,
>
> I think your suggestion for better way to determine the router at fault is 
> very valuable and would indeed be very helpful.

Thanks!

>
> But in my opinion what this draft focuses on is the least expensive and as 
> safe as possible while in the same time actually doable way to address 
> issue in existing networks deployed today. In those we can not rely on the 
> fact that all of my peers and peers of my peers will migrate and deploy 
> either new semantics for partial bit setting and treatment or introduce 
> some other form of malformation signaling.

As to deployment aspect, I fully agree with you, require all BGP routers to 
support a new function is not realistic.

But back to the new semantics of partial bit, if we could change it (assume 
no existing application uses it) to relect the status whether the direct 
neighbor saw and understood an attribute received from its peer(s), then 
based on the partial bit, a BGP router can use the rules defined in this 
optional-transitive draft to accurately judge whether a direct neighbor is 
at fault. This will not require that all routers MUST support it, the at 
worst situation (on one supports it) is same as current, but if a router 
support it, someone will benefit.

>
> So I would suggest to continue the draft as is and in the same time start 
> the work on exploring possibilities on better way to signal the peer if I 
> am at fault or some box few routers down.

I do not object to continue the draft as is, I just want to discuss more 
about it before we implement it.

If the WG think that it is worth to find a better way, maybe we could work 
on it and write a new draft.

> The real issue (and perhaps only one) is that the content of the opaque 
> transitive attribute is unknown to the router not supporting it. Therefor 
> unless it contains some form of well known per transitive attribute based 
> checksum it may be difficult to set any flag based on it's content.

IMO, it will not be so complex like that.

A BGP speaker SHOULD guarantee that the information (info originated from 
itself, info received from its peer and it see and understand) will be sent 
to its peer(s) MUST be correct. So, if a router does not know an received 
attribute, just setting the flag to tell its peer(s) that I do not know it 
and I should not answer for it. Of cause, that will be different if someone 
wants to locate the right point where is at fault.

Best regards,

Mach Chen

>> neighbor is innocence is the key point. Using the Partial bit for judging 
>> is somtimes a better than none choice, but as I said above, it will bring 
>> side effects.
>>
>> application of it, or someone please educate me), we may change the usage 
>> of Partial bit to indicate whether a BGP speaker recognizes the 
>> transitive optional attribute attached on a route, if we can't change the 
>> usage of the Partial bit, we could assign a new bit(may called Check

---

From: Mach Chen <[email-masked]>
Date: Wed, 15 Apr 2009 12:59:28 +0800

Hi John,

> be deployed, thus the current flags and their semantics are a given.

I got it.

> suggestion to change the semantics of Partial or standardize a new flag.

OK.

Best regards,

Mach