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

[Mach Chen <[e-mail]>]

Hi John,

> 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.

I got it.

> 
> 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.

OK.


Best regards,

Mach

> 
> 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
>>
> 
>