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

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Nov 2014 08:23:35 +0100

​Keyur,

1.

How do you envision this to work when only subset of nodes supports the new
attribute ?

To me the document misses the partial deployment section even it is to say
that it is not supported :)

2.

What happens when we receive two paths for a given NLRI however only one
carries such attribute and the one without it is selected as best path ?

3.

What is really wrong with using 3107 label carried in the MP_REACH as a SID
?

Thx,
r.

​

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 14 Nov 2014 09:55:13 -0500

My $0.02 on some of the issues raised at the mike and on this thread.

There was a brief discussion at the mike about the fact that when used
with SAFI 128, this draft is assigning prefix-SIDs to "service routes"
rather than to "transport routes".  I think I heard (the Meetecho
audio was a bit rough) Saikat say "think about option B".  I guess this
is a reference to the fact that at an option B ASBR, the service label
rises to the top of the stack, and in effect serves as the transport
label.  So if one is using inter-AS option B, the use of the prefix-SID
attribute for SAFI 128 routes is consistent with a desire to use
prefix-SIDs for transport.

Whether there is any point in doing so is a different issue.

Anyway, the draft really ought to discuss the option B scenario, and
perhaps also discuss whether the prefix-SID mechanism would also be used
in option C scenarios.

Note that if a DC consists of thousands of ASes, each with exactly two
BGP speakers, the service label serves as the transport label along the
entire path.  However, in a case like this, I don't think it's going to
be adequate to rely on per-session policies to constrain the
distribution of the prefix-SIDs.  I think the draft needs more attention
to the issue of how you can tell whether an Update has reached the
boundary of the domain in which the prefix-SID is valid.

A few other comments.

As others have already pointed out, the draft fails to say anything
about the advertisement of the SRGB label ranges.  This does not seem
like something that can just be declared "out of scope".  I also tend to
agree with Wim and Xiaohu that requiring the use of a single SRGB label
block per node seems very restrictive.

Wim states:

> 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.

Well, it will be difficult in any case for an LSR to find an available 
label range (or even a set of non-contiguous label ranges) that can 
contain millions of labels!  The draft should really discuss the scaling 
requirements.  Once the scaling requirements are understood, one can 
look at the impact of the inability to do attribute-packing.  (Of 
course, the scaling requirements depend not only on the number of 
prefixes, but on the label assignment strategy, e.g., per-route vs. 
per-VRF.)

As Robert suggests, the draft is not very explicit about the 
significance of the label that is encoded into the NLRI.  Suppose one 
receives an update where the NLRI prefix is X, the label encoded into 
the NLRI is L1, the next hop is N, and the label computed from the 
combination of Label Index attribute and N's SRGB label base is L2.  If 
one is sending a packet to X via N, the draft seems to leave one with 
the option of using either L1 or L2 as the label.  This means that N has 
to have both labels programmed for prefix X.

Is this really the intention of the authors?  If so, then unless L1 is 
required to be the same as L2, this doubles the number of labels that 
are needed.  On the other hand, one could require that L1 be the same as 
L2.  But in this case, there doesn't seem to be any point in having the 
Label Index attribute at all.

I'd appreciate some clarification on this issue.

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 14 Nov 2014 12:53:39 -0500

Inline...

> How do you envision this to work when only subset of nodes supports the new

Since this in no way changes the normal BGP-3107 forwarding paradigm
there is no issue here.  The operator can partially deploy the support
of this attribute and the local label of the routers that support it
will be set appropriately based on their local SRGB offset by the index
learned in the attribute.  The remote label used for forwarding/swap is
still the one learned from the remote peer, not at all influenced by the
attribute regardless of the remote peers capability to understand it.

> carries such attribute and the one without it is selected as best path ?

This is a good question and sould be clarified in the draft.  Presumably
we would want if it is bestpath or multipath capable to use the
attribute for local label programming.  Either way forwarding based on
the remote label learned via 3107 would work fine and be not impacted.

> What is really wrong with using 3107 label carried in the MP_REACH as a SID

Re-written at every hop, no deterministic behavior can be assumed.  We
are using 3107 label as SID if every node has capability for attribute
and has same SRGB configured effectively.

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Nov 2014 19:01:19 +0100

Hi Jon,

Inline ...

> attribute regardless of the remote peers capability to understand it.

​In your view do you still need to run LDP in intra-domian deployment to
get you LSP between SR nodes ? ​

> the remote label learned via 3107 would work fine and be not impacted.

​I think your scenario is EBGP based while the draft says:

"A BGP speaker receiving a BGP Label index attribute from its EBGP neighbor
SHOULD discard the attribute unless it is configured to accept the
attribute from the EBGP neighbor.​"

My point was more on intra-as RR, but also applies to EBGP case when one
peer sends you attribute with label X and other with no attribute at all.

> and has same SRGB configured effectively.

​Well it is rewritten when you set next hop self. In intra-domain case you
rather not doing it too often.

​For inter-domain I see where your reply is coming from, but I am not sure
we are really there yet with this concept :)

Cheers,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 14 Nov 2014 18:42:05 +0000

Hi Eric,

Please see my comments inline.

-----邮件原件-----
发件人: Idr [mailto:[email-masked]] 代表 Eric C Rosen
发送时间: 2014年11月14日 22:55
收件人: [email-masked]
抄送: Keyur Patel (keyupate); Robert Raszuk
主题: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

There was a brief discussion at the mike about the fact that when used with SAFI 128, this draft is assigning prefix-SIDs to "service routes"
rather than to "transport routes".  I think I heard (the Meetecho audio was a bit rough) Saikat say "think about option B".  I guess this is a reference to the fact that at an option B ASBR, the service label rises to the top of the stack, and in effect serves as the transport label.  So if one is using inter-AS option B, the use of the prefix-SID attribute for SAFI 128 routes is consistent with a desire to use prefix-SIDs for transport.

Anyway, the draft really ought to discuss the option B scenario, and perhaps also discuss whether the prefix-SID mechanism would also be used in option C scenarios.

Note that if a DC consists of thousands of ASes, each with exactly two BGP speakers, the service label serves as the transport label along the entire path.  However, in a case like this, I don't think it's going to be adequate to rely on per-session policies to constrain the distribution of the prefix-SIDs.  I think the draft needs more attention to the issue of how you can tell whether an Update has reached the boundary of the domain in which the prefix-SID is valid.

A few other comments.

As others have already pointed out, the draft fails to say anything about the advertisement of the SRGB label ranges.  This does not seem like something that can just be declared "out of scope".  I also tend to agree with Wim and Xiaohu that requiring the use of a single SRGB label block per node seems very restrictive.

> does not need to scale to Millions of prefixes with this attribute.

Well, it will be difficult in any case for an LSR to find an available label range (or even a set of non-contiguous label ranges) that can contain millions of labels!  The draft should really discuss the scaling requirements.  Once the scaling requirements are understood, one can look at the impact of the inability to do attribute-packing.  (Of course, the scaling requirements depend not only on the number of prefixes, but on the label assignment strategy, e.g., per-route vs. 
per-VRF.)

As Robert suggests, the draft is not very explicit about the significance of the label that is encoded into the NLRI.  Suppose one receives an update where the NLRI prefix is X, the label encoded into the NLRI is L1, the next hop is N, and the label computed from the combination of Label Index attribute and N's SRGB label base is L2.  If one is sending a packet to X via N, the draft seems to leave one with the option of using either L1 or L2 as the label.  This means that N has to have both labels programmed for prefix X.

Is this really the intention of the authors?  If so, then unless L1 is required to be the same as L2, this doubles the number of labels that are needed.  On the other hand, one could require that L1 be the same as L2.  But in this case, there doesn't seem to be any point in having the Label Index attribute at all.

[Xiaohu] In the above case, L1 should be the same as L2. My understanding of this draft is: Assume there is no usage of a LSP hierarchy for defining an explicit path, the current label distribution process (i.e., labeled BGP as defined in RFC3107) is good enough. Of course, index-based label advertisement process works as well AS LONG AS all BGP nodes are capable of processing the label-index attribute. The distinctive usage of the index-based label advertisement is the explicit path using stacked labels since the label for a given /32 or /128 prefix FEC on a certain BGP node be visible to all the other BGP nodes. In this source routing case, the labeled BGP approach as defined in RFC3107 is still useful for those legacy routers which don't support the new attribute(s) as defined in this draft. Of course, those legacy routers could not be used as explicitly specified hops along this explicit path.

Best regards,
XIaohu

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Fri, 14 Nov 2014 19:49:47 +0000

Hi Robert,

Comments inlined #Keyur
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 13, 2014 at 11:23 PM
To: Keyur Patel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

​Keyur,

1.

How do you envision this to work when only subset of nodes supports the new attribute ?

To me the document misses the partial deployment section even it is to say that it is not supported :)

#Keyur: We have made no change to RFC3107. So the node[s] not implementing the new attribute will 1) assign labels as per RFC 3107 rules and 2) still announce the attribute as its optinal transitive.

2.

What happens when we receive two paths for a given NLRI however only one carries such attribute and the one without it is selected as best path ?

#Keyur: Best path decides which path gets chosen (as usual). Labels would be assigned from the private label space if the path without an attribute is chosen as the best path. Otherwise, the label is computed off the label-index attribute.

3.

What is really wrong with using 3107 label carried in the MP_REACH as a SID ?

#Keyur: Nothing.  The draft assumes operates over RFC3107.

Regards,
Keyur

Thx,
r.

​

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Nov 2014 21:00:31 +0100

Keyur,

>  #Keyur: We have made no change to RFC3107. So the node[s] not
> implementing the new attribute will 1) assign labels as per RFC 3107 rules
> and 2) still announce the attribute as its optinal transitive.
>

​You are missing my question obviously.

Imagine RR sending this attribute over IBGP to 100 clients. Only 10 of them
support it. How the remaining 90 would know how to forward packets ? ​

​There is no assignment I am talking about here. Just receiving side only. ​

#Keyur: Best path decides which path gets chosen (as usual). Labels would
> be assigned from the private label space if the path without an attribute
> is chosen as the best path. Otherwise, the label is computed off the
> label-index attribute.
>

​Again I am not talking about assigning labels. ​

3.
>  #Keyur: Nothing.  The draft assumes operates over RFC3107.

​But for IBGP what is the value for new attribute then ? Why label carried
within NLRI can not be a SID ?

For EBGP perhaps due to NHS I see the point but I do not see how to deploy
it in a mixed env when only some nodes support it. ​

Thx,
R.

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Fri, 14 Nov 2014 20:05:55 +0000

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 14, 2014 at 12:00 PM
To: "Keyur Patel (keyupate)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

Keyur,

Imagine RR sending this attribute over IBGP to 100 clients. Only 10 of them support it. How the remaining 90 would know how to forward packets ? ​

[SR] The forwarding (outgoing label) is done only using 3107 label. The label index attribute is only used for assigning "local" label.

There is an example in the Spring presentation of draft-filsfils-spring-segment-routing-msdc.

3.

​But for IBGP what is the value for new attribute then ? Why label carried within NLRI can not be a SID ?

For EBGP perhaps due to NHS I see the point but I do not see how to deploy it in a mixed env when only some nodes support it. ​

Thx,
R.

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Fri, 14 Nov 2014 20:07:00 +0000

Hi Robert,

One comment inlined #Keyur.

Keyur,

3.

#Keyur:
Because the IBGP network could 1) have routers not enabled with this feature and hence may have computed labels off their private space and 2) SRGB range maybe different. SRGB is configured on each and every BGP speaker.

Regards,
Keyur

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Nov 2014 21:10:49 +0100

Hi Saikat,

[SR] The forwarding (outgoing label) is done only using 3107 label. The
> label index attribute is only used for assigning "local" label.
>
>  There is an example in the Spring presentation of
> draft-filsfils-spring-segment-routing-msdc.
>

​3107 label can not be used for forwarding (except very specific topology)
as BGP is not congruent with data plane in general.

3107 label can be used (and is used) for hierarchy creation or as local
label. Underneath for actual forwarding you still have LDP or RSVP-TE or
GRE ...

r.

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Fri, 14 Nov 2014 20:16:44 +0000

If it is hop-by-hop BGP-only network, you can use the BGP labels for forwarding. In other cases, you use it as the "inner" label. The outer label remains the "IGP label" (either LDP assigned or IGP carried SR label, etc.).

The essential point is, nothing of the forwarding is changed. The only thing is that is changed is the "local label" assignment. When a router A assigns its "local label" (if it needs to do so for the purpose of further advertisement of the route with itself as nexthop), normally it would assign a "random" label from its dynamic label range. If the bestpath carries a label-index attribute, it is a request to router A to assign the "derived label" as the local label instead of a random one.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 14, 2014 at 12:10 PM
To: sairay <[email-masked]<mailto:[email-masked]>>
Cc: "Keyur Patel (keyupate)" <[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 Saikat,

​3107 label can not be used for forwarding (except very specific topology) as BGP is not congruent with data plane in general.

3107 label can be used (and is used) for hierarchy creation or as local label. Underneath for actual forwarding you still have LDP or RSVP-TE or GRE ...

r.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Nov 2014 21:22:42 +0100

So for intra-domain we agree we need forwarding labels so we have IGP hence
no need to send SIDs label in BGP.

For EBGP all cases it "could be useful" are MPLS free so no point to have
this attribute as well. Nor 3107 is running there. If anything v6 SR is to
be used.

Hence natural question why do we need it ?

Cheers,
R.

On Fri, Nov 14, 2014 at 9:16 PM, Saikat Ray (sairay) <[email-masked]>
wrote:

>  If it is hop-by-hop BGP-only network, you can use the BGP labels for
> forwarding. In other cases, you use it as the "inner" label. The outer
> label remains the "IGP label" (either LDP assigned or IGP carried SR label,
> etc.).
>
>  The essential point is, nothing of the forwarding is changed. The only
> thing is that is changed is the "local label" assignment. When a router A
> assigns its "local label" (if it needs to do so for the purpose of further
> advertisement of the route with itself as nexthop), normally it would
> assign a "random" label from its dynamic label range. If the bestpath
> carries a label-index attribute, it is a request to router A to assign the
> "derived label" as the local label instead of a random one.
>
>   From: "[email-masked]" <[email-masked]>
> To: sairay <[email-masked]>
> Cc: "Keyur Patel (keyupate)" <[email-masked]>, "[email-masked]" <
> [email-masked]>
>    [SR] The forwarding (outgoing label) is done only using 3107 label.
>> The label index attribute is only used for assigning "local" label.
>>
>   ​3107 label can not be used for forwarding (except very specific
> topology) as BGP is not congruent with data plane in general.
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 14 Nov 2014 20:25:27 +0000

发件人: Idr [mailto:[email-masked]] 代表 Keyur Patel (keyupate)
发送时间: 2014年11月15日 3:50
收件人: Robert Raszuk
抄送: [email-masked]
主题: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

Hi Robert,

Comments inlined #Keyur

​Keyur,

1.

2.

[Xiaohu] Even the path with such attribute is selected as the best path, the label carried in the NRLI SHOULD be the same as that which is computed off the label-index attribute. Otherwise, the issue as mentioned by Eric would be raised. The unique role of the index-based label computation is just like that of the T-LDP (see https://tools.ietf.org/html/draft-gredler-spring-mpls-06) in case there are some legacy BGP routers between those explicitly specified hops

3.

[Xiaohu] Not wrong. Instead, it’s beneficial for incremental deployment, just like the benefit of the LDP for the IGP-SR.

Best regards,
Xiaohu

Regards,
Keyur

Thx,
r.

​

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Fri, 14 Nov 2014 20:25:45 +0000

Date: Friday, November 14, 2014 at 12:22 PM

So for intra-domain we agree we need forwarding labels so we have IGP hence no need to send SIDs label in BGP.

For EBGP all cases it "could be useful" are MPLS free

[SR] Which is something we are advocating to change ;)

so no point to have this attribute as well. Nor 3107 is running there. If anything v6 SR is to be used.

Cheers,
R.

On Fri, Nov 14, 2014 at 9:16 PM, Saikat Ray (sairay) <[email-masked]<mailto:[email-masked]>> wrote:
If it is hop-by-hop BGP-only network, you can use the BGP labels for forwarding. In other cases, you use it as the "inner" label. The outer label remains the "IGP label" (either LDP assigned or IGP carried SR label, etc.).

Hi Saikat,

r.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 14 Nov 2014 20:44:07 +0000

Hi Robert,

My understanding is: to allow the usage of the label stack for explicit path, the label assigned by a given node which would be used as an explicitly specified node along a given explicit path should be visible to all other BGP peers, not just its adjacent BGP peers. The advertisement of such globally visible (not globally unique☺) labels allocated by a given node (by advertisement of index and SRGB) happened to be piggbacked on the the labeled BGP update for a routable address of that node.

Best regards,
Xiaohu

发件人: Idr [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2014年11月15日 4:01
收件人: Keyur Patel (keyupate)
抄送: [email-masked]
主题: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

Keyur,

3.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 14 Nov 2014 21:55:19 +0100

Xiaohu,

> the label assigned by a given node which would be used as an explicitly
> specified node along a given explicit path should be visible to all other
BGP
> peers, not just its adjacent BGP peers.

/* Just talking about forwarding based on 3107 not this new attribute ....
*/

And that is precisely not how BGP works as BGP does not flood, but sends
best path only.

Even assuming there is no policy and also assuming that everyone in the
mesh is actually enabled for 3107 which may or may not be the case. Further
other BGP speakers will have no clue one AS away who was and who was not
enabled for 3107 :)

Cheers,
R.

On Fri, Nov 14, 2014 at 9:44 PM, Xuxiaohu <[email-masked]> wrote:

>  Hi Robert,
>
>
>
> My understanding is: to allow the usage of the label stack for explicit
> path, the label assigned by a given node which would be used as an
> explicitly specified node along a given explicit path should be visible to
> all other BGP peers, not just its adjacent BGP peers. The advertisement of
> such globally visible (not globally uniqueJ) labels allocated by a given
> node (by advertisement of index and SRGB) happened to be piggbacked on the
> the labeled BGP update for a routable address of that node.
>
>
>
> Best regards,
>
> Xiaohu
>
>
>
> *发件人:* Idr [mailto:[email-masked]] *代表 *Robert Raszuk
> *发送时间:* 2014年11月15日 4:01
> *收件人:* Keyur Patel (keyupate)
> *抄送:* [email-masked]
> *主题:* Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00
>
>
>
> Keyur,
>
>
>
> #Keyur: We have made no change to RFC3107. So the node[s] not implementing
> the new attribute will 1) assign labels as per RFC 3107 rules and 2) still
> announce the attribute as its optinal transitive.
>
>
>
> Imagine RR sending this attribute over IBGP to 100 clients. Only 10 of
> them support it. How the remaining 90 would know how to forward packets ?
> ​
>
>
>
>  #Keyur: Best path decides which path gets chosen (as usual). Labels
> would be assigned from the private label space if the path without an
> attribute is chosen as the best path. Otherwise, the label is computed off
> the label-index attribute.
>
>
>
>
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 14 Nov 2014 21:16:29 +0000

The advertisement of SRGBs and index for a given SR node is independent from the best path selection criteria at all. It just happens to be piggbacked on  the reachability advertisement of the routable address of that node. It has some similarity with the ISIS-SR approach in which the globally visible index/label is piggbacked on the reachability advertisement TLVs to some extent. It also has similarity with the usage of the ISIS prefix-specific attribute TLV in which the node-specific information (e.g., index and SRGB(s)) is contained in a prefix-specific attribute TLV. In the link-state IGP case (take the ISIS as an example),  there are two choices: one is to use the prefix-specific TLVs, the other is to use the node-specific TLV (e.g., router-capability TLV). Personally, I prefer the latter except that the SR-related information would be distribute by mapping servers on behalf of SR nodes. However, in the path-vector routing protocol (e.g., BGP), there is no alternative choice.

Best regards,
Xiaohu

发件人: Idr [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2014年11月15日 4:55
收件人: Xuxiaohu
抄送: Keyur Patel (keyupate); [email-masked]
主题: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

Xiaohu,

> specified node along a given explicit path should be visible to all other BGP

/* Just talking about forwarding based on 3107 not this new attribute .... */

And that is precisely not how BGP works as BGP does not flood, but sends best path only.

Even assuming there is no policy and also assuming that everyone in the mesh is actually enabled for 3107 which may or may not be the case. Further other BGP speakers will have no clue one AS away who was and who was not enabled for 3107 :)

Cheers,
R.

On Fri, Nov 14, 2014 at 9:44 PM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Best regards,
Xiaohu

发件人: Idr [mailto:[email-masked]<mailto:[email-masked]>] 代表 Robert Raszuk
发送时间: 2014年11月15日 4:01
收件人: Keyur Patel (keyupate)
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

Keyur,

3.

Thx,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 14 Nov 2014 21:28:11 +0000

Sorry that I have forgotten other alternatives, e.g., using node-specific BGP-LS, using independent SAFI, just as what have been considered in the attached.

Best regards,
Xiaohu

发件人: Xuxiaohu
发送时间: 2014年11月15日 5:18
收件人: 'Robert Raszuk'

Best regards,
Xiaohu

发件人: Idr [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2014年11月15日 4:55
收件人: Xuxiaohu
抄送: Keyur Patel (keyupate); [email-masked]<mailto:[email-masked]>
主题: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

Xiaohu,

Cheers,
R.

Best regards,
Xiaohu

Keyur,

3.

Thx,
R.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 22 Nov 2014 23:52:44 +0000

If only one segment is required to forward a packet, then
we use regular 3107 and only L1 is needed. L2 is redundant.

However...

when we use multiple segments, for which the whole concept of
segment routing is useful, the ingress router must know the labels
used by subsequent segment routers in the segment list. Those
labels are NOT advertised by RFC3107. The label index is used to
derive them.

L1 can be used to get to the nexthop at the end of the first
segment, but to derive the subsequent labels in the segment list,
the ingress router needs the label index and the SRGB of all the
routers in the list. [Thanks to Albert Tian for pointing this
out to me. Albert, correct me if I misinterpreted]

As far as SRGB is concerned, why would a data center operator
not configure all routers with the same SRGB?

--Jakob

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Eric C Rosen
> Sent: Friday, November 14, 2014 6:55 AM
> 
> significance of the label that is encoded into the NLRI.  Suppose
> one receives an update where the NLRI prefix is X, the label encoded
> into the NLRI is L1, the next hop is N, and the label computed from
> the combination of Label Index attribute and N's SRGB label base is
> L2.  If one is sending a packet to X via N, the draft seems to leave
> one with the option of using either L1 or L2 as the label.  This
> means that N has to have both labels programmed for prefix X.
> 
> Is this really the intention of the authors?  If so, then unless L1
> is required to be the same as L2, this doubles the number of labels
> that are needed.  On the other hand, one could require that L1 be
> the same as L2.  But in this case, there doesn't seem to be any
> point in having the Label Index attribute at all.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 23 Nov 2014 01:11:18 +0100

Hi Jakob,

> Those labels are NOT advertised by RFC3107. The label index is used to derive
them.

It is not about what get's advertised with 3107 .. it is about using
distance vector (with policy and heavy ECMP) to build your data plane paths
which worries me.

- - -

> not configure all routers with the same SRGB?

That is not the question to be asked.

The question is why would DC operator configure any SRGB at all.
For substantial arguments pls see:
http://www.ietf.org/mail-archive/web/spring/current/msg01188.html

Thx,
R.

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 24 Nov 2014 16:08:11 -0500

See question in-line.

> labels are NOT advertised by RFC3107. The label index is used to

If the ingress router knows the label advertised by the next hop (L1), 
and if it knows the SRGB of the next hop, then why can't it just  figure 
out the "label index" by doing a subtraction?  Why the need for a 
separate attribute that specifies the label index?

> not configure all routers with the same SRGB?

Because the available SRGB values are platform-dependent?

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 24 Nov 2014 21:25:12 +0000

> From: Eric C Rosen [mailto:[email-masked]]
> Sent: Monday, November 24, 2014 1:08 PM
> 
> See question in-line.
> 
> > If only one segment is required to forward a packet, then we use
> > regular 3107 and only L1 is needed. L2 is redundant.
> >
> > However...
> >
> segment
> > routing is useful, the ingress router must know the labels used by
> > subsequent segment routers in the segment list. Those labels are
> NOT
> > advertised by RFC3107. The label index is used to derive them.
> 
> If the ingress router knows the label advertised by the next hop
> (L1), and if it knows the SRGB of the next hop, then why can't it
> just  figure out the "label index" by doing a subtraction?  Why the
> need for a separate attribute that specifies the label index?

Because a neighbor may advertise 3 (implicit null)

--Jakob

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Tue, 25 Nov 2014 00:21:23 +0000

Also the neighbor might not support SR. I.e., if there is a topology
A--B--C, where A and C support SR, but B doesn't. The attribute is needed
for C to know what label-index A is using (for A's loopback interface).