Re: [Idr] I-D Action: draft-smn-idr-inter-domain-ibgp-00.txt

Hi folks,

I also have a question about the intended status of the document. It seems
to me that authors are trying to document well-known and widely-spread
designs/architectures. Reading the draft I don't see anything new to BGP or
BGP-VPN machinery.
Should it be Informational instead?

вт, 10 янв. 2023 г. в 00:28, Robert Raszuk <robert@raszuk.net>:

> Hi,
>
> Well your answer is now more confusing than the draft :)
>
> First the draft is a Standards Track and it says:
>
>
>
>
> *   This document relaxes these constraints specified in [RFC4271] and
>  [RFC4364], allowing the building of Inter-domain L3VPN architectures
>  with MP-IBGP (Multiprotocol internal BGP).*
>
> If it is a Standards Track doc it presumably proposes changes to the
> protocol or at least state machine.
>
> Section 2 says:
>
>
>
>
> *   The only difference compared to the original Inter-domain Option 10A
>  is the peering between two domains: now, it is IBGP, and no longer   EBGP.*
>
> There is nowhere mentioned that DBRs MUST be RRs from the BGP point of
> view.
>
> Section 3 says:
>
>
>
> *   The only difference compared to the original Inter-domain Option 10B
>  is the peering between two domains: now, it is IBGP, and no longer   EBGP.*
>
> So if you consider to decouple concept of IGP domain from BGP domain what
> the draft says is essentially what Randy pointed out that single BGP ASN
> has been deployed across N number of IGP domains quite successfully in the
> past.
>
> So if you are not proposing any change to BGP protocol the draft should be
> Informational and since it is focused on documenting specific deployment
> model of RFC4364 should be moved to BESS.
>
> If you are however proposing changes to BGP protocol or FSM please clearly
> document them. Currently it is not clear what exactly those changes would
> be.
>
> Kind regards,
> Robert
>
>
> On Mon, Jan 9, 2023 at 9:10 PM Krzysztof Szarkowicz <
> kszarkowicz@juniper.net> wrote:
>
>> Hello Robert,
>>
>>
>>
>> Please see comments inline.
>>
>>
>>
>> --
>>
>> Krzysztof Grzegorz Szarkowicz, JAWS PLM, Solutions Architect | Phone: +49
>> 89 203 012 127
>>
>> Please consider my current time zone, when calling: CET (UTC+01:00)
>>
>> https://easylink.juniper.net/slicing
>>
>>
>>
>>
>>
>> *From: *Robert Raszuk <robert@raszuk.net>
>> *Date: *Monday, 2023-01-09:Mo at 15:52
>> *To: *Krzysztof Szarkowicz <kszarkowicz@juniper.net>,
>> israel.means@att.com <israel.means@att.com>, Moshiko Nayman <
>> mnayman@juniper.net>
>> *Cc: *idr@ietf. org <idr@ietf.org>
>> *Subject: *Fwd: I-D Action: draft-smn-idr-inter-domain-ibgp-00.txt
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> Hello Krzysiek and other co-authors,
>>
>>
>>
>> I have read yr draft with interest. Lecture of it triggered number below
>> comments:
>>
>>
>>
>> * First fundamental - Concept of IGP domain and BGP domain are completely
>> separate entities. It has been the case for many years that BGP domain can
>> span number of IGP domains. In fact large global networks used (maybe still
>> use) such model.
>>
>>
>>
>> [Krzysztof] Indeed. This draft focuses on ‘BGP domain that span number of
>> IGP domains’.
>>
>>
>>
>>
>>
>> * Second fundamental - Essentially the entire draft is asking to
>> propagate IBGP learned routes to other IBGP peers without enabling route
>> reflection functionality. That is  a severely dangerous suggestion even if
>> (hopefully) controlled  with a new per session knob.
>>
>>
>>
>> [Krzysztof] Not sure, from where you got it. It depends on the scale in
>> given domain. In many places in the draft there are texts like ‘RR SHOULD
>> be used’ or ‘RR is recommended’. We will review the text, and make it
>> clearer.
>>
>>
>>
>> * Applying policy on IBGP sessions is with few exceptions a bad and
>> dangerous thing. And likely between domains policy is your friend not an
>> enemy.
>>
>>
>>
>> [Krzysztof] Could you be more precise here? In the draft, policies are
>> applied on domain boundaries only.
>>
>>
>>
>> * Suggestion to keep term label-unicast to SAFI 4 only. SAFI 128 does not
>> carry label unicast routes ... it carries VPN routes with VPN labels. If we
>> start mixing terms overlay and underlay will be likely mixed.
>>
>>
>>
>> [Krzysztof] Yep. We will change it in the next revision.
>>
>>
>>
>> * I am not sure what exactly is the issue if each domain would actually
>> have different ASN. We already have knobs not to set next hop self on EBGP
>> sessions for option C. You are complaining about Local_Pref not being
>> propagated but you have AIGP attribute or MED instead.  Not sure what is
>> the issue with RTC ... it works fine between and within domains.
>>
>>
>>
>> [Krzysztof] There are deployments with domains having the same ASN. We
>> are documenting it in this draft.
>>
>>
>>
>> Kind regards,
>>
>> Robert
>>
>>
>>
>>
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: <internet-drafts@ietf.org>
>> Date: Mon, Jan 9, 2023 at 3:26 PM
>> Subject: I-D Action: draft-smn-idr-inter-domain-ibgp-00.txt
>> To: <i-d-announce@ietf.org>
>>
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>         Title           : Interconnecting domains with Multiprotocol IBGP
>>         Authors         : Krzysztof G. Szarkowicz
>>                           Israel Means
>>                           Moshiko Nayman
>>   Filename        : draft-smn-idr-inter-domain-ibgp-00.txt
>>   Pages           : 13
>>   Date            : 2023-01-09
>>
>> Abstract:
>>    This document relaxes the constraints specified in [RFC4364] and
>>    [RFC4456] allowing the building of Inter-domain L3VPN architecture
>>    with Multiprotocol internal BGP.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-smn-idr-inter-domain-ibgp/
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-smn-idr-inter-domain-ibgp/__;!!NEt6yMaO-gk!GDaN5sViMDSS1JSsP-dPx22qGWnKoIf5HyXmvPIq94JpKiZJL7CpCbK6QaHkKywJaLlWsWwEUaYhy6gW8jYK$>
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-smn-idr-inter-domain-ibgp-00.html
>> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-smn-idr-inter-domain-ibgp-00.html__;!!NEt6yMaO-gk!GDaN5sViMDSS1JSsP-dPx22qGWnKoIf5HyXmvPIq94JpKiZJL7CpCbK6QaHkKywJaLlWsWwEUaYhy5orwexl$>
>>
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/i-d-announce__;!!NEt6yMaO-gk!GDaN5sViMDSS1JSsP-dPx22qGWnKoIf5HyXmvPIq94JpKiZJL7CpCbK6QaHkKywJaLlWsWwEUaYhy670JqNn$>
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> <https://urldefense.com/v3/__http:/www.ietf.org/shadow.html__;!!NEt6yMaO-gk!GDaN5sViMDSS1JSsP-dPx22qGWnKoIf5HyXmvPIq94JpKiZJL7CpCbK6QaHkKywJaLlWsWwEUaYhy_ANA8WX$>
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> <https://urldefense.com/v3/__ftp:/ftp.ietf.org/ietf/1shadow-sites.txt__;!!NEt6yMaO-gk!GDaN5sViMDSS1JSsP-dPx22qGWnKoIf5HyXmvPIq94JpKiZJL7CpCbK6QaHkKywJaLlWsWwEUaYhy3J8NyUc$>
>>
>> Juniper Business Use Only
>>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>