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

From: Robert Sparks via Datatracker <[email-masked]>
Date: Fri, 13 Mar 2020 08:16:27 -0700

Reviewer: Robert Sparks
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sidrops-ov-egress-01
Reviewer: Robert Sparks
Review Date: 2020-03-13
IETF LC End Date: 2020-03-18
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC

Very minor nit - feel free to ignore -

This sentence slowed me down when reading:

   As the origin AS may be modified by outbound policy, policy semantics
   based on RPKI Origin Validation state MUST be able to be applied
   separately on distribution into BGP and on egress.

I suggest something like:

  As the origin AS may be modified by outbound policy, a BGP speaker 
  MUST be able to apply policy semantics based on RPKI Origin Validation 
  state separately on distribution into BGP and on egress.

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Mar 2020 18:34:01 -0700

thanks for review robert,

>   state separately on distribution into BGP and on egress.

am i correct that you point is to make clear that this applies to the BGP
speaker?

i need to think.  clearly, the speaker will be applying the policy.  but
is it not the op configuring the policy which is deciding?  or is it
that you really want to MUST the application, a la

   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.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Mar 2020 20:26:36 -0700

> 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

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

randy

---

From: Robert Sparks <[email-masked]>
Date: Tue, 17 Mar 2020 22:18:43 -0500

> am i correct that you point is to make clear that this applies to the BGP

Yes, mostly that.

I wanted to avoid "be able to be" and have an explicit actor. I see the 
difficulty you point to below.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 17 Mar 2020 22:37:32 -0500

I like that and hope it's acceptable to the community.

But it was a very small nit - if it turns out to be problematic, I'm ok 
leaving things as they were.

RjS

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Mar 2020 20:55:54 -0700

> But it was a very small nit - if it turns out to be problematic, I'm
> ok leaving things as they were.

our illustrious AD is fond of specific references to RFCs and other
formal wording.  :)

randy

---

From: Keyur Patel <[email-masked]>
Date: Wed, 18 Mar 2020 18:05:28 +0000

Speaking as a wg member.

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 

    

    
    randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 18 Mar 2020 12:56:28 -0700

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

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.

randy

---

From: Keyur Patel <[email-masked]>
Date: Wed, 18 Mar 2020 23:55:01 +0000

On 3/18/20, 12:56 PM, "Randy Bush" <[email-masked]> wrote:

    

    
    
    so maybe

Looks good to me. __ 

Regards,
Keyur
    
    randy

---

From: Ben Maddison <[email-masked]>
Date: Fri, 20 Mar 2020 10:11:20 +0000

On Wed, 2020-03-18 at 12:56 -0700, Randy Bush wrote:
> > > > number

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Mar 2020 11:29:39 -0700

>     apply Route Origin Validation policy semantics Against the Route

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

---

From: Ben Maddison <[email-masked]>
Date: Fri, 20 Mar 2020 18:38:00 +0000

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<https://aka.ms/ghei36>

________________________________
From: Randy Bush <[email-masked]>
Sent: Friday, 20 March 2020, 20:29
To: Ben Maddison
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Mar 2020 11:42:47 -0700

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Mar 2020 11:47:33 -0700

>    put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the

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

---

From: Job Snijders <[email-masked]>
Date: Fri, 20 Mar 2020 18:48:51 +0000

>    put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the

Looks good to me.

Kind regards,

Job

---

From: Ben Maddison <[email-masked]>
Date: Fri, 20 Mar 2020 19:26:36 +0000

I think 6811 is the right ref for this. 8481 is the one you put in an RFP ;-)

I still prefer my wording, but this should be sufficiently hard to misinterpret.

Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Job Snijders <[email-masked]>
Sent: Friday, March 20, 2020 8:48:51 PM
To: Randy Bush <[email-masked]>
Cc: Ben Maddison <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Last-Call] [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01

Looks good to me.

Kind regards,

Job