Re: [spring] 答复: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Joel Halpern Direct <[e-mail]>]

Aijun, I am not sure I properly understand your request.
In some qys, it sounds like what you are asking for is conventional MPLS.
In other ways, it sounds like you are asking for Ross Callon's old 
writeup on adjusting routing metrics to achieve traffic engineering.

Are those objections to CRH?
Those are not even within the 6man remit.

Yours,
Joel

On 5/24/2020 4:16 AM, Aijun Wang wrote:
> Hi,
> We know the advantages of these proposals. But we also pay more 
> attention to their deployment in large network.
> Considering the flows that needs to be steered away the default path are 
> often small packets, adding the path list overhead on it is not 
> efficient. And we need to add these overhead to every packet of the flow...
> 
> I am wondering why we go from one extreme solution(keep state on network 
> device) to another extreme solution(keep state on every packet)? Network 
> device has the capability to keep state, why put these capabilities aside?
> 
> There are other aspects that we needs to consider, for example the SID 
> allocation across the AS boundary, The Path MTU, the Binding SID, the 
> complexities of different behavior based on these SIDS. All these Issues 
> have been discussed intensely in the mail list but it seems one solution 
> will induce another issue and formed one endless loop... ...
> 
> My thought is that if we depends on the central control/PCE  to 
> accomplish the E2E QoS assurance, we should simplify the protocol, not 
> just the number of them, but also the complexity of implementation and 
> deployment.
> 
> Aijun Wang
> China Telecom
> 
>> On May 23, 2020, at 08:23, Pengshuping (Peng Shuping) 
>> <[e-mail]> wrote:
>>
>> 
>>
>> Hi,
>>
>> Please see inline.
>>
>> --------------------------------------------------
>> 彭书萍 Peng Shuping
>> Mobile: [phone] <tel:[phone]>(优先)
>> Email: [e-mail] <mailto:[e-mail]>
>>
>> *发件人：*Aijun Wang <[e-mail]>
>> *收件人：*'Andrew Alston' <[e-mail]>;'Ketan 
>> Talaulikar (ketant)' <ketant=[e-mail]>;'Joel M. 
>> Halpern' <[e-mail]>
>> *抄 送：*rtg-ads <[e-mail]>;spring <[e-mail]>;'6man' 
>> <[e-mail]>
>> *时 间：*2020-05-22 23:55:46
>> *主 题：*[spring] 答复: CRH is back to the SPRING Use-Case - Re: Size 
>> of CR in CRH
>>
>> Hi, Andrew and all:
>>
>> Is using the “Routing Header” to maneuver the path of packet a good idea?
>>
>> From the viewpoint of the service provider, if we depend on the 
>> central controller/PCE to assure the QoS of application, we should 
>> simplify the network design and the network device.
>>
>> Currently, both SRH and CRH deployment requires the presence of SDN 
>> controller/PCE, but the network/device complexity is not decreased. 
>> How operator can benefit from the adoption of these technologies?
>>
>>
>> [Shuping] Protocols are simplified. Only need to care about IGP and BGP.
>>
>>
>> You have also mentioned the cloud provider. What their requirements is 
>> the openness/standard API from the device, this can give the most 
>> flexibility for network programming.
>>
>> Why we don’t dive into this direction? There are several NorthBound 
>> interfaces/protocols exist in IETF standard.
>>
>>
>> [Shuping] PCEP and BGP can be taken as the standard API of an SRv6 
>> network, by which you can program your network.
>>
>>
>> For CRH and SRH, I think there are some similarity between them. CRH 
>> does not conflict with the IPv6 address, but requires the map table 
>> exist. Many experts will dispute again the similar problem.
>>
>> Is CRH the brick that cloud provider want?
>>
>>
>> [Shuping] SRv6 into DC is also appealing since it enables end-to-end 
>> true network and cloud convergence.
>>
>>
>> Best Regards.
>>
>> Aijun Wang
>>
>> China Telecom
>>
>> *发件人:*[e-mail] <mailto:[e-mail]> 
>> [mailto:[e-mail]] *代表 *Andrew Alston
>> *发送时间:*2020年5月22日17:25
>> *收件人:*Andrew Alston; Ketan Talaulikar (ketant); Joel M. Halpern
>> *抄送:*[e-mail] <mailto:[e-mail]>; [e-mail] 
>> <mailto:[e-mail]>; 6man
>> *主题:*Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of 
>> CR in CRH
>>
>> Just as a followup – which I think illustrates my point here.
>>
>> https://blogs.cisco.com/sp/cisco-goes-sonic-on-new-networking-platforms
>>
>> If operators wanted fait accompli – why is it that Cisco – and other 
>> vendors – are starting to provide ASIC based API’s such that cloud 
>> providers and operators can do what they need on devices – rather than 
>> the dictates of vendors? I think the very fact that the above article 
>> exists – illustrates the desire for simple building blocks.
>>
>> Thanks
>>
>> Andrew
>>
>> *From:*spring <[e-mail] 
>> <mailto:[e-mail]>> *On Behalf Of *Andrew Alston
>> *Sent:* Friday, 22 May 2020 12:15
>> *To:* Ketan Talaulikar (ketant) <ketant=[e-mail] 
>> <mailto:ketant=[e-mail]>>; Joel M. Halpern 
>> <[e-mail] <mailto:[e-mail]>>
>> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] 
>> <mailto:[e-mail]>; 6man <[e-mail] <mailto:[e-mail]>>
>> *Subject:* Re: [spring] CRH is back to the SPRING Use-Case - Re: Size 
>> of CR in CRH
>>
>> Actually Ketan,
>>
>> As an operator – I am looking for the tyre – I want the building block 
>> – because it allows me to both use what the vendors build on top of it 
>> – and to build my own stuff on top of it that is specific to my needs.
>>
>> The tyre association is one such association – the brick is another – 
>> the brick was invented long before anyone created an architectural 
>> diagram to build a building. CRH is a brick – that can be shaped to 
>> many purposes.
>>
>> And as an operator – it is **exactly** what I want – without the 
>> dictates of what any vendor says I can do with it.
>>
>> There are unique conditions in every operator environment – and if an 
>> operator is given the right bricks – and those bricks can be used to 
>> build something that is inter-operable across the vendors and within 
>> their specific domain – it is that building that gives the operator 
>> their competitive advantage. If however, all operators are handed a 
>> completed building – its much harder to build something that 
>> differentiates.
>>
>> I must point out – in a world where we are seeing more and more white 
>> box technology – and where content providers are moving to building 
>> their own things pretty quickly – why do you think that is? One reason 
>> I believe is because the requirements are not the same everywhere – 
>> and I have long believed that a standard should be such that an 
>> operator can take that standard – and use it within his specific 
>> domain to build on top of – and rather we have a standard brick such 
>> that the solutions that are built are portable – than every operator 
>> inventing their own bricks and nothing working together.
>>
>> Again – the reason I support CRH – is because of the flexibility and 
>> simplicity it affords me as an operator – and because – we have 
>> specific use cases and things we wish to build on top of it – some of 
>> which – are pretty standard and happily in the public domain – other 
>> things – which are specific internally. And I for one right now – am 
>> far more willing as an operator to pay for the bricks that let me 
>> build something that is competitive in the market than pay for fait 
>> accompli that is nothing more than the dictates for what vendors think 
>> I want.
>>
>> And yes – I support the divorce of CRH for all things SPRING related – 
>> because the use cases beyond segment routing are multiple – and I have 
>> absolutely zero desire – plan – or anything else to use something like 
>> the PGM draft on my network and impose that level of overhead, 
>> complexity, overloading of the v6 address and what I view as a general 
>> corruption of the v6 architecture. What I want – is a simple routing 
>> header – that I can build on – and that’s the end of the architecture 
>> that I want dictated to me.
>>
>> Thanks
>>
>> Andrew
>>
>> *From:*ipv6 <[e-mail] <mailto:[e-mail]>> *On 
>> Behalf Of *Ketan Talaulikar (ketant)
>> *Sent:* Friday, 22 May 2020 08:24
>> *To:* Joel M. Halpern <[e-mail] <mailto:[e-mail]>>
>> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] 
>> <mailto:[e-mail]>; 6man <[e-mail] <mailto:[e-mail]>>
>> *Subject:* RE: [spring] CRH is back to the SPRING Use-Case - Re: Size 
>> of CR in CRH
>>
>> I am thinking that the operators would be looking for the car and not 
>> the tyre?
>>
>> Thanks,
>> Ketan
>>
>> -----Original Message-----
>> From: Ketan Talaulikar (ketant)
>> Sent: 22 May 2020 10:55
>> To: 'Joel M. Halpern' <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]>; 6man <[e-mail] 
>> <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of 
>> CR in CRH
>>
>> Hi Joel,
>>
>> I'll point you to RFC7855, RFC8355 and RFC8402 that cover both the 
>> data-planes for Spring. Then the RFC8354 which is focussed on SRv6. 
>> All this body of work along with a whole lot of discussion and 
>> brainstorming happening in the Spring WG provided the architecture, 
>> use-cases, applicability and requirements for SRH (RFC8754).
>>
>> It may be so that many people in 6man focussed on only the IPv6 
>> specific aspects as is their design expertise. But there were others 
>> (in 6man, Spring and other WGs) that were able to look at the solution 
>> in a holistic manner thanks to the body of work behind it.
>>
>> Net-PGM builds on top of RFC8402 and RFC8754.
>>
>> To give a real world analogy, let us understand what kind of a car we 
>> are trying to build (to carry goods/passengers or both and how 
>> much/many, what terrain it is meant for, what weather/environment 
>> conditions, how much speed/performance/fuel efficiency parameters 
>> required, etc.) before we start designing tyres for it.
>>
>> Thanks,
>> Ketan
>>
>> -----Original Message-----
>> From: Joel M. Halpern <[e-mail] <mailto:[e-mail]>>
>> Sent: 22 May 2020 10:02
>> To: Ketan Talaulikar (ketant) <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]>; 6man <[e-mail] 
>> <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of 
>> CR in CRH
>>
>> Ketan, I am trying to figure out which documents you think were 
>> adopted and approved elsewhere to drive the 6man work on SRH.
>>
>> I did find RFC 8354, which was a use case. It is not a problem 
>> statement. It is most definitely not an architecture. The only 
>> architecture documents I can find are general SR documents. Those did 
>> not justify a need for SRH. And I (at least) did not object to SRH on 
>> the basis of that gap.
>>
>> Yes, SRH normatively references 8402. But 8402 does not drive any need 
>> for SRH. In fact, the actual text references to SRH are fairly cursory.
>> (The most significant is some terminology.)
>>
>> In fact, as far as I can tell, the ties are such that there is no 
>> evidence in the documents that SPRING had any say in SRH. (the reality 
>> is more complex, I grant you. But there was no formal approval or 
>> signoff.)
>>
>> As far as I can tell, there was no formal approval of anything by 
>> SPRING that can be read as a request to 6man to work on SRH. (Do 
>> remember that the SRH document was adopted by 6man in December of 
>> 2015.) The network programming draft did not even appear at 00 until 
>> March of 2017, 15 months later.
>>
>> How, given this history, can you claim that CRH needs something more.
>> We have operators asking for this.
>>
>> Yours,
>> Joel
>>
>> On 5/21/2020 11:53 PM, Ketan Talaulikar (ketant) wrote:
>> > Hi Bob,
>> > 
>> > Perhaps I will try to make my case to you (and everyone else here) … 
>> > one last time.
>> > 
>> > This is how I've seen RH work being done in 6man until now (in a 
>> > matter that fits its charter).
>> > 
>> > 1) There is a WG (not 6man) that defines the problem statement, 
>> > use-cases and architecture that requires RH
>> > 
>> > 2) The 6man being the experts on IPv6 design, either take up the 
>> > document that specifies that RH (or even if it is done in another WG, 
>> > reviews it).
>> > 
>> > So 6man has always had work done in (1) to reference and lean upon 
>> > when doing (2).
>> > 
>> > My argument of the shortcut in the case of this specific adoption is 
>> > that we don't have (1).
>> > 
>> > It is not in 6man charter nor expertise to take up (1) because CRH is 
>> > not purely IPv6 work. It is not meant for "Internet" but a specific 
>> > "limited domain". The SIDs that it introduces is a new "mapping ID"
>> > concept. It is not an IPv6 address and neither it is MPLS. This is a
>> > *_Routing_* Header and part of a new Source *_Routing_* solution.
>> > 
>> > Therefore, without (1) being made available to 6man, I believe that 
>> > working on (2) in 6man is to me a shortcutting of the IETF technical 
>> > review process (specifically of the *_Routing_* area in this case) for 
>> > a solution and does not provide the necessary reference for 6man to work on.
>> > 
>> > Why the rush?
>> > 
>> > I close my arguments.
>> > 
>> > Thanks,
>> > 
>> > Ketan
>> > 
>> > -----Original Message-----
>> > From: Bob Hinden <[e-mail] <mailto:[e-mail]>>
>> > Sent: 22 May 2020 09:03
>> > To: Ketan Talaulikar (ketant) <[e-mail] <mailto:[e-mail]>>
>> > Cc: Bob Hinden <[e-mail] <mailto:[e-mail]>>; Brian Carpenter
>> > <[e-mail] <mailto:[e-mail]>>; Ron 
>> Bonica <[e-mail] <mailto:[e-mail]>>;
>> > Chengli (Cheng Li) <[e-mail] <mailto:[e-mail]>>; Zafar Ali (zali)
>> > <[e-mail] <mailto:[e-mail]>>; Robert Raszuk 
>> <[e-mail] <mailto:[e-mail]>>; [e-mail] 
>> <mailto:[e-mail]>;
>> > 6man <[e-mail] <mailto:[e-mail]>>
>> > Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of 
>> > CR in CRH
>> > 
>> > Ketan,
>> > 
>> > > On May 21, 2020, at 8:12 PM, Ketan Talaulikar (ketant) 
>> > <ketant=[e-mail]
>> <mailto:ketant=[e-mail]%0b>> 
>> <mailto:ketant=[e-mail]>> wrote:
>> > 
>> > >
>> > 
>> > > Hi Brian,
>> > 
>> > >
>> > 
>> > > Please see my previous response to your comments.
>> > 
>> > >
>> > 
>> > > My argument is not legalistic. I am not as experience in IETF work 
>> > as you and Bob are. But what I understand is that the reason why we 
>> > have these "legal" process of charters and BoF is to enable a proper 
>> > technical discussion with the right context and details of the 
>> > proposal presented for review of the community.
>> > 
>> > >
>> > 
>> > > I do not see how shortcutting them helps anyone and I wonder why it 
>> > is being done in this case?
>> > 
>> > There is no short cutting here. The adoption call is to determine if 
>> > there is interest in the w.g. to take this work into 6man. If it 
>> > becomes a w.g. draft, then the w.g. is responsible to decide what 
>> > happens next.
>> > 
>> > It’s a first step, it is not a decision to publish it.
>> > 
>> > Bob (w/ w.g. chair hat on)
>> > 
>> > >
>> > 
>> > > Thanks,
>> > 
>> > > Ketan
>> > 
>> > >
>> > 
>> > > -----Original Message-----
>> > 
>> > > From: Brian E Carpenter <brian.e.carpenter@gmail..com
>> <mailto:[e-mail]%20%0b>> 
>> <mailto:[e-mail]>>
>> > 
>> > > Sent: 22 May 2020 04:18
>> > 
>> > > To: Ketan Talaulikar (ketant) <[e-mail]
>> <mailto:[e-mail]%20%0b>> <mailto:[e-mail]>>; Ron 
>> Bonica <[e-mail]
>> <mailto:[e-mail]%20%0b>> <mailto:[e-mail]>>; 
>> Chengli (Cheng Li) <[e-mail]
>> <mailto:[e-mail]%20%0b>> <mailto:[e-mail]>>; Zafar Ali 
>> (zali) <[e-mail]
>> <mailto:[e-mail]%20%0b>> <mailto:[e-mail]>>; Robert Raszuk 
>> <[e-mail]
>> <mailto:[e-mail]%20%0b>> <mailto:[e-mail]>>
>> > 
>> > > Cc: [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>; 
>> 6man <[e-mail]
>> <mailto:[e-mail]%20%0b>> <mailto:[e-mail]>>
>> > 
>> > > Subject: Re: CRH is back to the SPRING Use-Case - Re: Size of CR in 
>> > CRH
>> > 
>> > >
>> > 
>> > > On 22-May-20 05:26, Ketan Talaulikar (ketant) wrote:
>> > 
>> > > ....> It is the 6man charter that precludes it from defining a new 
>> > Source Routing solution..
>> > 
>> > >> “It is not chartered to develop major changes or additions to the
>> > IPv6 specifications.”
>> > 
>> > >
>> > 
>> > > If this addition was major, that would be true. But adding a new RH 
>> > type is well within the scope of maintenance, IMHO. We have already 
>> > done it quite recently.
>> > 
>> > >
>> > 
>> > > In any case, legalistic arguments about WG charters are really not 
>> > how we should take technical decisions.
>> > 
>> > >
>> > 
>> > > Regards
>> > 
>> > >   Brian
>> > 
>> > >
>> > 
>> > >
>> > 
>> > > _______________________________________________
>> > 
>> > > spring mailing list
>> > 
>> > > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>> > 
>> > > https://www.ietf.org/mailman/listinfo/spring
>> > 
>> > 
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail] <mailto:[e-mail]>
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> > 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail] <mailto:[e-mail]>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring