Re: [RTG-DIR] [spring] Review of draft-ietf-spring-segment-routing-msdc-03

[Robert Raszuk <[e-mail]>]

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

> 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.
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>