On Mon, Sep 9, 2019 at 8:16 AM Robert Raszuk wrote:
>
>
>> In any case, I don't believe option number space being exhausted is why TLVs
>> are in SRV6 (if it was a problem, we'd want a general solution instead of
>> point solution just for SRV6). The reasons why TLVs were need in SRV6, as
>> op
Hello, Gyan,
On 7/9/19 19:58, Gyan Mishra wrote:
[...]
>
> I think when the SRv6 programming RFCs were written that violated the
> 6man WG RFC 8200 with EH only being allowed by the source node to insert
> EH and no other node when Spring WG decided to make this a requirement
> for SRv6 functiona
+1
Juniper Business Use Only
-Original Message-
From: ipv6 On Behalf Of Joel M. Halpern
Sent: Saturday, September 7, 2019 7:01 PM
To: Robert Raszuk
Cc: spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+ - Service Chaining
With regard to service
On 6/9/19 22:13, Voyer, Daniel wrote:
> I also agree 100% with Robert and Dirk.
>
[...]
>
> Second – facts: please do click the link and check the timeline:
>
> https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/and
> https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6
> In any case, I don't believe option number space being exhausted is why
> TLVs are in SRV6 (if it was a problem, we'd want a general solution instead
> of point solution just for SRV6). The reasons why TLVs were need in SRV6,
> as opposed to using DO or HBH, are unclear to me. I think it's some f
On Sat, Sep 7, 2019, 2:54 PM Robert Raszuk wrote:
> 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
obert Raszuk
Cc: spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Regaining Focus on SRv6 and SRv6+
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
>
> Best Regards,
>
> Cheng
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Xiejingrong
> *Sent:* Sunday, September 08, 2019 8:55 AM
> *To:* Ron Bonica ; Robert Raszuk <
> rob...@raszuk.net>; Tom Herbert
> *Cc:* spring ; 6man <6...
ng
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Xiejingrong
Sent: Sunday, September 08, 2019 8:55 AM
To: Ron Bonica ; Robert Raszuk
; Tom Herbert
Cc: spring ; 6man <6...@ietf.org>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
the CHG bit is meaningful of hop-by-h
hange interpretation of CHG.
Thanks
Jingrong
From:Ron Bonica
To:Robert Raszuk ;Tom Herbert
Cc:spring ;6man <6...@ietf.org>
Date:2019-09-08 06:32:00
SubjectRE: [spring] Regaining Focus on SRv6 and SRv6+
Robert,
You may need to rethink your argument. (That is, except for the part where you
said
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 R
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, i
Sent: Saturday, September 7, 2019 6:06 PM
To: Ron Bonica
Cc: Tom Herbert ; spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
Ron,
> SRv6+ relies on prepending
Interesting ... can you elaborate how you will do TI-LFA with SRv6+ ? If you
have slides sho
obert Raszuk
Sent: Saturday, September 7, 2019 5:54 PM
To: Tom Herbert
Cc: Ron Bonica ; spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
Dear Tom,
> The most obvious difference, besides SID size, is that SRV6 contains
> TLVs and SRV6+ doesn't.
comment about two destination headers. You might
> want to rethink that.
>
>
>
> Ron
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Saturday, September 7, 2019 1:54 PM
> *To:* Tom Herbert
> *Cc:* Ron Bonica ; spring@ietf.org; 6...@ietf.or
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
t
to rethink that.
Ron
From: Robert Raszuk
Sent: Saturday, September 7, 2019 1:54 PM
To: Tom Herbert
Cc: Ron Bonica ; spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
> It doesn
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
> 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 ho
Ron Bonica
>
> Cc:spring ;6man <6...@ietf.org>
> Date:2019-09-07 22:33:40
> SubjectRe: [spring] Regaining Focus on SRv6 and SRv6+
>
> Hi,
>
> I agree on Huzhibo on his observation on SRv6 SIDs and their benefit for
> scaling, among other aspects he mentioned.
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 follow
Cc:spring ;6man <6...@ietf.org>
Date:2019-09-07 22:33:40
SubjectRe: [spring] Regaining Focus on SRv6 and SRv6+
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 al
egards … Zafar
From: ipv6 on behalf of Huzhibo
Date: Saturday, September 7, 2019 at 12:58 AM
To: Robert Raszuk , Ron Bonica
Cc: "spring@ietf.org" , "6...@ietf.org" <6...@ietf.org>
Subject: RE: [spring] Regaining Focus on SRv6 and SRv6+
Hi Robert:
Agree with you.
SRv6 is
erhead cost would be much lower than 128 bit SIDs as a
>> result of using IPv6 addresses for SIDs.
>>
>>
>> >
>> > Thank you,
>> >
>> > Zhibo
>> >
>> >
>> >
>> > From: spring [mailto:spring-boun...@ietf.org] On Beha
uzh...@huawei.com>
发件人：Mark Smith
收件人：Huzhibo
抄 送：Robert Raszuk ;Ron Bonica
;spring@ietf.org
;6...@ietf.org <6...@ietf.org>
时间：2019-09-07 17:36:11
主题Re: [spring] Regaining Focus on SRv6 and SRv6+
Hi,
On Sat, 7 Sep 2019 at 18:08, Huzhibo wrote:
>
> Hi Mark:
> I don't
gt;
> >
> > Thank you,
> >
> > Zhibo
> >
> >
> >
> > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
> > Sent: Friday, September 06, 2019 9:33 PM
> > To: Ron Bonica
> > Cc: spring@ietf.org; 6...@ietf.org
>
oid sending something unexpected and that the receiver
will be confused by.
"Be conservative in what you send, ..."
Regards,
Mark.
> Thank you
> Zhibo
> -Original Message-
> From: Mark Smith [mailto:markzzzsm...@gmail.com]
> Sent: Saturday, September 07, 2019 2:04 P
mail.com]
Sent: Saturday, September 07, 2019 2:04 PM
To: Huzhibo
Cc: Robert Raszuk ; Ron Bonica
; spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
On Sat, 7 Sep 2019 at 14:58, Huzhibo wrote:
>
> Hi Robert:
>
>
>
> Agree with you.
&
mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
> Sent: Friday, September 06, 2019 9:33 PM
> To: Ron Bonica
> Cc: spring@ietf.org; 6...@ietf.org
> Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
>
>
>
> Dear Ron,
>
>
>
> I think you forgot f
network and IP network, we can solve this problem in the field of
SR MPLS.
Thank you,
Zhibo
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Friday, September 06, 2019 9:33 PM
To: Ron Bonica
Cc: spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Regaining Focus o
: [spring] Regaining Focus on SRv6 and SRv6+
I agree with Robert 100%.
If you want to use MPLS with IPv6, fine go ahead and
do so. All you need is already there. No need to
re-invent MPLS over UDP using a different encapsulation
inappropriately named "SRv6+".
SRv6 provides many distinct advan
;
To: Robert Raszukmailto:rob...@raszuk.net>>;SPRING WG
Listmailto:spring@ietf.org>>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
Time: 2019-09-06 22:53:00
I agree with Robert 100%.
If you want to use MPLS with IPv6, fine go ahead and
do so. All you need is already there. N
ource routing) in native IPv6
>> transport? Seems SRv6+ solves that there – and vanilla IPv4/v6 does not.
>>
>>
>>
>> Regards,
>>
>> Tarek
>>
>>
>>
>> *From: *Robert Raszuk
>> *Date: *Friday, September 6, 2019 at 10:09 AM
>
ransport? Seems SRv6+ solves that there – and vanilla IPv4/v6 does not.
>
>
>
> Regards,
>
> Tarek
>
>
>
> *From: *Robert Raszuk
> *Date: *Friday, September 6, 2019 at 10:09 AM
> *To: *Tarek Saad
> *Cc: *Ron Bonica , "spring@ietf.org"
> , "
as...@gmail.com>
> *Date: *Friday, September 6, 2019 at 9:33 AM
> *To: *Ron Bonica
> *Cc: *"spring@ietf.org" , "6...@ietf.org" <6...@ietf.org>
> *Subject: *Re: [spring] Regaining Focus on SRv6 and SRv6+
>
>
>
> Dear Ron,
>
>
>
> I thin
SRv6+ solves that there – and vanilla IPv4/v6 does not.
Regards,
Tarek
From: Robert Raszuk
Date: Friday, September 6, 2019 at 10:09 AM
To: Tarek Saad
Cc: Ron Bonica , "spring@ietf.org"
, "6...@ietf.org" <6...@ietf.org>
Subject: Re: [spring] Regaining Focus on SRv
lf of Robert Raszuk
Date: Friday, September 6, 2019 at 9:33 AM
To: Ron Bonica
Cc: "spring@ietf.org" , "6...@ietf.org" <6...@ietf.org>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
Dear Ron,
I think you forgot few main points in the summary:
* Many operato
Dear Ron,
I think you forgot few main points in the summary:
* Many operators use SR-MPLS successfully and it has been both standardized
and successfully deployed in the network with interoperable implementations
* The overhead on the data plane of SRv6+ is very comparable to overhead of
SR-MPLS
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 following:
* For many operators, SRv6 is not deployable unless the probl
39 matches
Mail list logo
