Re: [spring] WG Adoption Call: draft-xuclad-spring-sr-service-programming

[Rob Shakir]

SPRING,

Thanks for the review of this document. As with the other
document, apologies for the delay in following up. Based on the mailing
list replies, SPRING will adopt this document *once the IPR poll has been
completed*.

Authors - the following contributors have not yet responded to the IPR poll:

   - D Steinberg
   - G Dawra
   - S Bryant
   - H Assarpour
   - H Shah
   - L Contreras
   - J Tantsura
   - M Vigoureux

We can't make a more pointed follow up as these contributors do not have
their addresses listed in this draft, whilst not required -- they are
appreciated for us to be able to follow up on those that have contributed
material to drafts. Your assistance with following up here would be greatly
appreciated.

Thanks,
r.

On Wed, Jun 26, 2019 at 11:13 PM Rob Shakir  wrote:

> Hi SPRING WG,
>
> This email initiates a two week working group adoption call for
> draft-xuclad-spring-sr-service-programming. This follows the discussion
> that we had in the last few IETF meetings, and particularly the focused
> discussion we had at IETF 104 regarding service chaining and SPRING.
>
> Please indicate your support, comments, or objections for adopting this
> draft by *Wednesday July 10th, 2019.* We are particularly interested in
> hearing from WG members who are not authors of this draft, and those folks
> that are willing to spend time working on this draft after adoption.
>
> We are also looking for volunteers who can provide a technical review of
> the content of the draft at a later stage of its progress through the
> working group (e.g., before WGLC).
>
> In parallel - we'll send an IPR poll to the working group and authors. The
> currently disclosed IPR can be found in the datatracker
> <https://datatracker.ietf.org/ipr/search/?submit=draft=draft-xuclad-spring-sr-service-programming>
> .
>
> Thanks!
> Rob & Bruno.
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] IETF 105 Minutes Posted

[Rob Shakir]

Hi SPRING,

Minutes from IETF 105 have been uploaded at
https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00 --
thanks very much to PK for helping take these minutes.

If there are errors or corrections, please let me know and we'll upload a
revision.

Cheers,
r.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Error Handling for BGP-LS with Segment Routing

[Rob Shakir]

Alvaro,

I think this is one of the difficulties of overloading a protocol like BGP
with different datasets -- it's not simple to say how particular attributes
are actually going to be used within a protocol deployment. This was one of
the things that was noted in 7606 -- i.e., I can make *any* attribute
really affect forwarding if I write a policy that accepts/rejects some
UPDATE based on the presence of that attribute.

In general, any topology discovery mechanism (whether used in real-time or
not) needs to define how it handles cases where it might end up with
missing information. Let's consider what the different mechanisms for
discovery we have are today:

   - IGP listening -- in this case, if we have some malformed IS-IS TLV,
   then we might end up discarding this information (whether it be at the
   listening node, or a device that didn't flood it earlier in the chain) --
   meaning that we know that we have some potential gap in the topology.
   - Streaming telemetry -- speaking particularly to gNMI for LSDB
   streaming encoded using the OpenConfig model, here, we are tolerant to
   getting as much information as can be parsed, and have a way to carry
   unknown TLVs (which might include those that cannot be successfully parsed)
   as binary data to the external consumer. This means that the approach is
   "as complete data as possible", but has the same characteristic that we can
   also end up having the potential to lose data.
   - BGP-LS with attribute discard -- this has some information loss, since
   we'll have some attributes that could be malformed in the input data, and
   we discard them at the receiver.

It doesn't seem to me that, given the source of the data is the IGP, and we
might have information discarded there -- that we can really guarantee
strong consistency of an off-box view of the network, since we can't
guarantee strong consistency across the IGP domain itself.

Thus, I'm not sure that the issue that is being highlighted here actually
makes a difference when we're considering the overall system design -- we
always need to deal with the fact that the view of the network at the path
computing node might not match exactly the network's current state in the
presence of malformed protocol messages. One motivation for having the LSDB
via streaming telemetry is the ability to provide such validation ("do all
nodes within my IGP domain, including listeners, have a consistent view of
the state of the network?").

If the discussion is "should we adopt treat-as-withdraw vs. attribute
discard?" -- I don't think that from the system perspective there is really
any difference between the two in this situation. We still have the same
potentially inconsistent view of the network.

For these reasons, I'd err on leaving this unchanged in the current
specification(s).

Cheers,
r.

On Wed, Dec 19, 2018 at 10:13 AM Alvaro Retana 
wrote:

> On December 18, 2018 at 6:23:19 PM, Robert Raszuk (rras...@gmail.com)
> wrote:
>
> Robert:
>
> Hi!
>
> What comes as #1 question to your points is a comparison of SR controller
> with regular BGP RR.
>
> I think it is safe to assume that error handling on SR controller would be
> no more aggressive then on RRs. So if there is error the updates may be
> dropped on the RRs itself, logged and proper NOC alarm generated.
>
> IMO this is no different regardless if you use SR with BGP-LS or just
> plane regular BGP routing.
>
> In general, I agree that error handling should be the same regardless of
> the type of BGP speaker (RR, controller, PE, whatever).
>
> So unless your goal here is to point out the deficiency of BGP error
> handling RFC I am not sure what is so specific to BGP-LS and SR.
>
> No, the goal is not to point at any deficiency in the error handling RFC.
> I just replied to Bruno saying: " I don’t want to rehash the discussion
> from rfc7606 about the types of approached and whether there should be more
> or not (or what those could be)…. I’m just pointing out that I think the
> current approach is not the right one for all applications.”
>
> When BGP-LS was defined, it was noted that the "information present in
> this document carries purely application-level data that has no immediate
> corresponding forwarding state impact..”  I think that SR has a direct
> impact on the forwarding state of the network.  That is what is specific
> about BGP-LS+SR.
>
>
> To be clear, this thread is about using BGP-LS with applications that have
> an impact on forwarding/route selection in the network, like SR (Bruno
> pointed at lsvr and there may be others).  It is not about about the error
> handling approaches (rfc7606) or BGP sessions in general…just that specific
> application.
>
> Thanks for helping me clarify what I mean.  Hopefully this makes more
> sense. ;-)
>
> Alvaro.
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>

Re: [spring] Agenda Uploaded for IETF 103

[Rob Shakir]

Folks --

Please remember to send your slides prior to the meeting. Per Bruno's note
below, we'd like them by 17:00 to guarantee they are available for your
presentation.

Cheers,
r.



On Mon, Nov 5, 2018 at 12:10 PM  wrote:

> Speakers,
>
>
>
> We are meeting Wed. morning.
>
>
>
> Please send your slides to the chairs by Tuesday 17H00. Before is better.
>
>
>
> Please remember that your agenda time is total time for both presentation
> and WG questions. e.g., a 10 slides deck for a 10 minutes slot is probably
> too much.
>
>
>
> Thanks,
>
> --Bruno
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Rob Shakir
> *Sent:* Friday, October 26, 2018 9:01 AM
> *To:* SPRING WG List
> *Subject:* [spring] Agenda Uploaded for IETF 103
>
>
>
> Hi SPRING WG,
>
>
>
> The agenda for the SPRING working group session at IETF 103 has been
> uploaded to the datatracker
> <https://datatracker.ietf.org/meeting/103/materials/agenda-103-spring-00>.
>
>
>
> Again, we were oversubscribed for this session - with approximately 190
> minutes of requests for the two hour slot. The majority of these drafts
> have not been discussed in any detail on the mailing list -- making Bruno
> and my job somewhat harder!
>
>
>
> Given the oversubscription, our slots are short -- please focus your
> presentation on the changes to your drafts, or open items that the working
> group needs to consider for the work.
>
>
>
> Apologies if you did not get a slot -- however, this is even more reason
> to start a thread with what you would have presented on the list!
>
>
>
> See you in Bangkok,
>
> -- Bruno and Rob.
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Comments on draft-filsfils-spring-sr-policy-considerations-01

[Rob Shakir]

Ketan, Authors,

Thanks for the update. Further responses are in-line marked [rjs].

My key feedback here is that I feel like we're not really on the same page
as to what this draft is trying to communicate. Perhaps if we agreed this,
then it'd be clearer what the right direction for the document is.

I'd really encourage the WG to read this doc and provide the authors with
feedback -- especially if you have an implementation, or are implementing
SR-TE Policy in your network.

On Thu, 18 Oct 2018 at 19:10 Ketan Talaulikar (ketant) 
wrote:

>
>
>- (2) What is the intention of the diagram shown in this section? It
>seems to be completely an implementation detail that an implementation has
>the "SRPM" that acts as a central resolution point. For instance, what
>should a reader learn from the fact that the SRPM is not a standard RIB
>resolution process? If there are suggestions that one wants this
>implementation - should there be some discussion of the complexity of this
>new API between say, the BGP daemon and a general RIB process?
>
> *[KT] **We will clarify in the text that the section provides a
> conceptual overview of components/functionality that work with each other
> to implement SR Policy on a headend. The intention is not to define APIs
> between the blocks since those are implementation details. We have several
> drafts related to the SR Policy functionality – besides the architecture
> draft, there are extensions to BGP (BGP-SRTE & LS), PCEP then we have Yang
> model. This draft puts these blocks into reference so implementers get an
> idea of the functionality that maps to say BGP and the SR Policy processes
> (e.g. draft-ietf-idr-segment-routing-te-policy).*
>

>- (2) My general feedback on this section is that this is
>implementation discussion, that does not add to the IETF content that we
>are publishing within SPRING. Like we have had discussion of use case
>drafts, I think this is similar but from the implementor side. I'd like to
>discuss the value that this content has.
>
> *[KT] **There is a difference between documenting implementation details
> and providing a conceptual overview of the implementation aspects.
> Especially when defining an architecture which involves multiple protocols
> and functional blocks. I find it valuable as an implementer myself.*
>

[rjs] I don't think that the edits that are made to this section
particularly add anything. If the intention is the conceptual overview, I
don't understand why we refer to say, the "SRP process". Conceptually,
shouldn't this be describing interaction between functional blocks? i.e.,
we have a functional block in the architecture that is responsible for
learning candidate paths (it's an implementation detail from where...), and
selects the active path, installing it into the RIB or FIB.

If the intention is to have this be conceptual, my suggestion would be to
make the language refer to architectural concepts - rather than what seem
to be realisations of the idea, and to convert the diagrams into lists that
describe what each block is doing. Others may have thoughts on this too -
especially where they have other implementations.


>
>- (3.1) I think that this section has some useful content, but it's
>buried by starting out by defining the algorithms.. Why not make this
>section be focused towards the constraints that must be considered when
>calculating a SID stack for a particular path. i.e., the key points seem to
>be:
>
>
>- Use of the IGP metric as the metric for path optimisation is
>   desirable, especially in constrained push or readable depth 
> environments,
>   because it allows the minimum number of deviations from the shortest 
> path
>   and therefore labels.
>   - If a different metric is used, then this implies that every time
>   that metric differs from the IGP metric, then this will result in
>   additional SIDs.
>
>
>- There is no mention of flex-algorithm in this section. It seems
>  relevant given that you can also mitigate the problem that is trying 
> to be
>  solved here by having a set of prefix SIDs per metric.
>
> *[KT] **We will put a forward reference to the Flex Algo section here.*
>
>- It may be advantageous to sacrifice optimality of the path
>   calculation solution by relaxing the optimisation constraints.
>
>
>- The draft should talk about the operational considerations here -
>  i.e., it implies that you can actually tolerate the margin in the
>  optimisation objective for the service.
>  - The "just pick the best you can do within N SIDs" is
>  dangerous, since it means that the network delivers a service that 
> *isn't*
>  what the operator asked for - which may result in service degradation
>  (e.g., consider live/live where there is a maximum latency 
> difference that
>  is tolerable between the two feeds).

Re: [spring] [Editorial Errata Reported] RFC7855 (5384)

[Rob Shakir]

iff is common language in most technical/academic documentation I believe.
Whilst I am sympathetic to wanting to ensure that RFCs are as easy to parse
as possible for as wide an audience as possible I think that we have to
have some level at which we assume the reader can refer to external
references should they not be familiar with the terminology used. The RFC
Editor team is good at keeping authors honest around this bar.

James - I would encourage you to review the documents that are in last call
in the working group for these kinds of clarifications if you have time
please. Making these edits before we cut an RFC is preferable.

Thanks!
r.

On Mon, Jun 18, 2018, 12:30 AM James Bensley  wrote:

> On 8 June 2018 at 09:58, Adrian Farrel  wrote:
> > James,
> >
> > I believe "iff" was intended as written.
> >
> > https://en.wikipedia.org/wiki/If_and_only_if
> >
> > Adrian
>
> Hi Adrian,
>
> That seems like a handy acronym and I'm not against it's use. I'm just
> questioning how commonly used it is in networking circles and thus,
> whether this document should have a glossary or not? After a quick
> scan of "recent" RFCs it's not in common use (only one other RFC apart
> from this one);
>
> $ for i in `seq 5000 8500`; do wget
> "https://www.rfc-editor.org/rfc/rfc$i.txt;; done
>
> $ grep " iff " *.txt | awk '{print $1}' | uniq
> rfc7242.txt:
> rfc7855.txt:
>
> Cheers,
> James.
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Rob Shakir]

Zafar,

I intentionally left the list of milestones out of the mail. Clearly, we
need to agree the areas of work before we can break this down into
milestones. Equally, we have more flexibility in defining these since they
do not need to be reviewed by the IESG.

On Wed, Jun 6, 2018 at 12:14 PM Zafar Ali (zali)  wrote:

>
>
> At IETF101, you and Bruno presented a slide based on the WG feedback on
> the mailing list (
> https://datatracker.ietf.org/meeting/101/materials/slides-101-spring-00-chairs-slides-01).
> During the Spring meeting, the WG agreed to add milestones to those items.
> In general, I see some milestones are not included in the proposed
> chartered text.
>
>
>
> Specifically, multicast in SR is included in that list with the "Ingress
> replication SID (Tree SID /spray)" bullet (and support during the WG
> meeting) but is missing in the proposed charter text. So, I agree with
> Xiejingrong and Michael highlighting the same. There is already interest
> and agreement shown by the WG to include multicast in SR in the charter.
>

This list was a recap of what had been discussed on the mailing list. It
was not the proposed exhaustive list. The preference in the charter text
(after much discussion) is to ensure that SPRING has a set of focus areas
to work on. This does not preclude interested individuals doing other work
- and even bringing it to SPRING. We can change the charter in the future
if new work comes up that isn't within the charter.

I would point out that the narrow scope that we (the SPRING WG) initially
had to deliver on has taken almost five years since we initially discussed
it (see this thread

regarding chartering STATUS as it was at the time). In this period of time,
real deployments of SR have happened, and the standards that they rely on
have not yet been published.  This is unfortunate for those that have
shipping implementations, or are relying on behaviours in their network.

I'd encourage us to focus on defining the problem spaces that are most
important and then work on those, deliver a standard, and then move on to
the next area. We can usually determine the importance/relevance of the
work to networks based on the number of interested parties - so the
intention of the list in the charter is to capture those elements which we
perceived to have widest interest in the charter. At some point, there will
be a line that is either "in the charter" or not, and some things below it
at the current time - yes, that might mean that one's favourite SR
application is not currently in the charter, but if there is significant
discussion on the list, and work items being brought as individual drafts,
we can always address this with Martin.

Thanks,
r.

>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Rob Shakir]

Michael,

Thanks for the comment.

On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
wrote:

> It would be helpful, while updating the charter, to state whether
> multicast in SR is in/out of scope in order to know which wg to take our
> future work.
>

I think this is impractical. If we state everything that is in or out of
scope, we'll end up with a laundry list. The aim of the charter is to
define clearly the work that the WG should focus on. It does not mean that
we can never host discussion of individual drafts if they are relevant. If
there are requirements, we can always recharter if something new becomes
the highest priority for the industry w.r.t SR.

Kind regards,
r.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] New spring WG Co-Chair

[Rob Shakir]

Thanks Alvaro and Wim — looking forward to helping progress SPRING :-)

r.
On Wed, Feb 21, 2018 at 11:54 Henderickx, Wim (Nokia - BE/Antwerp) <
wim.henderi...@nokia.com> wrote:

> Welcome on board Rob
>
>
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Alvaro Retana <
> aretana.i...@gmail.com>
> *Date: *Wednesday, 21 February 2018 at 13:41
> *To: *SPRING WG <spring@ietf.org>
> *Subject: *[spring] New spring WG Co-Chair
>
>
>
> Dear spring WG:
>
>
>
> As all of you already know, Martin has been selected as a Routing AD
> starting next month at IETF 101 in London.  He will step down as spring
> co-chair then.  Martin: thank you for the focused effort you have dedicated
> to this WG — we all look forward to working with you in your new role.
> Congratulations!
>
>
>
> In consultation with Bruno and the other ADs, we have asked Rob Shakir to
> take on the role of spring Co-Chair.  Rob currently works at Google and has
> been a long time participant in the IETF.
>
>
>
> I am adding Rob as a third Chair to facilitate the transition.  The
> expectation is that he will fully take over for Martin at IETF 101.
> Welcome Rob!
>
>
>
> Rob can be reached at ro...@google.com.
>
>
>
> Thanks!
>
>
>
> Alvaro.
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

[Rob Shakir]

Bruno, SPRING,

I am aware of at least one implementation that makes heavy use of Binding
SIDs, so I do not think that this is something that we can remove from the
protocol specification. It seems to me that we have a number of cases that
continue to exist that make it useful to have them specified, particularly:

   - Binding of a SID to a deeper label stack to prevent there being large
   label stacks required on ingress. This is required due to limited push
   depth, and limited readable label depths for hashing.
   - Re-use of some other protocol's or network's forwarding path by a
   device that is imposing an SR label stack.

There is not an alternative construct that can be used for this purpose, so
we should not remove it.

In both of these cases there seems, to me, to be a use case for having the
information in the IGP in the case that an implementation computes TE paths
using cSPF, having binding SID information available to it (along with the
ERO) enables it to reduce the label stack depth by finding binding SIDs
that follow the same path as the computed ERO. Without the ERO (which might
not be an RSVP-TE ERO, but I believe that it how it was first envisaged)
how can the head-end of an TE path know what path the advertised Binding
SID takes? It's fine to punt this and say "the PCE in the sky will know" -
however, I believe SPRING's charter doesn't limit the technology to only
centralised computation of paths.

I don't believe current demand for this is a good reason to remove it from
the protocol specification - it is still somewhat early days for folks
deploying TE based on SR - where I think the Binding SID concept is most
important.

r.

On Mon, 12 Jun 2017 at 05:50  wrote:

> Hello SPRING WG,
>
> I'd like to encourage discussion on this thread.
>
> The related questions seem to be:
> - Binding SIDs:
> -  Is there any implementation?
> - Is it useful?
> - Does it need to be specified?
>
> - Binding SIDs advertised in IGP:
> -  Is there any implementation?
>  - Is it useful?
> - Does it need to be specified?
>
> As of today, there seem to be multiple SPRING (related) document that make
> reference (define/use) to the Binding SIDs. e.g.
> - architecture
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11#section-3.5.2
> - MPLS instantiation
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-08#section-2
> - non-protected paths
> https://tools.ietf.org/html/draft-litkowski-spring-non-protected-paths-01#section-3.3
> - SR policies:
> https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-00#section-7
>
>
> However, it also seems a priori possible to define Binding SIDs and not
> advertised them in the IGP. (e.g. by keeping them local to the PCE)
>
> On a side note, if the Binding SIDs are removed from the IGP, do they need
> to be removed from the BGP-LS extensions? [+IDR chairs]
>
> Thanks,
> Regards,
> --Bruno
>
> > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak
> > Sent: Monday, June 12, 2017 10:18 AM
>  > To: OSPF WG List; spring@ietf.org; isis...@ietf.org
>  > Cc: draft-ietf-ospf-segment-routing-extensi...@ietf.org
>  > Subject: Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions
> (would also effect
>  > OSPFv3 and IS-IS) - REPLY TO THIS ONE
>  >
>  > Hi,
>  >
>  > I would like to get some feedback on the usage of the SID/Label Binding
> TLV.
>  >
>  > Is there any implementation that uses SID/Label Binding TLV for
>  > advertising the SID/Label binding to a FEC as specified in section 6 of
>  > the draft-ietf-ospf-segment-routing-extensions-16 or section 2.4 of
>  > draft-ietf-isis-segment-routing-extensions-12?
>  >
>  > If not, do we see this as something we want to preserve in the IGP SR
>  > drafts?
>  >
>  > ISIS uses The SID/Label Binding TLV to advertise
>  > prefixes to SID/Label mappings, which is known to be supported by
>  > several implementations and that piece needs to be preserved.
>  >
>  > thanks,
>  > Peter
>  >
>  > On 09/06/17 19:04 , Peter Psenak wrote:
>  > > Acee,
>  > >
>  > > my question is whether we need the whole section 6 and the SID/Label
>  > > Binding Sub-TLV that it specifies. In OSPF Binding SID is not used for
>  > > SRMS advertisement like in ISIS.
>  > >
>  > > thanks,
>  > > Peter
>  > >
>  > >
>  > >
>  > > On 09/06/17 16:45 , Acee Lindem (acee) wrote:
>  > >> Corrected IS-IS WG alias – Please reply to this one.
>  > >> Thanks,
>  > >> Acee
>  > >>
>  > >> From: Acee Lindem >
>  > >> Date: Friday, June 9, 2017 at 10:42 AM
>  > >> To: OSPF WG List >,
>  > >> "spring@ietf.org "   > >> >, "i...@ietf.org "
>  > >> >
>  > >> Cc: "draft-ietf-ospf-segment-routing-extensi...@ietf.org
>  > >> 

Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

[Rob Shakir]

>
> As long as "mixed" use cases are not strictly prohibited in the draft (and
> this was at least one possible interpretation of the text), I do not have
> any issues with restricting it to just two "pure" use cases:
> - End-to-end path protection with disabled local protection
> - Local protection (of some kind) without end-to-end path protection.
>

Use cases drafts should never attempt to be exhaustive in terms of what
they try and cover, but provide sufficient motivation for the features that
are/were required in the technology that is developed as a response to
them. In this case, the use case of path protection - especially with
disjointness requirements - provides motivation for wanting to have a SID
in the network that is explicitly not protected by local protection
mechanisms.

In RSVP-TE, we have the ability to set the "local protection requested" bit
described in RFC4090 - which gives the head-end the ability to control the
re-route behaviour of the LSP. This use case presents the operational case
for the B-flag in the IGP extensions.

Operators can, and will continue to, deploy things that (shockingly!) are
not described in IETF use case documents. At this point, if we consider
that this document provides some explanation of the features that are
required in the protocol - let's go ahead and publish it. Due to the
different technical and business requirements of different operators,
almost certainly, someone will deploy some combination of these features,
but I do not feel that we need to describe such unknown cases within this
document.

Kind regards,
r.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

[Rob Shakir]

Hi Martin,

Support, as a co-author.

r.

On Mon, 30 Jan 2017 at 12:30 Edward Crabbe  wrote:

> Hi Martin;
>
> Support as co-author.
>
> cheers,
>-ed
>
> On Fri, Jan 27, 2017 at 3:05 AM, Martin Vigoureux <
> martin.vigour...@nokia.com> wrote:
>
> 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 the most recent
> version yet, and send your comments to the list, no later than the
> *12th of February*.
> Note that this is *not only* a call for comments on the document; it is
> also a call for support (or not) to publish this document as a Proposed
> Standard RFC.
>
> ¤ We have already polled for IPR knowledge on this document and all
> Authors have replied.
> IPR exists against this document and has been disclosed [2].
>
> Thank you
>
> M
>
> ---
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
> [2]
> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-spring-segment-routing-mpls
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING WGLC for draft-ietf-spring-resiliency-use-cases

[Rob Shakir]

On Mon, Sep 26, 2016 at 1:25 AM,  wrote:
>
>
>  > Authors: In parallel with the WGLC, please respond to this message
> (making sure you cc
>  > spring@ietf.org) and indicate if you are aware of any relevant IPR.
> Please do this even if it
>  > has been previously disclosed. Thanks.
>
> IINM, we are missing the IPR answers from Clarence, Stefano, Pierre and
> Rob.
>

 I'm not aware of any IPR on this draft.

Thanks,
r.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG adoption requested for draft‐filsfils‐spring‐large-scale-interconnect

[Rob Shakir]

Hi,

Apologies, this document uses my old e-mail address on it.

> On Jul 24, 2016, at 06:55, John G. Scudder  wrote:
> 
> Authors, please indicate whether you are aware of any relevant IPR and if so, 
> whether it has been disclosed. Also, the length of the author list for this 
> document greatly exceeds the maximum recommended. Assuming the document is 
> adopted, the authors should be prepared to correct this when submitting as a 
> WG document, ideally by reducing the list to simply the active editor(s) and 
> making use of the "contributors" section for the full list.


I’m not aware of any undisclosed IPR.

Thanks,
r.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC

[Rob Shakir]

Hi John, Bruno,  SPRING WG,

> On 24 Jul, 2016, at 6:49 AM, John G.Scudder  wrote:
> 
> As we discussed at the SPRING meeting, a second working group last call has 
> been requested for draft-ietf-spring-segment-routing. Before we begin the 
> WGLC, please indicate whether you are aware of any relevant IPR and if so, 
> whether it has been disclosed. (Please do this even if you've done it before, 
> thanks for your help.) Please cc the WG in your reply.

I am not aware of any IPR over and above that which has already been disclosed 
which is relevant to this draft.

Kind regards,
r.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Last Call: (SPRING Problem Statement and Requirements) to Informational RFC

[Rob Shakir]

Hi All,

On 6 January, 2016 at 8:21:22 AM, Martin Horneffer (m...@nic.dtag.de) wrote:

There's more than enough analyses that show that in typical carrier topologies 
traffic engineering with segment routing can achieve almost everything with 
just adding one or maybe two segments (labels).
However those analyses are not neccessarily public, nor would I think an 
Internet Draft or RFC would be a good place for this kind of information.

Maybe we should add a section to draft-ietf-spring-segment-routing-mpls saying 
that the operators are responsible for understanding the capabilities of the 
hardware they use, and to consider those when setting up their specific 
traffic-engineering tricks.
I agree with Martin here, but I also don’t really agree that there is a new 
conflict that is being raised here.

1) SR must be realisable on existing iLER hardware where there may be limits in 
terms of the number of labels that can be pushed. SPRING does not mandate a 
requirement to be able to push an arbitrary number labels - like RSVP-TE does 
not mandate any particular head-end path computation requirements. If any 
change is to be made to this document it should be to highlight that there MAY 
be operational limitations w.r.t how complex the policy specified at the iLER 
can be (_or_ optimisations may be required to map one path onto another path - 
e.g., through binding a SID to a stack of labels on another device). I find 
this quite self-evident though.

I have analysed label stack depth in a number of networks - and discussed it 
with hardware implementors in that context, and not found this to be a 
significant operational concern. The problem of publishing any analysis in this 
area is it contains information relating to topology (which may be considered 
sensitive); and to the operator’s policy requirements.

2) SR must be realisable on existing LSR hardware where there may be limits in 
terms of the depth of label stack that can be examined. SPRING is generally 
always realisable by forwarding on the outermost label (be in Node-SID or 
Prefix-SID) - in some cases, there may be a need to pop that label and forward 
on the following one (e.g., an anycast segment or where there is an Adj-SID 
that terminates on the node) which is a capability of the existing MPLS 
forwarding plane. The case of entropy is generally something that is complex, 
and the work on EL means that there is a requirement for a device to be able to 
find the ELI+EL pair in the label stack - this isn’t something that SR 
introduces. So, we should note that _as with anything that increases the label 
stack depth_, then if we have that ELI+EL deeper than where a midpoint can read 
to, then we may lose entropy. But this is no different than any other 
hierarchical LSPs that we have today - so again, I’m not sure I find this a 
necessary note.

Essentially, what is being highlighted here is that certain MPLS forwarding 
planes may have optimised for a) limited push capabilities, or b) limited 
midpoint visibility into the label stack - these are optimisations that might 
have been acceptable in some deployments in the past, and may not be going 
forward. I would really want to consider whether there is anything that is not 
already noted in RFC 7325 that has been raised here.

I also disagree that this should be in the problem statement document — this 
document tries to describe the requirements and use-cases for the SPRING 
architecture. It seems to me that if we do address these concerns, then really 
the document that they should be addressed in is 
draft-ietf-spring-segment-routing-mpls - which specifically deals with the 
realisation of the SPRING architecture in the MPLS data-plane.

r.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-ietf-spring-segment-routing-05

[Rob Shakir]

On 24 September 2015 at 09:09:00, Anil Kumar S N (VRP Network BL) 
(anil...@huawei.com) wrote:
> Hi Rob,
>  
> Thanks for reverting back the mail.
>  
> If there is a desire to control traffic flows on individual bundle interface,
> information about each of the bundle members interface is required to be 
> flooded
> using IGP extension. Segment routing framework is generic and flexible enough 
> to handle  
> this.
> IGP extension need to support it.
> […snip…]

Right - but this draft does not seek to catalogue every possible use of SR - 
since it could not possibly do this (given that some will be invented in the 
future). The examples within it give sufficient motivation for the types of SID 
that are defined which, IMHO, is their intention.

I think it would be best to finalise this document with what is there. Perhaps 
my co-authors will disagree.

r.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-ietf-spring-segment-routing-05

[Rob Shakir]

Anil,

Thanks for the mail.

On September 23, 2015 at 02:19:54, Anil Kumar S N (VRP Network BL) 
(anil...@huawei.com) wrote:
> 3.5.3. Bundle Adjacency Segments
>  
> A number of physical interfaces can be bundled to be a
> a logical interface. Adj-SIDs can be used in order to represent individual 
> member interface  
> of a logical bundle interface. The few advantages of the bundled interface 
> are expansion  
> of
> interface bandwidth, increase the link reliability and flow load sharing=

Can you expand on why you think this adds to what is said in 3.5.1? This 
document is not intended to be an exhaustive list of all of the things that one 
could do with SR, and my feeling is that §3.5.1 adequately covers the Adj-SID 
use case.

Thanks,
r.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop

[Rob Shakir]

Hi John, Bruno, SPRING & MPLS,


On July 22, 2015 at 09:17:48, John G.Scudder (j...@juniper.net) wrote:
> Dear WG,
>  
> As we discussed at our meeting yesterday, working group adoption has been 
> requested  
> for draft-filsfils-spring-segment-routing-ldp-interop. Please reply to the 
> list  
> with your comments, including although not limited to whether or not you 
> support adoption.  

As I co-author I, unsurprisingly, support adoption of this document.


> Authors, please indicate whether you are aware of any relevant IPR and if so, 
> whether  
> it has been disclosed. Also, the length of the author list for this document 
> greatly exceeds  
> the maximum recommended. Assuming the document is adopted, the authors should 
> be prepared  
> to correct this when submitting as a WG document, ideally by reducing the 
> list to simply  
> the active editor(s) and making use of the "contributors" section for the 
> full list. 

I’m not aware of any IPR.

Kind regards,
r.


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] working group last call for draft-ietf-spring-segment-routing

[Rob Shakir]

Hi Bruno, John,

Whilst I’m an author — I’ll still comment here. It would be good to see the 
SPRING WG finalise this document. Rapid progress is being made to multi-vendor 
implementations within live networks of the SPRING technology. It would be good 
to start getting documents such as this one - which underpins many of the other 
standards for SR published.

On 22 July 2015 at 14:13:06, John G. Scudder (j...@juniper.net) wrote:
Authors, please indicate whether you are aware of any relevant IPR and if so, 
whether it has been disclosed. (Please do this even if you've done it before, 
thanks for your help.) 
I’m not aware of IPR other than that which has already been disclosed on this 
document.

Cheers!

r.___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR Claims related to draft-filsfils-spring-segment-routing-mpls

[Rob Shakir]

Hi Alvaro,

On 24 Sep 2014, at 14:07, Alvaro Retana (aretana) aret...@cisco.com wrote:

 
 In parallel to the WG Adoption Call for this draft, I want to formally ask 
 the authors (no additional contributors are listed in the latest version of 
 the draft) to please respond to this message indicating whether or not you 
 are aware of any relevant IPR.  So far there are no related disclosures.  The 
 draft will not progress (pending the results of the WG Adoption Call) until 
 we have received a response from each author.

I’m not aware of any IPR which is relevant to this draft.

Kind regards,
r.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR Claims related to draft-filsfils-spring-segment-routing

[Rob Shakir]

On 24 Sep 2014, at 14:03, Alvaro Retana (aretana) aret...@cisco.com wrote:

 Hi!
 
 In parallel to the WG Adoption Call for this draft, I want to formally ask 
 the authors (no additional contributors are listed in the latest version of 
 the draft) to please respond to this message indicating whether or not you 
 are aware of any relevant IPR beyond what has been already disclosed.  The 
 draft will not progress (pending the results of the WG Adoption Call) until 
 we have received a response from each author.
 
 http://datatracker.ietf.org/ipr/search/?option=document_searchid=draft-filsfils-spring-segment-routing

Hi Alvaro,

I’m not aware of any other IPR beyond that which has already been disclosed 
which relates to this draft.

Kind regards,
r.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR Claims related to draft-ietf-spring-problem-statement

[Rob Shakir]

On 23 Sep 2014, at 19:34, Alvaro Retana (aretana) aret...@cisco.com wrote:

 Hi!
 
 In parallel to the WGLC for this draft, I want to formally ask the authors 
 (no additional contributors are listed in the latest version of the draft) to 
 please respond to this message indicating whether or not you are aware of any 
 relevant IPR.  So far there are no related disclosures.  The draft will not 
 progress (pending the results of the WGLC) until we have received a response 
 from each author.

Hi Alvaro,

I’m not aware of an IPR relating to this draft.

Kind regards,
r.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for draft-filsfils-spring-segment-routing

[Rob Shakir]

On 24 Sep 2014, at 14:01, Alvaro Retana (aretana) aret...@cisco.com wrote:

 Some additional background:  This draft presents the 'Segment Routing 
 Architecture'; it focuses on the terminology and general architecture.  
 draft-filsfils-spring-segment-routing-mpls (for which there is separate call 
 for adoption) describes the instantiation of Segment Routing on the MPLS data 
 plane.

I support adoption of this draft, it forms a good basis to describe the 
architecture of SR.

Kind regards,
r.___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for draft-filsfils-spring-segment-routing-mpls

[Rob Shakir]

Hi Alvaro,

Support the adoption of this draft.

Bruno,

I agree — it’d be good to capture (as we go forward) the additional MPLS 
requirements. We are currently iterating on a draft relating to the entropy 
label requirements, but it’d be good to give more general guidance for 
implementors going forward on these things. This draft seems like the natural 
home for such commentary.

Kind regards,
r.

On 24 Sep 2014, at 14:49, bruno.decra...@orange.com wrote:

 Hi,
  
 (as a co-author) I support working group adoption.
  
 This document defines how the SPRING architecture can be applied to MPLS with 
 existing hardware  networks and quite limited impact to MPLS sub-part (e.g. 
 OAM  loadbalancing). IMO this is a very applicable declination of the SPRING 
 architecture.
  
 More specific comments:
 - Eventually, the doc could list such “additional” MPLS requirements (e.g. 
 hardware/software ability to push more labels on the ingress, load-balancing 
 considerations in transit, OAM extensions…). Eventually in the section 8 
 “Manageability considerations” which is currently empty.
 - Last sentence of section 6 “Segment List History” is eventually historic 
 and need to be removed/updated.
 - Security consideration needs to be written. A priori, as the MPLS principle 
 are unchanged, MPLS SPRING probably does not change much the security 
 consideration of MPLS networks therefore IMO this is not blocking for WG 
 adoption. Existing doc on security may need to be referenced, e.g. RFC 5920 
 “Security Framework for MPLS and GMPLS Networks”, may be saying that as LDP 
 sessions are removed, LDP security aspects (as discussed in RFC 5036 and RFC 
 6952) no longer need to be considered.
  
 Thanks,
 Regards,
 Bruno
  
  
 From: Alvaro Retana (aretana) [mailto:aret...@cisco.com] 
 Sent: Wednesday, September 24, 2014 3:08 PM
 To: spring@ietf.org
 Cc: draft-filsfils-spring-segment-routing-m...@tools.ietf.org
 Subject: WG Adoption Call for draft-filsfils-spring-segment-routing-mpls
  
 Hi!
  
 This message officially starts the call for adoption for 
 draft-filsfils-spring-segment-routing-mpls.
  
 Please indicate your position about adopting this draft by end-of-day on 
 October 8, 2014.
  
 Some additional background:  This draft describes the instantiation of 
 Segment Routing on the MPLS data plane.  The Segment Routing Architecture is 
 presented in draft-filsfils-spring-segment-routing (for which there is a 
 separate call for adoption)
  
 http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-mpls
  
 Thanks!
  
 Alvaro.
 _
 
 Ce message et ses pieces jointes peuvent contenir des informations 
 confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
 ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
 electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere, deforme ou 
 falsifie. Merci.
 
 This message and its attachments may contain confidential or privileged 
 information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender and delete 
 this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been 
 modified, changed or falsified.
 Thank you.
 ___
 spring mailing list
 spring@ietf.org
 https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING MPLS and Entropy Label

[Rob Shakir]

Hi Robert,

On 26 Jul 2014, at 23:26, Robert Raszuk rob...@raszuk.net wrote:

 Perhaps you can expand on how an LSR programs its LFIB such that it has 
 multiple labels matched with a single entry please?
 
 ​When you install a label to LFIB you also pass its depth ie number of 
 significant bits to match on. 
 
 Hardware will treat the remaining bits as do not care. That is pretty basic 
 logical function for any match operation. 

rjs So, this is exactly akin to the description I gave of partitioning the 
label space - since it requires one to sterilise some of the label space 
(N-bits are now significant for forwarding, with the remaining (20-M) being 
used for entropy).

 At least I am quite sure it is much simpler then any other form of search for 
 ELI/EL within the SR deep stack :)

rjs The look-up logic has to change somewhat for the data-plane. Particularly 
as:

- We need to check whether the top-most label is within the block of labels 
that we are using for this function.
- If it is, we do a lookup based on the first N-bits to determine the next-hop.
- if it’s not, we need to do a lookup based on the entire label.
- If this was in the entropy block we determine the OIF by matching this 
next-hop along with the hash of the remaining (20-N) bits.
- else we fallback to the existing hashing procedures.

Alternatively, we need to:

- Look-up the next-hop based on the top-most label.
- If the ELI is in the label stack, take the following label as the EL.
- Determine the OIF based on the next-hop and the EL value received.
- if the EL is not present, then hash based on existing procedures.

Is the former “much simpler”? I am no hardware expert, but I would say they 
seem roughly analogous in terms of decision process that needs to be made - 
other than the latter needs visibility into more of the packet (such that 
ELI/EL is included in the header that is extracted). 

It’s notable that the latter logic must be implemented anyway at an LSR, 
because we have now standardised ELI/EL and it is implemented.

 I’m struggling to comprehend how this fits into the existing implementations, 
 or can be realised without requiring some forwarding/entropy split of the 
 20-bit label as I described before.
 
 ​The split I have in mind is passed explicitiely in control plane. So there 
 is no additional logic required for it. ​
 
 ​Now you may rightfully state that this requires an upgrade. Well true but 
 any alternative discussed here requires an upgrade as well. Moreover even 
 support of SR requires an upgrade :)
 
 Control plane vs data plane .. EL based solution requires both day one. Label 
 mask does not strictly require any data plane change during the transition 
 period as it could install all atomic labels till the mask support in LFIB is 
 available later.
 

rjs In smaller nodes (aggregation/access nodes) then this might have 
significant impact, given LFIB limitations. If we need to have M*(number of 
destination FECs) installed in the LFIB then this might bust some limits.

Whilst label mask is a potential solution, my view is that we should continue 
to leverage the EL work already done by this WG.

Kind regards,

 Cheers,
 R.​
 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING MPLS and Entropy Label

[Rob Shakir]

Hi Sri!

Thanks for the feedback.

On 23 Jul 2014, at 02:40, Sri sriganeshk...@gmail.com wrote:

 Sri You are correct. If a SID identifies multiple physical paths as in the 
 case of Adj-SID identifying a bundle, then load balancing on that segment 
 would be useful. When there is no information that every SID of a LSP maps to 
 a single physical path, a load-balancing mechanism should be used for that 
 LSP. I agree that today there is no mechanism to give such information about 
 the mapping, so load balancing on every segment is useful. Whether that is 
 achieved by using an EL per segment as described in sec 3.2 thereby resulting 
 in a label stack of 3*#SIDs is something to be discussed. The draft lists the 
 downsides of choosing that option. 
  
 
   I think that the above means that the current draft under-estimates the 
 depth
   of the stack when considering an EL per tunnel (§3.2), which might amplify
   some of the concerns raised for this option.
 
 
 Sri The draft does not estimate stack depth (without EL) since the depth is 
 dependent on the degree of strict-hop traffic-engineering desired by the 
 application. If you meant to say that the label stack is deep due to the 
 application trying to make it as close to the desired physical path but you 
 end up using the EL per segment anyways since there isn't information to 
 determine for sure whether the mapping is to a single physical path, then yes 
 the label stack will be very deep. 

rjs Absolutely. The point that I think is important here is that in the case 
that we have:

src-[ A ] -- [ B ] -- [ C ] -- [ D ] -- [ E ]-sink
\|/
 --[ F ] -

And we have a strict requirement for A-B-C-D-E, then whilst it might 
immediately look like we could specify:

SA{B},SB{C},SC{D},SD{E},SE{sink} [5 labels]

then actually, the requirement for EL per tunnel is now:

SA{B},ELI,EL,SB{C},ELI,EL,SC{D},ELI,EL,SD{E},ELI,EL,SE{sink},ELI,EL [15 
labels]

The example that you have in the document makes the case look somewhat better 
than this. As you say, this is because the application that is chosen in the 
example is somewhat less strict with its path placement requirements, and a 
number of the labels in the stack are associated with services. A reader could 
easily conclude that since the strict src-A-B-C-D-E-sink path that is 
chosen has affinity to individual adjacencies, this concern does not apply, but 
to deal with the fact that things are bundles/LAGs, then I think it does. 

It’d be great if we could patch the wording (happy to help contribute) to 
provide some wording that says that applications that already produce deep 
label stacks would produce even deeper label stacks with this option AND we 
know that there are limitations with the number of labels that can be pushed by 
real h/w today.

 Sri This is correct. In case of re-routing from ingress, the algorithm to 
 compute EL depths have to be re-computed. If the re-route is like FRR via a 
 bypass LSP, the PLR may want to insert ELs if load-balancing is desired along 
 the bypass. 
 
 
   In terms of discovery of the capabilities of a mid-point -- do we need to
   consider how, in a multi-area network, we discover the capabilities of a
   mid-point which might not have information about it leaked between areas?
 
 Sri Option in 3.4 runs into such complications in case of multi-area. All 
 such cases have not been addressed yet for the option in 3.4

rjs Sure — it would potentially be good to note this as a downside. Especially 
if there’s no clear solution other than leaking information between areas, 
since this has impact on operator’s network designs today.

  - Finally, it'd be good to determine what the intention of the authors for 
 this
   document is. Do we expect that we make a recommendation as to what equipment
   vendors who are going to support SR-MPLS should optimise for? At the moment,
   the document is good at classifying the different approaches that _could_ be
   taken, but potentially requires an operator/vendor to consider optimisation
   for both a) reading very deep into the stack when acting as an LSR, b) 
 pushing
   very deep stacks when acting as iLER, c) potentially implementing more 
 complex
   swap() operations, whereby some reshuffling of the EL is required.
 
   My feeling is that it would be very useful for this document to be able to
   make a clear recommendation as to which of these approaches should be
   optimised for, and hence we should debate their technical efficacy. It'd be
   good to understand whether the authors are intending to do this, or rather
   classify the approaches.
 
 Sri The first goal of the draft was to list the various approaches. But the 
 final goal is to come up with recommendations through the discussions on the 
 various approaches.

rjs Great — aligned with this, I think there would be some utility to adding 
another option, which is that where there are ECMPs that can be 

Re: [spring] SPRING MPLS and Entropy Label

[Rob Shakir]

On 22 Jul 2014, at 11:05, Xuxiaohu xuxia...@huawei.com wrote:

 It makes no sense of making that compromise, IMHO. It seems that the most 
 feasible way is to allow operators themselves to make the choice among these 
 options according to their network conditions.

Such a recommendation does not have to say that this is the ONLY solution that 
can be used. However, it is very likely that a number of operators have a 
common set of limitations (given that we know there are commonalities in 
deployed h/w). IMVHO, the thing that we should avoid is that e.g., Stephane 
asks to support solution 1, and I ask for support for solution 2 ?? such that 
(as a community) we end up needing to support 1  2, when maybe we could have 
reached some comment recommendation such that there was only need for support 
for 1 || 2.

Let??s wait and hear from the authors of the draft whether they intend to put 
forward some recommendation. If they do not, and rather it should be an 
operator??s choice, perhaps then the numerous operators that are involved in 
the SR/MPLS can instead try and make such a recommendation if we see that there 
is value in it. However, as Stephane pointed out, this is not a decision that 
can be made in isolation from those that build h/w.

r.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] SPRING MPLS and Entropy Label

[Rob Shakir]

Hi SPRING, draft-kini… authors,

I have a few comments on the discussion within this draft — and a quick question
on the intention around the document.

- I feel that it would be useful to provide some clarification as to where we
  expect entropy to be required for load-sharing in the draft. The current
  wording (to me) could be read to say that where Adj-SID is used, then there
  is no requirement to consider placement for EL since there will be no
  load-balancing. However, since Adj-SID can apply to a bundle (3.5.1 in
  draft-filsfils-spring-segment-routing-04), or the underlying transport for an
  IGP adjacency can be multi-path (e.g., an aggregated Ethernet link)
  this is not true unless a head-end PE can guarantee that a particular
  adjacency is made up of a transport that has only 1 path (i.e., explicitly
  requires no load-balancing). I'm not sure how the iLER would actually 
determine
  this, short of the definition of new per-adjacency advertisement capabilities.
  Even if it were able to, then it seems the result is very likely to be that an
  approach that requires per-hop entropy labels to be injected is going to
  guarantee label stack depth = 3*[number of path SIDs].

  I think that the above means that the current draft under-estimates the depth
  of the stack when considering an EL per tunnel (§3.2), which might amplify
  some of the concerns raised for this option. 

- §3.4 - I am not clear how we would really implement this option. If we learn
  midpoint capabilities, and then tune our placement of the EL based on these,
  then it seems like the only viable approach is really to consider _all_
  midpoints, and tune the placement according to the shallowest midpoint in
  the network. This is because, whilst we might expect that there is routing via
  some particular path, this might change if there is ECMP between mid-points
  nodes where some paths have different capabilities than others, and equally
  might change whilst re-routing occurs.

  In terms of discovery of the capabilities of a mid-point -- do we need to
  consider how, in a multi-area network, we discover the capabilities of a
  mid-point which might not have information about it leaked between areas?

- Finally, it'd be good to determine what the intention of the authors for this
  document is. Do we expect that we make a recommendation as to what equipment
  vendors who are going to support SR-MPLS should optimise for? At the moment,
  the document is good at classifying the different approaches that _could_ be 
  taken, but potentially requires an operator/vendor to consider optimisation
  for both a) reading very deep into the stack when acting as an LSR, b) pushing
  very deep stacks when acting as iLER, c) potentially implementing more complex
  swap() operations, whereby some reshuffling of the EL is required. 

  My feeling is that it would be very useful for this document to be able to
  make a clear recommendation as to which of these approaches should be
  optimised for, and hence we should debate their technical efficacy. It'd be
  good to understand whether the authors are intending to do this, or rather
  classify the approaches.

Cheers,
r.


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING MPLS and Entropy Label

[Rob Shakir]

Adding the MPLS wg to this discussion.

[Apologies for the spam.]

r.

On 21 Jul 2014, at 10:38, Rob Shakir r...@rob.sh wrote:

 Hi SPRING, draft-kini… authors,
 
 I have a few comments on the discussion within this draft — and a quick 
 question
 on the intention around the document.
 
 - I feel that it would be useful to provide some clarification as to where we
  expect entropy to be required for load-sharing in the draft. The current
  wording (to me) could be read to say that where Adj-SID is used, then there
  is no requirement to consider placement for EL since there will be no
  load-balancing. However, since Adj-SID can apply to a bundle (3.5.1 in
  draft-filsfils-spring-segment-routing-04), or the underlying transport for an
  IGP adjacency can be multi-path (e.g., an aggregated Ethernet link)
  this is not true unless a head-end PE can guarantee that a particular
  adjacency is made up of a transport that has only 1 path (i.e., explicitly
  requires no load-balancing). I'm not sure how the iLER would actually 
 determine
  this, short of the definition of new per-adjacency advertisement 
 capabilities.
  Even if it were able to, then it seems the result is very likely to be that 
 an
  approach that requires per-hop entropy labels to be injected is going to
  guarantee label stack depth = 3*[number of path SIDs].
 
  I think that the above means that the current draft under-estimates the depth
  of the stack when considering an EL per tunnel (§3.2), which might amplify
  some of the concerns raised for this option. 
 
 - §3.4 - I am not clear how we would really implement this option. If we learn
  midpoint capabilities, and then tune our placement of the EL based on these,
  then it seems like the only viable approach is really to consider _all_
  midpoints, and tune the placement according to the shallowest midpoint in
  the network. This is because, whilst we might expect that there is routing 
 via
  some particular path, this might change if there is ECMP between mid-points
  nodes where some paths have different capabilities than others, and equally
  might change whilst re-routing occurs.
 
  In terms of discovery of the capabilities of a mid-point -- do we need to
  consider how, in a multi-area network, we discover the capabilities of a
  mid-point which might not have information about it leaked between areas?
 
 - Finally, it'd be good to determine what the intention of the authors for 
 this
  document is. Do we expect that we make a recommendation as to what equipment
  vendors who are going to support SR-MPLS should optimise for? At the moment,
  the document is good at classifying the different approaches that _could_ be 
  taken, but potentially requires an operator/vendor to consider optimisation
  for both a) reading very deep into the stack when acting as an LSR, b) 
 pushing
  very deep stacks when acting as iLER, c) potentially implementing more 
 complex
  swap() operations, whereby some reshuffling of the EL is required. 
 
  My feeling is that it would be very useful for this document to be able to
  make a clear recommendation as to which of these approaches should be
  optimised for, and hence we should debate their technical efficacy. It'd be
  good to understand whether the authors are intending to do this, or rather
  classify the approaches.
 
 Cheers,
 r.
 
 
 ___
 spring mailing list
 spring@ietf.org
 https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING MPLS and Entropy Label

[Rob Shakir]

Hi Xiaohu,

On 21 Jul 2014, at 10:56, Xuxiaohu xuxia...@huawei.com wrote:

 In terms of discovery of the capabilities of a mid-point -- do we need to
 consider how, in a multi-area network, we discover the capabilities of a
 mid-point which might not have information about it leaked between areas?
 
 Did you mean that when propagating the capabilities TLV/sub-TLV of a given 
 node across areas, the information (e.g., IP address) of the originator of 
 that capability TLV/sub-TLV is lost?

I was more considering the case that the information is simply not propagated 
into the “downstream” area. There is no clear requirement to me that we need 
propagate capabilities and/or prefix SIDs for non-endpoint nodes across area 
boundaries, and hence we may not have visibility of each mid-point on the path.

r.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING MPLS and Entropy Label

[Rob Shakir]

On 21 Jul 2014, at 11:13, Xuxiaohu xuxia...@huawei.com wrote:

 [Xiaohu] If we need visibility of each mid-point on the path indeed, does it 
 mean that the capability of each mid-point should be propagated across area 
 boundaries?

This could be one solution. One could observe that if we need to propagate 
mid-point information across area boundaries, then we are beginning to reduce 
any (perceived) benefit of running multiple areas. 

Please note, I am not trying to state the need for any solution to this issue, 
just note that there are challenges with such an approach to the authors of the 
draft. If the intention of the draft is to recommend an approach to the 
SPRING+EL issue, then potentially such considerations should be taken into 
account when considering the technical efficacy of each of the options 
described in the document.

Cheers,
r. 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring