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

[Tarek Saad <[e-mail]>]

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]