hi les, see inline prefixed by HG>
On Tue, Aug 11, 2015 at 04:44:02PM +0000, Les Ginsberg (ginsberg) wrote: | | 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. HG> you're mistaken - 1:N comes from the fact that a label may belong now to more than one protocol (e.g. OSPF and IS-IS) now the label allocation software needs to get extended to support two "owners" in the exisiting (15 year old) scheme (one label belongs to one protocol) you do not have that hassle. | | | > 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. HG> point is: the common thinking flaw here is that 15 year old agreeed upon schemes: 1) labels are local 2) one label per protocol can get easily changed without much ramifications. we have already proof that 1) is not easy to change and i am pretty certain that 2) is in the same category. | | | > | | > 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. HG> its the other way around ... breaking the one label per protocol paradigm by a single SRGB across protocols makes things (GR as an example) really messy. suggest not to go there and not touch this 15 year old convention for no big benefit. | | > | 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 ([1]han...@juniper.net) | | > | > [[2]mailto:han...@juniper.net] | | > | > Sent: Friday, July 31, 2015 7:02 AM | | > | > To: [3]stephane.litkow...@orange.com | | > | > Cc: Les Ginsberg (ginsberg); Uma Chunduri; Aissaoui, Mustapha | | > | > (Mustapha); [4]spring@ietf.org; Shraddha Hegde | ([5]shrad...@juniper.net); | | > | > Pushpasis Sarkar | | > | > ([6]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, | | > | > [7]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) [[8]mailto:ginsb...@cisco.com] | | > | > | Sent: Wednesday, July 29, 2015 23:01 | | > | > | To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui, | | > Mustapha | | > | > | (Mustapha); [9]spring@ietf.org; Shraddha Hegde | | > ([10]shrad...@juniper.net); | | > | > | Pushpasis Sarkar ([11]psar...@juniper.net); Hannes Gredler | | > | > | ([12]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][13]stephane.litkow...@orange.com | | > | > | [[2][14]mailto:stephane.litkow...@orange.com] | | > | > | Sent: Wednesday, July 29, 2015 5:11 AM | | > | > | To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha | | > | > (Mustapha); | | > | > | [3][15]spring@ietf.org; Shraddha Hegde | ([4][16]shrad...@juniper.net); | | > | > Pushpasis | | > | > | Sarkar ([5][17]psar...@juniper.net); Hannes Gredler | | > | > ([6][18]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][19]mailto:uma.chund...@ericsson.com] | | > | > | Sent: Friday, July 24, 2015 16:59 | | > | > | To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); | | > LITKOWSKI | | > | > | Stephane SCE/IBNF; [8][20]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. [21]mailto:stephane.litkow...@orange.com | | > | > | 2. [22]mailto:stephane.litkow...@orange.com | | > | > | 3. [23]mailto:spring@ietf.org | | > | > | 4. [24]mailto:shrad...@juniper.net | | > | > | 5. [25]mailto:psar...@juniper.net | | > | > | 6. [26]mailto:han...@juniper.net | | > | > | 7. [27]mailto:uma.chund...@ericsson.com | | > | > | 8. [28]mailto:spring@ietf.org | | References | | Visible links | 1. mailto:han...@juniper.net | 2. mailto:han...@juniper.net | 3. mailto:stephane.litkow...@orange.com | 4. mailto:spring@ietf.org | 5. mailto:shrad...@juniper.net | 6. mailto:psar...@juniper.net | 7. mailto:stephane.litkow...@orange.com | 8. mailto:ginsb...@cisco.com | 9. mailto:spring@ietf.org | 10. mailto:shrad...@juniper.net | 11. mailto:psar...@juniper.net | 12. mailto:han...@juniper.net | 13. mailto:stephane.litkow...@orange.com | 14. mailto:stephane.litkow...@orange.com | 15. mailto:spring@ietf.org | 16. mailto:shrad...@juniper.net | 17. mailto:psar...@juniper.net | 18. mailto:han...@juniper.net | 19. mailto:uma.chund...@ericsson.com | 20. mailto:spring@ietf.org | 21. mailto:stephane.litkow...@orange.com | 22. mailto:stephane.litkow...@orange.com | 23. mailto:spring@ietf.org | 24. mailto:shrad...@juniper.net | 25. mailto:psar...@juniper.net | 26. mailto:han...@juniper.net | 27. mailto:uma.chund...@ericsson.com | 28. mailto:spring@ietf.org _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
