Hi Hannes,
I agree with you but if draft-kini-mpls-spring-entropy-label evolve to the
option where entropy label is always behind top label, there is no need to
encode such granularity.
That's why I think it's too early to progress the capability document.
Thoughts ?
Stephane
-Original Me
You are right, I think EL processing in SPRING is mainly an implementor
discussion about what is possible to do, what's the impact on legacy HWs ...
Some HW may also never be able to look at EL if it's 7 or 8 labels after the
top one ... and FAT PW solution (FAT label at bottom of stack) may not
Hi Rob,
Many thanks to raise this important subject back on the table.
Entropy label in SPRING is mainly a matter of what are the current capabilities
of our favorite vendor's current HW ... Unfortunately, I think we are touching
something quite "secret" and vendors would not share their issues
> It sounds like you'd be supportive of asking the authors to extend this draft
> to making a recommendation? :-)
Completely right :)
-Original Message-
From: Rob Shakir [mailto:r...@rob.sh]
Sent: Tuesday, July 22, 2014 10:23
To: LITKOWSKI Stephane SCE/IBNF
Cc: spring@ietf.org; draft-k
So let's find the best compromise ... but we can't stay stuck ...
-Original Message-
From: Xuxiaohu [mailto:xuxia...@huawei.com]
Sent: Tuesday, July 22, 2014 10:39
To: LITKOWSKI Stephane SCE/IBNF; Rob Shakir
Cc: m...@ietf.org; spring@ietf.org;
draft-kini-mpls-spring-entropy-la...@tools.
Having multiple implementations makes no sense to me :
- complex to understand in operations
- interop to handle
- vendors will not implement all the options, as some have HW development needs.
-Original Message-
From: Xuxiaohu [mailto:xuxia...@huawei.com]
Sent: Tuesday, July 22, 2014 1
IMHO,
> 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)?
Yes it is ... SPRING brings more flexibility in ECMP for TE tunnels than
RSVP-TE does. And ECMP with Bundle-Adj-SID is something really useful when a
Service Provider is using parallel ECMP links rather than LAGs.
>2) is EL the
Robert,
Talking MPLS, I don’t see a way to use MPLS label “prefix” … this is a
discussion we already had together. I think you are trying to sell IPv6 SR that
I will unfortunately not buy again ☺
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2
Robert,
From a practical point of view , how do you represent such MPLS label range
with a prefix ?
[70, 170]
[17, 69]
MPLS was not designed for “label aggregation” scheme …
Or we need to change of labels are allocated from the label space for all label
consumers … to permit this aggregation.
> We already know how to encode label offset.
Are you referring to Segment Index as offset of label base ?
> Using the same encoding you can treat offset value as number of significant
> bits within the 20 bit label.
Could you give an example of lookup and forwarding structure for your label
r
I'm not aware of non disclosed IPR.
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Wednesday, November 12, 2014 19:40
To: Alvaro Retana (aretana)
Cc: spring@ietf.org; draft-filsfils-spring-segment-routing-m...@tools.ietf.org
S
I'm not aware of non disclosed IPR.
From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
Sent: Wednesday, September 24, 2014 15:03
To: draft-filsfils-spring-segment-rout...@tools.ietf.org
Cc: spring@ietf.org
Subject: IPR Claims related to draft-filsfils-spring-segment-routing
Hi!
In paralle
I think it would be good to discuss this topic within SPRING WG.
-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of
stephane.litkow...@orange.com
Sent: Monday, January 12, 2015 09:14
To: Rob Shakir
Cc: isis...@ietf.org;
draft-ietf-ospf-segment-routing-extensi...@to
Hi Bruno,
Using TTL may work or not. Backup path does not mean that you will defacto have
more hops. Metric of backup path could be higher but number of hops equal or
smaller.
I created a new thread on SPRING WG list to discuss the different options.
Thanks !
-Original Message-
From:
Very good point, in our case, today we have up to 15 strict hops for TE tunnels.
When we will introduce interdomain, it will bring more.
-Original Message-
From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com]
Sent: Monday, January 12, 2015 11:45
To: LITKOWSKI Stephane SC
> Stack compression is only really required today because we have hardware that
> has never needed the stack depths that we’re talking about currently. Going
> forward, if SPRING-TE/SR-TE/AdjSID stacks are popular as a solution, then I
> see no reason that we MUST always have path compression. I
Hi Greg,
Inline comments
-Original Message-
From: Gregory Mirsky [mailto:gregory.mir...@ericsson.com]
Sent: Tuesday, January 13, 2015 19:59
To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org
Subject: RE: Providing unprotected SPRING TE path
Hi Stephane, et. al,
very interesting topic. Ple
Hi,
I agree with your point Nagendra, TTL cannot be used (Bruno already proposed
such TTL solution on ISIS/OSPF ML).
-Original Message-
From: Nagendra Kumar Nainar (naikumar) [mailto:naiku...@cisco.com]
Sent: Wednesday, January 14, 2015 05:50
To: Nobo Akiya (nobo); Rob Shakir; LITKOWS
Note that the case you pointed regarding bidirectional LSP with SPRING is also
interesting to investigate.
-Original Message-
From: Gregory Mirsky [mailto:gregory.mir...@ericsson.com]
Sent: Tuesday, January 13, 2015 19:59
To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org
Subject: RE: Pro
FYI, here is a first shot of YANG config model for segment-routing.
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, March 05, 2015 16:45
To: Ing-Wher Chen; Ing-Wher Chen; Pushpasis Sarkar; LITKOWSKI Stephane
SCE/IBNF; Acee Lindem; Acee
Hi Alvaro,
In case you did not receive my reply, I'm not not aware of any IPR regarding
this draft.
Best Regards,
From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
Sent: Tuesday, September 23, 2014 13:35
To: draft-ietf-spring-problem-statem...@tools.ietf.org
Cc: spring@ietf.org
Subject:
Hi Bruno,
"1) I don't really the issue. From a forwarding standpoint, looks like
we can simply program multiple SIDs in the FIB."
[SLI] What about the IP to MPLS entry ?
Support.
I'm not aware of any IPR on this document.
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Wednesday, June 10, 2015 17:06
To: spring@ietf.org
Subject: [spring] Poll for adoption: draft-kumar-spring-sr-oam-requirement
Hello working group,
Thi
Even if choosing any IP to MPLS entry does not break anything, I'm not sure
this is a good idea from an operational point of view to let it undeterministic.
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Thursday, June 18, 2
Hi Bruno,
It would be good if we can have 10min to present the progress on SPRING Yang
model.
Thanks,
Stephane
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Monday, June 22, 2015 20:41
To: spring@ietf.org
Subject: [spri
Hi Bruno,
Support as author and I'm not aware of any IPR on this document
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Monday, June 29, 2015 19:22
To: spring@ietf.org
Subject: [spring] Poll for adoption: draft-litkowski-sp
Hi Uma,
Pls find inline comments.
-Original Message-
From: Uma Chunduri [mailto:uma.chund...@ericsson.com]
Sent: Tuesday, June 30, 2015 20:24
To: Aissaoui, Mustapha (Mustapha); DECRAENE Bruno IMT/OLN
Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis...@ietf.org list;
Stefano Prev
Using an offset may be dangerous as if your network growth your algo1 SIDs may
collision with algo2 SIDs because the offset is no more enough ... (you always
need more ...) using an offset is similar to splitting the SRGB in 2 SRGBs with
the limitation of not being able to extend the first part.
Hi Tarek,
I think per-prefix granularity is still possible.
Advertising a SRGB for a particular algorithm does not mean that all the
prefixes advertised will be advertised for that particular algorithm.
I mean considering you have a network with node A ,B, C, D, each one
advertising a loopback.
Hi Tarek,
More inline
-Original Message-
From: Tarek Saad (tsaad) [mailto:ts...@cisco.com]
Sent: Tuesday, July 21, 2015 23:45
To: LITKOWSKI Stephane SCE/IBNF; cbow...@juniper.net
Cc: spring@ietf.org
Subject: Re: New Version Notification for
draft-bowers-spring-adv-per-algorithm-label-bl
Hi Les,
Inline comments
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, July 21, 2015 22:59
To: LITKOWSKI Stephane SCE/IBNF; Jon Mitchell; Chris Bowers
Cc: spring@ietf.org
Subject: RE: [spring] FW: New Version Notification for
draft-bowers-spring-adv-per-algorithm-label-
Support, not aware of any IPR
-Original Message-
From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of John G.Scudder
Sent: Wednesday, July 22, 2015 15:17
To: spring@ietf.org
Cc: m...@ietf.org
Subject: [mpls] working group adoption call for
draft-filsfils-spring-segment-routing-ldp-inter
Support
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of John G.Scudder
Sent: Wednesday, July 22, 2015 15:15
To: spring@ietf.org
Subject: [spring] working group adoption call for
draft-filsfils-spring-segment-routing-central-epe
Dear WG,
As we discussed at
Hi WG,
In the current version of the config Yang model for SR, the SRGB list is
configured at SR top level, so it is agnostic to the routing protocol.
We had some comment in Dallas on difficulties that having common label range
shared between protocols could lead to.
During discussion in our des
Hi Chairs,
I currently have some issue with the anycast section of the draft. Based on the
discussion we had during the WG session (through Pushpasis's presentation), it
looks that the anycast section is not enough explained (what is the problem
behind ...) and using a "MUST" for mandating "co
Hi all,
What if we keep the SRGB block config in "segment-routing" global module, and
if we allow for YANG configuration of carving this block inside each protocol
(maybe as a feature) ?
Stephane
From: Uma Chunduri [mailto:uma.chund...@ericsson.com]
Sent: Friday, July 24, 2015 16:59
To: Les G
As mentioned by others, there may be some operational gain.
IGP migration example given is a good example, today with pure IP, there's some
tricky cases because we need to manage it with admin distance and their may be
some differences in best path computation between IGPs (implementation
depend
Hi Stefano,
The new text for anycast fits perfectly my previous comment.
Best Regards,
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stefano Previdi
(sprevidi)
Sent: Friday, July 31, 2015 09:55
To: spring@ietf.org
Subject: [spring] Fwd: New Version Notifi
Looks that consensus is for option#2, so let's move SRGB to protocol
configuration.
From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com]
Sent: Friday, July 31, 2015 08:04
To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-s
Hi,
We come back to the same discussion for MT as for per algorithm SRGB. Do we
need for operational reason the same index value to be configured for different
algorithm or topologies ?
IMO, it is useful operationally otherwise adding a topology or algorithm would
be painful ... Adding a new in
Hi Eric,
Regarding MT case, §3.2 states :
" A single Prefix-SID is allocated to an IGP Prefix in a topology.
In the context of multiple topologies, multiple Prefix-SID's MAY be
allocated to the same IGP Prefix (e.g.: using the "algorithm" field
in the IGP advertisement as described in I
Hi Peter,
Inline comments
Stephane
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, August 19, 2015 09:53
To: LITKOWSKI Stephane SCE/IBNF; Pushpasis Sarkar; Eric Rosen; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain
Steph
Hi Peter,
>> 1. If a new topology is added by use of the MT features of an IGP,
>> then a new set of prefix-SIDs must be provisioned. This seems like a
>> major provisioning task. The alternative would be to have an SRGB per
>> topology; then when you add a new topology, you only have one qua
Hi Peter,
As I already pointed to Les, using an offset creates some holes in index space
that we need to manage when extending a block.
Let's say that we have SRGB [100-199] (to simplify) and you divide your block
in two so you will have topology #1 using [100-149] and topology #2 using
[150-1
I agree that in the second case the index is scoped (to a topology or algorithm
or whatever …).
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Tuesday, August 25, 2015 15:59
To: Robert Raszuk; Peter Psenak (ppsenak)
Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; Pushpasis Sarkar
(psar
Hi,
As you shown, different deployments mean different constraints, so I think we
all agree that supporting both (using same SRGB or different SRGB per protocol)
is required, and it would be up to the user to choose the best option based on
its design.
Brgds,
Stephane
From: Les Ginsberg (gi
Hi Pushpasis,
I just want to remember that the discussion is not only for MT, but there was
also a thread for per algorithm SRGB (as presented in Prague). IMO, there must
be some consistency in the choice we do.
Regarding encoding nothing is impossible (as example a new subTLV can be
created en
Hi Peter,
Yes I need to allocate a new SRGB, but my index space will be contiguous and I
will be able to use the index 51 in each scope.
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, August 26, 2015 09:28
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen;
Hi Peter,
There are some mix between SIDs and labels in your text.
Some comments inline
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, August 26, 2015 10:43
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar; SPRING WG
Subject: Re: [spr
Hi Les,
IMO, backward compatibility mean that we are compatible with the old flavor
functionality.
Let's assume that we create a new subTLV that will override the current SR
capability subTLV (just as example). The new subTLV will contain encoding for
per algo, per topo SRGB. I think we can def
Hi,
Just to know, is there some implementation today supporting MT for SPRING ? The
other point is : if yes, does someone use it in a live network ? If no, there
is no issue to change.
I agree that a migration is not easy, but coming back to previous sentence,
honestly I think no one use MT SPR
Hi Les,
I completely agree that consensus is not achieved yet, no worry. The only
consensus we have is on per IGP instance SRGB support.
But as the discussion moved to encoding issue, I just wanted to highlight that
it may not be an issue.
Anyway, yes, we need to find a consensus.
Best Regards,
Hi,
I'm not aware of any IPR
-Original Message-
From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of John G. Scudder
Sent: Wednesday, July 22, 2015 15:12
To: spring@ietf.org
Cc: i...@ietf.org; m...@ietf.org; 6...@ietf.org; o...@ietf.org
Subject: [mpls] working group last call for draft-
Hi,
In addition to Bruno's point a) about the consequences, it would be good to
have (maybe in the intro), what are the objectives of the conflict resolution.
We already have a statement saying that we want to avoid forwarding loops which
is good, but IMO, it may be good to agree and state that
Hi Bruno,
And best wishes all for this new year.
It seems that posting your txt back as attachment to the list does not work so
I will put my comments on the text directly in the email :
- In §2.2 : you keep the statement "The following ranges are used:" empty, may
be it would be better to ch
Hi Les,
Happy new year.
I agree with your proposal.
The text must state that there must be a local configuration mechanism that
avoids sender to originate overlapping SRGB.
In this case, as you mention, if a router receives overlapping SRGB, this is a
bad behavior and we cannot guess if the fo
Hi Les,
Pls find more inline.
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, January 05, 2016 00:34
To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB
INCONSISTENCY
Stephane -
Hi Robert,
Regarding SRGB management, it’s really a design choice. There was already some
discussion in the past.
If people/implementations uses a global SRGB which is agnostic to protocols,
cross protocol validation does not really make sense.
If people/implementations uses per protocol SRGB, c
Hi Les,
Yes we come back to the Yang discussion :)
I think the text you pointed is no more valid, as the consensus was to
authorize per protocol configuration as a feature. I think we missed to update
this definition part when we updated the model.
Here is the augmentation for ISIS :
augment /
So we agree that you can't write a draft to define SRGB errors as those are
local design choices. Done with that :)
[SLI] Yes, see my reply to Les ☺
As far as "SID conflict" I am not sure I would agree too ... if I can tunnel to
an anycast IP address why I can not tunnel to anycast SID - configu
Why not ... but in this case why also having Node-SID bound to a prefix ? Today
Anycast and Node-SID are all a subcase of the IGP Prefix SID, so bound to a
prefix.
I agree that there is no real need to bind them to a prefix as long as we can
still compute the path towards the SID (now we inherit
Fully agree but this is not the choice that has been made at the beginning. Do
you want to propose a change ?
From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, January 08, 2016 15:26
To: LITKOWSKI Stephane SCE/OINIS
Cc: Stewart Bryant; Les Ginsberg (gins
Hi,
Fully agree with Les statement, as long as a sender MUST NOT sent overlapping
SRGB for a particular protocol, if a node receives overlapping SRGBs in a LSP,
it cannot really predict the behavior of the sender when it will receive a
packet using those SRGB. The only thing the receiver knows
Hi Les,
BGP needs also to be taken into account : draft-ietf-idr-bgp-prefix-sid.
IMO, as I already pointed, it would be easier to handle it a single document
rather than in the protocol docs. Moreover we will have the sender part in many
docs, and the receiver part in the spring-conflict-resol
[Les:] Just to be sure I understand you, you are advocating putting the SRGB
sender behavior specification in draft-ginsberg-spring-conflict-resolution as
well as the receiver behavior?
Sender behavior HAS to be specified in the protocol documents as it describes
the normative behavior of the pr
Hi Stefano,
My worry is that tomorrow we will have a new protocol, and this KEY piece may
be forgotten because nothing tells that this is required... and this is a cross
protocol behavior that we want.
I'm fine to have it in the protocol as far as we have a more global document
telling that all
So I think we have an agreement by duplicating the sender requirement in the
conflict draft.
-Original Message-
From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
Sent: Thursday, January 14, 2016 18:39
To: LITKOWSKI Stephane SCE/OINIS
Cc: Les Ginsberg (ginsberg); DECRAENE Brun
Hi Les,
Many thanks for the text proposal.
I agree on most of the proposal expect :
" When
the procedures defined in [SR-MPLS] for mapping global SIDs to
outgoing labels are followed the advertising node is determined to be
incapable of supporting all global SIDs."
The statement is not t
Hi Les,
I agree that SR-MPLS is authoritative regarding the described behavior and the
text in SR-MPLS draft is clear to me. But the sentence I pointed reintroduce an
ambiguity.
So solutions :
- we keep the sentence but aligning it to what SR-MPLS describes. But I agree
that this is redundant.
Hi Les,
The new text proposal looks good.
Thanks,
Stephane
-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, February 03, 2016 00:03
To: LITKOWSKI Stephane SCE/OINIS; Stefano Previdi (sprevidi)
Cc: DECRAENE Bruno IMT/OLN; spring@ietf.org; Um
+1
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Thursday, April 14, 2016 09:51
To: spring@ietf.org
Subject: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call
Dear WG,
As we discussed at our meeting last
Hi Les,
Administrative distance (protocol preference) has always been used in router
implementation for a while. Yes inconsistent configuration of admin distance
can cause routing issues (loops or whatever ...). I'm not sure we can really
bypass it ...
Regarding the preference algorithm, the SR
Hi Les,
Some comments inline
Thanks,
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, July 01, 2016 02:14
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution
Stephane -
From: stephane.litkow...@o
Hi,
I'm not aware of any IPR for this doc.
Brgds,
Stephane
-Original Message-
From: John G.Scudder [mailto:j...@juniper.net]
Sent: Sunday, July 24, 2016 14:52
To: draft-ietf-spring-segment-routing-m...@ietf.org
Cc: spring@ietf.org
Subject: IPR for draft‐ietf-spring-segment‐routing-mpls
Support
-Original Message-
From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of John G. Scudder
Sent: Sunday, July 24, 2016 14:39
To: spring@ietf.org
Cc: m...@ietf.org
Subject: [mpls] WG adoption requested for
draft-psarkar-spring-mpls-anycast-segments
Dear WG (and cc MPLS, please incl
Hi,
I have been selected as Shepherd for this document, and as part of my review I
have several comments that you will find below :
General :
Is it a requirement document ? If yes, it would be good to mention it. The
document states requirements multiple times.
Abstract :
The abstract is real
Hi Authors,
Could you please check the comment's below so we can continue to progress the
document ?
Thanks !
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
stephane.litkow...@orange.com
Sent: Monday, August 22, 2016 15:14
To: draft-ietf-spring-resiliency-use-ca...@ietf.org
Cc: spr
Hi Stefano,
Thanks for the great improvments in the text.
Few more comments :
§2 :
I still have an issue with : "the two paths are installed in the forwarding
plane of A."
This works for sure, and in this case it would be good to mention that paths
are working in a FRR approach providing sub-5
Hi Stefano
Answers inline
Best Regards,
-Original Message-
From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
Sent: Thursday, September 22, 2016 18:18
To: LITKOWSKI Stephane OBS/OINIS
Cc: SPRING WG
Subject: Re: I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt
Hi Ste
Hi Stefano,
Thanks for the updates, it's fine for me . I just noted that you finally kept
the name "Shortest path based protection".
If that's your preference I'm fine.
I will complete the shepherd review in the next couple of days.
Best Regards and thanks again,
Stephane
-Original Messa
Hi,
As Stefano mentioned, as it's a use case and requirement draft, we do not have
to talk about solutions, and about issues in using one or other mechanism.
Such considerations about using or not some particular SIDs to fill the "path
must not be protected by any local repair" constraint are up
Hi,
Expressed this way I agree that this is an interesting additional requirement
for the draft.
Best Regards,
Stephane
-Original Message-
From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
Sent: Tuesday, September 27, 2016 14:41
To: LITKOWSKI Stephane OBS/OINIS
Cc:
We are in sync.
-Original Message-
From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
Sent: Tuesday, October 04, 2016 11:37
To: LITKOWSKI Stephane OBS/OINIS; Alexander Vainshtein
Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky;
draft-ietf-spring-resiliency-use-ca...@ietf
Hi,
Just to let you know that the Shepherd's write up is available at:
https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/shepherdwriteup/
AFAIK, we are still missing Pierre Francois' IPR answer, I did not receive any
answer even after multiple reminders sent.
Brgds,
Step
Hi,
Seems my reply was missing, sorry for that.
I'm not aware of any IPR that hasn't been disclosed already.
Brgds,
-Original Message-
From: John G.Scudder [mailto:j...@juniper.net]
Sent: Sunday, July 24, 2016 14:49
To: draft-ietf-spring-segment-rout...@ietf.org
Cc: spring@ietf.org
Subj
Support
-Original Message-
From: Martin Vigoureux [mailto:martin.vigour...@nokia.com]
Sent: Friday, January 27, 2017 12:05
To: spring@ietf.org
Cc: draft-ietf-spring-segment-routing-m...@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-06
Hello Working Group,
Thi
Hi Stefano,
Speaking as doc Shepherd, I do not see in the V09, how you are addressing Lou's
point about 1:1 and 1+1 protection in the Section 2.
I think it make sense to add a simple explicit statement that SPRING should
support both approach. It is partially addressed by " The two paths may be
Hi,
I think there is a misunderstanding on what the text says:
“ A first protection strategy consists in excluding any local repair
but instead use end-to-end path protection where each SPRING path is
protected by a second disjoint SPRING path. In this case local
protection MUST NOT be
Hi Les,
There is something unclear to me here.
Let's say we have the following entries:
OSPF mappings:
(192,10.0.0.1/32,100,1,0,0)
(128,10.0.0.1/32,200,300,0,0)
ISIS mappings:
(192,10.0.0.1/32,300,1,0,0)
(128,10.0.0.1/32,400,300,0,0)
There is a prefix conflict here because we have 4 SIDs for 10
No it's not, it's definitely not enough precise.
Telling that you include all the entries (from all protocols) in the conflict
resolution does not mean that cross protocol info may be used when programming
the FIB. That's a different story.
And speaking as an operator, from a troubleshooting po
Hi,
In the current version of the draft, conflict evaluation does not look at the
SRGB, it only looks at SIDs.
In any case, in the given example, there is a prefix conflict => multiple
SIDs/labels associated to a single prefix.
>From an LFIB point of view, as per the current draft, only a singl
Hi Les,
I think there is a fundamental disagreement here.
"SR Global Block (SRGB): local property of an SR node. In the MPLS
architecture, SRGB is the set of local labels reserved for global
segments."
We agree that the SRGB is a per node property, but a per node+per protocol SRGB
is stil
Hi,
Yes today we do not have any CLI command on any router to get paths statistics
for LDP (I mean Ingress to Egress) as LDP is based on MP2P LSPs, so a transit
node does not have the knowledge of the source. From an operational point of
view, what we do today is that we collect netflow statis
Hi Loa,
We are ready to go with the current version.
Brgds,
-Original Message-
From: Loa Andersson [mailto:l...@pi.nu]
Sent: Sunday, January 28, 2018 08:15
To: m...@ietf.org
Cc: draft-ietf-mpls-spring-entropy-la...@ietf.org; mpls-cha...@ietf.org;
spring@ietf.org
Subject: Closed -- wor
Hi,
I’m worrying that MPLS based SFCs may slowdown implementations of NSH.
Vendors have usually a limited bandwidth to implement new features especially
when the dataplane is involved. I would personally prefer to get the resources
allocated to NSH rather than MPLS based SFCs.
This is not just a
> Same approach that IETF took for EVPN with various encap options like MPLS,
> VXLAN, GENEVE,..
Well you do have the same thing with SFC/NSH, you can use any type of transport
underneath: MPLS, VXLAN, GRE,UDP,…
In your example EVPN provides the service, then you pick the transport you want.
H
For simple service chains, policy routing works fine as well (this was what was
used before bess-service-chaining has come). It becomes a nightmare when the
service chains are complex.
From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderi...@nokia.com]
Sent: Tuesday, March 20, 2018 11:3
Hi Daniel,
You may need to introduce new hardware as well for SRTE to handle the number of
labels to push.
If your hardware is flexible (network processors), there is a chance that it
can also handle NSH.
Now if you want just to use SR policies to perform a kind of service chaining,
is there s
Support
Not aware of any IPR
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Wednesday, May 16, 2018 17:20
To: SPRING WG List
Subject: [spring] Working Group Adoption Call for
draft-filsfils-spring-segment-routing-policy
Hi SPRING WG,
This email initiates a two wee
Hi,
I'm not aware of any IPR
From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Thursday, May 24, 2018 19:28
To: SPRING WG List; draft-ietf-spring-segment-routing-m...@ietf.org
Subject: IPR Poll for draft-ietf-spring-segment-routing-mpls
Hi SPRING WG,
In parallel to the WG
1 - 100 of 107 matches
Mail list logo
