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

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

Acee:

 

The point is that it is draft and BGP-LS drafts both put BGP Attributes into BGP packets.  Both this draft and BGP-LS drafts with SR functions flag SIDS for BGP Peering SIDS.  


Your draft states: 

 

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

 

If this method and the preferred method both have attributes in the BGP packet, what happens?  What if BGP-LS attributes and BGP PEER SID both try to set SID values?  Your draft does not specify the interaction and draft-ietf-idr-bgpls-segment-routing, and draft-ietf-bgp-ls-segment-routing-ext do not specify what happens. This is an error case that I did not catch until I was going through all the drafts to find cross-draft error conditions. 

 

Also, based on the above text, I was surprised to see it recommended as the main mechanism in: draft-ietf-spring-segment-routing-msdc-09.  

 

 

Sue Hares 

 

OPS - On the delays, we all (you, me, Alvaro, IESG, idr chairs)  need to own our piece of the delays.  You choose to take this draft back through the WG a second time.  If you take it through the WG again, then it goes through all the processing (RTG-DIR, WG LC, IETF LC, etc).  

 

Perhaps we can chat at IETF and see how we can improve the process. 

 

 

From: Idr [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, June 20, 2018 8:17 PM
To: Susan Hares; 'Warren Kumari'; 'Robert Raszuk'
Cc: 'The IESG'; 'idr@ietf. org'; [e-mail]; [e-mail]; acee=[e-mail]
Subject: Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

 

Hi Sue, 

I think you are confusing this draft with draft-ietf-idr-bgpls-segment-routing-epe.  This draft is not an extension of BGP-LS. I have no problems with making this a non-transitive attribute since this only impacts attributes that are not recognized by the receiver. What I do have a problem with are further delays when and reiterations as my opinion is that it never should have gone through the whole last-call and directorate review cycle again in the first place. There are multiple implementations of the draft and it has been in around for almost 4 years – everyone has had ample opportunity for review. 

Thanks,

Acee 

 

From: Susan Hares <[e-mail]>
Date: Wednesday, June 20, 2018 at 8:03 PM
To: Warren Kumari <[e-mail]>, Robert Raszuk <[e-mail]>
Cc: "acee=[e-mail]" <acee=[e-mail]>, IDR List <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>
Subject: RE: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM
Resent-From: <[e-mail]>
Resent-To: Stefano Previdi <[e-mail]>, <[e-mail]>, Acee Lindem <[e-mail]>, Arjun Sreekantiah <[e-mail]>, <[e-mail]>
Resent-Date: Wednesday, June 20, 2018 at 8:03 PM

 

Warren, Robert, Acee:

 

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

 

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

 

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

 

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

 

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

 

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

 

The rest of this long memo has two parts: 

 

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

 

2)      Big picture information for Warren’s information

 

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

 

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

 

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

 

Susan Hares 

Shepherd

IDR co-chair

 

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

 

Personal concerns as co-chair on draft

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

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

 

Problem 1: 

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

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

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

 

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

 

Problem 2: 

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



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

      collecting both peer segments (Peer SIDs) and SRGB information

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

      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  <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-25#section-3.2> Section 3.2 of this document.

 

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

 

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

 

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

Overview of the BGP-LS discussion 

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

A) Big picture Issues

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

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

 

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

 

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

 

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

 

 

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

Status: PAST WG LC 

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

  

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

 

Status: WG Draft 

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

 

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

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

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

      Should any of 

 

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

 

Status: WG draft 

 

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

 

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

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

 

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

 

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

Status: WG Draft

 

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

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

 

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

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

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

 

      

 

C) Upcoming IPv6 work 

 

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

 

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

 

 

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

 

 

 

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

Hi Acee,

 

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

 

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

 

W

 

 

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

 

Best,

R.

 

 

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

Hi Warren, 

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

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


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

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

Thanks,
Acee




> 
> 

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

 




 

-- 

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