Subject: [sidr] draft-ietf-sidr-origin-validation-signaling - new version submitted recently... WGLC?

From: Chris Morrow <[email-masked]>
Date: Wed, 23 Oct 2013 10:47:56 -0400

I believe the authors wanted this to progress, I believe there was
recently (8/29/2013) an updated version submitted, does it deal with the
outstanding comments? (the diff doesn't show much more than
boilerplate-like changes)

Should this be WGLC'd at this point?

-chris
co-chair-type-item

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Oct 2013 11:35:04 -0400

yes, do proceed to WGLC.

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Jay Borkenhagen <[email-masked]>
Date: Thu, 24 Oct 2013 13:52:47 -0400

> Should this be WGLC'd at this point?

Hi,

A couple comments.

http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-03
refers to "[I-D.ietf-sidr-pfx-validate]", but that has been published
as rfc6811.

The paragraph in Section 2 where that reference occurs says:

===============

   Note that routers do not perform prefix origin validation (compute
   the validation state as defined in [I-D.ietf-sidr-pfx-validate])
   for IBGP learnt routes.

===============

... but rfc6811 does not prohibit performing prefix origin validation
for IBGP learnt routes.  In a network where all edge routers are
capable and configured to perform prefix origin validation on EBGP
learnt routes it should not be necessary to perform that function also
on IBGP learnt routes, but in general doing so should not be
prohibited.  The current statement in
draft-ietf-sidr-origin-validation-signaling-03 is too strongly
worded. 

Thanks.

						Jay B.

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 Oct 2013 20:07:42 +0200

> the validation state as defined in [I-D.ietf-sidr-pfx-validate])

that is opposite of 6811 and running code

   When a BGP speaker receives an UPDATE from a neighbor, it SHOULD
   perform a lookup as described above for each of the Routes in the
   UPDATE message.  The lookup SHOULD also be applied to routes that are
   redistributed into BGP from another source, such as another protocol
   or a locally defined static route.

> In a network where all edge routers are capable and configured to
> perform prefix origin validation on EBGP learnt routes it should not
> be necessary to perform that function also on IBGP learnt routes

internal router A has a nail-up for prefix P which it gates to ibgp.  it
is not (yet) validation capable, so does not realize it was fat fingered
and does not own P.  it announces ibgp to B, a border router within the
AS which is validation enabled.  you want B to catch the fat finger and
not propagate it to a neighbor whose noc then calls you to tell you that
you have net bad breath.

validation of routes locally originated and those heard via ibgp is good
sanitation.

randy