Hello Bruno, Jon and Ignas,
thank you for the quick minutes!
One addition please:
@@ -65,2 +65,3 @@
Shahram: I advise not to go that route and just mandate everything use
same SRGB
+Martin Horneffer: This proposal lets devices which can configure a
CA-SRGB stay with it. Only devices
Support for wg adoption from me. In my opinion, this document describes
a real, serious use-case.
Martin
Am 22.07.15 um 15:13 schrieb John G. Scudder:
Dear WG,
As we discussed at our meeting yesterday, working group adoption has been
requested for draft-geib-spring-oam-usecase. Please
Support.
Martin
Am 22.07.15 um 15:15 schrieb John G.Scudder:
Dear WG,
As we discussed at our meeting yesterday, working group adoption has been
requested for draft-filsfils-spring-segment-routing-msdc. Please reply to the
list with your comments, including although not limited to whether or
As a co-author I support the adoption of this draft.
Also I am not aware of any IPR touched.
Best regards, Martin
Am 22.07.15 um 15:17 schrieb John G.Scudder:
Dear WG,
As we discussed at our meeting yesterday, working group adoption has been
requested for
Hello Les, Acee, Stephane, everyone,
happy new year!
From an operator's (carrier's) point of view I clearly and strongly
support this alternative solution: Treat an inconsistent set of SRGB
announcements as broken and ignore it.
- It is the simplest solution.
- It only affects traffic of
Hello Bruno, Les and everyone,
while I do appreciate and understand Les' motivation to forward this
document quickly, I would rather support Bruno's approach to first do a
little of analyses and discussions of the possible options before
finally deciding for one. So: many thanks to both of
Hi Les,
this topic, and this document is in my eyes a very important one. Thanks
a lot for writing and promoting it!
During the Berlin WG session you proposed a new preference rule which
would make the policy choice easier. You asked for a discussion on the
list - more on your slides rather
me...@ietf.org>>
Cc: <spring@ietf.org <mailto:spring@ietf.org>>, <ipr-annou...@ietf.org
<mailto:ipr-annou...@ietf.org>>
Dear Hannes Gredler, Clarence Filsfils, Stefano Previdi, Bruno
Decraene, Martin Horneffer, Pushpasis Sarkar:
An IPR disclos
Hello everyone,
speaking as co-worker of one of the editors: From my own viewpoint I
think this document makes a lot of sense and is in a good state. I'm not
aware of any problemwith the current state of the document. And there
already is an implementation report. The document should be sent
Hello Martin, and group,
I not aware of any IPR concerning this document either.
And I'm sorry I missed the call over my parental leave and offlineness.
Best regards, Martin
Am 09.09.16 um 13:57 schrieb Martin Vigoureux:
Authors and Contributors,
it seems that we are missing answers to the
As a contributor, and from an operator's point of view I support this
document.
Martin
Am 28.11.16 um 10:37 schrieb Martin Vigoureux:
Hello WG,
this e-mail initiates a two-week WG LC for
draft-ietf-spring-segment-routing [1].
All authors have already replied to the IPR poll.
There is
As a contributor, and from an operator's point of view I support this
document.
Martin
Am 28.11.16 um 10:37 schrieb Martin Vigoureux:
Hello WG,
this e-mail initiates a two-week WG LC for
draft-ietf-spring-segment-routing [1].
All authors have already replied to the IPR poll.
There is known
Strong support from me, too.
From an operator's point of view this is really needed.
Best regards, Martin
Am 10.07.17 um 14:58 schrieb Martin Vigoureux:
WG,
We are half-way through the WG Last Call and I am very surprised to
only see a single answer to it.
I am not sure I'll move this
+1
In other words, I confirm from an operators point of view that Robert
got good network desing goals quite right. I also perfectly agree with
the observations concerning the use of RSVP in the past.
BR, Martin
Am 21.11.17 um 19:34 schrieb Robert Raszuk:
Hi Adrian,
I am not going to
Hi,
first thank you Shraddha for bringing the topic of traffic measurement
to the lists.
And thanks to Stephane for focusing on the - from my point of view -
most important aspects.
Apparently you can have different requirement for traffic measurement
and based on those you'll need more or
Hi Stewart,
a quick comment on this, from an operator's point of view: Yes, we do
need the same measurements for LDP as well as for SR.
The exact kind of counter may be debatable. From what we have now,
per-FEC counters (per-SID for SR) on every node seem like the best
practical and
Dear chairs and group,
may I ask about the status of
draft-filsfils-spring-segment-routing-policy-05?
With the rechartering discussion I got the impression that nobody was
doubting that this work belongs in the SPRING wg. Would it be ready for
a wg adoption call now?
Best regards, Martin
I am not aware of any IPR that applies to this document.
Best regards, Martin
Am 16.05.18 um 17:20 schrieb Rob Shakir:
Hi SPRING WG,
In parallel to the call for adoption
for draft-filsfils-spring-segment-routing-policy, we would like to
poll for IPR.
If you are aware of IPR that applies
Speaking for an operator, and as a long-time responsible person for
applying traffic engineering to a global network, I support adoption of
this document at the SPRING wg.
Best regards, Martin
Am 16.05.18 um 17:20 schrieb Rob Shakir:
Hi SPRING WG,
This email initiates a two week call for
I’m not aware of any not yet disclosed IPR.
Best regards, Martin
Am 24.05.18 um 19:28 schrieb bruno.decra...@orange.com:
Hi SPRING WG,
In parallel to the WGLC for draft-ietf-spring-segment-routing-mpls, we
would like to poll for IPR.
If you are aware of IPR that applies to
Hello Bruno, Martin, Rob, and whole WG,
as with many bigger protocols that actually make their way into
production networks, I get the strong feeling that SPRING is not done
with the conclusion of the core documents. As the technology gets closer
to production use, unforeseen topics and
, Martin Horneffer wrote:
Hello Bruno, Martin, Rob, and whole WG,
as with many bigger protocols that actually make their way into
production networks, I get the strong feeling that SPRING is not done
with the conclusion of the core documents. As the technology gets
closer to production use
+1
Or, to be more explicit, mentioning TEAS is - in my eyes - a major
reason to insist in keeping the SPRING wg for a while, and for
having the SRE-TE discussions here and not there!!!
While it's always good to learn from each other, I strongly believe that
moving any SR-TE discussion to
ering", but in a way that doesn't
allow for any other methodology but using RSVP.
Apparently that feeling of insult made me choose aggressive words, which
I shouldn't have used. It was not my intention to hurt anyone in return.
Best regards, Martin
Am 20.03.18 um 14:27 schrieb Martin Horn
Hello everyone,
again it seems the interesting questions only show up when applying
something to the live network...
We ran into something that poses a question related to RFC8660: What is
the exact meaning of section 2.10.1, "Forwarding for PUSH and CONTINUE
of Global SIDs", when the
Saad <mailto:tsaad@gmail.com>> wrote:
Hi Martin,
See inline for some comments.
On 8/27/20, 6:35 AM, "spring on behalf of Martin Horneffer"
mailto:spring-boun...@ietf.org> on
behalf of m...@lab.dtag.de <mailto:m...@lab.dtag.de>> w
rd packets without a labelled route, you need to make sure that
this protection remains.
Regards,
Jakob.
-Original Message-
From: spring On Behalf Of Martin Horneffer
Sent: Thursday, August 27, 2020 3:35 AM
To: spring@ietf.org
Subject: [spring] to drop or to forward unlabelled (Re
schrieb Tarek Saad:
Hi Martin,
See inline for some comments.
On 8/27/20, 6:35 AM, "spring on behalf of Martin Horneffer"
wrote:
Hello everyone,
may I come back the the question below? Or rather let me update it a
little:
In case an SR-MPLS path is broken, sho
ition?
Best regards, Martin
Am 31.01.20 um 16:50 schrieb Martin Horneffer:
> Hello everyone,
>
> again it seems the interesting questions only show up when applying
> something to the live network...
>
> We ran into something that poses a question related to RFC8660: What
&g
have BGP free core (or Internet route
free core) I would say sure good idea to continue. But since you do I
think this is a lot of hidden traps number of networks may fall into
by doing it. So at least it should not be a default behaviour.
Thx,
R.
On Thu, Aug 27, 2020 at 12:35 PM Martin Hornef
perational experience and several internal discussions we
agreed that we want packets to be forwarded unlabelled rather than
dropped. Anyone to share, or oppose this position?
Best regards, Martin
Am 31.01.20 um 16:50 schrieb Martin Horneffer:
Hello everyone,
again it seems the interesting questions
Cheers,
Jeff
On Sep 4, 2020, at 17:49, bruno.decra...@orange.com wrote:
Hi Martin,
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Martin
Horneffer
Hello everyone,
may I come back the the question below? Or rather let me update it a little:
In case an SR-MPLS path is brok
Hi Shraddha, Pushpasis,
it's a very good point to see this interaction being documented. Thank you!
I support it.
Best regards, Martin
Am 04.08.20 um 19:48 schrieb Shraddha Hegde:
Hi Pushpasis,
Thanks for the review and comments.
Pls check if the below text looks good.
“
Thank you Martin, Rob, Jim and Joel!
Apparently chairing this wg is not an easy job. I greatly appreciate
that you support/did/do it!
Best regards, Martin
Am 14.06.20 um 22:25 schrieb Martin Vigoureux:
WG,
Rob had decided to step down as chair some time ago. There hasn't been
any formal
Yes, support.
From an operator's point of view: I think this can add valuable
enhancements to SR enabled networks.
Best regards, Martin
Am 07.06.21 um 14:33 schrieb James Guichard:
Dear WG:
The IPPM WG has adopted
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00
Dear srcomp dt, and spring wg,
thanks a lot for the enormous effort to collect and describe all the
requirements for compression mechanisms, and for already starting the
analysis! A true work of merit.
From an operator’s point of view I would like to add two requirements
that I believe to
Dear chairs,
I am not aware of any IPR concerning this documennt.
Best regards, Martin
Am 11.04.21 um 12:34 schrieb James Guichard:
Hi Authors, Contributors, WG
Authors of draft-ietf-spring-segment-routing-policy have asked for WG
last call. In preparation of the WGLC this email starts a
en covered
by existed "4.2.4. SID summarization" ?
B.R.
Weiqiang Cheng
-邮件原件-
发件人: spring [mailto:spring-boun...@ietf.org] 代表 Martin Horneffer
发送时间: 2021年4月7日 20:47
收件人: spring@ietf.org
主题: [spring] operator requirements for
draft-srcompdt-spring-compression-requirement
Dear s
-
From: spring On Behalf Of Martin Horneffer
Sent: Wednesday, April 14, 2021 11:53 AM
To: Weiqiang Cheng ; spring@ietf.org
Cc: 'srcomp'
Subject: Re: [spring] operator requirements for
draft-srcompdt-spring-compression-requirement
[External Email. Be cautious of content]
Hi Weiqiang,
thank
Many thanks to the DT for the good and thorough work(1)!
And many thanks to Wim for bringing this thread to the list.
My view as an operator is:
We already have more than enough standards and options. Often enough
actually introducing new technology in a multi-vendor environment is a
pain
My opinion clearly is: The WG should standardize ONE solution for SRv6
header compression, and it should follow to results of the DT.
Reason: As an operator I could theoretically ignore the effort vendors
have for implementing solution that I do not care for.
In reality however that usually
Hi Tony,
If silicon sooner or later get's tailored for SRv6, can't it be made to simply
parse big enough headers?
My understanding of SRv6 is that the SID list is effectively unbounded. It’s
hard to grow silicon to keep up with unbounded. :-)
true, but also true for any factor x by which
Hi Tony,
well said.
With this in mind I'd rather ask: Do we really need SID list compression
at all?
If silicon sooner or later get's tailored for SRv6, can't it be made to
simply parse big enough headers?
IMHO SRv6 is the one thing that really allows for full flexibility for
whatever
Hello everyone,
as I see it, the document fits well into the framework of RFC8986, it
solved the problem, and does so in an efficient manner. Thus I support
the adoption of this document.
Best rergards, Martin
Am 01.10.21 um 16:04 schrieb James Guichard:
Dear WG:
The chairs would like to
Dear WG,
strong support from my side.
While I would not advise to run an SR enabled network to mainly carry
circuit-style traffic, I do think this approach might be a valuable
technology to further consolidate multi-service network, esp in cases
when plain packet traffic seriously exceeds
45 matches
Mail list logo
