Hannes -
Your reply adds some confusion - largely because you have connected different topics inappropriately. I will try to unravel this - inline. > -----Original Message----- > From: Hannes Gredler (han...@juniper.net) [mailto:han...@juniper.net] > Sent: Tuesday, August 11, 2015 8:13 AM > To: Les Ginsberg (ginsberg) > Cc: stephane.litkow...@orange.com; Uma Chunduri; Aissaoui, Mustapha > (Mustapha); spring@ietf.org; Shraddha Hegde (shrad...@juniper.net); > Pushpasis Sarkar (psar...@juniper.net) > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr- > yang > > hi les, > > On Fri, Jul 31, 2015 at 11:26:56PM +0000, Les Ginsberg (ginsberg) wrote: > | Hannes - > | > | As a datapoint, we are able to successfully manage a reserved label space > among multiple SR clients. > | > | As regards GR I am not sure why you think SR introduces new > requirements. If your forwarding plane is to be persistent (NSF) then the > router has to have a way of supporting label persistence across control plane > restarts. In this context SR clients should be making use of whatever > infrastructure already exists to support label persistence. What do you think > is new here? > > in the pre-SR days upon graceful restart the routing system was re-reading > the forwarding table and could derive from pre-incaranation meta- > information which protocol "owned" this label before and suggest to the > new-incranation protocol to re-use that label. > in most implementations i have seen that mapping of label2protocol was a > 1:1 and not 1:N mapping. of course 1:N mapping *can* be done, but you may > loose some of the goodies of SR which is to re-use the existing MPLS eco- > system. > changing the scheme from 1:1 to 1:N has for certain ISSU/NSR implications. > [Les:] The "1:N" problem comes about because of the introduction of "protocol specific SRGBs" - which as this thread has agreed leads to multiple labels for the same prefix. It isn't something inherent w SR itself. In particular it does not arise if you are able to use a protocol independent SRGB - so this is yet another point emphasizing the added complexity of protocol specific SRGBs. > mandating "a single SRGB to rule them all", reminds me a bit to the early SR > debates where we've figured out that a single global SRGB is desirable but > practically not doable due to the various local label-allocations behaviors. > the analogy here is that we're about to change a 15 year old paradigm which > is that "labels are not reused across protocols". i am not saying it can not > be > done, i am just saying that there is a cost to it that not everybody is > willing to > bear. [Les:] The initial "single SRGB" discussion had nothing to do w protocol specific SRGBs. It had to do with whether a single label range (16000-23999 was the proposal) could be reserved for SR purposes on every router. If it could be then there would have been no need for indeces - we simply could have assigned absolute labels to a prefix within a given domain. Allowing each router to choose and advertise its own protocol independent SRGB range does NOT lead to multiple labels per prefix on ingress. So comparing the two discussions is quite inappropriate. > > its cool that your implementation can obviously do 1:N mapping, but no harm > is being done to your implementation if we keep the exisiting 1:1 paradigm > and go ahead with one SRGB per protocol. [Les:] You have completely misrepresented my position as well as the problem space. You made the comment/query: > | > it would be interesting to hear from other implementers if their > | > software can easily track 'multiple client' ownership per label to which I replied > | As a datapoint, we are able to successfully manage a reserved label space > among multiple SR clients. This has nothing to do w multiple labels/prefix. I then also commented > | What is more problematic is supporting multiple labels for the same prefix - > which is one of the consequences of the per-protocol SRGB approach. Please note that it is the proponents of the per-protocol SRGB that are introducing the 1:N mapping issue - and I have tried to explain in my replies why this is more complex. Note also that I did NOT say this was unsupportable - in fact something roughly equivalent is required for SR-LDP interworking - but it does add complexity both in the implementations and in the manageability of the network. Please see my replies to Pushpasis for further detail. Les > > /hannes > > | What is more problematic is supporting multiple labels for the same prefix - > which is one of the consequences of the per-protocol SRGB approach. I am > not saying this is unsupportable - just that it is a more difficult problem to > solve. I would be interested in other implementation experience on this > point. > | > | Les > | > | > | > -----Original Message----- > | > From: Hannes Gredler (han...@juniper.net<mailto:han...@juniper.net>) > | > [mailto:han...@juniper.net] > | > Sent: Friday, July 31, 2015 7:02 AM > | > To: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> > | > Cc: Les Ginsberg (ginsberg); Uma Chunduri; Aissaoui, Mustapha > | > (Mustapha); spring@ietf.org<mailto:spring@ietf.org>; Shraddha Hegde > (shrad...@juniper.net<mailto:shrad...@juniper.net>); > | > Pushpasis Sarkar > | > (psar...@juniper.net<mailto:psar...@juniper.net>) > | > Subject: Re: [spring] Modeling SRGB configuration for > | > draft-ietf-spring-sr- yang > | > > | > one further point is that implementations MAY reuse exisiting MPLS > | > label- managing software for SR. label-management software has often > | > this label- per-client (singular) and not-label-per-clients (plural) > | > bookkeeping in the sense that it cannot track multiple 'owners' of a > certain label value. > | > > | > it would be interesting to hear from other implementers if their > | > software can easily track 'multiple client' ownership per label (and > | > if not) what are the implications to non-SR code-paths e.g. graceful > restart scenarios ? > | > > | > /hannes > | > > | > On Thu, Jul 30, 2015 at 01:18:43PM +0000, > | > stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> > | > wrote: > | > | 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 dependant, but it's a reality). > | > | > | > | Here we have the opportunity to overcome this issue by letting the > | > | possibility to create two parallel forwarding planes using different > | > | labels. I agree that it consumes twice the number of required label, > but > | > | it may be a transient solution (for migration case) and also it's a > design > | > | choice of the operator. > | > | > | > | The last comment from Robert of virtualization , especially using > | > | containers or part of router OS running on COTS (just OSPF or ISIS or > BGP > | > | code), may require some more independency between router > software > | > | components. > | > | > | > | > | > | > | > | > | > | > | > | Now from an architectural perspective, what is Segment Routing ? > | > | > | > | Segment routing is just an architecture, like MPLS is. We see that > segment > | > | routing has more and more controlplanes (ISIS and OSPF first, now > BGP > | > | ...), like MPLS does. Moreover using segment routing in an MPLS > | > | environment leads to adding new controlplanes to MPLS. > | > | > | > | So I like the comment from Pushpasis talking about BGP, LDP, RSVP > which > | > | are different controlplane of MPLS. Do we advertise the same label > value > | > | for the same prefix FEC advertised in LDP, BGP and RSVP ? No ... so > why > | > | doing it with OSPF and ISIS ? > | > | > | > | > | > | > | > | > | > | > | > | From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > | > | Sent: Wednesday, July 29, 2015 23:01 > | > | To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui, > Mustapha > | > | (Mustapha); spring@ietf.org<mailto:spring@ietf.org>; Shraddha Hegde > (shrad...@juniper.net<mailto:shrad...@juniper.net>); > | > | Pushpasis Sarkar (psar...@juniper.net<mailto:psar...@juniper.net>); > Hannes Gredler > | > | (han...@juniper.net<mailto:han...@juniper.net>) > | > | Subject: RE: [spring] Modeling SRGB configuration for > | > | draft-ietf-spring-sr-yang > | > | > | > | > | > | > | > | Stephane - > | > | > | > | > | > | > | > | What is the requirement to have a per-protocol SRGB config? > | > | > | > | This makes no sense to me operationally or architecturally. > | > | > | > | > | > | > | > | (I am not talking about what may or may not have been implemented > by > | > | vendors - the YANG model should be architecturally correct) > | > | > | > | > | > | > | > | Les > | > | > | > | > | > | > | > | > | > | > | > | From: > [1]stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> > | > | [[2]mailto:stephane.litkow...@orange.com] > | > | Sent: Wednesday, July 29, 2015 5:11 AM > | > | To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha > | > (Mustapha); > | > | [3]spring@ietf.org<mailto:spring@ietf.org>; Shraddha Hegde > ([4]shrad...@juniper.net<mailto:shrad...@juniper.net>); > | > Pushpasis > | > | Sarkar ([5]psar...@juniper.net<mailto:psar...@juniper.net>); Hannes > Gredler > | > ([6]han...@juniper.net<mailto:han...@juniper.net>) > | > | Subject: RE: [spring] Modeling SRGB configuration for > | > | draft-ietf-spring-sr-yang > | > | > | > | > | > | > | > | 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 [[7]mailto:uma.chund...@ericsson.com] > | > | Sent: Friday, July 24, 2015 16:59 > | > | To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); > LITKOWSKI > | > | Stephane SCE/IBNF; [8]spring@ietf.org<mailto:spring@ietf.org> > | > | Subject: RE: [spring] Modeling SRGB configuration for > | > | draft-ietf-spring-sr-yang > | > | > | > | > | > | > | > | >Suggesting that the forwarding instruction (AKA label) needs to be > | > | different depending on what protocol provided > | > | > | > | >the instruction is completely unnecessary - it simply wastes label > space. > | > | > | > | > | > | > | > | [Uma]: Les, No - I never suggested anything like that. > | > | > | > | SRGB for a routing instance to be advertised should be part of the > routing > | > | instance provisioning as far as the yang model is concerned. > | > | > | > | Carving out the label space for SR is a local matter and agree, of > course, > | > | this can be done in so many ways through CLI, dynamically, > statically > | > | etc... > | > | > | > | > | > | > | > | -- > | > | > | > | Uma C. > | > | > | > | > | > | > | > | > | > | > | > > __________________________________________________________ > | > ____________ > | > | ___________________________________________________ > | > | > | > | > | > | > | > | 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. > | > | > | > | > | > | > | > > __________________________________________________________ > | > ____________ > | > | ___________________________________________________ > | > | > | > | 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. > | > | > | > | References > | > | > | > | Visible links > | > | 1. mailto:stephane.litkow...@orange.com > | > | 2. mailto:stephane.litkow...@orange.com > | > | 3. mailto:spring@ietf.org > | > | 4. mailto:shrad...@juniper.net > | > | 5. mailto:psar...@juniper.net > | > | 6. mailto:han...@juniper.net > | > | 7. mailto:uma.chund...@ericsson.com > | > | 8. mailto:spring@ietf.org
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
