[Lsr] RtgDir review: draft-ietf-lsr-ospf-prefix-originator-09

[opens]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-lsr-ospf-prefix-originator-09
Reviewer: Russ White
Review Date: 26 March 2021
IETF LC End Date: 29 March 2021
Intended Status: Proposed Standard

Summary:

No issues found. This document is ready for publication.

This document is well written and concise in describing the uses, mechanisms, 
and protocol extensions.

Major Issues:

No major issues found.

Minor Issues:

No minor issues found.

 /r

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Tony Przygienda]

Having had a long history with RFC5120 (and with the concept before IETF
was even afoot really) and their deployment in its time I cannot resist
finally chiming in a bit ;-)

Well, first, it seems there is agreement that the drafts state fairly
straightforward things but as informational probably nothing wrong with
having it captured and I'd agree with that.

Second, as to realities of MT in such architecture some musings based on
experience;

a) MT was best used when faced with the problem of "alien" topologies, e.g.
introduction of v6 into a network when a lot of boxes/links couldn't do v6
yet (there was a good set of discussions in its time around MT strictly per
node or per link being best approach and for many reasons link based
architecture was chosen) or need for drastically different forwarding
decision deviating from simple SPF (RPF problems).
b) using underlay to "slice" is an expensive proposition of course. The
costliest resources in large networks is really ASIC space in the core and
if the MTs are properly separated, that will take ASIC state. in simplest
form e.g. topology being mirrored into per DSCP bits lookup or something
like this. Nothing wrong with that if one has the $ (or CNY ;-) to foot the
bill for that and slicing underlay gives of course the best quality
assurance compared to overlay approaches AFAIS.
c) MT (well, at least in ISIS ;-) has been built to scale ;-), originally 8
bits were suggested and then I asked others "what's the biggest you can
imagine" to which answer was 1024 MT which needed of course a
multiplication by 4 to make sure stuff will still work in 25 years where we
are today ;-)
d) SPF is to an extent only limitation of MT. the tree itself can be
computed very efficiently today (and there are techniques like incremental
SPF which can drastically lessen the cost of a computation and one can go
to the extent of throwing the SPF computations to a beefy side-box even and
most extreme, ASIC [unbelievale or not, this has been done for trees up to
a certain space ;-)]), the limiting factor is more prefix attachement and
prefix download on massive changes (but there is no reason any LFA would
not work with MT BTW, even to the point where an MT can protect another MT
or MT use all links when protecting disregarding MT itself, I'm not aware
of implementations but the theoretical thinking/whiteboarding has been done
here long ago albeit one has to know a fair bit of math [metric sets
largely]) to not blow up on a mine ;-)
e) main limiting factor of MT deployment was IME operational discontinuity
of topologies that happens much more often than one thinks it does. That's
why MT negotiates on every link the topologies so continuity is clearly
provisioned and can be tracked. Tools to visualize, manage all that are
much harder to operate than one would think, I assume because humans
generally have poor intuition concerning topological spaces under different
metrics. Just look how confused we are when we try to strike something in a
glass of water ;-)
b) yes, TE can be advertised in topologies but here is bunch of things that
fall out of it
i) oversubscription is a fact of life in such an architecture and
discussions about this will start quickly
ii) except in case of massive under-subscription (but even then) the
correct scheduling of MTs will become an issue and possibly pre-emption in
HW when the timing becomes tight enough. DetNet is an interesting romping
ground of ideas for that right now
iii) Even with under-subscription interesting problems crop up like parties
that don't need much resources under normal circumstances but in case of
emergencies are willing to pay any amount to allocate resources their need
and pre-empt any other traffic.

--- tony






On Sat, Mar 27, 2021 at 4:47 AM Gyan Mishra  wrote:

>
> Hi Acee
>
> As an operator, I  support adoption of the draft and would like to provide
> answers to your questions.
>
> I would like to start by stating that as this is an informational
> document,  as nothing new is proposed other then the recommendation to use
> MT for VTN provisioning as a component of the 5G network slicing solutions,
> the benefit is that this concept can be used immediately as other NS
> features are still being developed.
>
> The solution for network slicing resource isolation is multi faceted
> involves Enhanced VPN+ provisioning, resource SIDs for provisioning
> underlay resources, SR-TE Per VPN or flow path steering to meet NS SLO
> requirements, as well as a method to isolate IGP resources for a VTN.
>
> MT is a component of the entire NS solution so there is really nothing to
> market as it’s not the only component used to provision the VTN.
>
> As their is a need for providing a viable means of provisioning IGP
> underlay resources VTN network slice and the ability to provide forwarding
> plane isolation via topological RIB without consuming tremendous control
> plane resources per instance as with MI.
>
> This draft does fill the gap 

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Acee Lindem (acee)]

Speaking as WG member:

Hi Chongfeng,

Another thing, if one is trying to support a VTN with legacy technologies, it 
would be good to decouple it from the SR resource-aware segments.

Thanks,
Acee

From: Chongfeng Xie 
Date: Friday, March 26, 2021 at 11:15 PM
To: Acee Lindem , Jie Dong , 
"chongfeng.xie" , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) 
for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03


Hi, Acee,

Thanks for your understanding about the deployment considerations and the value 
of reusing existing technologies when possible.

We have submitted the draft as draft-ietf-lsr-isis-sr-vtn-mt-00 with only the 
change in the title and date.  And we will expand section 5 and add references 
to relevant TEAS documents in next revision.

Chongfeng


发件人： Acee Lindem (acee)
发送时间： 2021-03-26 23:30
收件人： Dongjie (Jimmy); Chongfeng 
Xie; Acee Lindem 
(acee); 
lsr@ietf.org
主题： Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment 
Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Hi Jie, Chongfeng,

I’ve read draft-ietf-teas-enhanced-vpn and I agree that the combination of MT 
and SR could be used to meet a given SLO. Given that I work with products and 
customers, I also know there can be a significant time lag for qualification 
and deployment of a software version. In lieu of resource-aware segments, you 
could even use an existing technology like VLANs with appropriate QoS 
guarantees. Hence, I can see the value of using existing technologies. Please 
go ahead and republish draft-xie-lsr-sr-vtn-mt as 
draft-ietf-lsr-sr-vtn-mt-00.txt.

Section 5 can be expanded in subsequent revisions with appropriate references 
to TEAS documents.

Thanks,
Acee



From: Lsr  on behalf of Jie Dong 
Date: Friday, March 26, 2021 at 10:39 AM
To: Chongfeng Xie , "Acee Lindem (acee)" 
, "lsr@ietf.org" 
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03

Hi Acee,

I agree with what Chongfeng said about VTN. It refers to a virtual underlay 
network with specific topology and resource attributes, and the topology of 
VTNs can be specified using multi-topology. It is important to understand the 
difference between a VTN and a logical network topology.

As for the deployment choice and scalability, 
draft-dong-teas-enhanced-vpn-vtn-scalability gives some detailed analysis. In 
summary, it says in different network scenarios and phases, the required number 
of VTNs could be different, thus several options may be provided to meet 
different requirements, with different cost and time to market.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, March 26, 2021 2:14 PM
To: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03

Hi，Acee，

Regarding to the issues put forward in your mail, I'd like to provide some 
comments as below,

Q1：I’d like to know of the WG members who supported it, would you really want 
to market it as a VTN solution?

[CF]：VTN is defined in draft-ietf-teas-enhanced-vpn, and also used in other 
documents. It is a technical term to refer to virtual underlay networks with 
specific topology and resource attributes. This document provides an MT based 
mechanism to build VTNs. If for marketing, perhaps it would be better called 
"network slicing":-)

Q2：Those of you who operate networks, would you actually consider deploying it?

[CF]：As an operator we will consider the scenarios and the requirements to pick 
the most suitable solution, IMO this is a good candidate for scenarios where 
the required number of VTN is not very large, and as it requires no new 
encodings, it could be ready for shipment soon. we plans to use this approach 
in some of our network deployment.

Q3：In any case, section 5 needs to be expanded on the scalability and where 
using MTs to support VTNs would make sense and where it wouldn’t.

[CF]：OK. The current section 5 already has some text to cover this, and it can 
be expanded further to clarify.

Best regards
Chongfeng


发件人： Acee Lindem \(acee\)
发送时间： 2021-03-26 02:20
收件人： lsr@ietf.org
主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment 
Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Speaking as WG chair:

There has been considerable support for this document. However, there has also 
been objections to the document. The objections are either that there is 
nothing to standardize