Merge pull request #235275 from halkazwini/ip-faq3

FAQ update

Author: prmerger-automator[bot]

articles/internet-peering/service-faqs.yml

@@ -7,25 +7,24 @@ metadata:
   author: halkazwini
   ms.service: internet-peering
   ms.topic: faq
-  ms.date: 03/29/2023
+  ms.date: 04/20/2023
   ms.author: halkazwini
   ms.custom: engagement-fy23
 title: Peering Service frequently asked questions (FAQ)
 summary: |
 
-
 sections:
   - name: Ignored
     questions:
       - question: |
           Can a carrier use existing direct peering connections with Microsoft to support Peering Service?
         answer: |
-          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.
+          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.
 
       - question: |
           What are the diversity requirements on a direct peering to support Peering Service?
         answer: |
-          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.
+          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.
 
       - question: |
           The carrier already offers enterprise-grade internet, how is this offering different?
@@ -35,5 +34,5 @@ sections:
       - question: |
           If a service provider already peers with Microsoft, what kind of changes are required to support Peering Service?
         answer: |
-          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)
-          
+          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).
+