Hi,
I noticed this bit of your message, and it made me think.
> With regards to your points about its all already developed – are you really
> telling me that because the authors chose to go and spend ages developing
> something while taking zero cognizance of the consensus in the community on
Hi Alex, Robert,
I agree fully.
From an IETF process viewpoint, Suresh recently cited his email on this topic:
https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc
“I just want to confirm that header insertion work can be considered in the
future, and that it should be judged
Robert,
You've chosen to selectively comment on only parts of what I wrote,
not the main thesis which is that SRV6 packet format is more complex
than SRV6+.
The most obvious difference, besides SID size, is that SRV6 contains
TLVs and SRV6+ doesn't. I don't believe that this was ever needed, HBH
Fernando,
>> The takeaway I attempted to highlight is that there is in fact agreement
>> between 6man and spring on how to proceed, and we are proceeding as
>> agreed to work on the relevant documents.
>
> I don't really know what the agreement is, other than the implicit
> agreement that if
On 7/9/19 15:53, Robert Raszuk wrote:
> Hi,
>
> why do you use IPv6 addresses (IDs of global scope) to
> identify the SR nodes?
>
>
> Well one valid reason would be to avoid need for yet another mapping
> table like LDP or SR-MPLS requires.
If you care about overhead, that's an area
Dear Tom,
> The most obvious difference, besides SID size, is that SRV6 contains
> TLVs and SRV6+ doesn't.
I was hoping you know that this is not true at all so I skipped commenting
on that aspect.
Folks promoting SRv6+ are smart and they know how to sell stuff which looks
simple and innocent
On 8/9/19 00:32, Ole Troan wrote:
> Fernando,
>
>>> The takeaway I attempted to highlight is that there is in fact
>>> agreement between 6man and spring on how to proceed, and we are
>>> proceeding as agreed to work on the relevant documents.
>>
>> I don't really know what the agreement is,
Ron,
> SRv6+ relies on prepending
Interesting ... can you elaborate how you will do TI-LFA with SRv6+ ? If
you have slides showing packet format when TI-LFA is performed in the
middle of SRv6+ domain please just kindly fell free to share a pointer to
it.
> I don’t understand your comment about
Hi,
> 4) I expect that, as co-chair, you'd agree with me that allowing EH
> insertion in IPv6 is a major modification/addition. According to our
> charter, we don't seem allowed to do that:
Do you need a new charter to be allowed to standardize extensions to IPv6
header and their operations
Robert,
You may need to rethink your argument. (That is, except for the part where you
said that I was smart!)
The SRv6+ PPSI does replaces something int SRv6. But it does not replace the
SRH's tags, flags or TLVs. It replaces the low order bits in the last SID..
More specially, it identifies
On 8/9/19 01:23, Robert Raszuk wrote:
[...]
>
> 4) I expect that, as co-chair, you'd agree with me that allowing EH
> insertion in IPv6 is a major modification/addition. According to our
> charter, we don't seem allowed to do that:
>
>
> Do you need a new charter to be allowed to
Robert,
I don't have slides, but it should be pretty easy to describe. Rather than
inserting a second Routing header between the IPv6 header and the existing
router, Arv6+ the following:
* Update SL and the IPv6 destination address, if required
* Prepend an IPv6 header with its own
Hey Ron,
You may need to rethink your argument. (That is, except for the part where
> you said that I was smart!)
>
;-)
> The SRv6+ PPSI does replaces something int SRv6. But it does not replace
> the SRH’s tags, flags or TLVs. It replaces the low order bits in the last
> SID. More specially,
With regard to service chaining, with either SRv6 or SRv6+, the
interoperable mechanism for service function chaining is to carry NSH.
Carrying the content of the NSH header in SRv6 SRH PDUs, while
technically doable, is complexity that is not needed.
Yours,
Joel
On 9/7/2019 6:54 PM, Robert
On Sat, 7 Sep 2019 at 19:56, Robert Raszuk wrote:
>
> > It's tempting to write up SR over IPv4
>
> You don't have to write anything ... it is already written and looks like
> moving fwd :)
>
> https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07
>
That's tunnelling MPLS over SR over IPv4.
Hi Ole,
> I don’t see a need to continue this debate on meta issues, but since you
> framed this as criticism of me in the chair role I found it required to reply.
Following up now that I had some rest :)
I consider you a friend, and I respect you a lot. Which is why the way you were
> It doesn't depend on extension header insertion
Nothing depends on extension header insertion ... SRH insertion is an
optional optimization.
> and there's no need to have multiple routing headers in the same packet.
Really ?
If I am doing SRv6+ in my network for TE and want to to do TI-LFA
1：If you mean actual global, then surely MPLS 20 bit labels would be
creating even more problems for SR?
this is why we must using sr over bgp lsp for a inter as path，we must using
two labels or more to express a e2e path。if you have a global id you need not
do this。and then，I think sid
On Sat, 7 Sep 2019, 15:18 Bernier, Daniel, wrote:
> Hi Fernando,
>
>
>
> Let’s say I have a native *IPv6 application flow* to which I want to
> apply a service policy (i.e. chain of functions), carry metadata through
> TLVs or perform a very simplistic filtering action via the tag field. All
>
Hi,
On Sat, 7 Sep 2019 at 18:08, Huzhibo wrote:
>
> Hi Mark:
> I don't think it's a good idea to implement SR with IPv4.
> 1: Sid must be globally unique within a large range to achieve unobstructed
> routing capabilities,
20 bit MPLS label values are not globally unique. Why is this not a
Hello, Ketan,
Inline...
On 7/9/19 08:14, Ketan Talaulikar (ketant) wrote:
> < An engineer comes out from the trenches/ >
>
> Hi Fernando,
>
> I will attempt to answer and but also setup the context first.
Thanks for elaborating, by the way.
> 4) This is not about the IPv6 Internet. All of
/* Adjusting the subject to reflect the topic */
Ok ... I looked at the new wave of mails in wrong order :)
I like this proposal:
https://tools.ietf.org/html/draft-herbert-ipv4-eh-01
And have absolutely nothing against progressing it further - it looks on
the surface to be more efficient then
On Sat, 7 Sep 2019 at 14:58, Huzhibo wrote:
>
> Hi Robert:
>
>
>
> Agree with you.
>
> SRv6 is a completely different technology from SR MPLS. The biggest
> difference is that SRv6's Sid itself has routing capabilities. For example,
> it is aggregatable, it is programmable, it is globally
> So, double-checking if I understood correctly: You are saying that the
> two uses cases that you are referring to already have an alternative
> specification with encap/decap, but this document proposes to use EH
> insertion to avoid the extra overhead of adding an additional IPv6 header?
>
Hi Mark:
I don't think it's a good idea to implement SR with IPv4.
1: Sid must be globally unique within a large range to achieve unobstructed
routing capabilities, so we need at least 16 Bit to identify the node. It also
needs to mark the device's Function, which also requires 12~16 Bit. So I
On 7/9/19 14:43, Robert Raszuk wrote:
>
> So, double-checking if I understood correctly: You are saying that the
> two uses cases that you are referring to already have an alternative
> specification with encap/decap, but this document proposes to use EH
> insertion to avoid the
I am happy to see the converging, and I agree with both Robert and Gernando.
The problem that an EH-insertion want to solve can also be solved by using an
extra encap/decap, which is obviously compliant.
The more bytes used by extra encap/decap may be the tax we have to pay for
using IPv6!
Hi,
I agree on Huzhibo on his observation on SRv6 SIDs and their benefit for
scaling, among other aspects he mentioned.
CRH based solution, on the other hand, inherits all the characteristics of a
“mapping table” based solution, including scaling. Here is a partial list:
MPLS over UDP
+1.
I didn't see the possibility of handling packets with EH in fast path without
the indication of SRv6 SID in the preceding FIB lookup. This is uniquely
introduced in SRH and SRv6 networking programming draft.
The only 'problem' rising on the list, the V6 TI LFA, has been uniquely
considered
Ron,
> There hasn't been a single mail denying the above advantages of SRv6+
Among many comments from many operators and vendors, please see,
https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4
We must remind you that the original questions from the Spring chair were
the CHG bit is meaningful of hop-by-hop options, but is totally meaningless for
Destination options.
CHG is meaningful for both.
Also I think the use of unique last-5bits of option is just a week
recommendation. There is still enough space of 8bit if needed. It's not
necessary to change
Zafar,
While I am not going to answer all the points in your email – I am going to
raise one issue. You talk about NOT debating a solution. I point out that it
was also stated in Montreal that we needed an analysis of the IPv6 address
space required by the network programming and usid
Hi,
Please see in-line.
Thanks
Regards … Zafar
From: Sander Steffann
Date: Saturday, September 7, 2019 at 12:57 PM
To: Andrew Alston
Cc: "Zafar Ali (zali)" , Ron Bonica ,
Shraddha Hegde , Rob Shakir , SPRING WG
List
Subject: Re: [spring] Going back to the original question for the Spring
> [ZA] Please refer to section 3 of SRv6 deployment draft,
> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-01#section-3.
> It provides some details on the Significant industry collaboration that led
> to SRv6 standardization. SRv6 standardization went through the
On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica
wrote:
>
> Folks,
>
>
>
> We have explored many facets of SRv6 and SRv6, sometime passionately. I think
> that this exploration is a good thing. In the words of Tolkien, “All who
> wander are not lost.”
>
>
>
> But it may be time to refocus on the
Can someone give an example or use case of when SR insertion would be required
by an intermediary node in an SRv6 domain?
Sometimes when dealing with complex subjects and discussions for me it makes
sense to start with basics and work your way back up to reasons why decisions
were made for a
On Sat, Sep 7, 2019 at 10:38 AM Zafar Ali (zali) wrote:
>
> Hi Alex, Robert,
>
>
>
> I agree fully.
>
>
>
> From an IETF process viewpoint, Suresh recently cited his email on this topic:
>
> https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc
>
> “I just want to confirm that
37 matches
Mail list logo
