date:20201104

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

2020-11-04 Thread Aijun Wang

Hi, Linda:

 

Is it better to add some analysis for the flooding influences on the router 
performance when we add such dynamic information within the IGP protocol?

 

 

Best Regards

 

Aijun Wang

China Telecom

 

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

 

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 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 
proposes the extension to LSA that can carry the three SubTLVs that are used to 
represent the Running Status and Environment information of the 5G Edge 
Computing Servers attached to the router:

 

Ø  Load measurement sub-TLV  

Ø  Capacity Index  Sub-TLV 

Ø  Preference Index  Sub-TLV   

 

Several sections of the draft are devoted to describe what those measurement 
are and why need them for 5G Edge Computing, which may have made it not so 
straightforward when reading in a rush. 

 

The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA 
to be advertised to other routers in the 5G Local Data Network. 

 

If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension does 
seem easier and cleaner: 

 

We can have: 

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type  | Length|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Route Type| Prefix Length | AF| Flags |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Address Prefix (variable) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

| Load Measurement Sub-TLV  | 

~   ~ 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

| capacity Index Sub-TLV| 

~   ~ 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

| Site Preference Sub-TLV   | 

~   ~  

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

 

 

RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server addresses 
are in IPv6, should we specify the extension to RFC8362 in the same draft? Or 
define a new AF type for the same extension to RFC7684? 

 

Your guidance is greatly appreciated. 

 

Thank you very much. 

 

Linda Dunbar

 

 

From: Acee Lindem (acee) mailto:a...@cisco.com> > 
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar mailto:linda.dun...@futurewei.com> >; Yingzhen Qu mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org  ; 
lsr-cha...@ietf.org  
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

 

We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partially specified. It could benefit 
from some WG mailing list discussion prior to a 10 minute presentation where we 
wouldn’t have time to discuss the many issues. 

 

One major issue is that you should be extending RFC 7684 rather than RFC 3630 
and it seems you these app-server selection metrics should be associated with a 
prefix and NOT a stub link (i.e., the application server address).

 

I’ll try to read it in more depth before IETF 109. 

 

Thanks,
Acee

 

From: Linda Dunbar mailto:linda.dun...@futurewei.com> >
Date: Monday, November 2, 2020 at 10:12 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com> >, 
"lsr@ietf.org  " mailto:lsr@ietf.org> >, 
"lsr-cha...@ietf.org  " mailto:lsr-cha...@ietf.org> >
Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
(was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
Resent-From: mailto:alias-boun...@ietf.org> >
Resent-To: Yingzhen Qu mailto:yingzhen.i...@gmail.com> >, Acee Lindem mailto:a...@cisco.com> >, Christian Hopps mailto:cho...@chopps.org> >
Resent-Date: Monday, November 2, 2020 at 10:12 PM

 

LSR Chairs, YingZhen, 

 

Can you give us 10 minute slot to present this new draft:

https://

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-11-04 Thread Aijun Wang

Hi, Acee:

Thanks for this comments.
The consideration for the position of flagging the passive interface have been 
stated in the updated 05 version 
https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-05#section-3,
 as the followings:

   ISIS [RFC5029] defines the Link-Attributes Sub-TLV to carry the link
   attribute information, but this Sub-TLV can only be carried within
   the TLV 22, which is used to described the attached neighbor.  For
   passive interface, there is no ISIS neighbor, then it is not
   appropriate to use this Sub-TLV to indicate the passive attribute of
   the interface.

   OSPFv2[RFC2328] defines link type field within Router LSA, the type 3
   for connections to a stub network can be used to identified the
   passive interface.  But in OSPFv3 [RFC5340], type 3 within the
   Router-LSA has been reserved.  The information that associated with
   stub network has been put in the Intra-Area-Prefix-LSAs.

What about your opinions regarding to the above statements? Currently, we think 
putting the flag within the prefix attribute that associated the passive 
interface is appropriate.
If we can find other appropriate/acceptable place to hold this information, we 
can also update the draft later accordingly.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Thursday, November 5, 2020 4:11 AM
To: Aijun Wang 
Cc: Aijun Wang ; Peter Psenak (ppsenak) 
; lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt

Hi Aijun,
You still didn't answer the question as to why you didn't rework this draft for 
passive interface to be an interface attribute rather than a prefix attribute? 
Thanks,
Acee

On 10/1/20, 6:13 AM, "Acee Lindem (acee)"  wrote:

Hi Aijun, 
You didn't answer my question and pruned my message. Other than your 
attempt to expose the topology of areas outside the area, there is no other 
reason to associate the passive interface attribute with a prefix. We seem to 
be in a circular discussion 
Acee

On 9/30/20, 10:43 PM, "wang...@chinatelecom.cn on behalf of Aijun Wang" 
 wrote:

Hi, Acee:
Except the corner cases of unnumbered interface, would you like to 
illustrate other scenarios that the process does not apply?
As mentioned in last mail, knowing the passive interfaces can assist 
the nodes or controller know the boundaries of the network.

Aijun Wang
China Telecom

> On Sep 30, 2020, at 19:47, Acee Lindem (acee)  wrote:
> 

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

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

2020-11-04 Thread Acee Lindem (acee)

Exactly.
Thanks,
Acee

From: Jeff Tantsura 
Date: Wednesday, November 4, 2020 at 6:16 PM
To: Acee Lindem , 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

For OSPFv3 use E-LSAs (RFC8362)

Cheers,
Jeff
On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar , 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 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 
proposes the extension to LSA that can carry the three SubTLVs that are used to 
represent the Running Status and Environment information of the 5G Edge 
Computing Servers attached to the router:

 • Load measurement sub-TLV
 • Capacity Index  Sub-TLV
 • Preference Index  Sub-TLV

Several sections of the draft are devoted to describe what those measurement 
are and why need them for 5G Edge Computing, which may have made it not so 
straightforward when reading in a rush.

The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA 
to be advertised to other routers in the 5G Local Data Network.

If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension does 
seem easier and cleaner:

We can have:
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type| Prefix Length | AF| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Measurement Sub-TLV  |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capacity Index Sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site Preference Sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server addresses 
are in IPv6, should we specify the extension to RFC8362 in the same draft? Or 
define a new AF type for the same extension to RFC7684?

Your guidance is greatly appreciated.

Thank you very much.

Linda Dunbar

From: Acee Lindem (acee) 
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partially specified. It could benefit 
from some WG mailing list discussion prior to a 10 minute presentation where we 
wouldn’t have time to discuss the many issues.

One major issue is that you should be extending RFC 7684 rather than RFC 3630 
and it seems you these app-server selection metrics should be associated with a 
prefix and NOT a stub link (i.e., the application server address).

I’ll try to read it in more depth before IETF 109.

Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, November 2, 2020 at 10:12 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>
Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
(was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Monday, November 2, 2020 at 10:12 PM

LSR Chairs, YingZhen,

Can you give us 10 minute slot to present this new draft:
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/

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

2020-11-04 Thread Jeff Tantsura

For OSPFv3 use E-LSAs (RFC8362)

Cheers,
Jeff
On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar , 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 
> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 
> proposes the extension to LSA that can carry the three SubTLVs that are used 
> to represent the Running Status and Environment information of the 5G Edge 
> Computing Servers attached to the router:
>
>  • Load measurement sub-TLV
>  • Capacity Index  Sub-TLV
>  • Preference Index  Sub-TLV
>
> Several sections of the draft are devoted to describe what those measurement 
> are and why need them for 5G Edge Computing, which may have made it not so 
> straightforward when reading in a rush.
>
> The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA 
> to be advertised to other routers in the 5G Local Data Network.
>
> If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension 
> does seem easier and cleaner:
>
> We can have:
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type                          | Length                        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Route Type    | Prefix Length | AF            | Flags         |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Address Prefix (variable)                                     |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Load Measurement Sub-TLV                                      |
> ~                                                               ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | capacity Index Sub-TLV                                        |
> ~                                                               ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Site Preference Sub-TLV                                       |
> ~                                                               ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server 
> addresses are in IPv6, should we specify the extension to RFC8362 in the same 
> draft? Or define a new AF type for the same extension to RFC7684?
>
> Your guidance is greatly appreciated.
>
> Thank you very much.
>
> Linda Dunbar
>
>
> From: Acee Lindem (acee) 
> Sent: Tuesday, November 3, 2020 1:38 PM
> To: Linda Dunbar ; Yingzhen Qu 
> ; lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
> Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
>
> We have a pretty full schedule and we add you as optional. I took a look at 
> the draft and it is all over the place right now with standardization 
> requested for one solution but 3 separate solutions partially specified. It 
> could benefit from some WG mailing list discussion prior to a 10 minute 
> presentation where we wouldn’t have time to discuss the many issues.
>
> One major issue is that you should be extending RFC 7684 rather than RFC 3630 
> and it seems you these app-server selection metrics should be associated with 
> a prefix and NOT a stub link (i.e., the application server address).
>
> I’ll try to read it in more depth before IETF 109.
>
> Thanks,
> Acee
>
> From: Linda Dunbar 
> Date: Monday, November 2, 2020 at 10:12 PM
> To: Yingzhen Qu , "lsr@ietf.org" , 
> "lsr-cha...@ietf.org" 
> Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
> (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
> Resent-From: 
> Resent-To: Yingzhen Qu , Acee Lindem 
> , Christian Hopps 
> Resent-Date: Monday, November 2, 2020 at 10:12 PM
>
> LSR Chairs, YingZhen,
>
> Can you give us 10 minute slot to present this new draft:
> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/
>
> This draft describes an OSPF extension that can distribute the 5G Edge 
> Computing App running status and environment, so that other routers in the 5G 
> Local Data Network can make intelligent decision on optimizing forwarding of 
> flows from UEs. The goal is to improve latency and performance for 5G Edge 
> Computing services.
>
> Thank you very much,
>
> Linda Dunbar
>
> From: Lsr  On Behalf Of Yingzhen Qu
> Sent: Monday, October 19, 2020 3:52 PM
> To: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: [Lsr] IETF 109 LSR Presentation Slot Requests
>
> Hi all,
>
> We're now accepting agenda requests for the LSR Working Grouping meeting IETF 
> 109. Please send your requests to lsr-cha...@ietf.org indicating draft name, 
> speaker, and desired duration (covering presentation and discussion).
>
> LSR session is scheduled on Monday, Nov 16, 12:00-14:00 ICT.
>
> Th

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

2020-11-04 Thread Linda Dunbar

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 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 
proposes the extension to LSA that can carry the three SubTLVs that are used to 
represent the Running Status and Environment information of the 5G Edge 
Computing Servers attached to the router:


  *   Load measurement sub-TLV
  *   Capacity Index  Sub-TLV
  *   Preference Index  Sub-TLV

Several sections of the draft are devoted to describe what those measurement 
are and why need them for 5G Edge Computing, which may have made it not so 
straightforward when reading in a rush.

The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA 
to be advertised to other routers in the 5G Local Data Network.

If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension does 
seem easier and cleaner:

We can have:
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type| Prefix Length | AF| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Measurement Sub-TLV  |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capacity Index Sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site Preference Sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server addresses 
are in IPv6, should we specify the extension to RFC8362 in the same draft? Or 
define a new AF type for the same extension to RFC7684?

Your guidance is greatly appreciated.

Thank you very much.

Linda Dunbar


From: Acee Lindem (acee) 
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partially specified. It could benefit 
from some WG mailing list discussion prior to a 10 minute presentation where we 
wouldn’t have time to discuss the many issues.

One major issue is that you should be extending RFC 7684 rather than RFC 3630 
and it seems you these app-server selection metrics should be associated with a 
prefix and NOT a stub link (i.e., the application server address).

I’ll try to read it in more depth before IETF 109.

Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, November 2, 2020 at 10:12 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>
Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
(was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Monday, November 2, 2020 at 10:12 PM

LSR Chairs, YingZhen,

Can you give us 10 minute slot to present this new draft:
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/

This draft describes an OSPF extension that can distribute the 5G Edge 
Computing App running status and environment, so that other routers in the 5G 
Local Data Network can make intelligent decision on optimizing forwarding of 
flows from UEs. The goal is to improve latency and performance for 5G Edge 
Computing services.

Thank you very much,

Linda Dunbar

From: Lsr mailto:lsr-boun...@i

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-11-04 Thread Acee Lindem (acee)

Hi Aijun,
You still didn't answer the question as to why you didn't rework this draft for 
passive interface to be an interface attribute rather than a prefix attribute? 
Thanks,
Acee

On 10/1/20, 6:13 AM, "Acee Lindem (acee)"  wrote:

Hi Aijun, 
You didn't answer my question and pruned my message. Other than your 
attempt to expose the topology of areas outside the area, there is no other 
reason to associate the passive interface attribute with a prefix. We seem to 
be in a circular discussion 
Acee

On 9/30/20, 10:43 PM, "wang...@chinatelecom.cn on behalf of Aijun Wang" 
 wrote:

Hi, Acee:
Except the corner cases of unnumbered interface, would you like to 
illustrate other scenarios that the process does not apply?
As mentioned in last mail, knowing the passive interfaces can assist 
the nodes or controller know the boundaries of the network.

Aijun Wang
China Telecom

> On Sep 30, 2020, at 19:47, Acee Lindem (acee)  wrote:
> 

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

[Lsr] 5G Edge -Computing Solution drafts can be used for Dyncast (dynamic anycast) use cases

2020-11-04 Thread Linda Dunbar

Yi Zhou, Liang, Peng, and Peter,

We have 4 IETF drafts describing the different aspect of the solutions to 5G 
Edge computing, which can cover your use cases and requirement described in 
draft-geng-rtgwg-cfn-dyncast-ps-usecase:

Through working on the 3GPP Release 17’s 5G Edge Computing project (3GPP 
TR23.748), we noticed that IP Layer can do more to optimize the 5G Edge 
computing services.

https://datatracker.ietf.org/doc/draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics/
 describes the IP Layer metrics and methods to measure the Edge Computing 
Servers running status and environment for IP networks to select the optimal 
Edge Computing server location in 5G Edge Computing (EC) environment. This 
document also describes the method of incorporating those measurements with IP 
routing cost to come up with a more optimal criteria in selecting ANYCAST 
locations.

https://datatracker.ietf.org/doc/draft-dunbar-6man-5g-edge-compute-sticky-service/
 describes a solution of using IPv6 extension header to help Ingress router to 
stick traffic from a UE to the original App Server when the UE moves from one 
5G Site to another.

https://datatracker.ietf.org/doc/draft-dunbar-idr-5g-edge-compute-app-meta-data/
 describes a new BGP Network Layer Reachability Information (BGP NLRI) Path 
Attribute, AppMetaData, that can distribute the 5G Edge Computing App running 
status and environment, so that other routers in the 5G Local Data Network can 
make intelligent decision on optimized forwarding of flows from UEs. The goal 
is to improve latency and performance for 5G Edge Computing services. The 
extension enables a feature, called soft anchoring, which makes one Edge 
Computing Server at one specific location to be more preferred than others for 
the same application to receive packets from a specific source (UE).

https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/
 describe OSPF extension for the Routers that collect the IP Layer Metrics to 
propagate to all other routers.

Please let us know if the proposed solutions can solve your use cases.

Thank you
Linda Dunbar



From: rtgwg mailto:rtgwg-boun...@ietf.org>> On Behalf 
Of Liyizhou
Sent: Monday, November 2, 2020 1:17 AM
To: rt...@ietf.org
Cc: Lifeng (Frank) mailto:frank.lif...@huawei.com>>; 
Peng Liu mailto:liupeng...@chinamobile.com>>; 
gengli...@chinamobile.com
Subject: Dyncast (dynamic anycast)

Hi folks,

We submitted two drafts about dyncast (dynam

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

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

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

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

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

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

[Lsr] 5G Edge -Computing Solution drafts can be used for Dyncast (dynamic anycast) use cases

7 matches

Site Navigation

Mail list logo

Footer information