Re: [bess] About draft-wang-bess-l3-accessible-evpn

[Aijun Wang]

Hi, Jorge:

 

Thanks for your comments, please see detail replies inline.

Wish to hear more suggestions from you.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: bess-boun...@ietf.org  On Behalf Of Rabadan,
Jorge (Nokia - US/Mountain View)
Sent: Friday, March 12, 2021 5:55 PM
To: Wei Wang ; linda.dunbar

Cc: bess 
Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn

 

Hi Wei,

 

Thanks for taking the time to reply.

 

The ESI type was conceived in RFC7432 to specify the format of the remaining
9 bytes and produce unique ESIs, in the case auto-derived ESIs and manual
ESIs had to coexist in the same network.

Irrespective, on reception of the EVPN routes with non-zero ESI some
implementations just compare the 10-byte identifier and process EVPN routes
accordingly, including routes type 5. 

[WAJ] Should we require such implementation to follow the requirements of
the RFC?

 

Using the ESI in this context will create an unnecessary number of interop
issues. At least the Ethernet Tag ID would have no such issues.

[WAJ] Some implementations may also ignore the value of Ethernet Tag ID,
especially for the type-5 route. You have also mentioned this below.

 

My other comment would be that, when we created the IP Prefix route, we
added the Ethernet Tag ID so that user groups could be created within the
same IP-VRF, but ultimately we found no use case for it and left it at zero
in all the cases in the IP Prefix advertisement draft. 

[WAJ] Reusing the Ethernet Tag ID to classify the type-5 route is possible,
but I prefer to defining the new ESI type, because the new ESI type can
still preserve the "Multihoming Functions" , as described in RFC7432.

 

I personally still think it is better and simpler to create a separate
IP-VRF and VNI (or identifier) for each user group as people do today,
rather than an 'LSI' per group withing the IP-VRF. With separate IP-VRFs:

-   the data path is simpler (no need for a second lookup that is not
supported by current chipsets), and 

-   you can still use all the BGP route dissemination tools that are based
on route-targets.

 

I don't see any benefit in the solution you are suggesting, but of course I
may miss a lot of things.

[WAJ] Using separate IP-VRFs solution can accomplish the LSI-Based
Service(similar with VLAN-Based service) effect, but can't achieve the
LSI-Aware Service(similar with VLAN-aware service). The benefit of LSI-Aware
service is similar with the VLAN-Aware service, which it simplifies the
deployment of IP-VRF within the backbone network. The enhancement to the PE
device is necessary.

 

Thanks.

Jorge

 

 

From: Wei Wang mailto:weiwan...@foxmail.com> >
Date: Friday, March 12, 2021 at 9:14 AM
To: linda.dunbar mailto:linda.dun...@futurewei.com> >, Rabadan, Jorge (Nokia - US/Mountain
View) mailto:jorge.raba...@nokia.com> >
Cc: bess mailto:bess@ietf.org> >
Subject: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Linda and Jorge,

Thanks for your comments at IETF110 meeting, and I think I need to
explain our considerations for the newly defined LSI (Logical Session
Identifier) concept.

 

Question 1, from Linda Dunbar, "Is the usage of LSI same as the RD for VPN
route distinguish?"

Answer: LSI(Logical Session Identifier) is mainly used for distinguishing
the different logical sessions between CE and PE device. Such session can be
established via Vxlan, IPsec, or other tunnel technologies that can span
layer 3 network. 

The LSI information should be transferred via the control plane and
forwarding plane. In control plane, we try to use Ethernet Tag ID/newly
defined ESI type to transfer, its purpose is to further distinguish the
cusomer routes within one provider VRF. In forwarding plane, this
information should be inserted into some place of the exising VxLAN
encoding, as proposed in our
draft:https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-ev
pn-04#section-6.1

 

Question 2, from Jorge Rabadan. "The ESI shouldn't be used to distinguish
the route-type 5, it is mainly used for multi-homing purpose"

Answer: Currently, we are considering using two methods to identify the
routes that associated different LSI:

   Method 1: Ethernet Tag ID, which is similar with its usage in layer 2
vlan environment.

   Method 2: Newly defined ESI type(type 6)

 

We think both methods are approachable:

Method 1 requires also the update of
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11(Eth
ernet Tag ID is set to 0 for route type 5), may arises some confuse with its
original defintion.

Method 2 requires the extension of ESI type (as described in:
https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#
section-6.2). The original purpose of ESI (mulit-homing) can also be
preserved.

 

I hope the above explanations help.

Comments and questions are always welcome.

 

Best Regards,

Wei

China Telecom

Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

[zhang.zheng]

Hi Tony, 


Thank you very much for your explaining! 


I got it. The auto evpn function includes it but the aim is not it.


Much appreciate if you may respond my further comments in my previous email. 


Best regards,


Sandy





原始邮件



发件人：AntoniPrzygienda
收件人：张征7940;Jordan Head;Wen Lin;
抄送人：bess@ietf.org;r...@ietf.org;
日 期 ：2021年03月12日 16:07
主 题 ：Re: [Rift] comments on draft-head-rift-auto-evpn-00




___
RIFT mailing list
r...@ietf.org
https://www.ietf.org/mailman/listinfo/rift

 

Sandy, if you want to see it that way, yepp, you can think of one of the things 
AUTO EVPN does as “BGP peer auto-configuration”. This is however just a small 
part of the overall and really just kind of “necessary byproduct”, especially 
since the sessions to RR can go multi-hop so even with bgp single-hop discovery 
BGP couldn’t figure it out itself. (Yes, there was work done previously for RR 
autodiscovery in IGP AFAIR, I don’t think I ever saw it deployed).


 


--- tony


 


 



From: "zhang.zh...@zte.com.cn" 
 Date: Friday, 12 March 2021 at 05:01
 To: Antoni Przygienda , Jordan Head , Wen 
Lin 
 Cc: "r...@ietf.org" , "bess@ietf.org" 
 Subject: Re:[Rift] comments on draft-head-rift-auto-evpn-00



 



[External Email. Be cautious of content]


 

Hi Tony, 

Thank you for your response! It's interesting. 

So in some sense, the BGP auto discovery can be achieved by RIFT own way, in 
this situration, right? 

Please find more comments below with Sandy>.

Best regards,

Sandy


原始邮件



发件人：AntoniPrzygienda



收件人：张征7940;Jordan Head;Wen Lin;



抄送人：r...@ietf.org;bess@ietf.org;



日 期 ：2021年03月10日 23:45



主 题 ：Re: [Rift] comments on draft-head-rift-auto-evpn-00




Hey Sandy, yes, all sessions come up automatically


 


Yes, all the data is derived automatically just from the today’s RIFT database 
on the leaf or ToF (no key value necessary or any new TIEs, just topology info 
we have today already)


Sandy> Most of the info is topology info, but some may not, such as AS number. 
But I agree with you, it can be a small option to be added in the existed TIE 
or a new TIE.



 
 


There is _NO_ information about ToF in the leaves, e’thing is scaling just like 
RIFT does today


Sandy> I have a question, If ToF is RR, does it need to establish BGP peering 
with leaf nodes?


 


KV  will be just optional for telemetry in case that’s desired & will flow 
northbound only so no change in scaling properties.


Sandy> OK. I understand.


 


In short:


 


RR elects itself RR or not in the plane (section 6.3.2.1) and based on that  
assumes a special RR loopback with last byte representing its preference


 


X::[pref]


 


Every leaf tries to connect to


 


X::1


X::2


X::3


 


Which they know are RRs (# of RRs doesn’t matter, just pick a reasonable 
constant)


 


Each leaf elects own loopback in a well known range


Sandy> It's a reasonable design. For multiple RIFT instances, if multiple EVPN 
overlays can be built? Will they use the same well know range loopback address?


 


Y/64 :: something


 


On each RR any connection attempt from Y/64:: something is accepted (pretty 
much all mature implemenations today support that). If you want to be 
fastidious you could actually on the ToF that is RR (since it sees all node 
N-TIEs) even specify each leaf as allowed peer


Sandy> Do you mean the RR (ToF) is optional, leaf nodes can build BGP peering 
straightly?


 


All took a bit to figure out and my first input to the idea when brought to me 
was “well, of course it’s impossible to ZTP EVPN, even with RIFT”  But, with 
enough grey matter grease it actually works pretty well from all we see …


 


It will all become more concrete when we flesh the algorithm appendix albeit 
the description today already gives a pretty good idea but without standardized 
algorithms for the distributed elections interoperability cannot be guaranteed …


Sandy> Sound great. Looking forward to looking at it.


 


--- tony


 



From: "zhang.zh...@zte.com.cn" 
 Date: Wednesday, 10 March 2021 at 16:31
 To: Antoni Przygienda , Jordan Head , Wen 
Lin 
 Cc: "r...@ietf.org" 
 Subject: [Rift] comments on draft-head-rift-auto-evpn-00



 


[External Email. Be cautious of content]


 

Hi Tony, co-author, 

Thank for your presentation in RIFT and BESS WG.

I have question about the intent of this draft, before I read more on the 
detail. :-P

From the draft, seems like the leaf node will build BGP connection 
automatically, and exchange the necessary MAC/IP through EVPN advertisement. 

But does the info on leaf for BGP building (AS, router-id, etc.) derived from 
the leaf node itself? If it is, the BGP auto discovery function is included in 
(That is also the confusion from BESS WG).

If the info for BGP building on leaf comes from the TOF nodes (RR), then it has 
no relationship with BGP auto discovery, IMO necessary sourcebound KVs are 
needed. But I am not sure because I have 

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-irb-extended-mobility-01

[Neeraj Malhotra]

Hi Stephane,

Just fyi - new revision that addresses comments on this thread has been
uploaded.

Thanks,
Neeraj

On Thu, Feb 11, 2021 at 12:20 AM  wrote:

> Hi Authors,
>
>
>
> Please address the comments raised by the WG members before we move
> forward.
>
> I have fixed the dependency to the individual draft, so now the IPR
> appears on the WG doc.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
> *From:* Acee Lindem (acee) 
> *Sent:* lundi 18 janvier 2021 18:25
> *To:* slitkows.i...@gmail.com; bess@ietf.org
> *Cc:* bess-cha...@ietf.org
> *Subject:* Re: [bess] WG Last Call, IPR and Implementation Poll for
> draft-ietf-bess-evpn-irb-extended-mobility-01
>
>
>
> Hi Stephane, et al,
>
> I did another quick read of the draft and I support publication. I think
> it would be good to state in the introduction which sections of the draft
> our normative and which are informative.
>
> Thanks,
>
> Acee
>
>
>
> *From: *BESS  on behalf of "slitkows.i...@gmail.com"
> 
> *Date: *Monday, January 18, 2021 at 3:58 AM
> *To: *"bess@ietf.org" 
> *Cc: *"bess-cha...@ietf.org" 
> *Subject: *[bess] WG Last Call, IPR and Implementation Poll for
> draft-ietf-bess-evpn-irb-extended-mobility-01
>
>
>
> This email starts a two-week working group last call for
> draft-ietf-bess-evpn-irb-extended-mobility-01 [1]
>
>
>
>
>
>
>
> Please review the draft and send any comments to the BESS list. Also,
> please indicate if you support publishing the draft as a standards track
> RFC.
>
>
>
>
>
>
>
> This poll runs until February 1st.
>
>
>
>
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an Author or a Contributor of this document please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
>
>
> There is currently no IPR disclosed.
>
>
>
> In addition, we are polling for knowledge of implementations of this
> draft, per the BESS policy in [2].
>
>
>
>
>
> Thank you,
>
>
>
> Matthew & Stephane
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> 
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] I-D Action: draft-ietf-bess-evpn-irb-extended-mobility-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Extended Mobility Procedures for EVPN-IRB
Authors : Neeraj Malhotra
  Ali Sajassi
  Aparna Pattekar
  Jorge Rabadan
  Avinash Lingala
  John Drake
Filename: draft-ietf-bess-evpn-irb-extended-mobility-05.txt
Pages   : 25
Date: 2021-03-15

Abstract:
   Procedure to handle host mobility in a layer 2 Network with EVPN
   control plane is defined as part of RFC 7432.  EVPN has since evolved
   to find wider applicability across various IRB use cases that include
   distributing both MAC and IP reachability via a common EVPN control
   plane.  MAC Mobility procedures defined in RFC 7432 are extensible to
   IRB use cases if a fixed 1:1 mapping between VM IP and MAC is assumed
   across VM moves.  Generic mobility support for IP and MAC that allows
   these bindings to change across moves is required to support a
   broader set of EVPN IRB use cases, and requires further
   consideration.  EVPN all-active multi-homing further introduces
   scenarios that require additional consideration from mobility
   perspective.  This document enumerates a set of design considerations
   applicable to mobility across these EVPN IRB use cases and defines
   generic sequence number assignment procedures to address these IRB
   use cases.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-extended-mobility-05
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-irb-extended-mobility-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

[Gyan Mishra]

Understood.  Thanks Tony.

The draft is very detailed and well written.

Thanks

Gyan

On Mon, Mar 15, 2021 at 2:29 AM Antoni Przygienda  wrote:

> As Jeff pointed out, the scope is very different. The design team is
> focused on standardizing a solution given things that have been for a bit
> in the wild to “auto-peer” BGP, a useful thing non-withstanding how
> contrary to the original BGP design goals it was 
>
>
>
> AUTO EVPN targets a different problem where auto-peering is kind of
> understood implicitly from the underlay protocol plus lots other things. It
> brings original L2 simplicity to L2 over L3 again. Based on RIFT (other
> protocols are an open question but there are a lot of things needed for
> that that RIFT already does natively) it provides a absolutely zero config
> plug-and-play underlay and overlay EVPN bring-up of devices plugged
> together to form an IP fabric (well, I’m lying, the top of fabric switches
> in RIFT still need the knob for knowing they’re top-of-fabric).
>
>
>
> The draft outlines the architecture pretty well, we have the missing
> algorithms figured out quite precisly by now and stuff works but we simply
> didn’t have time for this IETF to fill them in or include the type-5 IRB
> details either. Next rev …
>
>
>
> --- tony
>
>
>
> *From: *Jeff Tantsura 
> *Date: *Sunday, 14 March 2021 at 19:51
> *To: *Gyan Mishra 
> *Cc: *Antoni Przygienda , "r...@ietf.org" ,
> "ext-zhang.zh...@zte.com.cn" , "bess@ietf.org" <
> bess@ietf.org>, Wen Lin , Jordan Head  >
> *Subject: *Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Gyan,
>
>
>
> It doesn’t and has a very different purpose.
>
> BGP work in IDR is meant to facilitate bringing up BGP peering
> session(discovery/config/etc).
>
> RIFT work is specifically for fabrics that run RIFT as the underlay
> routing protocol and wish to use EVPN for overlay. Auto-evpn facilities
> bringing up BGP sessions with EVPN AFI/SAFI as well as auto deriving EVPN
> attributes, such as  EVIs,VRFs, IRB/SVIs and so forth.
>
>
>
> Regards,
>
> Jeff
>
>
>
> On Mar 13, 2021, at 16:12, Gyan Mishra  wrote:
>
>
>
> Tony
>
>
>
> In IDR their is an BGP Auto config design team.
>
>
>
> Does this auto EVPN used by Rift separate effort from IDR DT below:
>
>
>
> 1. BGP Autoconf Design Team Report (15 mins)
>   https://tools.ietf.org/html/draft-ietf-idr-bgp-autoconf-considerations/
> 
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Fri, Mar 12, 2021 at 3:06 AM Antoni Przygienda  40juniper@dmarc.ietf.org> wrote:
>
> Sandy, if you want to see it that way, yepp, you can think of one of the
> things AUTO EVPN does as “BGP peer auto-configuration”. This is however
> just a small part of the overall and really just kind of “necessary
> byproduct”, especially since the sessions to RR can go multi-hop so even
> with bgp single-hop discovery BGP couldn’t figure it out itself. (Yes,
> there was work done previously for RR autodiscovery in IGP AFAIR, I don’t
> think I ever saw it deployed).
>
>
>
> --- tony
>
>
>
>
>
> *From: *"zhang.zh...@zte.com.cn" 
> *Date: *Friday, 12 March 2021 at 05:01
> *To: *Antoni Przygienda , Jordan Head ,
> Wen Lin 
> *Cc: *"r...@ietf.org" , "bess@ietf.org" 
> *Subject: *Re:[Rift] comments on draft-head-rift-auto-evpn-00
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Tony,
>
> Thank you for your response! It's interesting.
>
> So in some sense, the BGP auto discovery can be achieved by RIFT own way,
> in this situration, right?
>
> Please find more comments below with Sandy>.
>
> Best regards,
>
> Sandy
>
> 原始邮件
>
> *发**件人：*AntoniPrzygienda
>
> *收件人：*张征7940;Jordan Head;Wen Lin;
>
> *抄送人：*r...@ietf.org;bess@ietf.org;
>
> *日* *期* *：*2021年03月10日 23:45
>
> *主* *题* *：**Re: [Rift] comments on draft-head-rift-auto-evpn-00*
>
> Hey Sandy, yes, all sessions come up automatically
>
>
>
> Yes, all the data is derived automatically just from the today’s RIFT
> database on the leaf or ToF (no key value necessary or any new TIEs, just
> topology info we have today already)
>
> Sandy> Most of the info is topology info, but some may not, such as AS
> number. But I agree with you, it can be a small option to be added in the
> existed TIE or a new TIE.
>
>
>
> There is _*NO*_ information about ToF in the leaves, e’thing is scaling
> just like RIFT does today
>
> Sandy> I have a question, If ToF is RR, does it need to establish BGP
> peering with leaf nodes?
>
>
>
> KV  will be just optional for telemetry in case that’s desired & will
> flow northbound only so no change in scaling properties.
>
> Sandy> OK. I understand.
>
>
>
> In short:
>
>
>
> RR elects itself RR or not in the plane (section 6.3.2.1) and based on
> that  assumes a special RR loopback with last byte representing its
> 

Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

[Antoni Przygienda]

As Jeff pointed out, the scope is very different. The design team is focused on 
standardizing a solution given things that have been for a bit in the wild to 
“auto-peer” BGP, a useful thing non-withstanding how contrary to the original 
BGP design goals it was 

AUTO EVPN targets a different problem where auto-peering is kind of understood 
implicitly from the underlay protocol plus lots other things. It brings 
original L2 simplicity to L2 over L3 again. Based on RIFT (other protocols are 
an open question but there are a lot of things needed for that that RIFT 
already does natively) it provides a absolutely zero config plug-and-play 
underlay and overlay EVPN bring-up of devices plugged together to form an IP 
fabric (well, I’m lying, the top of fabric switches in RIFT still need the knob 
for knowing they’re top-of-fabric).

The draft outlines the architecture pretty well, we have the missing algorithms 
figured out quite precisly by now and stuff works but we simply didn’t have 
time for this IETF to fill them in or include the type-5 IRB details either. 
Next rev …

--- tony

From: Jeff Tantsura 
Date: Sunday, 14 March 2021 at 19:51
To: Gyan Mishra 
Cc: Antoni Przygienda , "r...@ietf.org" , 
"ext-zhang.zh...@zte.com.cn" , "bess@ietf.org" 
, Wen Lin , Jordan Head 
Subject: Re: [bess] [Rift] comments on draft-head-rift-auto-evpn-00

[External Email. Be cautious of content]

Hi Gyan,

It doesn’t and has a very different purpose.
BGP work in IDR is meant to facilitate bringing up BGP peering 
session(discovery/config/etc).
RIFT work is specifically for fabrics that run RIFT as the underlay routing 
protocol and wish to use EVPN for overlay. Auto-evpn facilities bringing up BGP 
sessions with EVPN AFI/SAFI as well as auto deriving EVPN attributes, such as  
EVIs,VRFs, IRB/SVIs and so forth.

Regards,
Jeff


On Mar 13, 2021, at 16:12, Gyan Mishra  wrote:

Tony

In IDR their is an BGP Auto config design team.

Does this auto EVPN used by Rift separate effort from IDR DT below:

1. BGP Autoconf Design Team Report (15 mins)
  
https://tools.ietf.org/html/draft-ietf-idr-bgp-autoconf-considerations/

Kind Regards

Gyan


On Fri, Mar 12, 2021 at 3:06 AM Antoni Przygienda 
mailto:40juniper@dmarc.ietf.org>> wrote:
Sandy, if you want to see it that way, yepp, you can think of one of the things 
AUTO EVPN does as “BGP peer auto-configuration”. This is however just a small 
part of the overall and really just kind of “necessary byproduct”, especially 
since the sessions to RR can go multi-hop so even with bgp single-hop discovery 
BGP couldn’t figure it out itself. (Yes, there was work done previously for RR 
autodiscovery in IGP AFAIR, I don’t think I ever saw it deployed).

--- tony


From: "zhang.zh...@zte.com.cn" 
mailto:zhang.zh...@zte.com.cn>>
Date: Friday, 12 March 2021 at 05:01
To: Antoni Przygienda mailto:p...@juniper.net>>, Jordan Head 
mailto:jh...@juniper.net>>, Wen Lin 
mailto:w...@juniper.net>>
Cc: "r...@ietf.org" 
mailto:r...@ietf.org>>, "bess@ietf.org" 
mailto:bess@ietf.org>>
Subject: Re:[Rift] comments on draft-head-rift-auto-evpn-00

[External Email. Be cautious of content]


Hi Tony,

Thank you for your response! It's interesting.

So in some sense, the BGP auto discovery can be achieved by RIFT own way, in 
this situration, right?

Please find more comments below with Sandy>.

Best regards,

Sandy
原始邮件
发件人：AntoniPrzygienda
收件人：张征7940;Jordan Head;Wen Lin;
抄送人：r...@ietf.org;bess@ietf.org;
日 期 ：2021年03月10日 23:45
主 题 ：Re: [Rift] comments on draft-head-rift-auto-evpn-00
Hey Sandy, yes, all sessions come up automatically

Yes, all the data is derived automatically just from the today’s RIFT database 
on the leaf or ToF (no key value necessary or any new TIEs, just topology info 
we have today already)
Sandy> Most of the info is topology info, but some may not, such as AS number. 
But I agree with you, it can be a small option to be added in the existed TIE 
or a new TIE.

There is _NO_ information about ToF in the leaves, e’thing is scaling just like 
RIFT does today
Sandy> I have a question, If ToF is RR, does it need to establish BGP peering 
with leaf nodes?

KV  will be just optional for telemetry in case that’s desired & will flow 
northbound only so no change in scaling properties.
Sandy> OK. I understand.

In short:

RR elects itself RR or not in the plane (section 6.3.2.1) and based on that  
assumes a special RR loopback with last byte representing its preference

X::[pref]

Every leaf tries to connect to

X::1
X::2
X::3

Which they know are RRs (# of RRs doesn’t matter, just pick a reasonable 
constant)

Each leaf elects own loopback in a well known range
Sandy> It's a reasonable design.