Zafar,
I’m sorry. I didn’t realize that you are not a native speaker. Your English is
excellent!
Let’s just call it an unfortunate acronym and move on.
Ron
Juniper Business Use Only
From: Zafar Ali (zali) <z...@cisco.com>
Sent: Thursday, September 26, 2019 7:13 PM
To: Ron Bonica <rbon...@juniper.net>; EXT - daniel.bern...@bell.ca
<daniel.bern...@bell.ca>; Jeff Tantsura <jefftant.i...@gmail.com>; Chengli
(Cheng Li) <chengl...@huawei.com>; Stewart Bryant <stewart.bry...@gmail.com>
Cc: SPRING WG List <spring@ietf.org>; SING Team <s.i.n.g.team.0...@gmail.com>;
Zafar Ali (zali) <z...@cisco.com>
Subject: Re: [spring] SR-MPLS over IPv6？
Hi Ron,
“limp” is indeed humorous interpretation! I can see why you would not want to
take seriously!
I do confess that I’m not a native English speaker.
I intended it to be pronounced “/limf/” as in the “lymphatic system” due to the
distribution of state to nodes in the system.
Thanks
Regards … Zafar
From: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>
Date: Thursday, September 26, 2019 at 2:58 PM
To: "Zafar Ali (zali)" <z...@cisco.com<mailto:z...@cisco.com>>, "EXT -
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>"
<daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>>, Jeff Tantsura
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>, "Chengli (Cheng Li)"
<chengl...@huawei.com<mailto:chengl...@huawei.com>>, Stewart Bryant
<stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>
Cc: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>, SING Team
<s.i.n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>>
Subject: RE: [spring] SR-MPLS over IPv6？
Zafar,
This is a pretty obvious attempt to create backronymn (
https://en.wikipedia.org/wiki/Backronym<https://urldefense.com/v3/__https:/en.wikipedia.org/wiki/Backronym__;!8WoA6RjC81c!VJuk15hJagZWK817yojThqDx6BgYIzYzv-m3DbxSJVYBmP6I4xpk_4v3DT_WdzpX$>
) with negative connotations. So, I am not taking it seriously.
(For those who are not native speakers of English, the work “limp” carries
negative connotations in English.)
Ron
Juniper Business Use Only
From: Zafar Ali (zali) <z...@cisco.com<mailto:z...@cisco.com>>
Sent: Thursday, September 26, 2019 12:17 PM
To: EXT - daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>
<daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>>; Jeff Tantsura
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; Ron Bonica
<rbon...@juniper.net<mailto:rbon...@juniper.net>>; Chengli (Cheng Li)
<chengl...@huawei.com<mailto:chengl...@huawei.com>>; Stewart Bryant
<stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>
Cc: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; SING Team
<s.i.n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>>; Zafar Ali
(zali) <z...@cisco.com<mailto:z...@cisco.com>>
Subject: Re: [spring] SR-MPLS over IPv6？
Hi Ron,
I agree with Dan, Jeff and others that the name should NOT create confusion
with an already established technology (SR).
The name should reflect the design and the spirit of your proposal.
To try to help you differentiate your solution, may I propose
“LIMPH: Label Indirection with MultiPle Headers”
Here is the rationale:
* A new system of mapping IDs to IP addresses is being introduced (btw
we’ve had MPLS for doing that for ages now and so is this really something
different?)
* Then these mapped IDs are spread across multiple IPv6 extension headers
(introducing 2 new RHs and 2 new DOHs) thereby introducing more complexity in
IPv6 processing. We have simpler existing solutions
[draft-ietf-mpls-sr-over-ip] i.e. {IPv6 NH = UDP, 8 byte UDP header, stack of
mapping IDs aka MPLS labels}.
* As Dan mentioned, there is the PSSI for implementing “limited service
chaining” which seems very similar to RFC8595 and is stateful and “encodes a
logical representation” of an NSH albeit with a simpler encapsulation and
without TLVs just as in RFC8595.
Let’s your individual submissions not continue to cause confusion by making use
of a marketing name that drags on the coattails of SRv6 (which has been adopted
at the IETF and deployed by the industry).
Thanks
Regards … Zafar
From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on
behalf of "Bernier, Daniel"
<daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>>
Date: Wednesday, September 25, 2019 at 3:41 PM
To: Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>,
Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org<mailto:rbonica=40juniper....@dmarc.ietf.org>>,
"Chengli (Cheng Li)" <chengl...@huawei.com<mailto:chengl...@huawei.com>>,
Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>
Cc: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>, SING Team
<s.i.n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>>
Subject: Re: [spring] SR-MPLS over IPv6？
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.i...@gmail.com<mailto:jefftant.i...@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.bry...@gmail.com<mailto:stewart.bry...@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) <chengl...@huawei.com><mailto:chengl...@huawei.com>
Sent: Monday, September 23, 2019 10:14 PM
To: Ron Bonica <rbon...@juniper.net><mailto:rbon...@juniper.net>; Jeff Tantsura
<jefftant.i...@gmail.com><mailto:jefftant.i...@gmail.com>
Cc: SING Team
<s.i.n.g.team.0...@gmail.com><mailto:s.i.n.g.team.0...@gmail.com>; EXT -
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>
<daniel.bern...@bell.ca><mailto:daniel.bern...@bell.ca>; SPRING WG List
<spr...@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:rbon...@juniper.net]
Sent: Monday, September 23, 2019 10:45 PM
To: Chengli (Cheng Li) <chengl...@huawei.com<mailto:chengl...@huawei.com>>;
Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>
Cc: SING Team
<s.i..n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>
<daniel.bern...@bell.ca<mailto:daniel.bern...@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) <chengl...@huawei.com<mailto:chengl...@huawei.com>>
Sent: Sunday, September 22, 2019 12:01 AM
To: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>; Jeff Tantsura
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>
Cc: SING Team
<s.i..n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>
<daniel.bern...@bell.ca<mailto:daniel.bern...@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: chengl...@huawei.com<mailto:chengl...@huawei.com>
From: Ron Bonica<rbon...@juniper.net<mailto:rbon...@juniper.net>>
To: Jeff
Tantsura<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>;Chengli
(Cheng Li)<chengl...@huawei.com<mailto:chengl...@huawei.com>>
Cc: SING
Team<s.i.n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>>;EXT -
daniel.bernier<daniel.bern...@bell.ca<mailto:daniel.bern...@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.i...@gmail.com<mailto:jefftant.i...@gmail.com>>
Sent: Saturday, September 21, 2019 4:32 PM
To: Chengli (Cheng Li) <chengl...@huawei.com<mailto:chengl...@huawei.com>>; Ron
Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>
Cc: SING Team
<s.i..n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>
<daniel.bern...@bell.ca<mailto:daniel.bern...@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
<rbon...@juniper.net<mailto:rbon...@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-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On
Behalf Of Jeff Tantsura
Sent: Thursday, September 19, 2019 10:53 PM
To: Chengli (Cheng Li) <chengl...@huawei.com<mailto:chengl...@huawei.com>>
Cc: SING Team
<s.i..n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>
<daniel.bern...@bell.ca<mailto:daniel.bern...@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)
<chengl...@huawei.com<mailto:chengl...@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-boun...@ietf.org] On Behalf Of Bernier, Daniel
Sent: Thursday, September 19, 2019 11:36 PM
To: SING Team <s.i..n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@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-boun...@ietf.org<mailto:spring-boun...@ietf.org> on behalf of
s.i.n.g.team.0...@gmail..com<mailto:s.i.n.g.team.0...@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.als...@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
spr...@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<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!TfFPXN46U8X4Ofg8HjOZURz2vibZ7xX9VPHPZwePpNpFS4mFSlSluJs8p3X8mteY$>
________________________________
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
