Subject: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 14 Nov 2014 00:24:14 +0000

The new BGP-Prefix-SID Label Index attribute avoids to pack routes in a single BGP update. I believe the authors did this for backward compatibility with RFC3107, etc +  the environment this is meant for does not need to scale to Millions of prefixes with this attribute. The result is that BGP NLRI(s) cannot be grouped in a single BGP update packet since the index is unique per prefix. We should clarify this because some environments might not cope with this very well.

Also I believe the solution should accommodate the ability to add multiple label blocks since we will never know up front how many prefixes we will allocate and things change, so operationally I believe this will be required.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 14 Nov 2014 00:50:13 +0000

发件人: Idr [mailto:[email-masked]] 代表 Henderickx, Wim (Wim)
发送时间: 2014年11月14日 8:24
收件人: [email-masked]
主题: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

[Xiaohu] Concur that it’s worthwhile to accommodate the ability to add multiple incontinuous label blocks on a given SR node. BTW, even given that each SR node is configured with only a single label block, how could one BGP router know the label block of another so as to establish an explicit path by using an MPLS label stack? It seems that there is no mention about the advertisement of the label block of each SR node.

Best regards,
Xiaohu

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 14 Nov 2014 13:04:58 -0500

> Also I believe the solution should accommodate the ability to add multiple label blocks since we will never know up front how many prefixes we will allocate and things change, so operationally I be…

SRGB is a local property of a node, I don't think this draft does
anything to change whether or not one or many SRGB ranges are used as
long as they are ordered and the label index received can be understood
and be computed into a local label value by the node receiving the
attribute.  Since SRGB is not sent between nodes by this draft, I don't
see any changes necessary to the text...