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 8C5EE120115 for ; Sat, 13 Jul 2019 08:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WA0sK2XI32kb for ; Sat, 13 Jul 2019 08:24:05 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 67373120110 for ; Sat, 13 Jul 2019 08:24:04 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id c14so6186730plo.0 for ; Sat, 13 Jul 2019 08:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8OIjXBhPfzyFnJfS/e1J4UnK7cP8gzjAuSpUQi5rXaY=; b=kTPBfAMe1pVaxu3pKaOLNArdvq1S0t0Jq4Y3j1nwVJlSaOxF8lDeOJ79m1C1pfRzBG LEN9JLUJynZQF2+fKNwkMWWnVWPCbHNmkQFFKf1TeuUBNCG687+eJU0PAK41DdkHaERM zeGWK8ElIE46ianJbFHskxCt/nA9IdiIFkl/dg54mw8q624wXjJ2NiAAG1byNubfx6qe L0I9FAPkFXeHxmW8SBlJtm2G2fVMp1PiqaAomjOFVIRrTX/ivOjnJbYFz9oRGeK+AOmC b/DzPLYbihI2rIQGMZofDUbBz3b8Ge2SvHhCb1Vcm19uUm5YB8sfSx/vtzhGAfFn7/SE IuQw== 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=8OIjXBhPfzyFnJfS/e1J4UnK7cP8gzjAuSpUQi5rXaY=; b=p9bGRZIp9F7GExSQfvSNJj5aW/VzOfGHZ9DhzIzDnWZVjenxeT1Y4/xAF/QuCJjypY nsNx2zPn0MTyTgLYviy4KrruQFm0FTC98FGzTtoq0Q2GdCiEneo/qOmu6NUrOI9Ii/6G yp5N90rWLmHHbJavwpJB79J9+2jdjXWxbF5oC3VDORMekhTWU7aY/k0/Bg4vh66qxbPN ydRUjrD+MLdU22z8qaqQd00TZPb6xyM/7YeeSpU4olf1RouUenCLjQIua9W4DDWR1qQE lhozJQROV76K7CY/GN1oZaoUcuB3o6YS8okAPTknSWx0EvaWsfbYudS1npqhH0DakTo7 HMtQ== X-Gm-Message-State: APjAAAWoJzuT04nqSX3OYWl3e5JJNyQzyXWmsI5AQFV7KfgoqjWd3rBi GrZ6SaRkbIt7csRcb0N3dUSXgG3JnQo99FdAa/E= X-Google-Smtp-Source: APXvYqy44RTQr4vloGEbgIyV1i9nKk2Cd3casvhQ+yf8yC/dvmtAPvFP8z1ENkEqWZv1VainUO2BamomK63off9EWus= X-Received: by 2002:a17:902:6b0c:: with SMTP id o12mr17684884plk.113.1563031440551; Sat, 13 Jul 2019 08:24:00 -0700 (PDT) MIME-Version: 1.0 References: <007801d53793$a18e37b0$e4aaa710$@org.cn> <05AD0B5A-D32D-4C8F-BF1D-BB9D22234E8B@tsinghua.org.cn> In-Reply-To: <05AD0B5A-D32D-4C8F-BF1D-BB9D22234E8B@tsinghua.org.cn> From: Vishnu Pavan Beeram Date: Sat, 13 Jul 2019 10:23:49 -0500 Message-ID: To: Aijun Wang Cc: Tarek Saad , "tsaad@juniper.net" , TEAS WG , Vishnu Pavan Beeram Content-Type: multipart/alternative; boundary="000000000000c97177058d919d64" Archived-At: Subject: Re: [Teas] Questions on IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels 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: Sat, 13 Jul 2019 15:24:07 -0000 --000000000000c97177058d919d64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Aijun, Hi! Thanks for giving the draft a read! Please see inline for responses (prefixed VPB). Regards, -Pavan On Thu, Jul 11, 2019 at 5:24 PM Aijun Wang wrote: > Hi, Tarek: > Thanks for your clarification. > Then the traffic will be sent in IPinIP tunnels with the outer address > kept the same as the EAB Address along the path? > [VPB] Yes, the traffic steered into the IP tunnel will have the EAB address as the destination in the outer IP header. > How you convince the person that worries about the state preservation > capabilities associated with the RSVP protocol then? > [VPB] I believe you are alluding to scalability concerns that folks tend to have about RSVP-TE (let me know if that isn=E2=80=99t what you are asking = about). There are two aspects to RSVP-TE state scalability - control-plane state and data-plane state. As far as control-plane state scalability is concerned, we now have techniques such as RI-RSVP and Per-Peer Flow Control (RFC8370) that allow implementations to support large scale deployments. There are also =E2=80=9CFast Reroute=E2=80=9D specific techniques like RI-R= SVP-FRR and Summary-FRR available now that significantly cut down processing cycles on the PLR/MP when there is a local failure. All of these techniques are applicable to the IP RSVP-TE tunnels discussed in this draft. As far as data-plane state scalability is concerned, please refer to the section on =E2=80=9CShared Forwarding=E2=80=9D (Section 3.7) in this draft.The intent = of the proposed solution is to provides tools that will help seamlessly replicate key MPLS RSVP-TE features/ functions in native IPv4/v6 networks. > > > Aijun Wang > China Telecom > > On Jul 12, 2019, at 00:14, Tarek Saad wrote: > > Hi Aijun, > > > > Thanks for reading and providing your comments on the draft. Please see > inline. > > > > > > *From: *Teas on behalf of Aijun Wang < > wangaijun@tsinghua.org.cn> > *Date: *Wednesday, July 10, 2019 at 10:52 PM > *To: *Tarek Saad >, 'Vishnu Pavan > Beeram' > *Cc: *'TEAS WG' > *Subject: *[Teas] Questions on IP RSVP-TE: Extensions to RSVP for P2P > IP-TE LSP Tunnels > > > > Hi, Tarek and Vishnu: > > > > I just read your draft > https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00, some > questions are raised as the following. Would you like to clarify them: > > 1. As described in section-3.5.2 > , > the final path is established hop by hop, with the EAB address is the fin= al > destination, and the next-hop address is determined via the EXPLICT_ROUTE > object. > > If so, then this draft proposes to establish one e2e path explicitly vi= a > RSVP in Native IP network. The tunnel itself is not related to this draft= ? > > [TS]: The idea here is to reuse the many constructs that RFC3209 (and > others) introduce to achieve the IP TE tunnel =E2=80=93 this includes FRR= , BW > management, make-before-break, e2e path-protection, preemption, etc.,-- s= o > the tunnel (as ingress construct) is surely related. > > > > If so, should the title be changed to =E2=80=9CIP RSVP-TE: Extensions t= o RSVP > for P2P IP-TE Path=E2=80=9D more appropriated? > > > > 2. The usage of the label proposed in section-3.4 > > is just for identification of the above P2P IP-TE Path(control plane only= )? > It will not existed within the forwarding packet(data plane) itself? > > [TS]: No, the EAB address is allocated by the egress node (triggered by > RSVP signaling). It is carried in the RESV message on the way back to > ingress. Any router that sees the RESV, will process it and program the E= AB > address in its forwarding =E2=80=93 effectively setting up its dataplane = for that > IP-LSP path. > > > > If my understanding is correct, I think this draft has the same effect as > that proposed in > https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/, both can > be the candidate solutions for the scenarios described in > > https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/ > > > > [TS]: We have mentioned in the draft that it is possible the ERO to be > computed and downloaded by a PCE (using PCEP) to an ingress PE, and for t= he > ingress PE to use that ERO in RSVP signaling to setup the IP RSVP-TE tunn= el > using the mechanisms defined in the draft. The draft you mentioned (from > skimming quickly have to say), seems to be using PCEP as interface to > program the RIB on router hops. I=E2=80=99m not sure if it covers many of= (exisiing > TE feature BW/preemption/protection/etc) aspects I=E2=80=99ve mentioned a= bove as > well as being able to establish multiple IP-LSP(s) to same destination an= d > being able to share the dataplane forwarding state among the different > IP-LSP(s) as we describe in this draft. > > > > Regards, > > Tarek > > > > > > Best Regards. > > > > Aijun Wang > > Network R&D and Operation Support Department > > China Telecom Corporation Limited Beijing Research Institute,Beijing, > China. > > > > _______________________________________________ > 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 > --000000000000c97177058d919d64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aijun, Hi!

= Thanks for giving the draft a read!
Please see inline for respons= es (prefixed VPB).

Regards,
-Pavan

On Thu, Jul 11, 2019 at 5:24 PM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
Hi, Tarek:<= div>Thanks for your clarification.
Then the traffic will be sent = in IPinIP tunnels with the outer address kept the same as the EAB Address a= long the path?
=C2=A0
[VPB] Yes, the= traffic steered into the IP tunnel will have the EAB address as the destin= ation in the outer IP header.
=C2=A0
How you convince the pers= on that worries about the state preservation capabilities associated with t= he RSVP protocol then?
=C2=A0
[VPB] = I believe you are alluding to scalability concerns that folks tend to have = about RSVP-TE =C2=A0(let me know if that isn=E2=80=99t what you are asking = about). There are two aspects to RSVP-TE state scalability - control-plane = state and data-plane state. As far as control-plane state scalability is co= ncerned, we now have techniques such as RI-RSVP and Per-Peer Flow Control (= RFC8370) that allow implementations to support large scale deployments. The= re are also =E2=80=9CFast Reroute=E2=80=9D specific techniques like RI-RSVP= -FRR and Summary-FRR available now that significantly cut down processing c= ycles on the PLR/MP when there is a local failure. All of these techniques = are applicable to the IP RSVP-TE tunnels discussed in this draft. As far as= data-plane state scalability is concerned, please refer to the section on = =E2=80=9CShared Forwarding=E2=80=9D (Section 3.7) in this draft.The intent = of the proposed solution is to provides tools that will help seamlessly rep= licate key MPLS RSVP-TE features/ functions in native IPv4/v6 networks.
=

=



Aijun Wang
China Telecom
<= /div>

On Jul 12, 2019, at 00:14, Tarek Saad <tsaad.net@gmail.com&g= t; wrote:

Hi Aijun,=

=C2=A0

Thanks fo= r reading and providing your comments on the draft. Please see inline.

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0<= /span>

From: Teas <teas-bounces@ietf.org>= ; on behalf of Aijun Wang <wangaijun@tsinghua.org.cn>
Date: Wednesday, July 10, 2019 at 10:52 PM
To: Tarek Saad <tsaad@juniper..net>, 'Vishnu Pavan Beeram' <vbeeram@juniper.net&g= t;
Cc: 'TEAS WG' <teas@ietf.org>
Subject: [Teas] Questions on IP RSVP-TE: Extensions to RSVP for P2P = IP-TE LSP Tunnels

=C2=A0

Hi, Tarek and Vishnu:=

=C2=A0

I just read your draft <= a href=3D"https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00"= target=3D"_blank"> https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00, some = questions are raised as the following. Would you like to clarify them:

1. As described in section-3.5.2, the final path is established hop by hop, with the EAB a= ddress is the final destination, and the next-hop address is determined via= the EXPLICT_ROUTE object.

=C2=A0=C2=A0If so, then = this draft proposes to establish one e2e path explicitly via RSVP in Native= IP network. The tunnel itself is not related to this draft?

[TS]: The idea here is to reuse the many co= nstructs that RFC3209 (and others) introduce to achieve the IP TE tunnel = =E2=80=93 this includes FRR, BW management, make-before-break, e2e path-protection, preemption, etc.,-- so the tunnel (as ingress constru= ct) is surely related.<= /span>

=C2=A0<= /span>

=C2=A0=C2=A0If so, shoul= d the title be changed to =E2=80=9CIP RSVP-TE: Extensions to RSVP for P2P I= P-TE Path=E2=80=9D more appropriated?

=C2=A0

2. The usage of the labe= l proposed in section-3.4 is just for identification of the above P2P IP-TE Path(cont= rol plane only)? It will not existed within the forwarding packet(data plan= e) itself?

[TS]: No, the EAB address is allocated by t= he egress node (triggered by RSVP signaling). It is carried in the RESV mes= sage on the way back to ingress. Any router that sees the RESV, will process it and program the EAB address in its for= warding =E2=80=93 effectively setting up its dataplane for that IP-LSP path= .

=C2=A0

If my understanding is c= orrect, I think this draft has the same effect as that proposed in https://datatracker.ietf.org/doc/draft-ietf-teas-pce-nat= ive-ip/, both can be the candidate solutions for the scenarios describe= d in

https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/<= u>

=C2=A0

[TS]: We = have mentioned in the draft that it is possible the ERO to be computed and = downloaded by a PCE (using PCEP) to an ingress PE, and for the ingress PE t= o use that ERO in RSVP signaling to setup the IP RSVP-TE tunnel using the mechanisms defined in the draft. The= draft you mentioned (from skimming quickly have to say), seems to be using= PCEP as interface to program the RIB on router hops. I=E2=80=99m not sure = if it covers many of (exisiing TE feature BW/preemption/protection/etc) aspects I=E2=80=99ve mentioned above as well= as being able to establish multiple IP-LSP(s) to same destination and bein= g able to share the dataplane forwarding state among the different IP-LSP(s= ) as we describe in this draft.

=C2=A0

Regards,<= /span>

Tarek

=C2=A0

=C2=A0

Best Regards.<= /u>

=C2=A0

Aijun Wang=

Network R&D and Oper= ation Support Department

China Telecom Corporatio= n Limited Beijing Research Institute,Beijing, China.

=C2=A0

_______= ________________________________________
Teas mailing list<= /span>
Teas@iet= f.org
https://www.ietf..org/mailman/listinfo/teas
_________________________= ______________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
--000000000000c97177058d919d64--