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

From: Jeff Tantsura <[email-masked]>
Date: Fri, 14 Nov 2014 03:10:12 +0000

Hi,

In BGP-LS-SR SRGB is encoded in SR Capabilities TLV (1034).
However today it comes from an IGP, e.g. Is ISIS case from SR Capabilities sub-TLV of Router Capability TLV, so BGP only case should be added.

Cheers,
Jeff

From: <Henderickx>, Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 13, 2014 at 4:24 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

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: "Keyur Patel (keyupate)" <[email-masked]>
Date: Fri, 14 Nov 2014 19:44:16 +0000

Jeff,

Yep. This would be a way of announcing SRGB.

Regards,
Keyur

From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 13, 2014 at 7:10 PM
To: "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

Hi,

Cheers,
Jeff

---

From: Ahmed Bashandy <[email-masked]>
Date: Fri, 14 Nov 2014 13:41:14 -0800

Hi,

There is a use case for sending the SRGB of a router in ISIS (e.g. ti-lfa)
What is the use case of having a BGP speaker send its SRGB to its peer 
in a BGP-only deployment?

Ahmed

On 11/13/2014 7:10 PM, Jeff Tantsura wrote:
> However today it comes from an IGP, e.g. Is ISIS case from SR 
> Capabilities sub-TLV of Router Capability TLV, so BGP only case should 
> be added.
>
> Cheers,
> Jeff
>
> From: <Henderickx>, Wim Henderickx <[email-masked] 
> <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>     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.
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 18 Nov 2014 18:50:26 +0100

hi ahmed,

short-answer: explicit routing using label-stacking.
(- isn't this what segment routing is about ;-) ?)

The problem is that an ingress router does not know
what the label-range of a egress router is.

so if you want to fold a stack using node-labels
and (*not* assuming identical label-ranges)
you need somehow to "learn" about the prefix-SID
originators label-range, such that you can construct
MPLS label stacks.

 range range range range range
 10000 10000 20000 40000 60000
 20000 20000 30000 50000 70000
   A-----B-----C------D-----E

so assume A wants to create a path
with ERO {C (Loose), E (Loose)}
we can use the 3107 provided label for
getting to C, but unless A "knows" (static config)
about the label-range from C there is now way
of construting the label to E.

/hannes

On Fri, Nov 14, 2014 at 01:41:14PM -0800, Ahmed Bashandy wrote:
|    Hi,
| 
|    There is a use case for sending the SRGB of a router in ISIS (e.g. ti-lfa)
|    What is the use case of having a BGP speaker send its SRGB to its peer in
|    a BGP-only deployment?
| 
|    Ahmed
| 
|    On 11/13/2014 7:10 PM, Jeff Tantsura wrote:
| 
|      Hi,
|      In BGP-LS-SR SRGB is encoded in SR Capabilities TLV (1034).
|      However today it comes from an IGP, e.g. Is ISIS case from SR
|      Capabilities sub-TLV of Router Capability TLV, so BGP only case should
|      be added.
|      Cheers,
|      Jeff
|      From: <Henderickx>, Wim Henderickx
|      <[1][email-masked]>
|      Date: Thursday, November 13, 2014 at 4:24 PM
|      To: "[2][email-masked]" <[3][email-masked]>
|      Subject: [Idr] draft-keyupate-idr-bgp-prefix-sid-00
| 
|        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.
| 
|  _______________________________________________
|  Idr mailing list
|  [4][email-masked]
|  [5]https://www.ietf.org/mailman/listinfo/idr
| 
| References
| 
|    Visible links
|    1. mailto:[email-masked]
|    2. mailto:[email-masked]
|    3. mailto:[email-masked]
|    4. mailto:[email-masked]
|    5. https://www.ietf.org/mailman/listinfo/idr

| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 18 Nov 2014 20:51:11 +0000

I concur below response.

>(*not* assuming identical label-ranges)

IMO there are total 2 (actually 3) options

1. Like the node doing "epe" making an eBGP connection to do BGP-LS, every node can do the same and send SRGB to a controller
2. Somehow send SRGB (multiple ranges if needed) to all the nodes 
       - I saw few comments on new SAFI etc - but still not clear how to flood these
3. Use SAME SRGB range on all nodes and send global prefix SID index
        - this is the one it seems envisioned here (from SPRING presentation)
        - but I would note that -  AFAICT  the point of "Globally unique index" came because you can't agree on a common SRGB range in a multi-vendor environment 
    (this is kind of mixed mode, same ranges on all nodes and send global index as opposed to what is proposed in SR base documents - viz
          a. same ranges and sending globally unique absolute SID value or
          b. different ranges on each node and using globally unique index)
--
Uma C.

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Hannes Gredler
Sent: Tuesday, November 18, 2014 9:50 AM
To: Ahmed Bashandy
Cc: [email-masked]
Subject: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

hi ahmed,

The problem is that an ingress router does not know what the label-range of a egress router is.

so if you want to fold a stack using node-labels and (*not* assuming identical label-ranges) you need somehow to "learn" about the prefix-SID originators label-range, such that you can construct MPLS label stacks.

so assume A wants to create a path
with ERO {C (Loose), E (Loose)}
we can use the 3107 provided label for
getting to C, but unless A "knows" (static config) about the label-range from C there is now way of construting the label to E.

/hannes