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

[Huaimo Chen <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, July 1, 2020 5:21 AM
To: Huaimo Chen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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.