Thanks Clarence, we are on the same page then.
On 3/2/18, 00:37, "Clarence Filsfils (cfilsfil)" <cfils...@cisco.com> wrote:
For sure. It was our intention to have this reference. It is absolutely
obvious that it must be. The point of the section 9.1 and especially the
new SID that we defined is to provide the proper support/context for the
POI draft and hence the reference is clear.
On 01/03/2018 19:13, Jeff Tantsura wrote:
> 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)" <ket...@cisco.com>
> *Date: *Thursday, March 1, 2018 at 09:14
> *To: *Jeff Tantsura <jefftant.i...@gmail.com>,
> "draft-anand-spring-poi...@ietf.org" <draft-anand-spring-poi...@ietf.org>
> *Cc: *SPRING WG <email@example.com>
> *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 this.
> So I do believe the policy and poi drafts are complementary.
> *From:*Jeff Tantsura [mailto:jefftant.i...@gmail.com]
> *Sent:* 01 March 2018 03:09
> *To:* draft-filsfils-spring-segment-routing-pol...@ietf.org;
> *Cc:* SPRING WG <firstname.lastname@example.org>
> *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