On Feb 6, 2015, at 12:56 PM, Hannes Gredler wrote: > hi stefano, > > is 'SRDB' a typo ?
yes. I'll fix it. Thanks. s. > - if not could you addd a definition/reference > what are the 'SRDB Maintenance rules', please ? > > thanks, > > /hannes > > --- > 3.6.1. Mapping Server > > A Remote-Binding SID S advertised by the mapping server M for remote > prefix R attached to non-SR-capable node N signals the same > information as if N had advertised S as a Prefix-SID. Further > details are described in the SR/LDP interworking procedures > ([I-D.filsfils-spring-segment-routing-ldp-interop]. > > The segment allocation and SRDB Maintenance rules are the same as > ^^^^^^^^^^^^^^^^ > those defined for Prefix-SID. > > 3.6.2. Tunnel Headend > > The segment allocation and SRDB Maintenance rules are the same as > ^^^^^^^^^^^^^^^^ > those defined for Adj-SID. A tunnel attached to a head-end H acts as > an adjacency attached to H. > > --- > > > On Fri, Feb 06, 2015 at 03:35:21AM -0800, [email protected] wrote: > | > | A New Internet-Draft is available from the on-line Internet-Drafts > directories. > | This draft is a work item of the Source Packet Routing in Networking > Working Group of the IETF. > | > | Title : Segment Routing Architecture > | Authors : Clarence Filsfils > | Stefano Previdi > | Ahmed Bashandy > | Bruno Decraene > | Stephane Litkowski > | Martin Horneffer > | Rob Shakir > | Jeff Tantsura > | Edward Crabbe > | Filename : draft-ietf-spring-segment-routing-01.txt > | Pages : 19 > | Date : 2015-02-06 > | > | Abstract: > | Segment Routing (SR) leverages the source routing paradigm. A node > | steers a packet through an ordered list of instructions, called > | segments. A segment can represent any instruction, topological or > | service-based. A segment can have a local semantic to an SR node or > | global within an SR domain. SR allows to enforce a flow through any > | topological path and service chain while maintaining per-flow state > | only at the ingress node to the SR domain. > | > | Segment Routing can be directly applied to the MPLS architecture with > | no change on the forwarding plane. A segment is encoded as an MPLS > | label. An ordered list of segments is encoded as a stack of labels. > | The segment to process is on the top of the stack. Upon completion > | of a segment, the related label is popped from the stack. > | > | Segment Routing can be applied to the IPv6 architecture, with a new > | type of routing extension header. A segment is encoded as an IPv6 > | address. An ordered list of segments is encoded as an ordered list > | of IPv6 addresses in the routing extension header. The segment to > | process is indicated by a pointer in the routing extension header. > | Upon completion of a segment, the pointer is incremented. > | > | > | > | The IETF datatracker status page for this draft is: > | https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ > | > | There's also a htmlized version available at: > | http://tools.ietf.org/html/draft-ietf-spring-segment-routing-01 > | > | A diff from the previous version is available at: > | http://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-01 > | > | > | 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. > | > | Internet-Drafts are also available by anonymous FTP at: > | ftp://ftp.ietf.org/internet-drafts/ > | > | _______________________________________________ > | spring mailing list > | [email protected] > | https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
