Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)

[Gyan Mishra <[e-mail]>]

Authors

I read through the draft again and based on the comments thus far trying to
see what gap this draft is addressing that does not exist exist today.

I have commented on this draft earlier on before WGLC and from what I
remember the result of the comments was that this draft is for Non SR or
MPLS and solely for pure IP based networks that require routing policy push
and no traffic steering in the context of PCE based path steering
instantiation that already exists today.

This is purely a policy push concept using BGP large communities new path
attribute container to accomplish the task.

So with that the idea is that this would accomplished by a centralized
controller.

Looking at controller based instantiation you start thinking PCE and BGP LS
for IGP path attributes propagation to the PCE, however in this particular
case we are not doing any traffic steering.

So from thinking PCE and IP based steering got me thinking about this draft
which I see a few authors are on this draft as well.

https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-09

So bottom line is this new MP Reach AFI SAFI code point assigned for IP
based routing control point only which can be managed with a centralized
controller doing the policy push via the new AFI SAFI code point.

One complex design I had worked on years ago which I mentioned in the prior
thread was based on standard community architecture where both sides are a
control point  multi active routing based on communities set.  Imagine you
have two MPLS core transports and have a edge CE that is connected as many
different locations all around the world and you want you tag all CEs off
each core with discrete communities and now you have a special perpending
pattern let’s say it’s 3 ties to make it easy and it’s 0x 2x 3x and so now
you match communities and set a prepend.  So now you duplicate that on both
sides so you don’t backhaul across the other core so you geographically
optimally route between each core over all the many tie points.  This does
get extremely complex but back then it worked and was all accomplished via
standard communities and to this day is still working, however of course
management of the policy changes is still a very very complex task.

So now this use case given could use Roberts Large communities draft and
apply this RPD  new routing policy AFI SAFI to make changes to a complex IP
policy deployment now becomes very simple deploy and manage for day to day
operations.

Based on what I have stated I support advancement of the draft with a
caveat.  I would like to add my use case to the draft and I think that
would help tremendously in explaining the gap and use case being addressed
by this draft.


Kind Regards

Gyan

On Fri, Jul 24, 2020 at 5:24 PM Robert Raszuk <[e-mail]> wrote:

>
> In addition to points already mentioned let's examine what the draft
> actually defines ... not sure if this is just the tip of the iceberg or
> full set of match and set tools authors envision to have.
>
> Match:
>
> IPv4 prefix,
> IPv6 prefix,
> AS-PATH regex
> Community
>
> Set:
>
> MED,
> Arbitrary AS-PATH
>
>
> - So first don't we see a need to match on Peer's ASN ?
> - Don't we need to match on the peer ? (NLRI itself just matches on
> the ASBR making it p2p)
> - How about to match on link bandwidth to the specific peer ?
> - The draft talks about outbound traffic engineering from local AS  ...
> well that is done typically by setting local preference which is not even
> mentioned in the document
> - The defined community sub-TLV merely covers RFC1997. How about Extended
> or Large Communities ? No use ? No need to match ?
>
> Kind regards,
> R.
>
>
> On Fri, Jul 24, 2020 at 10:28 PM Jakob Heitz (jheitz) <jheitz=
> [e-mail]> wrote:
>
>> Let me try a different way.
>>
>> Flowspec is designed to install a filter everywhere to mitigate DDoS.
>>
>> Even if the filter does not install in a few routers, the DDoS is still
>> mitigated.
>>
>> It does not matter which nodes install it before other nodes.
>>
>> Therefore, the spray and pray of BGP is ok for Flowspec.
>>
>>
>>
>> Routing policy distribution could cause unpleasant routing transients if
>>
>> it is not installed or installed late on random nodes.
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* Wanghaibo (Rainsword) <[e-mail]>
>> *Sent:* Thursday, July 23, 2020 11:23 PM
>> *To:* Jakob Heitz (jheitz) <[e-mail]>; Huaimo Chen <
>> [e-mail]>; Susan Hares <[e-mail]>; idr@ietf..org
>> *Subject:* RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
>> 7/29/2020)
>>
>>
>>
>> Hi Jakob,
>>
>>
>>
>> Can you give some more details about "the route and the flowspec spray
>> to the same places“
>>
>>
>>
>> Regards,
>>
>> Haibo
>>
>>
>>
>> *From:* Jakob Heitz (jheitz) [mailto:[e-mail] <[e-mail]>]
>>
>> *Sent:* Friday, July 24, 2020 1:31 AM
>> *To:* Wanghaibo (Rainsword) <[e-mail]>; Huaimo Chen <
>> [e-mail]>; Susan Hares <[e-mail]>; [e-mail]
>> *Subject:* RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
>> 7/29/2020)
>>
>>
>>
>> You're missing the point.
>>
>>
>>
>> The fact that BGP is spray and pray doesn't matter, because the route and
>> the
>>
>> flowspec spray to the same places.
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* Wanghaibo (Rainsword) <[e-mail]>
>> *Sent:* Thursday, July 23, 2020 12:02 AM
>> *To:* Jakob Heitz (jheitz) <[e-mail]>; Huaimo Chen <
>> [e-mail]>; Susan Hares <[e-mail]>; [e-mail]
>> *Subject:* RE: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
>> 7/29/2020)
>>
>>
>>
>> Hi Jakob,
>>
>>
>>
>> 1.  Flowspec’s validation is used to check whether a device can learn the
>> Flowspec routes from an EBGP peer, but the validation can be performed only
>> for the component of the destination type.
>>
>>     In practice, the centralized server or controller is often used to
>> send FlowSpec routes to devices.
>>
>> 2.  RPD and SR-Policy also have their own validation. That is, route
>> targets are used to check whether information is sent to the expected node.
>>
>>
>>
>> Regards,
>>
>> Haibo
>>
>>
>>
>> *From:* Idr [mailto:[e-mail] <idr-bounces@ietf...org>] *On
>> Behalf Of *Jakob Heitz (jheitz)
>> *Sent:* Tuesday, July 21, 2020 12:52 PM
>> *To:* Huaimo Chen <[e-mail]>; Susan Hares <
>> [e-mail]>; [e-mail]
>> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
>> 7/29/2020)
>>
>>
>>
>> There is an important difference between RPD and Flowspec.
>>
>> https://tools.ietf.org/html/rfc5575#section-6
>>
>> states:
>>
>>    A flow specification NLRI must be validated such that it is
>>
>>    considered feasible if and only if:
>>
>>
>>
>>    a) The originator of the flow specification matches the originator of
>>
>>       the best-match unicast route for the destination prefix embedded
>>
>>       in the flow specification.
>>
>>
>>
>>    b) There are no more specific unicast routes, when compared with the
>>
>>       flow destination prefix, that have been received from a different
>>
>>       neighboring AS than the best-match unicast route, which has been
>>
>>       determined in step a).
>>
>>
>>
>> Effectively, the advertisement of the route takes the same vector as the
>>
>> advertisement of the matching flowspec. Therefore, if the flowspec did not
>>
>> reach a node, then the route likely didn't either, so it doesn't matter.
>>
>>
>>
>> The fact that BGP is spray and pray doesn't matter, because the route and
>> the
>>
>> flowspec spray to the same places.
>>
>>
>>
>> RPD policy distribution has no such validation rule.
>>
>>
>>
>> SR policy distribution suffers from the same problem.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* Huaimo Chen <[e-mail]>
>> *Sent:* Monday, July 20, 2020 9:01 PM
>> *To:* Jakob Heitz (jheitz) <[e-mail]>; Susan Hares <
>> [e-mail]>; [e-mail]
>> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
>> 7/29/2020)
>>
>>
>>
>> Hi Jakob,
>>
>>
>>
>>     Thank you very much for your valuable comments.
>>
>>     Our answers/explanations are inline below with prefix [HC].
>>
>>
>>
>> Best Regards,
>>
>> Huaimo on behalf of co-authors
>> ------------------------------
>>
>> *From:* Idr <[e-mail]> on behalf of Jakob Heitz (jheitz) <
>> jheitz=[e-mail]..org <jheitz=40cisco.com@dmarc..ietf.org>>
>> *Sent:* Thursday, July 16, 2020 9:01 PM
>> *To:* Susan Hares <[e-mail]>; [e-mail] <[e-mail]>
>> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to
>> 7/29/2020)
>>
>>
>>
>> BGP seems the wrong way to distribute routing policy.
>>
>>
>>
>> [HC]: It seems that BGP flow spec has been used widely to distribute
>> policies for redirecting the traffic. It seems work well without some
>> mechanisms in Netconf. BGP RPD should be similar to BGP flow spec.  BGP SR
>> Policy is on the same train.
>>
>>
>>
>> IETF has already defined a way to distribute configuration: Netconf.
>>
>> Netconf provides needed features that BGP does not have:
>>
>> - Atomic Transactions:
>>
>>   If one configuration item fails, they all fail.
>>
>>   They all either succeed or all fail. There is no partial success.
>>
>>   Multiple configurations in one transaction are applied at the same time.
>>
>>    . This avoids non-deterministic transient behavior between application
>> of the first policy and the last.
>>
>> - Feedback:
>>
>>   BGP is "spray and pray".
>>
>>   Netconf provides an acknowledgement that the config either failed or
>> was applied,
>>
>>   which then allows the controller to take the next steps with
>>
>>   reliable information about what configuration exists in the network.
>>
>> - Persistence:
>>
>>   If the BGP session were to go down, all the configuration it sent will
>> be implicitly withdrawn.
>>
>>
>>
>> If another AS would not allow a foreign AS to configure it with netconf,
>>
>> it would not allow it with RPD either.
>>
>>
>>
>> There are already ways in BGP for an AS to signal preference across AS
>> boundaries:
>>
>> Med, AS-path length, communities.
>>
>>
>>
>> [HC]: Netconf can be used to distribute configurations from a controller
>> to the devices in a network. BGP RPD as an alternative option, may have
>> some advantages in some cases. For example, in the case where BGP as a
>> controller, BGP RPD seems more suitable. Using BGP RPD to control/redirect
>> the traffic dynamically in real time may be more effective.
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* Idr <[e-mail]> *On Behalf Of *Susan Hares
>> *Sent:* Wednesday, July 15, 2020 6:11 AM
>> *To:* [e-mail]
>> *Subject:* [Idr] WG LC on draft-ietf-idr-rpd-05.txt (7/15 to 7/29/2020)
>>
>>
>>
>> This begins a 2 week WG LC on draft-ietf-idr-rpd
>>
>> from 7/15 to 7/29/2020.  You can obtain this draft at:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rpd%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C12cf72daefe0446d5a7908d829ed0a36%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637305445341383523&sdata=3LvgG6xwElOv27jGetqpyk8ftRub%2B%2B4Ui31Yt8wN87A%3D&reserved=0>
>>
>>
>>
>> This draft defines a new AFI/SAFI and new atoms
>>
>> for the Wide Communities.  This WG LC has been delayed
>>
>> as I waited for a resubmission of the Wide Communities draft.
>>
>> I had hoped to do these 2 WG LC in parallel.
>>
>>
>>
>> I’ve not received the Wide Communities draft, but we will
>>
>> start this WGLC to provide feedback to the authors.
>>
>> We may have to run a short follow-up to this WG LC
>>
>> If there are changes to the Wide Communities draft during
>>
>> Its WG LC.
>>
>>
>>
>> There is an IPR statement on this draft.
>>
>>
>>
>> In your responses please answer the following questions:
>>
>>
>>
>> 1) Do you feel this draft has an solution that is acceptable
>>
>>    With the IPR as a WG RFC?
>>
>>
>>
>> 2) Do you feel this draft is ready to publish?
>>
>>
>>
>> 3) Do you know of implementations of this draft?
>>
>>
>>
>> 4) Do you know of deployments of this draft?
>>
>> If so, is this feature useful in the deploy ments.
>>
>>
>>
>> 5) Do you feel that Wide Communities is ready for
>>
>> Publication?
>>
>>
>>
>> Cheerily, Susan Hares
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD