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 the
Hello everyone,
there is a problem for networks that use spring on the MPLS forwarding
plane: It seems it would not be feasible to use anycast segments for
traffic engineering since we introduced indexed SIDs.
I would really like to use of some well-defined anycast addresses to
solve a numbe
+support
BR, Martin
Am 10.06.15 um 18:06 schrieb bruno.decra...@orange.com:
Hello working group,
This email starts a two-week poll on adopting
draft-kumar-spring-sr-oam-requirement as a working group item.
“OAM Requirements for Segment Routing Network“
https://tools.ietf.org/html/draft-ku
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 reply
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
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-central-epe. Please reply
to the list with your comments, including although not limited to whet
Support.
Best regards, Martin
Am 22.07.15 um 15:23 schrieb John G.Scudder:
[re-send with correct address for isis-wg]
Dear SPRING WG (and cc MPLS, OSPF, IS-IS, 6MAN, please include SPRING in
replies per the reply-to):
As we discussed at the SPRING meeting yesterday, working group last call
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 draft-filsfils-spring-segment-routi
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 not
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 t
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 you
Hello everyone,
concerning the first comment: I don't think that a document needs to
explicitly specify all out-of-scope topics in order to be
self-contained. So not exactly a contradiction, just maybe confusing.
Concerning the second comment: This is just another example of the
frequent mis
Support.
From an operator's point of view I see strong need for covering this topic.
Best regards, Martin
Am 14.04.16 um 09:50 schrieb bruno.decra...@orange.com:
Dear WG,
As we discussed at our meeting last week, working group adoption has been
requested for draft-ginsberg-spring-conflict-r
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
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 t
As an operator and as co-author I strongly support WG adoption of this
document.
IMO it is essential to make the SPRING architecture for the MPLS
dataplane complete.
Also I am not aware of any IPR.
BR, Martin Horneffer
Am 24.07.16 um 14:39 schrieb John G. Scudder:
Dear WG (and cc MPLS
..@ietf.org>>
Dear Hannes Gredler, Clarence Filsfils, Stefano Previdi, Bruno
Decraene, Martin Horneffer, Pushpasis Sarkar:
An IPR disclosure that pertains to your Internet-Draft entitled
"Anycast
Segments in MPLS based Segment Routing"
(draft-psarkar-s
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 IP
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 know
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
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 chosen
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 co
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.
“
draft-ietf-sprin
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
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
s position?
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: Wh
02:36 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
Tarek 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>&
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: Q
rt).
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 bro
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 be
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 pol
overed
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 Weiqia
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
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 beca
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 use
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 doe
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 y
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
Hello,
support from me as co-author and operator.
Bets regards, Martin
Am 27.01.17 um 12:05 schrieb Martin Vigoureux:
Hello Working Group,
This email starts a 2-week Working Group Last Call on
draft-ietf-spring-segment-routing-mpls-06 [1].
¤ Please read the document if you haven't read t
Hello Uma,
what kind of label depth discussion are you thinking of?
It seems to me this could easily become an endless discussion again.
People seem to have very different views on it. Thus I'm not sure
whether it would be suitable for this document.
BTW:
For my needs, bandwidth optimizatio
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 fo
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 l
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 existing
+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 defen
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 issues
n H,
On 2018-03-18 00:19, 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
+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 TEAS
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 M
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
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 wo
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
t
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
draft-ietf-spr
54 matches
Mail list logo