Re: [Gen-art] [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01

[Randy Bush]

>As the origin AS of a BGP UPDATE is decided by configuration and
>outbound policy of the BGP speaker, a validating BGP speaker MUST
>apply Route Origin Validation policy semantics (see [RFC6811] Sec 2)
>against the origin Autonomous System number which will actually be
>put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the
>UPDATE to the peer.

actually, 8481 sec 4 might be a stronger hammer.  whatcha think?

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01

[Randy Bush]

> Having spend the better part of last week stepping a vendor through
> exactly these semantics

while there is no proof of termination of clue insertion, that a BGP/ROV
*implementor* did not get it, justifies the hack.

   As the origin AS of a BGP UPDATE is decided by configuration and
   outbound policy of the BGP speaker, a validating BGP speaker MUST
   apply Route Origin Validation policy semantics (see [RFC6811] Sec 2)
   against the origin Autonomous System number which will actually be
   put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the
   UPDATE to the peer.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01

[Ben Maddison]

It doesn't clarify anything for me, but then I happen to know where that 
algorithm is defined.

Having spend the better part of last week stepping a vendor through exactly 
these semantics, my current mood is that explicit and specific is better.

The intent in having the ref where it is, is to point at the AS_PATH => Origin 
As mapping procedure, rather than that section more generally.

Cheers,

Ben

Get Outlook for Android


From: Randy Bush 
Sent: Friday, 20 March 2020, 20:29
To: Ben Maddison
Cc: ke...@arrcus.com; last-c...@ietf.org; rjspa...@nostrum.com; 
sidr...@ietf.org; gen-art@ietf.org; draft-ietf-sidrops-ov-egress@ietf.org
Subject: Re: [Sidrops] Genart last call review of 
draft-ietf-sidrops-ov-egress-01

> Although a little more verbose, perhaps the following is more explicit?
>
> As the origin AS of a BGP UPDATE is decided by configuration and
> outbound policy of the BGP speaker, a validating BGP speaker MUST
> apply Route Origin Validation policy semantics Against the Route
> Origin ASN as determined by applying the procedure in [RFC6811,
> Section 2] to the AS_PATH (see RFC 4271 4.3 Path Attributes:b) that
> it will send in the UPDATE to the peer.

i am torn about adding yet another 6811 ref.  does it clarify anything?
are there other possible "Route Origin Validation policy semantics?"

if so, i might put it earlier, after "apply Route Origin Validation
policy semantics".

randy

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01

[Randy Bush]

> Although a little more verbose, perhaps the following is more explicit?
> 
> As the origin AS of a BGP UPDATE is decided by configuration and
> outbound policy of the BGP speaker, a validating BGP speaker MUST
> apply Route Origin Validation policy semantics Against the Route
> Origin ASN as determined by applying the procedure in [RFC6811,
> Section 2] to the AS_PATH (see RFC 4271 4.3 Path Attributes:b) that
> it will send in the UPDATE to the peer.

i am torn about adding yet another 6811 ref.  does it clarify anything?
are there other possible "Route Origin Validation policy semantics?"

if so, i might put it earlier, after "apply Route Origin Validation
policy semantics".

randy

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01

[Ben Maddison]

On Wed, 2020-03-18 at 12:56 -0700, Randy Bush wrote:
> ( warning: quote depth errors and top posting.  keyur's mta, well
> let's
> not get into that :)
> 
> > Speaking as a wg member.
> 
> and one of the first ROV implementors, tyvm.
> 
> > Shouldn’t you be checking the "my autonomous system number" in the
> > update message (when sending it out to the ebgp peer) as opposed to
> > "my autonomous system number" in the open message.
> > 
> > Regards, Keyur
> > 
> > On 3/17/20, 8:27 PM, "Randy Bush"  wrote:
> > 
> > > I wanted to avoid "be able to be" and have an explicit actor. I
> > > see
> > > the difficulty you point to below.
> > 
> > i am happy to change to the following
> > 
> > > > As the origin AS may be modified by outbound policy, a BGP
> > > > speaker
> > > > MUST apply ROV policy semantics using the My Autonomous System
> > > > number
> > > > in the BGP OPEN message (see RFC 4271 section 4.2) issued to
> > > > the peer
> > > > to which the UPDATE is being sent.
> > 
> > but, in my free opinion, as it is in IETF LC, the change is enough
> > that
> > it might require approval by chairs and/or AD.
> 
> i think you're right.  what counts for ROV is the origin AS in the
> UPDATE.  open a hole to deviate from that and ...
> 
> and we have to remember that, for these UPDATEs which are
> redistributed
> into BGP by this speaker, have their AS_PATH first created when sent
> to
> the peer.  i.e. we can not (yet) speak of the origin AS in the
> AS_PATH.
> 
> so maybe
> 
> As the origin AS of a BGP UPDATE is decided by configuration and
> outbound policy of the BGP speaker, a validating BGP speaker MUST
> apply Route Origin Validation policy semantics against the origin
> Autonomous System number which it will put in the AS_PATH (see
> RFC
> 4271 4.3 Path Attributes:b) of the UPDATE to the peer.
> 

Although a little more verbose, perhaps the following is more explicit?

As the origin AS of a BGP UPDATE is decided by configuration and
outbound policy of the BGP speaker, a validating BGP speaker MUST
apply Route Origin Validation policy semantics against the Route
Origin ASN as determined by applying the procedure in [RFC6811,
Section 2] to the AS_PATH (see RFC 4271 4.3 Path Attributes:b) that
it will send in the UPDATE to the peer.

Cheers,

Ben

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art