Hi Sasha, In SR-MPLS, we have the inner VPN label and then we can have the BSID label. Similarly for SRv6, we have the VPN SID (e.g. End.DT4) and the BSID (i.e. End.B6.Encaps).
I hope that clarifies. Thanks, Ketan From: spring <spring-boun...@ietf.org> On Behalf Of Alexander Vainshtein Sent: 12 March 2020 16:03 To: Pablo Camarillo (pcamaril) <pcamaril=40cisco....@dmarc.ietf.org>; Christian Hopps <cho...@chopps.org> Cc: spring@ietf.org Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12 Pablo, Chris and all, I have not found the restriction for Binding SID not being the last SID in the SID list in RFC 8402 or RFC 8666. And I think that no such limitation exists in SR-MPLS, where a binding SID can be easily be the last SID in the LIST of SIDs in the SR policy that is used to deliver L3VPN traffic in an SR-based deployment of inter-AS Option C BGP/MPLS IP VPNs: * The ASBR of the AS hat contains the specific egress PR implements an intra-AS SR policy that goes to this PE, and allocates a Binding SID to steer packets into it * The ASBR of the AS that contains the specific ingress PE allocates an EPE SID to steer packets it receives from the PEs in this AS to the ASBR of the domain that contains the specific egress PE * The ingress PE implements an intra-AS SR policy going to the ASBR of this AS, augments it with the EPE SID to reach the ASNR of the AS that contains the specific egress PE and with the Binding SID allocated by this ASBR to reach the specific egress PE to obtain the inter-AS SR policy * VPN-IP routes are advertised by the egress PE to the ingress PE with the egress PE as their BGP NH, and the ingress PE resolved these routes using an inter-AS SR policy that, from its POV, has the Binding SID as the last entry in the SID list * VPN application labels carried in the VPN-IP routes do not represent any SIDs at all. Did I miss something substantial? Is the restriction you define here specific to just SRv6? Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com> -----Original Message----- From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of Pablo Camarillo (pcamaril) Sent: Thursday, March 12, 2020 12:06 PM To: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12 Hi Chris, The Binding SIDs have a restriction not to be the last SID in a SID list. This applies to all three Binding SID behaviors defined in draft-ietf-spring-network-programming (End.B6.Encaps, End.B6.Encaps.Red and End.BM) and is indicated by the statements such as "An End.B6.Encaps SID is never the last segment in a SID list." in section 4.13. More precisely, when a node processes the SRH of a packet whose IPv6 Destination Address matches a locally instantiated SRv6 Binding-SID behavior (any of the three) and it is not the last segment in the SID list, it steers the packet into the associated SR Policy (either by performing an IPv6 encapsulation or by pushing an MPLS label stack on top of the existing packet). However, if the binding SID is the last SID in a SID list or the IPv6 DA in a packet with no SRH, then the router will generate an ICMP Parameter Problem message with code 4. In either of those two cases, the packet is not steered in the SR Policy and the source is notified of the issue. This restriction exists for two reasons: First, the primary use-case for the Binding-SID concept is to apply an intermediate SR Policy that steers the packet along a particular path in an intermediate sub-domain, but the original SID-list is expected to steer the traffic up to the egress node of the SR domain. This means that the final segment in the original SID-list is usually an End.D* (VPN) segment at the egress node. Second, the processing a Binding-SID at a last position in a SID list requires a different processing. First you would need to decapsulate the packet (since it has reached it final destination) and then re-encapsulate it (or push a label stack on top of the inner packet). Many thanks, Pablo. -----Original Message----- From: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> Date: Wednesday, 11 March 2020 at 20:21 To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com<mailto:pcama...@cisco.com>> Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12 > On Mar 11, 2020, at 2:44 PM, Pablo Camarillo (pcamaril) <pcama...@cisco.com<mailto:pcama...@cisco.com>> wrote: > > Hi Chris, > > Indeed, an IPv6 packet with no SRH (and FIB entry is local End SID) is one way to get to the Upper Layer Header processing defined in 4.1.1. > Another way is to have a FIB entry bound to an End.DT* or End.DX* behavior. In these cases the ULH processing occurs if the SRH has SL=0 or there's no SRH. Ah right, sorry that's right there in the document, it's easy too lose track of all this when multitasking on other things. :) So if you don't mind, going back to my original question of how this works with Binding SID cases... You replied: "Normally the Upper-Layer Header should not be processed on a packet with a BSID, since you have just pushed an SR policy into the packet. That said, when the ultimate destination is BSID, then the Upper Layer Header processing is the same to End (4.1)." Can you expand on "when the ultimate destination is BSID"? Do you mean when the ultimate destination of the packet is the same node N that is currently processing the BSID FIB entry? If so then that will have to be handled in whatever way it should be after it is resubmitted to either IPv6 or MPLS engines and forwarded and then decapsulated. There won't be anymore header processing to follow from 4.{13,14,15} though. Given something has been added (an IPv6 header or an MPLS label stack) that still needs to get processed and removed before any upper-layer header of the now encapsulated packet gets looked at. I also find another bit of text confusing in these sections: "An End.BM SID is never the last SID, and any SID instantiation is associated with an SR-MPLS Policy B." Is that text is saying that if one lands on a BSID one can always expect more SIDs to be used in moving the packet (b/c of pushing an new IPv6 encap or MPLS label stack)? It's confusing b/c it certainly can read that a BSID can't be the "Last Segment" in an SRH, but that doesn't seem like a reasonable restriction. Thanks, Chris. > > Many thanks, > Pablo. > > -----Original Message----- > From: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> > Date: Wednesday, 11 March 2020 at 17:08 > To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com<mailto:pcama...@cisco.com>> > Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> > Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12 > > > >> On Mar 11, 2020, at 8:16 AM, Pablo Camarillo (pcamaril) <pcamaril=40cisco....@dmarc.ietf.org<mailto:pcamaril=40cisco....@dmarc.ietf.org>> wrote: >> >> Hi Chris, >> >> The processing defined in draft-ietf-spring-srv6-network-programming is aligned with the SRH. >> Particularly see https://clicktime.symantec.com/a/1/OOssComq7nKv3aheXcw3XaZubndcUPTiP4r7XKVYET0=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6man-segment-routing-header-26%23section-4.3 >> >>> Is 4.1.1 covering (and only covering) the case where my FIB lookup yields a local End SID, but the packet has no SRH in it? >> >> It is not *only* covering that case (although that is one of the cases, there are others). You process the extension header chain as defined in RFC8200. > > Right I had quoted the 8200 processing order so I'm using that as a guide. > >> When processing the SRH you follow the processing of 4.1; If you get to the Upper Layer Header, you process it as per 4.1.1 > > This is what I'm getting at though, if there is an SRH you will enter section 4.1 prior to 4.1.1, and if you are in 4.1 there is no processing path that leads to the upper-layer header. So AFAICT the only way to get to section 4.1.1 is if the FIB entry is a local END SID and there is no SRH. > > Thanks, > Chris. > >> >> Thank you, >> Pablo. >> >> -----Original Message----- >> From: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> >> Date: Wednesday, 11 March 2020 at 12:06 >> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com<mailto:pcama...@cisco.com>> >> Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> >> Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12 >> >> >> >>> On Mar 11, 2020, at 5:59 AM, Pablo Camarillo (pcamaril) <pcamaril=40cisco....@dmarc.ietf.org<mailto:pcamaril=40cisco....@dmarc.ietf.org>> wrote: >>> >>> Hi Chris, >>> >>> They are the same thing. >> >> Ok, so how do I get on 2 different processing paths for the same thing entry as Section 4.1 cannot lead to processing of an upper-layer header as far as I can tell, yet section 4.1.1 is talking about processing the upper layer header for the same FIB entry. >> >> 1) Packet arrives, FIB lookup on packet destination address returns local End SID entry. >> >> 2) Start processing the extension headers and arrive at the SRH (which comes prior to the upper-layer header. >> >> From RFC8200 the extension header order: >> IPv6 header >> Hop-by-Hop Options header >> Destination Options header (note 1) >> Routing header <------------------------------------ SRH >> Fragment header >> Authentication header (note 2) >> Encapsulating Security Payload header (note 2) >> Destination Options header (note 3) >> Upper-Layer header <-------------------------------- Upper Layer Header >> >> 3) Process the SRH according to 4.1 for which there is no exit that leads to processing any more headers. >> >> Oh wait... >> >> Is 4.1.1 covering (and only covering) the case where my FIB lookup yields a local End SID, but the packet has no SRH in it? If this is the case then it would make things *way* more clear for the document to state this outright. "When a packet's DA returns a FIB entry for a local END SID, but the packet does not contain an SRH ..." or something like that. >> >> Thanks, >> Chris. >> >> >>> >>> Section 3: >>> ... >>> Its processing is defined in [I-D.ietf-6man-segment-routing-header] >>> section 4.3 and reproduced here as a reminder. >>> >>> Without constraining the details of an implementation, the SR >>> segment endpoint node creates Forwarding Information Base (FIB) >>> entries for its local SIDs. >>> >>> When an SRv6-capable node receives an IPv6 packet, it performs a >>> longest-prefix-match lookup on the packets destination address. >>> This lookup can return any of the following: >>> >>> - A FIB entry that represents a locally instantiated SRv6 SID >>> >>> - A FIB entry that represents a local interface, not locally >>> instantiated as an SRv6 SID >>> >>> - A FIB entry that represents a non-local route >>> >>> - No Match >>> >>> Section 4: >>>> Each FIB entry indicates the behavior associated with a SID instance >>>> and its parameters. >>> >>> Thank you, >>> Pablo. >>> >>> -----Original Message----- >>> From: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> >>> Date: Tuesday, 10 March 2020 at 22:01 >>> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com<mailto:pcama...@cisco.com>> >>> Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> >>> Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12 >>> >>> >>> >>>> On Mar 10, 2020, at 2:13 PM, Pablo Camarillo (pcamaril) <pcamaril=40cisco....@dmarc.ietf.org<mailto:pcamaril=40cisco....@dmarc.ietf.org>> wrote: >>>> >>>> Hi Chris, >>>> >>>> Thanks for going through the document. >>>> The behaviors 4.13 (End.B6.Encaps), 4.14 (End.B6.Encaps.Red) and 4.15 (End.BM) correspond to Binding SIDs [1]. >>>> >>>> As a result of 4.13 for example, the packet is encapsulated with a new IPv6 header and an SRH that contains the SR policy associated to the BSID. >>>> Once the new IPv6 header is pushed into the packet, the NET-PGM pseudocode passes this packet to the IPv6 module of the router for transmission. >>>> >>>> Normally the Upper-Layer Header should not be processed on a packet with a BSID, since you have just pushed an SR policy into the packet. >>>> That said, when the ultimate destination is BSID, then the Upper Layer Header processing is the same to End (4.1). >>>> >>>> Hope it clarifies. >>> >>> I'm still not clear on things I guess, but your answer leads me to a more basic question: >>> >>> Section 4.1 described the basic "FIB entry" "End" which says: >>> >>> "When N receives a packet whose IPv6 DA is S and S is a local End SID, N does..." >>> >>> So it's talking about a FIB entry for a "local End SID". >>> >>> Section 4.1.1 says: >>> >>> "When processing the Upper-layer Header of a packet matching a FIB >>> entry locally instantiated as an SRv6 End SID" >>> >>> It's talking about a "FIB entry locally instantiated as an SRv6 END SID" >>> >>> I'm not understanding how these 2 things are different. 4.1s calling a FIB Entry a "local End SID" 4.1.1 is calling something (different?) a "FIB Entry locally instantiated as an SRv6 END SID". >>> >>> The terms seem too similar for me to make a distinction, where I feel the document expects me to make one. >>> >>> Thanks, >>> Chris. >>> >>> >>>> >>>> Thanks, >>>> Pablo. >>>> >>>> [1]. https://clicktime.symantec.com/a/1/ilkEJxP-mj7tnQF8crEOD_-axeoYHnBkoeJojGc0dEc=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402%23section-5 >>>> >>>> >>>> -----Original Message----- >>>> From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on behalf of Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> >>>> Date: Saturday, 7 March 2020 at 12:50 >>>> To: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> >>>> Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> >>>> Subject: [spring] Question on draft-ietf-spring-srv6-network-programming-12 >>>> >>>> In sections 4.13, (implicitly in 4.14) and 4.15 a set of steps is indicated. As far as I can tell the processing of the IPv6 header chain in all cases is terminated. e.g., >>>> >>>> " >>>> When N receives a packet whose IPv6 DA is S and S is a local End.BM >>>> SID, does: >>>> >>>> S01. When an SRH is processed { >>>> S02. If (Segments Left == 0) { >>>> .... >>>> Interrupt packet processing and discard the packet. >>>> S04. } >>>> S05. If (IPv6 Hop Limit <= 1) { >>>> .... >>>> Interrupt packet processing and discard the packet. >>>> S07. } >>>> S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { >>>> .... >>>> Interrupt packet processing and discard the packet. >>>> S11. } >>>> .... >>>> S15. Submit the packet to the MPLS engine for transmission to the >>>> topmost label. >>>> S16. } >>>> " >>>> >>>> The text then says: >>>> >>>> When processing the Upper-layer header of a packet matching a FIB >>>> entry locally instantiated as an SRv6 End.BM SID, process the packet >>>> as per Section 4.1.1. >>>> >>>> Why would I ever be processing the upper-layer header at this point? >>>> >>>> Thanks, >>>> Chris. >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org<mailto:spring@ietf.org> >>>> https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>>> >>>> >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org<mailto:spring@ietf.org> >>>> https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>> >>> >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org<mailto:spring@ietf.org> >>> https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> >> >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org<mailto:spring@ietf.org> >> https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> > > > _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://clicktime.symantec.com/a/1/Cdwzr-UEQMgwVYTI1eE5ix_5auaoRYzQKe9WVcMQ9MA=?d=FbLmDjVXbJhuMaAIeX4cFFFRyrykGJavriicKiMxIQmdbSLxawLPSlrgcZ8De4_VQPzYrIsIYu2Jpc6QjNpZWS3PiZaTFfeXC8XGjYl9YbsV2bSSqlKHj_RjzPOu_kt25loIwxspA7A3E--SZtLiLLyd4P5YBrCwuWwiPCoPRLIpAzbJ9P_R6b1K50qCQ4Q1glwB49KSM8nVDIJwsgkhY88KYSnFh3qVrXuAvTIUefHFLjrWyC1-ZHa99SHSs6-17QweSzVGf2LYBweiGQAqTcS-yp8BuVpwn9pg2WByynfNbk-85azDwcp2zfhA6bOZF7KkcH-Id1Sp7ko_TXsYJNElY0Mf2sa9gEtAruMwcmhnDWeTnwt9743JGtNA-k6AThTzy0xgZryhYxUHAVfzux8AmLMU2QXKbuGgtZoCYPmHo-G-giUPTuS5nGd2hYdCVb5GGYK5QoO43xeJxP0JqtJfXlhzeKqobRIKn1Txo1fWC547iPw_0dU4aJrrwAng&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
