[Lsr] FW: New Version Notification for draft-ppsenak-lsr-rfc8920bis-01.txt
Folks - Please note that V1 of the RFC8920bis draft has been posted. Les -Original Message- From: internet-dra...@ietf.org Sent: Monday, June 20, 2022 8:24 PM To: Jeff Tantsura ; John Drake ; Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak) ; Wim Henderickx Subject: New Version Notification for draft-ppsenak-lsr-rfc8920bis-01.txt A new version of I-D, draft-ppsenak-lsr-rfc8920bis-01.txt has been successfully submitted by Les Ginsberg and posted to the IETF repository. Name: draft-ppsenak-lsr-rfc8920bis Revision: 01 Title: OSPF Application-Specific Link Attributes Document date: 2022-06-20 Group: Individual Submission Pages: 23 URL: https://www.ietf.org/archive/id/draft-ppsenak-lsr-rfc8920bis-01.txt Status: https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/ Html: https://www.ietf.org/archive/id/draft-ppsenak-lsr-rfc8920bis-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-rfc8920bis Diff: https://www.ietf.org/rfcdiff?url2=draft-ppsenak-lsr-rfc8920bis-01 Abstract: Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings. This document obsoletes RFC 8920. The IETF Secretariat ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] FW: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt
Folks - Please note V01 of the RFC8919bis draft has been posted. This version incorporates comments received from Bruno. Les -Original Message- From: internet-dra...@ietf.org Sent: Monday, June 20, 2022 8:22 PM To: John Drake ; Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak) ; Stefano Previdi ; Wim Henderickx Subject: New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt A new version of I-D, draft-ginsberg-lsr-rfc8919bis-01.txt has been successfully submitted by Les Ginsberg and posted to the IETF repository. Name: draft-ginsberg-lsr-rfc8919bis Revision: 01 Title: IS-IS Application-Specific Link Attributes Document date: 2022-06-20 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.txt Status: https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/ Html: https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis Diff: https://www.ietf.org/rfcdiff?url2=draft-ginsberg-lsr-rfc8919bis-01 Abstract: Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. This document obsoletes RFC 8919. The IETF Secretariat ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
Thanks Aijun. So, in places where BFD can be reasonably deployed, would PUA really help? - Anup On Mon, Jun 20, 2022 at 4:06 PM Aijun Wang wrote: > Hi, Anup: > > The advantage of PUA over BFD is that the operator needs not deploy o(n^2) > BFD sessions for the services that rely on the IGP reachablity. > Such comparisons have been discussed on the list. > > Aijun Wang > China Telecom > > On Jun 18, 2022, at 12:55, Anup MalenaaDu wrote: > > > Hi, > > BGP uses BFD to track the remote PEs. > So, how does PUA really help? > > To be precise, > 1. what are the advantages of having PUAs for IGPs > 2. what are the advantages for services like BGP, Tunnels, LSPs etc going > over IGPs > > Thanks, > Anup > > On Thu, Jun 16, 2022 at 7:41 PM Voyer, Daniel 40bell...@dmarc.ietf.org> wrote: > >> Hi Gunter, see [DV] >> >> >> >> *From: *"Van De Velde, Gunter (Nokia - BE/Antwerp)" < >> gunter.van_de_ve...@nokia.com> >> *Date: *Thursday, June 16, 2022 at 6:38 AM >> *To: *Robert Raszuk >> *Cc: *Gyan Mishra , Dan Voyer < >> daniel.vo...@bell.ca>, " >> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" < >> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>, >> draft-wang-lsr-prefix-unreachable-annoucement < >> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>, "lsr@ietf.org" < >> lsr@ietf.org> >> *Subject: *[EXT]RE: [Lsr] Thoughts about PUAs - are we not >> over-engineering? >> >> >> >> Hi Robert, Peter, Bruno >> >> >> >> You wrote: >> >> “Aas there is no association between node_id (perhaps loopback) and SIDs >> (note that egress can use many SIDs) UPA really does not signal anything >> about SIDs reachability or liveness. “ >> >> >> >> Sure, but UPA signals that a locator is unreachable, would that not >> result for the SRv6 SID to become unreachable as well? >> >> >> >> I understood that UPA have increased value add benefit when using with >> SRv6. If suddenly a locator becomes unreachable, then it I guess the >> associated 128 bit SIDs become unreachable too, causing an event for >> something to happen in the transport network to fix the problem. >> >> >> >> That being said, Peter makes a good point stating that UPA is not solving >> the problem of partitioning areas, and hence, maybe my use-case is not >> overly relevant. >> >> >> >> So progressing, an operator using ABR based summarization then there are >> few options: >> >>1. No summarization at all at ABRs >>2. Summarize on ABR all prefixes that can be summarized >>3. Summarize all prefixes that are not associated with PEs and remain >>advertising individual PE addresses >>4. Summarize all prefixes and use UPA’s to advertise unreachability >>of protected prefixes >> >> >> >> [DV] if “an operator using ABR based summarization” then option 1 is >> out, right ? Also, option 4 is the point of this draft – but furthermore, >> if an aggregation device, inside a domain, is also being summarized – as >> the entire domain get summarized – but this agg device doesn’t have any >> services, because it’s an aggregation device, “then it’s up to the operator >> designing the network to implement” a form of policy/filter. So if that agg >> device reload, due to a maintenance, we don’t care about the unreachability >> advertisement (adding unnecessary LSP in the LSDB). >> >> >> >> We all know that option 1 -3 work well and has been working well for long >> time. Behavior is very well understood >> >> >> >> With the new option 4, to add value, applications need to get what is >> being referenced as ‘vendor secret sauce’ … I can already see the fun >> caused by inconsistent behavior and interop issues due to under >> specification. >> >> [DV] not sure I am following your “secret sauce” point here. Following >> the RFC5305/RFC5308 should be clear. >> >> >> >> The question I remain to have is if the UPA provide higher benefit as the >> tax it introduces. I can see operators suffer due to under specification, >> causing interop and inconsistent behaviors. >> >> >> >> I agree with Bruno’s statement “If you believe that all you need is >> RFC5305/RFC5308 I guess this means that we don't need >> draft-ppsenak-lsr-igp-ureach-prefix-announce” >> >> >> >> [DV] well, “draft-ppsenak-lsr-igp-ureach-prefix-announce”, is describing >> a use case/architecture and what you can do w/ RFC5305/RFC5308 – its >> “informational” >> >> >> >> G/ >> >> >> >> >> >> *From:* Robert Raszuk >> *Sent:* Thursday, June 16, 2022 11:54 AM >> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) < >> gunter.van_de_ve...@nokia.com> >> *Cc:* Gyan Mishra ; Voyer, Daniel > 40bell...@dmarc.ietf.org>; >> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; >> draft-wang-lsr-prefix-unreachable-annoucement < >> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>; lsr@ietf.org >> *Subject:* Re: [Lsr] Thoughts about PUAs - are we not over-engineering? >> >> >> >> Gunter, >> >> >> >> (1) Multiple-ABRs >> >> >> >> I was wondering for example if a ingress router receives a PUA
Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
Hi, Anup: The advantage of PUA over BFD is that the operator needs not deploy o(n^2) BFD sessions for the services that rely on the IGP reachablity. Such comparisons have been discussed on the list. Aijun Wang China Telecom > On Jun 18, 2022, at 12:55, Anup MalenaaDu wrote: > > > Hi, > > BGP uses BFD to track the remote PEs. > So, how does PUA really help? > > To be precise, > 1. what are the advantages of having PUAs for IGPs > 2. what are the advantages for services like BGP, Tunnels, LSPs etc going > over IGPs > > Thanks, > Anup > >> On Thu, Jun 16, 2022 at 7:41 PM Voyer, Daniel >> wrote: >> Hi Gunter, see [DV] >> >> >> >> From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" >> >> Date: Thursday, June 16, 2022 at 6:38 AM >> To: Robert Raszuk >> Cc: Gyan Mishra , Dan Voyer , >> "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" >> , >> draft-wang-lsr-prefix-unreachable-annoucement >> , "lsr@ietf.org" >> >> Subject: [EXT]RE: [Lsr] Thoughts about PUAs - are we not over-engineering? >> >> >> >> Hi Robert, Peter, Bruno >> >> >> >> You wrote: >> >> “Aas there is no association between node_id (perhaps loopback) and SIDs >> (note that egress can use many SIDs) UPA really does not signal anything >> about SIDs reachability or liveness. “ >> >> >> >> Sure, but UPA signals that a locator is unreachable, would that not result >> for the SRv6 SID to become unreachable as well? >> >> >> >> I understood that UPA have increased value add benefit when using with SRv6. >> If suddenly a locator becomes unreachable, then it I guess the associated >> 128 bit SIDs become unreachable too, causing an event for something to >> happen in the transport network to fix the problem. >> >> >> >> That being said, Peter makes a good point stating that UPA is not solving >> the problem of partitioning areas, and hence, maybe my use-case is not >> overly relevant. >> >> >> >> So progressing, an operator using ABR based summarization then there are few >> options: >> >> No summarization at all at ABRs >> Summarize on ABR all prefixes that can be summarized >> Summarize all prefixes that are not associated with PEs and remain >> advertising individual PE addresses >> Summarize all prefixes and use UPA’s to advertise unreachability of >> protected prefixes >> >> >> [DV] if “an operator using ABR based summarization” then option 1 is out, >> right ? Also, option 4 is the point of this draft – but furthermore, if an >> aggregation device, inside a domain, is also being summarized – as the >> entire domain get summarized – but this agg device doesn’t have any >> services, because it’s an aggregation device, “then it’s up to the operator >> designing the network to implement” a form of policy/filter. So if that agg >> device reload, due to a maintenance, we don’t care about the unreachability >> advertisement (adding unnecessary LSP in the LSDB). >> >> >> >> We all know that option 1 -3 work well and has been working well for long >> time. Behavior is very well understood >> >> >> >> With the new option 4, to add value, applications need to get what is being >> referenced as ‘vendor secret sauce’ … I can already see the fun caused by >> inconsistent behavior and interop issues due to under specification. >> >> [DV] not sure I am following your “secret sauce” point here. Following the >> RFC5305/RFC5308 should be clear. >> >> >> >> The question I remain to have is if the UPA provide higher benefit as the >> tax it introduces. I can see operators suffer due to under specification, >> causing interop and inconsistent behaviors. >> >> >> >> I agree with Bruno’s statement “If you believe that all you need is >> RFC5305/RFC5308 I guess this means that we don't need >> draft-ppsenak-lsr-igp-ureach-prefix-announce” >> >> >> >> [DV] well, “draft-ppsenak-lsr-igp-ureach-prefix-announce”, is describing a >> use case/architecture and what you can do w/ RFC5305/RFC5308 – its >> “informational” >> >> >> >> G/ >> >> >> >> >> >> From: Robert Raszuk >> Sent: Thursday, June 16, 2022 11:54 AM >> To: Van De Velde, Gunter (Nokia - BE/Antwerp) >> Cc: Gyan Mishra ; Voyer, Daniel >> ; >> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; >> draft-wang-lsr-prefix-unreachable-annoucement >> ; lsr@ietf.org >> Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering? >> >> >> >> Gunter, >> >> >> >> (1) Multiple-ABRs >> >> >> >> I was wondering for example if a ingress router receives a PUA signaling >> that a given locator becomes unreachable, does that actually really signals >> that the SID ‘really’ is unreachable for a router? >> >> >> >> Aas there is no association between node_id (perhaps loopback) and SIDs >> (note that egress can use many SIDs) UPA really does not signal anything >> about SIDs reachability or liveness. >> >> >> >> For example (simple design to illustrate the corner-case): >>
