[j-nsp] Standard practice for customer eBGP peering traffic engineer

[Hugo Slabbert]

Could be they got the idea from a recent NANOG thread on this very topic:

https://mailman.nanog.org/pipermail/nanog/2017-October/092887.html

>> Won't that cause a loop inside of the provider once the other IBGP 
>> routers see their own AS number?

The actual prepend would be applied on export, so on the provider's edge 
facing peers, rather than having the prepend applied on initial import and 
floating around the provider's internal routing.

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2017-Oct-26 10:16:42 +0700, Mark Tees <marktees at gmail.com> wrote:

>Hi Craig,
>
>They are probably referring to prepending the provider AS to certain
>other eBGP neighbours not within the AS.
>
>EG: Customer sends prefix X with community Y. Where provider chooses
>to advertise prefix X to other eBGP neighbours if they match community
>Y then prepend own AS.
>
>https://us.ntt.net/support/policy/routing.cfm
>http://tools.vocus.com.au/additionals/communities.htm
>https://onestep.net/communities/as3356/
>
>These are convenience methods to assist IP transit customers on
>guiding traffic towards their prefixes.
>
>--Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20171027/c553dbbe/attachment.sig>