Skip to content

Commit e6afb21

Browse files
committed
tweak
1 parent c41059b commit e6afb21

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

articles/internet-peering/service-faqs.yml

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -14,17 +14,17 @@ title: Peering Service frequently asked questions (FAQ)
1414
summary: |
1515
1616
sections:
17-
- name: Ignored
17+
- name:
1818
questions:
1919
- question: |
2020
Can a carrier use existing direct peering connections with Microsoft to support Peering Service?
2121
answer: |
22-
Yes, a carrier may leverage existing Private Network Interconnects (PNIs) to support Peering Service. Additional PNIs may be required to support local and geo diversity requirements. Primary and secondary connections must have equal capacity. In the Azure portal, carriers can request the conversion of existing PNIs to the Peering Service configuration and can also request new Peering Service connections PNIs.
22+
Yes, a carrier may use existing Private Network Interconnects (PNIs) to support Peering Service. Another PNIs may be required to support local and geo diversity requirements. Primary and secondary connections must have equal capacity. In the Azure portal, carriers can request the conversion of existing PNIs to the Peering Service configuration and can also request new Peering Service connections PNIs.
2323
2424
- question: |
2525
What are the diversity requirements on a direct peering to support Peering Service?
2626
answer: |
27-
A PNI must support local-redundancy and geo-redundancy. Local-redundancy is defined as two diverse peering connections on two routers in the same facility or in different facilities in the same metro. Geo-redundancy requires that the carrier has additional connectivity at a different Microsoft edge site within the geo-region in case the primary site fails. The carrier will route customer traffic through the backup site selected by the customer.
27+
A PNI must support local-redundancy and geo-redundancy. Local-redundancy is defined as two diverse peering connections on two routers in the same facility or in different facilities in the same metro. Geo-redundancy requires that the carrier has additional connectivity at a different Microsoft edge site within the geo-region in case the primary site fails. The carrier routes customer traffic through the backup site selected by the customer.
2828
2929
- question: |
3030
The carrier already offers enterprise-grade internet, how is this offering different?
@@ -34,12 +34,12 @@ sections:
3434
- question: |
3535
If a service provider already peers with Microsoft, what kind of changes are required to support Peering Service?
3636
answer: |
37-
Peering Service partners must have an Azure subscription and manage the Peering Service connections using the Azure Portal as this is where customer prefixes are registered, performance metrics are viewed, and support tickets are logged, among other features. If a provider has existing peering with Microsoft but no Azure subscription, the resources must be added to your subscription before you will be able to convert these to the Peering Service configuration. During the configuration change, Microsoft changes the policy group during a hard restart of the BGP session. No configuration changes are required on the partner’s side, unless the telco partner is supporting Peering Service for voice then BFD configuration is required. For more information, see [Azure Internet peering for Communications Services walkthrough](walkthrough-communications-services-partner.md)
37+
Peering Service partners must have an Azure subscription and manage the Peering Service connections using the Azure portal as this is where customer prefixes are registered, performance metrics are viewed, and support tickets are logged, among other features. If a provider has existing peering with Microsoft but no Azure subscription, the resources must be added to your subscription before you're able to convert these to the Peering Service configuration. During the configuration change, Microsoft changes the policy group during a hard restart of the BGP session. No configuration changes are required on the partner’s side, unless the telco partner is supporting Peering Service for voice, then BFD configuration is required. For more information, see [Azure Internet peering for Communications Services walkthrough](walkthrough-communications-services-partner.md).
3838
39-
- name: Ignored
39+
- name: Next steps
4040
questions:
4141
- question: |
42-
Next steps
42+
4343
answer: |
4444
For more Peering Service frequently asked questions, see [Peering Service frequently asked questions (FAQ)](../peering-service/faq.yml). <br> For more information about Peering Service, see [Azure Peering Service overview](../peering-service/about.md).
4545

0 commit comments

Comments
 (0)