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

["John G. Scudder" <[e-mail]>]

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.
>
> 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.
>
>
>> Hi John and others,
>> Happy Easter! maybe a little bit late:)
>> Pls see inline...
>> --------------------------------------------------
>> From: "John G. Scudder" <[e-mail]>
>> Sent: Thursday, April 09, 2009 11:11 PM
>> To: "Dong Jie" <[e-mail]>
>> Cc: "'idr List'" <[e-mail]>
>> Subject: Re: [Idr] Questions on draft-scudder-idr-optional- 
>> transitive-01
>>> 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.
>> 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 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,
>> 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
>>>
>>> On Apr 9, 2009, at 12:09 AM, Dong Jie wrote:
>>>
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>