Re: [Qirg] Similarities between RSVP IETF (RFC 2205) protocol and connection Setup in a Quantum Network

[Bruno Rijsman <[e-mail]>]

See 2>>> below

> On Nov 20, 2019, at 3:29 PM, Dino Farinacci <[e-mail]> wrote:
> 
>> One minor answer >>> below.
>> 
>> But before I address the main comment, can I ask you a clarifying question to fully understand the scenario that you have in mind?
>> 
>> In your scenario, are the service providers ATT and VZ only providing classical connectivity for the classical channel ([A] below) or are they also offering quantum connectivity for the quantum channel ([B] below)?
> 
> Classic connectivity. The QRs can be at their customer sites.

2>>> In that case, you just use standard routing protocols (default route or BGP if you are multi-homed) for the classical traffic that goes over the service provider network. Nothing fancy needed here (no RSVP in specific).

2>>> And in this case the quantum topology is a simple linear chain, so once again, nothing fancy needed here either. We use the specialized repeater protocol, collapse the multi-hop quantum chain into a single quantum layer-3 hop, and the whole topology simplifies to a single layer-3 point-to-point link. No RSVP needed, once again.

> And if ISPs provide QRs that sites need to pair with (good luck with that),

2>>> Right, this is scenarios [B] which is indeed way more complicated, because… (see next comment)

> then you will have to know the IP addresses of the ISP QRs (good luck with that).
> 

2>>> (That’s the least of your concerns, that’s like knowing the IP address of the Service Provider’s BGP router for peering. The bigger concern is in the next comment….)


>> In everything I have described until now, I was actually only considering intra-domain quantum routing and not yet inter-domain quantum routing, which is even further away into the future IMHO.
> 
> I don’t see why. 

2>>> The reasons why inter-domain routing / traffic engineering is far more complicated than intra-domain routing / traffic engineering are that (a) inter domain routing protocols optimize policy considerations (= money) rather than technical considerations (= shortest path) and (b) service providers don’t want to leak the internal details of their networks (topology, utilization, etc.) to their customers. We need to crawl and walk before we consider running a marathon :-)


> 
>> 
>> [A] Service provider provides only classical channel (CC):
>> 
>> CC      CC     CC     CC     CC     CC   CC    CC
>> +----CR----CR---+     +---CR----CR---+   +--CR--+
>> |   |........|  |     |  |.........| |   | |..| |
>> |      ATT      |     |     VZ       |   | Lab  |
>> |                \   /               \   /      \
>> QR1----------------QR2-----------------QR4--------QR5
>>          QC                 QC              QC
>> 
>> [B] Service provider provides both classical channel (CC) and quantum channel (QC):
>> 
>>    CC+   CC+   CC+    CC+   CC+   CC+    CC+   CC+
>>    QC    QC    QC     QC    QC    QC     QC    QC
>> QR1----QR----QR----QR2----QR----QR----QR4----QR----QR5
>>      |........|         |........|         |..|
>>       ATT                VZ                Lab
>> 
>> — Bruno
>> 
>>>> This is similar to not representing optical repeaters or Ethernet hubs in the classical layer 3 network topology.
>>> 
>>> Optical repeaters and ethernet hubs if SNMP managed would be hosts with accessible IP addresses on the layer-3 network.
>> 
>>>>> Exactly, they are represented as hosts (not routers) on the network. So, they do not appear as nodes in the layer-3 topology flooded by OSPF / ISIS / etc. In fact, they do not appear at all in the routing protocol (which only advertises subnets, not individual hosts).
> 
> Right, they are not routers. Just like your laptop right now is not pariticaping in OSPF/IS-IS.
> 
> Dino