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

From: "Susan Hares" <[email-masked]>
Date: Wed, 20 Jun 2018 20:02:40 -0400

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: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 21 Jun 2018 00:17:16 +0000

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

Warren, Robert, Acee:

Susan Hares
Shepherd
IDR co-chair

Problem 1:

Problem 2:

      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.

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

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

Status: PAST WG LC

Status: WG Draft

Status: WG draft

C) Upcoming IPv6 work

On Tue, Jun 19, 2018 at 11:01 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Acee,

W

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

Thanks,
Acee

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 20 Jun 2018 21:47:38 -0400

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:[email-masked]] 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'; [email-masked]; [email-masked]; acee=[email-masked]
Subject: Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

Hi Sue, 

Thanks,

Acee 

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 

 

 

Hi Acee,

W

Best,

R.

Hi Warren, 

Thanks,
Acee

 

--

---

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

Hi Sue,

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

Very interesting comment ... Where do you draw such conclusion from ?

IMO this draft has nothing to do with BGP-LS at all ...

BGP-LS is gathering data from network elements to controller ... this draft
is installing SIDs from controller to ingress network elements. While
mutually required for some solutions they are completely orthogonal to each
other.

Best,
R.

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.
>
>
>
> 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
>
>
>
> 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:
>
>       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.
>
>
>
> 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.
>
>
>
> =================
>
> 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.
>
>
>
> 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.
>
>
>
> Shepherd’s comments: Needs additions for 1) Error handling comment, 2)
> Manageability, 3) small addition to security security.
>
>
>
> 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).
>
>
>
>
> 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).
>
>
> 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)
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
> 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
> 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: stefano previdi <[email-masked]>
Date: Thu, 21 Jun 2018 08:26:38 +0200

Hi,

the BGP prefix SID attribute is advertised in order to give a hint to the receiver on what label value to allocate for BGP labelled routes. The receiver may or may not follow the hint.

The BGPLS SR attributes are defined in order for a local router to advertise what he has allocated. Extensions have been defined for the different use cases (IGP, EPE, TE, ...).

I agree with Robert’s statement: BGP Prefix SID is orthogonal to any BGPLS advertisement.

Thanks.
s.

> On Jun 21, 2018, at 7:59 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Sue,
> 
>> mechanisms for SR extensions to BGP-LS or the concept of extending BGP-LS

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Jun 2018 06:45:38 -0400

Robert and Stefano: 

I've pulled both of your comments to the front of this message.  

> as an exception if the BGP-LS service for Segment Routing (SR) is not available

[Robert]: Very interesting comment 
[Robert]:  Where do you draw such conclusion from ?
[Robert]: IMO this draft has nothing to do with BGP-LS at all ...

See comment from draft-ietf-idr-bgp-prefix-sid-25 below to where I get the comment from. 

[Stefano]: the BGP prefix SID attribute is advertised in order to give
[Stefano]: a hint to the receiver on what label value to allocate for BGP labelled 
[Stefano]: routes. The receiver may or may not follow the hint.
[Stefano]: The BGPLS SR attributes are defined in order for a local router
[Stefano]: to advertise what he has allocated. Extensions have been defined
[Stefano]:  for the different use cases (IGP, EPE, TE, ...).

My technical problem #1 has to do with what happens if all of these come in the same BGP packet as combinations of BGP attributes or as combination of BGP attributes and NLRIs?  

The mechanisms between draft-bgp-prefix-sid and draft-bgp-ls-segment-routing-ext should be orthogonal, but what happens if by error they end up in the same BGP packet being sent to a BGP-LS capable peer, or to a BGP Peer capable of only draft-bgp-prefix-sid functions.   

My plea as an IDR reviewer is to improve the error handling descriptions in the drafts to have interoperable implementations before publication of draft-ietf-idr-bgp-prefix-sid-25.txt. 

Right now the implementations that are listed on the IDR page are RTBRICK and Cisco.   I quote the RTbrick Fullstack-OS 17.2 or greater comments "No interoperability testing has been done".   The only interoperability testing that has been done is "Cisco NX-OS and Cisco IOS-XR".   
Therefore, as a BGP Reviewer I look carefully at the BGP error handling in cases where single company interoperability testing between two unique implementation has been done.  

Sue   

===============
>From the draft-ietf-idr-bgp-prefix-sid-25 in section 2:

     This document assumes that BGP-LS is the preferred method for
      collecting both peer segments (Peer SIDs) and SRGB information
      through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and
      [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 of this document.

Section 3.2 specifies the SRGB TLV.   

Draft-ietf-idr-bgp-ls-segment-routing-ext states: 
==========
2.  BGP-LS Extensions for Segment Routing

   This document defines SR extensions to BGP-LS and specifies the TLVs
   and sub-TLVs for advertising SR information.  Section 2.4 and
   Section 2.5 illustrates the equivalent TLVs and sub-TLVs in IS-IS,
   OSPFv2 and OSPFv3 protocols.

   BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a
   Link NLRI or a Prefix NLRI.  The corresponding BGP-LS attribute is a
   Node Attribute, a Link Attribute or a Prefix Attribute.

Section 2.1 defines the SID Node attribute TLVS, and the SR Local Block (specifies) the same SRGB TLV as above to be collected.  

BGP-LS Extensions for SR for BGP-EPE (draft-ietf-idr-bgpls-segment-routing-epe-15)   specifies setting the Peer-Node-SID in section 5.1.   Quoting from section 5.1

5.1.  Peer-Node-SID

   The Peer-Node-SID describes the BGP session peer (neighbor).  It MUST
   be present when describing a BGP-EPE topology as defined in
   [I-D.ietf-spring-segment-routing-central-epe].  The Peer-Node-SID is
   encoded within the BGP-LS Link NLRI specified in Section 4.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 2:00 AM
To: Susan Hares
Cc: Warren Kumari; Acee Lindem (acee); 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 COMM

Hi Sue,

> The mechanism in draft-idr-bgp-prefix-sid-25.txt is a BGP  attribute 
as an exception if the BGP-LS service for Segment Routing (SR) is not available.

BGP-LS is gathering data from network elements to controller ... this draft is installing SIDs from controller to ingress network elements. While mutually required for some solutions they are completely orthogonal to each other.

Best,
R.

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

> 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 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,
> mechanisms for SR extensions to BGP-LS or the concept of extending BGP-LS=

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 Jun 2018 13:13:36 +0200

​​Hello Sue,

Ok I see where your comment came from. Let me provide my POV on this:

* We were commenting in reference to section 3.1 Label-Index TLV while
clearly your comment was based on section 3.2 Originator SRGB TLV

* Yes there can be case you describe that both BGP-LS and this extension
advertises SRGB ranges of the node. But at most I would treat this as
redundant information. If there is mismatch then I suppose there are bigger
issues to be solved and I am not sure if they are actually in scope of this
proposal or IDR.

Along the same lines you could stop BGP-LS RFC and ask what happens if
BGP-LS fed information is different then listening to IGP by the controller
? I guess controller must be at min that much smart to handle it, raise the
alarms etc ...

Clearly those are important topics, but I fail to see how they are at all
related to BGP.  BGP is just a truck here :).

Cheers,
R.

On Thu, Jun 21, 2018 at 12:45 PM, Susan Hares <[email-masked]> wrote:

> available
> My technical problem #1 has to do with what happens if all of these come
> in the same BGP packet as combinations of BGP attributes or as combination
> of BGP attributes and NLRIs?
>
> The mechanisms between draft-bgp-prefix-sid and
> draft-bgp-ls-segment-routing-ext should be orthogonal, but what happens
> if by error they end up in the same BGP packet being sent to a BGP-LS
> capable peer, or to a BGP Peer capable of only draft-bgp-prefix-sid
> functions.
>
> My plea as an IDR reviewer is to improve the error handling descriptions
> in the drafts to have interoperable implementations before publication of
> draft-ietf-idr-bgp-prefix-sid-25.txt.
>
> Right now the implementations that are listed on the IDR page are RTBRICK
> and Cisco.   I quote the RTbrick Fullstack-OS 17.2 or greater comments "No
> interoperability testing has been done".   The only interoperability
> testing that has been done is "Cisco NX-OS and Cisco IOS-XR".
> Therefore, as a BGP Reviewer I look carefully at the BGP error handling in
> cases where single company interoperability testing between two unique
> implementation has been done.
>
> Sue
>
> ===============
> Section 2.1 defines the SID Node attribute TLVS, and the SR Local Block
> (specifies) the same SRGB TLV as above to be collected.
>
> BGP-LS Extensions for SR for BGP-EPE (draft-ietf-idr-bgpls-segment-routing-epe-15)
>  specifies setting the Peer-Node-SID in section 5.1.   Quoting from section
> 5.1
>
> 5.1.  Peer-Node-SID
>
> Cc: Warren Kumari; Acee Lindem (acee); idr@ietf. org; [email-masked];
> Subject: Re: [Idr] Warren Kumari's No Objection on
> draft-ietf-idr-bgp-prefix-sid-25: (with COMM
>
> Hi Sue,
>
> BGP-LS is gathering data from network elements to controller ... this
> draft is installing SIDs from controller to ingress network elements. While

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Jun 2018 07:28:40 -0400

Robert: 

Now you understand the point.  The BGP truck has rules about BGP Attribute errors.  RFC7606 states:

   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.

RFC7752 has the following “management” 

   If an implementation of BGP-LS detects a malformed attribute, then it
   MUST use the 'Attribute Discard' action as per [RFC7606], Section <https://tools.ietf.org/html/rfc7606#section-2>  2

If attribute-discard is used, it MUST not be used except in the case of an attribute that has no effect on route selection or installation. 

At this point, it is clear that the SRGB has an impact (as a hint) on SID selection and installation. Therefore, it does not qualify for the attribute discard unless specific error handling is provided. 

The authors may wish to treat the information as “redundant”, but then the specifications need to say that.  If the authors want to extend the Attribute discard error handling to another mechanism, then it needs to be stated. 

Sue 

(PS – to carry your truck analogy further, this trucks have rules for containers that are loaded on the flat-bed truck.  If the containers fall outside the exact specifications, it must be clearly describe what  truck is supposed to do). 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 7:14 AM
To: Susan Hares
Cc: stefano previdi; Warren Kumari; Acee Lindem (acee); 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 COMM

​​Hello Sue,

* We were commenting in reference to section 3.1 Label-Index TLV while clearly your comment was based on section 3.2 Originator SRGB TLV

* Yes there can be case you describe that both BGP-LS and this extension advertises SRGB ranges of the node. But at most I would treat this as redundant information. If there is mismatch then I suppose there are bigger issues to be solved and I am not sure if they are actually in scope of this proposal or IDR. 

Along the same lines you could stop BGP-LS RFC and ask what happens if BGP-LS fed information is different then listening to IGP by the controller ? I guess controller must be at min that much smart to handle it, raise the alarms etc ... 

Clearly those are important topics, but I fail to see how they are at all related to BGP.  BGP is just a truck here :). 

Cheers,

R.

 

 

Robert and Stefano: 

Sue   

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

5.1.  Peer-Node-SID

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 2:00 AM
To: Susan Hares
Cc: Warren Kumari; Acee Lindem (acee); 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 COMM

Hi Sue,

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 Jun 2018 13:49:23 +0200

Hi Sue,

Indeed but this is precisely where the crux of the bigger issue resides at.
This is not BGP data even if BGP carries it. Your error example stated:

"My technical problem #1 has to do with what happens if all of these come
in the same BGP packet as combinations of BGP attributes "

and this should be perfectly fine. As long as attribute boundary is where
it needs to be BGP should have no interest to pick into any TLV it contains
or TLV values to check or validate anything.

Unlike in routing related BGP attributes which BGP is to guarantee the
correctness of the information, for essentially opaque data carried here I
don't think BGP should worry about overlapping or inconsistent values even
if they are all packed in the same BGP message.

Thx,
R.

On Thu, Jun 21, 2018 at 1:28 PM, Susan Hares <[email-masked]> wrote:

>    MUST use the 'Attribute Discard' action as per [RFC7606], Section 2 <https://tools.ietf.org/html/rfc7606#section-2>
>
>
>
> If attribute-discard is used, it MUST not be used except in the case of an
> attribute that has no effect on route selection or installation.
>
>
>
> At this point, it is clear that the SRGB has an impact (as a hint) on SID
> selection and installation. Therefore, it does not qualify for the
> attribute discard unless specific error handling is provided.
>
>
>
> The authors may wish to treat the information as “redundant”, but then the
> specifications need to say that.  If the authors want to extend the
> Attribute discard error handling to another mechanism, then it needs to be
> stated.
>
>
>
> Sue
>
>
>
> (PS – to carry your truck analogy further, this trucks have rules for
> containers that are loaded on the flat-bed truck.  If the containers fall
> outside the exact specifications, it must be clearly describe what  truck
> is supposed to do).
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, June 21, 2018 7:14 AM
> *To:* Susan Hares
> *Cc:* stefano previdi; Warren Kumari; Acee Lindem (acee); idr@ietf. org;
> [email-masked]; [email-masked]; The IESG
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 21 Jun 2018 11:57:00 +0000

Hi Sue,

I think this matters on what you consider “route selection” or “installation”. RFC7752 (or other BGP-LS documents) do not talk of any of the BGP-LS attributes affecting the selection or installation of the BGP-LS NLRIs. Hence, IMHO “Attribute discard” is correct for malformed attributes. Furthermore, RFC 7752 lays down the generic rules for identifying what constitutes malformed for BGP-LS attributes – I would rather this becomes the “default” for all BGP-LS and only exceptions need to be called out by individual documents which otherwise can just reference RFC7752.

Coming to BGP Prefix SID scenario, the SRGB TLV (which is the only overlap here between that draft and the BGP-LS SR draft) does not play a role in route selection or installation. The “hint” is actually the Label Index TLV that is actually used by BGP. The TLVs coming via BGP-LS are used by controller likely but not by BGP process for its route selection.

I am also not clear about what is malformed between the SRGB being signalled in a redundant manner? Are you perhaps looking for text that indicates which of these redundant values take precedence if they happen to be different at a given point of time T?

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: 21 June 2018 16:59
To: 'Robert Raszuk' <[email-masked]>
Cc: 'idr@ietf. org' <[email-masked]>; 'stefano previdi' <[email-masked]>; [email-masked]; [email-masked]; 'The IESG' <[email-masked]>; 'Acee Lindem (acee)' <acee=[email-masked]>
Subject: Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

Robert:

   MUST use the 'Attribute Discard' action as per [RFC7606], Section 2<https://tools.ietf.org/html/rfc7606#section-2>

Sue

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 7:14 AM
To: Susan Hares
Cc: stefano previdi; Warren Kumari; Acee Lindem (acee); 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 COMM

​​Hello Sue,

Along the same lines you could stop BGP-LS RFC and ask what happens if BGP-LS fed information is different then listening to IGP by the controller ? I guess controller must be at min that much smart to handle it, raise the alarms etc ....

Cheers,
R.

On Thu, Jun 21, 2018 at 12:45 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Robert and Stefano:

[Robert]: Very interesting comment
[Robert]:  Where do you draw such conclusion from ?
[Robert]: IMO this draft has nothing to do with BGP-LS at all ....

Sue

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

5.1.  Peer-Node-SID

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

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 2:00 AM
To: Susan Hares
Cc: Warren Kumari; Acee Lindem (acee); 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 COMM
Hi Sue,

Very interesting comment .... Where do you draw such conclusion from ?

Best,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 21 Jun 2018 13:19:16 +0000

All,

Actually, the input I’ve gotten is not to change this to a non-transitive attribute since this would essentially revert to RFC 8277 if any BGP router not supporting the attribute is in the path. With the transitive attribute, a single BGP router only represents a break in the SR path where local labels are used.

Thanks,
Acee

From: "Acee Lindem (acee)" <acee=[email-masked]>
Date: Wednesday, June 20, 2018 at 8:17 PM
To: Susan Hares <[email-masked]>, Warren Kumari <[email-masked]>, Robert Raszuk <[email-masked]>
Cc: Acee Lindem <[email-masked]>, IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>
Subject: Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

Hi Sue,

Warren, Robert, Acee:

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: Thu, 21 Jun 2018 15:28:04 +0200

Acee,

RFC8277 has nothing to do with this entire discussion.

Yes you would need to upgrade RRs which is not that bad ;)

But as already stated since you are *only* putting this new attribute in
SAFI 4 there is no "leaking issue" any more and that should be your chosen
line of defence ;)

Best,
R.

On Thu, Jun 21, 2018, 15:19 Acee Lindem (acee) <[email-masked]> wrote:

> All,
>
>
>
> Actually, the input I’ve gotten is not to change this to a non-transitive
> attribute since this would essentially revert to RFC 8277 if any BGP router
> not supporting the attribute is in the path. With the transitive attribute,
> a single BGP router only represents a break in the SR path where local
> labels are used.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *"Acee Lindem (acee)" <acee=[email-masked]>
> *Date: *Wednesday, June 20, 2018 at 8:17 PM
> *To: *Susan Hares <[email-masked]>, Warren Kumari <[email-masked]>,
> Robert Raszuk <[email-masked]>
> *Cc: *Acee Lindem <[email-masked]>, IDR List <[email-masked]>, "
> [email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, The IESG <[email-masked]>
> *Subject: *Re: [Idr] Warren Kumari's No Objection on
> 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 <[email-masked]>
> *Date: *Wednesday, June 20, 2018 at 8:03 PM
> *To: *Warren Kumari <[email-masked]>, Robert Raszuk <[email-masked]>
> *Cc: *"acee=[email-masked]" <acee=[email-masked]>,
> IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, The IESG <[email-masked]>
> *Subject: *RE: [Idr] Warren Kumari's No Objection on
> *Resent-From: *<[email-masked]>
> *Resent-To: *Stefano Previdi <[email-masked]>, <[email-masked]>, Acee
> Lindem <[email-masked]>, Arjun Sreekantiah <[email-masked]>, <
> [email-masked]>
> *Resent-Date: *Wednesday, June 20, 2018 at 8:03 PM
>
>
>
> Warren, Robert, Acee:
>
>
>
> 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?
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> application of spring
> (draft-ietf-spring-segment-routing-central-epe-10.txt).
>
>
>
> 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.
>
>
>
> draft-li-idr-bgp-ls-sr-policy-path-segment,
> draft-li-idr-sr-policy-path-segment-distribution, and others.
>
>
>
>
>
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Jun 2018 11:28:19 -0400

Robert:

You are arguing your option regarding the definition of RFC7606 and what constitutes a “malformed packet” and your opinion on what constitutes conflict between attributes. 

My point is simple.  This is not in the documentation on these additions.   If this is the general opinion, put it in the document and get consensus on the additions. 

Sue 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 7:49 AM
To: Susan Hares
Cc: stefano previdi; Warren Kumari; Acee Lindem (acee); 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 COMM

Hi Sue,

Indeed but this is precisely where the crux of the bigger issue resides at. This is not BGP data even if BGP carries it. Your error example stated: 

"My technical problem #1 has to do with what happens if all of these come in the same BGP packet as combinations of BGP attributes " 

and this should be perfectly fine. As long as attribute boundary is where it needs to be BGP should have no interest to pick into any TLV it contains or TLV values to check or validate anything. 

Unlike in routing related BGP attributes which BGP is to guarantee the correctness of the information, for essentially opaque data carried here I don't think BGP should worry about overlapping or inconsistent values even if they are all packed in the same BGP message. 

Thx,

R.

Robert: 

Sue 

​​Hello Sue,

Cheers,

R.

 

 

Robert and Stefano: 

Sue   

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

5.1.  Peer-Node-SID

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 2:00 AM
To: Susan Hares
Cc: Warren Kumari; Acee Lindem (acee); 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 COMM

Hi Sue,

Best,
R.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Jun 2018 11:54:53 -0400

Ketan: 

See my comments below.  

I am simply looking for text that ties down the details on the error handling in every draft.   There are two cases – malformed and content that is syntactically.   

Thank you for your questions, 

Sue Hares 

From: Ketan Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Thursday, June 21, 2018 7:57 AM
To: Susan Hares; 'Robert Raszuk'
Cc: 'idr@ietf. org'; 'stefano previdi'; [email-masked]; [email-masked]; 'The IESG'; 'Acee Lindem (acee)'
Subject: RE: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

Hi Sue,

>I think this matters on what you consider “route selection” or “installation”. RFC7752 (or other >BGP-LS documents) do not talk of any of the BGP-LS attributes affecting the selection or >installation of the BGP-LS NLRIs. Hence, IMHO “Attribute discard” is correct for malformed >attributes. Furthermore, RFC 7752 lays down the generic rules for identifying what constitutes >malformed for BGP-LS attributes – I would rather this becomes the “default” for all BGP-LS and >only exceptions need to be called out by individual documents which otherwise can just 

> reference RFC7752.

These comments are not for general RFC7752, but the segment routing additions to RFC7752. 

RFC7752 was just indicated for information from an IGPs to BGP for transport.  BGP-LS peers (as my summary stated) were to feed centralized or other offline programs.  

The segment-routing architecture adds features for SID assignment or hinting (detailed below) to the basic RFC7752 architecture for creation of  BGP Peering segments, thus it is influencing routing.  Therefore it no long fits RFC7606 attribute discard language.     

If you want to write a proposed update for the RFC7606 language, please suggest something that is clear.  It can reside in 1 draft.  

>Coming to BGP Prefix SID scenario, the SRGB TLV (which is the only overlap here between that >draft and the BGP-LS SR draft) does not play a role in route selection or installation. The “hint” >is actually the Label Index TLV that is actually used by BGP. The TLVs coming via BGP-LS are >used by controller likely but not by BGP process for its route selection.

The mail below shows the text from section 3.2 of the BGP Prefix SID that indicates BGP-LS is the preferred method.   Perhaps it should go on to detail what happens if both the BGP attribute with the BGP-LS also sets the SID.   

>I am also not clear about what is malformed between the SRGB being signalled in a redundant >manner? Are you perhaps looking for text that indicates which of these redundant values take >precedence if they happen to be different at a given point of time T?

This is precisely my point.  You need to add text to indicate what happens when the redundant attributes occur.  I suggested text for your other documents.    

Thanks,

Ketan

Robert: 

Sue 

​​Hello Sue,

Cheers,

R.

 

 

Robert and Stefano: 

Sue   

===============
>From the draft-ietf-idr-bgp-prefix-sid-25 in section 3.2

5.1.  Peer-Node-SID

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 2:00 AM
To: Susan Hares
Cc: Warren Kumari; Acee Lindem (acee); 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 COMM

Hi Sue,

Best,
R.