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

Specifically I am puzzled by such statement(s) in the draft:

*This document relaxes these constraints specified in [RFC4271] *

So the basic question stands:

What "constraints" specified in RFC4271 this document intends to relax ?

Many thx,
Robert.

On Mon, Jan 9, 2023 at 9:43 PM Igor Malyushkin <gmalyushkin@gmail.com>
wrote:

> 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
>>
>