Hi Joel, I guarantee you there is case the performance penalty is more than 90%, only if the box send the IPv6 packet with RH or EH to the slow path (just to be compatible with RFC8200)! And I think that's common even for not very old box.
Thanks Jingrong -----Original Message----- From: Joel Halpern Direct [mailto:jmh.dir...@joelhalpern.com] Sent: Wednesday, March 4, 2020 9:39 PM To: Xiejingrong (Jingrong) <xiejingr...@huawei.com>; spring@ietf.org Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming Jingrong, the only "processing" of the SRH required in the ultimate node is to ignore it. Which is required by 8200. Skipping the SRH is not a 50% performance penalty in any situation. Yours, Joel On 3/4/2020 8:36 AM, Xiejingrong (Jingrong) wrote: > Hi Joel, Ketan, > Let me share my points about the statement "The SRH removal does not remove > the expensive part of the work, namely the need to decapsulate and process > the inner header." > For the ultimate segment endpoint that is well capable of processing SRH, the > statement is true I think. I guess the benefits may be around 50%? > While for the real network, the incremental deployment may be much more > important ---- It is determining, from 1(success) to 0(fail) or vice versa! > No matter how good a feature you provided, it just doesn't work on the > network with a bunch of PEs that is not capable of SRH, then it is useless. > > **Maybe my previously suggested text can be referenced** This has some > very important benefits for deployment in some networks when the final > tunnel end point is a lower-end node which is not capable of > processing the SRH for reasons like the hardware is overloaded or > unable to upgraded to process well with SRH. > > In case the final tunnel endpoint router is fully capable of the > functionality of SRH and the SRv6-NP defined in this document, it is > recommended not to use the PSP. > **End for reference** > > Thanks > Jingrong > > -----Original Message----- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. > Halpern > Sent: Wednesday, March 4, 2020 4:34 PM > To: Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org>; > bruno.decra...@orange.com; spring@ietf.org > Subject: Re: [spring] WGLC - > draft-ietf-spring-srv6-network-programming > > Given that we are talking about the ultimate node, all that it is being asked > to do is ignore the SRH. Whether it ignores it because it uses the option > 8200 permits to ignore things which are understood, or ignores it because > SL=0, it is required to be able to ignore it. > In either the encapsulated case or the native termination case, the > result of ignoring it is that the proper things will happen. The IP > header will be removed, and what is enclosed will be processed. (In > the native case, the upper layer header. In the encapsulated case, > the inner header.) > > So I am still confused as to what the advantage to any node is of doing more > work in the preceding node, work that is much more than the act of ignoring > the header in the final node. The SRH removal does not remove the expensive > part of the work, namely the need to decapsulate and process the inner header. > > Yours, > Joel > > > On 3/4/2020 3:27 AM, Ketan Talaulikar (ketant) wrote: >> Hi Joel, >> >> I would not like to misquote Bruno, but his conclusion on this topic >> was very logical, practical and nuanced (again most likely comes from >> working with a network operator). >> >> /QOUTE/ >> >> /My take is that PSP is an _optional data plane optimization_. >> Judging its level of usefulness is _very hardware and implementation >> dependent_. >> It may range anywhere from "not needed" to "required for my platform" >> (deployed if you are network operator, or been sold if you are a >> vendor), with possible intermediate points along _"n% packet >> processing gain", or "required when combined with a specific other >> feature"_. I don't think that the SPRING WG can really evaluate this >> point (lack of hardware knowledge, lack of detailed information on >> the hardwares). The fact that this has been implemented by some >> platforms and deployed by some operators, is, to me, an indication >> that it is useful for those cases. (I believe that an English proverb >> is *"the proof of the pudding is in the eating"*. Although I'm >> certainly missing part of its meaning and culture, in it's literal >> reading, it seems to apply)./ >> >> /UNQOUTE/ >> >> I don’t believe we need to get into the details of the 18 [1] >> publicly disclosed (I understand there are more) hardware >> implementations from multiple vendors to debate the gains from PSP. I >> don’t believe that is appropriate for an IETF mailing list or >> pursuant to IETF policy or practice (as you say)? >> >> Again, I like to make the point of how/why HBH processing was made >> optional based on real world considerations when moving from RFC2460 >> to RFC8200. So options are good and necessary! >> >> That said, let us turn the tables around. There is no technical >> reason for not allowing PSP with SRH – all the ones that have been >> brought up have been answered and clarified in the text as well as on the >> mailer. >> So I fail to understand the resistance of “the other side (including >> yourself)”. >> >> Therefore, I would suggest we go ahead with the declared Spring WG >> consensus. >> >> Thanks, >> >> Ketan >> >> [1] >> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-s >> t >> atus-05#section-4.2 >> >> -----Original Message----- >> From: Joel Halpern Direct <jmh.dir...@joelhalpern.com> >> Sent: 04 March 2020 13:26 >> To: Ketan Talaulikar (ketant) <ket...@cisco.com>; >> bruno.decra...@orange.com; Martin Vigoureux >> <martin.vigour...@nokia.com>; spring@ietf.org >> Subject: Re: [spring] WGLC - >> draft-ietf-spring-srv6-network-programming >> >> Bruno's statement, which you chose to quote, was that all it takes is >> for one person to find something useful. I was responding to what >> the chair said. It is not true as stated. >> >> Having said that, I agree that more than one person has asked for this. >> >> But the actual requirement is that there be a coherent and >> understandable explanation of why the feature adds value. From where >> I sit, I have not seen such an explanation. It is generally the >> unbiased chair's job to judge whether sufficient explanation has been >> given. But what Bruno said was not "explanation ... seems sufficient" >> but rather the text you quoted. Which is not an accurate statement >> of IETF policy or practice. >> >> If there is a claim that there is significant problems on the >> ultimate node for processing the SRH, I would like to see an >> explanation of how an 8200 compliant node would have such problems. >> In particular, unlike the MPLS case, the presence or absence of an >> SRH with SL=0 has no effect on the number of forwarding lookups that >> need to be performed. And 8200 requires the ability to ignore a routing >> header with SL=0. >> >> Yours, >> >> Joel >> >> On 3/4/2020 2:49 AM, Ketan Talaulikar (ketant) wrote: >> >> > Hi Joel, >> >> > >> >> > Surely you are exaggerating when you say "one person" asked for >> >> > something in the context of PSP? 😊 >> >> > >> >> > Would you like to clarify? >> >> > >> >> > And also respond on the real life and practical deployment >> scenarios and considerations that I've pointed out below? I doubt you >> meant to just dismissing them without sharing your views? >> >> > >> >> > Thanks, >> >> > Ketan >> >> > >> >> > -----Original Message----- >> >> > From: Joel M. Halpern <j...@joelhalpern.com >> <mailto:j...@joelhalpern.com>> >> >> > Sent: 04 March 2020 13:16 >> >> > To: Ketan Talaulikar (ketant) <ket...@cisco.com >> <mailto:ket...@cisco.com>>; >> >> > bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>; >> Martin Vigoureux >> >> > <martin.vigour...@nokia.com <mailto:martin.vigour...@nokia.com>>; >> spring@ietf.org <mailto:spring@ietf.org> >> >> > Subject: Re: [spring] WGLC - >> >> > draft-ietf-spring-srv6-network-programming >> >> > >> >> > If we really want to say that it takes only one person asking for >> something to put it in a planned RFC, then I guess we have to publish >> all of the competing versions of route headers for v6, since we >> clealry have more than 1 party asking for each variant? >> >> > Put differently, no, putting something in because one person >> asked for it (even with the caeat that it appears not to break) is >> not how the IETF generally works. I do not know where Bruno got that >> premise, but it does not match the history or written policies of the IETF. >> >> > >> >> > Yours, >> >> > Joel >> >> > >> >> > On 3/4/2020 2:43 AM, Ketan Talaulikar (ketant) wrote: >> >> >> Hi Joel, >> >> >> >> >> >> I would like to echo the arguments that Bruno has made (and >> quote >> >> >> part of it) in his summary and then previously on this thread. >> >> >> >> >> >> /QOUTE/ >> >> >> >> >> >> /The point was related to the usefulness of the optional >> feature, >> >> >> which has been challenged./ >> >> >> >> >> >> /I was trying to say the required argumentation to declare >> usefulness >> >> >> or usefulness is asymmetric, from a logical discussion stand >> point./ >> >> >> >> >> >> // >> >> >> >> >> >> /a) It only requires one person to find it useful, in order to >> make >> >> >> the feature useful (for that person)./ >> >> >> >> >> >> /b) In order to state that this is un-useful, requires to prove >> that >> >> >> this is never useful./ >> >> >> >> >> >> /UNQOUTE/ >> >> >> >> >> >> It’s pure logic! >> >> >> >> >> >> Please check inline below. >> >> >> >> >> >> -----Original Message----- >> >> >> From: spring <spring-boun...@ietf.org >> <mailto:spring-boun...@ietf.org>> On Behalf Of Joel M. Halpern >> >> >> Sent: 03 March 2020 21:54 >> >> >> To: bruno.decra...@orange.com >> <mailto:bruno.decra...@orange.com>; >> Martin Vigoureux >> >> >> <martin.vigour...@nokia.com >> <mailto:martin.vigour...@nokia.com>>; >> spring@ietf.org <mailto:spring@ietf.org> >> >> >> Subject: Re: [spring] WGLC - >> >> >> draft-ietf-spring-srv6-network-programming >> >> >> >> >> >> I'm sorry, but "in my gear I want an option to move some work >> around, >> >> >> so I need a protocol behavior for that" is not usually, in and >> of >> >> >> itself, enough reason to add an optional feature to a protocol. >> >> >> >> >> >> */[KT] To start with, there are other/more use-cases for PSP as >> have >> >> >> been discussed on the list over the course of the WGLC and before then. >> >> >> I think you are referring to the use-case that Dan Voyer brought >> up >> >> >> with legacy hardware - I don't see an issue of being practical >> and >> >> >> sensitive to real world problems and scenarios. This is what >> results >> >> >> in actual adoption and deployment success. We have options >> everywhere >> >> >> - the EH themselves are optional … IIRC HBH options were not so >> >> >> recently made optional out of pure consideration of the actual >> metal >> >> >> out there in the Internet! /**/😊/* >> >> >> >> >> >> At one point there was an argument that PSP was needed for >> compliant >> >> >> devices that would not be able to process the packet. It has >> been >> >> >> pointed out since that such devices would not comply to 8200 >> (not >> >> >> because of PSP, but because being able to ignore an exhausted >> routing >> >> >> header is required in 8200). Having an optional feature to take >> care >> >> >> of devices which violate a standard again requires some strong >> >> >> evidence to justify it. >> >> >> >> >> >> */[KT] A device can be conformant with RFC8200 even if were >> punting >> >> >> the packets for local s/w processing in the presence of an EH >> (or RH >> >> >> in this case). In that case, it would not be doing line-rate >> >> >> forwarding which is the requirement here. This is again a very >> >> >> practical consideration that is rooted in real world problems >> and >> >> >> deployments. /* >> >> >> >> >> >> So no, from where I sit I have not seen a clear explanation of >> the >> >> >> value for PSP. >> >> >> >> >> >> */[KT] There have been many use-cases and values expressed for >> PSP by >> >> >> those that have implemented and deployed it. I can understand if >> you >> >> >> do not appreciate them. But they are optional and it is unfair >> to >> >> >> deny it to those who need it./* >> >> >> >> >> >> I also do not understand why the authors have resisted the usual >> >> >> solution to this sort of disagreement, namely moving the feature >> to a >> >> >> separate document. Given the structure of the network >> programming >> >> >> draft, and that it is not exhaustive in either flavors or >> programming >> >> >> behaviors, there is no violence done to the draft by removing >> this flavor. >> >> >> >> >> >> */[KT] I think we can go by the track record through the >> progression >> >> >> of this draft. The contentious topics related to SRH insertion >> were >> >> >> removed by the authors based on WG feedback and technical >> arguments – >> >> >> note this was done after it was a WG document. This WGLC has >> gone >> >> >> beyond the usual timeframe and resulted in unusually large >> amount of >> >> >> technical discussions. We do see that the document has undergone >> >> >> through multiple changes to improve the text as well as fix >> certain >> >> >> issues. /* >> >> >> >> >> >> *//* >> >> >> >> >> >> */So by no stretch of imagination can we say that the authors >> have >> >> >> been resistant to change when such a change was technically warranted. >> >> >> I do not believe the removal of PSP makes practical and >> technical >> >> >> sense for those who have implemented and deployed it with real >> world >> >> >> scenarios in >> >> >> mind./* >> >> >> >> >> >> *//* >> >> >> >> >> >> */Thanks,/* >> >> >> >> >> >> */Ketan/* >> >> >> >> >> >> Yours, >> >> >> >> >> >> Joel >> >> >> >> >> >> On 3/3/2020 10:49 AM, bruno.decra...@orange.com >> <mailto:bruno.decra...@orange.com> >> >> >> <mailto:bruno.decra...@orange.com> wrote: >> >> >> >> >> >> > Fernando >> >> >> >> >> >> > >> >> >> >> >> >> >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of >> >> >> Fernando >> >> >> >> >> >> >> Gont >> >> >> >> >> >> >> Sent: Monday, March 2, 2020 9:23 PM >> >> >> >> >> >> >> To: Martin Vigoureux; spring@ietf.org >> <mailto:spring@ietf.org> <mailto:spring@ietf.org> >> >> >> >> >> >> >> Cc: 6...@ietf.org <mailto:6...@ietf.org> >> <mailto:6...@ietf.org>; 'i...@ietf.org'; >> >> >> >> >> >> >> draft-ietf-spring-srv6-network-programming >> >> >> >> >> >> >> Subject: Re: [spring] WGLC - >> >> >> >> >> >> >> draft-ietf-spring-srv6-network-programming >> >> >> >> >> >> >> >> >> >> >> >> >> >> Martin, >> >> >> >> >> >> >> >> >> >> >> >> >> >> As an Area Director, what are your thoughts regarding >> Bruno's >> >> >> claim >> >> >> >> >> >> >> that this working group (Spring) doesn't have the necessary >> >> >> skills >> >> >> >> >> >> >> for evaluating the need of a functionality (PSP) that this >> wg is >> >> >> >> >> >> >> including in draft-ietf-spring-srv6-network-programming? >> >> >> >> >> >> >> >> >> >> >> >> >> >> Specifically, Bruno has noted (in >> >> >> >> >> >> >> >> >> >> >> https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/): >> >> >> >> >> >> >> >> >> >> >> >> >> >> ---- cut here ---- >> >> >> >> >> >> >> Independently of RFC 8200, the question has been raised >> with >> >> >> regards >> >> >> >> >> >> >> to the benefit of PSP. >> >> >> >> >> >> >> My take is that PSP is an optional data plane optimization. >> >> >> Judging >> >> >> >> >> >> >> its level of usefulness is very hardware and implementation >> >> >> >> >> >> >> dependent. It may range anywhere from "not needed" to >> "required >> >> >> for my platform" >> >> >> >> >> >> >> (deployed if you are network operator, or been sold if you >> are a >> >> >> >> >> >> >> vendor), with possible intermediate points along "n% packet >> >> >> >> >> >> >> processing gain", or "required when combined with a >> specific >> >> >> other >> >> >> >> >> >> >> feature". I don't think that the SPRING WG can really >> evaluate >> >> >> this >> >> >> >> >> >> >> point (lack of hardware knowledge, lack of detailed >> information >> >> >> on the hardwares). >> >> >> >> >> >> >> ---- cut here ---- >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Doesn't this sound a bit like a group is shipping something >> that >> >> >> it >> >> >> >> >> >> >> cannot really understand? >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > There have been replied and statement from the WG. E.g. From >> Dan >> >> >> (network operator) & Jingrong (vendor). >> >> >> >> >> >> > >> >> >> >> https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWp >> >> >> n >> >> >> >> >> >> > AI/ >> >> >> >> >> >> > >> >> >> >> >> >> > My comment is that a statement such as "(1) reduce the load >> of >> >> >> final destination.", while true in general, is difficult to >> evaluate, >> >> >> e.g. in term of packet processing gain, or NPU processing resource gain. >> >> >> >> >> >> > One can say "not on my hardware", but nobody can say "not in >> your >> >> >> hardware". >> >> >> >> >> >> > >> >> >> >> >> >> > And I think that this is along Joel reply (although I would >> not >> >> >> want >> >> >> >> >> >> > to speak for Joel) "Do you have any comments on what appears >> to >> >> >> be the >> >> >> >> >> >> > significant increase in complexity on the device performing PSP? >> >> >> The >> >> >> >> >> >> > question I am trying to get at is about the tradeoff, which >> needs >> >> >> one to evaluate both sides." >> >> >> >> >> >> > >> >> >> >> https://mailarchive.ietf.org/arch/msg/spring/CMSX7ijacRdG8qHlla61ylJN >> >> >> g >> >> >> >> >> >> > go/ >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > So in the end, what we have is the statement "(1) reduce the >> load >> >> >> of final destination.". >> >> >> >> >> >> > >> >> >> >> >> >> > Thanks, >> >> >> >> >> >> > --Bruno >> >> >> >> >> >> > >> >> >> >> >> >> >> Thanks, >> >> >> >> >> >> >> Fernando >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 2/3/20 15:53, Martin Vigoureux wrote: >> >> >> >> >> >> >>> WG, >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> as I had indicated in a previous message I am the one >> >> >> evaluating >> >> >> >> >> >> >>> consensus for this WG LC. >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> I have carefully read the discussions on the list. I >> >> >> acknowledge >> >> >> >> >> >> >>> that disagreements were expressed regarding what a >> particular >> >> >> piece >> >> >> >> >> >> >>> of text of RFC 8200 says, and on which this document >> builds to >> >> >> >> >> >> >>> propose an optional capability. Since RFC 8200 is not a >> product >> >> >> of >> >> >> >> >> >> >>> the SPRING WG, I have paid specific attention to the >> messages >> >> >> ([1], >> >> >> >> >> >> >>> [2], and [3]) sent by the responsible AD of 6MAN and of RFC8200. >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> My overall conclusion is that there is support and rough >> >> >> consensus >> >> >> >> >> >> >>> to move this document to the next stage. >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> Bruno will handle the immediate next steps. >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> Martin >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> [1] >> >> >> >> >> >> >>> >> >> >> >> https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rG >> >> >> >> >> >> >>> pcso/ >> >> >> >> >> >> >>> [2] >> >> >> >> >> >> >>> >> >> >> >> https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76F >> >> >> >> >> >> >>> ZmQ0/ >> >> >> >> >> >> >>> [3] >> >> >> >> >> >> >>> >> >> >> >> https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jS >> >> >> >> >> >> >>> IKBc/ >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> Le 2019-12-05 à 18:15, bruno.decra...@orange.com >> <mailto:bruno.decra...@orange.com> >> >> >> <mailto:bruno.decra...@orange.com> a écrit : >> >> >> >> >> >> >>>> Hello SPRING, >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> This email starts a two weeks Working Group Last Call on >> >> >> >> >> >> >>>> draft-ietf-spring-srv6-network-programming [1]. >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> Please read this document if you haven't read the most >> recent >> >> >> >> >> >> >>>> version, and send your comments to the SPRING WG list, no >> >> >> later than December 20. >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> You may copy the 6MAN WG for IPv6 related comment, but >> >> >> consider not >> >> >> >> >> >> >>>> duplicating emails on the 6MAN mailing list for the >> comments >> >> >> which >> >> >> >> >> >> >>>> are only spring specifics. >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> If you are raising a point which you expect will be >> >> >> specifically >> >> >> >> >> >> >>>> debated on the mailing list, consider using a specific >> >> >> email/thread >> >> >> >> >> >> >>>> for this point. >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> This may help avoiding that the thread become specific to >> this >> >> >> >> >> >> >>>> point and that other points get forgotten (or that the >> thread >> >> >> get >> >> >> >> >> >> >>>> converted into parallel independent discussions) >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> Thank you, >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> Bruno >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> [1] >> >> >> >> >> >> >>>> >> >> >> >> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programm >> >> >> >> >> >> >>>> ing-05 >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> >> >> >> >> ___________________________________________________________________ >> >> >> >> >> >> >>>> ______________________________________________________ >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> Ce message et ses pieces jointes peuvent contenir des >> >> >> informations >> >> >> >> >> >> >>>> confidentielles ou privilegiees et ne doivent donc pas >> etre >> >> >> >> >> >> >>>> diffuses, exploites ou copies sans autorisation. Si vous >> avez >> >> >> recu >> >> >> >> >> >> >>>> ce message par erreur, veuillez le signaler a >> l'expediteur et >> >> >> le >> >> >> >> >> >> >>>> detruire ainsi que les pieces jointes. Les messages >> >> >> electroniques >> >> >> >> >> >> >>>> etant susceptibles d'alteration, Orange decline toute >> >> >> >> >> >> >>>> responsabilite si ce message a ete altere, deforme ou falsifie. >> >> >> >> >> >> >>>> Merci. >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> This message and its attachments may contain confidential >> or >> >> >> >> >> >> >>>> privileged information that may be protected by law; they >> >> >> should >> >> >> >> >> >> >>>> not be distributed, used or copied without authorisation. >> >> >> >> >> >> >>>> If you have received this email in error, please notify >> the >> >> >> sender >> >> >> >> >> >> >>>> and delete this message and its attachments. >> >> >> >> >> >> >>>> As emails may be altered, Orange is not liable for >> messages >> >> >> that >> >> >> >> >> >> >>>> have been modified, changed or falsified. >> >> >> >> >> >> >>>> Thank you. >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> _______________________________________________ >> >> >> >> >> >> >>>> spring mailing list >> >> >> >> >> >> >>>> spring@ietf.org <mailto:spring@ietf.org> >> <mailto:spring@ietf.org> >> >> >> >> >> >> >>>> https://www.ietf.org/mailman/listinfo/spring >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> _______________________________________________ >> >> >> >> >> >> >>> spring mailing list >> >> >> >> >> >> >>> spring@ietf.org <mailto:spring@ietf.org> >> <mailto:spring@ietf.org> >> >> >> >> >> >> >>> https://www.ietf.org/mailman/listinfo/spring >> >> >> >> >> >> >>> . >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> >> Fernando Gont >> >> >> >> >> >> >> e-mail: ferna...@gont.com.ar <mailto:ferna...@gont.com.ar> >> <mailto:ferna...@gont.com.ar> || >> >> >> fg...@si6networks.com <mailto:fg...@si6networks.com> >> <mailto:fg...@si6networks.com> PGP >> >> >> >> >> >> >> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 >> FFF1 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> >> spring mailing list >> >> >> >> >> >> >> spring@ietf.org <mailto:spring@ietf.org> >> <mailto:spring@ietf.org> >> >> >> >> >> >> >> https://www.ietf.org/mailman/listinfo/spring >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> _____________________________________________________________________ >> >> >> _ >> >> >> >> >> >> > ___________________________________________________ >> >> >> >> >> >> > >> >> >> >> >> >> > Ce message et ses pieces jointes peuvent contenir des >> >> >> informations >> >> >> >> >> >> > confidentielles ou privilegiees et ne doivent donc pas etre >> >> >> diffuses, >> >> >> >> >> >> > exploites ou copies sans autorisation. Si vous avez recu ce >> >> >> message >> >> >> >> >> >> > par erreur, veuillez le signaler a l'expediteur et le >> detruire >> >> >> ainsi que les pieces jointes. Les messages electroniques etant >> >> >> susceptibles d'alteration, Orange decline toute responsabilite >> si ce >> >> >> message a ete altere, deforme ou falsifie. Merci. >> >> >> >> >> >> > >> >> >> >> >> >> > This message and its attachments may contain confidential or >> >> >> >> >> >> > privileged information that may be protected by law; they >> should >> >> >> not be distributed, used or copied without authorisation. >> >> >> >> >> >> > If you have received this email in error, please notify the >> >> >> sender and delete this message and its attachments. >> >> >> >> >> >> > As emails may be altered, Orange is not liable for messages >> that >> >> >> have been modified, changed or falsified. >> >> >> >> >> >> > Thank you. >> >> >> >> >> >> > >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> spring mailing list >> >> >> >> >> >> spring@ietf.org <mailto:spring@ietf.org> >> <mailto:spring@ietf.org> >> >> >> >> >> >> https://www.ietf.org/mailman/listinfo/spring >> >> >> >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
