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

[Robert Raszuk <[e-mail]>]

Acee,

RFC8277 has nothing to do with this entire discussion.

Yes you would need to upgrade RRs which is not that bad ;)

But as already stated since you are *only* putting this new attribute in
SAFI 4 there is no "leaking issue" any more and that should be your chosen
line of defence ;)

Best,
R.

On Thu, Jun 21, 2018, 15:19 Acee Lindem (acee) <[e-mail]> wrote:

> All,
>
>
>
> Actually, the input I’ve gotten is not to change this to a non-transitive
> attribute since this would essentially revert to RFC 8277 if any BGP router
> not supporting the attribute is in the path. With the transitive attribute,
> a single BGP router only represents a break in the SR path where local
> labels are used.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *"Acee Lindem (acee)" <acee=[e-mail]>
> *Date: *Wednesday, June 20, 2018 at 8:17 PM
> *To: *Susan Hares <[e-mail]>, Warren Kumari <[e-mail]>,
> Robert Raszuk <[e-mail]>
> *Cc: *Acee Lindem <[e-mail]>, IDR List <[e-mail]>, "
> [e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>, The IESG <[e-mail]>
> *Subject: *Re: [Idr] Warren Kumari's No Objection on
> draft-ietf-idr-bgp-prefix-sid-25: (with COMM
>
>
>
> Hi Sue,
>
> I think you are confusing this draft with
> draft-ietf-idr-bgpls-segment-routing-epe.  This draft is not an extension
> of BGP-LS. I have no problems with making this a non-transitive attribute
> since this only impacts attributes that are not recognized by the receiver.
> What I do have a problem with are further delays when and reiterations as
> my opinion is that it never should have gone through the whole last-call
> and directorate review cycle again in the first place. There are multiple
> implementations of the draft and it has been in around for almost 4 years –
> everyone has had ample opportunity for review.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Susan Hares <[e-mail]>
> *Date: *Wednesday, June 20, 2018 at 8:03 PM
> *To: *Warren Kumari <[e-mail]>, Robert Raszuk <[e-mail]>
> *Cc: *"acee=[e-mail]" <acee=[e-mail]>,
> IDR List <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>, The IESG <[e-mail]>
> *Subject: *RE: [Idr] Warren Kumari's No Objection on
> draft-ietf-idr-bgp-prefix-sid-25: (with COMM
> *Resent-From: *<[e-mail]>
> *Resent-To: *Stefano Previdi <[e-mail]>, <[e-mail]>, Acee
> Lindem <[e-mail]>, Arjun Sreekantiah <[e-mail]>, <
> [e-mail]>
> *Resent-Date: *Wednesday, June 20, 2018 at 8:03 PM
>
>
>
> 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
>