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

["Susan Hares" <[e-mail]>]

Robert and Stefano: 

I've pulled both of your comments to the front of this message.  

> 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

[Robert]: Very interesting comment 
[Robert]:  Where do you draw such conclusion from ?
[Robert]: IMO this draft has nothing to do with BGP-LS at all ...

See comment from draft-ietf-idr-bgp-prefix-sid-25 below to where I get the comment from. 

[Stefano]: the BGP prefix SID attribute is advertised in order to give
[Stefano]: a hint to the receiver on what label value to allocate for BGP labelled 
[Stefano]: routes. The receiver may or may not follow the hint.
[Stefano]: The BGPLS SR attributes are defined in order for a local router
[Stefano]: to advertise what he has allocated. Extensions have been defined
[Stefano]:  for the different use cases (IGP, EPE, TE, ...).

My technical problem #1 has to do with what happens if all of these come in the same BGP packet as combinations of BGP attributes or as combination of BGP attributes and NLRIs?  

The mechanisms between draft-bgp-prefix-sid and draft-bgp-ls-segment-routing-ext should be orthogonal, but what happens if by error they end up in the same BGP packet being sent to a BGP-LS capable peer, or to a BGP Peer capable of only draft-bgp-prefix-sid functions.   

My plea as an IDR reviewer is to improve the error handling descriptions in the drafts to have interoperable implementations before publication of draft-ietf-idr-bgp-prefix-sid-25.txt. 

Right now the implementations that are listed on the IDR page are RTBRICK and Cisco.   I quote the RTbrick Fullstack-OS 17.2 or greater comments "No interoperability testing has been done".   The only interoperability testing that has been done is "Cisco NX-OS and Cisco IOS-XR".   
Therefore, as a BGP Reviewer I look carefully at the BGP error handling in cases where single company interoperability testing between two unique implementation has been done.  

Sue   

===============
>From the draft-ietf-idr-bgp-prefix-sid-25 in section 2:

     This document assumes that BGP-LS is the preferred method for
      collecting both peer segments (Peer SIDs) and SRGB information
      through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and
      [I-D.ietf-idr-bgp-ls-segment-routing-ext].  However, as an
      optional alternative for the advertisement of the local SRGB
      without the topology nor the peer SIDs, hence without
      applicability for TE, the Originator SRGB TLV of the BGP Prefix-
      SID attribute is specified in Section 3.2 of this document.

Section 3.2 specifies the SRGB TLV.   

  
Draft-ietf-idr-bgp-ls-segment-routing-ext states: 
==========
2.  BGP-LS Extensions for Segment Routing

   This document defines SR extensions to BGP-LS and specifies the TLVs
   and sub-TLVs for advertising SR information.  Section 2.4 and
   Section 2.5 illustrates the equivalent TLVs and sub-TLVs in IS-IS,
   OSPFv2 and OSPFv3 protocols.

   BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a
   Link NLRI or a Prefix NLRI.  The corresponding BGP-LS attribute is a
   Node Attribute, a Link Attribute or a Prefix Attribute.

Section 2.1 defines the SID Node attribute TLVS, and the SR Local Block (specifies) the same SRGB TLV as above to be collected.  

BGP-LS Extensions for SR for BGP-EPE (draft-ietf-idr-bgpls-segment-routing-epe-15)   specifies setting the Peer-Node-SID in section 5.1.   Quoting from section 5.1

5.1.  Peer-Node-SID

   The Peer-Node-SID describes the BGP session peer (neighbor).  It MUST
   be present when describing a BGP-EPE topology as defined in
   [I-D.ietf-spring-segment-routing-central-epe].  The Peer-Node-SID is
   encoded within the BGP-LS Link NLRI specified in Section 4.

=============

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 2:00 AM
To: Susan Hares
Cc: Warren Kumari; Acee Lindem (acee); idr@ietf. org; [e-mail]; [e-mail]; The IESG
Subject: Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

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=