RFC 5254, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", October 2008

Errata ID: 1578
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-10-24
Held for Document Update by: Stewart Bryant
Date Held: 2012-02-14

Section 1.2, pg. 4 says:

         Native  |<--------Multi-Segment Pseudowire----->|  Native
         Service |         PSN              PSN          |  Service
          (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)
           |     V     V     1    V     V     2    V     V   |
           |     +-----+          +-----+          +---- +   |
   +---+   |     |T-PE1|==========|S-PE1|==========|T-PE2|   |    +---+
   |   |---------|........PW1.......... |...PW3..........|---|----|   |
   |CE1|   |     |     |          |     |          |     |   |    |CE2|
   |   |---------|........PW2...........|...PW4..........|--------|   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |                             |                            |
       |                             |                            |
       |                     PW switching point                   |
       |                                                          |
       |                                                          |
       |<------------------- Emulated Service ------------------->|

                Figure 2: PW Switching Reference Model

   Figure 2 extends this architecture to show a multi-segment case.
   Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3
   service to CE1 and CE2.  These PEs terminate different PSN tunnels,
   PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or
   pseudowire domains.  One PSN tunnel extends from T-PE1 to S-PE1
   across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2
   across PSN2.

It should say:

         Native  |<--------Multi-Segment Pseudowire----->|  Native
         Service |         PSN              PSN          |  Service
          (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)
           |     V     V     1    V     V     2    V     V   |
           |     +-----+          +-----+          +---- +   |
   +---+   |     |T-PE1|==========|S-PE2|==========|T-PE3|   |    +---+
   |   |---------|........PW1.......... |...PW3..........|---|----|   |
   |CE1|   |     |     |          |     |          |     |   |    |CE2|
   |   |---------|........PW2...........|...PW4..........|--------|   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |                             |                            |
       |                             |                            |
       |                     PW switching point                   |
       |                                                          |
       |                                                          |
       |<------------------- Emulated Service ------------------->|

                Figure 2: PW Switching Reference Model

   Figure 2 extends this architecture to show a multi-segment case.
   Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3
   service to CE1 and CE2.  These PEs terminate different PSN tunnels,
   PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or
   pseudowire domains.  One PSN tunnel extends from T-PE1 to S-PE2
   across PSN1, and a second PSN tunnel extends from S-PE2 to T-PE2
   across PSN2.

Notes:

Rationale:

The original diagram was inconsistent. The proposed edits correct this inconsistency. Specifically the PEs are now labels xPE1, xPE2, xPE3 across
the page and the text is modified accordingly.


The erratum is technically correct, but since the purpose of this RFC was to establish the requirements in RFC5659 and the error does not occur in RFC5659 the problem may be classified as fixed in update.

Report New Errata