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

[Robert Raszuk <[e-mail]>]

​​Hello Sue,

Ok I see where your comment came from. Let me provide my POV on this:

* We were commenting in reference to section 3.1 Label-Index TLV while
clearly your comment was based on section 3.2 Originator SRGB TLV

* Yes there can be case you describe that both BGP-LS and this extension
advertises SRGB ranges of the node. But at most I would treat this as
redundant information. If there is mismatch then I suppose there are bigger
issues to be solved and I am not sure if they are actually in scope of this
proposal or IDR.

Along the same lines you could stop BGP-LS RFC and ask what happens if
BGP-LS fed information is different then listening to IGP by the controller
? I guess controller must be at min that much smart to handle it, raise the
alarms etc ...

Clearly those are important topics, but I fail to see how they are at all
related to BGP.  BGP is just a truck here :).

Cheers,
R.








On Thu, Jun 21, 2018 at 12:45 PM, Susan Hares <[e-mail]> wrote:

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