Subject: [Idr] comment in jabber room missed

From: Sandra Murphy <[email-masked]>
Date: Wed, 29 Oct 2014 12:09:57 -0400

Jeff, I noted that there was a comment from you in the jabber room shortly before we ended:

"And by strip, you effectively have to re-originate the route."

I'm not sure what you mean by "re-originate the route".

What you produce when you strip the BGPSEC_Path attribute is an update with the extracted AS_PATH (and any other attributes propagated or inserted locally) appended with your AS_PATH as usual.

If you are thinking that when 789 is stripping a BGPSEC_PATH attribute that mentions 567…345….123 it would send a route with AS_PATH == 789, that is not the case.  It would send a route with AS_PATH = 789, 567, 345, 123.

If that's what you meant, I need to be clear in speaker notes what actually happens.

If you meant something else by "re-originate the route", then maybe the speaker notes don't need modification.

--Sandy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 30 Oct 2014 09:39:15 -0400

Sandy,

On Wed, Oct 29, 2014 at 12:09:57PM -0400, Sandra Murphy wrote:
> If you are thinking that when 789 is stripping a BGPSEC_PATH attribute that mentions 567?345?.123 it would send a route with AS_PATH == 789, that is not the case.  It would send a route with AS_PATH = 789, 567, 345, 123.
> 

The comment was made at the time regarding discussion about how private ASes
were removed in a bgpsec context.

-- Jeff

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 30 Oct 2014 12:34:11 -0400

> were removed in a bgpsec context.

Ah!  Well, that makes much more sense.

Yes, if you are stripping private ASs from the path, then you are effectively originating a route to the prefix.

(The private AS case is probably good to consider carefully.  I have heard of cases where the AS path has a mix of private and global AS numbers, where those are deliberate, not oop's.  Tho' how that works now is not clear to me.)

--Sandy