Hi Peter, Thanks much for your comments. Please find some answers inline.
Thanks, Madhukar -----Original Message----- From: Peter Psenak [mailto:[email protected]] Sent: Tuesday, April 19, 2016 1:54 AM To: Madhukar Anand <[email protected]>; [email protected] Cc: Ramesh Subrahmaniam <[email protected]>; Sanjoy Bardhan <[email protected]> Subject: Re: [spring] Fwd: New Version Notification for draft-anand-spring-poi-sr-00.txt Hi Madhukar, - you defined Opaque-Adj-SID sub-TLV is an optional sub-TLV of Extended Link TLV in case of OSPF and one of the IS-Neighbor TLVs in case of ISIS. The parent TLVs in all cases carry the neighbor identifier. Repeating the Remote POG Router-ID/System ID in Opaque-Adj-SID sub-TLV looks redundant. [MA] Sure, we will take care of this and remove the redundancy. - Is the "paths through the optical transport domain" always between adjacent POGs? Would not you find it useful to advertise a "path" between non adjacent POG nodes? [MA] Yes, I think there may be scenarios where advertising a path may be useful. We will try to modify the TLV to accommodate this. - Existing SR architecture includes the definition of Binding SID and there are extensions for IGPs to advertise it. The SID/Label Binding Sub-TLV is used to advertise a SID/Label mapping for a "path" to the prefix. It looks to me there is an overlap between the new Opaque-Adj-SID sub-TLV and existing SID/Label Binding Sub-TLV. Both of them advertise a "binding label" for a "path". Binding Sub-TLV talks about a path to a prefix, but given that the prefix can represent a "Router-ID" of the remote node, it can be used to advertise the path to a node. - Section 4 of the draft says: "The opaque adjacency segment can also optionally be announced with a set of attributes that characterizes the path". The Opaque-Adj-SID sub-TLV encoding does not provide for additional attributes. SID/Label Binding Sub-TLV supports nested sub-TLVs, which allows you to advertise path path attributes. I wonder whether existing Binding Sub-TLV with new sub-TLVs could be used for the Packet-Optical integration, rather than defining a new sub-TLV of a similar kind. [MA] Yes, we are currently working with Jeff Tantsura on the possibility of using Binding SIDs for our extension. We will circle back to you once we make progress on this. thanks, Peter On 3/23/16 05:17 , Madhukar Anand wrote: > Hi all, > > The following draft talks about connecting packet and optical networks using > segment routing as a common control plane. This is an attempt towards > packet-optical integration. Please review and let us know of any comments. > https://www.ietf.org/internet-drafts/draft-anand-spring-poi-sr-00.txt > > Best regards, > Madhukar, Sanjoy and Ramesh > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Sunday, March 20, 2016 6:32 PM > To: Madhukar Anand <[email protected]>; Sanjoy Bardhan > <[email protected]> > Subject: New Version Notification for draft-anand-spring-poi-sr-00.txt > > > A new version of I-D, draft-anand-spring-poi-sr-00.txt has been successfully > submitted by Madhukar Anand and posted to the IETF repository. > > Name: draft-anand-spring-poi-sr > Revision: 00 > Title: Packet-Optical Integration in Segment Routing > Document date: 2016-03-20 > Group: Individual Submission > Pages: 15 > URL: > https://www.ietf.org/internet-drafts/draft-anand-spring-poi-sr-00.txt > Status: https://datatracker.ietf.org/doc/draft-anand-spring-poi-sr/ > Htmlized: https://tools.ietf.org/html/draft-anand-spring-poi-sr-00 > > > Abstract: > This document illustrates a way to integrate a new class of nodes and > links in segment routing to represent networks in an opaque way for > further extensibility of the link-state protocols that help with > segment routing. An instance of the opaque definition would be > optical networks that are typically transport centric. In the IP > centric network, this will help in defining a common control protocol > for packet optical integration that will include optical paths as > opaque 'segments' or sub-paths as an augmentation to the defined > extensions of segment routing. This opaque option defines a general > mechanism to allow for future extensibility of segment routing. > > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > . > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
