Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

[Gyan Mishra <[e-mail]>]

Few comments on the latest draft.

In Section 6 at the very top can we change the verbiage describing OTC from
“transitive” to “optional transitive” as the BGP path attribute is not a
required transitive attribute.

Also since the this new OTC path attribute is set on the eBGP peering
session it is then propagated within the operators transit AS iBGP mesh.
For clarity it maybe good to mention the OTC attribute being set on the
eBGP peering and then being propagated within a providers network via iBGP
to other external peering.

Section 5 mentions role correction mismatch, however what if one side of
peering session supports and other side does not the session would not come
up similar to role mismatch.  I think text should be added for that
scenario.

It maybe a good idea in the appendix to specificity the logical functional
configuration that is auto generated from each of the role mode settings.
In some of the role modes it seems similar to no-export or no-advertise
community being set for all prefixes from a peer based on role mode.

Can the OTC optional transitive path attribute be used in BGP best path
selection process, and if so then RFC 4271 should be updated to reflect.

Once the OTC path attribute is set on a prefix similar to the concept of
BGP community setting, where you can append communities with “additive”
push function, or you can pop and reset or remove the pre existing
communities.  Can the OTC path attribute set on a set of prefixes be
removed once it’s set and can it be done inbound or outbound and on any
eBGP or iBGP session.

Kind Regards

Gyan

On Wed, Jun 17, 2020 at 8:45 AM Andrei Robachevsky <
[e-mail]> wrote:

> I read the latest version (draft-ietf-idr-bgp-open-policy-11) and agree
> that is it ready for publication.
>
> The only suggestion I may make it to be even more explicit about how
> roles and OTC are supposed to be set or not when announcing routes
> internally (e.g. iBGP). I am referring to the issue that Pavel Lunin
> brought up. I think a sentence in the Introduction explaining the scope
> would help.
>
> Andrei
>
>
> Susan Hares wrote on 04/06/2020 23:19:
> > This begins a 2 week WG LC for draft-ietf-idr-bgp-open-policy-10.txt
> >
> > From 6/4 to 6/18/2020.
> >
> >
> >
> > There are 3 implementations:   BIRD (1.76, 2.05) , FRR, and Mikrotik.
> >
> > The BIRD and FRR implementations interoperate.
> >
> > I do not have details on Mikrotik.
> >
> >
> >
> > Details on the  interoperability are on the following IDR wiki page:
> >
> > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy
> >
> >
> >
> > Only one  error handling issues exists on the ability of BIRD
> >
> > to send Role Mismatch (Open Error (2), subcode 8).
> >
> > Another protocol was assigned to subcode 8.
> >
> >
> >
> > Please comment on the following questions:
> >
> > 1) Is this specification ready for publication?
> >
> > 2) Are there deployments where this BGP protocol extension is valuable?
> >
> > 3) Do you believe the error code handling is ready for publication?
> >
> >
> >
> > The shepherd for this draft is Susan Hares.
> >
> > During the WG LC, the shepherd’s report will be sent.
> >
> >
> >
> > Cheers,
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> >
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD