Re: [Lsr] OSPF/IS-IS Entropy Label Signaling Drafts
Hi Acee, We will update these two drafts so as to keep the terminologies be aligned with the https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-12.txt Best regards, Xiaohu -- From:Acee Lindem (acee) Send Time:2018年7月18日(星期三) 05:13 To:draft-ietf-ospf-mpls-...@ietf.org ; draft-ietf-isis-mpls-...@ietf.org Cc:lsr@ietf.org Subject:[Lsr] OSPF/IS-IS Entropy Label Signaling Drafts Authors of LSR MPLS ELC Signaling Drafts, Now that we have https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-12.txt on the RFC queue waiting on a MISREF for Segment Routing MPLS, it seems we should move forward with these drafts. However, it seems that we should advertise an Entropy RLD rather than a generic RLD to be aligned with the terminology in the MPLS draft (soon to be RFC). Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Fwd: IPR Poll follow up on draft-ietf-isis-segment-routing-extensions-16
-- Forwarded message -- From: Rob Shakir Date: Fri, Jun 22, 2018 at 6:52 PM Subject: Re: IPR Poll follow up on draft-ietf-isis-segment-routing-extensions-16 To: Saku Ytti Cc: umac.i...@gmail.com, draft-ietf-isis-segment-routing-extensi...@ietf.org, "Horneffer, Martin" , Edward Crabbe < edward.cra...@gmail.com>, milojevici...@gmail.com, slu...@cisco.com, lsr-cha...@ietf.org I am not aware of any IPR other than that already disclosed. Thanks, r. > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Fwd: IPR Poll follow up on draft-ietf-isis-segment-routing-extensions-16
-- Forwarded message -- From: Igor Milojevic Date: Sat, Jun 23, 2018 at 1:27 AM Subject: Re: IPR Poll follow up on draft-ietf-isis-segment-routing-extensions-16 To: Uma Chunduri Cc: Edward Crabbe , martin.hornef...@telekom.de, Rob Shakir , Saku Ytti , draft-ietf-isis-segment-routing-extensi...@ietf.org, lsr-cha...@ietf.org, slu...@cisco.com Not aware of any IPR related. Igor On Fri, 22 Jun 2018 at 23:16, Uma Chunduri wrote: > Dear All, > > All authors have responded to the IPR Poll. > > Still couple of contributors (as listed) need to respond to the IPR Poll > - Martin H. > - Edward C. > - Rob S. > - Igor M. > - Saku Y. > > Please respond to the LSR list thread. > > -- > Uma C. > > On Fri, Jun 15, 2018 at 9:16 AM, Uma Chunduri wrote: > >> Still need one author's and couple of contributors response for the above >> subject. >> >> Please respond to the LSR list thread. >> >> -- >> Uma C. >> > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Fwd: IPR Poll follow up on draft-ietf-isis-segment-routing-extensions-16
-- Forwarded message -- From: Saku Ytti Date: Fri, Jun 22, 2018 at 5:17 PM Subject: Re: IPR Poll follow up on draft-ietf-isis-segment-routing-extensions-16 To: umac.i...@gmail.com Cc: draft-ietf-isis-segment-routing-extensi...@ietf.org, "Horneffer, Martin" , Edward Crabbe < edward.cra...@gmail.com>, ro...@google.com, milojevici...@gmail.com, slu...@cisco.com, lsr-cha...@ietf.org Not aware of any IPR. On Sat, 23 Jun 2018 at 00:16, Uma Chunduri wrote: > > Dear All, > > All authors have responded to the IPR Poll. > > Still couple of contributors (as listed) need to respond to the IPR Poll > - Martin H. > - Edward C. > - Rob S. > - Igor M. > - Saku Y. > > Please respond to the LSR list thread. > > -- > Uma C. > > On Fri, Jun 15, 2018 at 9:16 AM, Uma Chunduri wrote: >> >> Still need one author's and couple of contributors response for the above subject. >> >> Please respond to the LSR list thread. >> >> -- >> Uma C. > > -- ++ytti ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00
V1 has been posted with the additional text. Hope this clears any issues with the shepherd's report. Les > -Original Message- > From: Lsr On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, July 17, 2018 2:07 PM > To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) > ; Christian Hopps ; lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > Ketan - > > I don't want to be overly prescriptive here. > The need for supporting backwards compatibility is limited by the amount of > existing deployment by implementations that chose the "length 5" solution - > and > hopefully any such issues will be short-lived as the problematic > implementations > get upgraded. > > But If there is a need for backwards compatibility it is possible that both > transmit/receive are required. This is a judgment call for implementers and > the > new text in the draft is not meant to tell implementers what they SHOULD do - > only to remind them that this may be an issue which they will have to > consider. If > they think receive only is sufficient that's fine, but it is beyond what I > think the > draft needs to say. > >Les > > > > -Original Message- > > From: Ketan Talaulikar (ketant) > > Sent: Tuesday, July 17, 2018 11:29 AM > > To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) > > ; Christian Hopps ; lsr@ietf.org > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > > Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > > > Hi Les, > > > > This sounds good. I would suggest being liberal in receive (i.e. > > accept and interpret the incorrect encoding) and there is no need to > > send that erroneous encoding. > > > > Thanks, > > Ketan > > > > -Original Message- > > From: Les Ginsberg (ginsberg) > > Sent: 17 July 2018 13:30 > > To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) > > ; Christian Hopps ; lsr@ietf.org > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > > Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > > > Ketan - > > > > Thanx for taking on the role of shepherd. > > > > I am attaching some proposed diffs which I think addresses your concern. > > Let me know if this suffices and we can publish an update. > > > >Les > > > > > > > -Original Message- > > > From: Ketan Talaulikar (ketant) > > > Sent: Tuesday, July 17, 2018 6:55 AM > > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > > > ; Christian Hopps ; > > > lsr@ietf.org > > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > > > Subject: RE: [Lsr] WG Last Call for > > > draft-ietf-lsr-isis-rfc7810bis-00 > > > > > > Hi All, > > > > > > I was reviewing this draft as the Shepherd. It is a fairly simple > > > and straightforward bis update to RFC7810 to fix an encoding error. > > > > > > There is one point that I would like the authors and WG to consider. > > > > > > The draft in the appendix talks about two interpretations of the > > > erroneous sub- TLVs and from the conversation on the list I get the > > > impression that there are at least two implementations out there > > > which did different interpretations. Do we want to consider putting > > > in a suggestion (i.e. not normative perhaps) that implementations > > > updated to this specifications accept the sub-TLV with the Reserved > > > field included and size 5? So they don't consider such an encoding > > > as error or > > malformed on reception? > > > > > > Thanks, > > > Ketan > > > > > > -Original Message- > > > From: Lsr On Behalf Of Acee Lindem (acee) > > > Sent: 18 June 2018 17:38 > > > To: Les Ginsberg (ginsberg) ; Christian Hopps > > > ; lsr@ietf.org > > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > > > Subject: Re: [Lsr] WG Last Call for > > > draft-ietf-lsr-isis-rfc7810bis-00 > > > > > > Hi Les, > > > Yes - the Working Group Last call has completed. We'll find a > > > shepherd and request publication. > > > Thanks, > > > Acee > > > > > > On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)" > > > > > wrote: > > > > > > WG chairs - > > > > > > Can we consider WG last call completed? (It has been more than 3 > > > weeks...) > > > > > > Would really like to get this small but important correction > > > published ASAP > > > > > > ___ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] I-D Action: draft-ietf-lsr-isis-rfc7810bis-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Traffic Engineering (TE) Metric Extensions Authors : Les Ginsberg Stefano Previdi Spencer Giacolone Dave Ward John Drake Qin Wu Filename: draft-ietf-lsr-isis-rfc7810bis-01.txt Pages : 19 Date: 2018-07-17 Abstract: In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc7810bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-rfc7810bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00
FWIW - I agree with Les. We really don't want to support both interpretations of the ambiguous encoding. Thanks, Acee On 7/17/18, 5:06 PM, "Les Ginsberg (ginsberg)" wrote: Ketan - I don't want to be overly prescriptive here. The need for supporting backwards compatibility is limited by the amount of existing deployment by implementations that chose the "length 5" solution - and hopefully any such issues will be short-lived as the problematic implementations get upgraded. But If there is a need for backwards compatibility it is possible that both transmit/receive are required. This is a judgment call for implementers and the new text in the draft is not meant to tell implementers what they SHOULD do - only to remind them that this may be an issue which they will have to consider. If they think receive only is sufficient that's fine, but it is beyond what I think the draft needs to say. Les > -Original Message- > From: Ketan Talaulikar (ketant) > Sent: Tuesday, July 17, 2018 11:29 AM > To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) > ; Christian Hopps ; lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > Hi Les, > > This sounds good. I would suggest being liberal in receive (i.e. accept and > interpret the incorrect encoding) and there is no need to send that erroneous > encoding. > > Thanks, > Ketan > > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: 17 July 2018 13:30 > To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) > ; Christian Hopps ; lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > Ketan - > > Thanx for taking on the role of shepherd. > > I am attaching some proposed diffs which I think addresses your concern. > Let me know if this suffices and we can publish an update. > >Les > > > > -Original Message- > > From: Ketan Talaulikar (ketant) > > Sent: Tuesday, July 17, 2018 6:55 AM > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > > ; Christian Hopps ; > > lsr@ietf.org > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > > Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > > > Hi All, > > > > I was reviewing this draft as the Shepherd. It is a fairly simple and > > straightforward bis update to RFC7810 to fix an encoding error. > > > > There is one point that I would like the authors and WG to consider. > > > > The draft in the appendix talks about two interpretations of the > > erroneous sub- TLVs and from the conversation on the list I get the > > impression that there are at least two implementations out there which > > did different interpretations. Do we want to consider putting in a > > suggestion (i.e. not normative perhaps) that implementations updated > > to this specifications accept the sub-TLV with the Reserved field > > included and size 5? So they don't consider such an encoding as error or > malformed on reception? > > > > Thanks, > > Ketan > > > > -Original Message- > > From: Lsr On Behalf Of Acee Lindem (acee) > > Sent: 18 June 2018 17:38 > > To: Les Ginsberg (ginsberg) ; Christian Hopps > > ; lsr@ietf.org > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > > > Hi Les, > > Yes - the Working Group Last call has completed. We'll find a shepherd > > and request publication. > > Thanks, > > Acee > > > > On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)" > wrote: > > > > WG chairs - > > > > Can we consider WG last call completed? (It has been more than 3 > > weeks...) > > > > Would really like to get this small but important correction > > published ASAP > > > > ___ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] OSPF/IS-IS Entropy Label Signaling Drafts
Authors of LSR MPLS ELC Signaling Drafts, Now that we have https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-12.txt on the RFC queue waiting on a MISREF for Segment Routing MPLS, it seems we should move forward with these drafts. However, it seems that we should advertise an Entropy RLD rather than a generic RLD to be aligned with the terminology in the MPLS draft (soon to be RFC). Thanks, Acee ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00
Ketan - I don't want to be overly prescriptive here. The need for supporting backwards compatibility is limited by the amount of existing deployment by implementations that chose the "length 5" solution - and hopefully any such issues will be short-lived as the problematic implementations get upgraded. But If there is a need for backwards compatibility it is possible that both transmit/receive are required. This is a judgment call for implementers and the new text in the draft is not meant to tell implementers what they SHOULD do - only to remind them that this may be an issue which they will have to consider. If they think receive only is sufficient that's fine, but it is beyond what I think the draft needs to say. Les > -Original Message- > From: Ketan Talaulikar (ketant) > Sent: Tuesday, July 17, 2018 11:29 AM > To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) > ; Christian Hopps ; lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > Hi Les, > > This sounds good. I would suggest being liberal in receive (i.e. accept and > interpret the incorrect encoding) and there is no need to send that erroneous > encoding. > > Thanks, > Ketan > > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: 17 July 2018 13:30 > To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) > ; Christian Hopps ; lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > Ketan - > > Thanx for taking on the role of shepherd. > > I am attaching some proposed diffs which I think addresses your concern. > Let me know if this suffices and we can publish an update. > >Les > > > > -Original Message- > > From: Ketan Talaulikar (ketant) > > Sent: Tuesday, July 17, 2018 6:55 AM > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > > ; Christian Hopps ; > > lsr@ietf.org > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > > Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > > > Hi All, > > > > I was reviewing this draft as the Shepherd. It is a fairly simple and > > straightforward bis update to RFC7810 to fix an encoding error. > > > > There is one point that I would like the authors and WG to consider. > > > > The draft in the appendix talks about two interpretations of the > > erroneous sub- TLVs and from the conversation on the list I get the > > impression that there are at least two implementations out there which > > did different interpretations. Do we want to consider putting in a > > suggestion (i.e. not normative perhaps) that implementations updated > > to this specifications accept the sub-TLV with the Reserved field > > included and size 5? So they don't consider such an encoding as error or > malformed on reception? > > > > Thanks, > > Ketan > > > > -Original Message- > > From: Lsr On Behalf Of Acee Lindem (acee) > > Sent: 18 June 2018 17:38 > > To: Les Ginsberg (ginsberg) ; Christian Hopps > > ; lsr@ietf.org > > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > > > Hi Les, > > Yes - the Working Group Last call has completed. We'll find a shepherd > > and request publication. > > Thanks, > > Acee > > > > On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)" > wrote: > > > > WG chairs - > > > > Can we consider WG last call completed? (It has been more than 3 > > weeks...) > > > > Would really like to get this small but important correction > > published ASAP > > > > ___ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [spring] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
Les - in-line ... > > Although I will certainly consider the additional response you seem to > have hinted at in your reply to Peter, it seems to me that Section 6 of > your draft acknowledges that there is a scaling problem [Uma]: What it says is there is no scale issue in certain deployments where only limited number of pats are required (examples given). In that case you don't need any *further extensions* as referred. As we noted this is fully backward compatible for SR-MPLS and SRH data planes and one can go ahead and use it one can't find a path and SID depth is an issue (in terms of any of these, HW compatibility, Line rate, header tax or MTU). > - and then references what seems to be a non-existent draft (I could not > find "draft-ce-ppr-graph-00" ???) as a proposed solution. > [Uma]: This will be posted soon, few things are being worked out. This helps in certain cases (you will see soon), where you want to scale optimized paths. > > In any further response you make it would be good if you did indicate > whether you agree PPR has a scaling issue - [Uma]: Plz see above.. > Thanx. > > Les > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [spring] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
> [Uma]: This helps in deployments, who is seeking source routing paradigm, but SID stack on the packet is unsustainable. This statement is applicable for both MPLS and IPv6 case. >[KT] Could we look at why the SID stack is getting "unsustainable" in the first place? I am not sure what you want to look - plz don't ask topology of a particular deployment and how the SRH/SR-MPLS path is crafted? Please see the generic example and some of the references in the draft. You have to tell me the issues summarized for various deployments (including brownfield scenarios) are not an issue. If this is not an issue there is no need for MSD capability either and all the hoops to discover this capability and work around. I don't think you can definitely say, you can limit X SR SIDs in SRH and Y labels etc.. >[KT] Dave's argument was in multicast context while he was giving the p2p example perhaps as a worst case theoretical example. IMHO we should not look at such worst case scenarios. >To me, this is a hybrid proposal to bring a hop by hop path (which is why the SID stack is so huge) like in RSVP-TE into an SR network and then try to figure out a way to do this in IGPs. You can feel free to disagree :-) This is not the worst case scenario (I just referred to the thread overall and discussion of adding a FIB entry is considered OK and being argued it is not OK stating that as considered as "state" - I feel at some level we are confusing with this and the soft state and refresh required thereof ); it could be the base scenario, depending on the deployment. -- Uma C. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00
Hi Les, This sounds good. I would suggest being liberal in receive (i.e. accept and interpret the incorrect encoding) and there is no need to send that erroneous encoding. Thanks, Ketan -Original Message- From: Les Ginsberg (ginsberg) Sent: 17 July 2018 13:30 To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) ; Christian Hopps ; lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 Ketan - Thanx for taking on the role of shepherd. I am attaching some proposed diffs which I think addresses your concern. Let me know if this suffices and we can publish an update. Les > -Original Message- > From: Ketan Talaulikar (ketant) > Sent: Tuesday, July 17, 2018 6:55 AM > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > ; Christian Hopps ; > lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > Hi All, > > I was reviewing this draft as the Shepherd. It is a fairly simple and > straightforward bis update to RFC7810 to fix an encoding error. > > There is one point that I would like the authors and WG to consider. > > The draft in the appendix talks about two interpretations of the > erroneous sub- TLVs and from the conversation on the list I get the > impression that there are at least two implementations out there which > did different interpretations. Do we want to consider putting in a > suggestion (i.e. not normative perhaps) that implementations updated > to this specifications accept the sub-TLV with the Reserved field > included and size 5? So they don't consider such an encoding as error or > malformed on reception? > > Thanks, > Ketan > > -Original Message- > From: Lsr On Behalf Of Acee Lindem (acee) > Sent: 18 June 2018 17:38 > To: Les Ginsberg (ginsberg) ; Christian Hopps > ; lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 > > Hi Les, > Yes - the Working Group Last call has completed. We'll find a shepherd > and request publication. > Thanks, > Acee > > On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)" wrote: > > WG chairs - > > Can we consider WG last call completed? (It has been more than 3 > weeks...) > > Would really like to get this small but important correction > published ASAP > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
Uma - I share the concerns expressed by Ketan and Peter. Although I will certainly consider the additional response you seem to have hinted at in your reply to Peter, it seems to me that Section 6 of your draft acknowledges that there is a scaling problem - and then references what seems to be a non-existent draft (I could not find "draft-ce-ppr-graph-00" ???) as a proposed solution. In any further response you make it would be good if you did indicate whether you agree PPR has a scaling issue - and given the contents of Section 6 of your draft - also discuss why we should consider PPR + some additional scaling enhancements when we already have at least one solution which does scale linearly. Thanx. Les > -Original Message- > From: Lsr On Behalf Of Uma Chunduri > Sent: Tuesday, July 17, 2018 6:43 AM > To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) > ; lsr@ietf.org > Cc: spr...@ietf.org > Subject: Re: [Lsr] Concerns with > draft-chunduri-lsr-isis-preferred-path-routing > > Hi Peter, > > > -Original Message- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Tuesday, July 17, 2018 9:34 AM > To: Uma Chunduri ; Ketan Talaulikar (ketant) > ; lsr@ietf.org > Cc: spr...@ietf.org > Subject: Re: [Lsr] Concerns with > draft-chunduri-lsr-isis-preferred-path-routing > > > > flex-algo is NOT a per path state. It's a regular prefix-SID, which is > bound to a prefix only. > > Not quite. I will come back to this bit later. > > >The problem with your proposal is that you flood all paths to all > routers > in the area and ask every router to evaluate all of them and see which of them > may apply. This scale poorly. > > Please see Section 6, in 01 version. > > -- > Uma C. > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
Hi Uma, Please check inline below. Thanks, Ketan -Original Message- From: Uma Chunduri Sent: 17 July 2018 08:57 To: Ketan Talaulikar (ketant) ; lsr@ietf.org Cc: spr...@ietf.org Subject: RE: Concerns with draft-chunduri-lsr-isis-preferred-path-routing Hi Ketan, In-line [Uma]: -- Uma C. -Original Message- From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Tuesday, July 17, 2018 7:13 AM To: Uma Chunduri ; lsr@ietf.org Cc: spr...@ietf.org Subject: Concerns with draft-chunduri-lsr-isis-preferred-path-routing Hi Uma, I would like share more context on the concerns that I raised on this proposal in LSR WG yesterday where we could not complete our discussion on the mike due to time constraints. IGPs were originally invented for topology computation and then route programming based on the SPT computed. We've extended IGPs to carry/flood information and this includes information that were meant for various applications. IGPs always do distribute topology computation - that is the core principle. The PPR proposal takes IGPs into the area of flooding p2p paths and then setting up forwarding state along the path - essentially introducing path provisioning capabilities into it. Essentially adding a new functionality that is NOT distributed topology computation. For clarity, I could summarize the PPR as follows (please correct if wrong): - Someone (head-end or controller) computes a SR Path which is expressed as a SID List (it's a list of EROs just like in RSVP-TE - loose or strict) - The head-end floods this SR Path (and its EROs) into the IGP domain so all routers in the area get the P2P paths computed by all head-ends - Each router then must look at every such SR Path flooded by every router and examine if it is part of the ERO list; if so then it needs to program the forwarding state for that PPR id (aka label) - The headend can then just look at this like a "tunnel" and do something like IGP shortcut to the destination behind it This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p path state pervasively. Consider the kind of flooding scale and challenges when all these SR Paths go to every router irrespective of whether they need/use it. Then on top of that, we are proposing IGPs to program a local cross-connect if they are on that SR Path. My question is, why not just use RSVP-TE in this case? RSVP-TE does signalling but it does it only on the nodes that matter for a specific LSP. [Uma]: This helps in deployments, who is seeking source routing paradigm, but SID stack on the packet is unsustainable. This statement is applicable for both MPLS and IPv6 case. [KT] Could we look at why the SID stack is getting "unsustainable" in the first place? Coming to the EROs in IGP - it was there in SR drafts, including as working group draft for 3 years. But what completely lacked was how to use those. [KT] Right and I never thought/realized that this was the purpose of those EROs. I repeat the scale challenge and that you are proposing to re-purpose IGPs for programming MPLS cross-connects for hop-by-hop LSP setup. This is my concern. There are significant differences in the format and importantly usage to solve various issues including hardware Compatibilities of various line cards (and hence available paths), MTU and line rate issues. I don't think you can use RSVP-TE to solve these SR issues. This is called SR but it introduces a forwarding state on each of the hops (i.e. the PPR label cross-connect) - something different from SR architecture. [Uma]: You already introduced per path state in various cases (binding sids to local policy, flex-algo). This has been discussed lately as part of re-chartering discussion. This thread discusses that in detail and I fully concur what Dave said here https://www.ietf.org/mail-archive/web/spring/current/msg03794.html [KT] Dave's argument was in multicast context while he was giving the p2p example perhaps as a worst case theoretical example. IMHO we should not look at such worst case scenarios. To me, this is a hybrid proposal to bring a hop by hop path (which is why the SID stack is so huge) like in RSVP-TE into an SR network and then try to figure out a way to do this in IGPs. You can feel free to disagree :-) Thanks, Ketan ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00
Hi All, I was reviewing this draft as the Shepherd. It is a fairly simple and straightforward bis update to RFC7810 to fix an encoding error. There is one point that I would like the authors and WG to consider. The draft in the appendix talks about two interpretations of the erroneous sub-TLVs and from the conversation on the list I get the impression that there are at least two implementations out there which did different interpretations. Do we want to consider putting in a suggestion (i.e. not normative perhaps) that implementations updated to this specifications accept the sub-TLV with the Reserved field included and size 5? So they don't consider such an encoding as error or malformed on reception? Thanks, Ketan -Original Message- From: Lsr On Behalf Of Acee Lindem (acee) Sent: 18 June 2018 17:38 To: Les Ginsberg (ginsberg) ; Christian Hopps ; lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00 Hi Les, Yes - the Working Group Last call has completed. We'll find a shepherd and request publication. Thanks, Acee On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)" wrote: WG chairs - Can we consider WG last call completed? (It has been more than 3 weeks...) Would really like to get this small but important correction published ASAP ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
Hi Peter, -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Tuesday, July 17, 2018 9:34 AM To: Uma Chunduri ; Ketan Talaulikar (ketant) ; lsr@ietf.org Cc: spr...@ietf.org Subject: Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing > flex-algo is NOT a per path state. It's a regular prefix-SID, which is bound to a prefix only. Not quite. I will come back to this bit later. >The problem with your proposal is that you flood all paths to all routers in the area and ask every router to evaluate all of them and see which of them may apply. This scale poorly. Please see Section 6, in 01 version. -- Uma C. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
Hi Uma, On 17/07/18 08:56 , Uma Chunduri wrote: Hi Ketan, In-line [Uma]: -- Uma C. -Original Message- From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Tuesday, July 17, 2018 7:13 AM To: Uma Chunduri ; lsr@ietf.org Cc: spr...@ietf.org Subject: Concerns with draft-chunduri-lsr-isis-preferred-path-routing Hi Uma, I would like share more context on the concerns that I raised on this proposal in LSR WG yesterday where we could not complete our discussion on the mike due to time constraints. IGPs were originally invented for topology computation and then route programming based on the SPT computed. We've extended IGPs to carry/flood information and this includes information that were meant for various applications. IGPs always do distribute topology computation - that is the core principle. The PPR proposal takes IGPs into the area of flooding p2p paths and then setting up forwarding state along the path - essentially introducing path provisioning capabilities into it. Essentially adding a new functionality that is NOT distributed topology computation. For clarity, I could summarize the PPR as follows (please correct if wrong): - Someone (head-end or controller) computes a SR Path which is expressed as a SID List (it's a list of EROs just like in RSVP-TE - loose or strict) - The head-end floods this SR Path (and its EROs) into the IGP domain so all routers in the area get the P2P paths computed by all head-ends - Each router then must look at every such SR Path flooded by every router and examine if it is part of the ERO list; if so then it needs to program the forwarding state for that PPR id (aka label) - The headend can then just look at this like a "tunnel" and do something like IGP shortcut to the destination behind it This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p path state pervasively. Consider the kind of flooding scale and challenges when all these SR Paths go to every router irrespective of whether they need/use it. Then on top of that, we are proposing IGPs to program a local cross-connect if they are on that SR Path. My question is, why not just use RSVP-TE in this case? RSVP-TE does signalling but it does it only on the nodes that matter for a specific LSP. [Uma]: This helps in deployments, who is seeking source routing paradigm, but SID stack on the packet is unsustainable. This statement is applicable for both MPLS and IPv6 case. Coming to the EROs in IGP - it was there in SR drafts, including as working group draft for 3 years. But what completely lacked was how to use those. There are significant differences in the format and importantly usage to solve various issues including hardware Compatibilities of various line cards (and hence available paths), MTU and line rate issues. I don't think you can use RSVP-TE to solve these SR issues. This is called SR but it introduces a forwarding state on each of the hops (i.e. the PPR label cross-connect) - something different from SR architecture. [Uma]: You already introduced per path state in various cases (binding sids to local policy, flex-algo). This has been discussed lately as part of re-chartering discussion. flex-algo is NOT a per path state. It's a regular prefix-SID, which is bound to a prefix only. The problem with your proposal is that you flood all paths to all routers in the area and ask every router to evaluate all of them and see which of them may apply. This scale poorly. thanks, Peter This thread discusses that in detail and I fully concur what Dave said here https://www.ietf.org/mail-archive/web/spring/current/msg03794.html ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr . ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
Hi Ketan, In-line [Uma]: -- Uma C. -Original Message- From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Tuesday, July 17, 2018 7:13 AM To: Uma Chunduri ; lsr@ietf.org Cc: spr...@ietf.org Subject: Concerns with draft-chunduri-lsr-isis-preferred-path-routing Hi Uma, I would like share more context on the concerns that I raised on this proposal in LSR WG yesterday where we could not complete our discussion on the mike due to time constraints. IGPs were originally invented for topology computation and then route programming based on the SPT computed. We've extended IGPs to carry/flood information and this includes information that were meant for various applications. IGPs always do distribute topology computation - that is the core principle. The PPR proposal takes IGPs into the area of flooding p2p paths and then setting up forwarding state along the path - essentially introducing path provisioning capabilities into it. Essentially adding a new functionality that is NOT distributed topology computation. For clarity, I could summarize the PPR as follows (please correct if wrong): - Someone (head-end or controller) computes a SR Path which is expressed as a SID List (it's a list of EROs just like in RSVP-TE - loose or strict) - The head-end floods this SR Path (and its EROs) into the IGP domain so all routers in the area get the P2P paths computed by all head-ends - Each router then must look at every such SR Path flooded by every router and examine if it is part of the ERO list; if so then it needs to program the forwarding state for that PPR id (aka label) - The headend can then just look at this like a "tunnel" and do something like IGP shortcut to the destination behind it This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p path state pervasively. Consider the kind of flooding scale and challenges when all these SR Paths go to every router irrespective of whether they need/use it. Then on top of that, we are proposing IGPs to program a local cross-connect if they are on that SR Path. My question is, why not just use RSVP-TE in this case? RSVP-TE does signalling but it does it only on the nodes that matter for a specific LSP. [Uma]: This helps in deployments, who is seeking source routing paradigm, but SID stack on the packet is unsustainable. This statement is applicable for both MPLS and IPv6 case. Coming to the EROs in IGP - it was there in SR drafts, including as working group draft for 3 years. But what completely lacked was how to use those. There are significant differences in the format and importantly usage to solve various issues including hardware Compatibilities of various line cards (and hence available paths), MTU and line rate issues. I don't think you can use RSVP-TE to solve these SR issues. This is called SR but it introduces a forwarding state on each of the hops (i.e. the PPR label cross-connect) - something different from SR architecture. [Uma]: You already introduced per path state in various cases (binding sids to local policy, flex-algo). This has been discussed lately as part of re-chartering discussion. This thread discusses that in detail and I fully concur what Dave said here https://www.ietf.org/mail-archive/web/spring/current/msg03794.html ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing
Hi Uma, I would like share more context on the concerns that I raised on this proposal in LSR WG yesterday where we could not complete our discussion on the mike due to time constraints. IGPs were originally invented for topology computation and then route programming based on the SPT computed. We've extended IGPs to carry/flood information and this includes information that were meant for various applications. IGPs always do distribute topology computation - that is the core principle. The PPR proposal takes IGPs into the area of flooding p2p paths and then setting up forwarding state along the path - essentially introducing path provisioning capabilities into it. Essentially adding a new functionality that is NOT distributed topology computation. For clarity, I could summarize the PPR as follows (please correct if wrong): - Someone (head-end or controller) computes a SR Path which is expressed as a SID List (it's a list of EROs just like in RSVP-TE - loose or strict) - The head-end floods this SR Path (and its EROs) into the IGP domain so all routers in the area get the P2P paths computed by all head-ends - Each router then must look at every such SR Path flooded by every router and examine if it is part of the ERO list; if so then it needs to program the forwarding state for that PPR id (aka label) - The headend can then just look at this like a "tunnel" and do something like IGP shortcut to the destination behind it This is picking EROs from RSVP-TE and putting them into IGPs for flooding p2p path state pervasively. Consider the kind of flooding scale and challenges when all these SR Paths go to every router irrespective of whether they need/use it. Then on top of that, we are proposing IGPs to program a local cross-connect if they are on that SR Path. My question is, why not just use RSVP-TE in this case? RSVP-TE does signalling but it does it only on the nodes that matter for a specific LSP. This is called SR but it introduces a forwarding state on each of the hops (i.e. the PPR label cross-connect) - something different from SR architecture. Including SPRING group as well for the review of this proposed SR solution. Seems like a mishmash of SR and RSVP-TE to me and I am concerned about where this takes IGPs. Thanks, Ketan ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
