Subject: [spring] Review of draft-ietf-spring-segment-routing-msdc-03

From: Susan Hares <[email-masked]>
Date: Mon, 06 Mar 2017 08:25:29 -0800

Reviewer: Susan Hares
Review result: Has Issues

The RTG-DIR has the categories:  minor concerns or major concerns
regarding "issues", I wil differentiate my issues by this quality. 
I also have editorial nits regardign under specified text. 

Major concerns: 
1) The security section is not sufficient for any review by the
Security area 

This draft depends on IDR WG draft (ietf-idr-bgp-prefix-sid) that
defines the BGP Segment attribute.  If this attribute is used with
IPv6, this simply gives more infromation about a link to a next. 
However, the combination of this information with the information
passed using draft-ietf-idr-bgpls-segment-routing-epe-09 that utilizes
BGP to pass BGP topologies in BGP - requires a better security
section.  BGP-LS was described to be an "information gathering"
function handled by a few routers on the edge of the network to obtain
link-state topology information.  The BGP peers would carry this
information in a separate informational stream.  With this constraint,
it was approved by the IESG.   
draft-ietf-idr-bgpls-segment-routing-epe  expands the initial concept
of BGP-LS from "information gathering" to a full-routing scheme of BGP
within BGP for data centers and for data center interconnection to the
network.   This extension takes it out of the approved range of the
BGP-LS.  Therefore, the security sections in both the IDR WG drafts
and this draft need to describe the new threat scenarios and describe
threat mitigation strategies for deployments.  

In addition, the information by BGP-LS
(draft-ietf-idr-bgpls-segment-routing-epe) or in draft-ietf-bgp-sid
may have privacy issues - so these need to be described the security
section. 

2) through-out the text you use words such as "ebgp3107" or BGP 3107
updates"

This phrase is inaccurate.  The base RFC3107 support will not provide
BGP-Prefix support (as supported in bgp-idr-bgp-prefix.   Some texts
goes on to clarify the addition of the BGP SID Prefix attribute.  It
would be better to invent a new phrase or term.  

In section 8.1, the authors state:
"The Prefix Segement is a lightweight extension to the BGP Labelled
Unicast".  As noted in my #1 major concern, this "hand-waving"
description either needs to be refined to be accurate.  If the MPLS
usage only uses the BGP-Prefix label and does not extend to the
Egress, it is simplier.  However, it is not clear that is what section
8.1 is about.   If 8.1 includes the
draft-ietf-idr-bgpls-segment-routing-epe, then BGP-LS addition does
have a number of prefixes and rules.   The trade-off between BGP-LS +
BGP-LS SID (draft-ietf-idr-bgp-sid) handling + BGP LS egress peer
engineering draft (draft-ietf-idr-bgp-segment-routing-epe) and a
signalling protocol is more complex than the hand-wave.  It may be the
right choice based on current implementations and management issues,
but these need to be laid specifically. 

3) Why are you defining 2-byte Private Use AS when there are plenty of
4-Byte Private Use AS (p. 5). 

This usage increases the confusion regarding 2-byte/4-byte ASN.  IDR
specifically worked on 4 byte ASN. 

Minor concerns  
1) It is not clear what happens in section 4.2.2 and figure 3-5

What happens if the traffic goes to node 3 instead of node 4 on the
ECMP path? 
What happens if the traffic goes to node 8 instead of node 7 on the
ECMP Path? 

Is there something missing in the stroy? 

2) section 4.3 - IBGP Labeled Unicast. 

The phrase "iBGP3107 reflection with nhop-self" needs to be explicitly
spelled out as IBGP Route-Reflection with next-hop self.  If that is
not what the authors mean, then it needs to be further spelled out. 
It is unclear where the central IBGP nodes are that share fully the
information learned from the three clusters. (nodes:5-8 cluster 1,
nodes 3-4 cluster 2, nodes 9-10 cluster 3).  

This section has hints of a solution, but it is miss a great deal. 
Please upgrade to specific solution.  A diagram might help. 

3) Load Sharing hints (Section 7.1) 

Elephant flow and mice flows are good descriptions.  Flowlets and VL2
should either warrant a 1 sentence explanation that actually describes
these features in a 22 page draft, or be removed.  

4)  The lack of a manageability or operations section (TBD in version
-02) - concerns me.  The operational issues may be well known to the
data centers and devices manufacturers who have implement this
specification, but this is an interoperability specification for IETF.
 Some manageabilty comments should be included or a BCP pointed to. 

Editorial issues: 

#1 - The following 4 abbrevitions need to be initially expanded when
first used:  CLOs (p.3),  SRGB(p.6), flowlets (p. 14), and VL2 (p.
14). 

#2 - page 7, section 4.2 last paragraph 
Old/: assuming the IP Addresses, AS and label-index allocation
previously described, the"
New/: assuming the IP address with the AS and label-index allocation
previously described, the" 
[Comma is optional]

#3 - page 14, section 7.1 paragraph 4,  /(e.g. spine switch Node1)/  -
by the diagram it should be node 5-8 or an error.  Please check the
number 

#4 - page 17, section 8.2 paragraph 2. 

Old/
This is easily accomplished by encapsulating the trafffic either 
directly at the host or the source ToR node by pushing the BGP-
Prefix-SID of the destination ToR for intra-DC traffic, or border 
node for inter-DC or DC-to-outside-world traffic./

New/
This is easily accomplished by encapsulating the trafffic either 
directly at the host or the source ToR node  by pushing  the BGP-
Prefix-SID of the destination ToR for intra-DC traffic, or
the BGP-Prefix-SID for the the border node for inter-DC or
DC-to-outside-world traffic./
 
If this is not the correct logic, then you can reword this further. 
I read it 4 or 5 times. 

#5 - Adding a diagram to section 4.3 might help your description.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 6 Mar 2017 17:56:06 +0100

Hi Sue,

Please kindly allow me to clarify two points here ...

Point 1:

You said:

"The BGP peers would carry this information in a separate informational
stream.  With this constraint,
it was approved by the IESG.
​"

​However looking at RFC7752 at most it lightly says three times that
dedicated RRs may be used to disseminate collected information. ​So while I
do recall how this extension was "sold" I am afraid in no way this has any
bearing on how it will be used now or in the future deployments.

​Point 2:

In your comment I see major concerns with security .. Well let's keep in
mind that this proposal is specific to MSDC. As such by design it is all
under single administrative domain .. hence I think non of the security
points really apply.

Cheers,
R.

On Mon, Mar 6, 2017 at 5:25 PM, Susan Hares <[email-masked]> wrote:

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 7 Mar 2017 11:20:54 +0000

Hi Sue,

thanks for the review. Some comments below.

> On Mar 6, 2017, at 5:25 PM, Susan Hares <[email-masked]> wrote:
> 
> Reviewer: Susan Hares

well, we have now different models that have been deployed and assuming that bgp-ls uses a separate stream is not accurate if we look what’s in the industry.

However, I take your point and I agree that more text in the security section is required in order to emphasize that the model the draft addresses is internal (DC and interconnected DC over a same-administration network).

> network.

EPE defines a model where the topology of the peering point (not the network, just the peering point) is advertised to an internal server.

>   This extension takes it out of the approved range of the
> BGP-LS.

I don’t know what is the “approved range”. To me, bgp-ls carries topology information. We started with lsdb, then extended to mpls-lsp's, ip tunnels, peering points, and more will come.

The security of bgp-ls doesn’t change. It’s the boundary of the network where bgp-ls is applied that matters.

>  Therefore, the security sections in both the IDR WG drafts

I will add more text about the information originated by bgp-ls (or the bgp prefix sid) and how it is intended to be consumed internally to a domain.

> may have privacy issues - so these need to be described the security

same here. I will emphasize the deployment model and the security boundaries.

> would be better to invent a new phrase or term.

I’ll check this out.

> Egress, it is simplier.

the BGP Prefix SID Attribute is just an extension to a 3107 update.

>  However, it is not clear that is what section
> signalling protocol is more complex than the hand-wave.

Not sure I understand your point but to me the statement: 
“The Prefix Segement is a lightweight extension to the BGP Labelled Unicast”
is correct because the prefix-sid is really just a new attribute. Here we’re just talking protocol extension.

The interaction and combination between prefix-sid and epe is a deployment and operational model that (we agreed above) requires more explanation in terms of security.

>  It may be the

well, we just want to be sure we address the worse case where you only have 2 octets.

> specifically worked on 4 byte ASN. 

yes but in order to be aligned with 7938 we also take into account 2 octet ASN and the re-usability of these numbers.

> Is there something missing in the stroy? 

nope. This is plain segment routing. As explained in the draft, assuming that you use the same SRGB (as recommended) a node is known through the same sid value all along the network so ecmp becomes trivial.

> spelled out as IBGP Route-Reflection with next-hop self.

ok

>  If that is

yes. I’ll check this out. In short (you certainly figured it out) it’s about using iBGP session where each node acts as a RR so to propagate to other iBGP peers (this is what "iBGP reflection” refers to). I agree, it’s probably a bit too cryptic.

> these features in a 22 page draft, or be removed.  

We have a reference for them but will add more text.

> Some manageabilty comments should be included or a BCP pointed to. 

ack.

> Editorial issues: 

I’ll go through all below and update the draft asap.

Thanks.
s.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 09:30:04 -0500

Stefano: 

Summary:  As I have often said, I believe in helping BGP meet the needs of operators (DC or BGP), and this includes BGP-LS.  If your transition from OSPF/IS-IS LSPs to BGP in BGP to MPLS is to meet operator needs - great.   Just document the security concern issues (new types of information, privacy issues on sending link info). 

My "concern" comments on BGP-LS only focus on 3 things: 
1) Upgrade your security section to deal with issues regarding new types of information and privacy issues on sending link-information (inside DC or DCI) 
 1 to 3 paragraphs should be sufficient.  I will suggest text. 
2) Be precise in your RFC3107 terminology - 
3)  Encourage the use of 4-byte Private AS, and treat 2-byte Private ASes as a legacy issues.    

All response below boil down to this summary.   Editorial Nits are your choice to adopt/not-adopt.  IETF LC and IESG review will provide you lots of feedback on editorial nits.  

Sue 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
Sent: Tuesday, March 7, 2017 6:21 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] [spring] Review of draft-ietf-spring-segment-routing-msdc-03

Hi Sue,

> it was approved by the IESG.   

Stefano: well, we have now different models that have been deployed and assuming that bgp-ls uses a separate stream is not accurate if we look what’s in the industry.  However, I take your point and I agree that more text in the security section is required in order to emphasize that the model the draft addresses is internal (DC and interconnected DC over a same-administration network).

Sue:  Good.  I look forward to your security section.  Please note to clearly state (or reference) whether the interconnected DC is over physically isolated or logically isolated on shared infrastructure.   Please indicated any privacy issues. 

> within BGP for data centers and for data center interconnection to the 

Stefano: EPE defines a model where the topology of the peering point (not the network, just the peering point) is advertised to an internal server.
Yes, but the topology of peering point may be considered information that falls under the "privacy" issues in security.   The security considerations should indicate whether you assume the peering point is physically isolated or shared infrastructure.  If shared infrastructure, are you requiring TCP-AO to e securie. 

>   This extension takes it out of the approved range of the BGP-LS.
Stefano:  I don’t know what is the “approved range”. To me, bgp-ls carries topology information. We started with lsdb, then extended to mpls-lsp's, ip tunnels, peering points, and more will come. The security of bgp-ls doesn’t change. It’s the boundary of the network where bgp-ls is applied that matters.

Sue: The focus is the security in this sentence.  The security case in the original BGP-LS was the transportation of the BGP-LS information (OSPF/ISIS topologies) on a separate network.  If you have changed due to customer needs/wants, fine.  Just provide the security case in the 3 paragraphs.  

>  Therefore, the security sections in both the IDR WG drafts and this 
> draft need to describe the new threat scenarios and describe threat 
> mitigation strategies for deployments.

Stefano: I will add more text about the information originated by bgp-ls (or the bgp prefix sid) and how it is intended to be consumed internally to a domain.
Sue: Great! 

> In addition, the information by BGP-LS (draft-ietf-idr-bgpls-segment-routing-epe) or in draft-ietf-bgp-sid 
> may have privacy issues - so these need to be described the security  section.

Stefano: same here. I will emphasize the deployment model and the security boundaries.
Sue: Wonderful! 

> would be better to invent a new phrase or term.

Stefano: I’ll check this out.
Sue: Great, just be a bit more precise in the test to aid future implementations. 

> usage only uses the BGP-Prefix label and does not extend to the 

Stefano: the BGP Prefix SID Attribute is just an extension to a 3107 update.
Sue: BGP Prefix is an BGP attribute that goes along with BGP-lS BGP topology information in the whole solution.  
The easiest thing is to just leave out the "evaluation".
 Alternatively, make the evaluation more precise by including more description.   

> signalling protocol is more complex than the hand-wave.

Stefano: Not sure I understand your point but to me the statement:  “The Prefix Segment is a lightweight extension to the BGP Labelled Unicast” is correct because the prefix-sid is really just a new attribute. Here we’re just talking protocol extension. The interaction and combination between prefix-sid and epe is a deployment and operational model that (we agreed above) requires more explanation in terms of security.

Sue: My purpose here is to simply point out where your RFC3107 and new BGP Prefix SID Text too loose.  
If you want to say that "BGP Prefix SID is a new BGP attribute and it along with RFC3107 NLRI provides the internal-DC without the DCI-interconnection" - just state that.   
This is the purpose of the sentence below: 
> It may be the  right choice based on current implementations and management issues,  but these need to be laid specifically.

> 4-Byte Private Use AS (p. 5).
Stefano: well, we just want to be sure we address the worse case where you only have 2 octets.
Sue:  It would be better to encourage the general use of 4-Byte ASes which have enough space to give most data center's one AS per box, and then deal with the worst case issues. 

> 
> This usage increases the confusion regarding 2-byte/4-byte ASN.  IDR  specifically worked on 4 byte ASN.

Stefano: yes but in order to be aligned with 7938 we also take into account 2 octet ASN and the re-usability of these numbers.
Sue: Wonderful, just add the 4 byte AS.  

ok

ack.

Thanks.
s.

> Prefix-SID of the destination ToR for intra-DC traffic, or border node 
> for inter-DC or DC-to-outside-world traffic./
> 
> New/
> Prefix-SID of the destination ToR for intra-DC traffic, or the 
> BGP-Prefix-SID for the the border node for inter-DC or

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 7 Mar 2017 15:30:35 +0000

> On Mar 7, 2017, at 3:30 PM, Susan Hares <[email-masked]> wrote:
> 
> Stefano: 
> 

agreed and will do so. Note also that EPE is just one piece of the picture described in the draft.

> 2) Be precise in your RFC3107 terminology - 

agreed. I added some text explaining what we intend by 3107 ebgp and ibgp.

> 3)  Encourage the use of 4-byte Private AS, and treat 2-byte Private ASes as a legacy issues. 

ok, will do so.

> All response below boil down to this summary.   Editorial Nits are your choice to adopt/not-adopt.  IETF LC and IESG review will provide you lots of feedback on editorial nits.

yup, I applied all of them.

Thanks.
s.