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

[Hannes Gredler <[e-mail]>]

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][e-mail]>
|      Date: Thursday, November 13, 2014 at 4:24 PM
|      To: "[2][e-mail]" <[3][e-mail]>
|      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][e-mail]
|  [5]https://www.ietf.org/mailman/listinfo/idr
| 
| References
| 
|    Visible links
|    1. mailto:[e-mail]
|    2. mailto:[e-mail]
|    3. mailto:[e-mail]
|    4. mailto:[e-mail]
|    5. https://www.ietf.org/mailman/listinfo/idr

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