Re: [Idr] One Admin Domain

>  That draft looks fine. Was it ever submitted? I can't find it in a
search.

https://tools.ietf.org/html/draft-uttaro-idr-oad-01

r.

On Wed, Apr 7, 2021 at 11:55 PM Jakob Heitz (jheitz) <jheitz=
40cisco.com@dmarc.ietf.org> wrote:

> Jim,
>
> That draft looks fine. Was it ever submitted? I can't find it in a search.
>
> I would add a mechanism to reduce the AS_PATH length.
> When sending out of the OAD, replace the sequence of ASNs in the
> OAD by a single configured master ASN.
> If a route is received by a speaker in any AS in the OAD from a speaker
> not in
> the OAD, then the master ASN in the AS_PATH counts as a loop.
>
> Regards,
> Jakob.
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of UTTARO, JAMES
> Sent: Wednesday, April 7, 2021 6:43 AM
> To: Jeffrey Haas <jhaas@pfrc.org>; Robert Raszuk <robert@raszuk.net>
> Cc: idr@ietf. org <idr@ietf.org>; Susan Hares <shares@ndzh.com>
> Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits -
> 3/30 to 4/13
>
> " I don't believe we're likely to come up with a simple answer to BGP
> capability domains soon.  That said, operators in a single administrative
> domain at least can figure this out themselves because they're the ones
> configuring it"
>
> This discussion illustrates that a single administrative domain spanning
> multiple ASes should be addressed. Pradosh, John Scudder and I began
> identifying how an OAD ( One Administrative Domain ) should behave in terms
> of an eBGP and OAD-eBGP learned paths. ( See Attached ).
>
> As an example if we offering RFC 1998 feature to a customer whose VPN
> spans multiple AS domains requires that the operator preserve or reset (
> default ) the LP. The customer may want to scope LP to a given AS or have
> it apply across an OAD.  As operators we have figured out how to create a
> somewhat seamless reachability/forwarding domain upon which services can be
> overlaid. That being said it maybe time to re-look at the scope of an AS
> vis-a-vis Admin domain including capabilities on a router, AS and OAD
> level..
>
> Thanks,
>         Jim Uttaro
>
>
>
>
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
> Sent: Wednesday, April 07, 2021 9:25 AM
> To: Robert Raszuk <robert@raszuk.net>
> Cc: idr@ietf. org <idr@ietf.org>; Susan Hares <shares@ndzh.com>
> Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits -
> 3/30 to 4/13
>
> Robert,
>
> I think you're mixing some of the points together.
>
> On Wed, Apr 07, 2021 at 12:29:21PM +0200, Robert Raszuk wrote:
> > I have a question on how practical this proposal is.
> >
> > Fundamental problem with today's BGP capabilities is that the information
> > is only known to the peer.
> >
> > So if I inject flowspec rule from behind the RR the RR will suppress some
> > updates but:
> >
> > * sender will have no clue about it
> > * any other flow spec BGP speaker which supports request filtering down
> the
> > BGP path will never get the chance to receive and apply the filter.
>
> This is explicitly acknowledged in section 5.
>
> It's also indistinguishable from policy.
>
> > Both are IMHO bad. The latter is in fact directly against flowspec spirit
> > to apply filtering as close to the src even if hops on the way are not
> > capable of doing so.
> >
> > So I am yet to be convinced this proposal is useful.
> >
> > Today as a general rule if a router does not support an extension
> received
> > via flowspec it just does not apply it but still can happily propagate
> the
> > update down the road.
>
> Not a single BGP flowspec implementation implemented the "opaque" property
> in RFC 5575.  Not one.  And it was the strong motivation to remove that
> text
> in RFC 8955.
>
> This may change in flowspec v2 where we likely will make the NLRI proper
> type-length-value rather than implied length as it is currently done.
>
> How well the argument to filter unsupported components stands once we're to
> something like flowspec v2 will be the longer question.  For such
> scenarios,
> once we're no longer concerned about propagation characteristics of the
> NLRI, it's quite reasoanble for a route reflector to carry NLRI with
> filtering components it doesn't understand - but edge devices may not want
> it.  But in that scenario, perhaps it's simply better for edge devices to
> accept it and simply not install it.
>
> > I think what we have here on the table is an illustration about the
> growing
> > need for domain wide (or set of domains under the same admin) capability
> > distribution such that all BGP speakers could advertise their
> > capabilities to interested parties. A bit broader than flowspec, but
> could
> > be useful here.
>
> At the day job, we talk about the "flooding domain" of new features that
> are
> gated on their capabilities.  BGP doesn't provide an explicit concept for
> this, but it's become a protocol intrinsic behavior.  Unless you configure
> a
> capability between two devices, it does't gain the ability to use the
> feature.  A contiguous set of devices using those capabilities becomes that
> domain.  That domain may, or may not, have strong overlap with one or more
> ASes under the control of one or more parties.
>
> For many BGP features, knowing what those domain boundaries are isn't much
> of a problem.  Flowspec implementations with disjoint capabilities is a
> place where it could be problematic.  (Again, see section 5.)
>
> ---
>
> I don't believe we're likely to come up with a simple answer to BGP
> capability domains soon.  That said, operators in a single administrative
> domain at least can figure this out themselves because they're the ones
> configuring it.
>
> Right now, we are unable to safely deploy new flowspec features. Even when
> you have disjoint flooding domains, if your flowspec rules are independent,
> you can gain benefit.  So, short term for flowspec v1, I think there's
> benefit for this feature.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!zKnvUXaBTauH415pLQgguhjbJ69dkTpI04OgwY3aoSSiPV4IGBB2u-MqG68$
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>