Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B45120232 for ; Thu, 3 Oct 2019 01:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPGSgeDP29tN for ; Thu, 3 Oct 2019 01:39:18 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1668912011E for ; Thu, 3 Oct 2019 01:39:18 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id u184so1544857qkd.4 for ; Thu, 03 Oct 2019 01:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WTPgPnYrGTuh2RYdWwH7NMgBJlg181fS9gdCaSHIR0o=; b=QUYSh5hPn7XNG9qOgF//ymbIVJ1Q8DWJatlUPoG31Un4fHyAelMp/aUN4kkJxfE0L2 g02dOnuskPY5UosQo91/erU20pcmSTa6kqr5EivG0EH5E7vJVVSxyal2LyrZU5WY8Oa+ ReQIe5uEKSjAM4umgwz6s0IVceXAZV7lgcxDG1MqoYdm7iGJz82uG3w8oRLIm3a5Z3aP fMoMz9Ah3BO4OBsUmPyQ24OubfhEoPCnmQa50izqmkRhRYgRPRWk4BC0FykJclIUSYKw Kd7/fqttQzsXwFkK27S23agKbMm+zTIkU06rNXsyr7R6tL4B1LIla1jATtYrWpl2AQJl LsZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WTPgPnYrGTuh2RYdWwH7NMgBJlg181fS9gdCaSHIR0o=; b=K9X76L0Aq5wjjZF/ZdTPOM/u5iOP8ASDliKp1Mw114Yp/e1W08Mf6DlrIfP6pVkea7 N4ks1AfA6WsdjQzZt/m+rbHp7Dwh5p0Q0pR745pUBqF0oPUt6XOynLgY0v87blpXT8h4 Pw8Z12LY1/c7Cl2u1Ld7cviHuiIMqQL6dq5I933VAmB0KMlenHufmAplL2uxNREmloIr //bRY0DijXr2WsT1GmYHuvkQO5lYZFLCZfBPnBS1kldPZF56zXrx5zjYP3CdtIEfCbbQ gwdPogxeL+5GiYIHjbw+vGu/2DzcmZSe+hAE6XWJsON9C25K3HDxGsR/tc2rs4BJIeke 3YpQ== X-Gm-Message-State: APjAAAVzThEOLa9IRD/6ZENvnMijnUc7JeoGmAvGm+OysWQM0c4TJfDE epS9JCkXs5YcAyoh6//RFHD4bZq08yaJiY7vSVYypg== X-Google-Smtp-Source: APXvYqzXk+kc5/Mzr5u4Clcape1z3u8cINjA/UX7OpovmCxzgG8XK+t9DI9Kt5aZNvwOkXBlDW0/FPrmlj89RGCSxVQ= X-Received: by 2002:a37:8547:: with SMTP id h68mr3088567qkd.219.1570091956980; Thu, 03 Oct 2019 01:39:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Thu, 3 Oct 2019 10:39:06 +0200 Message-ID: To: Aijun Wang Cc: Benjamin Kaduk , draft-ietf-teas-native-ip-scenarios@ietf.org, Lou Berger , teas-chairs@ietf.org, The IESG , teas@ietf.org Content-Type: multipart/alternative; boundary="0000000000005c608f0593fd85ca" Archived-At: Subject: Re: [Teas] Benjamin Kaduk's Discuss on draft-ietf-teas-native-ip-scenarios-09: (with DISCUSS and COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 08:39:21 -0000 --0000000000005c608f0593fd85ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, I think it is useful informational document. However I would remove PCE elements from it and turned it into requirements document perhaps also adding few more real life deployment scenarios where use of end to end IP TE is very important. Many thx, R. On Thu, Oct 3, 2019 at 10:10 AM Aijun Wang wrote: > =EF=BB=BF > =EF=BB=BFHi, Benjamin: > Thanks for your review. > > On summary, this draft just gives the scenarios that needed for TE in > Native IP network, this is absent in current existing IETF documents. The > simulation results just demonstrated the applicability of central control > under the global view. > This document is the base document of other two drafts: > > https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-04 (Solution > Draft) > > https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-native-ip-04 > = (PCEP > extension) > > There are currently at least three different solutions trying to > accomplish the TE necessities in native IP network. This scenarios and > simulation draft is just the start points of these documents. > > More details responses are inline below. Wish they can convince you for > the future vote. > > Thanks in advance. > > Aijun Wang > China Telecom > > On Oct 3, 2019, at 13:15, Benjamin Kaduk via Datatracker > wrote: > > =EF=BB=BFBenjamin Kaduk has entered the following ballot position for > draft-ietf-teas-native-ip-scenarios-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have two points for discussion: > > (1) If this document was subject to the approval requirements for > standards action, it would basically be suffering from "death by > abstain"; this seems like a good signal for the IESG to discuss whether > it makes sense to approve this document even though the more-lenient > document-action requirements would otherwise let it go forward. > > [Aijun Wang]: This document is the cooperation results of authors from > operators, research university and the vendor. The style of the document > maybe slight different from the traditional IETF documents, but the aim o= f > it same as others: give some useful information to the community based on > our efforts. > Wish the relevant responses and explanations can convince the reviewer. > > (2) The document seems incomplete to me. It has some aspects of being > all/any of a use-cases document, an architecture document, and an > applicability analysis, but does not seem to have a complete treatment > for any of them. To be clear, there is enough in the document to > indicate that the topic merits further work, and there are some > interesting results, but I'm not sure that publication as an RFC is > appropriate for this document in this form. Specifically: > > [Aijun Wang] It is mainly one native IP TE scenarios description document= . > The simulation part of this document just want to convince the reader the > addition gain of central control under the global view. > The architecture/solutions contents is in above mentioned solutions draft= . > > > (2a) use-cases: we see the examples of star topology with BRAS/SR and > the simulated network in Figure 6, but there is not much discussion of > where these (or similar) scenarios arise in practice, how common they > are, and how closely the simulation reflects actual usage. > > > [Aijun Wang]: The star topology and simulated topology are all abstractio= n > from our real network deployment. > > > (2b) architecture: a very high-level picture is given ("use a PCE to > engineer some of the IP traffic on a network and improve overall > efficiency"), but we don't see much about how PCCs will be involved and > apply the computed paths or what requirements will need to be met by the > protocols and components used to instantiate the architecture > > > [Aijun Wang]: The above contents that you concerned is described in the > above mentioned solution and PCEP extension drafts. As explained in > previous, this draft focus only the overall scenarios and the simulation > results. > > > (2c) applicability: we see some scenarios where the proposed technology > shows drastic improvement over the alternative selected for comparison, > but there is little to give confidence that this reflects a broad maxima > that is robust to environmental variations. Is the alternative selected > for comparison an appropriate one for the cases in question? How would > the propsal react in the face of changes in the environment it runs in, > such as link or node failure, changes in the baseline usage, or traffic > spikes? What timescale can it react in and what level of visibility > does the PCE need into current conditions in order to be reliable? > > [Aijun Wang] The SDN controller get the overall underlying network > conditions via BGP-LS/SNMP/Netflow protocol in about 5 minutes intervals. > The optimization process for the simulated complex topology and traffic > matrix need only tens of seconds. For further strict requirements, it is > easy to enhance the central controller=E2=80=99s capability to tackle the > changeable environment. > > The above concerns has more relations to the solutions, we can add such > descriptions in the solutions draft at its =E2=80=9CDeployment Considerat= ions=E2=80=9D > part.( > https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-04#section-9) > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > If we're using a PCE in a native IP network, how do the computed routes > get applied; are we using source routing or just being careful about > the prefixes in use? (Are there going to be any scaling concerns?) > > > [Aijun Wang] These contents are in the above mentioned solution draft. It > is not using the current source routing, but the combination of multiple > BGP session and the manipulation of the path to BGP nexthop with the help > of PCEP protocol. The scalability is discussed in section 9.1 of solution > draft( > https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-04#section-9.1) > > > > Section 3.1 > > I don't understand what Figure 1 is intending to convey. Are "Private > Cloud Site" and "Public Cloud Site" supposed to be separate boxes on the > edge of the distributed control network? Why is the "Cloud Based > Application" in neither of the named clouds? > > > [Aijun Wang]: The source and destination of the =E2=80=9CCloud-Based Appl= ication=E2=80=9D > are located at the =E2=80=9CPrivate Cloud Site=E2=80=9D and =E2=80=9CPubl= ic Cloud Site=E2=80=9D. You can > deem these sites as the concepts described in traditional VPN deployment > scenarios. > > Section 3.2 > > Network topology within a Metro Area Network (MAN) is generally in a > star mode as illustrated in Figure 2, with different devices > > "Generally" within what scope, commercial ISPs? I know of things that > could be called MANs that use a different topology.. > > [Aijun Wang]: In commercial ISP. > > Section 4..1 > > nit: several sentences are missing spaces after the full stop. > > > [Aijun Wang] Will correct them in update version. > > > Section 4.2 > > Is a fully-linked core of 100 nodes representative of typical > deployments? That's a lot of links not going to customers! > > > [Aijun Wang]: The core nodes can also connects the customers. That is the > reasons that the traffic matrix is 500*500, not 100*100 > > > Section 4.3 > > The traffic matrix is generated based on the link capacity of > topology. [...] > > I don't know how to interpret this statement. > It does sound like the traffic matrix is generated in a somewhat > arbitrary fashion, with no stated effort to keep it aligned with > real-world traffic patterns. > > [Aijun Wang] We just keep the overall congestion links ratio is similar > with the real network. The arbitration fashion can otherwise certificate > the robustness of the simulation process. > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --0000000000005c608f0593fd85ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

I think it is useful informational= document.=C2=A0

However I would remove PCE elemen= ts from it and turned it into requirements document perhaps also adding few= more real life deployment scenarios where use of end to end IP TE is very= =C2=A0important.

Many thx,
R.
=




On Thu, Oct 3, 2019 = at 10:10 AM Aijun Wang <wan= gaijun@tsinghua.org.cn> wrote:
=EF=BB=BF
=EF=BB=BFHi, Benjamin:
Thanks for your review.

<= /div>
On summary, this draft just gives the scenarios that needed for T= E in Native IP network, this is absent in current existing IETF documents. = The simulation results just demonstrated the applicability of central contr= ol under the global view.
This document is the base document of o= ther two drafts:

=

There are currently at least three different solutions trying = to accomplish the TE necessities in native IP network. This scenarios and s= imulation draft is just the start points of these documents.

=
More details responses are inline below. Wish they can convince = you for the future vote.

Thanks in advance.
<= div>
Aijun Wang
China Telecom=

On Oct 3, 2019, = at 13:15, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:

=EF=BB=BFBenjamin K= aduk has entered the following ballot position for
draft-ie= tf-teas-native-ip-scenarios-09: Discuss

Wh= en responding, please keep the subject line intact and reply to all<= br>email addresses included in the To and CC lines. (Feel free to cut= this
introductory paragraph, however.)


Please refer to https://www.iet= f.org/iesg/statement/discuss-criteria.html
for more inf= ormation about IESG DISCUSS and COMMENT positions.
<= br>
The document, along with other ballot positions, = can be found here:
https://datatra= cker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/
=


------------------------= ----------------------------------------------
DISCUSS:
--------------------------------------------------------------= --------

I have two points for discussion:=

(1) If this document was subject to the a= pproval requirements for
standards action, it would basical= ly be suffering from "death by
abstain"; this see= ms like a good signal for the IESG to discuss whether
it ma= kes sense to approve this document even though the more-lenient
<= span>document-action requirements would otherwise let it go forward.=

[Aijun Wang]: This document is= the cooperation results of authors from operators, research university and= the vendor. The style of the document maybe slight different from the trad= itional IETF documents, but the aim of it same as others: give some useful = information to the community based on our efforts.
Wish the relev= ant responses and explanations can convince the reviewer.

(2) The document seems = incomplete to me.=C2=A0 It has some aspects of being
all/an= y of a use-cases document, an architecture document, and an
applicability analysis, but does not seem to have a complete treatment
for any of them.=C2=A0 To be clear, there is enough in the doc= ument to
indicate that the topic merits further work, and t= here are some
interesting results, but I'm not sure tha= t publication as an RFC is
appropriate for this document in= this form.=C2=A0 Specifically:
[Aijun Wa= ng] It is mainly one native IP TE scenarios description document. The simul= ation part of this document just want to convince the reader the addition g= ain of central control under the global view.
The architecture/so= lutions contents is in above mentioned solutions draft.


(2a) use= -cases: we see the examples of star topology with BRAS/SR and
the simulated network in Figure 6, but there is not much discussion of
where these (or similar) scenarios arise in practice, how co= mmon they
are, and how closely the simulation reflects actu= al usage.

[Aijun Wang]: Th= e star topology and simulated topology are all abstraction from our real ne= twork deployment.


(2b) architecture: a very high-level picture is given (&q= uot;use a PCE to
engineer some of the IP traffic on a netwo= rk and improve overall
efficiency"), but we don't = see much about how PCCs will be involved and
apply the comp= uted paths or what requirements will need to be met by the
= protocols and components used to instantiate the architecture

[Aijun Wang]: The above contents that y= ou concerned is described in the above mentioned solution and PCEP extensio= n drafts. As explained in previous, this draft focus only the overall scena= rios and the simulation results.


(2c) applicability: we see some scenarios = where the proposed technology
shows drastic improvement ove= r the alternative selected for comparison,
but there is lit= tle to give confidence that this reflects a broad maxima
th= at is robust to environmental variations.=C2=A0 Is the alternative selected=
for comparison an appropriate one for the cases in questio= n?=C2=A0 How would
the propsal react in the face of changes= in the environment it runs in,
such as link or node failur= e, changes in the baseline usage, or traffic
spikes?=C2=A0 = What timescale can it react in and what level of visibility
does the PCE need into current conditions in order to be reliable?<= br>
[Aijun Wang] The SDN controller get = the overall underlying network conditions via BGP-LS/SNMP/Netflow protocol = in about 5 minutes intervals. The optimization process for the simulated co= mplex topology and traffic matrix need only tens of seconds. For further st= rict requirements, it is easy to enhance the central controller=E2=80=99s c= apability to tackle the changeable environment.

Th= e above concerns has more relations to the solutions, we can add such descr= iptions in the solutions draft at its =E2=80=9CDeployment Considerations=E2= =80=9D part.(https://tools.ietf.org/html/draft-ie= tf-teas-pce-native-ip-04#section-9)
=C2=A0=C2=A0

------------------= ----------------------------------------------------
COMMEN= T:
--------------------------------------------------------= --------------

If we're using a PCE in= a native IP network, how do the computed routes
get applie= d; are we using source routing or just being careful about
= the prefixes in use? =C2=A0(Are there going to be any scaling concerns?)


[Aijun Wang= ] These contents are in the above mentioned solution draft. It is not using= the current source routing, but the combination of multiple BGP session an= d the manipulation of the path to BGP nexthop with the help of PCEP protoco= l. The scalability is discussed in section 9.1 of solution draft(https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip= -04#section-9.1)



Section 3.1

I don't understand what Figure 1 is intending to convey.=C2=A0 Are = "Private
Cloud Site" and "Public Cloud Site&= quot; supposed to be separate boxes on the
edge of the dist= ributed control network?=C2=A0 Why is the "Cloud Based
Application" in neither of the named clouds?
<= br>

[Aijun Wang]: The source and dest= ination of the =E2=80=9CCloud-Based Application=E2=80=9D are located at the= =E2=80=9CPrivate Cloud Site=E2=80=9D and =E2=80=9CPublic Cloud Site=E2=80= =9D. You can deem these sites as the concepts described in traditional VPN = deployment scenarios.

<= span>Section 3.2

=C2=A0=C2=A0Network topo= logy within a Metro Area Network (MAN) is generally in a
= =C2=A0=C2=A0star mode as illustrated in Figure 2, with different devices

"Generally" within what scope, com= mercial ISPs?=C2=A0 I know of things that
could be called M= ANs that use a different topology..

[Aijun Wang]: In commercial ISP.

Section 4..1

n= it: several sentences are missing spaces after the full stop.

[Aijun Wang] Will correct them in update ver= sion.

= Section 4.2

Is a fully-linked core of 100 = nodes representative of typical
deployments?=C2=A0 That'= ;s a lot of links not going to customers!

[Aijun Wang]: The core nodes can also connects the customer= s. That is the reasons that the traffic matrix is 500*500, not 100*100

Sect= ion 4.3

=C2=A0=C2=A0The traffic matrix is= generated based on the link capacity of
=C2=A0=C2=A0topol= ogy. =C2=A0[...]

I don't know how to i= nterpret this statement.
It does sound like the traffic mat= rix is generated in a somewhat
arbitrary fashion, with no s= tated effort to keep it aligned with
real-world traffic pat= terns.

[Aijun Wang] We j= ust keep the overall congestion links ratio is similar with the real networ= k. The arbitration fashion can otherwise certificate the robustness of the = simulation process. =C2=A0


_______________________________________________<= /span>
Teas mailing list
Teas@ietf.org
https://www.ietf.= org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
--0000000000005c608f0593fd85ca--