Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

[stefano previdi <[e-mail]>]

Hi,

the BGP prefix SID attribute is advertised in order to give a hint to the receiver on what label value to allocate for BGP labelled routes. The receiver may or may not follow the hint.

The BGPLS SR attributes are defined in order for a local router to advertise what he has allocated. Extensions have been defined for the different use cases (IGP, EPE, TE, ...).

I agree with Robert’s statement: BGP Prefix SID is orthogonal to any BGPLS advertisement.

Thanks.
s.


> On Jun 21, 2018, at 7:59 AM, Robert Raszuk <[e-mail]> wrote:
> 
> Hi Sue,
> 
>> The mechanism in draft-idr-bgp-prefix-sid-25.txt is a BGP  attribute sent
> as an exception if the BGP-LS service for Segment Routing (SR) is not
> available.
> 
> Very interesting comment ... Where do you draw such conclusion from ?
> 
> IMO this draft has nothing to do with BGP-LS at all ...
> 
> BGP-LS is gathering data from network elements to controller ... this draft
> is installing SIDs from controller to ingress network elements. While
> mutually required for some solutions they are completely orthogonal to each
> other.
> 
> Best,
> R.
> 
> 
> On Thu, Jun 21, 2018 at 2:02 AM, Susan Hares <[e-mail]> wrote:
> 
>> Warren, Robert, Acee:
>> 
>> 
>> 
>> Warren has a valid question.  I cannot find a long mail thread on
>> transitive or non-transitive for this specific attribute.
>> 
>> 
>> 
>> Answering Warren’s question about discussions in WG also requires it
>> within a larger discussion. The mechanism in draft-idr-bgp-prefix-sid-25.txt
>> is a BGP  attribute sent as an exception if the BGP-LS service for Segment
>> Routing (SR) is not available. The BGP-LS service for SR routing consists
>> of BGP-LS NLRI and BGP Attributes.  Draft-idr-bgp-prefix-sid’s mechanism
>> expands the traffic flow burden for BGP beyond just BGP-LS peers. Is this
>> wise beyond a single AS?
>> 
>> 
>> 
>> Some long-term participants of IDR say it is unwise to expand BGP-LS to SR
>> routing (Robert Raszuk, Tony Li). Therefore I suspect that restricting
>> draft-idr-bgp-prefix-sid to a non-transitive attribute lessens some
>> concerns, but does not resolve the main issues.
>> 
>> 
>> 
>> The question of transitive or non-transitive depends on what you think SR
>> and BGP’s mechanisms for SR should do. If you think SR is a vibrant
>> technology which would should help to mature, then you may want to make it
>> easy for the multiple ASes within a Data Center to use the SR functions.
>> If this is your belief, then the attribute should be transitive.
>> 
>> 
>> 
>> If you are concerned about BGP-LS and SR requiring additional resources of
>> BGP peers which do not support BGP-LS, then you will want the attribute to
>> be non-transitive or refuse to standardize this mechanism.
>> 
>> 
>> 
>> To review IDR’s decision (and the IESG should), you will need to put in
>> the context of the entire SR mechanisms that are forthcoming in BGP based
>> on the SR Architecture decided by SPRING.  The IESG has approved SR
>> architecture and main applications (draft-ietf-spring-segment-routing,
>> draft-ietf-spring-segment-routing-central-epe-10.txt., and
>> drat-ietf-segment-routing-msdc-09.txt), but it has not looked at the
>> mechanisms for SR extensions to BGP-LS or the concept of extending BGP-LS