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

[Xuxiaohu <[e-mail]>]

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'
抄送: Keyur Patel (keyupate); [e-mail]
主题: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

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

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

Keyur,

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.

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

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

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