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