ing@ietf.org>; Mach Chen
mailto:mach.c...@huawei.com>>; Ron Bonica
mailto:rbon...@juniper.net>>; 6man
<6...@ietf.org<mailto:6...@ietf.org>>; Chengli (Cheng Li)
mailto:c...@huawei.com>>; Zafar Ali (zali)
mailto:z...@cisco.com>>
主题: [spring] Long-standing practice of
: Henderickx, Wim (Nokia - BE/Antwerp) ; Sander
Steffann
抄送: spring@ietf.org; Mach Chen ; Ron Bonica
; 6man <6...@ietf.org>; Chengli (Cheng Li)
; Zafar Ali (zali)
主题: [spring] Long-standing practice of due-diligence is expected - Re: CRH is
not needed - Re: How CRH support SFC/Segment En
Hi Ron,
The problem that I see is that the draft that we are reviewing for adoption
does not explain properly how CRH based IPv6 Source Routing works it's
evaluation for WG adoption.
I do find some of those details in the SRm6 draft which uses CRH but based on
your response, we should not be r
Hi Wim,
> Sander, can you describe your use case. So far the only thing that people has
> asked CRH to do is steering and as mentioned we have solutions for those. If
> there are others, please share them..
Well, a routing header is obviously for steering, but not only encapsulated
payloads ne
Sander, can you describe your use case. So far the only thing that people has
asked CRH to do is steering and as mentioned we have solutions for those. If
there are others, please share them..
On 28/05/2020, 16:58, "Sander Steffann" wrote:
Hi Robert,
> There can be a lot of acronymou
Sorry Typo 20 bit label not 2 byte label.
SR-MPLS still has the concept of FEC label binding but now just uses a
different range of 20 bit labels 16k-24k so is not overlapping with MPLS
LDP default label range.
Kind Regards
Gyan
On Thu, May 28, 2020 at 12:27 PM Gyan Mishra wrote:
>
> Robert
>
Robert
SR-MPLS is not using MPLS “LDPv4” but is still using the MPLS data plane
“layer 2 1/2” 4 byte shim now a much larger label stack subject to MSD
(Maximum SID Depth) issues with long static lsp SR-TE paths. SR-MPLS
still has the concept of FEC label binding but now just uses a different
ran
Ketan,
Please take a look at the version of the draft that we are reviewing. Values
0-15 are no longer reserved.
Ron
Juniper Business Use Only
From: Ketan Talaulikar (ketant)
Sent: Thursday, May 28, 2020 9:33 AM
To: Erik Kline ; Zafar Ali (zali)
Cc:
Hi,
All fine and your use case is valid. I never said it is not.
* But first it makes all those claims that solutions under discussion are
not to be used in Internet moot.
* Second you can use subset of SRH just fitted to your need end to end
without any encapsulation
* Last if I were you I wou
> And this is an important difference: some of us don't want
> encapsulation/tunneling, we want something that can be part of a
> non-encapsulated packet. There are use-cases where CRH used with
> encapsulating is the best solution, and there are cases where the packet
> itself can be steered w
Hi Robert,
> There can be a lot of acronymous or names invented but under the hood it 16,
> 32 or 20 bit opaque bit string in both CRH and SR-MPLS which is mapped to a
> rewrite string. No more no less.
So far so good
> And rfc8663 precisely automated such rewrite to UDP encapsulation.
And th
Fred and others,
I think there is some confusion here among many people.
SR-MPLS is not LDP MPLS ... even though both can be used for transport.
Nearly 25 years after introduction of tag switching people are highly
confused what MPLS is. Most do not even understand that service MPLS and
transpor
On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, 28 May 2020 16:33
To: Erik Kline ; Zafar Ali (zali)
Cc: Ron Bonica ; spring@ietf.org; 6man
<6...@ietf.org>
Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re:
CRH is not needed - Re: How CRH support SFC/S
Zafar,
We want this for planes, trains and automobiles – all of them, worldwide. And,
I am
not interested in looking at alternatives when I see exactly what I want in
CRH. I want
an IPv6-only solution without having to introduce an adjunct service like MPLS.
The reason compressed format is so i
Sometimes a known devil is better than an unknown one.
I think we need to be very careful in considering the introduction of a new
label/ID mapping technology into IPv6 Routing and it's ramifications.
https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-5.1
The maxim
Hi Erik,
Fully agree.
The idea was not to force ANY solution but to avoid “putting the cart before
the horse”.
As I responded to Fred at
https://mailarchive.ietf.org/arch/msg/ipv6/gyqvpfSkCt9fEZLdXnbrNjNOWg4/
Thanks
Regards … Zafar
From: Erik Kline
Date: Wednesday, May 27, 2020 at 5:40 PM
Hi Andrew,
Re: Reference is made to Montreal – yet the emails that stated the use cases
after it went by with no response.
The following use-case text was proposed during the adoption call [1].
“10.0 Use-cases
The CRH can be used to provide traffic steering in:
* Data centers
* Service
Hi Andrew,
Re: “Yes, originally, CRH was heavily linked to SRm6. But – over time,
thinking and ideas evolve.”
I looked at the following diffs
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-11.txt (rev.
10 to rev. 11 in Feb. 2020).
All I find is surgical removal of SRm6 and
Fred, if the issue is a document to describe RFC 8663 w/o calling our MPLS,
this can be done. Would that solve your issue?
From: "Templin (US), Fred L"
Date: Wednesday, 27 May 2020 at 22:33
To: Andrew Alston , Ron Bonica
, "Zafar Ali (zali)" ,
"Henderickx, Wim (Nokia - BE/Antwerp)" , Sander
S
Hi Fred,
MANY thanks for your follow-up – much appreciated.
> 3) Have the associated WG analyzed existing solutions? Have they feed the
> results
> of the above to 6man WG?
> I assume you are referring to existing SRH solutions? The subject of SRH is
> new
> to the aviation circles,
The su
Brian E Carpenter 写道:
On 28-May-20 07:18, Zafar Ali (zali) wrote:
WH> My position remains that RFC8663 is a valid alternative and is available; I
am against WG adoption of CRH.
The industry widely supports RFC8663.
Can you remind us which major operators rely on RFC8633 today? After
On 27/5/20 19:32, Zafar Ali (zali) wrote:
[...]
CRH is a “major” change and outside the scope of 6man charter.
This is plain wrong. I will remind you that this very same group shipped
what became RFC8754.
It should follow the proper IETF review process.
Well, yeah. What's ongoing is a "
On 27/5/20 18:50, Robert Raszuk wrote:
[...]
I am not against CRH. But what I am against is that CRH/SRm6 authors
already bounced back via SPRING doors so they have chosen to try to
enter via 6man window. That is not proper style for any proposal.
As someone that has experienced how folks ha
Are you a member of the IESG?
On Thu, 28 May 2020, 08:33 Zafar Ali (zali), wrote:
> Hi,
>
>
>
> The authors of CRH has already have multiple drafts and more CP/ DP
> changes will be required. E.g., it will require
>
>- ISIS changes (draft-bonica-lsr-crh-isis-extensions)
>- To carry VPN i
Zafar,
Many of the drafts that you list below are unrelated to the CRH (e.g.,
draft-bonica-6man-vpn-dest-opt). Many do not exist and are not required (e.g.,
OAM for debugging the mapping table).
Try to understand that the CRH is a building block that can be deployed in many
scenarios. It is no
Hi,
The authors of CRH has already have multiple drafts and more CP/ DP changes
will be required. E.g., it will require
* ISIS changes (draft-bonica-lsr-crh-isis-extensions)
* To carry VPN information (draft-bonica-6man-vpn-dest-opt)
* For SFC (draft-bonica-6man-seg-end-opt)
* BG
Zafar,
It amazes me how totally selective you are with your reading.
I won’t even bother dignifying much of the word twisting and gaming and
selective reading with a response – but what I will say is this. Yes,
originally, CRH was heavily linked to SRm6. But – over time, thinking and
ideas e
Hi Brian,
As you said,
>>I'd like hear from the Routing Area ADs.
And you also mentioned the following in [1]:
“progressing this draft without advice from the Routing Area that it is needed
would be a bit foolish IMHO.”
I agree with you.
I also said in my email is that “could the CRH auth
On 28-May-20 09:50, Robert Raszuk wrote:
> Andrew,
>
> I don't think this is about killing innovation. After all no one is saying
> you can not use it in your network.
>
> WG acceptance calls
Adoption is not acceptance. At least half the messages on this topic are
written as if we were in th
Hi Ron,
If there would never been SRm6 I would welcome that we have a technical
discussion and compare pros and cons between CRH and RbR .. then we proceed
with best option for the industry.
If you are open to such discussion my doors are open.
Best,
Robert
On Wed, May 27, 2020 at 11:59 PM Ron
Robert,
If there had never been an SRm6 proposal, would you still object to the CRH?
Ron
Juniper Business Use Only
From: Robert Raszuk
Sent: Wednesday, May 27, 2020 5:50 PM
To: ext-andrew.als...@liquidtelecom.com
Hi Zafar,
1) Is there any IETF requirement document for OMNI and AERO (I am sorry I am
not aware of the technology but very much interested in learning)?
AERO began life in the IEFT many years ago and was progressed there up to about
three years ago when it was brought into focus in the Internat
Andrew,
I don't think this is about killing innovation. After all no one is saying
you can not use it in your network.
WG acceptance calls are evaluated in terms of WG rough consensu if
significant number of members of WG find a proposal useful and if they are
willing to work on it.
It seems cle
There are actual, meaningful differences to be contemplated; folks
with no operational MPLS in there networks might not want to be forced
to start.
On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali)
wrote:
>
> Fred,
>
>
>
> Is there any IETF requirement document for OMNI and AERO (I am sorry I am
-Original Message-
From: ipv6 On Behalf Of Sander Steffann
> This makes me think back to the days of telcos. You know, the world where
> telcos defined the protocols and the users just had to accept their
> choices... The world where TCP/IP flourished because it allowed
> permissionles
Fred,
Is there any IETF requirement document for OMNI and AERO (I am sorry I am not
aware of the technology but very much interested in learning)?
Do we have some documents describing the scale you would need?
Have the associated WG analyzed existing solutions?
Have they feed the results of the a
On 28-May-20 07:18, Zafar Ali (zali) wrote:
> WH> My position remains that RFC8663 is a valid alternative and is available;
> I am against WG adoption of CRH.
>
> The industry widely supports RFC8663.
Can you remind us which major operators rely on RFC8633 today? After all, the
RFC is only 5 mo
Hi Andrew,
> What I find so bizarre is –
>
> You have an multiple operators – who have clearly said – we want this – we
> see advantage of this. Yet still the obstructionism and denialism continues.
> The “not invented here” syndrome seems to run deep – and email after email
> is patently ig
As I said, I want to use CRH for OMNI and AERO; I don't want the term "MPLS" to
appear
either in my documents or in any documents mine cite. The 16-bit CRIDs in CRH
are very
handy for coding ULA Subnet Router Anycast addresses such as fd80::/16,
fd81::/16,
fd82::/16, etc., and the 32-bit CRIDs a
What I find so bizarre is –
You have an multiple operators – who have clearly said – we want this – we see
advantage of this. Yet still the obstructionism and denialism continues. The
“not invented here” syndrome seems to run deep – and email after email is
patently ignored from the very peop
Zafar,
Why all the passion about stopping the CRH? Does it break any existing
standard? Does it consume any scarce resource?
You might argue that there is a scarcity of Routing header type numbers. But
that would be a very short argument. You might argue that WG resources are
scarce, and that
WH> My position remains that RFC8663 is a valid alternative and is available; I
am against WG adoption of CRH.
The industry widely supports RFC8663.
Instead of denying the evidence, could the CRH authors and proponents finally
understand that people are not opposed to new ideas?
People ar
42 matches
Mail list logo
