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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Adrian,

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

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Sunday, January 16, 2022 2:16 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: A review of draft-ietf-spring-sr-for-enhanced-vpn-01
> 
> 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.

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


> 
> 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.

Thanks for the reminder. 

> 
> 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?

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. 

> 
> 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.

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 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.

Agreed, we will move them to normative reference.

> 
> 
> 
> == Nits ==

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

Best regards,
Jie

> 
> 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/