Hi Shuping,


Thank you for taking the minutes.

Please find enclosed a proposed update (with diff highlighted).

Nothing that significant, but sending on the list with diff for transparency.



Regards,

Bruno

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pengshuping (Peng 
Shuping)
Sent: Thursday, December 5, 2019 4:12 AM
To: spring@ietf.org
Subject: [spring] Minutes for SPRING sessions at IETF 106 Singapore


Hi all,



The minutes for the two SPRING sessions at IETF 106 can be found at:


https://datatracker.ietf.org/meeting/106/materials/minutes-106-spring-01.txt

Please let me know if any changes may be needed. Thank you!

Regards,

Shuping


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

 SPRING WG - Source Packet Routing in Networking

    Chairs:
        Bruno Decraene <bruno.decra...@orange.com>
        Rob Shakir <ro...@google.com>

    Secretary:
        Shuping Peng <pengshup...@huawei.com>

===============================================================================

    Monday, November 18, 2019
    10:00 - 12:00, Monday Morning Session I
    Room: Padang


o Administrivia                                                                
[ 10 minutes ] 
   Chairs        
        - Note Well        
        - Scribe        
        - Blue Sheets        
        - Document Status        

Comments on the slide - Beyond SRv6
    On the slides: The WG should continue to progress SRv6. Regarding the 
several solutions reducing the header size, the authors need to be explicit 
about the goals and the costs of their proposals in their document. Let's 
complete SRv6 work that we have and we engaged with 6man, use the learnings 
there to try and guide some of these future decisions as to what the next steps 
after that should be.
    Kireeti Kompella: Is it the best approach for the IETF to complete SRv6 
before really digging into these other proposals? Or is it better for us to 
look at all of them and see if maybe there is something there that either we 
come back to SRv6 and do it slightly differently or maybe even say that it is 
not completely the best approach.
    Rob Shakir: It is pretty clear across the comments on the mailing list that 
there are folks who are using this technology. So it is not unusable if we 
publish it. 
    Kireeti Kompella: I was saying more like get a little further down the path 
of what's right and what's wrong about the current approach, and what are the 
things we want to fix? And if we then say the current approach is fine and then 
go ahead with that. But the idea that we complete this and use the learnings 
from this to inform the rest is fine but I think we could actually go a little 
further down the path of doing the analysis. 
    Rob Shakir: I think absolutely we should continue to examining these other 
bits of work but we would like to do, the Chairs and the ADs of SPRING, is to 
allow that to happen not necessarily in the framework for them being working 
group drafts. 
    Kireeti Kompella: Ok, all right thanks.
    Darren Dukes: Just to reiterate what you said. There are a lot of 
deployments. This stuff is deployed and this work is functional. It is 
implemented by multiple vendors. The standardization of it by this working 
group seems obvious at this point for SRv6. 
    Andrew Alston:The last bullet point is creating a potential situation where 
some work is potentially hostage to other work.   
    Rob Shakir: SRv6 is something that has been consensus of this working group 
to adopt. We have rough consensus for SRv6. There is rough consensus and 
running code, at this point I think it is difficult to argue though that we 
should not progress it. I don't think it is blocking other work. SR-MPLS 
progressed outside of having a working group and was adopted and had running 
code way before that time, and it did not stop that solution progressing. 
    James Guichard: IETF works on certain principles and processes. One of 
those processes is that the working group will work based on the charter. The 
current SPRING charter says that the working group is there to work on SR-MPLS 
and SRv6. We should not be working on anything that is incompatible in the data 
plane with the existing solutions that we are working on. Some of the other 
solutions that are not compatible with SRv6. If other work wants to be done use 
the right IETF process, go and get your own working group, change the charter 
and do whatever you need to do.
    Darren Dukes: We have done that process for SR-MPLS and SRv6. We have 
architecture and a lot of maturity. If these other solutions want to progress, 
at the very least they need to define why they are better and why this working 
group should be interested in them. There is no justification for these other 
solutions. 
    Rob Shakir: I think that is true for all proposals, not just true for 
alternative proposals, should be true for the amendments to the existing 
proposals. We should remember that the documents that we have adopted as 
working group are not individually owned any more.They are owned by the working 
group.Things go into the working group document should be by the consensus of 
working group not by the consensus of the authors of that work.   
    Ron Shakir: Let's complete SRv6. But you have not mentioned is the degree 
to which other solutions are blocked. The other solution got flow time? Will 
they be able to ask for call for adoption?  
    Rob Shakir: Flow time. If you look at the agenda over last n IETF the 
majority of our flow time is not all about the working group drafts. So 
absolutely we have been giving the individual drafts the time of the working 
group. If it is relevant to SPRING and specially there are discussions in the 
mailing list, it is fine to have flow time in this working group. 
    Ron Bonica: Adoption call?
    Rob Shakir: That is the discussion that we will have to have. It isnt clear 
to me that we have got a good pattern that says that this is the level of 
benefits that one has to demonstrate to adopt different. We do have huge amount 
of competing solutions that we are looking to adopt. Maybe what we did like the 
NSH draft and service programming draft. We had technical discussions about 
what the two work solve, and we adopted both. I dont think adoption is blocked. 
But we do have to have the consensus of the group about the work.    
    Ron Bonica: <...Typing and relaying...>
    Andrew Alston: Fair enough Adoption call is not out of the question. 
    Rob Shakir: The adoption will be based on the consensus of the working 
group. If charter update is required, then it is something that needs to be 
discussed with ADs.    

        
o SRv6 Network Programming                                                [ 20 
minutes ] 
    draft-ietf-spring-srv6-network-programming-05        
    Pablo Camarillo        
    
    Pablo Camarillo: Ask for WG Last call
    Ron Shakir: In the terminology section, you mentioned that a single packet 
can carry two SRHs, is it one per IP header or two for the same IP header?   
    Pablo Camarillo: In SRv6 network programming, we are not suggesting to 
craft a packet with two SRHs. But if we receive a packet with two SRHs, we must 
process according to RFC8200
    Ron Shakir: Can you add some text refer to RFC8200 saying that the packet 
should not carry two SRHs. But you will process it if it does.  
    Pablo Camarillo: But the draft is not suggesting to craft a packet with two 
SRHs.
    Ron Bonica: Actually if you read the terminology section, it makes the 
suggestion.
    Pablo Camarillo: We can discuss in the mailing list.     
    Greg Mirsky: If there are multiple SRHs, what would be the order of 
processing multiple headers? If segments left is zero in first header, what 
happens then?  
    Darren Dukes: RFC8200 says to process them in the order received.
    Ron Bonica: Whether you can always skip over the routing header when the 
segment left equals to zero where you still need to look at the Type and 
Lengths in TLVs.  
    Pablo Camarillo: The SRv6 network programming is defining how you process 
the SRH. Regarding the processing of other headers please refer to RFC 8200. It 
is not part of network programming.  
    Ron Bonica: What you are saying is if segment left equals to zero, you may 
ignore all the flags and tags and TLVs. 
    Pablo Camarillo: If segment left equals to zero then we dont process the 
SRH. 
    Ron Bonica: OK, excellent.  
    Darren Dukes: I think that we need text to describe that behavior, because 
I dont think it is necessarily the case. We need to add something there. 
    Zafar Ali: Ron's comment is more applicable to OAM. OAM draft does explain 
that and was discussed in the mailing list. When a packet received with its 
segment left equals to zero, and if the O bit is set and the TLV will be 
processed. 
    Ron Bonica: A bit of conflict. Needs to check RFC8200's requirement to skip 
over the routing header when the segment left equals to zero.   
    Zafar Ali: Let's discuss it in the context of OAM draft. It does not affect 
the network programming draft. 
    The authors think that it is ready for the WG Last Call.  
        
o YANG Data Model for SRv6 Base and Static                                [  5 
minutes ] 
    draft-raza-spring-srv6-yang-05        
    Sonal Agarwal         
    
    Acee Lindem: We did that in the base for a lot of things we thought would 
need to be augmented. It forces to use identities. This will help in the future 
to add more functions with augmentation.      
    Sonal Agarwal: Ask for WG adoption
    Bruno:
        Who read the draft?  about 15 persons
        Who believe it's a good start for a WG document? about 15 persons
        Who believe it's not a good start for a WG dcoument? nobody
    
o YANG Data Model for Segment Routing Policy                                [ 
10 minutes ] 
    draft-raza-spring-sr-policy-yang-02        
    Kamran Raza 
        
    Kamran Raza: Ask for WG adoption
    Shraddha Hegde: Config-Attributes tree. There is attribute section and 
affinity-map. Is it that you are modeling this SR policy as a link? Is it why 
there is this affinity-map here?
    Kamran Raza: The affinity map is for some of the dynamic constraint that 
you want to add to the policy. This could be leveraged from existing TE 
modelling. We are looking forward to see that how we can align with the color.
    Shraddha Hegde: The constraints for the dynamic policy?
    Kamran Raza: It is about constraints.     
    Bruno:
        Who has read the draft?  about 15 persons
        Who believe it's a good start for a WG document? about 15 persons
        Who believe it's not a good start for a WG dcoument? nobody
    
Unified Identifier in SRv6: use case and the solution                        [ 
10 minutes ]
o Unified Identifier usecase in IPv6 Segment Routing Networks                
    draft-wmsaxw-6man-usid-id-use-00                
o Unified Identifier in IPv6 Segment Routing Networks                         
    draft-mirsky-6man-unified-id-sr-04         
    Weiqiang Cheng 
    
    Ketan Talaulikar: The proposal is to put a lot of different mappings into 
the SRH which was meant for SRv6 SID. We have developed solutions in SPRING and 
MPLS WG for IPv6 using mappings and labels. SRv6 and SR-MPLS interworking draft 
is also related, we are looking for inputs on it.          
    Greg Mirsky: True, there is a proposal to do SR-MPLS over IP. The important 
benefit of SRH is that preserves the path information from the source to the 
destination. SR-MPLS does not do that. The differentiator of the unified SID 
proposal is to use SRH to preserve the path information of a SR-MPLS path, 
which is a benefit. Using SRH gives the benefit of path information being 
available to the egress. 
    Ketan: SRH is designed to carry SRv6 SID. Just using the header for 
carrying something different it is not really the same SRH. We have the 
interworking solution already, and should look at it. 
    Greg Mirsky: Surprised that SRH can only carry specific size of SID. Let's 
discuss on the list.
    Ketan Talaulikar: To clarify, I was saying that SRH carries the SRv6 SID. I 
didnot talk about the size of the SID.
    Kireeti Kompella: In the draft, you say that this is a way to upgrade from 
SRv6 to SR-MPLS. It is like going in the opposite direction. There are more 
SR-MPLS deployments than there are SRv6. It is useful to talk about that 
particular option. There are two bits. Are you also going to interoperate with 
SRm6? 
    Weiqiang Cheng: Free reserved bits are used. We just gave some examples. I 
dont think it breaks the SRv6 rules. 
    Greg Mirsky: It is good to emphasize that SR-MPLS and SRv6 are primary 
scenarios. In terms of the two-bit flag, we need to be compatible with the IPv6 
SIDs, so 00 is given. Two others are open for discusions. Suggestions are 
welcomed. 
    Darren Dukes: SR architecture is already RFC. SR-MPLS and SRv6 interworking 
draft. We have couple of compression mechanisms that work without mapping 
table. We have 18 implementations from different vendors and merchant silicon 
vendors are implementing SRv6 without a mapping table. There is no description 
of what this work (and also SRm6) brings to the working group or the community 
in large over what has been already defined in RFCs. What are the benefits? 
    Weiqiang Cheng: In the current POC, only the lookingup table. We could 
develop more smart way to optimise that. 
    Darren Dukes: A new document for describing the processing in details and 
comparison and justification of why this work is needed? 
    Weiqiang Cheng: Yes, the document will be built, and welcome comments. 
    Kamran Raza: Question about performance impact because of 2 lookup tables.
    Greg Mirsky: No additonal impact comparing with SR-MPLS over IP.
    Robin Li: Requirement is important. Statics information is good to have 
from CMCC on the size of the SID and its distribution. Once the requirement is 
clear then we can work on the solutions and analyze the cost accordingly.  
    Weiqiang Cheng: Ongoing work to deploy 35k nodes to support 5G backhaul in 
Bejing and have detailed calculation of required number of SIDs. Need to 
support more than 10 SIDs. Because of SRH overhead there is only 60% of 
capacity. We have optimise it otherwise we can not have large scale deployment. 
Future, we will have more detailed analysis in the control plane and management 
plane. 
    David Melman: Compared with micro-SID solution?
    Greg Mirsky: Activities for the future work. 
    Cheng Li: There is also another work on SRv6 compression. It would be good 
to make this kind of comparison. 
    Ron Bonica: For the Beijing network if you tried the micro SID solution, 
you would need /32 so it is not a reliable solution.  
    Bruno Decraene: It is the topic belongs to "Beyond SRv6". First we need to 
agree with what the goals are. Then we need to discuss the benefits and costs 
of each solution. We would like to converge the solutions in SPRING first. So 
far it is within SPRING.   
    Greg Mirsky: Where is this work to continue? Suggestion from Chair. 
    Bruno Decraene: So far it is up to the authors. 
            
o Segment Routing Mapped To IPv6 (SRm6)                                        
[ 10 minutes ] 
    draft-bonica-spring-srv6-plus-06        
    Reji on behalf of Ron Bonica        
    
    Darren Dukes: You have not changed the title of the draft yet. It caused 
confusions. 
    Reji Thomas: will update it. 
    Darren Dukes: We dont see any justification for this work to be involved in 
SPRING. It is not in the current Charter. 
    Reji Thomas: There are customers who are interested in SRm6.
    Andrew Alston: Justification has been pointed out in the mailing list. 
    Darren Dukes: SRv6 has architecture and control plane work, and 
deployments. Now you are suggesting the working group to work on something 
else. But there is no justification. Onus is on the authors of this draft.
    Andrew Alston: Both work should exist and progress. Should let the 
operators to choose. SRH is in 6man. The micro SID draft actually acknowledged 
that there is the overhead problem. 
    Martin Vigoureux: SRH is in the RFC editor queue, not in 6man anymore. 
    Darren Dukes: A lot of background work built for SRv6. There is not the 
same background in the working group for SRm6 and SRv6.   
    Andrew Alston: Not sure what is wanted from the SRm6 authors/co-authors? 
    Ketan Talaulikar: We already have work done on this topic. Why this cannot 
be achieved with what we have done with SR-MPLS?
    Andrew Alston: There is a demand in the market to move away from MPLS 
labels at the top of the packet. No desire to slow down ongoing SRv6 work.
    Ketan Talaulikar: The mechanisms needed have already been done, why again?
    Andrew Alston: Operators want a choice. We believe that all alternatives 
should proceed. 
    Ron Bonica: The difference of SRm6 is stated at the end of the draft. We 
can call out the motivations in the next revision.
    Darren Dukes: Content in section 9 is resolved with SRv6 in the current 
form. Needs more arugments in the draft to discuss.
    Zafar Ali: SRm6 requires new control plane and new data plane and new 
architecture. Then what about the past many years on SRv6?
    James Guichard: SRm6 is not compatible with SRv6,and it is not in the 
current SPRING Charter. 
    Ron Bonica: Nobody is departing a new dataplane. 
    Andrew Alston: SRm6 is on the v6 data plane.  Not an incompatible data 
plane. 
    James Guichard: That can also be done with SRv6 as well. Two completely 
incompatible solutions are not desired. 
    Ron Bonica: In order to really be compliant with the charter we need to 
comply both with RFC8200.  
    John Scudder: Disappointing this debate is still going on. 
    Robin Li: Requirements must be cleared, and the two types of requirements 
need to be distinguished: 1) to reduce the SRv6 SID size 2) to propose new IPv6 
based SR solutions. It is not reasonable to produce a new IPv6 based SR 
solution just for reducing the SRv6 SID size. It is a process issue, AD's email 
already asked to refocus to SRv6. SRm6 work should follow the IETF process, 
starting with the Problem statement and then the following process. 
    Pablo Camarillo: This draft is not defining segment routing as defined in 
RFC8402. Why call it segment routing? 
    Rob Shakir: Renaming it to something different won't change the problem 
space.    
    Xing Li: China Education and Research Network (CERNET2) is the largest IPv6 
only network and been running SRv6. We found that shorter SID has some 
benefits. We support both proposals. We should open our eyes for the new work. 
    Kamran Raza: How many are on ASIC based implementation, and how many of 
those options at the line rate you can process?
    Reji Thomas: A VPN level part can be processed on a line rate. 
    Cheng Li: Think about the cost of processing DOH TLV when you are talking 
about reducing the overhead of SRH. Overhead and processing cost should be 
considered.  
    Andrew Alston: Ask for adoption of the SRm6 overview draft. 
    Bruno Decraene: Need to ensure we understand the problem as we're hearing 
different things, also from the draft authors. 
    Rob Shakir: Same comments will be raised if we do a call for adoption so we 
need to address those before that.

o Path Segment for SRv6 (Segment Routing in IPv6)                        [  7 
minutes ] 
    draft-li-spring-srv6-path-segment-04        
    Cheng Li 
        
    Cheng Li: ask for WG Adoption
    Weiqiang Cheng: Solution is important, especially for the large network 
operation. 
        
o Segment Routing Header encapsulation for In-situ OAM Data                [ 10 
minutes ] 
    draft-ali-spring-ioam-srv6-02        
    Zafar Ali    
    <SKIPPED>      
                
o An Experiment of SRv6 Service Chaining at Interop Tokyo 2019 ShowNet        [ 
 5 minutes ] 
    draft-upa-srv6-service-chaining-exp-00        
    Ryo Nakamura

The session is cut off from here. 
---------------------------------------------------------------------------------------------------------------
     
        
        
o SRv6 Tagging proxy                                                        [ 
10 minutes ] 
    draft-eden-srv6-tagging-proxy-00        
    Yukito Ueno           
        
o SRv6 for Deterministic Networking (DetNet)                                [ 
10 minutes ] 
    draft-geng-spring-srv6-for-detnet-00         
o DetNet SRv6 Data Plane Encapsulation        
    draft-geng-detnet-dp-sol-srv6-01         
    Xuesong Geng  
        
Total Presentation Time:            107 minutes
Speaker Shuffling Time/Buffer:      12 minutes


===============================================================================

    Thursday, November 21, 2019
    15:50-17:20, Thursday Afternoon session II
    Room: Canning


o Administrivia                                                                 
               [  5 minutes ] 
   Chairs        
        - Note Well        
        - Scribe        
        - Blue Sheets        
        - Document Status        
        
    o SR Replication Segment for Multi-point Service Delivery                   
             [ 10 minutes ]
    draft-voyer-spring-sr-replication-segment-00
    Zafar Ali
    
    Zafar: The authors ask for WG adoption.
    Wim: It is a good idea. It is a easy way to support multicast. 
    Himanshu£º Support the draft. Good ingress replication, pretty 
straightforward. 
    
    
    o BGP-LS Extensions for Inter-As TE using EPE based mechanisms              
                  [  5 minutes ]
    draft-hegde-idr-bgp-ls-epe-inter-as-02
    Shraddha Hegde 
    
    Acee Lindem: F stands for FRR, right?
    Shraddha Hegde: Yes. 
    Aijun Wang: Doesnt need every ASBR to run the protocol. 
    Shraddha Hegde: Yes. 
    Aijun Wang: In our network, the nodes are actually connected to ASBR, there 
maybe some extensibility issue. 
    Shraddha Hegde: This mechanism is only for Inter-area path. 



o Performance Measurement Using TWAMP Light for Segment Routing Networks        
        [ 10 minutes ]
    draft-gandhi-spring-twamp-srpm-04
    
    Bruno Decraene: how many have read the draft? - 10-15 persons
    Bruno Decraene: How many agree to adopt the draft? About the same amount. 
    Bruno Decraene: To further confirm in the list. 

o Segment Routing Generic TLV for MPLS Label Switched Path (LSP) 
Ping/Traceroute        [ 10 minutes ]
    draft-nainar-mpls-spring-lsp-ping-sr-generic-sid-00
    Nagendra / Zafar 
    
    Sam Aldrin: If anycast, what is the procedure to use to validate?
    Ketan Talaulikar: As long as it reached the anycast node, it is all good. 
Discuss offline. 
    Sam Aldrin: How many other types of SID have been defined? Are you going to 
repeat the definition?
    Zafar Ali: If not covered yet, we will continue. Good to have an option for 
new definition. Asking for more feedback.
    Shraddha Hegde: Agree with Sam. We may find more corner cases. 
    Zafar Ali: Please check the slides on Monday. 
    Tarek Saad: Valid the assigner, what the SID is assigned to is missing. 
Just to valid the label is reasonable. Dont think you can deprecated the other 
effects that are defined. 
    Zafar Ali: Agree. 
    Jabber question from Srihari Ramachandra: if the link between 7 and 8 
becomes unidirectional, would you be able to define it?
    Zafar Ali: Yes. 
    Greg Mirsky: It is also open to others. 
    Zafar Ali: Let's keep the option open. It is SR focused. 
        

o Segment-Routing over Forwarding Adjacency Links                               
         [ 10 minutes ]
    draft-saad-sr-fa-link-00
    Tarek Saad 
    
    Dhruv Dhody: Would you compare this to binding SID?
    Tarek Saad: It can be a BSID. It can multiple LSPs. 
    Dhruv Dhody: What is the benefit offering? 
    Tarek Saad: There is no standard way how you push it into the TED.
    Dhruv Dhody: When would this link go down?    
    Peter Psenak: What is the difference from regular SR TE Policy?  
    Tarek Saad: FA link can be supported by one SR policy or multiple SR 
policies.
    Peter Psenak: So this is not traditional fowarding adjacency as we know it 
from RSVP-TE? 
    Tarek Saad: FA link is a traffic engineering link. Please refer to the RFC 
I listed in the slides.
    Peter Psenak: As long as you dont advertise this as a link in the IGP 
topology it is fine. 
    Ketan Talaulikar: Please refer to the draft we have for exporting such link 
via BGP-LS. The difference is not done as a link NLRI but as a TE Policy NLRI.
    Tarek Saad: Draft is gone through. Here it is just a link. 
    Ketan Talaulikar: Just want to see if you want to add those on the SR 
policy.
    Tarek Saad: Sure, let's talk about it. 
    Robin Li: Only SR-MPLS or both SR-MPLS and SRv6? 
    Tarek Saad: Both. 
    Jeff Tantsura: Please refer to a draft published on integration of IP and 
optical.  
    Tarek Saad: ok. 

o Segment Routing for Enhanced VPN Service                                      
          [ 10 minutes ]
    draft-dong-spring-sr-for-enhanced-vpn-05
    Jie Dong 
    WG adoption has been requested.
  
    Bruno Decraene: The work in TEAS is generic. 
    Bruno Decraene: who read the draft and who support? about the same 15-20
    Bruno Decraene: who think it is not ready? about 1-2 person. Now there is a 
design team on network slicing. We need to wait a bit for the outcome of the 
design team. 
    Jie Done: The work can be decoupled. VPN+ framework is already adopted in 
TEAS. This is a solution for VPN+ and network slicing is one of its use cases. 
No need to rely on the work of design team in TEAS.
    Bruno Decraene: The name of the draft is a bit of marketing, could be 
useful to focus on what is added, such as network resource partitioning, and 
needs to fix the introduction. Terminologies need to be clarified.    
    Jeff Tantsura: The design team's focus is not about the technology as such 
but the northbound API. Not going to work on this specifically. Please use the 
same term of 
    Jie Dong: Sure. 
    Fengwei Qin: The draft is a good idea and reflect the use cases. 
    Ran Chen: Agree with Jeff. Out of scope of the design team. Another 
proposal will be presented later. 
    Jie Dong: This is only on data plane. Control plane extensions are in other 
drafts. 
    Bruno Decraene: Please send comments to the mailing list. 
    Rakesh Gandhi: Requirement and framework are in the scope of the design 
team. We need to make progress in requirements and framework. 
    Greg Mirsky: Encourage to work on the model that includes both resource 
sharing and isolation cases. 
    Jie Dong: The two cases are already covered and we have clarified in the 
draft. 
    Greg Mirsky: There are other resources.
    Jie Dong: We can discuss more.
    Bruno Decraene: Need to discuss on the list. You need to refine the draft 
to make the abstract and introduction inline with the scope, maybe rephrase as 
partitioning of network resources.       


o Building blocks for Slicing in Segment Routing Network                        
        [  8 minutes ]
    draft-ali-spring-network-slicing-building-blocks-02 
    Zafar Ali 
    
    Bruno Decraene: The first page is a good summary of all the tools we have 
in SPRING. What tools are missing in SPRING to fullfil the requirements for 
network slicing? One part could be a segregation of resources within the 
network. 
    Jeff Tantsura: Use terminology correctly. It is not network slicing.
    Bruno Decraene/Zafar Ali: Please send comments on the list. 
    Zhenqiang Li: Please add resource segment presented by Jie to the building 
blocks. 

o Packet Network Slicing using Segment Routing                                  
              [ 10 minutes ]
    draft-peng-teas-network-slicing-01
    Fengwei Qin 
    
    Bruno Decraene: Please mainly talk about the difference since we know the 
concept. 
    Bruno Decraene: Since we don't have enough time, we dont have time for the 
details. We will refer to the TEAS design team's outcome. 
    
The session is cut off from here. 

------------------------------------------------------------------------------------------------------------------------
 

o The Use of Path Segment in SR Inter-domain Scenarios                          
              [  5 minutes ]
    draft-xiong-spring-path-segment-sr-inter-domain-01
    Quan Xiong 

        
Total Presentation Time:            83 minutes
Speaker Shuffling Time/Buffer:      7 minutes
Title: wdiff minutes-106-spring-01.txt minutes-106-spring-01-Bruno.txt
 SPRING WG - Source Packet Routing in Networking

    Chairs:
        Bruno Decraene <bruno.decra...@orange.com>
        Rob Shakir <ro...@google.com>

    Secretary:
        Shuping Peng <pengshup...@huawei.com>

===============================================================================

    Monday, November 18, 2019
    10:00 - 12:00, Monday Morning Session I
    Room: Padang

o Administrivia                                                                [ 10 minutes ]
   Chairs
        - Note Well
        - Scribe
        - Blue Sheets
        - Document Status

Comments on the slide - Beyond SRv6
    On the slides: The WG should continue to progress SRv6. Regarding the several solutions reducing the header size, the authors need to be explicit about the goals and the costs of their proposals in their document. Let's complete SRv6 work that we have and we engage engaged with 6man, use the learnings there to try and guide some of these future decisions as to what the next steps after that should be.
    Kireeti Kompella: Is it the best approach for the IETF to complete SRv6 before really digging into these other proposals? Or is it better for us to look at all of them and see if maybe there is something there that either we come back to SRv6 and do it slightly differently or maybe even say that it is not completely the best approach.
    Rob Shakir: It is pretty clear across the comments on the mailing list that there are folks who are using this technology. So it is not unusable if we publish it.
    Kireeti Kompella: I was saying more like get a little further down the path of what's right and what's wrong about the current approach, and what are the things we want to fix? And if we then say the current approach is fine and then go ahead with that. But the idea that we complete this and use the learnings from this to inform the rest is fine but I think we could actually go a little further down the path of doing the analysis.
    Rob Shakir: I think absolutely we should continue to examining these other bits of work but we would like to do, the Chairs and the ADs of SPRING, is to allow that to happen not necessarily in the framework for them being working group drafts.
    Kireeti Kompella: Ok, all right thanks.
    Darren Dukes: Just to reiterate what you said. There are a lot of deployments. This stuff is deployed and this work is functional. It is implemented by multiple vendors. The standardisation standardization of it by this working group seems obivious obvious at this point for SRv6.
    Andrew Alston:The last bullet point is creating a potential situation where some work is potentially hostage to other work.
    Rob Shakir: SRv6 is something that has been consensus of this working group to adopt. We have rough consensus for SRv6. There is rough consensus and running code, at this point I think it is difficult to argue though that we should not progress it. I dont don't think it is blocking other work.SR-MPLS work. SR-MPLS progressed outside of having a working group and was adopted and had running code way before that time, and it did not stop that solution progressing.
    James Guichard: IETF works on certain principles and progresses. processes. One of those progesses processes is that the working group will work based on the charter. The current SPRING charter says that the working group is there to work on SR-MPLS and SRv6. We should not be working on anything that is incompatible in the data plane with the existing solutions that we are working on. Some of the other solutions that are not compatible with SRv6. If other work wants to be done use the right IETF process, go and get your own working group, change the charter and do whatever you need to do.
    Darren Dukes: We have done that process for SR-MPLS and SRv6. We have architecture and a lot of maturity. If these other solutions want to progress, at the very least they need to define why they are better and why this working group should be interested in them. There is no justification for these other solutions.
    Rob Shakir: I think that is true for all proposals, not just true for alternative proposals, should be true for the amendaments amendments to the existing proposals. We should remember that the documents that we have adopted as working group are not individually owned any more.They are owned by the working group.Things go into the working group document should be by the consensus of working group not by the consensus of the authors of that work.
    Ron Shakir: Let's complete SRv6. But you have not mentioned is the degree to which other solutions are blocked. The other solution got flow time? Will they be able to ask for call for adoption?
    Rob Shakir: Flow time. If you look at the agenda over last n IETF the majority of our flow time is not all about the working group drafts. So absolutely we have been giving the individual drafts the time of the working group. If it is relevant to SPRING and specially there are discussions in the mailing list, it is fine to have flow time in this working group.
    Ron Bonica: Adoption call?
    Rob Shakir: That is the discussion that we will have to have. It isnt clear to me that we have got a good pattern that says that this is the level of benefits that one has to demonstrate to adopt different. We dont do have huge amount of competing solutions that we are looking to adopt. Maybe what we did like the NSH draft and service programming draft. We had technical discussions about what the two work solve, and we adopted both. I dont think adoption is blocked. But we do have to have the consensus of the group about the work.
    Ron Bonica: <...Typing and relaying...>
    Andrew Alston: Fair enough Adoption call is not out of the question.
    Rob Shakir: The adoption will be based on the consensus of the working group. If charter update is required, then it is something that needs to be discussed with ADs.

o SRv6 Network Programming                                                [ 20 minutes ]
    draft-ietf-spring-srv6-network-programming-05
    Pablo Camarillo

    Pablo Camarillo: Ask for WG Last call
    Ron Shakir: In the terminology section, you mentioned that a single packet can carry two SRHs, is it one per IP header or two for the same IP header?
    Pablo Camarillo: In SRv6 network programming, we are not suggesting to craft a packet with two SRHs. But if we receive a packet with two SRHs, we must process according to RFC8200
    Ron Shakir: Can you add some text refer to RFC8200 saying that the packet should not carry two SRHs. But you will process it if it does.
    Pablo Camarillo: But the draft is not suggesting to craft a packet with two SRHs.
    Ron Bonica: Actually if you read the terminology section, it makes the suggestion.
    Pablo Camarillo: We can discuss in the mailing list.
    Greg Mirsky: If there are multiple SRHs, what would be the order of processing multiple headers? If segments left is zero in first header, what happens then?
    Darren Dukes: RFC8200 says to process them in the order received.
    Ron Bonica: Whether you can always skip over the routing header when the segment left equals to zero where you still need to look at the Type and Lengths in TLVs.
    Pablo Camarillo: The SRv6 network programming is defining how you process the SRH. Regarding the processing of other headers please refer to RFC 8200. It is not part of network programming.
    Ron Bonica: What you are saying is if segment left equals to zero, you may ignore all the flags and tags and TLVs.
    Pablo Camarillo: If segment left equals to zero then we dont process the SRH.
    Ron Bonica: OK, excellent.
    Darren Dukes: I think that we need text to describe that behavior, because I dont think it is necessarily the case. We need to add something there.
    Zafar Ali: Ron's comment is more applicable to OAM. OAM draft does explain that and was discussed in the mailing list. When a packet received with its segment left equals to zero, and if the O bit is set and the TLV will be processed.
    Ron Bonica: A bit of conflict. Needs to check RFC8200's requirement to skip over the routing header when the segment left equals to zero.
    Zafar Ali: Let's discuss it in the context of OAM draft. It does not affect the network programming draft.
    The authors think that it is ready for the WG Last Call.

o YANG Data Model for SRv6 Base and Static                                [  5 minutes ]
    draft-raza-spring-srv6-yang-05
    Sonal Agarwal

    Acee Lindem: We did that in the base for a lot of things we thought would need to be augmented. It forces to use identities. This will help in the future to add more functions with augmentation.
    Sonal Agarwal: Ask for WG adoption
    The Chair called
    Bruno:
	Who read the draft?  about 15 persons
	Who believe it's a good start for a WG adoption document? about 15 persons
	Who believe it's not a good start for a WG dcoument? nobody

o YANG Data Model for Segment Routing Policy                                [ 10 minutes ]
    draft-raza-spring-sr-policy-yang-02
    Kamran Raza

    Kamran Raza: Ask for WG adoption
    Shraddha Hegde: Config-Attributes tree. There is attribute section and affinity-map. Is it that you are modeling this SR policy as a link? Is it why there is this affinity-map here?
    Kamran Raza: The affinity map is for some of the dynamic constraint that you want to add to the policy. This could be leveraged from existing TE modelling. We are looking forward to see that how we can align with the color.
    Shraddha Hegde: The constraints for the dynamic policy?
    Kamran Raza: It is about constraints.
    The chair called
    Bruno:
	Who has read the draft?  about 15 persons
	Who believe it's a good start for a WG adoption. document? about 15 persons
	Who believe it's not a good start for a WG dcoument? nobody

Unified Identifier in SRv6: use case and the solution                        [ 10 minutes ]
o Unified Identifier usecase in IPv6 Segment Routing Networks
    draft-wmsaxw-6man-usid-id-use-00
o Unified Identifier in IPv6 Segment Routing Networks
    draft-mirsky-6man-unified-id-sr-04
    Weiqiang Cheng

    Ketan Talaulikar: The proposal is to put a lot of different mappings into the SRH which was meant for SRv6 SID. We have developed solutions in SPRING and MPLS WG for IPv6 using mappings and labels. SRv6 and SR-MPLS interworking draft is also related, we are looking for inputs on it.
    Greg Mirsky: Ture, True, there is a proposal to do SR-MPLS over IP. The important benefit of SRH is that preserves the path information from the source to the destination. SR-MPLS does not do that. The differentiator of the unified SID proposal is to use SRH to preserve the path information of a SR-MPLS path, which is a benefit. Using SRH gives the benefit of path information being available to the egress.
    Ketan: SRH is designed to carry SRv6 SID. Just using the header for carrying something different it is not really the same SRH. We have the interworking solution already, and should look at it.
    Greg Mirsky: Surprised that SRH can only carry specific size of SID. Let's discuss on the list.
    Ketan Talaulikar: To clarify, I was saying that SRH carries the SRv6 SID. I didnot talk about the size of the SID.
    Kireeti Kompella: In the draft, you say that this is a way to upgrade from SRv6 to SR-MPLS. It is like going in the opposite direction. There are more SR-MPLS deployments than there are SRv6. It is useful to talk about that particular option. There are two bits. Are you also going to interoperate with SRm6?
    Weiqiang Cheng: Flahe Free reserved bits are used. We just gave some examples. I dont think it breaks the SRv6 rules.
    Greg Mirsky: It is good to emphasize that SR-MPLS and SRv6 are primary scenarios. In terms of the two-bit flag, we need to be compatible with the IPv6 SIDs, so 00 is given. Two others are open for discusions. Suggestions are welcomed.
    Darren Dukes: SR architecture is already RFC. SR-MPLS and SRv6 interworking draft. We have couple of compression mechanisms that work without mapping table. We have 18 implementions implementations from different vendors and merchant silicon venfors vendors are implementing SRv6 without a mapping table. There is no description of what this work (and also SRm6) brings to the working group or the community in large over what has been already defined in RFCs. What are the benefits?
    Weiqiang Cheng: In the current POC, only the lookingup table. We could develop more smart way to optimise that.
    Darren Dukes: A new document for describing the processing in details and comparison and justification of why this work is needed?
    Weiqiang Cheng: Yes, the document will be built, and welcome comments.
    Kamran Raza: Question about performance impact because of 2 lookup tables.
    Greg Mirsky: No additonal impact comparing with SR-MPLS over IP.
    Robin Li: Requirement is important. Statics information is good to have from CMCC on the size of the SID and its distribution. Once the requirement is clear then we can work on the solutions and analyze the cost accordingly.
    Weiqiang Cheng: Ongoing work to deploy 35k nodes to support 5G backhaul in Bejing and have detailed calculation of required number of SIDs. Need to support more than 10 SIDs. Because of SRH overhead there is only 60% of capacity. We have optimise it otherwise we can not have large scale deployment. Future, we will have more detailed analysis in the control plane and management plane.
    David Melman: Compared with micro-SID solution?
    Greg Mirsky: Activities for the future work.
    Cheng Li: There is also another work on SRv6 compression. It would be good to make this kind of comparison.
    Ron Bonica: For the Beijing network if you tried the micro SID solution, you would need /32 so it is not a reliable solution.
    Bruno Decraene: It is the topic belongs to "Beyond SRv6". First we need to agree with what the goals are. Then we need to discuss the benefits and costs of each solution. We would like to converge the solutions in SPRING first. So far it is within SPRING.
    Greg Mirsky: Where is this work to continue? Suggestion from Chair.
    Bruno Decraene: So far it is up to the authors.

o Segment Routing Mapped To IPv6 (SRm6)                                        [ 10 minutes ]
    draft-bonica-spring-srv6-plus-06
    Reji on behalf of Ron Bonica

    Darren Dukes: You have not changed the title of the draft yet. It caused confusions.
    Reji Thomas: will update it.
    Darren Dukes: We dont see any justification for this work to be involved in SPRING. It is not in the current Charter.
    Reji Thomas: There are customers who are interested in SRm6.
    Andrew Alston: Justification has been pointed out in the mailing list.
    Darren Dukes: SRv6 has architecture and control plane work, and deployments. Now you are suggesting the working group to work on something else. But there is no justification. Onus is on the authors of this draft.
    Andrew Alston: Both work should exist and progress. Should let the operators to choose. SRH is in 6man. The micro SID draft actually acknowledged that there is the overhead problem.
    Martin Vigoureux: SRH is in the RFC editor queue, not in 6man anymore.
    Darren Dukes: A lot of background work built for SRv6. There is not the same background in the working group for SRm6 and SRv6.
    Andrew Alston: Not sure what is wanted from the SRm6 authors/co-authors?
    Ketan Talaulikar: We already have work done on this topic. Why this cannot be achieved with what we have done with SR-MPLS?
    Andrew Alston: There is a demand in the market to move away from MPLS labels at the top of the packet. No desire to slow down ongoing SRv6 work.
    Ketan Talaulikar: The mechanisms needed have already been done, why again?
    Andrew Alston: Operators want a choice. We believe that all alternatives should proceed.
    Ron Bonica: The difference of SRm6 is stated at the end of the draft. We can call out the motivations in the next revision.
    Darren Dukes: Content in section 9 is resolved with SRv6 in the current form. Needs more arugments in the draft to discuss.
    Zafar Ali: SRm6 requires new control plane and new data plane and new architecture. Then what about the past many years on SRv6?
    James Guichard: SRm6 is not compatible with SRv6,and it is not in the current SPRING Charter.
    Ron Bonica: Nobody is departing a new dataplane.
    Andrew Alston: SRm6 is on the v6 data plane.  Not an incompatible data plane.
    James Guichard: That can also be done with SRv6 as well. Two completely incompatible sotuions solutions are not desired.
    Ron Bonica: In order to really be compliant with the charter we need to comply both with RFC8200.
    John Scudder: Disappointing this debate is still going on.
    Robin Li: Requirements must be cleared, and the two types of requirements need to be distinguished: 1) to reduce the SRv6 SID size 2) to propose new IPv6 based SR solutions. It is not reasonable to produce a new IPv6 based SR solution just for reducing the SRv6 SID size. It is a process issue, AD's email already asked to refocus to SRv6. SRm6 work should follow the IETF process, starting with the Problem statement and then the following process.
    Pablo Camarillo: This draft is not defining segment routing as defined in RFC8402. Why call it segment routing?
    Rob Shakir: Renaming it to something different won't change the problem space.
    Xing Li: China Education and Research Network (CERNET2) is the largest IPv6 only network and been running SRv6. We found that shorter SID has some benefits. We support both proposals. We should open our eyes for the new work.
    Kamran Raza: How many are on ASIC based implementation, and how many of those options at the line rate you can process?
    Reji Thomas: A VPN level part can be processed on a line rate.
    Cheng Li: Think about the cost of processing DOH TLV when you are talking about reducing the overhead of SRH. Overhead and processing cost should be considered.
    Andrew Alston: Ask for adoption of the SRm6 overview draft.
    Bruno Decraene: Need to ensure we understand the problem as we're hearing different things, also from the draft authors.
    Rob Shakir: Same comments will be raised if we do a call for adoption so we need to address those before that.

o Path Segment for SRv6 (Segment Routing in IPv6)                        [  7 minutes ]
    draft-li-spring-srv6-path-segment-04
    Cheng Li

    Cheng Li: ask for WG Adoption
    Weiqiang Cheng: Solution is important, especially for the large network operation.

o Segment Routing Header encapsulation for In-situ OAM Data                [ 10 minutes ]
    draft-ali-spring-ioam-srv6-02
    Zafar Ali
    <SKIPPED>

o An Experiment of SRv6 Service Chaining at Interop Tokyo 2019 ShowNet        [  5 minutes ]
    draft-upa-srv6-service-chaining-exp-00
    Ryo Nakamura

The session is cut off from here.
---------------------------------------------------------------------------------------------------------------

o SRv6 Tagging proxy                                                        [ 10 minutes ]
    draft-eden-srv6-tagging-proxy-00
    Yukito Ueno

o SRv6 for Deterministic Networking (DetNet)                                [ 10 minutes ]
    draft-geng-spring-srv6-for-detnet-00
o DetNet SRv6 Data Plane Encapsulation
    draft-geng-detnet-dp-sol-srv6-01
    Xuesong Geng

Total Presentation Time:            107 minutes
Speaker Shuffling Time/Buffer:      12 minutes

===============================================================================

    Thursday, November 21, 2019
    15:50-17:20, Thursday Afternoon session II
    Room: Canning

o Administrivia                                                                                [  5 minutes ]
   Chairs
        - Note Well
        - Scribe
        - Blue Sheets
        - Document Status

    o SR Replication Segment for Multi-point Service Delivery                                [ 10 minutes ]
    draft-voyer-spring-sr-replication-segment-00
    Zafar Ali

    Zafar: The authors ask for WG adoption.
    Wim: It is a good idea. It is a easy way to support multicast.
    Himanshu�� Support the draft. Good ingress replication, pretty straightforward.

    o BGP-LS Extensions for Inter-As TE using EPE based mechanisms                                [  5 minutes ]
    draft-hegde-idr-bgp-ls-epe-inter-as-02
    Shraddha Hegde

    Acee Lindem: F stands for FRR, right?
    Shraddha Hegde: Yes.
    Aijun Wang: Doesnt need every ASBR to run the protocol.
    Shraddha Hegde: Yes.
    Aijun Wang: In our network, the nodes are actually connected to ASBR, there maybe some extensibility issue.
    Shraddha Hegde: This mechanism is only for Inter-area path.

o Performance Measurement Using TWAMP Light for Segment Routing Networks                [ 10 minutes ]
    draft-gandhi-spring-twamp-srpm-04

    Bruno Decraene: how many have read the draft? - 10%-15% 10-15 persons
    Bruno Decraene: How many agree to adopt the draft? About the same amount.
    Bruno Decraene: To further confirm in the list.

o Segment Routing Generic TLV for MPLS Label Switched Path (LSP) Ping/Traceroute        [ 10 minutes ]
    draft-nainar-mpls-spring-lsp-ping-sr-generic-sid-00
    Nagendra / Zafar

    Sam Aldrin: If anycast, what is the procedure to use to validate?
    Ketan Talaulikar: As long as it reached the anycast node, it is all good. Discuss offline.
    Sam Aldrin: How many other types of SID have been defined? Are you going to repeat the definition?
    Zafar Ali: If not covered yet, we will continue. Good to have an option for new definition. Asking for more feedback.
    Shraddha Hegde: Agree with Sam. We may find more corner cases.
    Zafar Ali: Please check the slides on Monday.
    Tarek Saad: Valid the assigner, what the SID is assigned to is missing. Just to valid the label is reasonable. Dont think you can deprecated the other effects that are defined.
    Zafar Ali: Agree.
    Jabber question from Srihari Ramachandra: if the link between 7 and 8 becomes unidirectional, would you be able to define it?
    Zafar Ali: Yes.
    Greg Mirsky: It is also open to others.
    Zafar Ali: Let's keep the option open. It is SR focused.

o Segment-Routing over Forwarding Adjacency Links                                        [ 10 minutes ]
    draft-saad-sr-fa-link-00
    Tarek Saad

    Dhruv Dhody: Would you compare this to binding SID?
    Tarek Saad: It can be a BSID. It can multiple LSPs.
    Dhruv Dhody: What is the benefit offering?
    Tarek Saad: There is no standard way how you push it into the TED.
    Dhruv Dhody: When would this link go down?
    Peter Psenak: What is the difference from regular SR TE Policy?
    Tarek Saad: FA link can be supported by one SR policy or multiple SR policies.
    Peter Psenak: So this is not traditional fowarding adjacency as we know it from RSVP-TE?
    Tarek Saad: FA link is a traffic engineering link. Please refer to the RFC I listed in the slides.
    Peter Psenak: As long as you dont advertise this as a link in the IGP topology it is fine.
    Ketan Talaulikar: Please refer to the draft we have for exporting such link via BGP-LS. The difference is not done as a link NLRA NLRI but as a TE Policy NLRA. NLRI.
    Tarek Saad: Draft is gone through. Here it is just a link.
    Ketan Talaulikar: Just want to see if you want to add those on the SR policy.
    Tarek Saad: Sure, let's talk about it.
    Robin Li: Only SR-MPLS or both SR-MPLS and SRv6?
    Tarek Saad: Both.
    Jeff Tantsura: Please refer to a draft published on integration of IP and optical.
    Tarek Saad: ok.

o Segment Routing for Enhanced VPN Service                                                [ 10 minutes ]
    draft-dong-spring-sr-for-enhanced-vpn-05
    Jie Dong
    WG adoption has been requested.

    Bruno Decraene: The work in TEAS is generic.
    Bruno Decraene: who read the draft and who support? about the same 15-20
    Bruno Decraene: who think it is not ready? about 1-2 person. Now there is a design team on network slicing. We need to wait a bit for the outcome of the design team.
    Jie Done: The work can be decoupled. VPN+ framework is already adopted in TEAS. This is a solution for VPN+ and network slicing is one of its use cases. No need to rely on the work of design team in TEAS.
    Bruno Decraene: The name of the draft is a bit of marketing, could be useful to focus on what is added, such as network resource partitioning, and needs to fix the introduction. Terminologies need to be clarified.
    Jeff Tantsura: The design team's focus is not about the technology as such but the northbound API. Not going to work on this specifically. Please use the same term of
    Jie Dong: Sure.
    Fengwei Qin: The draft is a good idea and reflect the use cases.
    Ran Chen: Agree with Jeff. Out of scope of the design team. Another proposal will be presented later.
    Jie Dong: This is only on data plane. Control plane extensions are in other drafts.
    Bruno Decraene: Please send comments to the mailing list.
    Rakesh Gandhi: Requirement and framework are in the scope of the design team. We need to make progress in requirements and framework.
    Greg Mirsky: Encourage to work on the model that includes both resource sharing and isolation cases.
    Jie Dong: The two cases are already covered and we have clarified in the draft.
    Greg Mirsky: There are other resources.
    Jie Dong: We can discuss more.
    Bruno Decraene: Need to discuss on the list. You need to refine the draft to make the abstract and introduction inline with the scope, maybe rephrase as partitioning of network resources.

o Building blocks for Slicing in Segment Routing Network                                [  8 minutes ]
    draft-ali-spring-network-slicing-building-blocks-02
    Zafar Ali

    Bruno Decraene: The first page is a good summary of all the tools we have in SPRING. What tools are missing in SPRING to fullfil the requirements for network slicing? One part could be a segregation of resources within the network.
    Jeff Tantsura: Use terminology correctly. It is not network slicing.
    Bruno Decraene/Zafar Ali: Please send comments on the list.
    Zhenqiang Li: Please add resource segment presented by Jie to the building blocks.

o Packet Network Slicing using Segment Routing                                                [ 10 minutes ]
    draft-peng-teas-network-slicing-01
    Fengwei Qin

    Bruno Decraene: Please mainly talk about the difference since we know the concept.
    Bruno Decraene: Since we don't have enough time, we dont have time for the details. We will refer to the TEAS design team's outcome.

The session is cut off from here.

------------------------------------------------------------------------------------------------------------------------

o The Use of Path Segment in SR Inter-domain Scenarios                                        [  5 minutes ]
    draft-xiong-spring-path-segment-sr-inter-domain-01
    Quan Xiong

Total Presentation Time:            83 minutes
Speaker Shuffling Time/Buffer:      7 minutes
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to