Re: [Idr] Doubt noticed while looking at draft-uttaro-idr-bgp-oad-02.txt

[Gyan Mishra <[e-mail]>]

I think we really need to assess the problem statement and what policy are
we not able to craft today with RFC 4271 that requires this change to make
all non transitive path attributes transitive.

I think there is very good reason for some path attribute such as MED and
local preference to be non transitory and it actually provides a means of
routing control moreso then making them now transitive.

On Tue, Jul 11, 2023 at 8:34 PM Gyan Mishra <[e-mail]> wrote:

>
> I can see the very slight benefits for cooperating ASNs under the same
> administrative domain, however this is a MAJOR quite massive  update to RFC
> 4271 as  to how BGP was intended to work as far as what path attributes are
> transitive verses non transitive.
>
> Taking a step back if you look at the gains for cooperating ASNs within
> the same domain versus the massive change in BGP path selection process for
> the entire internet, I am not sure this is a good idea.
>
> Even within the same cooperating domain all operators and network
> designers, every engineer out there worldwide  knows how BGP works today
> and this is a complete rewrite of BGP following a brand new set of rules
> for best path selection.
>
> I am fearful of possible loops and routing issues that could arise with
> such a dramatic change.
>
> I think it would be good to test feasibility with some open BGP
> implementations and test to see if there are any major problems that come
> about before progressing.  This could be in a large virtual lab simulating
> the internet and with OAD and try to make things break to see if the change
> to the best path selection process causes any major problems.
>
> There are a few path attributes I see that could benefit from the change
> but there are already other path attributes that provide the same de
> preference of backup paths capabilities or any other policy type changes.
>
> If it’s not broken, don’t try to fix it.  I think that mantra applies to
> this type of change to BGP.
>
> I truly don’t think the benefits outweigh the risk.
>
> As well as the possible implementation bugs that could crop up.  OMG!  I
> hope I am retired before then.
>
> Gyan
> On Mon, Jul 10, 2023 at 4:25 PM Robert Raszuk <[e-mail]> wrote:
>
>> Hi,
>>
>> The subject draft says:
>>
>> *3.3. NEXT_HOP*
>>
>>
>> *The NEXT_HOP attribute is a well-known mandatory BGP path attribute
>> [RFC4271] that MUST be present in UPDATE messages sent over EBGP-OAD
>> sessions. The origination and modification of the NEXT_HOP attribute MUST
>> comply with the EBGP-related specification in [RFC4271].*
>>
>> Well I am afraid this is wrong on multiple grounds.
>>
>> The reason to state this is that RFC4760 made NEXT_HOP attribute
>> optional. It is no longer mandatory as next hop information is carried in
>> MP_REACH_NLRI attribute.
>>
>> Moreover most protocol enhancements and in fact all which seems
>> applicable to the author's goal went into defining NEXT_HOP information
>> encoded in MP_REACH and not carried in standalone attributes.
>>
>> In fact RFC7606 very clearly highlights how NEXT_HOP path
>> attribute became optional if we negotiate MP capability in section 3d:
>>
>>
>>
>>
>> *   d.  If any of the well-known mandatory attributes are not present in
>>      an UPDATE message, then "treat-as-withdraw" MUST be used.  (Note
>>  that [RFC4760] reclassifies NEXT_HOP as what is effectively
>>  discretionary.)*
>>
>> Observing the history there is still confusion among vendors and
>> customers if standalone NEXT-HOP Attribute should be still sent in spite of
>> MP capability or not.
>>
>> However it is clear that it would not be a great idea to suddenly make it
>> mandatory for BGP-OAD.
>>
>> Thx,
>> R.
>>
>> PS. Yes, its mandatory nature as defined in RFC4271 was never formally
>> relaxed. But it really does not make any sense to send the same information
>> twice ... and it makes UPDATES much more fragile if they happen to contain
>> different data formats.
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*