Subject: [Idr] SRGB TLV

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 Jun 2018 20:02:50 +0200

Hello Acee,

In order to keep focused on the subject of the thread adjusting it ... The
previous one was indicating much bigger issue and it would be pretty bad to
narrow it down to one TLV topic.

I only mentioned it there as an example, but since you are asking to keep
silent on that specific proposed extension just because "design was already
done" let me bring few points on that.

Yes each router can have different SRGB blocks for any MPLS application. In
most implementations those blocks can be configured by operator.

So this TLV is to reside in the new attribute which can be placed into
BGP_UPDATE message of SAFI 4. This means that just for signalling three
statically configured values each router now has to enable new SAFI (SAFI 4
is not that commonly used in any MPLS domain) then send it to RRs then RRs
will blast those UPDATES to everybody in the domain for zero reason.

And the only interested consumer of this info is the controller which can
get such data from NMS, YANG, XML etc .... in the first place.

Best,
R.

On Fri, Jun 22, 2018 at 5:11 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
>
>
> *From: *Idr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Friday, June 22, 2018 at 8:09 AM
> *To: *"Ketan Talaulikar (ketant)" <[email-masked]>
> *Cc: *IDR List <[email-masked]>, Susan Hares <[email-masked]>
> *Subject: *Re: [Idr] BGP-LS and the like ...
>
>
>
> 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 :(.
>
>
>
> I wasn’t in favor including this either but, for SR domains with
> heterogeneous SRGBs, it needed to be advertised some place and this was the
> consensus. It is unproductive to rehash this design point.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> Thx,
> R.
>
>
>
>
>
> On Fri, Jun 22, 2018 at 1:48 PM, Ketan Talaulikar (ketant) <
> [email-masked]> 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 <[email-masked]>
> *Sent:* 22 June 2018 16:57
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; 'Robert Raszuk' <
> [email-masked]>
> *Cc:* 'idr@ietf. org' <[email-masked]>
>
>
> *Subject:* RE: [Idr] BGP-LS and the like ...
>
>
>
> Ketan:
>
>
>
> Thank you for your comments.   See mine below.
>
>
>
> Sue
>
>
>
>
>
> *From:* Ketan Talaulikar (ketant) [mailto:[email-masked]
> <[email-masked]>]
> *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 <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* 21 June 2018 12:00
> *To:* Susan Hares <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>
> *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 <[email-masked]> 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:[email-masked]]
> *Sent:* Wednesday, June 20, 2018 3:08 PM
> *To:* Robert Raszuk
> *Cc:* acee=[email-masked]; idr@ietf. org; [email-masked];
> [email-masked]; 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 <[email-masked]> 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=[email-masked]> wrote:
>
> Hi Warren,
>
> > On Jun 18, 2018, at 8:30 PM, Warren Kumari <[email-masked]> 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
> [email-masked]
> 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
>
>
>
>
>

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 25 Jun 2018 14:39:06 -0400

On 6/22/2018 2:02 PM, Robert Raszuk wrote:
> BGP_UPDATE message of SAFI 4. This means that just for signalling 
> three statically configured values each router now has to enable new 
> SAFI (SAFI 4 is not that commonly used in any MPLS domain) then send 
> it to RRs then RRs will blast those UPDATES to everybody in the domain 
> for zero reason.
>
> And the only interested consumer of this info is the controller which 
> can get such data from NMS, YANG, XML etc .... in the first place.

I don't think that's the intended use case.

The intended use case is a scenario where:

- SAFI-4 is being used anyway, and

- multiple ingress nodes need to be able construct to construct 
traffic-engineered MPLS/SR label stacks that will get a packet, destined 
to a particular prefix, to the proper egress node, and

- when the packet arrives at the egress node, that egress node's label 
for the prefix should appear at the top of the stack.

Assuming that the ingress nodes know the SID for the prefix (via the 
prefix-SID attribute), they also need to know the SRGB of the egress 
node in order to determine the egress node's label for the prefix.

While this may or may not be a useful use case (so to speak), no one has 
ever suggested to enable SAFI-4 as a way of having  a node signal its 
SRGB to a controller.