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

From: [email-masked]
Date: Tue, 09 Jun 2020 15:49:18 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : BGP Extensions for Routing Policy Distribution (RPD)
        Authors         : Zhenbin Li
                          Liang Ou
                          Yujia Luo
                          Sujian Lu
                          Huaimo Chen
                          Shunwan Zhuang
                          Haibo Wang
	Filename        : draft-ietf-idr-rpd-05.txt
	Pages           : 18
	Date            : 2020-06-09

Abstract:
   It is hard to adjust traffic and optimize traffic paths on a
   traditional IP network from time to time through manual
   configurations.  It is desirable to have an automatic mechanism for
   setting up routing policies, which adjust traffic and optimize
   traffic paths automatically.  This document describes BGP Extensions
   for Routing Policy Distribution (BGP RPD) to support this.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-rpd-05
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rpd-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 12 Jun 2020 14:10:45 -0400

Hi Authors

Tracker shows this draft in WGLC state?

Is that correct?
BGP Extensions for Routing Policy Distribution (RPD)
draft-ietf-idr-rpd-05

   - Status <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/>
   - IESG evaluation record
   - IESG writeups
   <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/writeup/>
   - Email expansions
   <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/email/>
   - History <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/history/>

   - Versions
   - 00 <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/00/>
   - 01 <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/01/>
   - 02 <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/02/>
   - 03 <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/03/>
   - 04 <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/04/>
   - 05 <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/>

000102030405000102030405Jul 2015Jun 2016Oct 2018Mar 2019May
2020draft-li-idr-flowspec-rpddraft-ietf-idr-rpd
DocumentType Active Internet-Draft (idr WG
<https://datatracker.ietf.org/wg/idr/>)
Last updated 2020-06-10 (latest revision 2020-06-09)
Replaces draft-li-idr-flowspec-rpd
<https://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/>
Stream IETF
Intended RFC status (None)
Formats  plain text <https://www.ietf.org/id/draft-ietf-idr-rpd-05.txt> pdf
<https://tools.ietf.org/pdf/draft-ietf-idr-rpd-05.pdf> htmlized (tools)
<https://tools.ietf.org/html/draft-ietf-idr-rpd-05> htmlized
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd-05> bibtex
<https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/bibtex>
StreamWG state <https://datatracker.ietf.org/help/state/draft/ietf> In WG
Last Call
Document shepherd No shepherd assigned
IESGIESG state <https://datatracker.ietf.org/help/state/draft/iesg> I-D
Exists
Consensus Boilerplate Unknown

On Tue, Jun 9, 2020 at 6:50 PM <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> 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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 22 Jun 2020 19:15:23 -0400

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.

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.

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

Kind Regards

Gyan

On Fri, Jun 12, 2020 at 2:10 PM Gyan Mishra <[email-masked]> wrote:

>    - History
>    <https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/history/>
>
>
>    - Versions
> Formats  plain text <https://www.ietf.org/id/draft-ietf-idr-rpd-05.txt>
>  pdf <https://tools.ietf.org/pdf/draft-ietf-idr-rpd-05.pdf> htmlized
> (tools) <https://tools.ietf.org/html/draft-ietf-idr-rpd-05> htmlized

*Gyan Mishra*

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 1 Jul 2020 00:53:19 +0000

Hi Gyan,

    Thank you very much for your comments.

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

Best Regards,
Huaimo on behalf of authors
________________________________

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.

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.

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%7C07a9442b208a4e85cc3108d81c9b0415%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637290799405571469&sdata=wTNqdsqeXJVkHqK%2FZ0iIDAstepTYRxWtDoxX%2FSOg9HY%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 1 Jul 2020 00:30:45 -0400

Hi Huaimo

Few more questions in-line

Thank you

Gyan

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

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

> [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.
>
>
>
>
> [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

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
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C07a9442b208a4e85cc3108d81c9b0415%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637290799405571469&sdata=wTNqdsqeXJVkHqK%2FZ0iIDAstepTYRxWtDoxX%2FSOg9HY%3D&reserved=0>
>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>*Gyan
> Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

*Gyan Mishra*