DetNet WG Chairs: Lou Berger lberger@labn.net Pat Thaler - - PowerPoint PPT Presentation

▶
detnet wg
SMART_READER_LITE
LIVE PREVIEW

DetNet WG Chairs: Lou Berger lberger@labn.net Pat Thaler - - PowerPoint PPT Presentation

Jun 09, 2023 187 likes •325 views

DetNet WG Chairs: Lou Berger lberger@labn.net Pat Thaler pat.thaler@broadcom.com Jnos Farkas janos.farkas@ericsson.com Secretary: Jouni Korhonen jouni.nospam@gmail.com Online Agenda and Slides at:

slide-1
SLIDE 1

DetNet WG

Chairs: Lou Berger lberger@labn.net Pat Thaler pat.thaler@broadcom.com János Farkas janos.farkas@ericsson.com Secretary: Jouni Korhonen jouni.nospam@gmail.com Online Agenda and Slides at:

https://datatracker.ietf.org/meeting/interim-2018-detnet-03/session/detnet

WG Information: https://datatracker.ietf.org/wg/detnet/

slide-2
SLIDE 2

IETF Note Well

  • Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and

any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to:

  • The IETF plenary session
  • The IESG, or any member thereof on behalf of the IESG
  • Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning

under IETF auspices

  • Any IETF working group or portion thereof
  • Any Birds of a Feather (BOF) session
  • The IAB or any member thereof on behalf of the IAB
  • The RFC Editor or the Internet-Drafts function
  • All IETF Contributions are subject to the rules of RFC 5378 and RFC 8179.
  • Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an

IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 8179 for details.

  • A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices

RFCs and IESG Statements.

  • A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be

available to the public.

  • Also see: http://www.ietf.org/about/note-well.html:

IETF DetNet WG 2

Note: RFC8179 published May 2017

slide-3
SLIDE 3

Meeting Administrativia

  • Webex:

https://ietf.webex.com/ietf/j.php?MTID=mca0b929db5297a5867 bc7585429ad35b

  • Joint minute taking

 Please contribute

  • http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018-detnet-03
  • Online Agenda and Slides at:
  • https://datatracker.ietf.org/meeting/interim-2018-detnet-03/session/detnet
  • Blue sheets
  • Please add your name to etherpad

3 IETF DetNet WG

slide-4
SLIDE 4

Resolving Data Plane Open Issues

  • General desire to work through issues in WG at a faster/higher

bandwidth pace

  • More frequent than in person meetings
  • Failed initial try at in person meeting
  • Travel budget/availability remains a concern for most
  • Current plan: periodic working meetings
  • Frequency
  • Weekly for an hour?
  • Every 2 weeks for 1-2 hours?
  • Extended meeting at IETF 101
  • Friday until 1:30 or 2pm (based on room availability)
  • Considering in person interim between 101 and 102
  • Based on progress through IETF101

IETF DetNet WG 4

slide-5
SLIDE 5

Agenda

1500GMT – Scheduled to 1.5 hours, but can runover 30 minutes if needed Session should be less formal, and discussion oriented!

  • Administrativa (chairs)
  • Draft status update (authors)

see https://tools.ietf.org/html/draft-ietf-detnet-dp-sol https://github.com/jounikor/draft-dt-detnet-dp-sol

  • Contributions to address open issues (contributors)
  • Next steps, including future meetings

IETF DetNet WG 5

slide-6
SLIDE 6

Focusing Today’s Discussion

  • Key open question:
  • IP end to end support
  • Converging on D-CW/MPLS service and PR-EF, so not focus of today’s discussion
  • Detnet services

1. Congestion protection and latency control: usage of allocated resources (queuing, policing, shaping). 2. Explicit routes: select/apply the flow specific path. 3. Service protection: recognize DetNet compound and member flows for replication an elimination.

  • Detnet scenarios (simplified)
  • IPvX end to end service
  • TSN over DetNet

IETF DetNet WG 6

slide-7
SLIDE 7

Simplifjed IPvX End to End Service

  • DetNet Service is end to end

1. Congestion protection and latency control: usage of allocated resources (queuing, policing, shaping). 2. Explicit routes: select/apply the flow specific path.

  • Service protection is per link/sub net
  • 3. Service protection: recognize DetNet compound and member flows for

replication an elimination.

IETF DetNet WG 7

DetNet Relay Transit Relay DetNet End System Node Node Node End System +---------+ (Router) (LSR) (Router) +---------+ | Appl. |<---------------- End to End Service ---------->| Appl. | +---------+ +---------+ +---------+ +---------+ | Service |<---| Service |--- DetNet flow ---: Service :-->| Service | +---------+ +---+-+---+ +---------+ +---+-+---+ +---------+ |DN Transp| |Trp| |Trp| |DN Transp| |Trp| |Trp| |DN Transp| +-------.-+ +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ +---.-----+ : Link : / ,-----. \ : Link : / ,-----. \ +........+ +-[ Sub ]-+ +........+ +-[ Sub ]-+ [Network] [Network] `-----' `-----'

Application L4 Transport IP TSN Application L4 Transport IP TSN TSN May be MPLS May be MPLS TSN Pref Domain

Question: Is no end-to-end (IP) PREF an acceptable simplifjcation for the initial DetNet IP solution?

slide-8
SLIDE 8

Unifjed CW IPvX End to End Service

  • DetNet Service is end to end
  • 1. Congestion protection and latency control: usage of allocated

resources (queuing, policing, shaping).

  • 2. Explicit routes: select/apply the flow specific path.
  • 3. Service protection: recognize DetNet compound and member flows for

replication an elimination.

IETF DetNet WG 8

DetNet Relay Transit Relay DetNet End System Node Node Node End System +---------+ (Router) (LSR) (Router) +---------+ | Appl. |<---------------- End to End Service ---------->| Appl. | +---------+ +---------+ +---------+ +---------+ | Service |<---| Service |--- DetNet flow ---: Service :-->| Service | +---------+ +---+-+---+ +---------+ +---+-+---+ +---------+ |DN Transp| |Trp| |Trp| |DN Transp| |Trp| |Trp| |DN Transp| +-------.-+ +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ +---.-----+ : Link : / ,-----. \ : Link : / ,-----. \ +........+ +-[ Sub ]-+ +........+ +-[ Sub ]-+ [Network] [Network] `-----' `-----'

Application L4 Transport D-CW/PW IP TSN TSN MPLS MPLS TSN Pref Domain Application L4 Transport D-CW/PW IP TSN Based on Balazs Varga contribution

Question: Is addition of D-CW/PW on end hosts acceptable?

slide-9
SLIDE 9

TSN over DetNet

  • TSN Service is end to end
  • DetNet Service is edge to edge

1. Congestion protection and latency control: usage of allocated resources (queuing, policing, shaping). 2. Explicit routes: select/apply the flow specific path. 3. Service protection: recognize DetNet compound and member flows for replication an elimination.

IETF DetNet WG 9

TSN Edge Transit Edge TSN End System Node Node Node End System +---------+ +---------+ +---------+ +---------+ | Appl. |<---:Svc Proxy:-End to End Svc----:Svc Proxy:-->| Appl. | +---------+ +---------+ +---------+ +---------+ +---------+ | TSN | |TSN| |Svc|<DF-| Service | -->|Svc| |TSN| | TSN | +---------+ +---+ +---+ +---------+ +---+ +---+ +---------+ |Transport| |Trp| |Trp| |Trp| |Trp| |Trp| |Trp| |Transport| +-------.-+ +-.-+ +-.-+ +--.+ +-.-+ +-.-+ +-.-+ +---.-----+ : Link : / ,-----. \ : Link : / ,-----. \ +........+ +-[ Sub ]-+ +........+ +-[ Sub ]-+ [Network] [Network] `-----' `-----'

IP

  • ver TSN

IP

  • ver TSN

TSN Domain 1 MPLS MPLS TSN Domain 1 TSN over D-CW TSN over D-CW

slide-10
SLIDE 10

Open discussion

IETF DetNet WG 10

slide-11
SLIDE 11

Some Open Questions

  • How do we move beyond PREF discussions?
  • PREF is just an option for DetNet flows
  • DetNet function related scenarios:
  • 1. Congestion protection and latency control: usage of allocated

resources (queuing, policing, shaping).

  • 2. Explicit routes: select/apply the flow specific path.
  • 3. Service protection: recognize DetNet compound and member flows for

replication an elimination.  PREF

  • Current solution text primarily covers item 3!
  • Have section 7, but also have:

5.6.1. Congestion protection TBD. 5.6.2. Explicit routes TBD.

  • Perhaps focus on non-PREF text between now and IETF 101?

IETF DetNet WG 11

slide-12
SLIDE 12

Some Open Questions

  • IP handling -- Current proposal
  • Limit DetNet flow identification/support to existing header
  • 5-tuple, DSCP
  • Implies no DetNet PREF for IP end stations
  • Other DetNet services can still be provided end-to-end
  • PREF can be provided at the subnet level
  • DetNet/MPLS or TSN/802.1cb
  • Is this acceptable?
  • Timing of document split?

IETF DetNet WG 12

slide-13
SLIDE 13

Next Steps

  • Next working meeting
  • ~2 weeks for 1-2 hours?

IETF DetNet WG 13