Subject: [spring] A review of draft-ietf-spring-sr-for-enhanced-vpn-01

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 15 Jan 2022 18:15:30 -0000

Hi,

I've been on a roll reading and reviewing network slicing and enhanced
VPN drafts, so I thought I'd get round to this one. A bit surprised to
find it has expired - you probably want to post something to keep it
alive.

Seems most drafts I review these days I end up writing a comments that
goes...
Before this document gets published as an RFC you will need to cut down
the names on the front page to 5 or fewer. It is usually easiest to do
this early and in your own time rather than being forced to do it or
having the document held up while you sort it out.

Otherwise, this draft seems fairly much ready, and only blocked on the
completion of the normative references (see note below). I wonder, 
however, whether some of the informative references are a little
immature (early individual drafts) to serve as example/possible protocol
solutions.

Here are a few points for you to consider.

Thanks,
Adrian

== Minor Points ==

I have some scaling concerns about the mechanism defined here. If you
imagine running 1000 VTNs in the network, and if each link is 
advertising a SID, wouldn't you end up needing to advertise 1000 SIDs
for each link?

This is made clear in 2.1

   For one IGP link, multiple Adj-SIDs are allocated, each of which is
   associated with a VTN that link participates in, and represents a
   subset of the link resources allocated to the VTN.  For one IGP node,
   multiple prefix-SIDs are allocated, each of which is associated with
   a VTN which the node participates in, and identifies the set of
   network resources allocated to the VTN on network nodes which
   participate in the VTN.

While section 2.4 makes a stab at identifying the scaling concerns, it
seems to miss the main point that the IGP may be quite fragile as the
number of VTNs increases.

Note that similar issues came up in IGP-TE work. The solution there was
to advertise just once for the link, but to list the TE attributes on
the advertisement. I think you could do the same here so that a link
would be a simple advertisement with a list of adjacency SIDs (resource
aware SIDs) subtended. Of course, you have to handle the addition and
removal of VTNs (or variations in the allocated bandwidth), but this 
seems easy enough to manage.

Curiously, section 4 appears to make a positive thing of the fact that
there are scalability concerns. Continuing to contrast SR per topology
state with pre-SR topology per path state is beginning to look a little
thin at this point since the link in the VNT is exactly the path in the
pre-SR topology. You only difference at this stage is the signaling
state, and control plane signaling is not a requirement in a non-SR
system. Since (I think) you don't want to get distracted in this work 
into a re-initiation of the arguments about SR or no SR, I suggest that
you should be more careful with the wording in the third bullet of
section 4. (The final sentence of section 4 contrasting the resource
aggregation in this case with that in RSVP-TE and claiming that resource
allocation is easier and more flexible that with RSVP-TE is really 
likely to cause a fight. It is simply unnecessary to say this in this
document. Stop trying to make marketing statements in Internet-Drafts
and just define the technology!)

I think that the scaling concerns in the current draft merit a mention
in Section 7 since the whole system may be destabilised by an attack (or
accident) that causes a large number of VTNs to be configured. This can
be mitigated by placing thresholds (for alarms or cut-off) in the 
configuration process.

---

I think that I-D.ietf-spring-resource-aware-segments and
I-D.ietf-teas-enhanced-vpn are used in a way that makes them normative
references.

== Nits ==

Throughout

s/(e.g./(e.g.,/ 

---

Abstract

s/which has/which have/

---

1.

Just to future-proof yourself...
s/proposes to extend SR/extends SR/

---

1.

s/which has customized/which have customized/

---

3.

   The detailed control
   plane mechanisms and possible extensions are described in separate
   documents and are out of the scope of this document.

Which separate documents?

---

You have an upper case "SHOULD" in section 3.3. Since you don't have the
BCP 14 boilerplate, I suspect you mean this to be lower case.

---

OLD
3.5.  VTN Visibility to Customer
NEW
3.5.  VTN Visibility to Customers
END

---

3.5

s/requirement, VTN/requirement, VTNs/

---

OLD
4.  Characteristics of SR based VTN
NEW
4.  Characteristics of SR based VTNs
END

---

In several places (and notably section 4) you say...

   The proposed mechanism...

You need to be more assertive if this is to be an RFC (that is not
Experimental). You are "describing" a mechanism not "proposing" it.

---

4.

      Each customer is only aware of the topology
      and attributes of his own VTN

Please consider using the gender-neutral "their" in place of "his"

---

4.

s/provides an practical/provides a practical/

---

OLD
5.  Service Assurance of VTN
NEW
5.  Service Assurance for VTNs
END

---

5.

   In order to provide assurance for services provisioned in the SR
   based VTNs, it is necessary to instrument the network at multiple
   levels, e.g. in both the underlay network level and the VTN level.
   The operator or the customer may also monitor and measure the
   performance of the services carried by the VTN.  In principle these
   can be achieved using existing or in development techniques in IETF.
   The detailed mechanisms are out of the scope of this document.

Assuming that VTNs without service assurance are undesirable, and
reading "it is necessary to instrument", I think this paragraph rather
fails to deliver... "You can probably use some mechanisms defined 
elsewhere or maybe being defined, but we are not going to tell you about
them."

Can you at least give some "such as" references?

---

5.

s/degradation happens in/degradation in/

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 17 Jan 2022 12:44:49 +0000

Hi Adrian,

Thanks a lot for the review and comments. And please see come replies inline:

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Sunday, January 16, 2022 2:16 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: A review of draft-ietf-spring-sr-for-enhanced-vpn-01
> 
> Hi,
> 
> VPN drafts, so I thought I'd get round to this one. A bit surprised to find it
> has expired - you probably want to post something to keep it alive.

Yes, the plan is to provide an update in the following one or two weeks. 

> the names on the front page to 5 or fewer. It is usually easiest to do this
> early and in your own time rather than being forced to do it or having the
> document held up while you sort it out.

Thanks for the reminder. 

> imagine running 1000 VTNs in the network, and if each link is advertising a
> SID, wouldn't you end up needing to advertise 1000 SIDs for each link?

Yes, if 1000 VTNs are required in the network, then the number of SIDs required for each link/node would become an issue. This is analyzed in the VTN scalability draft in TEAS. 

> While section 2.4 makes a stab at identifying the scaling concerns, it seems
> to miss the main point that the IGP may be quite fragile as the number of
> VTNs increases.
> 
> Note that similar issues came up in IGP-TE work. The solution there was to
> advertise just once for the link, but to list the TE attributes on the
> advertisement. I think you could do the same here so that a link would be
> a simple advertisement with a list of adjacency SIDs (resource aware SIDs)
> subtended. Of course, you have to handle the addition and removal of
> VTNs (or variations in the allocated bandwidth), but this seems easy
> enough to manage.

Totally agree that the control plane (e.g. IGP) extensions for VTN need to be optimized to improve the scalability. This is analyzed in the VTN scalability draft in TEAS, and the IGP extensions are specified in draft-dong-lsr-sr-for-enhanced-vpn. 

> 
> Curiously, section 4 appears to make a positive thing of the fact that there
> are scalability concerns. Continuing to contrast SR per topology state with
> pre-SR topology per path state is beginning to look a little thin at this point
> since the link in the VNT is exactly the path in the pre-SR topology. You only
> difference at this stage is the signaling state, and control plane signaling is
> not a requirement in a non-SR system. Since (I think) you don't want to get
> distracted in this work into a re-initiation of the arguments about SR or no
> SR, I suggest that you should be more careful with the wording in the third
> bullet of section 4. (The final sentence of section 4 contrasting the
> resource aggregation in this case with that in RSVP-TE and claiming that
> resource allocation is easier and more flexible that with RSVP-TE is really
> likely to cause a fight. It is simply unnecessary to say this in this document.
> Stop trying to make marketing statements in Internet-Drafts and just define
> the technology!)

Since a path usually consists of multiple links, my understanding is that maintaining per-segment state can have better scalability than maintaining per path state, as one resource-aware segment can be part of multiple paths in a VTN, and the resource represented by the resource-aware SID can be the aggregation of the resources required by multiple paths. 

But I agree there is no need to provide the comparison between the two approaches here. 

> 
> I think that the scaling concerns in the current draft merit a mention in
> Section 7 since the whole system may be destabilised by an attack (or
> accident) that causes a large number of VTNs to be configured. This can be
> mitigated by placing thresholds (for alarms or cut-off) in the configuration
> process.
> 

Agreed. 

> I-D.ietf-teas-enhanced-vpn are used in a way that makes them normative

Agreed, we will move them to normative reference.

> == Nits ==

Thanks for catching the nits, we will fix them in next revision. 

Best regards,
Jie

> reading "it is necessary to instrument", I think this paragraph rather fails to
> deliver... "You can probably use some mechanisms defined elsewhere or
> maybe being defined, but we are not going to tell you about them."
>