Nirmala, inline
On Mon, Jul 05, 2021 at 02:53:17PM +0000, Nirmala Shenoy wrote:
> Thanks Toerless for the detailed information – it was very helpful.
> Thanks Hesham will check it out - my hardware knowledge is quite outdated ☺
>
> Following up on the discussion:-
>
> 1. As I understand overlay solutions have constraints because of the underlay networks, which in most cases is based on IP as network layer, but they have alternative paths to select from.
And that ability alone makes them big business ;-)
> 2. I noticed that you mentioned MPLS and segment routing Toerless which are layer 2.5 solutions, and they can be used as underlay networks. However these solutions still depend on IP and its routing protocols to provide the routing information?
The taxonomy of layers would be a fun topic, but it certainly needs fractions betwen layer 2 and layer 4 ;-))
> Segment routing further uses source routing
Yes.
> which if I am not mistaken is not very robust to failures.
I think Sement Routing proponent would tell you that you are mistaken.
Consider the most common form of deploying SR-MPLS, which is not to actually have a multi-segment
steering list in packets, but only the final segment. In this use-case, SR simply serves as a simplification
of prioor MPLS designs which used LDP, and that arguably was more fragile because of its
added complexity and interctions with the IGP. SR-MPLS in this design simply has the same recovery
properties tas IP has, fast-convergence plus any of the IP-FastReRoute (IP-FRR) options, predominantly
IP-LFA, and then by virtue of using MPLS, it is the more lightweight encpasulation and adds all MPLS OAM
management and L2/L3VPN and other services benefits. Aka: SR-MPLS is simplifcation without loss
of functionality, hence resulting in arguably hiher system stability (very high level abstracted).
Once you have in packets source routing with actual steering across midpoints you do get
into the same resilience solution space as RSVP-TE, although networks would most likely
not want to provision classical FRR tunnels as used in RSVP-TE, but rely on IP-FRR and
than tactical, controller based reoptimization. Arguably no less robustness against failures
as those prior solutions, but again arguably again less in-network-control-plane complexity.
Of course, all this comes at the price of more and more important functionality to go into
PCE/controllers and being less and less visible in public as all the alorithms and procedures
can be proprietary. But that trend also started when PCE where oriinally introduced for RSVP-TE.
> 3. Lastly – what challenges would a layer 2.5 solution (not MPLS) that does not depend on IP and its routing protocols face, especially if they can operate in parallel with IP at layer 3 i.e. we can have two independent network layers operating in parallel – I hope I captured that right!
In IP/MPLS networks, IP and MPLS pretty much do operate in parallel, its just that IP
typically is used only as data plane for MPLS control and device/infra OAM, but there
have traditionally also been networks that ran IPv4/IPv6 customer traffic natively
and MPLS only for L2/L3-VPN services. They typically just converged to run everything over MPLS to
unify OAM an resilience models.
The main challenge for evolving beyond IP for MPLS control is that
operators would have no interest in your question because they have not been shown anything
that a non-IP based MPLS control plane could do better, and obviously the reason why the
current IP based PLS control/OAM-plane works as well as it does is because of 20 years
of deployment and experience. SO i think one would foremost want to look for candidate
answers to - what could evolution of MPLS control plane from its current IP approach
offer as possible benefits.
Cheers
Toerless
>
> Thanks
> Nirmala
>
> From: Semantic Address Routing and Hardware - SARAH <[log in to unmask]> On Behalf Of Hesham ElBakoury
> Sent: Friday, July 2, 2021 9:54 PM
> To: [log in to unmask]
> Subject: Re: [SARAH] Revitalizing the Internet by making it Extensible
>
>
> Thanks Nirmala for participating in the SARAH email list.
>
> With Moore's law slowing down and Dennard scaling is dead, I think the future of computer architecture is DSA (Domain Specific Accelerators) and Open Source Instruction Set Architecture (e.g. RISC-V). What I like about RISC-V is that you can invent your own instruction sets to support specific functions in a cost efficient manner. If you want more details you can watch John Hennessy and David Patterson 2017 ACM A.M. Turing Award Lecture: (736) John Hennessy and David Patterson 2017 ACM A.M. Turing Award Lecture - YouTube<https://www.youtube.com/watch?v=3LVeEjsn8Ts>
>
> Thanks
>
> Hesham
> On 7/2/2021 10:11 AM, Nirmala Shenoy wrote:
>
> Hello Toerless
>
> The overlay solutions you mentioned why are they not able to provide mechanism to improve services. Is the constraint due to the underlay network?
>
>
>
> To all
>
> I would like to quote in this discussion some points from an observation made by Adrian Farrel under topic 'Complexity and Layering'
>
> "1. Make a distinction between protocols in limited domains, and protocols that connect things together"------ i.e. separate routing from locating?
>
> "2. Don't make the core protocol overly complex" - ---- I presume doing 1 would achieve this
>
> ------------
>
> "4. Consider using different protocol identifiers to keep protocols separate" --- separate routing id from device/domain id?
>
> ----------
>
> I think this proposes a divide and conquer approach. Any potential challenges or issues we could face with such an approach? Given that we have to support a variety of limited domains - such an approach would be very convenient.
>
>
>
> Lastly - Is there still a concern on variable length addresses - given the CPU processing capacities we have today?
>
>
>
> My research ties up with the above and insights into these points will help my research.
>
>
>
> Thanks
>
> Nirmala
>
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: Semantic Address Routing and Hardware - SARAH <[log in to unmask]><mailto:[log in to unmask]> On Behalf Of Toerless Eckert
>
> Sent: Tuesday, June 29, 2021 4:53 PM
>
> To: [log in to unmask]<mailto:[log in to unmask]>
>
> Subject: Re: [SARAH] Revitalizing the Internet by making it Extensible
>
>
>
> On Tue, Jun 29, 2021 at 01:25:48PM -0700, Hesham ElBakoury wrote:
>
> Good input Toerless!
>
>
>
> From the discussions I had with people in IETF I gathered that using
>
> overlays with different address semantics from the underlay is
>
> structurally cleaner and easier to use amongst the overlay
>
> participants than trying to change the semantics of IPv6 in the underlay.
>
>
>
> And all research did start as such overlays, MBoned, 6Bone, etc. pp.
>
> Today, even many new designs to consider that their best form of deployment is just some form of "overlay", aka: tunnel between whaever infra exists between DCs and subscribers. For example i would put SCION (just to name one bigger fish in the research pond) into that bucket.
>
>
>
> This is perfectly fine as long as you do not want to improve the services offered by that underlay. Which alas is primarily the business i am in - latency, monitoring, multicast, reliability, resilience, you name it.
>
>
>
> But i can also complain about overlays heavily. For example none of those overlay headers (like LISP) did add simple monitoring capabilities such as sequence numbers to be able to easily isolate where packet loss happened. Or time-stamps to discover when there is significant latency introduced by the underlay.
>
> In the end, this makes overlays more fragile instead of more resilient.
>
>
>
> Cheers
>
> Toerless
>
>
>
> Hesham
>
>
>
> On 6/29/2021 12:59 PM, Toerless Eckert wrote:
>
> My information is likely stale, i remember two main things:
>
>
>
> a) There is some early adopter community across the Internet
>
> (collaborative, federated). The whole original goal of the IETF
>
> Locator Identifier Split work fell flat on its face so far because
>
> vendors can still scale the native Internet BGP routing table enough.
>
>
>
> b) AFAIK, customers really are commercial/enterprise who simply use LISP
>
> as their VPN encapsulation. Some of these may be federated, such as
>
> between between B2B partners, e.g.: in supply chains . The primary reason
>
> for relying on LISP as opposed to other encaps for VPNs is it richer
>
> policy framework to support exit/entry point path selection policies,
>
> ability to outsource the control plane from the routers, therefore making
>
> it more extensible and AFAIK also when extending LISP directly into
>
> cloud hosted VM/containers for secure cloud based applications.
>
>
>
> Today, everybody and their dog can deploy new protocols as an
>
> overlay, and the space LISP lives in is what commercial offerings
>
> are calling SD-WAN or secure cloud access methods. All of these use
>
> the "whatever, likely self-hacked or maybe stolen from
>
> IPsec/TLS/LISP/DMVPN" encapsulation and/or control, and you do not
>
> see any of the technology used because all these solutions are vertical silos from the individual service vendor.
>
> Maybe some of them actually do use LISP unmodified.
>
>
>
> The main reason for this evolution is really - as Geoff Houston so
>
> nicely summarized in his DIRNG talk - capital:
>
>
>
> To build a successful overlay network service you need capital. The
>
> most simple calculation is this: You need to be able to attract
>
> enough customers so that their total amount of traffic and your
>
> revenue from it is larger than the cost you need to pay for the
>
> cloud hosting of your own virtual service routers on e.g.: AWS or
>
> other cloud providers: All this cloud-hosting is volume based: The
>
> larger your overlay service is, the more you buy such infrastructure
>
> capacity (compute, networking), the lower your per-packet cost.
>
>
>
> Most challengers can not get over the hump of growing into that size
>
> where an overlay solution becomes economic - unless they identify a
>
> specific high-margin niche that their overall solution serves better.
>
>
>
> And of course, the answer why we can not get new technologies into
>
> the underlay is because whoever operates the underlay has no idea
>
> how to make additional money out of new services, all they know is
>
> how to make logarithimically more money out of more volume. Hence
>
> the focus on limited domain networks IMHO.
>
>
>
> Cheers
>
> Toerless
>
>
>
> On Tue, Jun 29, 2021 at 12:03:08PM -0700, Hesham ElBakoury wrote:
>
> Cisco supports LISP in its IOS XE release. Any idea on how/where
>
> they deploy LISP ?
>
>
>
> Hesham
>
>
>
> On 6/15/2021 6:35 AM, Luigi IANNONE wrote:
>
> *From:* Semantic Address Routing and Hardware - SARAH
>
> [mailto:[log in to unmask]] *On Behalf Of *Dirk Trossen
>
> *Sent:* Tuesday, June 15, 2021 13:11
>
> *To:* [log in to unmask]<mailto:[log in to unmask]>
>
> *Subject:* Re: Revitalizing the Internet by making it Extensible
>
>
>
> [SNIP]
>
>
>
> That still leaves the question (that Hesham raises here) of how
>
> to get a new protocol deployed. Again, it seems easier to deploy
>
> new end-to-end protocols than hop-by-hop protocols. Experience
>
> seems to show that initial deployment within “limited domains”
>
> proves easier and more successful than attempts at more wide-scale deployment.
>
>
>
> */[DOT] For ICN, RFC8763 outlines deployment considerations for
>
> this technology, including the deployment via NFV. This is
>
> particularly interesting for deployments in what is considered a
>
> limited domain itself (i.e., a 5G mobile subsystem). /*
>
>
>
> *[LI] A similar exercise has been done with LISP. RFC7215
>
> (https://datatracker.ietf.org/doc/html/rfc7215
>
> <https://datatracker.ietf.org/doc/html/rfc7215><https://datatracker.ietf.org/doc/html/rfc7215>) describes
>
> deployment consideration early in the history of LISP. I guess a
>
> few things have changed in the meantime.*
>
>
>
> **
>
>
>
> *Ciao*
>
>
>
> **
>
>
>
> *L.*
>
>
>
> **
>
>
>
> */Best,/*
>
>
>
> *//*
>
>
>
> */Dirk/*
>
>
>
> Cheers,
>
>
>
> Adrian
>
>
>
> *From:* Semantic Address Routing and Hardware - SARAH
>
> <[log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>> *On Behalf
>
> Of *Hesham ElBakoury
>
> *Sent:* 15 June 2021 02:10
>
> *To:* [log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>
>
> *Subject:* Re: Revitalizing the Internet by making it Extensible
>
>
>
> I think they want to have a prototype or PoC quickly using open
>
> source code which runs on every mobile or Internet host.
>
>
>
> I agree that using standard protocols is preferable because they
>
> allow independent implementations that can interwork. The issue
>
> is that it takes long time to standardize and deploy such
>
> protocols in a large scale network such as the Internet. Look at
>
> how hard it is to get IPv6 deployed.
>
>
>
> Hesham
>
>
>
> On Mon, Jun 14, 2021, 8:19 AM Dirk Trossen
>
> <[log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>> wrote:
>
>
>
> Hmm, came across it during another exercise, somewhat linked to
>
> our discussion here.
>
>
>
> My main issues are the mix of architecture and governance into the
>
> same discussion (I’m not opposed to open source at all but don’t
>
> find it useful/suitable as an architectural principle) and my
>
> confusion (after reading) on what a service really is here.
>
>
>
> Dirk
>
>
>
> *From:* Semantic Address Routing and Hardware - SARAH
>
> [mailto:[log in to unmask] <mailto:[log in to unmask]><mailto:[log in to unmask]>] *On
>
> Behalf Of *Hesham ElBakoury
>
> *Sent:* 14 June 2021 13:53
>
> *To:* [log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>
>
> *Subject:* Revitalizing the Internet by making it
>
> Extensible
>
>
>
> What do you think of the approach described in this paper which
>
> was recently published this year :
>
> https://www.cs.princeton.edu/~jrex/papers/ei21.pdf
>
> <https://www.cs.princeton.edu/~jrex/papers/ei21.pdf><https://www.cs.princeton.edu/~jrex/papers/ei21.pdf>. This paper
>
> is coauthored by known researchers in MIT, Stanford, Berkeley,
>
> Princeton, Georgia Tech, Cornell, ...
>
>
>
> This approach uses a new browser and a service node to allow a
>
> host on the Internet to communicate with an IoT device on a
>
> network such as Sigfox network which does not internally use TCP/IP.
>
>
>
> Hesham
>
>
>
> On Mon, Jun 14, 2021, 12:25 AM Dirk Trossen
>
> <[log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>> wrote:
>
>
>
> Adrian,
>
>
>
> Please see inline.
>
>
>
> Best,
>
>
>
> Dirk
>
>
>
> -----Original Message-----
>
> From: Semantic Address Routing and Hardware - SARAH
>
> [mailto:[log in to unmask] <mailto:[log in to unmask]><mailto:[log in to unmask]>] On
>
> Behalf Of Adrian Farrel
>
> Sent: 11 June 2021 19:19
>
> To: [log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>
>
> Subject: Re: Complexity and Layering
>
>
>
> Hi Dirk,
>
>
>
> I think, perhaps, some misunderstanding.
>
>
>
> > "Further, the networks on which the research is carried out
>
> need to
>
> > both reflect the characteristics that are being explicitly
>
> tested, and
>
> > reproduce the variety of real networks that constitute the
>
> Internet."
>
> >
>
> > So any discussed solution must reproduce over all 'real
>
> networks that
>
> > constitute the internet'? Apart from my view that this goes
>
> counter
>
> > research since to do so the solution would need to be
>
> deployed first
>
> > in all those real networks (which is NOT research and it's
>
> even for
>
> > engineered solution a steep goal). It also goes explicitly
>
> counter any
>
> > solution designed for a limited domain. Well, even DC
>
> networking would
>
> > fall foul of this, wouldn't it? Is this what we want?
>
>
>
> The word "all" is yours not mine.
>
> And you also introduced the word "deployed".
>
> [DOT] well, it's where my problem lies. Which 'real networks'
>
> are we talking about (deployed ones do come to mind). If we
>
> talk about 'testing', isn't 'all' a suitable qualifier for the
>
> extent of testing we are asking for? I have no intention to
>
> put words in your mouth but feel that if we use
>
> 'requirement-like' language, there needs to be some
>
> clarification - more below.
>
>
>
> It is, of course, fine to start somewhere. The starting point
>
> will inevitably be a private network: a limited domain. Test,
>
> develop, experiment.
>
> My point is that it is that the research needs to go further.
>
> We need to know whether the proposal can be generalised. We
>
> need to know how it would behave in different shape networks
>
> and different environments. We need to know what would happen
>
> if it was deployed more widely.
>
> [DOT] So maybe we can use a different approach. The above
>
> sentence is the starting point. But going towards 'real
>
> networks' (as you suggested) is the part embodied in the
>
> engagement with the community, e.g., in SDOs. As Toerless
>
> pointed out, we have good examples of this in
>
> multi-stakeholder projects. My point is that I would like
>
> avoid something that reads like a requirement for what is
>
> research but instead state the research starting point (even
>
> if seemingly obvious), amended by the community approach
>
> where, maybe, the IRTF can be a useful vehicle.
>
>
>
> > My suggested re-wording:
>
> >
>
> > "Further, the networks on which the research is carried out
>
> need to
>
> > both reflect the characteristics that are being explicitly
>
> tested, and
>
> > reproduce over the variety of networks for which its
>
> mechanisms were designed."
>
>
>
> And I contest that that is an engineering approach not a
>
> research approach. It takes a problem space and develops a
>
> solution in that space, but it doesn't look more widely.
>
>
>
> [DOT] I didn't say that it's engineering approach but it would
>
> be good to state the 'obvious' research starting point and the
>
> space where the wider community and the insights into 'real
>
> networks' can push this research further, i.e., the 'place to
>
> meet' to do more and get more insights. We do share the same
>
> goal here, I would think. As for your request on a re-draft (I
>
> suppose of your proposed Section 4.1 below), I'd be happy to
>
> do this but won't be able to do so before Wednesday due to
>
> other commitments. If that works for you, please do mark my
>
> name down for it.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> -----Original Message-----
>
> From: Semantic Address Routing and Hardware - SARAH
>
> [mailto:[log in to unmask] <mailto:[log in to unmask]><mailto:[log in to unmask]>] On
>
> Behalf Of Adrian Farrel
>
> Sent: 11 June 2021 15:40
>
> To: [log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>
>
> Subject: Re: Complexity and Layering
>
>
>
> Well, how about this as a starting point...
>
>
>
> 4.1. Research Principles
>
>
>
> Research into semantic addressing should be founded on regular
>
> scientific research principles [royalsoc]. Given the
>
> importance of
>
> the Internet today, it is critical that research is targeted,
>
> rigorous, and reproducible.
>
>
>
> The most valuable research will go beyond an initial
>
> hypothesis, a
>
> report of the work done, and the results observed.
>
> Although that is
>
> a required foundation, networking research needs to be
>
> independently
>
> reproducible so that claims can be verified or falsified.
>
> Further,
>
> the networks on which the research is carried out need to both
>
> reflect the characteristics that are being explicitly
>
> tested, and
>
> reproduce the variety of real networks that constitute the
>
> Internet.
>
>
>
> Thus, when conducting experiments and research to address the
>
> questions in the next section, attention should be given to
>
> how the
>
> work is documented and how meaningful the test environment
>
> is, with a
>
> strong emphasis on making it possible for others to
>
> reproduce and
>
> validate the work.
>
>
>
>
>
> [royalsoc]
>
> The Royal Society, "Evidence synthesis :
>
> Principles", Web
>
> page Principles for good evidence synthesis,
>
> September
>
> 2018,
>
> <https://royalsociety.org/topics-policy/projects/
>
> <https://royalsociety.org/topics-policy/projects/><https://royalsociety.org/topics-policy/projects/>
>
> evidence-synthesis/principles/>.
>
>
>
>
>
> Reasonable, or too much 'apple pie'?
>
>
>
> Adrian
>
>
>
> -----Original Message-----
>
> From: Semantic Address Routing and Hardware - SARAH
>
> <[log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>> On Behalf
>
> Of Adrian Farrel
>
> Sent: 11 June 2021 12:13
>
> To: [log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>
>
> Subject: Re: Complexity and Layering
>
>
>
> Thanks Stephen and Dirk,
>
>
>
> This is precipitating (slowly) into a new sub-section in
>
> draft-king-irtf-challenges-in-routing on "Research Principles."
>
>
>
> There is inevitably going to be some egg-sucking in that
>
> section, but in the light of what Stephen writes about "doing
>
> better", I think it will stand being written and read.
>
>
>
> If anyone wants to contribute text on that, then please.
>
> Otherwise I will make something up.
>
>
>
> Best,
>
> Adrian
>
>
>
> -----Original Message-----
>
> From: Semantic Address Routing and Hardware - SARAH
>
> <[log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>> On Behalf
>
> Of Stephen Farrell
>
> Sent: 11 June 2021 11:44
>
> To: [log in to unmask]<mailto:[log in to unmask]> <mailto:[log in to unmask]><mailto:[log in to unmask]>
>
> Subject: Re: Complexity and Layering
>
>
>
>
>
> Hiya,
>
>
>
> On 11/06/2021 08:01, Dirk Trossen wrote:
>
> > So I have an opposite view to Stephen in that I'd like to
>
> see more of
>
> > those experiments that are done by a handful of companies or
>
> > academics.
>
> Please read what I wrote. The above is not the opposite of that.
>
>
>
> So long as experiments can be independently reproduced and
>
> potentially falsified then we're probably ok. But many
>
> experiments in networking and computing generally cannot
>
> actually be reproduced by someone else and that's a bad thing.
>
>
>
> For the case at hand: I've heard people argue for, and against
>
> (in my case:-), this idea of "limited domains"
>
> but I don't recall anything in the nature of a good experiment
>
> aiming to test a related hypothesis.
>
>
>
> And that was my point in responding to Adrian - given the
>
> importance of the Internet today we should do better than the
>
> "here's a thing I did and some numbers" type of paper/finding
>
> that's still way too common.
>
>
>
> Cheers,
>
> S.
>
>
>
>
>
> ################################################################
>
> ########
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>
>
> <http://www.jiscmail.ac.uk/SARAH><http://www.jiscmail.ac.uk/SARAH>, a mailing list hosted by
>
> www.jiscmail.ac.uk<http://www.jiscmail.ac.uk> <http://www.jiscmail.ac.uk><http://www.jiscmail.ac.uk>, terms &
>
> conditions are available at
>
> https://www.jiscmail.ac.uk/policyandsecurity/
>
> <https://www.jiscmail.ac.uk/policyandsecurity/><https://www.jiscmail.ac.uk/policyandsecurity/>
>
>
>
>
>
> ################################################################
>
> ########
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>
>
> <http://www.jiscmail.ac.uk/SARAH><http://www.jiscmail.ac.uk/SARAH>, a mailing list hosted by
>
> www.jiscmail.ac.uk<http://www.jiscmail.ac.uk> <http://www.jiscmail.ac.uk><http://www.jiscmail.ac.uk>, terms &
>
> conditions are available at
>
> https://www.jiscmail.ac.uk/policyandsecurity/
>
> <https://www.jiscmail.ac.uk/policyandsecurity/><https://www.jiscmail.ac.uk/policyandsecurity/>
>
>
>
>
>
> ################################################################
>
> ########
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>
>
> <http://www.jiscmail.ac.uk/SARAH><http://www.jiscmail.ac.uk/SARAH>, a mailing list hosted by
>
> www.jiscmail.ac.uk<http://www.jiscmail.ac.uk> <http://www.jiscmail.ac.uk><http://www.jiscmail.ac.uk>, terms &
>
> conditions are available at
>
> https://www.jiscmail.ac.uk/policyandsecurity/
>
> <https://www.jiscmail.ac.uk/policyandsecurity/><https://www.jiscmail.ac.uk/policyandsecurity/>
>
>
>
>
>
> ################################################################
>
> ########
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>
>
> <http://www.jiscmail.ac.uk/SARAH><http://www.jiscmail.ac.uk/SARAH>, a mailing list hosted by
>
> www.jiscmail.ac.uk<http://www.jiscmail.ac.uk> <http://www.jiscmail.ac.uk><http://www.jiscmail.ac.uk>, terms &
>
> conditions are available at
>
> https://www.jiscmail.ac.uk/policyandsecurity/
>
> <https://www.jiscmail.ac.uk/policyandsecurity/><https://www.jiscmail.ac.uk/policyandsecurity/>
>
>
>
>
>
> ################################################################
>
> ########
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>
>
> <http://www.jiscmail.ac.uk/SARAH><http://www.jiscmail.ac.uk/SARAH>, a mailing list hosted by
>
> www.jiscmail.ac.uk<http://www.jiscmail.ac.uk> <http://www.jiscmail.ac.uk><http://www.jiscmail.ac.uk>, terms &
>
> conditions are available at
>
> https://www.jiscmail.ac.uk/policyandsecurity/
>
> <https://www.jiscmail.ac.uk/policyandsecurity/><https://www.jiscmail.ac.uk/policyandsecurity/>
>
>
>
>
>
> ################################################################
>
> ########
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>
>
> <http://www.jiscmail.ac.uk/SARAH><http://www.jiscmail.ac.uk/SARAH>, a mailing list hosted by
>
> www.jiscmail.ac.uk<http://www.jiscmail.ac.uk> <http://www.jiscmail.ac.uk><http://www.jiscmail.ac.uk>, terms &
>
> conditions are available at
>
> https://www.jiscmail.ac.uk/policyandsecurity/
>
> <https://www.jiscmail.ac.uk/policyandsecurity/><https://www.jiscmail.ac.uk/policyandsecurity/>
>
>
>
>
>
> ----------------------------------------------------------------
>
> --------
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
>
>
> ----------------------------------------------------------------
>
> --------
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> ----------------------------------------------------------------
>
> --------
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> ----------------------------------------------------------------
>
> --------
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> ----------------------------------------------------------------
>
> --------
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
>
>
> ----------------------------------------------------------------
>
> --------
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
> <https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
>
>
> ##################################################################
>
> ######
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>, a
>
> mailing list hosted by www.jiscmail.ac.uk<http://www.jiscmail.ac.uk>, terms & conditions are
>
> available at https://www.jiscmail.ac.uk/policyandsecurity/
>
>
>
> ######################################################################
>
> ##
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>, a
>
> mailing list hosted by www.jiscmail.ac.uk<http://www.jiscmail.ac.uk>, terms & conditions are
>
> available at https://www.jiscmail.ac.uk/policyandsecurity/
>
>
>
> --
>
> ---
>
> [log in to unmask]<mailto:[log in to unmask]>
>
>
>
> ########################################################################
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>, a mailing list hosted by www.jiscmail.ac.uk<http://www.jiscmail.ac.uk>, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
>
>
>
> ########################################################################
>
>
>
> To unsubscribe from the SARAH list, click the following link:
>
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
>
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH<http://www.jiscmail.ac.uk/SARAH>, a mailing list hosted by www.jiscmail.ac.uk<http://www.jiscmail.ac.uk>, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
>
> ________________________________
>
> To unsubscribe from the SARAH list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
> ########################################################################
>
> To unsubscribe from the SARAH list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
>
> This message was issued to members of www.jiscmail.ac.uk/SARAH, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
--
---
[log in to unmask]
########################################################################
To unsubscribe from the SARAH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
This message was issued to members of www.jiscmail.ac.uk/SARAH, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
|
