Re: [Idr] BGP-LS and the like ...

[Robert Raszuk <[e-mail]>]

Hi Ketan,

> and I am unable to follow the relation between the BGP SR Prefix SID and
BGP-LS SR extensions

Indeed.

Further let's observe that Prefix SID TLV defined in 3.1 is actually needed
by all ingress nodes to a domain so it does fit p2mp distribution model and
therefor I see no issue at all to propagate it with BGP.

On the other hand I can not say the same about SRGB TLV propagation as
defined in section 3.2 :(.

Thx,
R.


On Fri, Jun 22, 2018 at 1:48 PM, Ketan Talaulikar (ketant) <[e-mail]
> wrote:

> Hi Sue,
>
>
>
> My response was to Robert’s observations and points related to BGP-LS. We
> are discussing/debating whether and how much opacity we want to have
> between what BGP carries via BGP-LS and what sort of semantic (or content)
> checking should be done by BGP for what is carried in LS TLVs. This clearly
> needs to continue and open to feedback here.
>
>
>
> What I do not follow is why “SR extensions to BGP” are being clubbed
> together and I am unable to follow the relation between the BGP SR Prefix
> SID and BGP-LS SR extensions. Really the only relation and redundant
> information being carried is that SRGB is signalled in both. The BGP SR
> Prefix SID draft clearly states that signalling SRGB of a node is preferred
> via BGP-LS SR extensions.
>
>
>
> It is really only BGP SR Prefix SID which extends existing BGP-LU routing
> with SR information and is related to and affects BGP route installation
> and download. IMHO the authors of that draft have address all comments and
> inputs related to semantic checks, malformed TLV handling and other
> considerations.
>
>
>
> None of the BGP-LS SR extensions impact base BGP routing. What they
> provide is topology information (including SR info and SIDs associated with
> it) to a (say) controller that can use them independently for applications
> like Traffic Engineering and installing SR Policies for traffic steering.
> This is within an administrative SR domain and does not affect or change
> BGP routing.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Susan Hares <[e-mail]>
> *Sent:* 22 June 2018 16:57
> *To:* Ketan Talaulikar (ketant) <[e-mail]>; 'Robert Raszuk' <
> [e-mail]>
> *Cc:* 'idr@ietf. org' <[e-mail]>
>
> *Subject:* RE: [Idr] BGP-LS and the like ...
>
>
>
> Ketan:
>
>
>
> Thank you for your comments.   See mine below.
>
>
>
> Sue
>
>
>
>
>
> *From:* Ketan Talaulikar (ketant) [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Thursday, June 21, 2018 7:44 AM
> *To:* Robert Raszuk; Susan Hares
> *Cc:* idr@ietf. org
> *Subject:* RE: [Idr] BGP-LS and the like ...
>
>
>
> Hi Robert,
>
>
>
> Thanks for bringing up this topic and more importantly putting it in
> (IMHO) “right” context.
>
>
>
> Please check inline below
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of *Robert Raszuk
> *Sent:* 21 June 2018 12:00
> *To:* Susan Hares <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>
> *Subject:* [Idr] BGP-LS and the like ...
>
>
>
> Hi Sue & WG,
>
>
>
> Adjusting subject line to reflect content.
>
>
>
> Excellent writeup on BGP-LS ! The only thing which I could perhaps add is
> that while maintaining previous opinion on BGP-LS in general the most what
> bothers me with this is the granularity of BGP machinery awarness of
> "stuff" it is subject to carry.
>
> *[KT] Agree – it would bother me too if every BGP speaker had to do this.
> It would also bother if we could not introduce a new BGP-LS attribute TLV
> with code changes on just the originator and the receiver BGP-LS nodes –
> just because say the transit BGP speakers (e.g. RRs) do not understand it.*
>
>
>
> [Sue]:  How do we assure that every BGP speaker does not have to deal with
> it?
>
> Draft-ietf-bgp-prefix-sid is traveling to BGP peers which do not speak
> BGP-LS.
>
>
>
> If we continue for every new IGP extension or SR policy extension see a
> corresponding BGP draft in order to carry it in BGP where do we end up in
> few months or years from now ?
>
> *[KT] This is actually ongoing right now and required for the use-cases
> where BGP-LS provides the topology information “northbound” to a
> controller.*
>
>
>
> [Sue]:  The fact it is ongoing in specification does not abrogate the need
> to stop at this point and ask “Is this a good idea?”.    We need to have
> some agreed upon idea on where this is going.
>
>
>
> It is bad for BGP (p2mp) to carry IGP state (p2p), but it is even worse to
> make it to recognize what it carries.
>
> *[KT] This is very important and that is why RFC 7752 proposes the
> framework for fault management which should be applicable to BGP-LS in
> general. It is all about verifying the TLVs without necessary having to do
> a check on the content. It is possible for a BGP speaker to opaquely handle
> these BGP-LS messages without semantic interpretation of the contents.*
>
>
>
> [Sue]:  The RFC7752 fault management is a list of questions that form a
> filter.  I have indicated in my reviews of your draft where the “content”
> requirements (PEER-NODE-SID) requirements do not fit.
>
>
>
>
>
> Perhaps using BGP as a pure LSDB transport and carry big black container
> with "some other stuff inside" would be ok for some .. at least during the
> transition to much more proper transport. Not advocating it - just
> recognizing reality observing the flight already inroute.
>
>
>
>
>
> *[KT] Perhaps a packed set of black boxes in the NLRI descriptors and
> attributes – so as to ensure transport integrity for BGP. However, the
> semantic verification or understanding of the individual TLVs may be left
> to the nodes (rather applications) that originate & consume this
> information. Today, most use-cases involve the use of BGP-LS to propagate
> information within an administrative domain (one or more AS) and being a
> separate AFI/SAFI provides the control to limit its scope as such. At the
> point where BGP speakers in transit do require to perform policy or
> filtering operations on these TLVs then they would need to be aware of the
> same and when there are such considerations, then they should be called out
> by specific documents.*
>
>
>
> [Sue]:  I am assuming your sematic verification is my “content” error
> handling.
>
>
>
> If you are going have the sematic verification that compares and
> understands TLVS unique to the individual nodes, why do you need a
> standard?   However, I assume that you mean BGP Peers that process the
> BGP-LS attribute and the BGP-LS NLRI.  If this is true, then clearly
> specify this in your specifications.  Clearly indicate what happens a
> transit BGP Speaker processes these opaque packets.
>
>
>
> I also noticed below in your BGP-LS writeup you bring up
> draft-ietf-idr-segment-routing-te-policy-03.txt. But how is this related
> to BGP-LS at all ? It defines its own new SAFI and do not even carry any
> link state information ...
>
> *[KT] It is not.*
>
>
>
> *[Sue] It is not linked to BGP-LS, but to segment routing additions to
> BGP. Please note that the original topic was not BGP-LS, but segment
> routing additions to BGP.  *
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> I am starting to have a feeling that this non core routing information
> transport over BGP is simply getting out of hand :) And of course many will
> correctly say that this started with introduction of multiprotocol
> extensions to BGP followed by original 2547 - but it seems that this trend
> is growing exponentially now.
>
>
>
> Cheers,
> Robert.
>
>
>
>
>
> 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 <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
>
>
>