Re: [Teas] Preferred Path Routing (PPR) Re: Questions on IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels

Gyan Mishra <hayabusagsm@gmail.com> Fri, 25 October 2019 01:11 UTC

Return-Path: <hayabusagsm@gmail.com>
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 E9B8812008D for <teas@ietfa.amsl.com>; Thu, 24 Oct 2019 18:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 yZ4fk9IpV8ua for <teas@ietfa.amsl.com>; Thu, 24 Oct 2019 18:11:21 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 208A8120018 for <teas@ietf.org>; Thu, 24 Oct 2019 18:11:21 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id g21so245817qkm.11 for <teas@ietf.org>; Thu, 24 Oct 2019 18:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3fpvfd7SJZ0wYW1T4vEYIjqLj1wb/z7Gk01Yg/SL6PM=; b=BxWtW1YR+kNwMrBWdUhE3jQVRQKp+1bU3Tbh4oWWpNAbqyQpnBDHnjUVs4x6zdKlod 5qMsx6GRag/qMZmZulrwdGV8pucx1kWvemQ4FJccUYCegvsDk7mhJsCQTm4Xx/YdMh3M rzLlfZIJr0FGkg6MqeATwJ+Ywf9m64ng4FYiQBinOV8JDOoWyGe43WbIHPsQe+dG4lFO Q2CRaVbPtkX5Ocs1q+r0XLy8jjY6G0lPHECwdZ1U9y2LVhZyjo1Am+nKbqv82DCZ/XYQ CmAeBSGKSw5y8t9sffYn7Du6wok+aeE6lsnCDkWqJDHRPY8FGRZZ8YOqqaqo2XS1VB0z AyRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3fpvfd7SJZ0wYW1T4vEYIjqLj1wb/z7Gk01Yg/SL6PM=; b=ekWXZ6cL0lcGJqTz3kQkM4/cPUypCFrmJxkn3Y1eENqVctGfsNZR8LFUHqaleyNl/K Sfm0uHM3MzKBPvSL3i5DycAidsoeVfMDCi+EXVeRWP2c9fEaSKPvgZdaswi8rQnL7LFW xZ8KlOru3aQackggHXFRdpcjmHxYMOQxnXpyMWGPY/wRdB8vqngcHiozZ/ug+caOGGSP icp913jvCKN7kEs3MfF1Pa8UPruquuwYsyj1CYKRr6OMS5SMh9VhgZiSeFZiIL9Q9pcH QE6S8+FVpefMIrfew7o2SngnXNfpWaTjsrUcLdAKa5XP/QQoU2ciTsWPDgSoI7bjkLCz yosg==
X-Gm-Message-State: APjAAAX7o5RHO93JiFNnlmhJQD+s9uIDk95iTOby2hLyjisKm7vJIaS7 sIkqFQkHb1+o02wxxKeqZRo=
X-Google-Smtp-Source: APXvYqxUH9yND9PbR+7AYlHovoR/C27lOzCTew4AZH4/nCDWf++vU9co/DMGeng/WZ33x3qO+XkFjA==
X-Received: by 2002:a05:620a:4d9:: with SMTP id 25mr624399qks.75.1571965879630; Thu, 24 Oct 2019 18:11:19 -0700 (PDT)
Received: from ?IPv6:2600:1003:b019:67eb:e145:eab7:9c:b33a? ([2600:1003:b019:67eb:e145:eab7:9c:b33a]) by smtp.gmail.com with ESMTPSA id w15sm77541qtk.43.2019.10.24.18.11.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Oct 2019 18:11:17 -0700 (PDT)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Google-Original-From: Gyan Mishra <hayabusaGSM@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <E4052477-0B77-47EF-B1F7-C6B63EEBF6B8@juniper.net>
Date: Thu, 24 Oct 2019 21:11:15 -0400
Cc: Toerless Eckert <tte@cs.fau.de>, Tarek Saad <tsaad.net@gmail.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, TEAS WG <teas@ietf.org>, Vishnu Pavan Beeram <vbeeram@juniper.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <31E420AD-E8F6-4042-B1EF-FDD1B95B9956@gmail.com>
References: <20190729215513.7yf4cj7mf3ieevs4@faui48f.informatik.uni-erlangen.de> <E4052477-0B77-47EF-B1F7-C6B63EEBF6B8@juniper.net>
To: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/X3NOSDdNyaFWOojBslFm6fk13lc>
Subject: Re: [Teas] Preferred Path Routing (PPR) Re: 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 <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Oct 2019 01:11:25 -0000

Tarek & Authors of PRR Draft I had some questions related to the applications of IP-TE extensions use cases of native IP forwarding networks where hop by hop state does not exist as in with MPLS forwarding plane with label switching topmost label in this case TE LFIB does not exist.

So the maib use case is with Spring WG Segment Routing which the major benefit of SR is inherent TE source routing capability by the source node which allows the core to be free of maintaining any state as exists with MPLS P routers LFIB forwarding plane.

So since SR-MPLS has SR-TE for explicit IP-TE paths which is inherent to SR-MPLS.

With SRv6 has native IPv6 forwarding plane hop by hop traffic engineering capability with EH SRH insertion at source node routing header type 4 and IP FRR path protection with Ti-LFA.

So given both SR-MPLS and SRv6 both have inherent source routing traffic engineering capability of IP-FRR what does this draft for IP-TE PPR provide that already exists.

Regards 

Gyan

Sent from my iPhone

> On Aug 6, 2019, at 1:27 PM, Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org> wrote:
> 
> Hi Toerless,
> 
> Thanks for forking a separate thread on this as PPR is indeed an orthogonal topic.
> Admittedly, we're still catching up on PPR, but please see inline for some comments on your points.
> 
> On 7/29/19, 5:55 PM, "Toerless Eckert" <tte@cs.fau.de> wrote:
> 
>    I think this option might not have been brought up on TEAS in before:
>    With "Preferred Path Routing" (PPR) we have proposed a solutoin that
>    signals traffic engineered paths efficiently solely via the IGP, independent
>    of fowarding plane, hence applicable to IPv4/IPv6/SR-MPLS/SRv6 (or
>    even L2 switching).
> 
>    The core thought was to simplify signalling and leverage what we learned
>    eliminating LDP from the necessary signaling protocol suite with SR,
>    something customers seem to overall appreciate. But there was no
>    equivalent mechanism to eliminate RSVP-TE signaling, and with PPR there
>    is.
> 
> [TS]: We understand the drive to reduce protocols for the argument of simplicity. However, with RSVP we have an efficient mechanism to communicate (downstream or upstream) with all or some nodes along the path or even between a specific node and the ingress of the Path. While PPR piggybacks over IGP (trying to eliminate RSVP), it is inheriting IGP's flooding nature. It seems all nodes within the IGP domain will have the state about all the PPR path(s) and all nodes will have to process all of the PPR TLVs to determine whether or not they are relevant for them or not. This may raise some concerns about scale and convergence implications. Also, while [ID. draft-cls-ppr-te-attributes] is an early attempt to bring BW reservation to links traversed by the PPR path by adding BW to the flooded PPR TLV, it still lacks handling of things admission failures (which occur in race conditions), (soft/hard) preemption (due to capacity decrease, etc.) and many others - and it is not clear how the ingress of the path is notified of such conditions - short of potentially multiple preempting nodes flooding such notifications in the IGP domain.. 
> 
>    Btw: When i started working on RSVP/RSVP-TE i also wanted TE functions
>    for RSVP-IP, but after having experienced a lot of the perfomance /
>    complexity issues, i think its a good idea to consider a more forward
>    looking alternative.
> 
> [TS]: We are not sure what performance/complexity issues you are eluding to above. As you know, there's been some significant work done at IETF for improving RSVP protocol for scale deployments (for e.g. message bundling/RFC2961, scale/RFC8370, RSVP Summary FRR, and RI RSVP FRR, etc...). Also note, IP-TE RSVP entails a single IP-in-IP encapsulation (at the ingress) and a decapsulation (at the egress). Nodes along the path do not perform additional dataplane processing -- besides the regular IP forwarding instructions.
> 
>    Wrt to loose hop forwarding: With PPR, the cost of signaling strict cost
>    is minimized, so whenever the desired policy better suits strict (e.g.:
>    no undeisred rerouting on loose segments), PPR should make it most easy.
>    When the policy is really loose segments, then i think for all signaling
>    mechanisms (RSVP-TE-IP, PPR or anything else), the same considaration
>    for the forwarding plane could apply:
> 
> [TS]: Please note that loose paths are possible with RSVP.
> 
> Regards,
> Tarek and Pavan
> 
>    Typically you wouldn't want to carry customer payload packets without
>    encap across the TE domain. Not an issue of TE, just of not wanting
>    customer addresses in your own network domain.  So you can assume to have a TE-domain
>    end-to-end encap. You can logically simply do on loose hops an
>    architectural IP-decap followed by IP-encap. And implementation wise its
>    at worst a 2 * 128-bit rewrite (Src,Dst-IP-addr). If you are creative
>    and consider the source-address to be an anycast-address owned by every
>    loose-hop, and you don't need to steer on the source-address, it's only a
>    single 128 bit rewrite. So not that difficult. In IPv4 the rewrite would be
>    shorter, but you also need to incrementally update the checksum, which
>    may be an issue for simpler forwarding HW (shouldn't be for P4-class
>    forwardign engine, but might cost more performance).
> 
>    For PPR, See e.g.: draft-chunduri-lsr-isis-preferred-path-routing,
>    draft-qct-lsr-ppr-yang, draft-bryant-rtgwg-plfa,
>    draft-chunduri-idr-bgp-ls-ppr-ext, draft-ce-lsr-ppr-graph,
>    draft-cls-ppr-te-attributes, ...
> 
>    Cheers
>        Toerless
> 
>>    On Thu, Jul 11, 2019 at 04:14:55PM +0000, Tarek Saad wrote:
>> Hi Aijun,
>> 
>> Thanks for reading and providing your comments on the draft. Please see inline.
>> 
>> 
>> 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>et>, 'Vishnu Pavan Beeram' <vbeeram@juniper.net>
>> Cc: 'TEAS WG' <teas@ietf.org>
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsaad-2Dteas-2Drsvpte-2Dip-2Dtunnels-2D00&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=60Kd1iKaFRXkC1muJlLnPWj5oYBoMAQXBuJo0HwHPvQ&s=JGD977mQrjiZZwqEbO4wLw4ijrgNgnIYG1HdYPblJdY&e= , some questions are raised as the following. Would you like to clarify them:
>> 1. As described in section-3.5.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsaad-2Dteas-2Drsvpte-2Dip-2Dtunnels-2D00-23section-2D3.5.2&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=60Kd1iKaFRXkC1muJlLnPWj5oYBoMAQXBuJo0HwHPvQ&s=Uo5-DdoW-CplEeMvsHhu2LggDdaqWPfFxMzIQwOI92s&e= >, the final path is established hop by hop, with the EAB address is the final 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 via 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 ? this includes FRR, BW management, make-before-break, e2e path-protection, preemption, etc.,-- so the tunnel (as ingress construct) is surely related.
>> 
>>  If so, should the title be changed to ?IP RSVP-TE: Extensions to RSVP for P2P IP-TE Path? more appropriated?
>> 
>> 2. The usage of the label proposed in section-3.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsaad-2Dteas-2Drsvpte-2Dip-2Dtunnels-2D00-23section-2D3.4&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=60Kd1iKaFRXkC1muJlLnPWj5oYBoMAQXBuJo0HwHPvQ&s=9gakAjx_5PIY8eFJjhrKA_Ww-pWv-YZjh4qCGsjHZpE&e= > 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 EAB address in its forwarding ? 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Dpce-2Dnative-2Dip_&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=60Kd1iKaFRXkC1muJlLnPWj5oYBoMAQXBuJo0HwHPvQ&s=sM_zMk8WlWNyUOpaAWjNhQK-lP8eNd6OCx0vvz1WaAk&e= , both can be the candidate solutions for the scenarios described in
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Dnative-2Dip-2Dscenarios_&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=60Kd1iKaFRXkC1muJlLnPWj5oYBoMAQXBuJo0HwHPvQ&s=VQsubDKP6SERYCS3w29I3Rm2sczMrKHdMBlx1d92Q8A&e= 
>> 
>> [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 to 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?m not sure if it covers many of (exisiing TE feature BW/preemption/protection/etc) aspects I?ve mentioned above as well as being able to establish multiple IP-LSP(s) to same destination and 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Kd6NW5ctLWr7GB646PVmMByvi8wQxPILpKhHvGQeRHY&m=60Kd1iKaFRXkC1muJlLnPWj5oYBoMAQXBuJo0HwHPvQ&s=ZPZIwldqPiG44tfYdq8_UgnDlAEPSJYBGhw7BsVydZQ&e= 
> 
> 
>    -- 
>    ---
>    tte@cs.fau.de
> 
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas