Re: [Lsr] RtgDir Last Call review: draft-ietf-lsr-ospf-admin-tags-16

[Acee Lindem]

Hi Russ, 

Thanks for the review. See inline. 

> On Mar 16, 2024, at 16:51, r...@riw.us wrote:
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The 
> Routing Directorate seeks to review all routing or routing-related drafts as 
> they pass through IETF last call and IESG review, and sometimes on special 
> request. The purpose of the review is to provide assistance to the Routing 
> ADs. For more information about the Routing Directorate, please see 
> https://wiki.ietf.org/en/group/rtg/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, it 
> would be helpful if you could consider them along with any other IETF Last 
> Call comments that you receive, and strive to resolve them through discussion 
> or by updating the draft.
> 
> Document: draft-ietf-lsr-ospf-admin-tags-16
> Reviewer: Russ White
> Review Date: 16 March 2024
> IETF LC End Date: 5 April 2024
> Intended Status: copy-from-I-D
> 
> Summary:
> Choose from this list...
> 
> This document is basically ready for publication but has nits that should be 
> considered prior to publication.
> 
> Comments:
> 
> Beyond the two miro issues/questions below, the draft is readable and 
> well-structured.
> 
> Major Issues:
> 
> No major issues found.
> 
> Minor Issues:
> 
> I don't consider these blockers, just two questions.
> 
> In the abstract:
> 
>> described in RFC 5130.
> 
> My understanding is there should be no references in the abstract (?). Is it 
> still okay to mention a document that would normally include a reference, or 
> should this bit be removed, and a reference to the pertinent RFC inserted 
> later?

One can refer to another RFC but not with an actual cited reference, i.e., 
[RFC]. You’ll note that all the BIS documents call out the document that is 
being replaced in the Abstract.  


> 
> In the Introduction:
> 
>> The definition of the 64-bit tag was considered but discard given that there 
>> is no strong requirement or use case. The specification is included here for 
>> information.
> 
> I don't see the specification here (?). Maybe the second sentence should be 
> removed?

I agree and will remove. We formerly had this in an appendix. 

Thanks,
Acee



> 
> :-) /r

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-ietf-lsr-ospf-admin-tags-17.txt

[internet-drafts]

Internet-Draft draft-ietf-lsr-ospf-admin-tags-17.txt is now available. It is a
work item of the Link State Routing (LSR) WG of the IETF.

   Title:   Extensions to OSPF for Advertising Prefix Administrative Tags
   Authors: Acee Lindem
Peter Psenak
Yingzhen Qu
   Name:draft-ietf-lsr-ospf-admin-tags-17.txt
   Pages:   19
   Dates:   2024-03-18

Abstract:

   It is useful for routers in OSPFv2 and OSPFv3 routing domains to be
   able to associate tags with prefixes.  Previously, OSPFv2 and OSPFv3
   were relegated to a single tag and only for AS External and Not-So-
   Stubby-Area (NSSA) prefixes.  With the flexible encodings provided by
   OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs,
   multiple administrative tags may be advertised for all types of
   prefixes.  These administrative tags can be used for many
   applications including route redistribution policy, selective prefix
   prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection,
   and many others.

   The ISIS protocol supports a similar mechanism that is described in
   RFC 5130.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-admin-tags-17.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospf-admin-tags-17

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Intra-domain SAVNET method - draft-lin-savnet-lsr-intra-domain-method-03

[Acee Lindem]

Speaking as WG member: 

Co-Authors,

I see you have a slot at the LSR meeting on Thursday to present the subject 
draft. 

I believe this document is misguided. You shouldn't need to advertise protected 
prefixes. If you are doing Source Address Validation for intra-domain sources, 
why wouldn't you do it for all of them? What do you do for the intra-domain 
prefixes that aren't advertised (blindly forward them or summarily discard 
them)? If you were to only do SAV on certain prefixes, this should be a local 
decision as opposed to something that is advertised by the sources. 

Also, you shouldn't need to advertise any reverse metric. At least within an 
area, you have all the reverse costs in link-sate.  Incoming interfaces for 
asymmetric paths can be readily calculated without any IGP advertisement. 
Algorithms to accomplish this are described in 

https://patents.google.com/patent/US11882019B1/en?oq=11882019

The SAVNET WG shouldn't adopt any document requiring IGP advertisement without 
LSR approval. 

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt

[internet-drafts]

Internet-Draft draft-ietf-lsr-flex-algo-bw-con-08.txt is now available. It is
a work item of the Link State Routing (LSR) WG of the IETF.

   Title:   Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints
   Authors: Shraddha Hegde
William Britto A J
Rajesh Shetty
Bruno Decraene
Peter Psenak
Tony Li
   Name:draft-ietf-lsr-flex-algo-bw-con-08.txt
   Pages:   30
   Dates:   2024-03-18

Abstract:

   Many networks configure the link metric relative to the link
   capacity.  High bandwidth traffic gets routed as per the link
   capacity.  Flexible algorithms provide mechanisms to create
   constraint based paths in IGP.  This draft documents a generic metric
   type and set of bandwidth related constraints to be used in Flexible
   Algorithms.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-flex-algo-bw-con-08

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[Shraddha Hegde]

Acee,

I read your comment about elephant flow and added below text in sec 4.1.1.2

“Note that a single elephant flow is normally
   pinned to a single layer-3 interface. If the single layer-3 link
   bandwidth is not sufficient for any single elephant flow, the mechanisms
   to solve this issue are outside the scope of this document”
Replace the term “centralized controller” with “PCE”

Posting -08 version now. Pls check

Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Shraddha Hegde
Sent: Wednesday, March 6, 2024 12:22 PM
To: Acee Lindem 
Cc: lsr ; draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]

Hi Acee,

Thanks for the review and edits.
I have incorporated all edits.
Will post -08 when window opens.
Pls see inline for replies



Juniper Business Use Only


Juniper Business Use Only
From: Acee Lindem mailto:acee.lin...@gmail.com>>
Sent: Friday, March 1, 2024 4:16 AM
To: Acee Lindem mailto:acee.lin...@gmail.com>>
Cc: lsr mailto:lsr@ietf.org>>; 
draft-ietf-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

[External Email. Be cautious of content]


Authors,

I support publication of this document but not in its current state. I have the 
following comments that should be resolved first:

1. "Backward Compatibility" section is missing. This should be 
straightforward given that an FAD computation only includes
nodes supporting that FAD.
 OK

 2. “Security Considerations” is “TBD”.
 ok

 3. There is no “Operational Considerations” section. Someone may ask for 
one.
 ok

 4. The document alludes to the problem with elephant flows. Yet for 
“Interface Group Mode”, the aggregate bandwidth for multiple L3 links is used. 
How would this work when a flow is typically bound to a single L3 interface?
 All we are trying to do in this document is to assign metric relative to 
bandwidth. IGPs cannot  do any bandwidth management and path placement and it’s 
been mentioned in the introduction section clearly.

 5. #3 in section 5 is very hard to parse. Possibly split into multiple 
coherent sentences.
 will do


Lots of editorial nits - I’m attaching some suggested edits but I’m not sure I 
got them all.

  1. Use “sub-TLV” and “Sub-TLV” consistent with the usage in RFC  9350. I 
tried to fix these on the fly but it probably still needs work. Basically, it 
is capitalized when used as part of a proper noun identifying a specific 
sub-TLV. Also, in section titles and captions.
 will do

  2. Reference RFC9350 rather than the Flex-Algo draft throughout.
 ok

  3. I didn’t make the change but I’d use “Layer-2” and “Layer-3” 
hyphenated.
ok


See attached editorial suggestions  in the RFC diff.

Thanks,
Acee


> On Feb 19, 2024, at 5:25 PM, Acee Lindem 
> mailto:acee.lin...@gmail.com>> wrote:
>
>
> This starts the Working Group Last call for 
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm 
> enhancements described in the document have been implemented.
>
> Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Cv33O23fKbqI5Mibov464lpU2T_xjsvN8M9FRLg5sfwFuc-uvt8zz70GyAVhzS-6Tzg8QoA1XXKadGgo4se8DQ$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Is UPA expected to trigger BGP best path calculation?

[Muthu Arul Mozhi Perumal]

Hi all,

draft-ietf-lsr-igp-ureach-prefix-announce mentions BGP PIC edge as one the
use cases for UPA in the presence of summarization. However, it is not
quite clear whether UPA is expected to trigger BGP best path calculation at
the ingress PE (in addition to triggering BGP PIC) in spite of the BGP NH
(or SRv6 locator as the case may be) being reachable through the summary
route in RIB. Or should BGP wait for the service route to be withdrawn
(say, by an RR having reachability to the egress PE) before triggering BGP
best path?

It looks either case would be problematic in case of a short flap in
reachability for the BGP NH as detected by the egress ABR:

   - If the ingress PE were to run the BGP best path on receiving UPA for
   the BGP NH, what would be the trigger to run another best path when the BGP
   NH becomes reachable again soon after, for reverting the traffic to the
   original NH? This is unlike using MH-BFD to detect the BGP NH reachability
   which can indicate both down/up. UPA on the other hand indicates only a
   down.
   - If the ingress PE were to rely on the service routes to be
   withdrawn/re-advertised, then what about scenarios where the BGP session is
   directly b/w the ingress and egress PEs? Is UPA not expected to be deployed
   in such scenarios?

There was a discussion earlier about the UP flag in the UPA advertisement
triggering BGP best path:
https://mailarchive.ietf.org/arch/msg/lsr/_qhlHBjQ8H-bLXtA6Nn4J7musjc/

Is this applicable also to the U flag?

I think it is difficult to realize the use case for UPA in an interoperable
way without this clarity..

Regards,
Muthu
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[internet-drafts]

Internet-Draft draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt is now
available. It is a work item of the Link State Routing (LSR) WG of the IETF.

   Title:   IGP Flexible Algorithms Reverse Affinity Constraint
   Authors: Peter Psenak
Jakub Horn
Amit Dhamija
   Name:draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
   Pages:   9
   Dates:   2024-03-18

Abstract:

   An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
   constraint-based paths.

   This document extends IGP Flex-Algorithm with additional constraints.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-flex-algo-reverse-affinity/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-flex-algo-reverse-affinity-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-flex-algo-reverse-affinity-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr