Subject: [GROW] Questions regarding draft-ietf-grow-bmp-local-rib

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Tue, 2 Apr 2019 04:04:27 +0000

Dear authors of draft-ietf-grow-bmp-local-rib,

I have some questions regarding the address family indication in the local-rib PEER DOWN.

Section 6.1.1. Multiple Loc-RIB Peers says:

   "...In some implementations, it might be required to have more than one
   emulated peer for Loc-RIB to convey different address families for
   the same Loc-RIB.  In this case, the peer distinguisher and BGP ID
   should be the same since it represents the same Loc-RIB instance.
   Each emulated peer instance MUST send a PEER UP with the OPEN message
   indicating the address family capabilities.  A BMP receiver MUST
   process these capabilities to know which peer belongs to which
   address family..."

Q1: Should different address families be carried in the same OPEN message or individual messages with the PEER UP for enabling different address families?

Section 5.3. Peer Down Notification says:

   Peer down notification SHOULD use reason code TBD3.  Following the
   reason is data in TLV format.  The following peer Down information
   TLV type is defined:

   o  Type = 3: VRF/Table Name.  The Information field contains an ASCII
      string whose value MUST be equal to the value of the VRF or table
      name (e.g.  RD instance name) being conveyed.  The string size
      MUST be within the range of 1 to 255 bytes.  The VRF/Table Name
      informational TLV SHOULD be included if it was in the Peer UP.

Q2: Is there a strong motivation of disabling different address families under the same VRF separately?
Q3: If yes to Q2, then where to carry such information in the PEER DOWN?

Thanks.

Yunan

Best Regards,

[a]
Dr. Yunan Gu
Huawei Technologies Co. Ltd
Beijing
IP Technology Research Division
156 Beiqing Rd
Phone: +86 15001353906

---

From: Paolo Lucente <[email-masked]>
Date: Thu, 4 Apr 2019 20:35:23 +0000

Hi Yunan,

A1: I would carry all supported AFs as part of the same OPEN message. But you could do different, say, emulate a peer for each different AF.
A2: I would myself say no (hence my A1 answer). Do you see a use-case for that?
A3: If you are positive on A2: would it work for you to emulate a peer for each different AF that you may want to tear down independently of the others?

Paolo

On 2 Apr 2019, at 06:04, Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]<mailto:[email-masked]>> wrote:

   “…In some implementations, it might be required to have more than one
   address family…”

Thanks.

Yunan

Best Regards,

Dr. Yunan Gu

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Tue, 9 Apr 2019 08:26:19 +0000

Hi Paolo,

Thanks for the reply.

Q2/A2: In fact, disabling/enabling AF separately is not motivated by use cases, in Huawei implementations, the route distinguishers (RDs) of v4 and v6 routes under the same VRF are set independently. Thus, it requires separate PEER UP messages for v4 and v6 AFs. Further, we’d like separate PEER DOWN indications. The V flag of the PER-PEER HEADER for adj-rib-in in RFC 7854 can do the work, however it’s not currently defined in the local rib PER-PEER HEADER. Do you have any suggestion as how to indicate this info in PEER DOWN?

Another question pops up: regarding multiple BGP instances, currently for Huawei implementations, we may configure the same router ID and same VRF name under different BGP instances. Thus, the current local-rib PEER UP is not capable of distinguish different BGP instances under certain cases. Do you think adding a new information TLV type indicating the BGP instance name in the PEER UP (similar to the VRF/Table Name) sounds reasonable?

BR,

Yunan

From: Paolo Lucente [mailto:[email-masked]]
Sent: Friday, April 05, 2019 4:35 AM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] Questions regarding draft-ietf-grow-bmp-local-rib

Hi Yunan,

Paolo

Thanks.

Yunan

Best Regards,

Dr. Yunan Gu