[Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07

Hi Tony, > Please see figure 2. Ok I thought this is all about this :) To me such advertisement is useful .. just like Henk's idea to include and flood node names in ASCII characters turned super useful - especially when you are at the CLI prompt and running some show commands. Sure one could sa

[Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07

Hi Tony, > If you want 'leaderless' then you simply remove the current discussion > from the algorithm draft and only support manual, ubiquitous configuration > in your implementation. > Could you kindly quote which specific text in the version 07 are you referring to ? >From what I see the ena

[Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07

Hi Les, Your comments stay directly in odds with text from section 2 of the subject draft specifically: The solution proposed in this draft pays particular attention to those realities and operational requirements. *It is designed to be deployable without initial configuration,* *allows n

[Lsr] Re: Using RFC 7356 to address TLV size limitations

be used for a subset of the nodes. > > But that argument doesn’t apply here. > > > >Les > > > > > > *From:* Robert Raszuk > *Sent:* Friday, November 1, 2024 8:44 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* Henk Smit ; lsr@ietf.org; Hannes Gredler < > han...

[Lsr] Re: Using RFC 7356 to address TLV size limitations

h issues related to requests for the IGPs > to carry data not used by the protocol itself. > > > >Les > > > > *From:* Robert Raszuk > *Sent:* Friday, November 1, 2024 2:35 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* Henk Smit ; lsr@ietf.org; Hannes Gredler <

[Lsr] Re: Using RFC 7356 to address TLV size limitations

– which is required to be <= the minimum MTU of all links in the network > enabled for IS-IS. > > > > References to RFC 5311 are in the context of needing more than 256 > LSPs/node/level – not in the context of 16 bit TLVs. > > > >Les > > > > >

[Lsr] Re: Using RFC 7356 to address TLV size limitations

Dear Les, Issue #2 is the limited size of a single TLV/sub-TLV. > > This is addressed by using 16 bit type/length fields. > Can you please kindly elaborate how you fit 65K octet TLV into 9K octets of jumbo frames (max practical MTU) on a link used for flooding between any two nodes ? RFC7356 say

[Lsr] Re: It's time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot Requests

Hi Hannes, How do you deal with MTU of the links if your TLV can grow to 65K octets ? The workarounds to use multiple system IDs or more LSPs seem far from perfect. Related to the subject - IMO we should aim to shrink not grow in size ISIS LSPs. MP seems to be doing the right thing here in provid

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

t of discussion. > > > > Given that Bruno and I understand each other (even if we do not agree) – I > do not find your post helpful – just confusing. > > > >Les > > > > *From:* Robert Raszuk > *Sent:* Wednesday, September 25, 2024 8:43 AM > *To:* L

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Les, > Example: One can imagine a network where MP is the norm and a given operator > might wish to NOT have to configure enablement in the interest of > configuration simplification. Wrong example .. or not related to this discussion. There is no mandate to enable MP-TLVs by configuration.

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Bruno, > If you are ok with a required _*single*_ configuration controls to enable/disable generation of MP-TLVs > (for the TLVs extended by this draft) we are good How would you see this config knob to look if this would not be per TLV ? #router isis disable MP-TLV as defined in rfc

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

warn on > 255 blowout when mp-tlvs are generated and flooded. And yes, the folks > deploying it will come down hard on those evil, evil vendors to pack > decently so it's not non-chalanty done for fun and this is BTW already the > case today due to other reasons and that's ano

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

ements > mp-tlv by putting every prefix into a single TLV will read this and > understand that he SHOULD NOT do this. > > But you're correct, even if it says MUST I would not even know how to > enforce or implement a MUST here. > > -- tony > > On Mon, Sep 9, 2024 at 10

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Tony, > The section 5 says: > >Although MP-TLVs SHOULD NOT be sent unless the >capacity of a single TLV (255 octets) is exceeded, receivers MUST NOT >reject MP-TLVs if senders do not strictly adhere to this constraint. >See Section 7.3 for guidance when sending MP-TLVs. > > If y

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

> things around and in pathological cases basically end up basically > repacking all fragments (which causes normally a serious network > disturbance so it's avoided like the plague in good implementations) > > The SHOULD Les put in is exactly what is both pragmatically necessa

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Tony, I understand the vendor position to protect the pre-standard > implementation. But I’m in the network operator position and I’m trying to > make the network as safe as possible. We’ll see what position the IETF will > take. > > You do not make the network safer by mandate. You make it sa

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi Les, *> We can only do our best to advertise what the configuration requires us to advertise,* Let's zoom on this important statement as if this would be really the case I don't think we would have this discussion. The issue seems to be that the configuration may enable flooding various dynam

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Acee and WG, > Those questioning the flag should have been paying attention > when RFC 9513 and RFC 9352 were being discussed. No. #1 Those two RFCs are about segment routing extensions. draft-chen-lsr-anycast-flag is not. #2 In those two RFCs it is very clear that anycast flag reflects only

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

not want to use an anycast address > for a node on the repair path because forwarding of packets to that address > could be sent towards multiple nodes. > > > >Les > > > > > > *From:* Robert Raszuk > *Sent:* Friday, March 22, 2024 7:33 AM > *To:*

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Les, > Knowledge of whether a given prefix is Anycast has proven useful in existing deployments Would you be so kind and enlighten us with a few practical examples in which you exhibit practical usefulness of this flag at the IGP level? More basic question - is this set by CLI or is there a s

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

Peter, Ok I think what you are proposing is pretty granular and that is fine. We may still disagree if link should be used at all if there are errors on this link in *ANY* direction. So my suggestion here is to have that support build in as well in the nodes computing the topology and not always

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

Hey Peter, > Why do we need the notion of "reverse direction" to be any different then > the notion of forward direction from node B to A on a link ? > > For a link A->B, we typically use attributes in the direction A->B. .e.g. > link delay, link affinities, etc. > > The reason why we want to be a

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

pecify procedures for propagation of anycast > attribute of individual prefixes to the summary since that is not something > that is going to be robust. > > Thanks, > Ketan > > > On Thu, Mar 21, 2024 at 10:02 PM Robert Raszuk wrote: > >> Hi, >> >> Isn&

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

Hi, > When Flex-Algorithm calculation processes the link A to B, it may look at > the 'colors' of the link in the reverse direction, e.g., link B to A. This would > allow the operator to exclude such link from the Flex-Algorithm topology. Why do we need the notion of "reverse direction" to be any

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi, Isn't this knowledge gone outside of the local area when ABR does summarization ? If so, is this really practically useful ? Thx, R. On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar wrote: > Hi Bruno, > > Please check inline below with KT2 for responses. > > > On Thu, Mar 21, 2024 at 7:16

Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

Aijun, > And, if the interfaces share the same prefixes, they are in the same IP subnet. That is unfortunately a wrong assumption. In number of deployments all external links can share the same IP addresses as they are terminated in VRFs and on the other side belong to completely different peers

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

n to “slow but stable” control plane. > > Cheers, > Jeff > > On Nov 26, 2023, at 14:30, Robert Raszuk wrote: > >  > Hey Jeff, > > Could you be so kind and defined term: "scaled-out leaf-spine fabrics" ? > > Specifically folks watching us here would highl

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

Hey Jeff, Could you be so kind and defined term: "scaled-out leaf-spine fabrics" ? Specifically folks watching us here would highly appreciate if we state max target nodes with vanilla ISIS and max target nodes when your ISIS implementation supports draft-ietf-lsr-dynamic-flooding

Re: [Lsr] 转发: New Version Notification for draft-xu-lsr-fare-00.txt

Hi Xiaohu, I would be interested to learn why described elephant flows couldn't be instead handled in typical TE fashion (choose your TE flavor) since we know the target AI training clusters at the CLOS edges ? Such TE could steer such flows link by link or inject it into disjoied virtual topologi

Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

Indeed ... a tunnel (GRE, IPSec, etc...) is an interface. How is this different from any other interface from an OSPF point of view If mtu is configured on such interface (and in most cases it should be) that value should be used in OSPF not 0. Either way it has zero reassemblage to the "OSPF vir

Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

at 05:13, Acee Lindem wrote: > > Hi Robert, > > > > On Sep 18, 2023, at 07:50, Robert Raszuk wrote: > > Acee, > > I agree with your assessment. > > But looking at the RFC I would say it is missing a Terminology section. If > such section would

Re: [Lsr] [Technical Errata Reported] RFC5838 (7644)

Acee, I agree with your assessment. But looking at the RFC I would say it is missing a Terminology section. If such section would clearly define meaning of virtual link in the context of this RFC there would be no ambiguity. Otherwise those not skilled in OSPF art may take a document and apply c

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

Hi Acee, In any case, one will need to update the signaling routers and the routers > acting on the signal. I guess this is clear to all. Additionally, your request for the adoption was that the draft have a > stronger statement about the mechanism being used for solely for signaling > for appl

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

Peter, > > I am not sure what harm would it make to start WG adoption call on both > > drafts and see the results. > > > > So far I am not seeing strong and uniform adoption support for either > > one :) > > I hope you are not serious. Having two different ways of signalling the > same thing in a

[Lsr] Question on draft-ppsenak-lsr-igp-unreach-prefix-announce

Hi Peter & Les, I was looking at the draft, but failed to find any text which would be a normative MUST and would state that only advertisers of a given summary are allowed to inject specific UPAs covered by those summaries. If it comes from some other node it MUST be dropped. I think this is ju

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

t; Please see some comments inline: > > > > *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Thursday, August 31, 2023 4:19 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* Huzhibo ; Peter Psenak > (ppsenak) ; linchangwang ; > Acee Lindem ; lsr ;

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

*Hi Les,* > But existing implementations will NOT ignore a prefix reachability advertisement just because > it has a source Router ID set to 0 as > draft-wang-lsr-prefix-unreachable-annoucement defines. True, but let's do not forget the bigger picture here. The dst is already covered by summary

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

023 02:23, Robert Raszuk wrote: > > > > Well takeMSDs ... I would think remote PE may find useful to know them > > (ie. what is the capability of egress PE). Why those would not be needed > > outside of an area I do not get. > > MSDs are advertise per node or pe

Re: [Lsr] New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

Hi Tony, Unless you are using precise interface based packet steering (which may not be a great idea to start with) how do you know on which line card type your packets arrive/exit ? Just curious ... Thx, R. On Tue, Aug 29, 2023 at 4:36 AM Tony Li wrote: > > Hi Yao, > > Please consider the ca

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

Well takeMSDs ... I would think remote PE may find useful to know them (ie. what is the capability of egress PE). Why those would not be needed outside of an area I do not get. Thx, R. On Tue, Aug 29, 2023 at 10:38 AM Peter Psenak wrote: > Robert, > > On 28/08/2023 14:19, Robert Ras

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

28, 2023 at 11:05 PM Voyer, Daniel wrote: > Hi Robert, inlines > > > > > > *From: *Lsr on behalf of Robert Raszuk < > rob...@raszuk.net> > *Date: *Monday, August 28, 2023 at 12:00 PM > *To: *"Hassan, Shehzad" , Daniel > Bernier > *Cc: *lsr , &q

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

Hi Shehzad & Daniel, > I support this work as it is key for summarization in an SRv6/IPv6 network. > Are you not going to advertise and leak across your IGP domain any of the SRv6 extensions as described in https://datatracker.ietf.org/doc/rfc9352/ for the PEs ? And if you do, is there still so

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

Hi Peter, > The version -04 does not contain normative MUST that UPA shall only be > > used to trigger invalidation when end to end encapsulation is used for > > subject application(s). So as written is in fact quite undeployable in a > > mixed vendor and legacy node(s) environment doing hop by ho

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

Dear LSR WG, I object on two basis ... 1) The version -04 does not contain normative MUST that UPA shall only be used to trigger invalidation when end to end encapsulation is used for subject application(s). So as written is in fact quite undeployable in a mixed vendor and legacy node(s) environ

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

> where you are forwarding hop by hop routing simultaneously with end to end encapsulation. That is not the point here. What you said above is mutually exclusive. The issue arise when you are not doing end to end encapsulation as current UPA draft does not preclude using UPA for such networks wh

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Peter, I am with you that enabling signalling UPA to the application is up to the operator. But going with Bruno's concern, the app (say BGP) on vendor X may use UPA in a completely different way that on vendor Y then again on vendor Z. One may invalidate a path with a given next hop for 5 sec th

[Lsr] UPA for option C

Hey Peter and Lsr, At the risk of being called troublemaker by Les again :) can you refresh my failing memory how UPA would work in case of Inter-AS option C (where original next hops are maintained for service routes across two or more ASNs) and reachability to next hops is redistributed (often w

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

lly reflected as holes/drops in their respective FIBs. Thx, R. On Tue, Jul 25, 2023 at 10:38 AM Peter Psenak wrote: > Hi Robert, > > > > On 25/07/2023 18:51, Robert Raszuk wrote: > > Hey Peter, > > > > I think the point Bruno is making is valid ... Imagine d

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hey Peter, I think the point Bruno is making is valid ... Imagine dual or triple vendor network and hop by hop routing (no end to end SAFI). That means that all nodes should be in synch in terms to react on UPA, Of course you will say that this is up to wise operator to enable it only when it ma

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

this is FA129 related. QOS is then > applied at ingress or egress. > > i.e. 2xxx refers to PHB, and xxx refers to the exit interface. > > > > Hope this is clear. > > > > /louis > > > > *From:* Robert Raszuk > *Sent:* Thursday, April 13, 2023 9:44 PM &

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

Louis, I must be missing something obvious ... Consider the SR-MPLS case and 5 nodes on which I need specific PHB. Does this mean that each packet requires at least *10 labels* on the stack imposed on ingress ? Many thx, R. On Thu, Apr 13, 2023 at 3:35 PM Louis Chan wrote: > Hi ChangWang,

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

into the packet. This is also described in > section 5.3 of draft-dong-lsr-sr-enhanced-vpn-08. > > > > Hope this helps. > > > > Best regards, > > Jie > > > > *From:* Lsr *On Behalf Of *Krzysztof Szarkowicz > *Sent:* Wednesday, April 12, 2023 11:42 PM > *T

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

t; for 200 different service bandwidth guarantees (but having only one - or > handful - SPF calculation domains, where one SPF calculation domain is one > ‘legacy’ flex-algo ). The challenge is with SPP calculations, once the > number of flex-algos goes high. > > Thanks, > Krzysztof

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

Ok you can use 20 flex algos today with no extension. Is going to another level of nesting really necessary ? On Wed, Apr 12, 2023 at 4:52 PM linchangwang wrote: > Hi Acee > > > > An operator's backbone network is divided into different flex algorithms > planes according to different SLA require

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

> Number of LSPs in the entire network: 140 * 20 * 32 * 200/1497=12000 LSPs > > The performance of IGP has always been affected by the size of the entire > network's LSDB, > and even if the periodic flooding time is reduced, there will still be > convergence issues. How total number of LSPs in th

Re: [Lsr] UPA and planned/unplanned signalling

Hi Shraddha, So are you saying that ABR will inject UPA with U Flag when it notices unreachability and it will inject UP Flag when it notices Max Metric ? And the remote end point receiving UPA will still in both cases result in identical action ? Thx, R On Mon, Mar 27, 2023 at 9:25 PM Shraddha

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7406)

Hi Barry, Looks like RFC Editor expanded the "LSP" abbreviation as version -26 (last before publication) says this: * The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number.* IS- IS router MAY advertise more than one IS-IS FAD Sub-TLV for a given Flexible Algorithm (see Section

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

uld describe this procedure in detail. Thx, R On Mon, Mar 27, 2023 at 8:07 AM Peter Psenak wrote: > Robert, > > On 27/03/2023 16:57, Robert Raszuk wrote: > > Hi Peter, > > > > > 4. Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will > >

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

> > Hi Peter, > > > 4. Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will > > trigger BGP PIC edge for 255 /32) > > no. For BGP PIC to be triggered by UPA, the UPA must be sent for the > prefix that is used to resolve BGP prefixes. But the treatment of the > UPA is outside of the

Re: [Lsr] Interdomain UPA & UP Flag

standalone doc. Many thx, Robert On Mon, Mar 27, 2023 at 1:39 AM Peter Psenak wrote: > Hi Robert, > > On 27/03/2023 10:05, Robert Raszuk wrote: > > Hi, > > > > I would like to get more clarification in respect to extending External > > LSAs for UPA. Area summary use case

[Lsr] Interdomain UPA & UP Flag

Hi, I would like to get more clarification in respect to extending External LSAs for UPA. Area summary use case is pretty clear - but in case of redistribution (typical src of external LSAs) IMO we are going way too far with this. Let's all keep in mind that this is a pulse designed to trigger upp

Re: [Lsr] Working Last Call for "Dynamic Flooding on Dense Graphs" - draft-ietf-lsr-dynamic-flooding-12

Support Regards, R. On Fri, Feb 24, 2023 at 9:59 PM Acee Lindem wrote: > There was a lot of LSR Working Group interest and excellent technical work > on this draft > and we’ve decided publish it on the “Experimental” track. We chose that > track due to the > complexity and the fact that there i

Re: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

Support R. On Tue, Nov 22, 2022 at 9:02 PM Acee Lindem (acee) wrote: > LSR WG, > > > > This begins a 2 week WG adoption call for the following draft: > > > > https://datatracker.ietf.org/doc/draft-white-lsr-distoptflood/ > > > > The draft would be adopted on the Informational or Experimental tr

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

Robert On Sun, Nov 13, 2022 at 1:18 PM Christian Hopps wrote: > > Robert Raszuk writes: > > > Chris, > > > >> unreachable routes in the IP routing table > > That quote leaves zero context at all for what I was saying. > > I was replying to Pe

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

Chris, > unreachable routes in the IP routing table I don't see anywhere in the UPA spec even a hint that those unreachable pulses would be installed in the IP routing table. It seems to be a local implementation choice how ISIS or OSPF would inform other protocols about them. In fact the quote

Re: [Lsr] OSPF-GT

deployments for Geninfo in IS-IS can also predict the future fate > of such approaches in some sense. > > > Aijun Wang > China Telecom > > On Nov 10, 2022, at 10:48, Robert Raszuk wrote: > >  > Thx Acee ... > > Since you mentioned "sparse" and si

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

> > > > I think the point of this was that it could be other applications where > > an ephemeral unreachability notification is useful. For this type of > > notification, recursive route resolution is the primary application. > > However, I’ll defer to the authors. > > that is correct indeed. > Ok

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

it clearly in the document. This is not my current assumption. Many thx, R. On Thu, Nov 10, 2022 at 11:47 AM Acee Lindem (acee) wrote: > Hi Robert, > > > > *From: *Robert Raszuk > *Date: *Thursday, November 10, 2022 at 9:41 AM > *To: *Peter Psenak > *Cc: *Bruno Dec

Re: [Lsr] OSPF-GT

interested parties for a given type of info present in such a plane, but this comes with much more overhead then pub-sub. Cheers, R. On Thu, Nov 10, 2022 at 11:34 AM Acee Lindem (acee) wrote: > Hi Robert, > > > > *From: *Robert Raszuk > *Date: *Wednesday, November 9, 2022 at

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

Peter, > But: > > - that is nonetheless a change which is non backward compatible with > people currently using such high metric without the intention to mean UPA > > - to differentiate different usages (e.g. your UPA, my other usage such > as "graceful shutdown" (still reachable but will disappea

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

Aijun, > there is another summary address that covers it is in the FIB. You keep bringing this point over and over. But what you are not aware of is that service route validation or invalidation can be set and tracked for reachability with specific length of the next hop. Both validation and in

[Lsr] OSPF-GT

Hi Acee, The point of sparse GT makes it much more attractive. With that I have two questions/suggestions to make it even more useful. #1 Would you consider adding reflection function to spares mode GT ? #2 If you do #1 would you considet pub-sub model ? Then this could be used for lot's of cu

Re: [Lsr] RFC 8362 and LSInfinity

> 1) The LSInfinity is defined almost 30 years, but it is not applied/deployed within the > network about 30 years OSPF Max Metric (LSInfinity) is commonly deployed and used in pretty much every decent network. As an example it is used to drain traffic from active forwarding nodes before planned

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

gt; > From: Christian Hopps > > Sent: Thursday, October 6, 2022 1:36 PM > > To: Peter Psenak (ppsenak) > > Cc: Christian Hopps ; Tony Li ; Les > > Ginsberg (ginsberg) ; Robert Raszuk > > ; Henk Smit ; lsr@ietf.org > > Subject: Re: [Lsr] New Version Notification f

Re: [Lsr] Warren Kumari's Yes on draft-ietf-lsr-ospf-bfd-strict-mode-09: (with COMMENT)

Hi Warren, You have just asked a very valid question. I have brought this to the attention of LSR WG here: https://mailarchive.ietf.org/arch/msg/lsr/LaXtqHuoZ6FCeOuvZ9sUXxZ_Z20/ But after 10s of emails on and off line apparently you observing the issue again at this stage is proof that no real

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

if you want to pursue this I think another thread/draft > is called for. > > Certainly well beyond anything I am thinking about. > > > >Les > > > > *From:* Robert Raszuk > *Sent:* Wednesday, October 5, 2022 2:41 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* b

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

mentation. > > > >Les > > > > *From:* Robert Raszuk > *Sent:* Wednesday, October 5, 2022 1:41 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* bruno.decra...@orange.com; Tony Li ; Christian > Hopps ; Henk Smit ; lsr@ietf.org > *Subject:* Re: [Lsr] New Version Noti

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

enabling until > all nodes advertise support. > > Am I close?? > > > > If so, this is one of the aspects that adds complexity. > > And it still does not result in a working network. > > So, no thanks. > > > >Les > > > > *From:* Robert

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

k functional. > > > > I am quite concerned that this is something that “sounds good” but in > practice adds little value – yet places significant demands on > implementations. > > > >Les > > > > > > *From:* Lsr *On Behalf Of * > bruno.dec

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

Tony & Les, I do think we should be signalling node's enabled/active capabilities including the ability to process various types of encoded PDUs in band. I do not believe in live management planes. Sure getting stats, config push etc ... it is all doable and deployed. But dynamic configuration ba

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

s in a separate thread – and > note that (with the notable exception of “hostname”) this isn’t done today > – so it is something very new. > > > >Les > > > > > > > > *From:* Robert Raszuk > *Sent:* Thursday, September 22, 2022 12:38 PM > *To:* Le

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

Hi Les, > 2) Applicability of advertising what features an implementation supports extends > to much more than just multi-tlv support. Indeed. Spot on ! And wasn't it the reason for rfc4971 then updated by rfc7981 ? I think having such capabilities flooded via area or entire domain is a very us

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

All, I am actually finding this capability useful. If for nothing else then to help the operator to see what is going on in the area. On any node simple show command will clearly show who is willing and capable to receive MP-TLVs and who is not. Analogy to including hostnames Tony brought here as

Re: [Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

> > you advertise the algo X locator as UPA. > So as UPA is generated by ABRs now ABRs must be locator aware. Moreover local flooding must be able to map nodes to locators and locators must be flooded in the underlay. If one wants to tunnel flex-algo's between POPs across base (say core not bein

Re: [Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

n the case where BGP next hop is different then flex-algo destination address ? Thx, R. On Fri, Aug 5, 2022 at 3:19 PM Peter Psenak wrote: > Robert, > > On 05/08/2022 09:09, Robert Raszuk wrote: > > Peter, > > > > Side question ... > > > > Assume

Re: [Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

Peter, Side question ... Assume PE participates in 10 end to end flex-algos. However BGP advertises 100K service routes with base 0 nh 1.1.1.1/32 Are you stating that BGP should advertise 100K routes 10 times with different IP address ? Note that mapping to flex-algo may not be prefix based on

Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

Hi Aijun, How does this proposal impacts BGP path selection ? Note that it is common to do next hop self on the ASBRs towards the intradomain. So your proposal would not require any signalling to be effective on a given ASBR. Local decision. Originally I was under impression that you want to enh

Re: [Lsr] UPA/PUA

t; >>> >>> >>>PUAM can track the unreachability of the important component >>> >>> prefixes to ensure traffic is not black hole sink routed for the >>> >>>above overlay services. >>> >>> >>> >>>

Re: [Lsr] UPA/PUA

es. > > > > Then considering only the BFD sessions among PEs are not enough, even we > put aside the BFD sessions overhead on each PE. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* Greg Mirsky > *Sent:*

Re: [Lsr] UPA/PUA

lution, can we say that the PUA/UPA solution is more preferable? >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> *From:* lsr-boun...@ietf.org *On Behalf Of *Greg >> Mirsky >>

Re: [Lsr] UPA

p sessions to run over this crappy-link at > millisecond rates, but *not* ok for a single link local session to do the > same? > > Thanks, > Chris. > > Robert Raszuk writes: > > > Hi Les, > > > > > >> You seem to be suggesting that multi-ho

Re: [Lsr] UPA

ution MUST work at scale – up > to thousands of PEs. > > That’s because there are customers asking for this. > > > >Les > > > > *From:* Robert Raszuk > *Sent:* Sunday, July 17, 2022 1:12 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* Christian Hopps ; Peter P

Re: [Lsr] UPA

Hi Les, Your excerpted top posting may not have enough context for everyone to > easily follow the point being discussed – hopefully that is not the case. > Well just trying to respond to the points raised. *[LES:] Sooo, you apparently think it is OK to declare a node unreachable > even though t

Re: [Lsr] UPA

t;> >> Finally, I am not certain you are saying this – but you seem to be saying >> that BFD itself does not tell you whether the BFD client is fully sane. >> This I agree with – but again it applies to Multi-hop BFD as well as single >> hop BFD. >> >> >> >>

Re: [Lsr] UPA

e with – but again it applies to Multi-hop BFD as well as single > hop BFD. > > > > Thanx. > > > > Les > > > > > > > > *From:* Lsr *On Behalf Of * Robert Raszuk > *Sent:* Sunday, July 17, 2022 4:49 AM > *To:* Christian Hopps > *Cc:* Pe

Re: [Lsr] UPA

n area. Many thx, R. On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps wrote: > > Robert Raszuk writes: > > > Peter, > > > > In the scenario described there is really nothing to be tuned as you > > are limited by the quality of local telco carriers. > > &

Re: [Lsr] IGP Monitoring Protocol

process over either TCP or QUIC sessions in native IGP format. So IMP is focusing on this very functionality. Many thx, R. On Sun, Jul 17, 2022 at 12:38 AM Christian Hopps wrote: > > Robert Raszuk writes: > > > Btw this independent attempt by two WG groups to normalize link stat

Re: [Lsr] FW: New Version Notification for draft-lin-lsr-srv6-service-sid-00.txt

Hi, Thank you for publishing this document. I have few comments about it. #1 - While you are defining IGP extensions I think this document still belongs in BESS WG not in LSR WG. #2 - Injecting IPv4 sites to your IPv6 only IGP is IMO a terrible idea. BGP overlays are used to keep core IGPs stab

Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

t the meaning of a given > term when used in the scope of a document so long as we have a clear > definition – which we do. > > > >Les > > > > > > > > *From:* Robert Raszuk > *Sent:* Wednesday, July 13, 2022 12:25 AM > *To:* Shraddha Hegd

Re: [Lsr] New Version Notification for draft-ginsberg-lsr-rfc8919bis-01.txt

Hello, Yes I very much support Shraddha's msg. The term "application" should not even be (re)defined up front, but completely removed from the document. Likewise ASLA should be renamed too. I thought we had the agreement in subsequent documents to do so. Why not fix it across the board ? If we l

  1   2   3   4   5   6   >