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

[Robert Raszuk <[e-mail]>]

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.
>
>
>
> The rest of this long memo has two parts:
>
>
>
> 1)  2 problems I see in the current draft-ietf-bgp-peer-sid based on
> additional reviews of BGP documents I did in preparation for this IESG
> Review of this document,
>
>
>
> 2)  Big picture information for Warren’s information
>
>
>
> 3)  Summary of current status of BGP work regarding SR and BGP-LS
>
>
>
> If Warren or the IESG has not considered these issues in depth, I
> recommend the scope of the SR and BGP additions for SR are such that we
> should hold a briefing session for the IESG at Montreal.
>
>
>
> As IDR co-chair, it is my hope to move all of these documents on BGP-LS
> additions for SR toward completion (standardization or closure on next
> steps) within the next few months.
>
>
>
> Susan Hares
>
> Shepherd
>
> IDR co-chair
>
>
>
> =======================================================
>
>
>
> Personal concerns as co-chair on draft
>
> =======================
>
> Please note that I see the BGP-LS work as a vibrant technology that needs
> to have error handling and manageability improved in order to be released
> in an environment where BGP Peers are interoperable/
>
>
>
> Problem 1:
>
> I noted over the weekend that draft-ietf-bgp-prefix-sid-25.txt does not
> specify what happens with the BGP attribute for BGP Peer-SID is contained
> in a BGP packet with:
>
> ·         BGP Attribute for BGP-LS with BGP attributes for SR routing
> (per draft-ietf-idr-bgp-ls-segment-routing-ext-08),  or
>
> ·         BGP Attribute for BGP-LS with BGP attributes for BGP-EPE SR
> routing for the centralized controller form of segment routing (per
> draft-ietf-idr-bgpls-segment-routing-epe-15).
>
>
>
> I noticed that the drafts simply say the normal BGP-LS error handling will
> work, but these normally fine BGP-LS attributes are not valid when taken
> together. This is “content” checking – so the drafts all need to be
> revised.  (see my shepherd comments on the drafts).
>
>
>
> Problem 2:
>
> Another concern is draft-ietf-spring-segment-routing-msdc-09 in section
> 4.1 makes RFC8277 (BGP with labels) + BGP attribute for bgp-prefix SID as
> the main BGP choice for the data center.  The direction does not match the
> statement draft-ietf-idr-bgp-prefix-sid-25 that says:
>
>       This document assumes that BGP-LS is the preferred method for
>
>       collecting both peer segments (Peer SIDs) and SRGB information
>
>       through [RFC7752 <https://tools.ietf.org/html/rfc7752>], [
> I-D.ietf-idr-bgpls-segment-routing-epe
> <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-25#ref-I-D.ietf-idr-bgpls-segment-routing-epe>],
> and
>
>       [I-D.ietf-idr-bgp-ls-segment-routing-ext
> <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-25#ref-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
> <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-25#section-3.2>
> of this document.
>
>
>
> The draft-ietf-spring-segment-routing-msdc-09.txt does not really treat
> the draft-ietf-bgp-prefix-sid-25.txt as an “exception”.  It is this
> creeping feature that has made some long-time IDR participants asked where
> the boundaries of the SR additions to BGP are.
>
>
>
> As IDR co-chair, I need to understand is the bgp attribute for BGP Peer
> SID an exception for a corner case (as IDR WG says) or a main mechanism of
> a use case (as SPRING WG Says).
>
>
>
> ======================
>
> Overview of the BGP-LS discussion
>
> -------------
>
> A) Big picture Issues
>
>
>
> BGP-LS was passed due as an informational stream among specific routers
> that were carrying information to the centralized controller. This
> information stream was to limited to a set of BGP peers who primary job was
> to pass information to allow off-line computation of routes (SDN or
> centralized controller).
>
>
>
> BGP-LS for segment routing adds feedback to this information stream by
> providing mechanisms to tag certain links, nodes, adjacencies, and Peer
> sets as segments. Based on this information routing can utilize these
> segments to established smart forwarding planes to enable source-routing
> protocol within a domain.  The BGP-LS weight is currently carried only by
> the routers who have BGP-LS functions.
>
>
>
> The expansion outside of that set of peers to general BGP peers is what
> the draft-bgp-prefix-sid-25 is proposing.  This expansion may spread the
> burden of information flow to more peers than the original scope of BGP-LS.
>
>
>
> SPRING’s WG is spreading the amount of information sent by BGP-LS peers.
>
>
>
> With the IESG’s approval of draft-ietf-spring-segment-routing and
> draft-spring-segment-routing-central-epe, you have enabled an
> architecture that allows SDN controller to control a single AS or a group
> of ASes within the wide-area. With draft-ietf-spring-segment-routing-msdc,
> you have enable for one or many datacenters.  Data centers may have
> thousands or tens of thousands of BGP ASes (from the private AS space).
>
>
>
> The expansion of BGP to carrying massive amounts of Traffic Engineering
> for IGPs (draft-ietf-idr-te-pm-bgp-10.txt, draft-ietf-idr-segment-routing-te-policy-02)
> and BGPs is a natural outgrowth of the source-routing use of BGP.  This
> direction needs to be confirmed before we send the next 10 drafts from IDR
> into the IESG.  In this way, the IESG will agree to the direction and then
> each draft can be evaluate in terms of its fitting with the direction.
>
>
>
> Have the Security ADs taken a strong look at the potential failure cases
> for the Segment Routing architecture as expressed by BGP?   If so, feedback
> should be given on all BGP-LS drafts and the spring architecture.
>
>
>
> Tony Li and Robert Raszuks, have commented that this extension to BGP-LS
> goes beyond the bounds of good network technology. As I have described, the
> expansion of the information flow is grown in 2 direction: more data (SR
> extensions, SR-TE extensions, BGP-EPE extensions, etc.. ) and more peers
> (bgp-prefix-sid) beyond just the BGP-LS capable BGP peers.
>
>
>
> The IDR and SPRING WG have been working on these technologies for 3 years
> so hopefully, the IESG has an opinion about the extension of BGP-LS in
> these two fashions to serve these features.  I would be glad to provide a
> BGP discussion with the IESG along with my IDR co-chair and with the chairs
> of the SPRING WG.
>
>
>
> =================
>
> Key drafts for BGP-LS passing Service besides draft-ietf-bgp-prefix-sid
>
>
>
> Please note that the key drafts for the BGP portion of segment routing
> are:
>
> 1.  draft-ietf-idr-bgpls-segment-routing-ext-08 – changes to BGP
> attribute for BGP-LS and BGP-LS NLRI to support segment routing,
>
>
>
> status: This draft has passed WG LC, see shepherd’s report for latest
> revisions needed. The draft is generally readable, so please read the draft
> before deciding on bgp-prefix-sid.  Please remember that the TLVs being
> proposed are for both the NLRI and the attribute.
>
>
>
> Spring WG link: draft-ietf-spring-segment-routing – getting IGP
> information.
>
>
>
> Shepherd’s concern:  1) Error handling and manageability with other BGP
> technology (Yang models), 2) security concerns, 3)
>
>
>
>
>
>
>
> 2.  draft-ietf-idr-bgpls-segment-routing-epe-15
>
>
>
> Status: Passed WG LC, and provides the mechanisms needed SR’s BGP Peer
> Egress Peer Engineering (BGP-EPE).  Please see my shepherd’s report on this
> draft.
>
>
>
> Shepherd’s concerns: 1) error handling/manageability, 2) security
> concerns, 3) adaption of this technology beyond E-BGP to IBGP is
> underspecified (see long-term looping issues with IBGP RR), 3) security
>
>
>
> Editorial comment: This draft needs a lot of editorial work so reading
> this draft may be difficult. Authors are active in upgrading the draft.
>
>
>
> 3.   draft-ietf-idr-te-pm-bgp-10 –
>
>
>
> Status: WG-LC light response,  1 Week final call (6/20 to 6/27)
>
> Shepherd’s comments: Technology links nicely to the traffic  Engineering
> for BGP-LS in general.  SR can utilize this information. Chairs have
> discussed forwarding this traffic.
>
>
>
> 4.  Draft-ietf-idr-bgp-ls-node-admin-tag-extension
>
>
>
> Status: PAST WG LC
>
> Shepherd’s comments: Needs additions for 1) Error handling comment, 2)
> Manageability, 3) small addition to security security.
>
>
>
> 5.  draft-ietf-idr-segment-routing-te-policy-03.txt
>
>
>
> Status: WG Draft
>
> Spring WG link: draft-ietf-spring-segment-routing-policy-01
>
>
>
> Shepherd’s comments:  Policy inclusion for SR is recommended by
>
> Spring.  BGP SR TE policy sub-TLVS fit SPRING’s requirement
>
>       If IDR, SPRING And IESG Agree it should be added.
>
>       Should any of
>
>
>
> 6.  draft-ietf-idr-bgp-ls-segment-routing-rld:
>
>
>
> Status: WG draft
>
>
>
> Spring-link: MPLS Entropy label exposing from IGPs (ISIS and OSPF) the
> information on RLD (readable label depth) and ELC (entropy label
> capability) of a node.  This addition supports a centralized controller
> application of spring (draft-ietf-spring-segment-routing-central-epe-10.txt).
>
>
>
>
> Shepherd’s comment: TLVs are for BGP attribute for BGP-LS and
>
> BGP-LS NLRI to be shared amount BGP-LS peers.
>
>
>
> Shepherd’s concerns: error handling (conflicting TLVS in BGP attribute,
> conflicting TLVs in BGP-LS attribute
>
>
>
> 7.  draft-ietf-idr-bgp-ls-segment-routing-msd
>
> Status: WG Draft
>
>
>
> IGP-link: Capturing IGP (ISIS, OSPF) the Maximum SID Depth supported by a
> node (draft-ietf-isis-segment-routing-msd, draft-ietf-ospf-segment-routing-msd).
>
>
> PCE –link: draft-ietf-pce-segment-routing.
>
>
>
> Shepherd’s comment: TLVs are for BGP attribute for BGP-LS and
>
> BGP-LS NLRI to be shared amount BGP-LS peers.
>
> Shepherd’s concerns: error handling (conflicting TLVS in BGP attribute,
> conflicting TLVs in BGP-LS attribute.
>
>
>
>
>
>
>
> C) Upcoming IPv6 work
>
>
>
> The upcoming SRv6 work is being proposed in: draft-dawra-idr-bgpls-srv6-ext-03,
> draft-dawra-idr-srv6-vpn-03, draft-kentant-idr-bgp-ls-bgp-only-fabric-03.
>
>
>
>
> Additional extensions for the BGP-LS for Inter-AS topology,  routing, or
> service chaining include: Draft-chunduri-idr-bgp-ls-nspfid,
> draft-li-idr-bgp-ls-sr-policy-path-segment, draft-li-idr-sr-policy-path-segment-distribution,
> and others.
>
>
>
>
>
> *From:* Warren Kumari [mailto:[e-mail]]
> *Sent:* Wednesday, June 20, 2018 3:08 PM
> *To:* Robert Raszuk
> *Cc:* acee=[e-mail]; 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 COMMENT)
>
>
>
>
>
>
>
> On Tue, Jun 19, 2018 at 11:01 AM Robert Raszuk <[e-mail]> wrote:
>
> Hi Acee,
>
>
>
> Just making the attribute non transitive to prevent accidental leaking
> worldwide would easliy address this valid concern for the cost of upgrading
> RRs (if applicable) in any given domain which is to use it.
>
>
>
> ​That sounds like a fine idea -- was this discussed and rejected? Is
> there any reason that this cannot be non-transitive?
>
>
>
> W
>
>
>
>
>
> Leaking it with IPv6 routes globally - either by accident or not so
> perfect operational practices of the sourcing AS  seems like an a little
> architecture bug since such info would be of no use externally to
> original administrative domain.
>
>
>
> Best,
>
> R.
>
>
>
>
>
> On Tue, Jun 19, 2018 at 4:33 PM, Acee Lindem (acee) <
> acee=[e-mail]> wrote:
>
> Hi Warren,
>
> > On Jun 18, 2018, at 8:30 PM, Warren Kumari <[e-mail]> wrote:
> >
> > Warren Kumari has entered the following ballot position for
> > draft-ietf-idr-bgp-prefix-sid-25: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I'm balloting NoObjection, but I'm sad that nothing came of my previous
> request:
> >
> > "Major(ish) issue:
> > Section 5.  Advertising BGP Prefix-SID Attribute
> >  "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes
> >  (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760].  In
> >  order to prevent distribution of the BGP Prefix-SID attribute beyond
> >  its intended scope of applicability, attribute filtering SHOULD be
> >  deployed."
> > Thank you for including this -- however, as I'm sure you know, the state
> of BGP
> > filtering in the wild is, er, poor. Can you please provide some
> additional
> > guidance? For example, could you include an appendix with examples?
>
> No. As I told you before this is a can of worms that I’m not going to open
> in this draft (and particularly not during IESG review). As I also told you
> before the state of BGP filtering is something that you should propose as a
> work item for your OPS homies in the GROW WG.
>
>
> > Or simply a
> > bit more text on determining the scope of applicability? Apologies if I
> missed
> > this, but should this by default be filtered on eBGP sessions? The
> included
> > text is a great start, but some more (so people don't miss it and shoot
> > themselves in the foot would be much appreciated. “
>
> I will add “, e.g., at SR domain boundaries,’  to the statement.
>
> Thanks,
> Acee
>
>
>
>
> >
> >
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
>
>
>
> --
>
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf
>