Re: [spring] SR-MPLS over IPv6？
Stewart Bryant <stewart.bryant@gmail.com> Thu, 26 September 2019 14:06 UTC
Return-Path: <stewart.bryant@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5BB120043 for <spring@ietfa.amsl.com>; Thu, 26 Sep 2019 07:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6gi9S2v8wkP for <spring@ietfa.amsl.com>; Thu, 26 Sep 2019 07:06:14 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D28F12002F for <spring@ietf.org>; Thu, 26 Sep 2019 07:06:14 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id q17so2633105wrx.10 for <spring@ietf.org>; Thu, 26 Sep 2019 07:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=1EJ/pxywTzVL0lT/bxultjQb9Td10kBf7DY6jefyGdA=; b=crK5V+Wchz5oDblc/3pSEaYqJwCA3oviZtARxzt4EMshJMlU2XddKYL2zq96K0dN/u F14yPljB5pEPHaktBot4AEuU4Dgg7ocIw/qQlUI187bfPyspaRIwPKGWDJyBlPgnSsxb 0nxKjVs3bGDlGUX04ZuDJHXgqNTjwcD+8SPyHF7dQsbq/Uo4yQhvhnQcjrBlF/wt3xcE agIYpqcW8X3HhaInAH26nPx9gjNKZ/reNpKQ7lW17IPaN2tugzSQ1cn6ciajv+rlqfam sR57mKTgd+WcfSejOvCBxysK5ZUPtrdkaAU1uD4H3QYXFGADLDYTNlf+2e9eC1kwVyST Ngcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1EJ/pxywTzVL0lT/bxultjQb9Td10kBf7DY6jefyGdA=; b=rE8jRtsng61y+cH0+cfFdAbQvpjLDwFkeJF7lScut3MLkpyVxrjTue7egOYDZSVyfz v/Oa12MvlJclycwiJg2MebHdWUkMPpG20p6R/rFQr8I355J4MY6iCDptz7wONzuFCv/x fZQA7sG6Yg+9x92fhvpLtfYwVtTMem2u+OZVJR4LUiuNwNb81ONYDUGkh2OTpAehX//T cwOopMu+gzqH9A6EdbNNRx1Mdib62Mnt73Tx/z+K5eoXRaciWd62QSaMvrtq5mqR8y5H RkIedp4DkZaYIvaMNhDgww/9gZRhTg6D6sSYb0Rd8OcxwjWEjyLgOgxopjguMu6q7av1 xL4g==
X-Gm-Message-State: APjAAAUcw4kQ15Kxc3GYgIz+OC2+/WgO5TRrtPdyn8gOF8bqlb+Ocswt JdU4kAQP25r9lQjtUQdqctcnyaCVJmw=
X-Google-Smtp-Source: APXvYqztjFOaf1uC/unfywELf5TusLMBLNwXqC/0KEQzT2jOviOxMkhI1j/5Enjr3NXii24X8/aCgw==
X-Received: by 2002:a05:6000:108e:: with SMTP id y14mr3109503wrw.344.1569506772201; Thu, 26 Sep 2019 07:06:12 -0700 (PDT)
Received: from Appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id y186sm6927039wmb.41.2019.09.26.07.06.10 for <spring@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Sep 2019 07:06:11 -0700 (PDT)
To: spring@ietf.org
References: <C7C2E1C43D652C4E9E49FE7517C236CB02700FC1@dggeml529-mbx.china.huawei.com> <BN7PR05MB56994D4335D5ECCC9FE591A8AE840@BN7PR05MB5699.namprd05.prod.outlook.com> <3b7e474d-7462-4bc5-310c-6489516a0b1a@gmail.com> <d00cbf3d-823b-41e3-8759-21e50058a7eb@Spark> <4BB0E927-025D-4497-9DD1-0307FCBAFB97@bell.ca> <f16a4119-dde9-832b-0fa1-ad8ebef71314@joelhalpern.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <72130776-7a98-114f-98cc-5776ce97c096@gmail.com>
Date: Thu, 26 Sep 2019 15:06:09 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <f16a4119-dde9-832b-0fa1-ad8ebef71314@joelhalpern.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/yJuqxlNHDjZpMeN3qrUEs12b_I8>
Subject: Re: [spring] SR-MPLS over IPv6？
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 14:06:18 -0000
The thing that pushes the original SR design into statefulness is binding SIDs which require state to be pre-positioned in the network. - Stewart On 25/09/2019 20:50, Joel M. Halpern wrote: > SR is Stateless in the sense of not having per-path state. It is not > stateless in a general sense, since otherwise MPLS-SR would not be SR > (it needs label state). So I think we are reading 8402 differently. > > We can let the marketing folks fight it out in the marketplace. > > Yours, > Joel > > On 9/25/2019 3:41 PM, Bernier, Daniel wrote: >> Hi Ron, >> >> Similarly I would refrain from using the SR acronym since a key >> characteristic of the SR architecture as per RFC8402 is statelessness. >> >> As per current SRv6+ documents, state is required for an intermediate >> node to add the relevant next PSSIs in DOH. This is whether they are >> domain-wide defined or with local significance (i.e. prepending >> short-SID). >> >> Cheers, >> >> Dan B >> >> On 2019-09-25, 8:43 AM, "Jeff Tantsura" <jefftant.ietf@gmail.com >> <mailto:jefftant.ietf@gmail.com>> wrote: >> >> Agree with Stuart. >> >> SRinUDP is a well defined solution, let’s not mix things. >> >> Cheers, >> >> Jeff >> >> On Sep 25, 2019, 2:39 PM +0200, Stewart Bryant >> <stewart.bryant@gmail.com>, wrote: >> >> I agree. >> >> Inclusion of the term MPLS would cause confusion with >> draft-ietf-mpls-sr-over-ip, which is entitled SR-MPLS over IP. The >> design decribed in draft-ietf-mpls-sr-over-ip works over both IPv4 >> and IPv6. Also course, as Ron states, such a name is not a true >> refelction of the design. >> >> - Stewart >> >> On 24/09/2019 05:01, Ron Bonica wrote: >> >> Cheng, >> >> I have no problem with changing the name. SR-MPLS over IPv6 may >> not be appropriate, because MPLS is not part of the solution. >> >> Something like SR-extensible-6 or SR-compressed-6 might work. >> >> Ron >> >> Juniper Business Use Only >> >> *From:* Chengli (Cheng Li) <chengli13@huawei.com> >> <mailto:chengli13@huawei.com> >> *Sent:* Monday, September 23, 2019 10:14 PM >> *To:* Ron Bonica <rbonica@juniper.net> >> <mailto:rbonica@juniper.net>; Jeff Tantsura >> <jefftant.ietf@gmail.com> <mailto:jefftant.ietf@gmail.com> >> *Cc:* SING Team <s.i.n.g.team.0810@gmail.com> >> <mailto:s.i.n.g.team.0810@gmail.com>; EXT - >> daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca> >> <daniel.bernier@bell.ca> <mailto:daniel.bernier@bell.ca>; SPRING >> WG List <spring@ietf.org> <mailto:spring@ietf.org> >> *Subject:* RE: [spring] SR-MPLS over IPv6？ >> >> Oh, I misunderstood the BSID in CRH in last email, sorry for >> that. >> >> Yes, the SID is not an IPv6 address in CRH, but a 16/32 bit >> value like MPLS label. >> >> Therefore, IMHO, it may not comply with RFC8402: >> https://tools.ietf.org/html/rfc8402#section-3.1.3 >> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402*section-3.1.3__;Iw!8WoA6RjC81c!WoPYW9IpnDYjcdhli0b80_-KyrOIBYFAZfip_NxPLB1-Bt7oHjt8uGU68K49j2yk$> >> >> If possible, I suggest to change the name of SRv6+, since it is >> not SRv6 based. Something like SR-MPLS over IPv6 maybe better? >> >> Thanks, >> >> Cheng >> >> *From:* Ron Bonica [mailto:rbonica@juniper.net] >> *Sent:* Monday, September 23, 2019 10:45 PM >> *To:* Chengli (Cheng Li) <chengli13@huawei.com >> <mailto:chengli13@huawei.com>>; Jeff Tantsura >> <jefftant.ietf@gmail.com <mailto:jefftant.ietf@gmail.com>> >> *Cc:* SING Team <s.i..n.g.team.0810@gmail.com >> <mailto:s.i.n.g.team.0810@gmail.com>>; EXT - >> daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca> >> <daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca>>; SPRING >> WG List <spring@ietf.org <mailto:spring@ietf.org>> >> *Subject:* RE: [spring] A note on CRH and on going testing >> >> Cheng, >> >> In SRv6+, it would be very difficult to pollute the architecture >> because: >> >> -A SID is either 16-or 32-bits long >> >> -An IPv6 address is 128-bits long >> >> -Therefore, it is impossible to copy a SID to an IPv6 address or >> an IPv6 address to a SID >> >> The binding SID will be a 16-or 32-bit topological instruction, >> found in the CRH. Like all topological instructions, it will >> identify an SFIB entry. >> >> There will be a new SFIB entry type that will contain the >> following information: >> >> -An IPv6 Destination Address (to be used in the outer IPv6 >> header) >> >> -A list of SIDs (to be used in the CRH >> >> Ron >> >> Juniper Business Use Only >> >> *From:* Chengli (Cheng Li) <chengli13@huawei.com >> <mailto:chengli13@huawei.com>> >> *Sent:* Sunday, September 22, 2019 12:01 AM >> *To:* Ron Bonica <rbonica@juniper.net >> <mailto:rbonica@juniper.net>>; Jeff Tantsura >> <jefftant.ietf@gmail.com <mailto:jefftant.ietf@gmail.com>> >> *Cc:* SING Team <s.i..n.g.team.0810@gmail.com >> <mailto:s.i.n.g.team.0810@gmail.com>>; EXT - >> daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca> >> <daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca>>; SPRING >> WG List <spring@ietf.org <mailto:spring@ietf.org>> >> *Subject:* RE: [spring] A note on CRH and on going testing >> >> Hi Ron, >> >> Good to hear that. Looking forward to seeing it in the next >> revision. >> >> But I am curious that is a bind SID in CRH an interface IPv6 >> address only without any other semantics? Just like the other >> SIDs you mentioned in CRH. >> >> If not, this binding SID should not be introduced in to CRH >> since it pollutes the architecture. >> >> If yes, what’s the standard for an Interface IPv6 address? >> >> Thanks for confirming that BSID is needed in CRH. I totally >> agree with you. >> >> Best regards, >> Cheng >> >> ------------------------------------------------------------------------ >> >> 李呈Cheng Li >> Email: chengli13@huawei.com <mailto:chengli13@huawei.com> >> >> *From:* Ron Bonica<rbonica@juniper.net >> <mailto:rbonica@juniper.net>> >> >> *To:* Jeff Tantsura<jefftant.ietf@gmail.com >> <mailto:jefftant.ietf@gmail.com>>;Chengli (Cheng >> Li)<chengli13@huawei.com <mailto:chengli13@huawei.com>> >> >> *Cc:* SING Team<s.i.n.g.team.0810@gmail.com >> <mailto:s.i.n.g.team.0810@gmail.com>>;EXT - >> daniel.bernier<daniel.bernier@bell.ca >> <mailto:daniel.bernier@bell.ca>>;SPRING WG List<spring@ietf.org >> <mailto:spring@ietf.org>> >> >> *Subject:* RE: [spring] A note on CRH and on going testing >> >> *Time:* 2019-09-22 04:37:17 >> >> Jeff, >> >> After an off-line conversation with the SRv6+ implementors, we >> decided that it would be trivial to add a binding SID to SRv6+. >> So, we will do that in the next version of the draft. >> >> In keeping with RFC 8200, it will prepend only. Since the CRH is >> short, insertion is not needed. >> >> Ron >> >> Juniper Business Use Only >> >> *From:* Jeff Tantsura <jefftant.ietf@gmail.com >> <mailto:jefftant.ietf@gmail.com>> >> *Sent:* Saturday, September 21, 2019 4:32 PM >> *To:* Chengli (Cheng Li) <chengli13@huawei.com >> <mailto:chengli13@huawei.com>>; Ron Bonica <rbonica@juniper.net >> <mailto:rbonica@juniper.net>> >> *Cc:* SING Team <s.i..n.g.team.0810@gmail.com >> <mailto:s.i.n.g.team.0810@gmail.com>>; EXT - >> daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca> >> <daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca>>; SPRING >> WG List <spring@ietf.org <mailto:spring@ietf.org>> >> *Subject:* RE: [spring] A note on CRH and on going testing >> >> Hi Ron, >> >> Thanks for your comments, exactly, BSID MPLS label = CRH >> value :) >> >> Cheers, >> >> Jeff >> >> On Sep 20, 2019, 11:09 AM -0700, Ron Bonica <rbonica@juniper.net >> <mailto:rbonica@juniper.net>>, wrote: >> >> Hi Jeff, >> >> It would be easy enough to add a binding SID to SRv6+. Given >> customer demand, I would not be averse to adding one. >> >> However, there is another way to get exactly the same >> behavior on the forwarding plane without adding a new SID >> type. >> >> Assume that on Node N, we have the following SFIB entry: >> >> ·SID: 123 >> >> ·IPv6 address: 2001:db8::1 >> >> ·SID type: prefix SID >> >> Now assume that was also have the following route on Node N: >> >> 2001:db8::1 -> SRv6+ tunnel with specified destination >> address and CRH >> >> This gives you the same forwarding behavior as a binding >> SID. >> >> Ron >> >> Juniper Business Use Only >> >> *From:* spring <spring-bounces@ietf.org >> <mailto:spring-bounces@ietf.org>> *On Behalf Of* Jeff >> Tantsura >> *Sent:* Thursday, September 19, 2019 10:53 PM >> *To:* Chengli (Cheng Li) <chengli13@huawei.com >> <mailto:chengli13@huawei.com>> >> *Cc:* SING Team <s.i..n.g.team.0810@gmail.com >> <mailto:s.i.n.g.team.0810@gmail.com>>; EXT - >> daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca> >> <daniel.bernier@bell.ca <mailto:daniel.bernier@bell.ca>>; >> SPRING WG List <spring@ietf.org <mailto:spring@ietf.org>> >> *Subject:* Re: [spring] A note on CRH and on going testing >> >> There’s number of solutions on the market that extensively >> use BSID for multi-domain as well as multi-layer signaling. >> >> Regards, >> >> Jeff >> >> >> On Sep 19, 2019, at 19:49, Chengli (Cheng Li) >> <chengli13@huawei.com <mailto:chengli13@huawei.com>> wrote: >> >> +1. >> >> As I mentioned before, Binding SID is not only for >> shortening SID list. >> >> We should see the important part of binding SID in >> inter-domain routing, since it hides the details of >> intra-domain. Security and Privacy are always important. >> >> Since the EH insertion related text will be removed from >> SRv6 NP draft, I don’t think anyone will still say we >> don’t need binding SID. >> >> Let’s be honest, Encap mode Binding SID is very useful >> in inter-domain routing. It is not secure to share >> internal info outside a trusted network domain. >> >> Cheng >> >> *From:* spring [mailto:spring-bounces@ietf.org] *On >> Behalf Of* Bernier, Daniel >> *Sent:* Thursday, September 19, 2019 11:36 PM >> *To:* SING Team <s.i..n.g.team.0810@gmail.com >> <mailto:s.i.n.g.team.0810@gmail.com>> >> *Cc:* 'SPRING WG List' <spring@ietf.org >> <mailto:spring@ietf.org>> >> *Subject:* Re: [spring] A note on CRH and on going >> testing >> >> +1 >> >> This is what we did on our multi-cloud trials. >> >> Encap with Binding SID to avoid inter-domain mapping + I >> don’t need to have some sort of inter-domain alignment >> of PSSIs >> >> Dan >> >> On 2019-09-19, 11:18 AM, "spring on behalf of SING Team" >> <spring-bounces@ietf.org >> <mailto:spring-bounces@ietf.org> on behalf of >> s.i.n.g.team.0810@gmail.com >> <mailto:s.i.n.g.team.0810@gmail.com>> wrote: >> >> Hi Andrew, >> >> Good to hear that reality experiment :) >> >> But is it secure to share internal SID-IP mappings >> outside a trusted network domain? >> >> Or is there an analogue like Binding SID of SRv6, in >> SRv6+? >> >> Btw, PSSI and PPSI can not do that now, right? >> >> Best regards, >> Moonlight Thoughts >> >> >> (mail failure, try to cc to spring again.) >> >> On 09/19/2019 17:49, Andrew Alston >> <mailto:Andrew.Alston@liquidtelecom.com> wrote: >> Hi Guys, >> >> I thought this may be of interest in light of >> discussions around deployments and running code - >> because one of the things we've been testing is >> inter-domain traffic steering with CRH on both our DPDK >> implementation and another implementation. >> >> So - the setup we used last night: >> >> 6 systems in a lab - one of which linked to the open >> internet. Call these S1 -> S6 >> 3 systems in a lab on the other side of the world - no >> peering between the networks in question. Call these R1 >> -> R3 >> >> We applied a SID list on S1, that steered S1 -> S2 -> S3 >> -> S6 -> R1 -> R3, with the relevant mappings from the >> CRH SID's to the underlying addressing (S2 had a mapping >> for the SID for S3, S3 had a mapping for the SID >> corresponding to S6, S6 had a mapping for the SID >> corresponding to R1 etc) >> >> Then we sent some packets - and the test was entirely >> successful. >> >> What this effectively means is that if two providers >> agree to share the SID mappings - it is possible to >> steer across one network, out over an open path, and >> across a remote network. Obviously this relies on the >> fact that EH's aren't being dropped by intermediate >> providers, but this isn't something we're seeing. >> >> Combine this with the BGP signaling draft - and the >> SID's can then be signaled between the providers - work >> still going on with regards to this for testing >> purposes. Just as a note - there would be no >> requirement to share the full SID mapping or topologies >> when doing this with BGP - the requirement would be only >> to share the relevant SID's necessary for the steering. >> >> I can say from our side - with various other providers - >> this is something that we see *immense* use case for - >> for a whole host of reasons. >> >> Thanks >> >> Andrew >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf..org <mailto:spring@ietf.org> >> https://www.ietf.org/mailman/listinfo/Spring >> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/Spring__;!8WoA6RjC81c!U4_s7somKP_KyQ3viBMIcXpk_pTMYlY11nTHMB2b-JTdTLKi9mnrF1wu_DoXwIdf$> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org <mailto:spring@ietf.org> >> https://www.ietf.org/mailman/listinfo/spring >> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!U4_s7somKP_KyQ3viBMIcXpk_pTMYlY11nTHMB2b-JTdTLKi9mnrF1wu_Ll7ej5P$> >> >> >> >> _______________________________________________ >> >> spring mailing list >> >> spring@ietf.org <mailto:spring@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/spring >> >> ------------------------------------------------------------------------ >> >> */External Email:/*/Please use caution when opening links and >> attachments / /*/Courriel externe:/*/Soyez prudent avec les liens et >> documents joints / >> >> >> _______________________________________________ >> 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
- Re: [spring] SR-MPLS over IPv6？ Chengli (Cheng Li)
- Re: [spring] SR-MPLS over IPv6？ Ron Bonica
- Re: [spring] SR-MPLS over IPv6？ Stewart Bryant
- Re: [spring] SR-MPLS over IPv6？ Jeff Tantsura
- Re: [spring] SR-MPLS over IPv6？ Bernier, Daniel
- Re: [spring] SR-MPLS over IPv6？ Joel M. Halpern
- Re: [spring] SR-MPLS over IPv6？ Bernier, Daniel
- Re: [spring] SR-MPLS over IPv6？ Ron Bonica
- Re: [spring] SR-MPLS over IPv6？ Ron Bonica
- Re: [spring] SR-MPLS over IPv6？ Bernier, Daniel
- Re: [spring] SR-MPLS over IPv6？ Joel M. Halpern
- Re: [spring] SR-MPLS over IPv6？ Stewart Bryant
- Re: [spring] SR-MPLS over IPv6？ Stewart Bryant
- Re: [spring] SR-MPLS over IPv6？ Ron Bonica
- Re: [spring] SR-MPLS over IPv6？ Zafar Ali (zali)
- Re: [spring] SR-MPLS over IPv6？ Ron Bonica
- Re: [spring] SR-MPLS over IPv6？ Zafar Ali (zali)
- Re: [spring] SR-MPLS over IPv6？ Mark Smith
- Re: [spring] SR-MPLS over IPv6？ Ron Bonica
- Re: [spring] SR-MPLS over IPv6？ Robert Raszuk
- Re: [spring] SR-MPLS over IPv6？ Ron Bonica
- Re: [spring] SR-MPLS over IPv6？ Ron Bonica
- Re: [spring] SR-MPLS over IPv6？ Robert Raszuk
- Re: [spring] SR-MPLS over IPv6？ Ron Bonica