Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

From: <[email-masked]>
Date: Wed, 1 Mar 2017 14:39:32 +0000

Hi Stefano,

> From: Stefano Previdi (sprevidi) [mailto:[email-masked]]  > Sent: Tuesday, February 28, 2017 10:16 AM
> 
 > Hi Bruno,
 > 
 > thanks for the review. I integrated all the comments in the new version I'm going to submit
 > very soon.

Thanks.

 > One last comment here below:
 > 
 > > On Feb 22, 2017, at 2:00 PM, [email-masked] wrote:
 > >
 > > 2)      For the document write up, are there any known deployment of draft-ietf-spring-
 > segment-routing-msdc?
 > >
 > >
 > > 3)      § 2.1.  Reference design
 > >
 > > "   o  Each node is its own AS (Node X has AS X)
 > >
 > >       *  For simple and efficient route propagation filtering, Nodes 5,
 > >          6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS,
 > >          Nodes 9 and 10 share the same AS.
 > >
 > >       *  For efficient usage of the scarce 2-byte Private Use AS pool,
 > >          different Tier-3 nodes might share the same AS.
 > >
 > >       *  Without loss of generality, we will simplify these details in
 > >          this document and assume that each node has its own AS."
 > >
 > >
 > > First 2 bullets are contradicting each other's.
 > 
 > 
 > why so ? First bullet refers to tier-1 and tier-2. second bullet refers to tier-3.

Bullet 1: "Each node is its own AS"
Bullet 2: "Nodes 5, 6, 7 and 8 share the same AS"

Looks a priori contradicting.
Now thinking more about this, and given that on your 5-stage clos topology nodes 5, 6, 7 and 8 are not connected to each other's and any flow has no valid reason to cross two of them, I now see what you mean.

I would then propose the following change:
OLD: share the same AS
NEW: use the same AS number

It may look the same, but the two nodes are indeed in different ASes. But they use the same AS number, just like private AS number.

Or may be it's just me ;-)  So up to you.

Thanks,
-- Bruno
 > thanks.
 > s.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 1 Mar 2017 14:53:29 +0000

> On Mar 1, 2017, at 3:39 PM, [email-masked] wrote:
> 
> Hi Stefano,
> 
> Bullet 2: "Nodes 5, 6, 7 and 8 share the same AS”

ok sorry, the indent was such that I was confused.

> NEW: use the same AS number

I agree. I also think that “sharing” has other implications which are not intended here.

> Or may be it's just me ;-)  So up to you.

no, it’s me too ;-)

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 1 Mar 2017 15:44:35 +0000

> On Feb 28, 2017, at 8:29 PM, Anoop Ghanwani <[email-masked]> wrote:
> 
> I support publication of the document as an informational RFC.
> 
> Below are my comments.
> 
> Thanks,
> Anoop
> 
> ==
> 
> - pg 5, line 1
>   What is the criteria that allow sharing the AS number?  Is there a reference?

we changed this to “use the same AS”. As explained in 4.3, using the same AS brings the update loop prevention mechanism so facilitate filtering and propagation.

> - pg 6
>   "This means that every new connection will be established 
>    obliviously (memory- less) with regards to the paths chosen 
>     before, or chosen by other nodes."
>   I am not sure what "chosen by other nodes" adds.  I think it 
>   can be removed. 

It refers to the “obliviousness” extended also to the choices that other nodes of the network could have made.

> - pg 7
>   "local label 1600x" -> "local label (16000 + x).
>   Also because of the way loopbacks are assigned, does this mean that the number nodes that this scheme can handle is 512?  May be good to mention why this is considered a good number.

the example assumes loopbacks assigned from 192.0.2/24. It gives you 255 host addresses. This is of course just illustrative.

> - pg 11
>   "BGP Prefix Segment 16011 then directs the packet down to Node11 along the path (Node5, Node9, Node11)."
>   I think it would be worth mentioning that node 9 need not appear in this path.  In general, because of the nature of clos topologies, there is no need to have intermediate nodes between the spine and the ToR on the way down.  (If there is, it would be good to know why.)

maybe I’m missing your point but the example is baed on the illustrative topology where 9 in the shortest path but you don’t need to specify 9 in the segment list. This is base of SR explained in the architecture draft. 

> Editorial

I fixed the remaining editorial nits.

Thanks.

s.

> 
> - some inconsistencies throughout.  would be good to make them consistent.
>   Node1 and Node2 vs Nodes 1 and 2 vs "Node1" and "Node2"
>   data center, data-center, DC
> 
> - Spell out SRGB and AIGP at first use.
> 
> - pg 1
>   "use-case use-cases" -> use-cases
> 
> - pg 5
>   "via BGP session" -> "via a BGP session."  (missing 'a' and period.)
>   "address of it's loopback" -> "address of its loopback"
>   "per-flow ECMP that does not" -> "per-flow ECMP does not"
>   "placed on one path over others" ->  "placed on one path over others."  (missing period)
>   " implements oblivious" -> "implements an oblivious"
> 
> - pg 6
>   "Absence of path visibility" -> "The absence of path visibility"
>   
> - pg 7
>   "Figure 2 zooms on" -> "Figure 2 zooms in on"
> 
> - pg 8 
>   "an nondeterministic label" -> "a non-deterministic label"
> 
> - pg 9
>   "Referring to Figure 1Referring to Figure 1" -> "Referring to Figure 1"
> 
> - pg 11
>   "if Node7 does not support" -> "even though Node7 does not support"
> 
> - p12
>   Missing a period at the end of the first and second items in Sec 4.3.
>   "Attribute adverting" -> "Attribute advertising"
> 
> - pg 14
>   "let us illustrate this assuming" -> "let us illustrate this concept assuming"
>   "flow to Z" -> "flow to HostZ"
>   "assuming A is made aware" -> "assuming HostA is made aware"
>   
> - pg 15
>   "the latter one" -> "the last one"
> 
> - pg 16
>   "monitoring network elements health" -> "monitoring network elements' health"
>   "inSection 7.2" -> "in Section 7.2"
>   "BGP Labelled Unicast" -> "BGP Labeled Unicast"  (also on pg 17)
> 
> - pg 18
>   "thanks to PHP" -> "because of PHP"
>   "Internet- scale" -> "Internet-scale"  (extra space)
>   "go-to-the- Internet" -> "go-to-the-Internet"
>   " do not recommend to use" -> "do not recommend using"
>   "operation viewpoint" -> "operational viewpoint"
> 
> - pg 19
>   "allows to construct" -> "allows us to construct"
>   "Spine5 and Spine 8" -> Node5 and Node8
>   "(e.g. ToR1's SRGB is [1000, 1999], ToR2's SRGB is [2000, 2999]...)." ->
>   "(e.g. ToR1's SRGB is [1000, 1999], ToR2's SRGB is [2000, 2999], ...)." ->
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 1 Mar 2017 08:48:16 -0800

Thanks for the responses.

On Wed, Mar 1, 2017 at 7:44 AM, Stefano Previdi (sprevidi) <
[email-masked]> wrote:

> we changed this to “use the same AS”. As explained in 4.3, using the same
> AS brings the update loop prevention mechanism so facilitate filtering and
> propagation.
>
>
I think your response is about the spine/leaf nodes.  My comment is about
the ToR nodes.

> >   Also because of the way loopbacks are assigned, does this mean that
> the number nodes that this scheme can handle is 512?  May be good to
> mention why this is considered a good number.
>
>
> the example assumes loopbacks assigned from 192.0.2/24. It gives you 255
> host addresses. This is of course just illustrative.
>

It may be good to mention explicitly that the numbers used are
illustrative.  I did not get that impression when reading the draft.

> >   I think it would be worth mentioning that node 9 need not appear in
> this path.  In general, because of the nature of clos topologies, there is
> no need to have intermediate nodes between the spine and the ToR on the way
> down.  (If there is, it would be good to know why.)
>
>
> maybe I’m missing your point but the example is baed on the illustrative
> topology where 9 in the shortest path but you don’t need to specify 9 in
> the segment list. This is base of SR explained in the architecture draft.
>
>
Yes, that is indeed my point. I think it would be better to remove it and
have a statement that says why it doesn't appear pointing to the arch doc.

Thanks,
Anoop

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 1 Mar 2017 17:21:32 +0000

> On Mar 1, 2017, at 5:48 PM, Anoop Ghanwani <[email-masked]> wrote:
> 
> On Wed, Mar 1, 2017 at 7:44 AM, Stefano Previdi (sprevidi) <[email-masked]> wrote:
> 
> I think your response is about the spine/leaf nodes.  My comment is about the ToR nodes.

the same applies. The rules and guidelines related to bgp deployment and AS numbering are the same.

> It may be good to mention explicitly that the numbers used are illustrative.  I did not get that impression when reading the draft. 
> 
> 
> > - pg 11
> Yes, that is indeed my point. I think it would be better to remove it and have a statement that says why it doesn't appear pointing to the arch doc.

I will add a reference but remember that this is a use case draft. For the mechanics of SR you always have to reference to the architecture draft (in fact, it is referenced in many places in the draft).

Thanks.
s.

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 1 Mar 2017 10:27:14 -0800

On Wed, Mar 1, 2017 at 9:21 AM, Stefano Previdi (sprevidi) <
[email-masked]> wrote:

> > we changed this to “use the same AS”. As explained in 4.3, using the
> same AS brings the update loop prevention mechanism so facilitate filtering
> and propagation.
> >
> >
In this draft, we have:

 For efficient usage of the scarce 2-byte Private Use AS pool,
         different Tier-3 nodes might share the same AS.

In RFC 7938, we have:

 A unique ASN is allocated to every Tier 3 device (e.g., ToR) in
      this topology.

What I am asking for is clarification on how different Tier-3 nodes might
share the same AS number.

Your comment above (referencing 4.3) is talking about a different scheme
(iBGP) in which case I am assuming all nodes (spine, leaf, tor) share the
same AS number.

Thanks,
Anoop

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 3 Mar 2017 14:38:22 +0000

> On Mar 1, 2017, at 7:27 PM, Anoop Ghanwani <[email-masked]> wrote:
> 
> On Wed, Mar 1, 2017 at 9:21 AM, Stefano Previdi (sprevidi) <[email-masked]> wrote:
> 
> What I am asking for is clarification on how different Tier-3 nodes might share the same AS number.

“share” is the wrong term and we agreed to change it.

Btw, RFC7938 section 5.2.2. "Private Use ASNs” says:

   The original range of Private Use ASNs [RFC6996] limited operators to
   1023 unique ASNs.  Since it is quite likely that the number of
   network devices may exceed this number, a workaround is required.
   One approach is to re-use the ASNs assigned to the Tier 3 devices
   across different clusters.  For example, Private Use ASNs 65001,
   65002 ... 65032 could be used within every individual cluster and
   assigned to Tier 3 devices.

By “share” we intended to “use” the same number in different clusters.

s.

> 
> Your comment above (referencing 4.3) is talking about a different scheme (iBGP) in which case I am assuming all nodes (spine, leaf, tor) share the same AS number.
> 
> Thanks,
> Anoop

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 3 Mar 2017 12:25:57 -0800

> By “share” we intended to “use” the same number in different clusters.

Thanks.  That address all the comments I had.

Anoop

---

From: <[email-masked]>
Date: Wed, 8 Mar 2017 14:25:23 +0000

Hi Stefano,

Thanks for the updated version.
-03 address all my comments except two. Please see below:

---
> §7.3 seems very similar to me than §7.2. e.g.
>
> §7.2:
> "  One particularly interesting instance of performance-aware routing is
>   dynamic fault-avoidance.  If some links or devices in the network
>   start discarding packets due to a fault, the end-hosts could detect
>   the path(s) being affected and steer their flows away from the
>   problem spot.  Similar logic applies to failure cases where packets
>   get completely black-holed, e.g. when a link goes down."
>
> §7.3
> "if in the topology depicted on
>   Figure 1 a link between spine switch Node5 and leaf node Node9 fails,
>   HostA may exclude the segment corresponding to Node5 from the prefix
>   matching the servers under Tier-2 devices Node9."
>
> May be §7.3 should be removed or rephrased to better differentiate its content compared to §7.2

You have removed the title of section 7.3 but not changed the text. Hence we still have the same similarities.
In addition, with the change, the text in section 7.2 is now self-referencing section 7.2:
"Until then, the existing flows may recover using local detection of the path issues, as described in Section 7.2<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-03#section-7.2>. »

Bottom line, merging both paragraphs is a valid idea but some editorial work is needed to merge the text.

---
> "Common SRGB"
> The call for a common SRGB is duplicated in section 4.1, 4.2 and 8.1. Please remove the duplicated text. (e.g. moving all related text to 8.1)

I'm not seeing this point really addressed. Extract from -03:

§4.1:
In this document, we make the network design decision to assume that
   all the nodes are allocated the same SRGB (Segment Routing Global
  Block), e.g. [16000, 23999] This is important to fulfill the
   recommendation for operational simplification as explained in
   [I-D.ietf-spring-segment-routing<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-03#ref-I-D.ietf-spring-segment-routing>].

   Note well that the use of a common SRGB in all nodes is not a
   requirement, one could use a different SRGB at every node.  However,
   this would make the operation of the DC fabric more complex as the
   label allocated to the loopback of a remote node is then different at
   every node.  This also may increase the complexity of the centralized
   controller.  More on the SRGB allocation scheme is described in
   Section 9<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-03#section-9>.

§4.2.5:
   When deployed together with a homogeneous SRGB (same SRGB across the
   fabric), the operator incrementally enjoys the global prefix segment
   benefits as the deployment progresses through the fabric.

§8.1

   A key element of the operational simplicity is the deployment of the
   design with a single and consistent SRGB across the DC fabric.

   At every node in the fabric, the same label is associated to a given
   BGP-Prefix-SID and hence a notion of global prefix segment arises.

[...]
All of this unnecessary complexity is eliminated if a
   single consistent SRGB is utilized across the fabric.

§9.  Preferred SRGB Allocation
The whole section (1 page) is about this.

So I still believe the point is still replicated and spread through the whole document, while it could be made a single time.
I would propose the below change

§4.1:
OLD
In this document, we make the network design decision to assume that
   all the nodes are allocated the same SRGB (Segment Routing Global
  Block), e.g. [16000, 23999] This is important to fulfill the
   recommendation for operational simplification as explained in
   [I-D.ietf-spring-segment-routing<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-03#ref-I-D.ietf-spring-segment-routing>].

   Note well that the use of a common SRGB in all nodes is not a
   requirement, one could use a different SRGB at every node.  However,
   this would make the operation of the DC fabric more complex as the
   label allocated to the loopback of a remote node is then different at
   every node.  This also may increase the complexity of the centralized
   controller.  More on the SRGB allocation scheme is described in
   Section 9<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-03#section-9>.

NEW
In this document, we make the network design decision to assume that
   all the nodes are allocated the same SRGB (Segment Routing Global
  Block), e.g. [16000, 23999]. This provides
operational simplification as explained in Section 9<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-03#section-9>, but this is not a requirement.

§8.1
OLD:
   A key element of the operational simplicity is the deployment of the
   design with a single and consistent SRGB across the DC fabric.

   At every node in the fabric, the same label is associated to a given
   BGP-Prefix-SID and hence a notion of global prefix segment arises.

   When a controller programs HostA to send traffic to HostZ via the
   normally available BGP ECMP paths, the controller uses label 16011
   associated with the ToR node connected to the HostZ.  The controller
   does not need to pick the label based on the ToR that the source host
   is connected to.

   In a classic BGP Labeled Unicast design applied to the DC fabric
   illustrated in Figure 1, the ToR Node1 connected to HostA would most
   likely allocate a different label for 192.0.2.11/32 than the one
   allocated by ToR Node2.  As a consequence, the controller would need
   to adapt the SR policy to each host, based on the ToR node that they
   are connected to.  This adds state maintenance and synchronization
   problems.  All of this unnecessary complexity is eliminated if a
   single consistent SRGB is utilized across the fabric.

NEW:
Provided the same SRGB is configured on all nodes, all nodes use the same MPLS label for a given IP prefix. This is simpler from an operation standpoint, as discussed in Section9.
---
As a side note, calling from network operator to use the same SRGB is one thing. But in a multi-vendor/plateform network, it would require all vendors/plateform to agree on a common range or to allow the configurable of the SRGB over a large enough common range. Also this is nothing specific to BGP SR/MSDC but more general to MPLS SR, hence would be better described in the architecture document. You do reference it "This is important to fulfill the recommendation for operational simplification as explained in [I-D.ietf-spring-segment-routing<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-03#ref-I-D.ietf-spring-segment-routing>]." but in this case there is no need to duplicate the discussion again in this document.

Thanks,
Regards,
-- Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 22, 2017 2:00 PM
To: [email-masked]
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

Please find below some additional points

1)      "Abstract

   This document describes the motivation and benefits for applying
   segment routing in the data-center.  It describes the design to
   deploy segment routing in the data-center, for both the MPLS and IPv6
   dataplanes. »

It looks to me that this document is limited to BGP-based large-scale data-center  (DC) design described in [RFC7938].
So may be
:s/ the data-center./ BGP-based large-scale data-center.
:s/ in the data-center,/ in those data-center,

2)      For the document write up, are there any known deployment of draft-ietf-spring-segment-routing-msdc?

First 2 bullets are contradicting each other's.
Please update/rephrase as needed.

4)         [I-D.ietf-idr-bgp-prefix-sid] could be seen as a normative document. IDR WG is also initiating the WG last call, hence both document could progress together.

Thanks,
Regards,
Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, February 21, 2017 4:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

Hi authors,

As the document shepherd, I have reviewed the document and have the following comments.

Thanks,
Regards,
Bruno

======================================
Major comment:
======================================
- Section 12 (Manageability) is empty ("TBD")
- Section 13 (Security) is empty ("TBD")

======================================
Minor Comment:
======================================
- Section 11 (IANA) is empty ("TBD")
- I-D.ietf-spring-segment-routing should probably be a normative reference

---
§1
Term "middle stage" is used twice but is not defined. May be replacing it with the terms Tier-x which are defined.

---
§4.1

---
"all the nodes are allocated the same SRGB"
Please expand SRGB on first use, and provides a reference ([I-D.ietf-spring-segment-routing])

---
§4.2.1
"BGP-Prefix Attribute"
The name of the BGP attribute is "BGP Prefix-SID" and the TLV hosting the index is "Label-Index"

---
§4.2.1

"Then, Node10 sends the following eBGP3107 update to Node7:

   . NLRI:  192.0.2.11/32
   . Label: 16011"

As per RFC 3107, the NLRI is both the IP prefix and the label. Hence, proposed
:s/NLRI/Prefix
or :s/NLRI/IP Prefix

(RFC 3107 uses the term "Prefix" but IMHO it implies "IP Prefix")

---
§4.2.1

OLD: it should allocate the label LOCAL-SRGB (16000) + "index" 11 (hence 16011)
"LOCAL-SRGB" is undefined. I would suggest
NEW: it should allocate the label from its own SRGB block, offset by the index received in the BGP Prefix-SID attribute. (16000+11 hence 16011)

---
§7.3 seems very similar to me than §7.2. e.g.

§7.2:
"  One particularly interesting instance of performance-aware routing is
   dynamic fault-avoidance.  If some links or devices in the network
   start discarding packets due to a fault, the end-hosts could detect
   the path(s) being affected and steer their flows away from the
   problem spot.  Similar logic applies to failure cases where packets
   get completely black-holed, e.g. when a link goes down."

§7.3
"if in the topology depicted on
   Figure 1 a link between spine switch Node5 and leaf node Node9 fails,
   HostA may exclude the segment corresponding to Node5 from the prefix
   matching the servers under Tier-2 devices Node9."

May be §7.3 should be removed or rephrased to better differentiate its content compared to §7.2

---
§8.1
"The Prefix Segment is a lightweight extension to BGP Labelled Unicast"
"Prefix Segment" is loosely (un)defined. draft-ietf-idr-bgp-prefix-sid-04 uses the term "BGP-Prefix-SID" or "BGP-Prefix-SID Attribute"

Please make a consistent use of the right term in the whole document.

---
"Common SRGB"
The call for a common SRGB is duplicated in section 4.1, 4.2 and 8.1. Please remove the duplicated text. (e.g. moving all related text to 8.1)

---
"§8 Additional Benefits
[...]
§8.4 Incremental Deployments
As explained in Section 4.2.5, this design can be deployed incrementally."

As the incremental benefit is already discussed at length in §4.2.5 there is no need to create a one line section 8.4 as this is not an _additional_ benefit.

So either removing §8.4 or moving §4.2.5 to 8.4.

---
§10
:/BGP Prefix SID attribute/BGP Prefix-SID attribute

Plus may be adding the reference to the IDR document.

:/ORIGINATOR_SRGB TLV/Originator SRGB TLV

---
§10
"   Specifically, the ORIGINATOR_SRGB TLV in the BGP Prefix SID signals
   the SRGB of the switch that originated the BGP Prefix Segment.

   This allows to determine the local label allocated by any switch for
   any BGP Prefix Segment, despite the lack of a consistent unique SRGB
   in the domain."

The above text is not clear enough for me to understand why and how the ORIGINATOR_SRGB is used.
I find the text in the IDR draft a little more clear. "It is used to build SRTE policies when different
   SRGB's are used in the fabric ([I-D.ietf-spring-segment-routing-msdc])." Which is a pity given that the IDR draft refers to the SPRING draft for the reason and the use.

So please rephrase/elaborate.

On a side note, I would not call this node a "switch" which for me is a layer 2 devices (e.g. Ethernet). I'd rather use the term router or LSR (or (egress) LER)

And I fail see the relation with the title "Alternative options"

======================================
Nits:
======================================
In figure 1 and 2, Node10 diagram outrun the box. :s/ 10  |/10  |

---
"In other words, per-flow ECMP that does not perform efficiently when flow life-time distribution is heavy-tailed."

may be :s/that does/does

---
"Referring to Figure 1Referring to Figure 1"

duplicated.

---
"In the MPLS case, we do not recommend to use different SRGBs at each node."
May be avoiding (double) negation when positive statement is meant . e.g. NEW: In the MPLS case, we do recommend to use same SRGBs at each node

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, February 21, 2017 10:51 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02

Hello Working Group,

This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-msdc-02 [1].

Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *7th of March*.

Note that this is *not only* a call for comments on the document; it is also a call for support (or not) to publish this document as an Informational RFC.

We have already polled for IPR knowledge on this document and all Authors have replied.

No IPR has been disclosed [2].

Thank you

M&B

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02
[2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-msdc

Thank you.

Thank you.

Thank you.

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 8 Mar 2017 12:59:11 -0800

Hi Stefano,

Just noticed, pg 7 still says 1600x, when I think it should say (16000 + x).

Anoop