> On the composition of the DT, the selection was done by the WG, so are we
> questioning if this was done appropriately. People have various backgrounds
> and I found the mix pretty good. Again if after 1 year this is being
> discussed I find this very odd. Could have been done a while ago if ther
Let me shime in as another individual contributor.
On requirements, there has been plenty of input from various people (see
meeting minutes and comments from people on mailing lists). On top given the
people discussing this were in the DT they had direct access to getting the
requirements in th
Darren,
First, it is important to note that you and I can speak as members of the
design team, but not on behalf of it. Neither the design team nor the WG chairs
have commissioned us to do that.
Beyond that, the WG has every right to evaluate whether any candidate solutions
violate existing BC
Speaking as a design team member, I have some corrections to make. Please see
[DD] inline.
On 2021-07-26, 9:16 PM, "Ron Bonica"
wrote:
Gyan,
The design team was not chartered to select a winner. It was chartered to
provide input to the WG.
AFAIKS, the WG still has the following tasks before
Hi Stewart,
I agree with your examples that PCE and RSVP label distribution mechanisms
allow egress to deduce the identity of the ingress LER. In MPLS-TP, as I
recall, label merge and PHP are prohibited, and that also allows the egress to
"know" the particular ingress LER based on the ToS label
Hi Stewart,
Please find some feedback inline.
Thanks!
Xuesong
From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Tuesday, July 27, 2021 10:33 PM
To: Gengxuesong (Geng Xuesong)
Cc: Stewart Bryant ; 6...@ietf.org; spring@ietf.org
Subject: Re: Discussion about SRv6 Midpoint Protection Me
Hi Cheng
Again, Excellent work done by DT - Many Thanks!
Comments in-line
Gyan
On Tue, Jul 27, 2021 at 6:26 AM Chengli (Cheng Li) wrote:
> Hi Gyan,
>
>
>
> Many thanks for your comments. Yes it is, we finished the work as
> required, really difficult.
>
> Gyan> Yes very difficult job & well
For all operators around the world looking at deployment of SRv6
compression and being in a holding pattern waiting for SRv6 compression to
be standardized by the IETF.
Given the ubiquitous importance of SRV6 compression and MSD issues with
long strict SR-TE explicit route object, it is critical
+1. 😊
Regards,
Keyur
From: spring on behalf of "Henderickx, Wim (Nokia -
BE/Antwerp)"
Date: Tuesday, July 27, 2021 at 12:11 AM
To: "spring@ietf.org"
Subject: [spring] SRv6 compression
Given the design team accomplished the work on providing requirements and
analysis to compress an SRv6 SID
I agree with this.
The experience in NVO3 was that picking one data plane solution to take forward
on the standards track allowed the WG to focus on that solution, as well as
control plane and OAM mechanisms required to support it. It also gave a clear
indication to the industry.
Regards
Matt
Presumably the path is N1->N2->N3->N4 with N3 being node protected
3. SRv6 Midpoint Protection Example
The topology in Figure 1 illustrates an example of network topology
with SRv6 enabled on each node.
Chen, et al.Expires January 13, 2022[Page 3]
Internet-Draf
Same here. We want a single standard method of SID compression to allow the WG
to focus on finalizing it and get vendors hardware implementations updated.
Regards,
Mustapha.
From: spring On Behalf Of Rabadan, Jorge (Nokia -
US/Mountain View)
Sent: Tuesday, July 27, 2021 4:54 AM
To: Henderickx,
+1
Kind Regards
Gyan
On Tue, Jul 27, 2021 at 4:54 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:
> I agree with Wim’s statement that the precedent in NVO3 **could** apply
> here too: pick one solution as Standard’s track RFC, and once it is done,
> the others m
Hi 6man,
We have proposed an SRv6 local repair mechanism to provide endpoint protection.
The document could be found in:
https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/
The basic idea is quite straight forward: when the node finds that the
neighbor, which the packet i
Hi,
IMHO: Standardized solution for the same problem (more optimal data plane for
SR in IPv6 infrastructure) should be one.
VPLS has lost a lot of market to L3VPN because VPLS had LDP and BGP flavors.
Many vendors have implemented only one, customers did not want vendor lock.
The primary goal of I
Chairs.
The design team had no such question about csid nor any of the srv6 based
proposals.
Csid utilizes the locator function and argument documented in rfc8986 and the
srh as documented in rfc8754. This is all described in the draft.
Darren
From: spring o
Hi all
From the analysis report provided by the hard work of the DT, I think the C-SID
solution is the most reliable solution for me.
I hope the WG can move forward the adoption poll of the C-SID solution.
Thanks
Yisong
发件人: Chengli (Cheng Li)
时间: 2021/07/27(星期二)18:17
收件人: Gyan
Hello,
Knowing the importance of compressed SID for SRv6, it is imperative for the
industry to have a single standardized solution. In this context, it would be
wise for the IETF to leverage on what has been previously achieved by other WGs
facing a similar situation, e.g. NV03 when selecting t
Agree, we should pick one solution to be standardized now, to facilitate the
network deployment.
And I believe the solution is the one that has been implemented by the most
vendors in the world, which is CSID.
That would help the industry for sure.
Respect,
Cheng
发件人: spring [mailto:spring-
Hi Gyan,
Many thanks for your comments. Yes it is, we finished the work as required,
really difficult.
I do hope the WG can move forward to make the adoption call of the better/best
solution.
As you know, the vendors and operators have made their choice already, over 10
vendors have implement
I agree with Wim’s statement that the precedent in NVO3 *could* apply here too:
pick one solution as Standard’s track RFC, and once it is done, the others
might be documented as Informational RFCs if they have implementations.
That would help the industry to move forward.
Thanks.
Jorge
From:
Hello Fan;
I read something else there too; the question whether we need to do PREOF
inside the network (IOW a complex mesh or ring chain of replication and
elimination) or whether it is enough to do it only end to end (IOW live-live
only).
When we started DetNet, many people came from TP styl
Hi Stewart & Weiqiang,
Thanks for Mr Stewart's comments, which are valuable for understanding the Path
Segment.
And I agree Weiqiang's responses. One more thing I want to notice that Path
Segment could balance the philosophy of SR and MPLS for Path capabilities, such
as Path Policy or PM. T
Given the design team accomplished the work on providing requirements and
analysis to compress an SRv6 SID list, I would recommend we pick 1 solution
similar to what was done in NVO3 (when we discussed GENEVE, GUE, GPE, etc)
given this has to be implemented in HW..
I hope we can conclude on thi
Hi SPRING,
Due to limited presentation time today, I’d like to give the clarification to
the questions brought by Greg at IETF 110 and 111.
From today’s meeting minutes:
Suggest to analyze why this is more beneficial than just 1+1 protection when
you select the working source and protection sou
25 matches
Mail list logo
