RE: sr - spring - what's the deal with 2 names
>> Does anyone know the scope on why we have 2 names for this ? > > SPRING is the IETF working group name - Source Packet Routing in Networking > Segment Routing is under SPRING Yeah, sorry, this was my fault. Gotta have a catchy name. As to "SPRINGv4" as others have said, this is not a recognised term in the IETF. I can think of it meaning a number of things (ranging from a private invention of SRv4, up to RFC 8663). You're going to have to check with the vendor using the term to find out what they mean, and possibly why they are using a new term instead of an existing one. Cheers, Adrian
RE: GEO IP Updates
Hey folk, Martijn Schmidt said. > They're also working on getting the format standardised in the IETF. I > applaud this, because less badly guessed geoip data and more reliably > self-published data is better: > > https://datatracker.ietf.org/doc/html/draft-google-self-published-geofeeds Just a quick note that this document is being advanced for publication as an Independent Stream [1] RFC. That means it is not getting IETF review or consensus and will not be an IETF RFC or any kind of standard. It is important to recognise that not all RFCs are IETF RFCs. Publication on the Independent Stream is a way to produce RFCs that describe proprietary protocols, provide commentary on IETF work, or offer contrary opinions. While the Independent Stream RFCs are held to the same editorial standards as other RFCs, their technical content is not subject to the same level of scrutiny. Reviews of drafts on the Independent Stream are always welcome. You can send comments and thoughts direct to the authors or to me as Independent Submissions Editor via rfc-...@rfc-editor.org <mailto:rfc-...@rfc-editor.org> . Thanks, Adrian -- Adrian Farrel Independent Submissions Editor (ISE) mailto: rfc-...@rfc-editor.org [1] https://datatracker.ietf.org/doc/rfc4846/
RE: carping about CARP
Far be it from me to get involved in a private pissing match, but... Owen wrote: Perhaps we should ask IETF/IANA to allocate a group of protocol numbers to the wild west. A protocol-number equivalent of RFC-1918 or private ASNs. You can use these for whatever you want, but so can anyone else and if you do, you do so at your own risk. This won't entirely solve the problem, but at least it would provide some level of shield for protocol numbers that are registered to particular purposes through the IETF/IANA process. Would that be 253 and 254 Use for experimentation and testing per RFC 3692? Of course, no-one like to see their pet protocol designated as an experiment (unless they really believe it is something that should be carefully researched and tried out in a controlled environment), but the garden-walling that you describe seems to fit exactly within the 3692 definitions. Adrian
RE: Inter-domain OTN, does it happen in the real world?
Will, I think you also need to consider the case where one operator runs more than one network. This can happen because of acquisition or administrative structure. I regret it might also happen because of vendor equipment compatibility/lock-in issues. Cheers, Adrian -Original Message- From: Will Orton [mailto:w...@loopfree.net] Sent: 24 October 2012 00:07 To: nanog@nanog.org Subject: Inter-domain OTN, does it happen in the real world? Reading about OTN networks, I see that IrDI is specified to handle the case where one OTN network needs to connect to another natively with OTN signals. Is this done in the real world? Does OTN network operator A ever go to OTN network operator B and say, I'd like to buy a OTU2 from city X to city Y on your long haul network (at buildings J and K where we can connect simply with short-distance SMF/1310 signals), and what TCM levels can you give me? I understand this in the case of lit 10GbE-WANPHY, LAN, and OC-192, but are OTU lit signals bought and sold wholesale this way too? Is there generally a price premium over the more normal client signals? -Will Orton
IETF's PIM Working Group conducting deployment survey
Hi, After a snafu, the PIM working group has restarted its survey into PIM sparse mode deployments. Please see the email at http://www.ietf.org/mail-archive/web/pim/current/msg02479.html for more information. responses will be anonymised. Many thanks to all operators who are able to respond. Adrian
