Skip to main content

Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator
RFC 7708

Yes

(Deborah Brungard)

No Objection

Alvaro Retana
(Alissa Cooper)
(Barry Leiba)
(Ben Campbell)
(Benoît Claise)
(Joel Jaeggli)
(Kathleen Moriarty)
(Stephen Farrell)
(Terry Manderson)

Note: This ballot was opened for revision 05 and is now closed.

Alvaro Retana No Objection

(Alia Atlas; former steering group member) Yes

Yes (2015-09-16 for -05)
1) In the last paragraph of Section 3: " Note that the inclusion of a GAL following the PW LSE over a label
   switched path subject to Equal-Cost Multi-path (ECMP) load balancing
   can cause the OAM packet to take a different path through the network
   from the corresponding PW data packets.  If that is not acceptable,
   then an alternative VCCV type needs to be used."

Since the GAL is a Reserved label, it should not be included in a hash done for load-balancing.  This is
described in RFC 7325 Sec 2.4.5.1 bullet 3 " Special-purpose labels (label values 0-15) MUST NOT be used. 
Extended special-purpose labels (any label following label 15) MUST NOT be used.  In particular, GAL and 
RA MUST NOT be used so that OAM traffic follows the same path as payload packets with the same label stack."

Please correct the paragraph to add this reference.  I know that there may be old implementations out
there that do the wrong thing - but an RFC should refer to the correct behavior.

The sentence in Section 7 " Attention is drawn to the possible absence of fate sharing between PW
   data packets and VCCV CC Type 4 packets described in Section 3 and
   Section 4." will also need updating.

2)  The use of LSE as an unintroduced abbreviation is slightly confusing.  Can you please expand it the first time
to Label Stack Entry?

(Deborah Brungard; former steering group member) Yes

Yes (for -05)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -05)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -05)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (for -05)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (for -05)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (2015-09-14 for -05)
Is there a particular reason to request that the assigned MPLS VCCV CC Type be bit 3?

(Jari Arkko; former steering group member) No Objection

No Objection (2015-09-17 for -05)
The Gen-ART comments from Dan Romascanu (I believe the points were agreed) still need to lead to edits in a new version of this draft.

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -05)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -05)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (2015-09-15 for -05)
A minor question ... I was somewhat surprised to see this statement.

1.  Introduction

   o  Some operators are concerned that the inclusion of the PW CW will
      increase the PW packet size.
      
It seems like the working group would know whether that's true (so, something like "The increase in PW packet size due to the inclusion of the PW CW will cause problems X, Y, and Z"), or it's not. 

Is it true? If so, the issue isn't that operators believe there's a problem, but that there's really a problem.

(Stephen Farrell; former steering group member) No Objection

No Objection (for -05)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -05)