Subject: Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Jul 2020 11:21:57 +0200

Hi,

I have two small suggestions about this document.

1.

I think current suggestion of NLRI content to include peer IP address is
very unfortunate. I would recommend to replace it with either sender IP
address or policy group ID.

Why ? As the target of the policy will be already included in the wide
communities and may conflict or extend the currently defined NLRI value.

For example if you ask to apply policy X to ASN 100 it does not matter what
peer address is.

If you need policy to be applicable to a specific peering point just also
encode it consistently within the wide community itself.

2.

While the text is clear that such policy would apply to inbound and
outbound peers I think it would be good to state that this is about
external policy propagation.

Unless you also intend to push internal policies which would be a
completely different game.

Many thx,
R.

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 4 Jul 2020 02:37:37 +0000

Hi Robert,

    Thank you very much for your comments.

    Our answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo on behalf of authors
________________________________
From: Robert Raszuk <[email-masked]>
Sent: Wednesday, July 1, 2020 5:21 AM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt

Hi,

1.

I think current suggestion of NLRI content to include peer IP address is very unfortunate. I would recommend to replace it with either sender IP address or policy group ID.

Why ? As the target of the policy will be already included in the wide communities and may conflict or extend the currently defined NLRI value.

For example if you ask to apply policy X to ASN 100 it does not matter what peer address is.

If you need policy to be applicable to a specific peering point just also encode it consistently within the wide community itself.

[HC]: When a router A receives a policy X (say from a controller), router A may have a few other peers. The peer IP address indicates a specific peer (of router A) among these few peers to which the policy applies if the address is not 0. If the address is 0, the policy applies to all these peers. Using the peer IP address to indicate a specific peer for the policy can eliminate the unnecessary work that the others do to process and filter the policy. This may improve the efficiency.

2.

While the text is clear that such policy would apply to inbound and outbound peers I think it would be good to state that this is about external policy propagation.

Unless you also intend to push internal policies which would be a completely different game.

[HC]: We will state something like it is about external policy propagation in general.

Many thx,
R.

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 4 Jul 2020 03:07:54 +0000

Hi Gyan,

Best Regards,
Huaimo
________________________________
From: Gyan Mishra <[email-masked]>
Sent: Wednesday, July 1, 2020 12:30 AM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt

Hi Huaimo

Few more questions in-line

Thank you

Gyan

On Tue, Jun 30, 2020 at 8:53 PM Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Best Regards,

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 22, 2020 7:15 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt

Authors

Few comments

In the abstract and introduction it mentions adjusting traffic.  When reading the abstract and introduction adjusting traffic the first thing I think of when saying adjusting is BGP QOS QPPB policy to rate limit BGP traffic.

[HC]: It seems that the way (or say RPD) in which the traffic is adjusted in the draft and BGP QOS QPPB are different. The BGP QOS QPPB is based on configurations or commands. Different configurations for different parts of the network need to be done. These configurations combined with the BGP propagation provides some QoS policy on some traffic. The RPD provides a way to adjust the traffic (i.e., adjust the route attributes to redirect the traffic to the less used links) automatically without those configurations on different parts of the network.

    Gyan> The point here I was trying to make is that in the intro and draft you mention adjusting traffic to me that means BGP QOS rate limiting which may also be accomplished by RPD, but I think what may better represent RPD is stating RPD accomplishes the goal of automated update of  complex multi active routing policy using a centralized PCE controller using large communities atoms containers for policy granularity and flexibility.

https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-05<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-pce-pcep-extension-native-ip-05&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C492cf6fac93c4fec423808d81d778cb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637291746592317776&sdata=vKshhIwypzgBA2QOxMHgAuI%2Fzba6ONcuBY1aJ8CD0W0%3D&reserved=0>

[HC]: We will add some text into Section 1 "Introduction" to state something like RPD with a central controller accomplishes automatic update of complex multi active routing policy. The controller uses wide communities containers for policy granularity and flexibility.

In general routing policy is pretty straight forward with active / backup routing policy.

However when optimal active/ active all active routing optimization is required where geographic region based routing is desired and if routing control optimization is desired between both peering AS’s , the policy can become very complex and unmanageable.  If routing control policy is on one side only, the other side AS back hauls based on peering policy the policy is complex but manageable.  However optimized routing so both sides of peering does not back haul can be very complex.

There are many peering scenario and this one above  is a dual transit as all active peering policy scenario.

The above relates to AFI /SAFI 1/1 2/1 and can be accomplished with standard communities.

[HC]: The above can be achieved using standard communities, but can be very complex as you said. Using the RPD in stead of the standard communities can reduce the complexity greatly and can adjust the route attributes without configurations for some parts of the network to redirect the service traffic from the heavy-loaded links to the links with light traffic. Thus the network resource is effectively used and the QoE is improved. For example, in one metro area network without using the RPD, planning and implementing a redirection of a service traffic (coming to and exiting from a router) takes days. After the RPD is deployed in the network with a controller NCE, this takes just minutes instead of days.

I would say auto adjustment of active routing paths routing where routing control is required on both sides of peering to enable optimized paths

[HC]: The RPD can be used for automatically adjusting active routing paths on the both sides of a peer if it is required and permitted. In the case where the two sides of a peer are two different ISPs (say ISPa and ISPb) and each side (ISP) does not allow the other to control its network, when ISPa adjusts routing paths, it can not control the network owned by ISPb directly.

   Gyan> Understood.  In this particular case it would have to be coordinated as exchange is between administrative domains, but in this case RPD automatic large communities policy update can be accomplished via centralized PCE controller.

I noticed you have AFI/SAFI codepoint request for RPD.  Would this be just a SAFI request similar to any other SAFI such as BGP flowspec safi 133 134

https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fsafi-namespace%2Fsafi-namespace.xhtml&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C492cf6fac93c4fec423808d81d778cb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637291746592327773&sdata=PCG2dpgie3PkNbnRmBvmvXMmJzIHyjJVVphud1jFbR8%3D&reserved=0>

[HC]: AFI/SAFI codepoint request for RPD is similar to AFI/SAFI codepoint request for any other.

It would nice to see maybe in an appendix an example of the large communities atoms containers of the RPD automated proxy use case of how a complex policy translated into RPD policy provides tremendous simplicity in provisioning policy updates.

Kind Regards

Gyan

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C492cf6fac93c4fec423808d81d778cb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637291746592327773&sdata=d7FTXFRMrZj%2BThY6XTl2EMpEJxyeK9SuCeLfO2USjFw%3D&reserved=0>

<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C492cf6fac93c4fec423808d81d778cb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637291746592337767&sdata=o2Gv6iypdfqZYTmT6tQIzx9KRJf1pqLT2%2BbhHuhUuPA%3D&reserved=0>Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C492cf6fac93c4fec423808d81d778cb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637291746592347764&sdata=h9jIJgQtPikUZXEmAoMpYXEpYVAlWxYN07uHKUIU0e8%3D&reserved=0>
Silver Spring, MD<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C492cf6fac93c4fec423808d81d778cb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637291746592347764&sdata=h9jIJgQtPikUZXEmAoMpYXEpYVAlWxYN07uHKUIU0e8%3D&reserved=0>

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C492cf6fac93c4fec423808d81d778cb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637291746592357759&sdata=w0R9mtvQl3A2F0keOZ8RXb%2BjF3hnwb%2BL3XGBL7tFtjM%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 4 Jul 2020 12:18:10 +0200

Hi Huaimo,

If I am reading your response correctly regarding point #1 then you are
really turning BGP into p2p configuration push. That is not what BGP is
for. I recommend we do not do that.

That BGP update will be sent to *every* BGP speaker in the domain talking
your new SAFI unless you go to next level and use prefix ORF to push all of
your peers IP address to say RR. This is getting very very ugly.

Note pls that you already can share policy among many peers by either
listing peers explicitely in the wide community or include there their
ASN(s). The peer IP address as key in the NLRI will break all of this
completely.

I recommend you reconsider.

Thx,
R.

On Sat, Jul 4, 2020 at 4:37 AM Huaimo Chen <[email-masked]>
wrote:

> ------------------------------
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, July 1, 2020 5:21 AM
> *To:* Huaimo Chen <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt
>
> Hi,
>
> [HC]: When a router A receives a policy X (say from a controller), router
> A may have a few other peers. The peer IP address indicates a specific peer
> (of router A) among these few peers to which the policy applies if the
> address is not 0. If the address is 0, the policy applies to all these
> peers. Using the peer IP address to indicate a specific peer for the policy
> can eliminate the unnecessary work that the others do to process and filter
> the policy. This may improve the efficiency.
>
> 2.
>

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 7 Jul 2020 00:33:47 +0000

Hi Robert,

    Our answer/explanation is inline below with prefix [HC].

Best Regards,

Sent: Saturday, July 4, 2020 6:18 AM

Hi Huaimo,

If I am reading your response correctly regarding point #1 then you are really turning BGP into p2p configuration push. That is not what BGP is for. I recommend we do not do that.

That BGP update will be sent to *every* BGP speaker in the domain talking your new SAFI unless you go to next level and use prefix ORF to push all of your peers IP address to say RR. This is getting very very ugly.

Note pls that you already can share policy among many peers by either listing peers explicitely in the wide community or include there their ASN(s). The peer IP address as key in the NLRI will break all of this completely.

[HC]:  The value 0 in the peer IP address field means that the BGP update is sent to every BGP speaker, which is the default. We will add some text into the document to state that this field is set to 0 for now normally.

Thx,
R.

On Sat, Jul 4, 2020 at 4:37 AM Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Best Regards,
Huaimo on behalf of authors
________________________________
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 1, 2020 5:21 AM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt

Hi,

1.

2.

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 7 Jul 2020 11:32:42 +0200

Huaimo,

In BGP (across all known AFI/SAFIs) NLRI field is a key to all other
information contained in the attached attributes.

It is never a filter to whom BGP UPDATE MSG applies.

Just think about withdraw ... Imagine you have 1000 BGP speakers. 800 of
them have eBGP sessions. If you have policy which needs to be applied to
your speakers which terminate eBGP sessions then you need to send 800 times
the new UPDATE msg instead of just 1 !

You are breaking most useful remains of BGP fundamental scaling properties
pretty badly here.

Besides those target peers can be already grouped and placed in the wide
community anyway so any filtering at NLRI level is pointless.

Kind regards,
R.

On Tue, Jul 7, 2020 at 2:33 AM Huaimo Chen <[email-masked]>
wrote:

> *Sent:* Saturday, July 4, 2020 6:18 AM
> [HC]:  The value 0 in the peer IP address field means that the BGP update
> is sent to every BGP speaker, which is the default. We will add some text
> into the document to state that this field is set to 0 for now normally.
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>