[Teas] 答复: Questions on IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels

["Aijun Wang" <[e-mail]>]

Hi, Vishnu and Tarek:

 

I think you should add these explanation in some section such as  “deployment consideration” to convince the persons about the extensibility of RSVP-TE.

One other question, also raised by other person during the IETF 105 presentation, how you consider to accomplish the loose path function in Native IP environment? 

 

We are seeking some solutions for TE in native IP network.

Currently, we consider using PCE to assist us to accomplish this task (as that described in https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-03).  The merit of this solution is that it can control the underlay network flexibly(strict path or loose path) and also exploit the advantage of traditional IGP/BGP protocol.  One need not worry about the extensibility of these protocols.

 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

 

发件人: [e-mail] [mailto:[e-mail]] 代表 Vishnu Pavan Beeram
发送时间: 2019年7月13日 23:24
收件人: Aijun Wang
抄送: [e-mail]; Tarek Saad; TEAS WG; Vishnu Pavan Beeram
主题: Re: [Teas] Questions on IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels

 

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 <[e-mail]> 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’t 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 “Fast Reroute” specific techniques like RI-RSVP-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 “Shared Forwarding” (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 <[e-mail]> 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 <tsaad@juniper..net <mailto:[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://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 <https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00#section-3.5.2> , 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://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00#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 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://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 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://www.ietf..org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas> 

_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas