Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Aijun Wang]

Hi, Linda:

 

Scenario 1 is straightforward and is the local decision of the router. Do we
need the draft then?

For scenario 2, I am considering where is the right place to place such
information. The consideration in my previous mail is not addressed.

It seems RFC8362 does not illustrate which "OSPFv3 Extended-LSA Sub-TLVs"
(https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#
extended-lsa-sub-tlvs) should be put into which "OSPFv3 Extended-LSA TLVs"? 

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Linda Dunbar
Sent: Thursday, December 17, 2020 11:09 AM
To: Aijun Wang ; 'Acee Lindem (acee)'
; 'Jeff Tantsura'
; 'Yingzhen Qu' ;
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot
Requests

 

Aijun, 

 

Thank you for the analysis and suggestions. 

 

The draft specified 3 Sub-TLVs to carry the IP Layer Metrics to Gauge App
Server Running Status: Load Measurement; Capacity Index; and Preference
Index. More may be added in the future, especially when there are more
information about UEs and their flows that can be passed from 5G Network
Exposure Functions. 

 

Let's consider two different scenarios:

Scenario 1: 

All the Egress routers to which the App Servers are attached can be
configured with a consistent algorithm to compute an aggregated cost that
take into consideration of Load Measurement, Capacity value and Preference
value. Then this aggregated cost can be encoded in the Metric field [the
interface cost] of Intra-Area-Prefix-LSA for  IPv6 [ RFC5340], or  encoded
in the "Metric" field of the Stub Link LSA [Link type =3] [RFC2328] for
IPv4. 

In this scenario, there is no protocol extension needed, but requires all
egress routers to agree upon a consistent algorithm to compute the cost to
the App server (Prefix)

 

Scenario 2: 

Either it is not possible for all the egress routers to have a consistent
algorithm to compute the aggregated cost, or the ingress routers need all
the detailed IP Layer metrics for the App Servers for other purposes. Then,
the IP Layer Metrics to Gauge App Server running status need to be encoded
in LSAs to other nodes. Under this scenario, it makes sense to use the
OSPFv2 Extended Prefix Opaque LSA for IPv4 and OSPFv3 Extended LSA with
Intra-Area-Prefix TLV to carry the detailed sub-TLVs proposed in the draft,
so that nodes that don't care about those metrics can ignore them very
easily. 

 

For OSPFv2 Extended Prefix Opaque LSA or OSPFv3 Extended LSA, the receiving
nodes, who care about the information, have to adjust path compute engine
anyway to derive the lowest cost path that takes the IP Layer Metrics into
consideration. 

 

Do you agree with this approach? 

 

We will revise the draft to reflect those two different scenarios. 

 

 

Linda 

 

 

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> > 
Sent: Tuesday, December 15, 2020 9:45 PM
To: 'Acee Lindem (acee)' mailto:acee=40cisco@dmarc.ietf.org> >; 'Jeff Tantsura'
mailto:jefftant.i...@gmail.com> >; 'Yingzhen Qu'
mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org
 ; lsr-cha...@ietf.org  ;
Linda Dunbar mailto:linda.dun...@futurewei.com>
>
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot
Requests

 

Hi, Acee and Linda:

 

The mentioned information in this draft are more related to the links that
connect the server to the edge router, than to the prefix of the app server.

For example, the "Capacity Index", "Preference Index" are all related to the
site, not the prefix. 

And, for "Load Measurement", it is not enough to detect only the load to the
server, but omits the load status of the link that connected the servers.

We should also considering the future possible extension, such as the
bandwidth reservation on these links to the App server etc.

 

In conclusion, associate these attributes to the link is more reasonable
than to the prefix.

Such links are another typical use case of passive/stub link within the
network.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org> > On Behalf Of Acee
Lindem (acee)
Sent: Thursday, November 5, 2020 8:42 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>
>; Yingzhen Qu mailto:yingzhen.i...@gmail.com> >;
lsr@ietf.org  ; lsr-cha...@ietf.org
 ; Linda Dunbar mailto:linda.dun...@futurewei.com> >
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot
Requests

 

Exactly. 

Thanks,
Acee

 

From: Jeff Tantsura mailto:jefftant.i...@gmail.com> >
Date: Wednesday, November 4, 2020 at 6:16 PM
To: Acee 

Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Linda Dunbar]

Aijun,

Thank you for the analysis and suggestions.

The draft specified 3 Sub-TLVs to carry the IP Layer Metrics to Gauge App 
Server Running Status: Load Measurement; Capacity Index; and Preference Index. 
More may be added in the future, especially when there are more information 
about UEs and their flows that can be passed from 5G Network Exposure Functions.

Let's consider two different scenarios:

Scenario 1:

All the Egress routers to which the App Servers are attached can be configured 
with a consistent algorithm to compute an aggregated cost that take into 
consideration of Load Measurement, Capacity value and Preference value. Then 
this aggregated cost can be encoded in the Metric field [the interface cost] of 
Intra-Area-Prefix-LSA for  IPv6 [ RFC5340], or  encoded in the "Metric" field 
of the Stub Link LSA [Link type =3] [RFC2328] for IPv4.

In this scenario, there is no protocol extension needed, but requires all 
egress routers to agree upon a consistent algorithm to compute the cost to the 
App server (Prefix)



Scenario 2:

Either it is not possible for all the egress routers to have a consistent 
algorithm to compute the aggregated cost, or the ingress routers need all the 
detailed IP Layer metrics for the App Servers for other purposes. Then, the IP 
Layer Metrics to Gauge App Server running status need to be encoded in LSAs to 
other nodes. Under this scenario, it makes sense to use the OSPFv2 Extended 
Prefix Opaque LSA for IPv4 and OSPFv3 Extended LSA with Intra-Area-Prefix TLV 
to carry the detailed sub-TLVs proposed in the draft, so that nodes that don't 
care about those metrics can ignore them very easily.



For OSPFv2 Extended Prefix Opaque LSA or OSPFv3 Extended LSA, the receiving 
nodes, who care about the information, have to adjust path compute engine 
anyway to derive the lowest cost path that takes the IP Layer Metrics into 
consideration.

Do you agree with this approach?

We will revise the draft to reflect those two different scenarios.


Linda



From: Aijun Wang 
Sent: Tuesday, December 15, 2020 9:45 PM
To: 'Acee Lindem (acee)' ; 'Jeff Tantsura' 
; 'Yingzhen Qu' ; 
lsr@ietf.org; lsr-cha...@ietf.org; Linda Dunbar 
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Hi, Acee and Linda:

The mentioned information in this draft are more related to the links that 
connect the server to the edge router, than to the prefix of the app server.
For example, the "Capacity Index", "Preference Index" are all related to the 
site, not the prefix.
And, for "Load Measurement", it is not enough to detect only the load to the 
server, but omits the load status of the link that connected the servers.
We should also considering the future possible extension, such as the bandwidth 
reservation on these links to the App server etc.

In conclusion, associate these attributes to the link is more reasonable than 
to the prefix.
Such links are another typical use case of passive/stub link within the network.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Thursday, November 5, 2020 8:42 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org; 
lsr-cha...@ietf.org; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Exactly.
Thanks,
Acee

From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Date: Wednesday, November 4, 2020 at 6:16 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

For OSPFv3 use E-LSAs (RFC8362)

Cheers,
Jeff
On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>, wrote:
Acee,

Thank you very much for suggesting using the Prefix TLV for carry the Running 
Status and environment of 5G Edge Computing servers.

In a nutshell, the 

Re: [Lsr] Yangdoctors last call review of draft-ietf-lsr-yang-isis-reverse-metric-01

[Acee Lindem (acee)]

Hi Lada, 
Thanks for your prompt and thorough review. 

Hi Chris, 
Please address the comments.
Thanks,
Acee

On 12/16/20, 7:13 AM, "Ladislav Lhotka via Datatracker"  
wrote:

Reviewer: Ladislav Lhotka
Review result: Ready with Issues

 General comments

- YANG module "ietf-isis-reverse-metric" is in a good shape except for
  one issue described below.
- I appreciate the three examples of instance data in appendices (two
  in XML representation, one in JSON).

 Specific comments

- In three places, the module uses "when" expressions with plain
  string equality test applied to identityref values, such as:

 when "../rt:type = 'isis:isis'"

  This is known to be fragile, which can demonstrated on the JSON
  example in appendix A.3: It has

 "type": "ietf-isis:isis"

  which makes the "when" expression false because of the different
  prefix, and the corresponding augment doesn't happen.

  The above "when" expression should use the XPath function
  "derived-from-or-self" that is defined in RFC 7950:

 when "derived-from-or-self(../rt:type, 'isis:isis')"  

- The "tlv16-reverse-metric" grouping is used only once in the
  module. Unless it is expected to be used elsewhere, I would
  recommend to remove this grouping and use its contents directly.

- The phrase "YANG XML data" is somewhat misleading, although it is
  probably often used in informal discussions. I would suggest "XML
  instance data" instead.

 Nits

- Abstract & Introduction: s/routeing/routing/

- Appending A.3: s/YANG XML data/JSON instance data/




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

[Lsr] Yangdoctors last call review of draft-ietf-lsr-yang-isis-reverse-metric-01

[Ladislav Lhotka via Datatracker]

Reviewer: Ladislav Lhotka
Review result: Ready with Issues

 General comments

- YANG module "ietf-isis-reverse-metric" is in a good shape except for
  one issue described below.
- I appreciate the three examples of instance data in appendices (two
  in XML representation, one in JSON).

 Specific comments

- In three places, the module uses "when" expressions with plain
  string equality test applied to identityref values, such as:

 when "../rt:type = 'isis:isis'"

  This is known to be fragile, which can demonstrated on the JSON
  example in appendix A.3: It has

 "type": "ietf-isis:isis"

  which makes the "when" expression false because of the different
  prefix, and the corresponding augment doesn't happen.

  The above "when" expression should use the XPath function
  "derived-from-or-self" that is defined in RFC 7950:

 when "derived-from-or-self(../rt:type, 'isis:isis')"  
  
- The "tlv16-reverse-metric" grouping is used only once in the
  module. Unless it is expected to be used elsewhere, I would
  recommend to remove this grouping and use its contents directly.

- The phrase "YANG XML data" is somewhat misleading, although it is
  probably often used in informal discussions. I would suggest "XML
  instance data" instead.

 Nits

- Abstract & Introduction: s/routeing/routing/

- Appending A.3: s/YANG XML data/JSON instance data/



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