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

["Susan Hares" <[e-mail]>]

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

 

 

 

 

 

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

Ketan: 

 

Thank you for your comments.   See mine below. 

 

Sue 

 

 

From: Ketan Talaulikar (ketant) [mailto:[e-mail]] 
Sent: Thursday, June 21, 2018 7:44 AM
To: Robert Raszuk; Susan Hares
Cc: idr@ietf. org
Subject: RE: [Idr] BGP-LS and the like ...

 

Hi Robert,

 

Thanks for bringing up this topic and more importantly putting it in (IMHO) “right” context.

 

Please check inline below

 

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

 

Hi Sue & WG,

 

Adjusting subject line to reflect content. 

 

Excellent writeup on BGP-LS ! The only thing which I could perhaps add is that while maintaining previous opinion on BGP-LS in general the most what bothers me with this is the granularity of BGP machinery awarness of "stuff" it is subject to carry. 

[KT] Agree – it would bother me too if every BGP speaker had to do this. It would also bother if we could not introduce a new BGP-LS attribute TLV with code changes on just the originator and the receiver BGP-LS nodes – just because say the transit BGP speakers (e.g. RRs) do not understand it.

 

[Sue]:  How do we assure that every BGP speaker does not have to deal with it? 

Draft-ietf-bgp-prefix-sid is traveling to BGP peers which do not speak BGP-LS. 

 

If we continue for every new IGP extension or SR policy extension see a corresponding BGP draft in order to carry it in BGP where do we end up in few months or years from now ? 

[KT] This is actually ongoing right now and required for the use-cases where BGP-LS provides the topology information “northbound” to a controller.

 

[Sue]:  The fact it is ongoing in specification does not abrogate the need to stop at this point and ask “Is this a good idea?”.    We need to have some agreed upon idea on where this is going. 

 

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

[KT] This is very important and that is why RFC 7752 proposes the framework for fault management which should be applicable to BGP-LS in general. It is all about verifying the TLVs without necessary having to do a check on the content. It is possible for a BGP speaker to opaquely handle these BGP-LS messages without semantic interpretation of the contents.

 

[Sue]:  The RFC7752 fault management is a list of questions that form a filter.  I have indicated in my reviews of your draft where the “content” requirements (PEER-NODE-SID) requirements do not fit. 

 

 

Perhaps using BGP as a pure LSDB transport and carry big black container with "some other stuff inside" would be ok for some .. at least during the transition to much more proper transport. Not advocating it - just recognizing reality observing the flight already inroute. 

 

 

[KT] Perhaps a packed set of black boxes in the NLRI descriptors and attributes – so as to ensure transport integrity for BGP. However, the semantic verification or understanding of the individual TLVs may be left to the nodes (rather applications) that originate & consume this information. Today, most use-cases involve the use of BGP-LS to propagate information within an administrative domain (one or more AS) and being a separate AFI/SAFI provides the control to limit its scope as such. At the point where BGP speakers in transit do require to perform policy or filtering operations on these TLVs then they would need to be aware of the same and when there are such considerations, then they should be called out by specific documents.

 

[Sue]:  I am assuming your sematic verification is my “content” error handling. 

 

If you are going have the sematic verification that compares and understands TLVS unique to the individual nodes, why do you need a standard?   However, I assume that you mean BGP Peers that process the BGP-LS attribute and the BGP-LS NLRI.  If this is true, then clearly specify this in your specifications.  Clearly indicate what happens a transit BGP Speaker processes these opaque packets.  

 

I also noticed below in your BGP-LS writeup you bring up draft-ietf-idr-segment-routing-te-policy-03.txt. But how is this related to BGP-LS at all ? It defines its own new SAFI and do not even carry any link state information ... 

[KT] It is not.

 

[Sue] It is not linked to BGP-LS, but to segment routing additions to BGP. Please note that the original topic was not BGP-LS, but segment routing additions to BGP.  

 

Thanks,

Ketan

 

I am starting to have a feeling that this non core routing information transport over BGP is simply getting out of hand :) And of course many will correctly say that this started with introduction of multiprotocol extensions to BGP followed by original 2547 - but it seems that this trend is growing exponentially now. 

 

Cheers,
Robert.

 

 

On Thu, Jun 21, 2018 at 2:02 AM, Susan Hares <[e-mail]> wrote:

Warren, Robert, Acee:

 

Warren has a valid question..  I cannot find a long mail thread on transitive or non-transitive for this specific attribute.   

 

Answering Warren’s question about discussions in WG also requires it within a larger discussion. The mechanism in draft-idr-bgp-prefix-sid-25.txt is a BGP  attribute sent as an exception if the BGP-LS service for Segment Routing (SR) is not available.. The BGP-LS service for SR routing consists of BGP-LS NLRI and BGP Attributes.  Draft-idr-bgp-prefix-sid’s mechanism expands the traffic flow burden for BGP beyond just BGP-LS peers. Is this wise beyond a single AS? 

 

Some long-term participants of IDR say it is unwise to expand BGP-LS to SR routing (Robert Raszuk, Tony Li).. Therefore I suspect that restricting draft-idr-bgp-prefix-sid to a non-transitive attribute lessens some concerns, but does not resolve the main issues. 

 

The question of transitive or non-transitive depends on what you think SR and BGP’s mechanisms for SR should do. If you think SR is a vibrant technology which would should help to mature, then you may want to make it easy for the multiple ASes within a Data Center to use the SR functions.  If this is your belief, then the attribute should be transitive. 

 

If you are concerned about BGP-LS and SR requiring additional resources of BGP peers which do not support BGP-LS, then you will want the attribute to be non-transitive or refuse to standardize this mechanism.   

 

To review IDR’s decision (and the IESG should), you will need to put in the context of the entire SR mechanisms that are forthcoming in BGP based on the SR Architecture decided by SPRING.  The IESG has approved SR architecture and main applications (draft-ietf-spring-segment-routing,  draft-ietf-spring-segment-routing-central-epe-10.txt., and drat-ietf-segment-routing-msdc-09.txt), but it has not looked at the mechanisms for SR extensions to BGP-LS or the concept of extending BGP-LS.  

 

The rest of this long memo has two parts: 

 

1)  2 problems I see in the current draft-ietf-bgp-peer-sid based on additional reviews of BGP documents I did in preparation for this IESG Review of this document, 

 

2)  Big picture information for Warren’s information

 

3)  Summary of current status of BGP work regarding SR and BGP-LS  

 

If Warren or the IESG has not considered these issues in depth, I recommend the scope of the SR and BGP additions for SR are such that we should hold a briefing session for the IESG at Montreal. 

 

As IDR co-chair, it is my hope to move all of these documents on BGP-LS additions for SR toward completion (standardization or closure on next steps) within the next few months.  

 

Susan Hares 

Shepherd

IDR co-chair

 

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

 

Personal concerns as co-chair on draft

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

Please note that I see the BGP-LS work as a vibrant technology that needs to have error handling and manageability improved in order to be released in an environment where BGP Peers are interoperable/ 

 

Problem 1: 

I noted over the weekend that draft-ietf-bgp-prefix-sid-25.txt does not specify what happens with the BGP attribute for BGP Peer-SID is contained in a BGP packet with:

·         BGP Attribute for BGP-LS with BGP attributes for SR routing (per draft-ietf-idr-bgp-ls-segment-routing-ext-08),  or 

·         BGP Attribute for BGP-LS with BGP attributes for BGP-EPE SR routing for the centralized controller form of segment routing (per draft-ietf-idr-bgpls-segment-routing-epe-15). 

 

I noticed that the drafts simply say the normal BGP-LS error handling will work, but these normally fine BGP-LS attributes are not valid when taken together. This is “content” checking – so the drafts all need to be revised.  (see my shepherd comments on the drafts). 

 

Problem 2: 

Another concern is draft-ietf-spring-segment-routing-msdc-09 in section 4.1 makes RFC8277 (BGP with labels) + BGP attribute for bgp-prefix SID as the main BGP choice for the data center.  The direction does not match the statement draft-ietf-idr-bgp-prefix-sid-25 that says: 

      This document assumes that BGP-LS is the preferred method for

      collecting both peer segments (Peer SIDs) and SRGB information

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

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

      optional alternative for the advertisement of the local SRGB

      without the topology nor the peer SIDs, hence without

      applicability for TE, the Originator SRGB TLV of the BGP Prefix-

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

 

The draft-ietf-spring-segment-routing-msdc-09.txt does not really treat the draft-ietf-bgp-prefix-sid-25.txt as an “exception”.  It is this creeping feature that has made some long-time IDR participants asked where the boundaries of the SR additions to BGP are.     

 

As IDR co-chair, I need to understand is the bgp attribute for BGP Peer SID an exception for a corner case (as IDR WG says) or a main mechanism of a use case (as SPRING WG Says). 

 

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

Overview of the BGP-LS discussion 

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

A) Big picture Issues

 

BGP-LS was passed due as an informational stream among specific routers that were carrying information to the centralized controller. This information stream was to limited to a set of BGP peers who primary job was to pass information to allow off-line computation of routes (SDN or centralized controller).  

 

BGP-LS for segment routing adds feedback to this information stream by providing mechanisms to tag certain links, nodes, adjacencies, and Peer sets as segments. Based on this information routing can utilize these segments to established smart forwarding planes to enable source-routing protocol within a domain.  The BGP-LS weight is currently carried only by the routers who have BGP-LS functions. 

 

The expansion outside of that set of peers to general BGP peers is what the draft-bgp-prefix-sid-25 is proposing.  This expansion may spread the burden of information flow to more peers than the original scope of BGP-LS. 

 

SPRING’s WG is spreading the amount of information sent by BGP-LS peers.  

 

With the IESG’s approval of draft-ietf-spring-segment-routing and draft-spring-segment-routing-central-epe, you have enabled an architecture that allows SDN controller to control a single AS or a group of ASes within the wide-area. With draft-ietf-spring-segment-routing-msdc, you have enable for one or many datacenters.  Data centers may have thousands or tens of thousands of BGP ASes (from the private AS space). 

 

The expansion of BGP to carrying massive amounts of Traffic Engineering for IGPs (draft-ietf-idr-te-pm-bgp-10.txt, draft-ietf-idr-segment-routing-te-policy-02) and BGPs is a natural outgrowth of the source-routing use of BGP.  This direction needs to be confirmed before we send the next 10 drafts from IDR into the IESG.  In this way, the IESG will agree to the direction and then each draft can be evaluate in terms of its fitting with the direction. 

 

Have the Security ADs taken a strong look at the potential failure cases for the Segment Routing architecture as expressed by BGP?   If so, feedback should be given on all BGP-LS drafts and the spring architecture. 

 

Tony Li and Robert Raszuks, have commented that this extension to BGP-LS goes beyond the bounds of good network technology. As I have described, the expansion of the information flow is grown in 2 direction: more data (SR extensions, SR-TE extensions, BGP-EPE extensions, etc.. ) and more peers (bgp-prefix-sid) beyond just the BGP-LS capable BGP peers.  

 

The IDR and SPRING WG have been working on these technologies for 3 years so hopefully, the IESG has an opinion about the extension of BGP-LS in these two fashions to serve these features.  I would be glad to provide a BGP discussion with the IESG along with my IDR co-chair and with the chairs of the SPRING WG..  

 

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

Key drafts for BGP-LS passing Service besides draft-ietf-bgp-prefix-sid 

 

Please note that the key drafts for the BGP portion of segment routing are:  

1.  draft-ietf-idr-bgpls-segment-routing-ext-08 – changes to BGP attribute for BGP-LS and BGP-LS NLRI to support segment routing,

 

status: This draft has passed WG LC, see shepherd’s report for latest revisions needed. The draft is generally readable, so please read the draft before deciding on bgp-prefix-sid.  Please remember that the TLVs being proposed are for both the NLRI and the attribute. 

 

Spring WG link: draft-ietf-spring-segment-routing – getting IGP information.  

 

Shepherd’s concern:  1) Error handling and manageability with other BGP technology (Yang models), 2) security concerns, 3)

 

 

 

2.  draft-ietf-idr-bgpls-segment-routing-epe-15

 

Status: Passed WG LC, and provides the mechanisms needed SR’s BGP Peer Egress Peer Engineering (BGP-EPE).  Please see my shepherd’s report on this draft.  

 

Shepherd’s concerns: 1) error handling/manageability, 2) security concerns, 3) adaption of this technology beyond E-BGP to IBGP is underspecified (see long-term looping issues with IBGP RR), 3) security 

 

Editorial comment: This draft needs a lot of editorial work so reading this draft may be difficult. Authors are active in upgrading the draft. 

 

3.   draft-ietf-idr-te-pm-bgp-10 – 

 

Status: WG-LC light response,  1 Week final call (6/20 to 6/27)  

Shepherd’s comments: Technology links nicely to the traffic  Engineering for BGP-LS in general.  SR can utilize this information. Chairs have discussed forwarding this traffic.  

 

4.  Draft-ietf-idr-bgp-ls-node-admin-tag-extension

 

Status: PAST WG LC 

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

  

5.  draft-ietf-idr-segment-routing-te-policy-03.txt 

 

Status: WG Draft 

Spring WG link: draft-ietf-spring-segment-routing-policy-01

 

Shepherd’s comments:  Policy inclusion for SR is recommended by

Spring.  BGP SR TE policy sub-TLVS fit SPRING’s requirement

      If IDR, SPRING And IESG Agree it should be added.  

      Should any of 

 

6.  draft-ietf-idr-bgp-ls-segment-routing-rld: 

 

Status: WG draft 

 

Spring-link: MPLS Entropy label exposing from IGPs (ISIS and OSPF) the information on RLD (readable label depth) and ELC (entropy label capability) of a node.  This addition supports a centralized controller application of spring (draft-ietf-spring-segment-routing-central-epe-10.txt).  

 

Shepherd’s comment: TLVs are for BGP attribute for BGP-LS and

BGP-LS NLRI to be shared amount BGP-LS peers. 

 

Shepherd’s concerns: error handling (conflicting TLVS in BGP attribute, conflicting TLVs in BGP-LS attribute

 

7.  draft-ietf-idr-bgp-ls-segment-routing-msd 

Status: WG Draft

 

IGP-link: Capturing IGP (ISIS, OSPF) the Maximum SID Depth supported by a node (draft-ietf-isis-segment-routing-msd, draft-ietf-ospf-segment-routing-msd). 

PCE –link: draft-ietf-pce-segment-routing. 

 

Shepherd’s comment: TLVs are for BGP attribute for BGP-LS and

BGP-LS NLRI to be shared amount BGP-LS peers. 

Shepherd’s concerns: error handling (conflicting TLVS in BGP attribute, conflicting TLVs in BGP-LS attribute.  

 

      

 

C) Upcoming IPv6 work 

 

The upcoming SRv6 work is being proposed in: draft-dawra-idr-bgpls-srv6-ext-03, draft-dawra-idr-srv6-vpn-03, draft-kentant-idr-bgp-ls-bgp-only-fabric-03.  

 

Additional extensions for the BGP-LS for Inter-AS topology,  routing, or service chaining include: Draft-chunduri-idr-bgp-ls-nspfid, draft-li-idr-bgp-ls-sr-policy-path-segment, draft-li-idr-sr-policy-path-segment-distribution, and others.  

 

 

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

 

 

 

On Tue, Jun 19, 2018 at 11:01 AM Robert Raszuk <[e-mail]> wrote:

Hi Acee,

 

Just making the attribute non transitive to prevent accidental leaking worldwide would easliy address this valid concern for the cost of upgrading RRs (if applicable) in any given domain which is to use it.  

 

​That sounds like a fine idea -- was this discussed and rejected? Is there any reason that this cannot be non-transitive?

 

W

 

 

Leaking it with IPv6 routes globally - either by accident or not so perfect operational practices of the sourcing AS  seems like an a little architecture bug since such info would be of no use externally to original administrative domain.

 

Best,

R.

 

 

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

Hi Warren, 

> On Jun 18, 2018, at 8:30 PM, Warren Kumari <[e-mail]> wrote:
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-idr-bgp-prefix-sid-25: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www..ietf.org/iesg/statement/discuss-criteria.html> 
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I'm balloting NoObjection, but I'm sad that nothing came of my previous request:
> 
> "Major(ish) issue:
> Section 5.  Advertising BGP Prefix-SID Attribute
>  "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes
>  (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760].  In
>  order to prevent distribution of the BGP Prefix-SID attribute beyond
>  its intended scope of applicability, attribute filtering SHOULD be
>  deployed."
> Thank you for including this -- however, as I'm sure you know, the state of BGP
> filtering in the wild is, er, poor. Can you please provide some additional
> guidance? For example, could you include an appendix with examples?

No. As I told you before this is a can of worms that I’m not going to open in this draft (and particularly not during IESG review). As I also told you before the state of BGP filtering is something that you should propose as a work item for your OPS homies in the GROW WG. 


> Or simply a
> bit more text on determining the scope of applicability? Apologies if I missed
> this, but should this by default be filtered on eBGP sessions? The included
> text is a great start, but some more (so people don't miss it and shoot
> themselves in the foot would be much appreciated. “

I will add “, e.g., at SR domain boundaries,’  to the statement. 

Thanks,
Acee




> 
> 

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr

 




 

-- 

I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf