Re: [LOOPS] FW: draft-welzl-loops-gen-info: general direction

[wangjl1.bri <[e-mail]>]

Dear Carsten, All
       This is  Jianglong Wang from China Telecom. For the use case mentioned  in draft-li-tsvwg-loops-problem-opportunities, it talked about using LOOPS for different path segments over a selected path. I think SRv6 is a good candidate here too as it provides the path selection (source routing) naturally. So SRv6 could be a specific encapsulation protocol for LOOPS. SRv6 + LOOPS may benefit two other deployments which are currently under our evaluation.   
 
1.      Enterprise branch connection over public Internet
SiteA GW1 -------------(SRv6)-------------vCPE1 -------------(Internet, multiple SRv6 segments)---------------vCPE2---------( SRv6 )---------SiteB GW2 
                |---<- LOOPS enabled here -> ---|----------------------<- LOOPS enabled here -> - ---------------------|      
                                                           
     In this scenario, the enterprise accesses to the Internet backbone network through vCPE, and uses SRv6 encapsulated packets to carry the end-to-end services. Considering the operation of the existing network, there are certain packet loss in the Internet backbone network. In addition, operators have to provide service guarantees when the quality of the access network is not good. The application of srv6+loops may solve the path selection and long packet loss retransmission problems at the same time. 
 
2.      Connect an enterprise GW to a cloud based POP for public cloud access                    
SiteA GW1 -------------(SRv6)-------------vCPE1 -------------(Internet, multiple SRv6 segments)--------------PoP in public cloud-----vPC-----( DC Interconnection )------- vPC
                                                                       |----------------------<- LOOPS enabled here -> - ---------------------|      
    
 In this scenario, vCPE connects to a cloud based PoP which further directs direct traffic to vPC. vCPE can be city or province based. Number of cloud based PoP is much fewer. So vCPE to PoP can be over a long distance. If srv6+loops can be enabled for segments of this sub-path, that would be useful too. 
 
It seems that your current assumption is ingress and egress are virtual nodes based. So it would be easier to embed LOOPS function for virtual nodes in terms of computing and memory resources. If embeded in srv6 over the abovementioned Internet path, LOOPS may need to be supported by all the intermediate SRv6 nodes in addition to ingress and egress. It may not be easy, considering they are hardware based.  But it should be considered in my opinion for future deployment.
Regards
Jianglong Wang



From: LOOPS [mailto:[e-mail]] On Behalf Of Carsten Bormann
Sent: Wednesday, June 12, 2019 5:18 PM
To: [e-mail]
Subject: [LOOPS] draft-welzl-loops-gen-info: general direction

Is the general direction taken by

https://tools.ietf.org/html/draft-welzl-loops-gen-info

the one that should be pursued in the LOOPS activity?

Specifically:
— protocol is run between an ingress and an egress, apart from some form of controller for setup purposes no other nodes are involved.
— two modes for recover: retransmission mode, FEC mode — protocol operates on sparse forward information (for retransmission mode, pretty much a sequence number and an ACK request) and reverse information that can be piggybacked on a reverse tunnel or sent in separate messages — no “connection setup” between ingress and egress nodes — the protocol defines a generic information model; specific encodings are defined for specific encapsulation protocols such as GUE or Geneve

(The draft actually offers two slightly different approaches, one in the main body, one somewhat more innovative approach in Appendix B.  If you think that Appendix B could be used in a kind of deployment that you are interested in, we would like to hear from you.)

Grüße, Carsten

--
LOOPS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/loops