Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

[Susan Hares <[e-mail]>]

Robert and WG:

[IDR document shepherd hat on].
I’m behind in my email on this call, so please note this email is
directed all wonderfully passionate IDR members.
I really love the active participation in August!
3 cheers for IDR people!

Would you do the following in this adoption call:
1. Please be specific on what vendors support and do not support
2. Please be careful to specify what is your opinion.
3. When it seems you’ve answer the question more than once,
Please use the format of:
 [diagram for scenario]
 [technical description]
[Observations]
 [opinion]

This really helps the WG and the chairs.

With Robert’s kind indulgence, I will use his email below as an example of
Item #1 and #2.  For #3, please see the CAR/CT discussion from 7/15 to 7/31.

Item #1:  In phrases like “during import RDs are rewritten and RTs are not”,
please be specific on what vendors support and do not support.
This helps us understand how you are supporting your logic.

Item #2: When stating things like:
 “If you like to complicate your import and keep tons of
run time import stats for no legitimate reasons no one will stop you”

State as:
IMHO, “If you like to complicate your import and keep tons of
run time import stats for no legitimate reasons no one will stop you, but… “

[IDR Shepherd hat off]

I’m a professor and this my first week of class, so I’m behind in my WG adoption call shepherd monitoring.
I’ll try to catch up this thread ASAP.

Thanks, Sue
[shepherd for this call]




From: Robert Raszuk <[e-mail]>
Sent: Wednesday, August 24, 2022 3:53 PM
To: Jeffrey Haas <[e-mail]>
Cc: Igor Malyushkin <[e-mail]>; Wanghaibo (Rainsword) <rainsword.wang=[e-mail]>; Susan Hares <[e-mail]>; [e-mail]
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

Jeff, Except that during import RDs are rewritten and RTs are not. If you like to complicate your import and keep tons of run time import stats for no legitimate reasons no one will stop you, but when
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzY5MDNiNTcyYmUxYjFjOGNmNTE1OGI1NjkwMzg2NDUzLzE2NjEzNzA4MDAuOTQ=#key=ae8b05c1b58a6c8fc8a9eb7fc91111d0>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Jeff,

Except that during import RDs are rewritten and RTs are not.

If you like to complicate your import and keep tons of run time import stats for no legitimate reasons no one will stop you, but when it comes to making IETF to bless it - let's consider all much cleaner and easier options.

Again - if at all needed ...

Many thx,
R.


On Wed, Aug 24, 2022 at 9:49 PM Jeffrey Haas <[e-mail]<mailto:[e-mail]>> wrote:
Robert,


On Aug 24, 2022, at 3:23 PM, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:

In almost all large scale VPN deployments I have seen VPN routes carry lots of RTs for various reasons. Allocating one more to determine the src VRF is trivial. If at all needed :)


Route targets (specifically) are intended to discuss destinations for routes, not their sources.

Certainly other extended communities could be used for such a purpose.

Route distinguishers, when configured distinct per VRF in a network, already provide that behavior.

-- Jeff