Re: [Idr] [bess] Type 1 RD for Pure IPv6 network -- EVPN

Gyan Mishra <hayabusagsm@gmail.com> Wed, 03 February 2021 14:04 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9C13A0B08; Wed, 3 Feb 2021 06:04:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXpa-VFgNSQU; Wed, 3 Feb 2021 06:03:56 -0800 (PST)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BEF3A0A2E; Wed, 3 Feb 2021 06:03:56 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id j12so16684727pfj.12; Wed, 03 Feb 2021 06:03:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VnFYPpzsM9xtgUaQZP1fhOw+MTu5d/UUCYeb4N6fPr8=; b=HO1igfHgcGTsD0teOfkQNXdbjl0AJ3NN3XOlyOOYPEnBjtqpjXEbD577OPtk18x/Qd GmKSx+3RYDxyZJsokfVPsqa66qzEnpPvnXL4+kQi5+KJF8XDe9Em2sAsvsoNjhQVayvR Q6h38XCkh1Uc9FBRBjbBYdQ6+jMA/WOSYj/P6jHkU4k2NiiRuUMji3xAAgV27OgK21Ut +tCium3NlSih4M4tlSZ+/JOdTApmcB0P7cwuCn1etN1KwxBXUQguVmOzCMp+NgF3FYEp EXCUJgOAhQeavf/mHCpv+CIqhXz9dyb/gpNdEcL+laIQflFOQ+GKCbq7f+JCOo+mcFwQ 65tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VnFYPpzsM9xtgUaQZP1fhOw+MTu5d/UUCYeb4N6fPr8=; b=RYFLTB0nly+fKL9hE6DPyQfiAY90qpyiD8tRjXqQOLebPnOJcUq4w3ScDe+xRX+3kw 83DOxKT5tzsc1+tFlrtup1THIr5MawVRNSb++1Qo1YhWRgxZn9TU4t/tlBZVmgrQD3h5 SltOXT7+/69sJz/n2ViqaG7zzGgW2EHZ/LZgUrDz9GLcuE/zjGEUjOlMZqzCvc8LeolM KqlatwlkbONY5Kn/2RDbd0EQmxUyp8XicCqLRLgVFbVKioycvTSPj/oU2bBe607kyzKV cnetqguUgh87mFrVWZQTAHPHv6uUn2p9Ho7/5qs96tOnqotrjvCVXZp4E8egcaEZipBr iJ+Q==
X-Gm-Message-State: AOAM533++bSZoT4RFlhbE3cAokUT3SsWewUQpJO5hR/XE8XFT0kxC/Mk 34DpfH0VZtkkMzgHrV1jMPIuGcjyMHfd/A/BNiI=
X-Google-Smtp-Source: ABdhPJyHUa3P+gnhUKd5Ws+LsZt/bonCZs7eWi1m8g40w0Ch3k5bs2O30cYIIWgs5UbXMCC1DWCD6BujuBrCGEX8zH8=
X-Received: by 2002:a65:6547:: with SMTP id a7mr3806173pgw.50.1612361035860; Wed, 03 Feb 2021 06:03:55 -0800 (PST)
MIME-Version: 1.0
References: <CA+JENaK55mrR0hDEbTC62kASxTLtEfbmRkWh-VUhRU3oPQcBVA@mail.gmail.com> <CAKz0y8zOjsHS-_Nm7b_AYVy93zE4aDxvKJ+iTBtMDmdP5SCCoQ@mail.gmail.com> <CABNhwV3Jy_gH351+COn-ta14T5WVb0aixb9598nHHrJceOyz_Q@mail.gmail.com> <CAKz0y8zDkZ9q5f5B7VWdmtSwoXtDhuYzfTRyMpd52-=vpHsOrw@mail.gmail.com>
In-Reply-To: <CAKz0y8zDkZ9q5f5B7VWdmtSwoXtDhuYzfTRyMpd52-=vpHsOrw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 03 Feb 2021 09:03:44 -0500
Message-ID: <CABNhwV2=utxO62LMD1im7-Ts0hsKT83YQy_3cBtnu0xLVecRbQ@mail.gmail.com>
To: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Cc: TULASI RAM REDDY <tulasiramireddy@gmail.com>, bess@ietf.org, idr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cacd5105ba6f0e20"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lFiF02t3JPkMhvwARpPmAlAn91g>
Subject: Re: [Idr] [bess] Type 1 RD for Pure IPv6 network -- EVPN
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2021 14:04:01 -0000

Hi Muthu

Please see in-line

On Wed, Feb 3, 2021 at 12:20 AM Muthu Arul Mozhi Perumal <
muthu.arul@gmail.com> wrote:

> Hi Gyan,
>
> Please see inline..
> Regards,
> Muthu
>
> On Sat, Jan 30, 2021 at 3:26 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>> Muthu
>>
>> How does RFa. 6286 AS wide BGP identifier change the BGP path selection
>> process when all attributes are equal and ‘bestpath compare-routerid” is
>> uses so the valid/best path is deterministic and oldest versus newest
>> default.
>>
> The AS wide BGP identifier shouldn't change the BGP path selection process
> in this case, since you compare by converting them to host byte order and
> treating them as 4-octet unsigned integers as per RFC4271.
>

    Gyan> So with RFC 6286 the 4 octet unsigned could be any number from 1
to 4.2 billion.  I see in the remarks that the BGP identifier is to use RFC
4271 process for path selection resolution.

     In the route selection, where the BGP Identifier is not used in
     comparing a route from an internal neighbor and a route from an
     external neighbor.  In addition, routes from BGP speakers with
     identical BGP Identifiers have been dealt with (e.g., parallel BGP
     sessions between two BGP speakers).


When you are comparing two paths with the same router-id and you convert to
host byte order and treat as unsigned integer per RFC 4271 can you give an
example of how that would work.  I am not following the verbiage.  If the
BGP identifier is the same AS wide would the host byte order be the same
for each BGP speaker?

         The BGP Identifier of the local system is compared to the BGP
         Identifier of the remote system (as specified in the OPEN
         message).  Comparing BGP Identifiers is done by converting them
         to host byte order and treating them as 4-octet unsigned
         integers.


>
>>
>> I believe the BGP Identifier just as with OSPF or ISIS does not have to
>> be routable, so in an IPv6 only network precluding RFC 6286 I believe could
>> you still use a 4 octet IP address as the router-id.
>>
>
> Right. However, if we preclude RFC6286, then the BGP identifier needs to
> be a valid unicast host IPv4 address (for e.g. can't be a multicast
> address):
>
> <snip RFC4271>
>    Syntactic correctness means that the BGP Identifier field represents
>    a valid unicast IP host address.
> </snip>
>
>
     Gyan> I do see that verbiage in section 6.2


   If the BGP Identifier field of the OPEN message is syntactically
   incorrect, then the Error Subcode MUST be set to Bad BGP Identifier.
   Syntactic correctness means that the BGP Identifier field represents
   a valid unicast IP host address.


BGP with IGP call back NH tracker checks the NH but how does BGP code
validate the RIB that the router-id is a connected loopback but

and also advertised by IGP.  I have not tried it but if you set a
bogus router-id would all the BGP peers go down.

I will try that in the lab.



>>
>> This question comes up a lot these days as operations migrate to some
>> flavor of IPv6 only core MPLS LDPv6, SR-MPLSv6, SRv6.
>>
>>
>> Thanks
>>
>> Gyan
>> On Wed, Jan 27, 2021 at 5:45 AM Muthu Arul Mozhi Perumal <
>> muthu.arul@gmail.com> wrote:
>>
>>> Hi Tulasi,
>>>
>>> In pure IPv6 networks, I think using the BGP identifier in place of the
>>> IP address part in the type 1 RD should suffice for all practical purposes.
>>> The only catch is, if it is an AS-wide unique BGP identifier [RFC6286],
>>> then it is not an IP address 'per se'. But, I think it makes no difference
>>> from an interoperability standpoint..
>>>
>>> Perhaps, in line with RFC6286, we should redefine the IP address part of
>>> the type 1 RD as just a 4-octet, unsigned, non-zero integer..
>>>
>>> Regards,
>>> Muthu
>>>
>>> On Fri, Jan 22, 2021 at 11:31 AM TULASI RAM REDDY <
>>> tulasiramireddy@gmail.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> In a pure IPv6 network, how do one expect to construct the Type 1 RD.
>>>> As per EVPN RFC 7432 for EAD per ES, it should be Type 1 RD, but if the
>>>> loopback address is only IPv6 then what is the expectation here?
>>>> Should we use BGP router ID(32bit) here?
>>>>
>>>> From RFC7432: EVPN
>>>>
>>>> 8.2.1 <https://tools.ietf.org/html/rfc7432#section-8.2.1>.  Constructing Ethernet A-D per Ethernet Segment Route
>>>>
>>>>    The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364 <https://tools.ietf.org/html/rfc4364>].  The
>>>>    *value field comprises an IP address of the PE (typically, the
>>>>    loopback address)* followed by a number unique to the PE.
>>>>
>>>>
>>>> Thanks,
>>>> TULASI RAMI REDDY N
>>>> _______________________________________________
>>>> BESS mailing list
>>>> BESS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>> Spring, MD
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD