Hi Sasha and Jie,
As for the document type (standard track or informational), my personal
opinion is that if we need to assign a new IANA code-point on this new
SR resource semantics at another draft, this document will be Standards
Track (as an example, a new IS-IS sub-TLVs (RFC8667) for the
Sander,
On 26/05/2020, 21:48, "Sander Steffann" wrote:
Hi,
> WH> what you are saying I only want a CRH solution and you are not open
to anything else, because the SIDs are not in the right place.
No, that is not what I said. Please stop twisting my words. I want to steer
a packe
Pablo, et al,
Your draft assumes that UE to gNB is with the SRv6 instead of 3GPP's GTP? If
you can't convince 3GPP to replace their GTP, what kind of scenarios will
deploy SRv6 from UE -gNB-UPF?
In Section 3.1.3, you stated that SRv6 offers Load balancing among VNFs, does
it require the head n
Robert,
On May 26, 2020, at 5:17 PM, Robert Raszuk
mailto:rob...@raszuk.net>> wrote:
- In what context have we spent so many emails discussing "escaping packets to
the Internet" or protecting infrastructure (SID addresses from "entering your
network from Internet" ?
The difference is between
Hi John,
That is indeed an interesting point. Honestly in all of my personal and
business interests I want to use any of those technologies (of course with
RbR preference) for engineering SDWANs. So clearly Internet transit
applies.
But then I have just one question:
- In what context have we sp
Jim,
I don’t disagree with your statement that some of my views are subjective.
They are however the subjective views of an operator when the question was
asked do we want CRH.
The answer remains yes – because agree with my views or disagree with them – it
is the perceptions that I have that
On May 26, 2020, at 3:52 PM, Sander Steffann
mailto:san...@steffann.nl>> wrote:
Source and destination are in the same domain. Who says that the domain is
contiguous? Let's change the example to main and branch offices. Same
administrative domain, while still traversing the internet.
This is a
Hi!
Someone just reminded me of my age… I am of the generation of simple Lego
blocks, and still prefer the classical plain bricks to the modern ones where
they create special bricks just for one or two models. I guess that preference
also applies to my preferences in protocol design :)
Cheers!
On Tue, May 26, 2020 at 10:27 AM James Guichard
wrote:
>
> Hi Andrew,
>
>
>
> Some of your comments about SRv6 are a little subjective.
>
>
>
> You say SRv6 is complex and yet in its basic form it is simply a list of IPv6
> addresses carried in a routing header which does not seem too difficult t
Hi,
> draft says:
>
> Is designed to operate within a network domain.
Source and destination are in the same domain. Who says that the domain is
contiguous? Let's change the example to main and branch offices. Same
administrative domain, while still traversing the internet.
Cheers,
Sander
_
Hi,
> WH> what you are saying I only want a CRH solution and you are not open to
> anything else, because the SIDs are not in the right place.
No, that is not what I said. Please stop twisting my words. I want to steer a
packet without needing to encapsulate it. Why is that so hard to understan
Hi Sander,
Ok your use case is indeed original and valid. No encapsulation at all.
Just plain end to end IPv6 header. Cool so far.
If so honestly for your use case I must observe that SRv6 with basic 128
bit SIDs is much easier to use.
Any scheme which requires mapping really works well in a lim
Sander,
On 26/05/2020, 21:17, "Sander Steffann" wrote:
Hi Wim,
> WH> We are either all encapsulating or not, but in essence the point is
that the difference is you put the sids in the extension header versus next
header. Lets leave it like this. All in all what I am saying is RFC8663
Hi Wim,
> WH> We are either all encapsulating or not, but in essence the point is that
> the difference is you put the sids in the extension header versus next
> header. Lets leave it like this. All in all what I am saying is RFC8663
> allows you to do what you intend with CRH.
No, I can't. Yo
Sander,
On 26/05/2020, 19:40, "Sander Steffann" wrote:
Hi Wim,
> Wh> Nothing is put in the payload when using RFC8663. The SID list is put
in a next header field as per RFC 4023, whereas in CRH you put them in an EH,
but the payload is intact. I have not done the exact calculation on
Hi Wim,
> Wh> Nothing is put in the payload when using RFC8663. The SID list is put in
> a next header field as per RFC 4023, whereas in CRH you put them in an EH,
> but the payload is intact. I have not done the exact calculation on the wire,
> but they are almost the same in size wrt overhead
Sander,
On 26/05/2020, 19:20, "Sander Steffann" wrote:
Hi Wim,
> WH> Why would it matter if I add the sids in an Extension Header, versus
through a Next header. As long as we achieve the same goal why would you care?
I don't understand what you mean. If you're talking about enca
Hi Andrew,
Some of your comments about SRv6 are a little subjective.
1. You say SRv6 is complex and yet in its basic form it is simply a list of
IPv6 addresses carried in a routing header which does not seem too difficult to
understand especially in light of the fact that with CRH I have es
Hi Wim,
> WH> Why would it matter if I add the sids in an Extension Header, versus
> through a Next header. As long as we achieve the same goal why would you
> care?
I don't understand what you mean. If you're talking about encapsulation, I care
because of the overhead. If you're talking abou
Sander, inline
On 26/05/2020, 19:03, "Sander Steffann" wrote:
Hi Wim,
> WH> Sander RFC8663 is supported in linux and various implementations.
You can do the encap in the same way as you have done with CRH w/o a router
doing the encap.
You misunderstand. I don't want any encap
Hi Wim,
> WH> Sander RFC8663 is supported in linux and various implementations. You
> can do the encap in the same way as you have done with CRH w/o a router doing
> the encap.
You misunderstand. I don't want any encap overhead, I just want IPv6 packets...
Cheers,
Sander
__
On 26/05/2020, 18:11, "Sander Steffann" wrote:
Hi Wim,
> WH> in the same way as you get CRH across the Internet. It is a tag
encapsulated in an IPV6 header. It uses ipv6 encap based on RFC4023.
That assumes that there is always a router that adds an encap to an
existing packet.
Hi Wim,
> WH> in the same way as you get CRH across the Internet. It is a tag
> encapsulated in an IPV6 header. It uses ipv6 encap based on RFC4023.
That assumes that there is always a router that adds an encap to an existing
packet. I want to look beyond that and allow for end nodes participat
On 26/05/2020, 16:46, "Sander Steffann" wrote:
Hi Wim,
> It does work across domains that are not directly connected, but that
scenario is not well described I have to admit. The operation is as I said very
similar to CRH.
> Think of the MPLS tag as the same as the SID tag in C
Hi Wim,
> It does work across domains that are not directly connected, but that
> scenario is not well described I have to admit. The operation is as I said
> very similar to CRH.
> Think of the MPLS tag as the same as the SID tag in CRH. From a data-plane
> all packets on the wire will use v
It does work across domains that are not directly connected, but that scenario
is not well described I have to admit. The operation is as I said very similar
to CRH.
Think of the MPLS tag as the same as the SID tag in CRH. From a data-plane all
packets on the wire will use v6 addresses, so inte
Hi Wim,
> I agree that if you look into the details RFC8663 from a data-plane operation
> is very similar to CRH. It uses a tag and derives a destination ipv6 address
> from it.
> On top it if you look at the requirements, the following is possible with
> RFC8663
>
> • It can steer the p
I agree that if you look into the details RFC8663 from a data-plane operation
is very similar to CRH. It uses a tag and derives a destination ipv6 address
from it.
On top it if you look at the requirements, the following is possible with
RFC8663
* It can steer the packet through a specific
Hi Ron,
Thanks for your reply. I think I asked a wrong question, so I change the title
to be "How SRm6 supports SFC/Segment Endpoint option?"
In Segment endpoint option draft[1], you define PSSI for supporting limited
Service Chain.
PSSI: Per-Segment Service Instructions, the text is shown belo
Speaking as an operator that operates in 15 countries – yes – yes and yes again.
SRv6 will never find a home on our network – it is complex, it has massive
overhead, it overloads the address space in ways that make me cringe, it
currently (in my view) violates RFC8200, the network programming dr
Hi,
> Take a step back, assume SRm6 is also adopted, there will be two solutions
> for the community to choose; there will be interop issues between the two
> solutions. The vendors will have to support both to make different customers
> happy, more money will be spent and will be finally payed
Hi,
If you follow the discussions of the past several months, you should know that
CRH is the foundation of SRm6. In my understanding, SRm6 is another IPv6 based
Segment Routing, it was originally motivated to address the SRH header compress
issue.
Technically, SRm6 works (it has the same conce
Hi Weibin,
Thanks for your comment.
Yes SR aims to reduce the amount of state maintained inside the network, one
approach is to keep the path information only at the edge nodes. The mechanism
described in this draft aligns with this approach, there is still no per-path
state on the P nodes. Th
Hi Jie and Sasha,
Thanks for the discussion to make my point more accurate! ☺
Currently, a SID can be associated to an adjacency, a Prefix, a Service, a
topology/algorithm, my understanding of this draft is that it introduces a new
function/semantic to associate a SID to a specific resource. IM
Hi,
It appears that some may have misunderstood the SRv6 solution and invented CRH.
It is good to clarify these points.
SRv6 offers the possibility to combine underlay and overlay instructions in a
single SRH.
However,
* This is entirely optional
* If one would like to spread the source
35 matches
Mail list logo
