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

[Gyan Mishra <[e-mail]>]

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=[e-mail]> 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" <[e-mail]> 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 <[e-mail]> on behalf of Aijun Wang <[e-mail]>
>> Date: Wednesday, July 10, 2019 at 10:52 PM
>> To: Tarek Saad <[e-mail]>, 'Vishnu Pavan Beeram' <[e-mail]>
>> Cc: 'TEAS WG' <[e-mail]>
>> 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
>> [e-mail]
>> 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= 
> 
> 
>    -- 
>    ---
>    [e-mail]
> 
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas