Adrian
In the introduction it mentions the following backbone transport:
The various ASes that provide connectivity between the Ingress and Egress
Domains could each be constructed differently and use different
technologies such as IP, MPLS with global table routing native BGP to
the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN.
In the draft it talks about SR steering
however can RSVP be used in the backbone transport .
I think to clarify we should mention the MUST for the data plane
requirements for the backbone transport.
On the call last week we confirmed that the ingress and egress
domains now called “sites” not domains do not have to be SR enabled.
Kind Regards
Gyan
On Mon, May 17, 2021 at 5:04 PM Gyan Mishra <[email protected]> wrote:
> Hi John
>
> I agree with your comments that the scenario I mentioned is covered in
> Section 3 and agree as well on the RFC 2119 keyword usage scrub.
>
> In-line
>
> On Mon, May 17, 2021 at 3:55 PM John Scudder <[email protected]> wrote:
>
>> Hi Gyan,
>>
>> > On May 17, 2021, at 1:50 PM, Gyan Mishra <[email protected]> wrote:
>> >
>> > So if GW2 connection to external was down but GW1 still has its
>> connection to external. GW2 would auto discover GW1 over iBGP and GW2
>> would advertise both GW1 and GW2 as reachable gateways. However GW2 has
>> its external peer down. So if GW1 continues to advertised GW2 as we stated
>> GW1 will auto discover GW2 over iBGP.
>>
>> Isn’t this scenario covered? From §3:
>>
>> If a gateway becomes disconnected from the backbone network, or if
>> the SR domain operator decides to terminate the gateway's activity,
>> it withdraws the advertisements described above. This means that
>> remote gateways at other sites will stop seeing advertisements from
>> this gateway.
>
>
> Gyan> Yes. Agreed. I wanted to draw some more attention to this to
> the authors on the withdrawal that it’s critical and agreed a MUST.
>
>>
>>
>> So when GW2’s external peering goes down, GW2 withdraws its auto
>> discovery route, and therefore GW1 re-advertises its routes externally
>> without GW2 listed in the tunnel attribute.
>>
>
>
>
>
>> I will say that reviewing the above-quoted text — which seems tailor-made
>> for a “MUST withdraw” — made me notice that the draft makes only sporadic
>> and desultory use of RFC2119 keywords. In fact there are so few used, that
>> it seems like it might be better to scrub those two SHOULD and two MUST out
>> and remove the 2119 citation.
>
>
> Gyan> Agreed. I will parse the draft for RFC 2119 keyword placement in
> my final GEN-ART review update
>
>>
>>
>> —John
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [email protected] <[email protected]>*
>
>
>
> *M 301 502-1347*
>
> --
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email [email protected] <[email protected]>*
*M 301 502-1347*
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
