Thank you for addressing my comments.

Always a pleasure working with you! 




From: "Ketan Talaulikar (ketant)" <>
Date: Friday, March 2, 2018 at 00:39
To: Jeff Tantsura <>, 
"" <>
Subject: RE: Section 9.1 of the draft 
draft-filsfils-spring-segment-routing-policy (IP/Optical)


Hi Jeff,


Thanks for clarifying and we should definitely add the reference to the POI 
draft in sec 9.1. I’ll work with other authors to incorporate the same in the 
next rev.


Also thanks for pointing this out as it helps indeed to clarify the 
relationship between these two drafts and the both draft authors’ intentions.





From: Jeff Tantsura [] 
Sent: 01 March 2018 23:44
To: Ketan Talaulikar (ketant) <>;;
Subject: Re: Section 9.1 of the draft 
draft-filsfils-spring-segment-routing-policy (IP/Optical)


Hi Ketan,


Thanks for responding.

I’m completely with you here, drafts are complimentary, moreover, draft poi 
extensively uses and references policy draft. 

My only request is to reference draft poi for the use cases that are relevant, 
such as section 9.1.


Hope this makes sense and clarifies the intentions. 





From: "Ketan Talaulikar (ketant)" <>
Date: Thursday, March 1, 2018 at 09:14
To: Jeff Tantsura <>, 
"" <>
Subject: RE: Section 9.1 of the draft (IP/Optical)


Hi Jeff/All,


Perhaps there is some misunderstanding on the content in the policy draft and 
let me try to clarify the same.


Section 4 of the policy draft introduces and describes the different Segment 
Types. We wanted to introduce a segment type to indicate in general a “non-IP” 
link that may be used to divert traffic into a link/segment as a part of an 
explicit segment list. This type of link could be an optical transport path, or 
some Layer-2 link/channel, or such. In the previous rev 04, we introduced a new 
Segment Type 12 for this purpose but after review/feedback, we realized that 
this was not necessary. Hence in the 05 version, it is clarified that Segment 
Type 5 or 7 may be used as such.


Section 9.1 is actually an illustration of the use-case of such a layer-2 
segment type used for an SR Policy as described above. Even if the example is 
integrated-DWDM interface, it is clarified that the same applies for any other 
layer-2 or “non-IP” link representation on the router. The policy draft 
provides the SR Policy framework and definition.


The poi draft is very important IMHO as it covers and explains the optical 
transport SR Policies along with their use-cases. This draft actually specifies 
the Optical Transport SR policy in the form of Transport Segments – it 
introduces this new type of transport segment and SR policy as it references 
the policy draft. It also talks about the Optical Transport Policy being used 
through its BSID in the IP layers. This maps to Segment Type 1 in the policy 
draft – just similar to a SR Policy between IP segments. It is absolutely 
correct that the poi draft specifies the control plane extensions and TLV for 
the optical transport segments and capabilities. The policy draft does not do 


So I do believe the policy and poi drafts are complementary.





From: Jeff Tantsura [] 
Sent: 01 March 2018 03:09
Subject: Section 9.1 of the draft (IP/Optical)


Hello authors of draft-filsfils-spring-segment-routing-policy(further 
references as policy draft),


We, authors of draft-anand-spring-poi-sr draft(further referenced as poi draft) 
have noted that section 9.1 of 04 version of the policy draft now has 
IP/Optical use case, that is in great details described in the poi draft. It 
also references policy draft and in details explains how it could be used in 
IP/Optical case.


All control plane extensions needed for the solution to work are defined in the 
poi draft.

Rather than having 2 different drafts trying to specify same technology, we 
think that for the IP/Optical case a reference (normative) to the poi draft 
would be in place.


Thanks and looking forward to working with you!



Jeff on behalf of co-authors


P.S. Since Clarence is on the both drafts, I’d let him speak for himself.


spring mailing list

Reply via email to