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

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 Jun 2018 08:29:44 +0200

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.

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 ?

It is bad for BGP (p2mp) to carry IGP state (p2p), but it is even worse to
make it to recognize what it carries.

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.

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

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
> > 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: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 21 Jun 2018 11:43:30 +0000

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,

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.

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.

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.

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.

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.

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]<mailto:[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.

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,

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).

======================

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.

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.

=================

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)

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.

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.

Status: PAST WG LC
Shepherd’s comments: Needs additions for 1) Error handling comment, 2) Manageability, 3) small addition to security security.

Status: WG Draft

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 concerns: error handling (conflicting TLVS in BGP attribute, conflicting TLVs in BGP-LS attribute

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]<mailto:[email-masked]>]
Sent: Wednesday, June 20, 2018 3:08 PM
To: Robert Raszuk
Cc: acee=[email-masked]<mailto:[email-masked]>; idr@ietf. org; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[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]<mailto:[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]<mailto:acee=[email-masked]>> wrote:
Hi Warren,

> On Jun 18, 2018, at 8:30 PM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<https://www..ietf.org/iesg/statement/discuss-criteria.html>
> I'm balloting NoObjection, but I'm sad that nothing came of my previous request:
>
> "Major(ish) issue:
> 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

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

Thanks,
Acee

_______________________________________________
Idr mailing list
[email-masked]<mailto:[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: Randy Bush <[email-masked]>
Date: Thu, 21 Jun 2018 10:22:27 -0700

> while maintaining previous opinion on BGP-LS in general the most what
> 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 ?

no proof of termination and unbounded feature chase.  welcome to the
ietf, where this is a career extending feature.

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

i always thought all that stuff should have used dns instead

randy, who gave up whining about this long ago

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 22 Jun 2018 07:27:28 -0400

Ketan: 

Thank you for your comments.   See mine below. 

Sue 

From: Ketan Talaulikar (ketant) [mailto:[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,

Hi Sue & WG,

[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. 

[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. 

[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. 

 

[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.  

[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

Cheers,
Robert.

Warren, Robert, Acee:

Susan Hares 

Shepherd

IDR co-chair

=======================

Problem 1: 

·         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). 

Problem 2: 

      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

      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.

======================

-------------

A) Big picture Issues

=================

 

Status: PAST WG LC 

Status: WG Draft 

      Should any of 

Status: WG draft 

Status: WG Draft

      

C) Upcoming IPv6 work 

 

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)

Hi Acee,

W

Best,

R.

On Tue, Jun 19, 2018 at 4:33 PM, Acee Lindem (acee) <acee=[email-masked]> wrote:

Hi Warren, 

> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www..ietf.org/iesg/statement/discuss-criteria.html> 

Thanks,
Acee

 

--

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 Jun 2018 11:48:11 +0000

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:

Sue

Hi Robert,

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: 21 June 2018 12:00
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] BGP-LS and the like ...

Hi Sue & WG,

Thanks,
Ketan

Cheers,
Robert.

Susan Hares
Shepherd
IDR co-chair

Problem 1:

Problem 2:

======================

=================

Status: PAST WG LC

Status: WG Draft

Status: WG draft

C) Upcoming IPv6 work

W

Best,
R.

Thanks,
Acee

---

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

Hi Sue,

*> Please note that the original topic was not BGP-LS, but segment routing
additions to BGP.  *

Since I started this thread allow me to clarify what was the original
topic. It is not about SR additions to BGP at all.

BGP-LS as example in its RFC7752 does not talk a word about segment routing
... it was mentioned that it is helpful for ALTO or PCE.

*My point is much broader of using BGP TCP sessions to disseminate point to
point information just because it is there. *

The assumption BGP-LS promised that new infrastructure (say separate RRs)
are going to be used and will not co-exist with other routing BGP SAFIs is
not enforceable and as we have seen already in some other threads does not
work in operational practice causing for example resets of the entire
sessions.

Also I want to clarify that when I mentioned that the MP-BGP extensions did
provided that skeleton for encoding various types of information in BGP at
least the original ones including 2547 were originated by one and needed
for reachability by many - so they did fit to p2mp paradigm. It just quite
recent where BGP extensions proposed are to carry various opaque
information which are needed between two endpoints only.

Regards,
Robert.

On Fri, Jun 22, 2018 at 1:27 PM, Susan Hares <[email-masked]> wrote:

> *From:* Ketan Talaulikar (ketant) [mailto:[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,
>
>
>
> *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,
>
>
>
> *[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.*
>
>
>
> *[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.
>
>
>
> *[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.
>
>
>
>
>
> *[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.*
>
>
>
> 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.
>
>
>
> 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*
>
>
>
> Warren has a valid question..  I cannot find a long mail thread on
> routing (Robert Raszuk, Tony Li).. Therefore I suspect that restricting
> html <https://www..ietf.org/iesg/statement/discuss-criteria.html>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 Jun 2018 14:08:16 +0200

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) <[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]>
>
> *From:* Ketan Talaulikar (ketant) [mailto:[email-masked]
> <[email-masked]>]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 22 Jun 2018 15:11:18 +0000

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]<mailto:[email-masked]>> wrote:
Hi Sue,

Thanks,
Ketan

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Sent: 22 June 2018 16:57
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>
Cc: 'idr@ietf. org' <[email-masked]<mailto:[email-masked]>>

Ketan:

Sue

Hi Robert,

Hi Sue & WG,

Thanks,
Ketan

Cheers,
Robert.

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?

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.

Susan Hares
Shepherd
IDR co-chair

Problem 1:

Problem 2:

======================

=================

Status: PAST WG LC

Status: WG Draft

Status: WG draft

C) Upcoming IPv6 work

W

Best,
R.

Thanks,
Acee

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 25 Jun 2018 11:17:44 -0400

Ketan:

Thank you for your response.  I appreciate your active work on to resolve these issues.  I would like to resolve these issue quickly. 

Sue Hares  

From: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Friday, June 22, 2018 7:48 AM
To: Susan Hares; 'Robert Raszuk'
Cc: 'idr@ietf. org'
Subject: RE: [Idr] BGP-LS and the like ...

Hi Sue,

[Sue]: Thank you for the discussion. 

[Sue:] Yes – you are 50% of the way to the solution.  If you ignore the less preferred solution, simply state this fact.  Simply state this fact in both drafts and you have resolved my concern over this error condition. 

[Sue]:  the simple addition above will resolve the concern I have over “problem 1” I mentioned. 

[Sue]: 

1st - If you provide a “hint”, then we get into a recursive problem of the hint accelerating the solution the controller provides.  See the earliest ARPANET where the hints of performance causes the solution to grow dramatically without bounds in an algorithm.   If it is suggesting how many local labels it is allocating, it is suggesting something that may impact. 

2nd - If you use a transitive BGP Prefix SID Attribute, then you are not within a single AS.   You cannot use the AS boundary to guarantee the administrative SR domain.   If the configured SR Domain ID is someplace (configuration, etc), then how do we check it to determine SR domain boundares. 

By the way, I would prefer to solve this solution as I can see where transitive BGP Prefix SID is useful in a data center environment.  Therefore, I am not looking to remove this work – but to find a way to codify what safe guards you are placing on the algorithm and boundary of the SR domain.  

So – make a suggestion for text in the BGP error handling or the manageability section that provides the same guidelines you are using for the code.  

Thank you for thinking through these error handling routines. 

Thanks,

Ketan

Ketan: 

Sue 

Hi Robert,

Hi Sue & WG,

 

 

[KT] It is not.

Thanks,

Ketan

Cheers,
Robert.

Warren, Robert, Acee:

Susan Hares 

Shepherd

IDR co-chair

=======================

Problem 1: 

Problem 2: 

======================

-------------

A) Big picture Issues

=================

 

Status: PAST WG LC 

Status: WG Draft 

      Should any of 

Status: WG draft 

Status: WG Draft

      

C) Upcoming IPv6 work 

 

 

Hi Acee,

W

Best,

R.

Hi Warren, 

Thanks,
Acee

 

--

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 25 Jun 2018 13:10:53 -0400

Robert:

This is a valuable topic.  We will split this discussion to allow both to continue.   I’m going to start a thread and discussion with the authors to discuss error handling (problem 1 in my longish email.). 

Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, June 22, 2018 7:51 AM
To: Susan Hares
Cc: idr@ietf. org
Subject: Re: [Idr] BGP-LS and the like ...

Hi Sue,

> Please note that the original topic was not BGP-LS, but segment routing additions to BGP.   

Since I started this thread allow me to clarify what was the original topic. It is not about SR additions to BGP at all. 

BGP-LS as example in its RFC7752 does not talk a word about segment routing ... it was mentioned that it is helpful for ALTO or PCE. 

My point is much broader of using BGP TCP sessions to disseminate point to point information just because it is there. 

The assumption BGP-LS promised that new infrastructure (say separate RRs) are going to be used and will not co-exist with other routing BGP SAFIs is not enforceable and as we have seen already in some other threads does not work in operational practice causing for example resets of the entire sessions. 

Also I want to clarify that when I mentioned that the MP-BGP extensions did provided that skeleton for encoding various types of information in BGP at least the original ones including 2547 were originated by one and needed for reachability by many - so they did fit to p2mp paradigm. It just quite recent where BGP extensions proposed are to carry various opaque information which are needed between two endpoints only.

Regards,

Robert.

 

Ketan: 

Sue 

Hi Robert,

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,

 

 

[KT] It is not.

Thanks,

Ketan

Cheers,
Robert.

Warren, Robert, Acee:

Susan Hares 

Shepherd

IDR co-chair

=======================

Problem 1: 

Problem 2: 

======================

-------------

A) Big picture Issues

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

=================

 

Status: PAST WG LC 

Status: WG Draft 

      Should any of 

Status: WG draft 

Status: WG Draft

      

C) Upcoming IPv6 work 

 

 

Hi Acee,

W

Best,

R.

On Tue, Jun 19, 2018 at 4:33 PM, Acee Lindem (acee) <acee=[email-masked]..org <mailto:acee=[email-masked]> > wrote:

Hi Warren, 

Thanks,
Acee

 

--

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 25 Jun 2018 13:15:18 -0400

Acee:

Where was that consensus reached?   If it is idr WG, then please point the email thread out to me.   I will review the discussions and summarize on list.    

If it was SPRING or LSR, then please send the link.   

Susan Hares

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Friday, June 22, 2018 11:11 AM
To: Robert Raszuk; Ketan Talaulikar (ketant)
Cc: idr@ietf. org; Susan Hares
Subject: Re: [Idr] BGP-LS and the like ...

Hi Robert, 

Hi Ketan,

Indeed. 

Thanks,
Acee 

Thx,
R.

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

Hi Sue,

Thanks,

Ketan

Ketan: 

Sue 

From: Ketan Talaulikar (ketant) [ <mailto:[email-masked]> mailto:[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,

Hi Sue & WG,

 

 

[KT] It is not.

Thanks,

Ketan

Cheers,
Robert.

Warren, Robert, Acee:

Susan Hares 

Shepherd

IDR co-chair

=======================

Problem 1: 

Problem 2: 

      through [ <https://tools.ietf.org/html/rfc7752> RFC7752], [ <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-25#ref-I-D.ietf-idr-bgpls-segment-routing-epe> I-D.ietf-idr-bgpls-segment-routing-epe], and

      [ <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-25#ref-I-D.ietf-idr-bgp-ls-segment-routing-ext> I-D.ietf-idr-bgp-ls-segment-routing-ext].  However, as an

      SID attribute is specified in  <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-25#section-3.2> Section 3.2 of this document.

======================

-------------

A) Big picture Issues

=================

 

Status: PAST WG LC 

Status: WG Draft 

      Should any of 

Status: WG draft 

Status: WG Draft

      

C) Upcoming IPv6 work 

 

From: Warren Kumari [mailto: <mailto:[email-masked]> [email-masked]] 
Sent: Wednesday, June 20, 2018 3:08 PM
To: Robert Raszuk
Cc: acee= <mailto:[email-masked]> [email-masked]; idr@ietf. org;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; The IESG
Subject: Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMMENT)

Hi Acee,

W

Best,

R.

Hi Warren, 

Thanks,
Acee

 

--

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 25 Jun 2018 17:41:20 +0000

Sue,

As I told Robert offline, I was only mildly against this when we discussed it among the authors. There are many trade-offs as far as advertising SRGB and this Prefix-SID attribute SRGB TLV is implemented and deployed today.

The important point is that the IPv6 SID TLV which no one implemented was removed prior to publication – even if this did require going through the whole process again.

Thanks,
Acee

From: Susan Hares <[email-masked]>
Date: Monday, June 25, 2018 at 1:15 PM
To: Acee Lindem <[email-masked]>, Robert Raszuk <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>
Cc: IDR List <[email-masked]>
Subject: RE: [Idr] BGP-LS and the like ...

Acee:

Susan Hares

Hi Robert,

Hi Ketan,

Indeed.

Thanks,
Acee

Thx,
R.

Thanks,
Ketan

Ketan:

Sue

Hi Robert,

Hi Sue & WG,

Thanks,
Ketan

Cheers,
Robert.

Susan Hares
Shepherd
IDR co-chair

Problem 1:

Problem 2:

======================

=================

Status: PAST WG LC

Status: WG Draft

Status: WG draft

C) Upcoming IPv6 work

W

Best,
R.

Thanks,
Acee

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 25 Jun 2018 14:01:36 -0400

Acee:

If  “SRGB and the Prefix-SID attribute SRGB TLV” precedence handling and error handling  can documented, then it resolves my concerns.  Did you author group have any notes on precedence that we can utilize?  

I agree with you on the removal of the IPv6 SID TLV after reading Ketan’s proposal.   It did not pass IDR’s requirement for implemented specifications. 

Susan Haresa 

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Monday, June 25, 2018 1:41 PM
To: Susan Hares; 'Robert Raszuk'; Ketan Talaulikar (ketant)
Cc: 'idr@ietf. org'
Subject: Re: [Idr] BGP-LS and the like ...

Sue, 

Thanks,
Acee 

Acee:

Susan Hares

Hi Robert, 

Hi Ketan,

Indeed. 

Thanks,
Acee 

Thx,
R.

Hi Sue,

Thanks,

Ketan

Ketan: 

Sue 

Hi Robert,

Hi Sue & WG,

 

 

[KT] It is not.

Thanks,

Ketan

Cheers,
Robert.

Warren, Robert, Acee:

Susan Hares 

Shepherd

IDR co-chair

=======================

Problem 1: 

Problem 2: 

======================

-------------

A) Big picture Issues

=================

 

Status: PAST WG LC 

Status: WG Draft 

      Should any of 

Status: WG draft 

Status: WG Draft

      

C) Upcoming IPv6 work 

 

 

Hi Acee,

W

Best,

R.

Hi Warren, 

Thanks,
Acee

 

--

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 25 Jun 2018 18:22:49 +0000

Hi Sue,

I believe the error handling is clearly documented. What do you mean by precedence?

Thanks,
Acee

Date: Monday, June 25, 2018 at 2:02 PM

Acee:

Susan Haresa

Sue,

Thanks,
Acee

Acee:

Susan Hares

Hi Robert,

Hi Ketan,

Indeed.

Thanks,
Acee

Thx,
R.

Thanks,
Ketan

Ketan:

Sue

Hi Robert,

Hi Sue & WG,

Thanks,
Ketan

Cheers,
Robert.

Susan Hares
Shepherd
IDR co-chair

Problem 1:

Problem 2:

======================

=================

Status: PAST WG LC

Status: WG Draft

Status: WG draft

C) Upcoming IPv6 work

W

Best,
R.

Thanks,
Acee

---

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

On 6/25/2018 11:17 AM, Susan Hares wrote:
>
> [Sue]:
>
> 1^st - If you provide a “hint”, then we get into a recursive problem 
> of the hint accelerating the solution the controller provides.  See 
> the earliest ARPANET where the hints of performance causes the 
> solution to grow dramatically without bounds in an algorithm.   If it 
> is suggesting how many local labels it is allocating, it is suggesting 
> something that may impact.
>

I don't understand this objection.    Typically, when a node receives a 
SAFI-4 update, and has to propagate that update on an EBGP session, it 
changes the label value and the next hop value before propagation.  The 
"hint" tells you what to change the label value to.  Without the hint, 
you make a local choice of what to change the label value to.  There is 
nothing here that is "growing without bounds" or causing a "recursive" 
problem.

Also, I don't understand what ARPANET phenomenon is being referenced ;-)

> 2^nd - If you use a transitive BGP Prefix SID Attribute, then you are 
> not within a single AS. You cannot use the AS boundary to guarantee 
> the administrative SR domain.   If the configured SR Domain ID is 
> someplace (configuration, etc), then how do we check it to determine 
> SR domain boundares.
>

The problem here is that the notion of "AS boundary" as "administrative 
boundary" has long been obsolete.  The attribute under discussion is 
just one of a whole set of attributes that could benefit from a general 
"attribute scoping" solution, assuming someone could figure out a 
solution that is general enough to make sense and not too costly to 
deploy.  You can't expect this particular draft to address that problem.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 26 Jun 2018 09:54:21 -0400

Eric: 

On your questions for #1,  The ARPANET’s original algorithm 

Used a “link metric, which was an instantaneous sample rather than an average, was a poor indicator of expected delay on a link as the quantity being sampled fluctuated fairly rapidly at all traffic levels.”  This is a quote from the reference academic paper link below (circa 1989).  

http://www2.cs.arizona.edu/classes/cs525/fall14/papers/ak89.pdf

I can send you links additional modern papers on the predictive algorithms that still consider this problem if  you wish.  

This early ARPANET lesson causes us to learn that feedback loops (even hints) that readjust the algorithms can cause fluctuations.  Does this apply to all algorithms?  No,  but this common wisdom is one of the reason the BGP error handling calls out the following  text in section 2. 

   o  Attribute discard: In this approach, the malformed attribute MUST

      be discarded and the UPDATE message continues to be processed.

      This approach MUST NOT be used except in the case of an attribute

      that has no effect on route selection or installation.

Other reasons can be algorithms specific to BGP (see RFC 7964, RFC3345].   If you suggest something that borders on this point, the burden of proof is on the inventors of the protocol and algorithm to show it is not going to cause problems. 

If you suggest that hints to the buffer algorithm do not cause fluctuations, then provide the discussion on the list that provides this proof.   There are two cases to consider:  normal buffer growth/reduction and edge cases that caused by errors in the central process.  The error scenarios to check that I can think of are: 

1)      Critical nodes that receive alternating hints for large/small, 

2)      Massive large hints for all nodes

On #2, the AS boundary for AS confederations or AS policies have known solutions for existing problems. 

You are arguing for is a new technology – segment routing enabled by BGP technology with the capability to have BGP peer topology as part of the segment routing.  A group of drafts defining this new technology should provide a cogent definition for the administrative boundary of segment routing in either the segment routing drafts.  This SR domain boundary should be detectable by management process.  

A positive solution would be to provide: a) a definition boundary one of the BGP drafts (or a segment routing drafts) and b) a Yang model that will provide the detection of the boundary.  

On, the 2015 prefix-sid mail – I will send a summary to the list. 

Sue Hares 

From: Eric C Rosen [mailto:[email-masked]] 
Sent: Monday, June 25, 2018 2:12 PM
To: Susan Hares; 'Ketan Talaulikar (ketant)'; 'Robert Raszuk'
Cc: 'idr@ietf. org'
Subject: Re: [Idr] BGP-LS and the like ...

[Sue]: 

I don't understand this objection.    Typically, when a node receives a SAFI-4 update, and has to propagate that update on an EBGP session, it changes the label value and the next hop value before propagation.  The "hint" tells you what to change the label value to.  Without the hint, you make a local choice of what to change the label value to.  There is nothing here that is "growing without bounds" or causing a "recursive" problem.

 

The problem here is that the notion of "AS boundary" as "administrative boundary" has long been obsolete.  The attribute under discussion is just one of a whole set of attributes that could benefit from a general "attribute scoping" solution, assuming someone could figure out a solution that is general enough to make sense and not too costly to deploy.  You can't expect this particular draft to address that problem.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 26 Jun 2018 11:36:42 -0400

On 6/26/2018 9:54 AM, Susan Hares wrote:
> Used a “link metric, which was an instantaneous sample rather than an 
> average, was a poor indicator of expected delay on a link as the 
> quantity being sampled fluctuated fairly rapidly at all traffic 
> levels.”  This is a quote from the reference academic paper link below 
> (circa 1989).
>

I am very familiar with this issue about feedback loops in the ARPAnet, 
but I don't understand what it has to do with the draft under discussion.

>
> If you suggest that hints to the buffer algorithm do not cause 
> fluctuations, then provide the discussion on the list that provides 
> this proof.
>

Are we still talking about the prefix-SID attribute draft?  It has 
nothing to do with buffer allocations.  Also, it has no feedback loops.

Or are you talking about the BGP-LS draft?  That draft just describes 
the distribution of information; if you're worried about feeback loops 
created by the use of that information, I think you need to go to the 
LSVR WG.  The BGP-LS stuff has nothing to do with the prefix-SID draft 
though.

> A group of drafts defining this new technology should provide a cogent 
> definition for the administrative boundary of segment routing in 
> either the segment routing drafts.  This SR domain boundary should be 
> detectable by management process.
>
>

Defining the admin boundary of an SR domain would be outside the scope 
of any BGP document.

It would be nice if BGP had a simple way of restricting the distribution 
of attributes and/or communities and/or extended communities and/or 
large communities and/or super-duper communities to specified 
administrative domains.  Unfortunately, it doesn't. But this is a 
long-standing problem that is generally dealt with on an ad hoc basis by 
policy.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 26 Jun 2018 12:28:05 -0400

Eric:

The context was whether SRGB TLV in BGP PREFIX-SID qualified for the attribute discard (per RFC7606) error handling.

I’m open to either “yes” or “no” to this question - as long as the answer comes a discussion regarding the impact of label stack availability on TE algorithms or segment routing policies used to build segment routes in a network.   See the statements from bgp-prefix-sid below. 

I started a new thread on this topic that you are welcome to join. 

Sue Hares 

---------------

See statements by draft-ietf-idr-bgp-prefix-sid-26:

      If a prefix segment is to be included in an MPLS label stack,

      e.g., for traffic engineering purposes, the knowledge of the SRGB

      of the originator of the prefix is required in order to compute

      the local label used by the originator.

Section 3.2 

   The Originator SRGB TLV contains the SRGB of the node originating the

   prefix to which the BGP Prefix-SID is attached.  The Originator SRGB

   TLV MUST NOT be changed during the propagation of the BGP update.  It

   is used to build segment routing policies when different SRGBs are

   used in the fabric, for example

   ([I-D.ietf-spring-segment-routing-msdc <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-26#ref-I-D.ietf-spring-segment-routing-msdc> ]).

From: Eric C Rosen [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2018 11:37 AM
To: Susan Hares; 'Ketan Talaulikar (ketant)'; 'Robert Raszuk'
Cc: 'idr@ietf. org'
Subject: Re: [Idr] BGP-LS and the like ...

Eric: 

I am very familiar with this issue about feedback loops in the ARPAnet, but I don't understand what it has to do with the draft under discussion.

If you suggest that hints to the buffer algorithm do not cause fluctuations, then provide the discussion on the list that provides this proof.   

Are we still talking about the prefix-SID attribute draft?  It has nothing to do with buffer allocations.  Also, it has no feedback loops.

Or are you talking about the BGP-LS draft?  That draft just describes the distribution of information; if you're worried about feeback loops created by the use of that information, I think you need to go to the LSVR WG.  The BGP-LS stuff has nothing to do with the prefix-SID draft though.

A group of drafts defining this new technology should provide a cogent definition for the administrative boundary of segment routing in either the segment routing drafts.  This SR domain boundary should be detectable by management process.  

Defining the admin boundary of an SR domain would be outside the scope of any BGP document.   

It would be nice if BGP had a simple way of restricting the distribution of attributes and/or communities and/or extended communities and/or large communities and/or super-duper communities to specified administrative domains.  Unfortunately, it doesn't.  But this is a long-standing problem that is generally dealt with on an ad hoc basis by policy.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 26 Jun 2018 16:50:01 +0000

Hi Sue,

If the application building the SR policies is receiving the topology feed via BGP-LS (which includes the SRGB), then the BGP Prefix SID draft does say that the SRGB learnt via BGP-LS is preferred. If the application also receives a conflicting value of SRGB from BGP via the SRGB TLV in the Prefix SID Attribute then this could be logged as an error but I am not sure we want to discard the entire BGP Prefix SID attribute in this case. The use-case for SRGB TLV is for this TE purpose where there might be a conflict (resolved via the preference indicated), but there is no such conflict for BGP-LU operations while using the Label Index TLV.

Thanks,
Ketan

From: Susan Hares <[email-masked]>
Sent: 26 June 2018 21:58
To: 'Eric C Rosen' <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Cc: 'idr@ietf. org' <[email-masked]>
Subject: RE: [Idr] BGP-LS and the like ...

Eric:

Sue Hares

---------------

Section 3.2

   ([I-D.ietf-spring-segment-routing-msdc<https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-26#ref-I-D.ietf-spring-segment-routing-msdc>]).

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 26 Jun 2018 13:00:48 -0400

Ketan:

This is one reasonable answer.   I suggest the documents provide these answers to non-conflicts in order provide interoperable specifications.   

Sue Hares 

From: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2018 12:50 PM
To: Susan Hares; 'Eric C Rosen'; 'Robert Raszuk'
Cc: 'idr@ietf. org'; Acee Lindem (acee)
Subject: RE: [Idr] BGP-LS and the like ...

Hi Sue,

Thanks,

Ketan

Eric:

Sue Hares 

---------------

Section 3.2 

Eric:

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 26 Jun 2018 13:23:21 -0400

On 6/26/2018 12:50 PM, Ketan Talaulikar (ketant) wrote:
> If the application also receives a conflicting value of SRGB from BGP 
> via the SRGB TLV in the Prefix SID Attribute then this could be logged 
> as an error but I am not sure we want to discard the entire BGP Prefix 
> SID attribute in this case. 

The attribute is not malformed in this case, so there would be no reason 
to apply the attribute-discard procedure.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 Jun 2018 17:43:11 +0000

On Jun 26, 2018, at 1:23 PM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:

On 6/26/2018 12:50 PM, Ketan Talaulikar (ketant) wrote:
If the application also receives a conflicting value of SRGB from BGP via the SRGB TLV in the Prefix SID Attribute then this could be logged as an error but I am not sure we want to discard the entire BGP Prefix SID attribute in this case.

The attribute is not malformed in this case, so there would be no reason to apply the attribute-discard procedure.

FWIW, I agree totally.

Acee

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 26 Jun 2018 14:28:42 -0400

Acee:

As long as draft-ietf-idr-bgp-prefix-sid indicates how to handle the
duplicates then it is not a malformed attribute or a conflict between
attributes.

The WG needs to still discuss the attribute discard case for the SR routing
case.  I've started another thread for that discussion on "Does SRGB TLV in
draft-ietf-idr-bgp-prefix-sid qualify for BGP Attribute discard?"

Sue 

PS - I believe that your suggested text you sent me as shepherd handles
duplicates.  Perhaps you can ask the WG to review it to see if I am correct.

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2018 1:43 PM
To: Eric C Rosen
Cc: Ketan Talaulikar (ketant); Susan Hares; Robert Raszuk; idr@ietf. org
Subject: Re: [Idr] BGP-LS and the like ...

On Jun 26, 2018, at 1:23 PM, Eric C Rosen <[email-masked]> wrote:

If the application also receives a conflicting value of SRGB from BGP via
the SRGB TLV in the Prefix SID Attribute then this could be logged as an
error but I am not sure we want to discard the entire BGP Prefix SID
attribute in this case. 

The attribute is not malformed in this case, so there would be no reason to
apply the attribute-discard procedure.

FWIW, I agree totally. 

Acee