[spring] Re: [IPv6]Re: New Version Notification for dr aft-varhal-6man-icmp-srv6-vpn-01.txt
Joel Halpern <[email protected]> Wed, 15 Apr 2026 10:23:04 -0400
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============1369486889570811502== Content-Type: multipart/alternative; boundary="------------E9o2zsLGK0kVXEj3AHrnU4iO" Content-Language: en-US This is a multi-part message in MIME format. --------------E9o2zsLGK0kVXEj3AHrnU4iO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Without getting into the details, let me ask about what I see as one important difference in the two approaches. What happens when the path from the ingress to the egress is broken somewhere along the way. With draft-ali, that seems to mean that all probes of the path fail. Traceroute will always associate the failrue with the ingress. Our intention with draft-varhal is that the probes will succeed along the path until they reach the failure. Thus giving the operator and the customer (when the operator is willing to expose these details) better visibility. Is there some way that I am missing that draft-ali allows one to determine where a path failure is occurring? Thank you, Joel On 4/15/2026 7:14 AM, Krzysztof Szarkowicz wrote: > Hi Balázs, > > > Thank you for your comments. Please see my responses inline. > > > Cheers, > Krzysztof > > >> On 2026 Apr 2, at 17:06, Balázs Varga A <[email protected]> >> wrote: >> >> Hi Krzysztof, >> many thanks for the review of the updated draft. Reaction as follows: >> 1, Multiple IP encapsulation (e.g., B-SID): >> I do not think this is an VPN-specific issue. It is a more general one. >> Let's assume such a network (B-SID used between P2/P3/P4): >> A--PE1--P1--P2==P3==P4--P5--PE2--B >> If You are tracerouting PE2 from PE1 and Your HL expire at P3, as per >> current >> RFCs, the ICMP error is sent to P2 and PE1 will not receive the ICMP >> error >> message. The multiple encapsulation part of the path is not visible >> for the >> traceroute. >> Note, that there are no VPNs in the above example. The issue is not >> VPN specific, >> but VPN traceroute also suffers from this unwanted characteristics. >> I think we agree that here we need a solution, but I would not expect >> from a >> VPN specific solution to solve it. We need a more general one. > > [Krzysztof] Indeed. Hence, authors of > draft-ali-6man-srv6-vpn-icmp-error-handling proposed a solution to > solve this (among many others) use case. > >> 2, Real IPv4 address of 'P' node: >> This is covered in the draft. Please, double check the last paragraph in >> section 3.4. It is also part of the illustration in Section 3.5 (see >> the last >> PE1_out packet at the end of the section). > > [Krzysztof] I see in the draft: “How the PE node is aware of that > information is out-of-scope in this document.” > draft-ali-6man-srv6-vpn-icmp-error-handling, on the other hand, covers > that use case as well. > > >> 3. Handling migration/interop (MPLS <-> SRv6) scenarios: >> Please clarify by describing the scenario details You are referring >> to. Many thanks. > > [Krzysztof] For example, Mo6 > (draft-ietf-spring-srv6-mpls-interworking-02, Section 7.1.1.2). > Topology diagram from the draft: > > +-----+ +-----+ RD:V/v via 10 +-----+ > .......|S-RR1|<...............|S-RR2|<.................|S-RR3| <.. > : +-----+ +-----+ +-----+ : > : : > : : > +--:-------------------+----------------------+---------------------:-+ > | : | 2 | | | 5 | | | 8 | : | > | : +---+ | +---+ | +---+ : | > | : | | : | > | : | | : | > | : | | : | > |----+ IGP1 +---+ IGP2 +---+ IGP3 +----| > | 1 | | 4 | | 7 | | 10 | > |----+ +---+ +---+ +----| > | | | | > | | | | > | | | | > | +---+ | +---+ | +---+ | > | | 3 | | | 6 | | | 9 | | > +----------------------+----------------------+-----------------------+ > iPE iBR eBR ePE > > <----------LI---------><----------C----------><-----------LE----------> > Figure 1 > <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-02#figure-1>: > Reference multi-domain network topology > <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-02#name-reference-multi-domain-netw> > > In Mo6, IGP1 and IGP3 are MPLS domains, whereas IGP2 is SRv6 domain. > Assume, TTL/HC expires in IGP2 (SRv6 domain) at some transit node > between node ‘4’ and node ‘7’. > >> 4. Handling VPNs with DX4/DX6 SIDs: >> This is covered in the draft. Please, double check Section 3.2. The >> paragraph after >> the "Packet processing" steps clarifies it in detail. > > [Krzysztof] I see following in the draft: > > More specifically for a VPN service the PE node can allocate SID(s) > per-prefix (e.g., End.DX6) or per-vrf (e.g., End.DT6). The solution > uses a per-vrf SID (e.g., End.DT6) in the IP SA of the SRv6 > encapsulated packets. > > So, no description about deployments using DX4/DX6. Draft addresses > only deployments using DT4/DT6/DT46. > >> 5. Handling of Hub-and-Spoke VRFs: >> This is covered in the draft. Please, double check Section 3.2. The >> second paragraph >> after the "Packet processing" steps clarifies it in detail. > > [Krzysztof] in the draft I see: > > For more sophisticated VPN configurations (e.g., Hub-and-Spoke VPN) > where multiple VRFs (and SIDs) are configured for a given VPN, the VPN > specific SID of PE1 always refers to the VRF instance (and its per-vrf > SID) where the prefixes of the connected customer site(s) can be > looked up. > > Draft assumes per-VRF SID, while many hub-and-spoke deployments use > per-CE SID, to prevent IP lookup inside spoke VRF and thus to prevent > unintentional direct CE-to-CE communication inside spoke VRF. > >> 6. Routable VPN-specific SID + multi-domain scenario: >> Multi-domain has its side-effects. See reply regarding item 1). > > [Krzysztof] Indeed. The authors of > draft-ali-6man-srv6-vpn-icmp-error-handling realized that, and > proposed solution in the draft-ali-6man-srv6-vpn-icmp-error-handling > to address this. > >> 7. Different visibility for served VPNs >> Yes, this section needs some further clarification. It is an >> additional (optional) >> capability of the VPN-associated-ICMP-process-function. We will >> update for the >> next version. >> Thanks & Cheers >> Bala'zs >> *From:*Krzysztof Szarkowicz <[email protected]> >> *Sent:*Monday, March 30, 2026 10:01 AM >> *To:*Balázs Varga A <[email protected]> >> *Cc:*SPRING WG List <[email protected]>; IPv6 List <[email protected]>; >> Mustapha Aissaoui (Nokia) <[email protected]> >> *Subject:*Re: [spring] New Version Notification for >> draft-varhal-6man-icmp-srv6-vpn-01.txt >> Hi Balázs, >> I have checked the updated version of the draft. It addresses some >> shortcomings of this solution raised for initial version of the >> draft, but is still doesn't address many other shortcomings: >> 1. Handling of multiple IP encapsulations (e.g. expanding of B-SID >> with encap mode) on the node that is not service aware - i.e., B-SID >> is expanded on a node without VRF, and with no service prefix visibility) >> 2. Providing real IPv4 address of 'P' node (when such address exists >> - for example during migration scenarios, when dual IPv4/IPv6 stack >> is used) to the node invoking IPv4 traceroute >> 3. Handling migration/interop (MPLS <-> SRv6) scenarios >> 4. Handling VPNs with DX4/DX6 SIDs, where DT4/DT6/DT46 SIDs are not >> deployed >> 5. Handling of Hub-and-Spoke VRFs, where on PE traffic incoming on >> PE-CE interfaces in multiple local VRFs, is forced (vendor >> terminology: filter based forwarding, policy based routing, etc.) via >> single outgoing VRF (VRF-out) >> 6. "As the locator part of the VPN-specific SID is routable within >> the SRv6 domain other PE and P nodes of the SRv6 domain can >> send/route packets to it." -> this is not necessarily true in >> multi-domain designs, with B-SID expansion at domain boundaries. >> 7. "It can hide the SIDs used inside the SRv6 domain and can provide >> different visibility for served VPNs if needed." -> Not sure, if I >> understand this statement >> Cheers, >> Krzysztof >> >> >> On 2026 Mar 18, at 22:30, Mustapha Aissaoui (Nokia) >> <[email protected]> wrote: >> Hi Balazs, >> I have a couple of comments on this draft. >> The first one is to referenceRFC 2473 >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2473*section-8__;Iw!!NEt6yMaO-gk!CQq_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79hihx0kcrkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$> as >> it is well described that an ICMP reply must be sent on the outer >> IPv6 header in the case of an IP-in-IP tunnel. For me this is the >> closest prior art we can refer to when discussing potential new >> solutions, other than ICMP tunneling. >> This RFC also describes a general ICMP relay function covering >> various ICMP error messages. In the specific context of a TCP/UDP >> traceroute probe, this relay function will only work for >> traceroute packets of routes in the global routing table as >> discussed in an earlier thread on >> draft-ali-6man-srv6-vpn-icmp-error-handling. It does however not >> address probes sent in VRF context. >> The second is regarding the use of a SRv6 service SID as the >> source address on the outer IPv6 header. The source address in >> the outer IPv6 header is used by downstream routers to report >> various ICMP error messages on the SRv6 tunnel, some of which are >> ad-hoc and triggered by malformed outer headers in user packets. >> Hence it cannot be sent to a specific VRF context of the ingress >> SRv6 PE. >> I can see a service SID being used as the source address of the >> traceroute for probes originating at the ingress SRv6 PE since >> the user can configure this specifically for these probes. But >> not for probes generated by the CE since they are treated as user >> packets at the ingress SRv6 PE and they would inherit the source >> address of the SRv6 tunnel. For probes originating at the ingress >> SRv6 PE, one can correlate the error message with a specific VPN >> or global routing table traceroute probe based on TCP or UDP port >> number. So there are alternatives too. >> Regards, >> Mustapha. >> >> *From:*Balázs Varga A <[email protected]> >> *Date:*Monday, March 16, 2026 at 9:51 AM >> *To:*SPRING WG List <[email protected]>, IPv6 List <[email protected]> >> *Subject:*[spring] FW: New Version Notification for >> draft-varhal-6man-icmp-srv6-vpn-01.txt >> >> >> CAUTION: This is an external email. Please be very careful when >> clicking links or opening attachments. See the URLnok.it/ext >> <http://nok.it/ext>for additional information. >> >> >> >> Hi, >> >> Based on the valuable feedbacks on the lists the draft on >> "ICMP Error Handling for VPNs in SRv6 Networks" was >> updated. >> >> Thanks & Cheers >> Bala'zs (and Joel) >> >> -----Original Message----- >> From:[email protected]<[email protected]> >> Sent: Monday, March 16, 2026 2:36 PM >> To: Balázs Varga A <[email protected]>; Joel Halpern >> <[email protected]> >> Subject: New Version Notification for >> draft-varhal-6man-icmp-srv6-vpn-01.txt >> >> A new version of Internet-Draft >> draft-varhal-6man-icmp-srv6-vpn-01.txt has been successfully >> submitted by Balazs Varga and posted to the IETF repository. >> >> Name: draft-varhal-6man-icmp-srv6-vpn >> Revision: 01 >> Title: ICMP Error Handling for VPNs in SRv6 Networks >> Date: 2026-03-16 >> Group: Individual Submission >> Pages: 12 >> URL: >> https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-vpn/ >> HTMLized:https://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-vpn >> Diff: >> https://author-tools.ietf.org/iddiff?url2=draft-varhal-6man-icmp-srv6-vpn-01 >> >> Abstract: >> >> This document specifies ICMP error handling in SRv6-based Virtual >> Private Networks, that support direct localization of >> failures. It >> provides a solution for connectivity check and fault localization >> without adding complexity to P nodes and keeps P nodes service >> agnostic. ICMP processing is changed only on ingress PE nodes and >> gains from adding VPN-specific information to the SRv6 >> encapsulated >> packet. Egress PE nodes are not involved in the forwarding of the >> ICMP error messages. Therefore, the solution provides visibility >> upto the failure even if ingress PE to egress PE connectivity is >> broken within the SR domain. >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> spring mailing list [email protected] >> To unsubscribe send an email [email protected] >> _______________________________________________ >> spring mailing list [email protected] >> To unsubscribe send an email [email protected] >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > List Info:https://mailman3.ietf.org/mailman3/lists/[email protected]/ > -------------------------------------------------------------------- --------------E9o2zsLGK0kVXEj3AHrnU4iO Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>Without getting into the details, let me ask about what I see as one important difference in the two approaches.</p> <p>What happens when the path from the ingress to the egress is broken somewhere along the way. With draft-ali, that seems to mean that all probes of the path fail. Traceroute will always associate the failrue with the ingress. Our intention with draft-varhal is that the probes will succeed along the path until they reach the failure. Thus giving the operator and the customer (when the operator is willing to expose these details) better visibility.</p> <p>Is there some way that I am missing that draft-ali allows one to determine where a path failure is occurring?</p> <p>Thank you,</p> <p>Joel</p> <div class="moz-cite-prefix">On 4/15/2026 7:14 AM, Krzysztof Szarkowicz wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> Hi Balázs, <div><br> </div> <div><br> </div> <div>Thank you for your comments. Please see my responses inline.</div> <div><br> </div> <div><br> </div> <div>Cheers,</div> <div>Krzysztof</div> <div><br id="lineBreakAtBeginningOfMessage"> <div><br> <blockquote type="cite"> <div>On 2026 Apr 2, at 17:06, Balázs Varga A <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote:</div> <br class="Apple-interchange-newline"> <div> <meta charset="UTF-8"> <div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;"> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Hi Krzysztof,<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">many thanks for the review of the updated draft. Reaction as follows:<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">1, Multiple IP encapsulation (e.g., B-SID):<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">I do not think this is an VPN-specific issue. It is a more general one.<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Let's assume such a network (B-SID used between P2/P3/P4):<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">A--PE1--P1--P2==P3==P4--P5--PE2--B<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">If You are tracerouting PE2 from PE1 and Your HL expire at P3, as per current<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">RFCs, the ICMP error is sent to P2 and PE1 will not receive the ICMP error<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">message. The multiple encapsulation part of the path is not visible for the<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">traceroute.<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Note, that there are no VPNs in the above example. The issue is not VPN specific,<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">but VPN traceroute also suffers from this unwanted characteristics.<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">I think we agree that here we need a solution, but I would not expect from a<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">VPN specific solution to solve it. We need a more general one.</div> </div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] Indeed. Hence, authors of draft-ali-6man-srv6-vpn-icmp-error-handling proposed a solution to solve this (among many others) use case.</div> <br> <blockquote type="cite"> <div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;"> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">2, Real IPv4 address of 'P' node:<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">This is covered in the draft. Please, double check the last paragraph in<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">section 3.4. It is also part of the illustration in Section 3.5 (see the last<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">PE1_out packet at the end of the section).</div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] I see in the draft: “How the PE node is aware of that information is out-of-scope in this document.” draft-ali-6man-srv6-vpn-icmp-error-handling, on the other hand, covers that use case as well.</div> <div><br> </div> <br> <blockquote type="cite"> <div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;"> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">3. Handling migration/interop (MPLS <-> SRv6) scenarios:<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Please clarify by describing the scenario details You are referring to. Many thanks.</div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] For example, Mo6 (draft-ietf-spring-srv6-mpls-interworking-02, Section 7.1.1.2). Topology diagram from the draft:</div> <div><br> </div> <div> <div class="alignLeft art-text artwork" id="section-2-2.1" style="font-size: 16px; box-sizing: border-box; margin-top: 20.8px; margin-bottom: 20.8px; flex-wrap: nowrap; align-items: end; display: flex; color: rgb(32, 37, 42); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-variant-ligatures: normal; background-color: rgb(255, 255, 255);"> <pre style="box-sizing: border-box; font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-size: 1em; margin: 0px; overflow: auto clip; padding: 0px; flex: 0 0 content; max-width: 72ch;"> +-----+ +-----+ RD:V/v via 10 +-----+ .......|S-RR1|<...............|S-RR2|<.................|S-RR3| <.. : +-----+ +-----+ +-----+ : : : : : +--:-------------------+----------------------+---------------------:-+ | : | 2 | | | 5 | | | 8 | : | | : +---+ | +---+ | +---+ : | | : | | : | | : | | : | | : | | : | |----+ IGP1 +---+ IGP2 +---+ IGP3 +----| | 1 | | 4 | | 7 | | 10 | |----+ +---+ +---+ +----| | | | | | | | | | | | | | +---+ | +---+ | +---+ | | | 3 | | | 6 | | | 9 | | +----------------------+----------------------+-----------------------+ iPE iBR eBR ePE <----------LI---------><----------C----------><-----------LE----------> </pre> </div> <figcaption style="font-size: 16px; box-sizing: border-box; text-align: center; margin-top: 20.8px; color: rgb(32, 37, 42); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-variant-ligatures: normal; background-color: rgb(255, 255, 255);"><a href="https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-02#figure-1" class="selfRef" style="box-sizing: border-box; color: inherit; text-decoration: none;" moz-do-not-send="true">Figure 1</a>: <a href="https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-02#name-reference-multi-domain-netw" class="selfRef" style="box-sizing: border-box; color: inherit; text-decoration: none;" moz-do-not-send="true">Reference multi-domain network topology</a></figcaption></div> <div><br> </div> <div>In Mo6, IGP1 and IGP3 are MPLS domains, whereas IGP2 is SRv6 domain. Assume, TTL/HC expires in IGP2 (SRv6 domain) at some transit node between node ‘4’ and node ‘7’.</div> <br> <blockquote type="cite"> <div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;"> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">4. Handling VPNs with DX4/DX6 SIDs:<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">This is covered in the draft. Please, double check Section 3.2. The paragraph after<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">the "Packet processing" steps clarifies it in detail.</div> </div> </blockquote> <div><br> </div> [Krzysztof] I see following in the draft:</div> <div> <p id="section-3.2-5" style="font-size: 16px; box-sizing: border-box; margin: 20.8px 0px 20.8px 3ch; overflow-wrap: break-word; color: rgb(32, 37, 42); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-variant-ligatures: normal; background-color: rgb(255, 255, 255);">More specifically for a VPN service the PE node can allocate SID(s) per-prefix (e.g., End.DX6) or per-vrf (e.g., End.DT6). The solution uses a per-vrf SID (e.g., End.DT6) in the IP SA of the SRv6 encapsulated packets.</p> </div> <div>So, no description about deployments using DX4/DX6. Draft addresses only deployments using DT4/DT6/DT46.</div> <div><br> <blockquote type="cite"> <div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;"> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">5. Handling of Hub-and-Spoke VRFs:<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">This is covered in the draft. Please, double check Section 3.2. The second paragraph<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">after the "Packet processing" steps clarifies it in detail.</div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] in the draft I see:</div> <div> <p id="section-3.2-6" style="font-size: 16px; box-sizing: border-box; margin: 20.8px 0px 20.8px 3ch; overflow-wrap: break-word; color: rgb(32, 37, 42); font-family: "Noto Sans Mono", SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; font-variant-ligatures: normal; background-color: rgb(255, 255, 255);">For more sophisticated VPN configurations (e.g., Hub-and-Spoke VPN) where multiple VRFs (and SIDs) are configured for a given VPN, the VPN specific SID of PE1 always refers to the VRF instance (and its per-vrf SID) where the prefixes of the connected customer site(s) can be looked up.</p> </div> <div>Draft assumes per-VRF SID, while many hub-and-spoke deployments use per-CE SID, to prevent IP lookup inside spoke VRF and thus to prevent unintentional direct CE-to-CE communication inside spoke VRF.</div> <br> <blockquote type="cite"> <div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;"> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">6. Routable VPN-specific SID + multi-domain scenario:<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Multi-domain has its side-effects. See reply regarding item 1).</div> </div> </blockquote> <div><br> </div> <div>[Krzysztof] Indeed. The authors of draft-ali-6man-srv6-vpn-icmp-error-handling realized that, and proposed solution in the draft-ali-6man-srv6-vpn-icmp-error-handling to address this.</div> <br> <blockquote type="cite"> <div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickness: auto; text-decoration-style: solid;"> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">7. Different visibility for served VPNs<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Yes, this section needs some further clarification. It is an additional (optional)<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">capability of the VPN-associated-ICMP-process-function. We will update for the<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">next version.<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Thanks & Cheers<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Bala'zs<o:p></o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div> <div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) currentcolor currentcolor; border-image: none; padding: 3pt 0in 0in;"> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif;">From:</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif;"><span class="Apple-converted-space"> </span>Krzysztof Szarkowicz <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>><br> <b>Sent:</b><span class="Apple-converted-space"> </span>Monday, March 30, 2026 10:01 AM<br> <b>To:</b><span class="Apple-converted-space"> </span>Balázs Varga A <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>><br> <b>Cc:</b><span class="Apple-converted-space"> </span>SPRING WG List <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>>; IPv6 List <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>>; Mustapha Aissaoui (Nokia) <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>><br> <b>Subject:</b><span class="Apple-converted-space"> </span>Re: [spring] New Version Notification for draft-varhal-6man-icmp-srv6-vpn-01.txt<o:p></o:p></span></div> </div> </div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Hi Balázs,<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">I have checked the updated version of the draft. It addresses some shortcomings of this solution raised for initial version of the draft, but is still doesn't address many other shortcomings:<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">1. Handling of multiple IP encapsulations (e.g. expanding of B-SID with encap mode) on the node that is not service aware - i.e., B-SID is expanded on a node without VRF, and with no service prefix visibility)<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">2. Providing real IPv4 address of 'P' node (when such address exists - for example during migration scenarios, when dual IPv4/IPv6 stack is used) to the node invoking IPv4 traceroute<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">3. Handling migration/interop (MPLS <-> SRv6) scenarios<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">4. Handling VPNs with DX4/DX6 SIDs, where DT4/DT6/DT46 SIDs are not deployed<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">5. Handling of Hub-and-Spoke VRFs, where on PE traffic incoming on PE-CE interfaces in multiple local VRFs, is forced (vendor terminology: filter based forwarding, policy based routing, etc.) via single outgoing VRF (VRF-out)<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">6. "As the locator part of the VPN-specific SID is routable within the SRv6 domain other PE and P nodes of the SRv6 domain can send/route packets to it." -> this is not necessarily true in multi-domain designs, with B-SID expansion at domain boundaries.<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">7. "It can hide the SIDs used inside the SRv6 domain and can provide different visibility for served VPNs if needed." -> Not sure, if I understand this statement<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Cheers,<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Krzysztof<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><br> <br> <o:p></o:p></div> <blockquote style="margin-top: 5pt; margin-bottom: 5pt;"> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">On 2026 Mar 18, at 22:30, Mustapha Aissaoui (Nokia) <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:<o:p></o:p></div> </div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> <div> <div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Hi Balazs,<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">I have a couple of comments on this draft. <o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">The first one is to reference<span class="Apple-converted-space"> </span><a href="https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2473*section-8__;Iw!!NEt6yMaO-gk!CQq_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79hihx0kcrkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$" style="color: blue; text-decoration: underline;" moz-do-not-send="true">RFC 2473</a> as it is well described that an ICMP reply must be sent on the outer IPv6 header in the case of an IP-in-IP tunnel. For me this is the closest prior art we can refer to when discussing potential new solutions, other than ICMP tunneling. <o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">This RFC also describes a general ICMP relay function covering various ICMP error messages. In the specific context of a TCP/UDP traceroute probe, this relay function will only work for traceroute packets of routes in the global routing table as discussed in an earlier thread on draft-ali-6man-srv6-vpn-icmp-error-handling. It does however not address probes sent in VRF context.<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">The second is regarding the use of a SRv6 service SID as the source address on the outer IPv6 header. The source address in the outer IPv6 header is used by downstream routers to report various ICMP error messages on the SRv6 tunnel, some of which are ad-hoc and triggered by malformed outer headers in user packets. Hence it cannot be sent to a specific VRF context of the ingress SRv6 PE. <o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">I can see a service SID being used as the source address of the traceroute for probes originating at the ingress SRv6 PE since the user can configure this specifically for these probes. But not for probes generated by the CE since they are treated as user packets at the ingress SRv6 PE and they would inherit the source address of the SRv6 tunnel. For probes originating at the ingress SRv6 PE, one can correlate the error message with a specific VPN or global routing table traceroute probe based on TCP or UDP port number. So there are alternatives too.<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Regards,<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Mustapha.<o:p></o:p></div> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div> </div> <div id="mail-editor-reference-message-container"> <div style="border-width: 1pt medium medium; border-style: solid none none; border-image: none; padding: 3pt 0in 0in; border-color: currentcolor;"> <p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 12pt; font-family: Aptos, sans-serif;"><b>From:<span class="Apple-converted-space"> </span></b>Balázs Varga A <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>><br> <b>Date:<span class="Apple-converted-space"> </span></b>Monday, March 16, 2026 at 9:51<span style="font-family: Arial, sans-serif;"> </span>AM<br> <b>To:<span class="Apple-converted-space"> </span></b>SPRING WG List <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>>, IPv6 List <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>><br> <b>Subject:<span class="Apple-converted-space"> </span></b>[spring] FW: New Version Notification for draft-varhal-6man-icmp-srv6-vpn-01.txt<o:p></o:p></p> </div> <div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><br> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL<span class="Apple-converted-space"> </span><a href="http://nok.it/ext" style="color: blue; text-decoration: underline;" moz-do-not-send="true">nok.it/ext</a><span class="Apple-converted-space"> </span>for additional information.<br> <br> <br> <br> Hi,<br> <br> Based on the valuable feedbacks on the lists the draft on<br> "ICMP Error Handling for VPNs in SRv6 Networks" was<br> updated.<br> <br> Thanks & Cheers<br> Bala'zs (and Joel)<br> <br> -----Original Message-----<br> From:<span class="Apple-converted-space"> </span><a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><span class="Apple-converted-space"> </span><<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>><br> Sent: Monday, March 16, 2026 2:36 PM<br> To: Balázs Varga A <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>>; Joel Halpern <<a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>><br> Subject: New Version Notification for draft-varhal-6man-icmp-srv6-vpn-01.txt<br> <br> A new version of Internet-Draft draft-varhal-6man-icmp-srv6-vpn-01.txt has been successfully submitted by Balazs Varga and posted to the IETF repository.<br> <br> Name: draft-varhal-6man-icmp-srv6-vpn<br> Revision: 01<br> Title: ICMP Error Handling for VPNs in SRv6 Networks<br> Date: 2026-03-16<br> Group: Individual Submission<br> Pages: 12<br> URL: <span class="Apple-converted-space"> </span><a href="https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-01.txt" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ietf.org/archive/id/draft-varhal-6man-icmp-srv6-vpn-01.txt</a><br> Status: <span class="Apple-converted-space"> </span><a href="https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-vpn/" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/draft-varhal-6man-icmp-srv6-vpn/</a><br> HTMLized:<span class="Apple-converted-space"> </span><a href="https://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-vpn" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/html/draft-varhal-6man-icmp-srv6-vpn</a><br> Diff: <span class="Apple-converted-space"> </span><a href="https://author-tools.ietf.org/iddiff?url2=draft-varhal-6man-icmp-srv6-vpn-01" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">https://author-tools.ietf.org/iddiff?url2=draft-varhal-6man-icmp-srv6-vpn-01</a><br> <br> Abstract:<br> <br> This document specifies ICMP error handling in SRv6-based Virtual<br> Private Networks, that support direct localization of failures. It<br> provides a solution for connectivity check and fault localization<br> without adding complexity to P nodes and keeps P nodes service<br> agnostic. ICMP processing is changed only on ingress PE nodes and<br> gains from adding VPN-specific information to the SRv6 encapsulated<br> packet. Egress PE nodes are not involved in the forwarding of the<br> ICMP error messages. Therefore, the solution provides visibility<br> upto the failure even if ingress PE to egress PE connectivity is<br> broken within the SR domain.<br> <br> <br> <br> The IETF Secretariat<br> <br> <br> _______________________________________________<br> spring mailing list --<span class="Apple-converted-space"> </span><a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><br> To unsubscribe send an email to<span class="Apple-converted-space"> </span><a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><o:p></o:p></span></div> </div> </div> </div> <div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">_______________________________________________<br> spring mailing list --<span class="Apple-converted-space"> </span><a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><br> To unsubscribe send an email to<span class="Apple-converted-space"> </span><a href="mailto:[email protected]" style="color: blue; text-decoration: underline;" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a></div> </div> </blockquote> </div> </div> </blockquote> </div> <br> </div> <br> <fieldset class="moz-mime-attachment-header"></fieldset> <pre wrap="" class="moz-quote-pre">-------------------------------------------------------------------- IETF IPv6 working group mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> List Info: <a class="moz-txt-link-freetext" href="https://mailman3.ietf.org/mailman3/lists/[email protected]/">https://mailman3.ietf.org/mailman3/lists/[email protected]/</a> -------------------------------------------------------------------- </pre> </blockquote> </body> </html> --------------E9o2zsLGK0kVXEj3AHrnU4iO-- --===============1369486889570811502== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============1369486889570811502==--