Re: [Lsr] Paul Wouters' No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[Paul Wouters]

Yes, it basically said, you MUST do this protocol to get this protocol.

Sent using a virtual keyboard on a phone

> On Jun 8, 2023, at 09:05, John Scudder  wrote:
> 
> Hi Peter and all,
> 
>>> On Jun 8, 2023, at 2:43 AM, Peter Psenak 
>>>  wrote:
>>> 
>>>A node MUST participate in a Flex-Algorithm to be:
>>>- Able to compute path for such Flex-Algorithm
>>>- Part of the topology for such Flex-Algorithm
>>> 
>>> This is an odd use of MUST.
>> 
>> what exactly is odd in it?
> 
> I don’t know what Paul found odd about it, but now that I’m looking at it 
> afresh, I also think it’s odd. My reason is that it’s not expressing a 
> requirement, it’s expressing a statement of fact, a natural consequence. An 
> analogy would be if we said “if you let go of your coffee cup as you’re 
> lifting it, it MUST fall down”. You don’t need a MUST there, gravity doesn’t 
> care about your rules. To continue the analogy, a more usual use of MUST 
> would be to express an actual requirement on the implementor — “you MUST NOT 
> drink your coffee through a straw”.
> 
> I haven’t gone and re-checked in the doc to be sure, but as I recall, it’s 
> not possible for a node to be part of the topology for a given FA unless it 
> participates in the FA, and this would be true whether the quoted MUST were 
> there or not.
> 
> $0.02,
> 
> —John

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

Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-dynamic-flooding-13

[Tony Li]

Hi Acee,

These issues have been addressed:

- The technical sections have been checked against implementations. The 
implementations have been found to be non-existant. All existing 
implementations only deal with the P2P case.

- We’ve added an informative reference. -14 published with the update.

Thanks,
Tony


> On Jun 5, 2023, at 10:30 AM, Acee Lindem  wrote:
> 
> Hi Sue, 
> 
> Thanks for your review of a fairly large specifying complex functionality 
> required prior IGP expertise. 
> 
> Authors, 
> 
> Please address Sue’s comments. 
> 
> Thanks,
> Acee (as document Shepherd) 
> 
>> On Jun 5, 2023, at 13:21, Susan Hares via Datatracker  
>> wrote:
>> 
>> Reviewer: Susan Hares
>> Review result: Ready
>> 
>> The document is written in a clear and concise manner.
>> The authors have done an excellent job of making a difficult subject clear 
>> and
>> readable.
>> 
>> Two technical sections should be checked against implementations of IS-IS 
>> with
>> dense flooding (section 6.6.2.1 and section 6.6.2.2.  I am not implementing 
>> so
>> this check is beyond my capabilities.
>> 
>> Editorial nit:
>> section 3, requirement 3, sentence 2.  "Just addressing a complete bipartite
>> topology such as K5, 8 is insufficient."  An informative reference to K5,8 
>> or a
>> bipartite topology might be helpful to readers.  This is an optional 
>> editorial
>> comment.
>> 
>> 
> 

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

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-dynamic-flooding-14.txt

[Tony Li]

FYI

This addresses a comment raised during the rtgdir last call review. We were 
asked to add an informative reference for graph theory.

Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-dynamic-flooding-14.txt
> Date: June 8, 2023 at 9:49:26 AM PDT
> To: "Huaimo Chen" , "Luay Jalil" 
> , "Peter Psenak" , "Srinath 
> Dontula" , "Tony Li" 
> 
> 
> A new version of I-D, draft-ietf-lsr-dynamic-flooding-14.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-dynamic-flooding
> Revision: 14
> Title:Dynamic Flooding on Dense Graphs
> Document date:2023-06-08
> Group:lsr
> Pages:48
> URL:
> https://www.ietf.org/archive/id/draft-ietf-lsr-dynamic-flooding-14.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-dynamic-flooding-14
> 
> Abstract:
>   Routing with link state protocols in dense network topologies can
>   result in sub-optimal convergence times due to the overhead
>   associated with flooding.  This can be addressed by decreasing the
>   flooding topology so that it is less dense.
> 
>   This document discusses the problem in some depth and an
>   architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
>   and OSPFv3 are described in this document.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

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

[Lsr] I-D Action: draft-ietf-lsr-dynamic-flooding-14.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Link State Routing
(LSR) WG of the IETF.

   Title   : Dynamic Flooding on Dense Graphs
   Authors : Tony Li
 Peter Psenak
 Huaimo Chen
 Luay Jalil
 Srinath Dontula
   Filename: draft-ietf-lsr-dynamic-flooding-14.txt
   Pages   : 48
   Date: 2023-06-08

Abstract:
   Routing with link state protocols in dense network topologies can
   result in sub-optimal convergence times due to the overhead
   associated with flooding.  This can be addressed by decreasing the
   flooding topology so that it is less dense.

   This document discusses the problem in some depth and an
   architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
   and OSPFv3 are described in this document.

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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-14

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-dynamic-flooding-14

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] Paul Wouters' No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-14: (with COMMENT)

[Ketan Talaulikar]

Hi Paul,

Thanks for the discussion and feedback. I've fixed the nit in my edit
buffer and it will get reflected in the next update (if one is needed to
address further comments).

Thanks,
Ketan


On Thu, Jun 8, 2023 at 9:07 PM Paul Wouters via Datatracker <
nore...@ietf.org> wrote:

> Paul Wouters has entered the following ballot position for
> draft-ietf-lsr-ospfv3-srv6-extensions-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
> --
> COMMENT:
> --
>
> Thanks to Ketan for the constructive discussion and changes. I've updated
> my
> ballot to No Objection. I do hope the WG will consider properly replacing
> or
> updating RFC5340, but that is not this document's problem.
>
> NIT: IPSec -> IPsec  (no need for new draft, it can be fixed during the RFC
> editing cycle)
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Paul Wouters' No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-14: (with COMMENT)

[Paul Wouters via Datatracker]

Paul Wouters has entered the following ballot position for
draft-ietf-lsr-ospfv3-srv6-extensions-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/



--
COMMENT:
--

Thanks to Ketan for the constructive discussion and changes. I've updated my
ballot to No Objection. I do hope the WG will consider properly replacing or
updating RFC5340, but that is not this document's problem.

NIT: IPSec -> IPsec  (no need for new draft, it can be fixed during the RFC
editing cycle)



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

Re: [Lsr] Paul Wouters' No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[Peter Psenak]

John,

I'll remove the MUST.

thanks,
Peter

On 08/06/2023 15:05, John Scudder wrote:

Hi Peter and all,


On Jun 8, 2023, at 2:43 AM, Peter Psenak  
wrote:


 A node MUST participate in a Flex-Algorithm to be:
 - Able to compute path for such Flex-Algorithm
 - Part of the topology for such Flex-Algorithm

This is an odd use of MUST.


what exactly is odd in it?


I don’t know what Paul found odd about it, but now that I’m looking at it 
afresh, I also think it’s odd. My reason is that it’s not expressing a 
requirement, it’s expressing a statement of fact, a natural consequence. An 
analogy would be if we said “if you let go of your coffee cup as you’re lifting 
it, it MUST fall down”. You don’t need a MUST there, gravity doesn’t care about 
your rules. To continue the analogy, a more usual use of MUST would be to 
express an actual requirement on the implementor — “you MUST NOT drink your 
coffee through a straw”.

I haven’t gone and re-checked in the doc to be sure, but as I recall, it’s not 
possible for a node to be part of the topology for a given FA unless it 
participates in the FA, and this would be true whether the quoted MUST were 
there or not.

$0.02,

—John


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

Re: [Lsr] Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[John Scudder]

Hi Zahed,

> On Jun 8, 2023, at 6:42 AM, Zaheduzzaman Sarker  
> wrote:
> 
> I can help with text if I can understand use case better. Right now that is 
> not the case.

Do you understand the use case and intent of the section well enough now that 
you’d be able to propose text?

Thanks,

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

Re: [Lsr] Paul Wouters' No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[John Scudder]

Hi Peter and all,

> On Jun 8, 2023, at 2:43 AM, Peter Psenak  
> wrote:
> 
>> A node MUST participate in a Flex-Algorithm to be:
>> - Able to compute path for such Flex-Algorithm
>> - Part of the topology for such Flex-Algorithm
>> 
>> This is an odd use of MUST.
> 
> what exactly is odd in it?

I don’t know what Paul found odd about it, but now that I’m looking at it 
afresh, I also think it’s odd. My reason is that it’s not expressing a 
requirement, it’s expressing a statement of fact, a natural consequence. An 
analogy would be if we said “if you let go of your coffee cup as you’re lifting 
it, it MUST fall down”. You don’t need a MUST there, gravity doesn’t care about 
your rules. To continue the analogy, a more usual use of MUST would be to 
express an actual requirement on the implementor — “you MUST NOT drink your 
coffee through a straw”.

I haven’t gone and re-checked in the doc to be sure, but as I recall, it’s not 
possible for a node to be part of the topology for a given FA unless it 
participates in the FA, and this would be true whether the quoted MUST were 
there or not.

$0.02,

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

[Lsr] Andrew Alston's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-14: (with COMMENT)

[Andrew Alston via Datatracker]

Andrew Alston has entered the following ballot position for
draft-ietf-lsr-ospfv3-srv6-extensions-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/



--
COMMENT:
--

Thanks for addressing my previous discuss and for your responsiveness!



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

Re: [Lsr] Andrew Alston's Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-13: (with DISCUSS)

[Ketan Talaulikar]

Hi Andrew,

I understand your point and thanks for your suggestion.

I've just posted an update that reflects this change:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-14

Thanks,
Ketan


On Thu, Jun 8, 2023 at 4:30 PM Andrew Alston - IETF 
wrote:

> Hi Ketan,
>
>
>
> Thanks for the clarification and apologies for the misunderstanding.
>
>
>
> What I would suggest is that a line be added to section 9 to make it
> explicitly clear that the end.x TLV’s are NOT sub-tlv’s of the locator –
> because while I realize on a second read that this is stated – it’s very
> easy to miss and I think this could end up with implementors making a
> similar mistake in the reading that I did.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From: *Ketan Talaulikar 
> *Date: *Thursday, 8 June 2023 at 13:16
> *To: *Andrew Alston - IETF 
> *Cc: *The IESG ,
> draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org <
> draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>, lsr-cha...@ietf.org <
> lsr-cha...@ietf.org>, lsr@ietf.org , a...@cisco.com <
> a...@cisco.com>
> *Subject: *Re: Andrew Alston's Discuss on
> draft-ietf-lsr-ospfv3-srv6-extensions-13: (with DISCUSS)
>
> CAUTION: This email has originated from a free email service commonly used
> for personal email services, please be guided accordingly especially if
> this email is asking to click links or share information.
>
>
>
> Hi Andrew,
>
>
>
> Thanks for your review and please check inline below for responses.
>
>
>
>
>
> On Thu, Jun 8, 2023 at 2:50 PM Andrew Alston via Datatracker <
> nore...@ietf.org> wrote:
>
> Andrew Alston has entered the following ballot position for
> draft-ietf-lsr-ospfv3-srv6-extensions-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
> --
> DISCUSS:
> --
>
> Hi There,
>
> Firstly thanks for the document.
>
> I'd like to have a discussion about the following text in Section 7.1.
>
> If the SRv6 Locator TLV for
>the same Locator appears in multiple SRv6 Locator LSAs that have the
>same flooding scope, the TLV in the SRv6 Locator LSA with the
>numerically smallest Link-State ID MUST be used and subsequent
>instances of the TLV MUST be ignored.
>
> My question may be as a result of not quite understanding the nature of
> End.X
> SID's - and as such, this may be easy to resolve.  But - Reading the
> document,
> you have a limit of the size of an OSPFv3 packet of 65535 bytes (with
> fragmentation - which I would argue you probably don't wanna rely on).
> Now, if
> you are stacking END.X sub-TLV's beneath a locator SID - and you require
> more
>
>
>
> KT> The End.X sub-TLVs are not advertised under the Locator TLV but as
> sub-TLVs of each link/adjacency under the E-Router-Link TLV - refer
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-13#section-9.
> Furthermore, the E-Router-LSA that carry the E-Router-Link TLV can have
> multiple instances to accomodate a large set of links - most granularly it
> could be one E-Router-LSA carrying a single link/adjacency each. This flows
> from the base OSPFv3 spec - refer
> https://datatracker.ietf.org/doc/html/rfc5340#section-4.4.3.2.
>
>
>
> than 4000 of them on a large device (though in reality its probably far
> less
> than this because of overhead etc - if you avoid fragmentation even on a
> large
> MTU network you're at under 500) you're going to run into a problem
> because you
> cannot split the announcement by using the same locator in subsequent
> LSA's (my
> understanding is that normally this would be accomplished by having the
> same
> locator in multiple LSA's with different LS ID's, that the router would
> then
> combine).
>
> So - the question is - under what scenarios are END.X and END sub tlv's
> added
> to the packet and advertised - and could we run into a major length problem
> here on large dense devices that are, for example, terminating huge
> numbers of
> cross connects.  Further to this, is there a reason why the locator cannot
> be
> split across multiple packets with different Link State ID's to reduce the
> size
> of the OSPF packets if this does become necessary?
>
>
>
> KT> As explained above, a large number of links would not result in growth
> of the SRv6 Locator TLV size. Since the SRv6 Locator is like an object on
> the same lines as a Link or a Prefix in OSPFv3, if it were to grow large
> the protocol mechanism today allow

[Lsr] I-D Action: draft-ietf-lsr-ospfv3-srv6-extensions-14.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Link State Routing
(LSR) WG of the IETF.

   Title   : OSPFv3 Extensions for SRv6
   Authors : Zhenbin Li
 Zhibo Hu
 Ketan Talaulikar
 Peter Psenak
   Filename: draft-ietf-lsr-ospfv3-srv6-extensions-14.txt
   Pages   : 29
   Date: 2023-06-08

Abstract:
   The Segment Routing (SR) architecture allows a flexible definition of
   the end-to-end path by encoding it as a sequence of topological
   elements called segments.  It can be implemented over an MPLS or IPv6
   data plane.  This document describes the OSPFv3 extensions required
   to support Segment Routing over the IPv6 data plane (SRv6).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-14

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospfv3-srv6-extensions-14

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] Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[Zaheduzzaman Sarker]

On Thu, Jun 8, 2023 at 1:58 PM Peter Psenak  wrote:

> Zahed,
>
> please see inline:
>
> On 08/06/2023 12:42, Zaheduzzaman Sarker wrote:
> >
> >
> > On Thu, Jun 8, 2023 at 9:36 AM Peter Psenak  > > wrote:
> >
> > Zahed,
> >
> > please see inline:
> >
> > On 08/06/2023 07:00, Zaheduzzaman Sarker via Datatracker wrote:
> >  > Zaheduzzaman Sarker has entered the following ballot position for
> >  > draft-ietf-lsr-ip-flexalgo-13: No Objection
> >  >
> >  > When responding, please keep the subject line intact and reply to
> all
> >  > email addresses included in the To and CC lines. (Feel free to
> > cut this
> >  > introductory paragraph, however.)
> >  >
> >  >
> >  > Please refer to
> >
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> <
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> >
> >  > for more information about how to handle DISCUSS and COMMENT
> > positions.
> >  >
> >  >
> >  > The document, along with other ballot positions, can be found
> here:
> >  > https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
> > 
> >  >
> >  >
> >  >
> >  >
> >
>  --
> >  > COMMENT:
> >  >
> >
>  --
> >  >
> >  > Thanks for working on this specification.
> >  >
> >  > I have no comment from TSV point of view. However, the
> > description in section 3
> >  > is a not clear to me. It references 5G system and N3 interfaces
> > then describes
> >  > the need for UPF selection based on some sort of session needs.
> > However, I
> >  > could not relate how IP addresses plays role in that selection
> > and where in 5G
> >  > system this is done or planned to be done based of IP addresses?
> > is there any
> >  > deployment case or already deployed UPF selection based on just
> > IP addresses?
> >
> > yes. The real field example is where the mobile site accepts both
> data
> > and voice traffic. Voice traffic is sent from mobile site to the
> voice
> > gateway that has its own unique address. That traffic needs low
> latency
> > paths. Rest of the data traffic is routed to its destination using
> best
> > effort path.
> >
> >
> > Here, I think you are talking about the QoS framework that 3GPP has ,
> > and it also involves radio bearer, radio schedulers and more.
>
> we are not claiming it's 5G specific. We are using 5G as an example -
> the section name has "Example" in it. We picked the 5G example because
> that is one of the real field deployments, where IP Flex-algo is used.
>
> In the context of this draft, we focus on IP, radio portion is unchanged.
>

OK then lets make that clear in the specification, even if this is an
example.


>
> > The IP
> > address only could be one part of it.
>
> certainly, but that is the part relevant to this draft.
>
> > It is not the case that if you
> > have certain IP address your traffic would get the extra treatment it
> > wants.
>
> no, but with IP flex-algo, we can make it that way.
>

Also make is clear that it is the intention or a potential case. Obviously
if it is the main intention then it need to be clearly written.


>
> > The bearer concept is not new to 5G system and applicable to 4G
> > system as well. The current text I think is very shy on explaining the
> > concept and relating it to IP address.
>
> All we say is that if the specific traffic/service can be identified by
> the IP address, traffic to it can use constrained based paths using IP
> algo.
>

That was not so obvious to me. Again, if we clarify it then it will be very
helpful.

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

Re: [Lsr] Andrew Alston's Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-13: (with DISCUSS)

[Andrew Alston - IETF]

Hi Ketan,

Thanks for the clarification and apologies for the misunderstanding.

What I would suggest is that a line be added to section 9 to make it explicitly 
clear that the end.x TLV’s are NOT sub-tlv’s of the locator – because while I 
realize on a second read that this is stated – it’s very easy to miss and I 
think this could end up with implementors making a similar mistake in the 
reading that I did.

Thanks

Andrew


From: Ketan Talaulikar 
Date: Thursday, 8 June 2023 at 13:16
To: Andrew Alston - IETF 
Cc: The IESG , draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org 
, lsr-cha...@ietf.org 
, lsr@ietf.org , a...@cisco.com 

Subject: Re: Andrew Alston's Discuss on 
draft-ietf-lsr-ospfv3-srv6-extensions-13: (with DISCUSS)
CAUTION: This email has originated from a free email service commonly used for 
personal email services, please be guided accordingly especially if this email 
is asking to click links or share information.

Hi Andrew,

Thanks for your review and please check inline below for responses.


On Thu, Jun 8, 2023 at 2:50 PM Andrew Alston via Datatracker 
mailto:nore...@ietf.org>> wrote:
Andrew Alston has entered the following ballot position for
draft-ietf-lsr-ospfv3-srv6-extensions-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/



--
DISCUSS:
--

Hi There,

Firstly thanks for the document.

I'd like to have a discussion about the following text in Section 7.1.

If the SRv6 Locator TLV for
   the same Locator appears in multiple SRv6 Locator LSAs that have the
   same flooding scope, the TLV in the SRv6 Locator LSA with the
   numerically smallest Link-State ID MUST be used and subsequent
   instances of the TLV MUST be ignored.

My question may be as a result of not quite understanding the nature of End.X
SID's - and as such, this may be easy to resolve.  But - Reading the document,
you have a limit of the size of an OSPFv3 packet of 65535 bytes (with
fragmentation - which I would argue you probably don't wanna rely on).  Now, if
you are stacking END.X sub-TLV's beneath a locator SID - and you require more

KT> The End.X sub-TLVs are not advertised under the Locator TLV but as sub-TLVs 
of each link/adjacency under the E-Router-Link TLV - refer 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-13#section-9.
 Furthermore, the E-Router-LSA that carry the E-Router-Link TLV can have 
multiple instances to accomodate a large set of links - most granularly it 
could be one E-Router-LSA carrying a single link/adjacency each. This flows 
from the base OSPFv3 spec - refer 
https://datatracker.ietf.org/doc/html/rfc5340#section-4.4.3.2.

than 4000 of them on a large device (though in reality its probably far less
than this because of overhead etc - if you avoid fragmentation even on a large
MTU network you're at under 500) you're going to run into a problem because you
cannot split the announcement by using the same locator in subsequent LSA's (my
understanding is that normally this would be accomplished by having the same
locator in multiple LSA's with different LS ID's, that the router would then
combine).

So - the question is - under what scenarios are END.X and END sub tlv's added
to the packet and advertised - and could we run into a major length problem
here on large dense devices that are, for example, terminating huge numbers of
cross connects.  Further to this, is there a reason why the locator cannot be
split across multiple packets with different Link State ID's to reduce the size
of the OSPF packets if this does become necessary?

KT> As explained above, a large number of links would not result in growth of 
the SRv6 Locator TLV size. Since the SRv6 Locator is like an object on the same 
lines as a Link or a Prefix in OSPFv3, if it were to grow large the protocol 
mechanism today allows it to grow to the largest IP packet size of 64K (and 
subject to IP fragmentation). The OSPFv3 level fragmentation is available at an 
object level - i.e. different LSAs for each individual link or prefix or 
locator object is possible. If we ever get to a situation where we need to 
extend this protocol 

Re: [Lsr] Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[Peter Psenak]

Zahed,

please see inline:

On 08/06/2023 12:42, Zaheduzzaman Sarker wrote:



On Thu, Jun 8, 2023 at 9:36 AM Peter Psenak > wrote:


Zahed,

please see inline:

On 08/06/2023 07:00, Zaheduzzaman Sarker via Datatracker wrote:
 > Zaheduzzaman Sarker has entered the following ballot position for
 > draft-ietf-lsr-ip-flexalgo-13: No Objection
 >
 > When responding, please keep the subject line intact and reply to all
 > email addresses included in the To and CC lines. (Feel free to
cut this
 > introductory paragraph, however.)
 >
 >
 > Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 

 > for more information about how to handle DISCUSS and COMMENT
positions.
 >
 >
 > The document, along with other ballot positions, can be found here:
 > https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/

 >
 >
 >
 >
--
 > COMMENT:
 >
--
 >
 > Thanks for working on this specification.
 >
 > I have no comment from TSV point of view. However, the
description in section 3
 > is a not clear to me. It references 5G system and N3 interfaces
then describes
 > the need for UPF selection based on some sort of session needs.
However, I
 > could not relate how IP addresses plays role in that selection
and where in 5G
 > system this is done or planned to be done based of IP addresses?
is there any
 > deployment case or already deployed UPF selection based on just
IP addresses?

yes. The real field example is where the mobile site accepts both data
and voice traffic. Voice traffic is sent from mobile site to the voice
gateway that has its own unique address. That traffic needs low latency
paths. Rest of the data traffic is routed to its destination using best
effort path.


Here, I think you are talking about the QoS framework that 3GPP has , 
and it also involves radio bearer, radio schedulers and more. 


we are not claiming it's 5G specific. We are using 5G as an example - 
the section name has "Example" in it. We picked the 5G example because 
that is one of the real field deployments, where IP Flex-algo is used.


In the context of this draft, we focus on IP, radio portion is unchanged.

The IP 
address only could be one part of it. 


certainly, but that is the part relevant to this draft.

It is not the case that if you 
have certain IP address your traffic would get the extra treatment it 
wants. 


no, but with IP flex-algo, we can make it that way.

The bearer concept is not new to 5G system and applicable to 4G 
system as well. The current text I think is very shy on explaining the 
concept and relating it to IP address.


All we say is that if the specific traffic/service can be identified by 
the IP address, traffic to it can use constrained based paths using IP 
algo.


thanks,
Peter




 >
 > If this section supposed to be the motivation of this whole
specification then
 > it need to be improved in description on how this specification
helps in the
 > usecase it describes. Or may be removed from the specification.

Section 3 is an example of the use case. It's one of the motivations
behind the spec.

I don't mind removing it, but I feel it has some value. Not sure how to
improve it, if you can suggest the better wording, I can certainly
use it.


I can help with text if I can understand use case better. Right now that 
is not the case.


//Zahed


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

Re: [Lsr] Zaheduzzaman Sarker's No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)

[Zaheduzzaman Sarker]

On Thu, Jun 8, 2023 at 9:36 AM Peter Psenak  wrote:

> Zahed,
>
> please see inline:
>
> On 08/06/2023 07:00, Zaheduzzaman Sarker via Datatracker wrote:
> > Zaheduzzaman Sarker has entered the following ballot position for
> > draft-ietf-lsr-ip-flexalgo-13: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Thanks for working on this specification.
> >
> > I have no comment from TSV point of view. However, the description in
> section 3
> > is a not clear to me. It references 5G system and N3 interfaces then
> describes
> > the need for UPF selection based on some sort of session needs. However,
> I
> > could not relate how IP addresses plays role in that selection and where
> in 5G
> > system this is done or planned to be done based of IP addresses? is
> there any
> > deployment case or already deployed UPF selection based on just IP
> addresses?
>
> yes. The real field example is where the mobile site accepts both data
> and voice traffic. Voice traffic is sent from mobile site to the voice
> gateway that has its own unique address. That traffic needs low latency
> paths. Rest of the data traffic is routed to its destination using best
> effort path.
>

Here, I think you are talking about the QoS framework that 3GPP has , and
it also involves radio bearer, radio schedulers and more. The IP address
only could be one part of it. It is not the case that if you have certain
IP address your traffic would get the extra treatment it wants. The bearer
concept is not new to 5G system and applicable to 4G system as well. The
current text I think is very shy on explaining the concept and relating it
to IP address.


>
> >
> > If this section supposed to be the motivation of this whole
> specification then
> > it need to be improved in description on how this specification helps in
> the
> > usecase it describes. Or may be removed from the specification.
>
> Section 3 is an example of the use case. It's one of the motivations
> behind the spec.
>
> I don't mind removing it, but I feel it has some value. Not sure how to
> improve it, if you can suggest the better wording, I can certainly use it.
>

I can help with text if I can understand use case better. Right now that is
not the case.

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

Re: [Lsr] Andrew Alston's Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-13: (with DISCUSS)

[Ketan Talaulikar]

Hi Andrew,

Thanks for your review and please check inline below for responses.


On Thu, Jun 8, 2023 at 2:50 PM Andrew Alston via Datatracker <
nore...@ietf.org> wrote:

> Andrew Alston has entered the following ballot position for
> draft-ietf-lsr-ospfv3-srv6-extensions-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
> --
> DISCUSS:
> --
>
> Hi There,
>
> Firstly thanks for the document.
>
> I'd like to have a discussion about the following text in Section 7.1.
>
> If the SRv6 Locator TLV for
>the same Locator appears in multiple SRv6 Locator LSAs that have the
>same flooding scope, the TLV in the SRv6 Locator LSA with the
>numerically smallest Link-State ID MUST be used and subsequent
>instances of the TLV MUST be ignored.
>
> My question may be as a result of not quite understanding the nature of
> End.X
> SID's - and as such, this may be easy to resolve.  But - Reading the
> document,
> you have a limit of the size of an OSPFv3 packet of 65535 bytes (with
> fragmentation - which I would argue you probably don't wanna rely on).
> Now, if
> you are stacking END.X sub-TLV's beneath a locator SID - and you require
> more
>

KT> The End.X sub-TLVs are not advertised under the Locator TLV but as
sub-TLVs of each link/adjacency under the E-Router-Link TLV - refer
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-13#section-9.
Furthermore, the E-Router-LSA that carry the E-Router-Link TLV can have
multiple instances to accomodate a large set of links - most granularly it
could be one E-Router-LSA carrying a single link/adjacency each. This flows
from the base OSPFv3 spec - refer
https://datatracker.ietf.org/doc/html/rfc5340#section-4.4.3.2.


> than 4000 of them on a large device (though in reality its probably far
> less
> than this because of overhead etc - if you avoid fragmentation even on a
> large
> MTU network you're at under 500) you're going to run into a problem
> because you
> cannot split the announcement by using the same locator in subsequent
> LSA's (my
> understanding is that normally this would be accomplished by having the
> same
> locator in multiple LSA's with different LS ID's, that the router would
> then
> combine).
>
> So - the question is - under what scenarios are END.X and END sub tlv's
> added
> to the packet and advertised - and could we run into a major length problem
> here on large dense devices that are, for example, terminating huge
> numbers of
> cross connects.  Further to this, is there a reason why the locator cannot
> be
> split across multiple packets with different Link State ID's to reduce the
> size
> of the OSPF packets if this does become necessary?
>

KT> As explained above, a large number of links would not result in growth
of the SRv6 Locator TLV size. Since the SRv6 Locator is like an object on
the same lines as a Link or a Prefix in OSPFv3, if it were to grow large
the protocol mechanism today allows it to grow to the largest IP packet
size of 64K (and subject to IP fragmentation). The OSPFv3 level
fragmentation is available at an object level - i.e. different LSAs for
each individual link or prefix or locator object is possible. If we ever
get to a situation where we need to extend this protocol fragmentation
capability, we would need to come up with a generic OSPFv3 mechanism to
break a single object into multiple parts for all types of objects - not
just the SRv6 Locator. IMHO, we don't yet have a case to do so.

Thanks,
Ketan


>
> (I do realise that you could use multiple locators on the same router to
> split
> this up - but would argue thats going to create operational nightmares and
> lead
> to potentially big problems with admins having to figure out when they are
> going to hit the limit)
>
>
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Andrew Alston's Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-13: (with DISCUSS)

[Andrew Alston via Datatracker]

Andrew Alston has entered the following ballot position for
draft-ietf-lsr-ospfv3-srv6-extensions-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/



--
DISCUSS:
--

Hi There,

Firstly thanks for the document.

I'd like to have a discussion about the following text in Section 7.1.

If the SRv6 Locator TLV for
   the same Locator appears in multiple SRv6 Locator LSAs that have the
   same flooding scope, the TLV in the SRv6 Locator LSA with the
   numerically smallest Link-State ID MUST be used and subsequent
   instances of the TLV MUST be ignored.

My question may be as a result of not quite understanding the nature of End.X
SID's - and as such, this may be easy to resolve.  But - Reading the document,
you have a limit of the size of an OSPFv3 packet of 65535 bytes (with
fragmentation - which I would argue you probably don't wanna rely on).  Now, if
you are stacking END.X sub-TLV's beneath a locator SID - and you require more
than 4000 of them on a large device (though in reality its probably far less
than this because of overhead etc - if you avoid fragmentation even on a large
MTU network you're at under 500) you're going to run into a problem because you
cannot split the announcement by using the same locator in subsequent LSA's (my
understanding is that normally this would be accomplished by having the same
locator in multiple LSA's with different LS ID's, that the router would then
combine).

So - the question is - under what scenarios are END.X and END sub tlv's added
to the packet and advertised - and could we run into a major length problem
here on large dense devices that are, for example, terminating huge numbers of
cross connects.  Further to this, is there a reason why the locator cannot be
split across multiple packets with different Link State ID's to reduce the size
of the OSPF packets if this does become necessary?

(I do realise that you could use multiple locators on the same router to split
this up - but would argue thats going to create operational nightmares and lead
to potentially big problems with admins having to figure out when they are
going to hit the limit)





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