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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]>
wrote:

> Hi Robert,
>
>     Thank you very much for your comments.
>
>     Our answer/explanation is inline below with prefix [HC].
>
> Best Regards,
> Huaimo on behalf of authors
>
> ------------------------------
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Saturday, July 4, 2020 6:18 AM
> *To:* Huaimo Chen <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *Subject:* Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt
>
> 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.
>
> [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 <[e-mail]>
> wrote:
>
> 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 <[e-mail]>
> *Sent:* Wednesday, July 1, 2020 5:21 AM
> *To:* Huaimo Chen <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *Subject:* Re: [Idr] I-D Action: draft-ietf-idr-rpd-05.txt
>
> 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.
>
> [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.
>
>