Hi, In Singapore I described this draft to the WG. My last slide said:
----- Is it helpful to have this type of document? - Some people say "It's just a white paper. Publish it elsewhere." - Some people say "This is really helpful to understand how all of the pieces of IETF work fit together for a real deployment." The authors plan to keep this draft alive as a framework for discussion - It seems to us (the authors) that SPRING is a good place to have those discussions ------ I expected some pushback, but I think the response in the room was somewhere between benign indifference and general support. So we did some house-keeping, cleaned up the text a bit and fixed some references. If anyone has some time to read the latest revision, your comments on content or clarity would be helpful. Thanks, Adrian > ________________________________________ > From: [email protected] > Sent: 18 December 2017 17:25:49 (UTC+00:00) Dublin, Edinburgh, Lisbon, London > To: John E Drake; Adrian Farrel > Subject: New Version Notification for draft-farrel-spring-sr-domain-interconnect- > 02.txt > > A new version of I-D, draft-farrel-spring-sr-domain-interconnect-02.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. > > Name: draft-farrel-spring-sr-domain-interconnect > Revision: 02 > Title: Interconnection of Segment Routing Domains - Problem Statement and > Solution Landscape > Document date: 2017-12-18 > Group: Individual Submission > Pages: 33 > URL: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_internet-2Ddrafts_draft-2Dfarrel-2Dspring-2Dsr-2Ddomain- > 2Dinterconnect-2D02.txt&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=uMf2AvUxVCBheNFdVy1Y_8kG3CPWoDoPEbxx8m859_Q > &m=l2p-pmPEY_yiZ-lFk5fvLeUHjrpuU4uz5ehspbc8igU&s=UNj2lX7a-TG- > 9SmofiYumEIVSWszL6Fvkn1ZDEbAE6E&e= > Status: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__datatracker.ietf.org_doc_draft-2Dfarrel-2Dspring-2Dsr-2Ddomain- > 2Dinterconnect_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=uMf2AvUxVCBheNFdVy1Y_8kG3CPWoDoPEbxx8m859_Q > &m=l2p-pmPEY_yiZ- > lFk5fvLeUHjrpuU4uz5ehspbc8igU&s=bdnFEuQn4Ey7Hrpzli6mCpxG19Lr8dnB9fi4U > LL0DcQ&e= > Htmlized: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__tools.ietf.org_html_draft-2Dfarrel-2Dspring-2Dsr-2Ddomain- > 2Dinterconnect-2D02&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=uMf2AvUxVCBheNFdVy1Y_8kG3CPWoDoPEbxx8m859_Q > &m=l2p-pmPEY_yiZ- > lFk5fvLeUHjrpuU4uz5ehspbc8igU&s=jM_KdTr2tTC_04be2woO8a- > toA4b1wR5HEJftZQ3gPo&e= > Htmlized: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__datatracker.ietf.org_doc_html_draft-2Dfarrel-2Dspring-2Dsr-2Ddomain- > 2Dinterconnect-2D02&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=uMf2AvUxVCBheNFdVy1Y_8kG3CPWoDoPEbxx8m859_Q > &m=l2p-pmPEY_yiZ- > lFk5fvLeUHjrpuU4uz5ehspbc8igU&s=Ddr0Iue5sjlBxxDzyJAbRK5jNWyVvDCROsXO > xmqoqVo&e= > Diff: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfarrel-2Dspring-2Dsr-2Ddomain- > 2Dinterconnect-2D02&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=uMf2AvUxVCBheNFdVy1Y_8kG3CPWoDoPEbxx8m859_Q > &m=l2p-pmPEY_yiZ- > lFk5fvLeUHjrpuU4uz5ehspbc8igU&s=TrDWmdv0k3XahcZ0COvkAVF4PV4ppe0JcU > 71A2uHbTI&e= > > Abstract: > Segment Routing (SR) is a popular forwarding paradigm for use in MPLS > and IPv6 networks. It is typically deployed in discrete domains that > may be data centers, access networks, or other networks that are > under the control of a single operator and that can easily be > upgraded to support this new technology. > > Traffic originating in one SR domain often terminates in another SR > domain but must transit a backbone network that provides > interconnection between those domains. > > This document describes a mechanism for providing connectivity > between SR domains to enable end-to-end or domain-to-domain traffic > engineering. > > The approach described allows connectivity between SR domains, > utilizes traffic engineering mechanisms (RSVP-TE or Segment Routing) > across the backbone network, makes heavy use of pre-existing > technologies, and requires the specification of very few additional > mechanisms. > > This document provides some background and a problem statement, > explains the solution mechanism, gives references to other documents > that define protocol mechanisms, and provides examples. It does not > define any new protocol mechanisms. > > > > > 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
