Skip to main content

Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator
draft-ietf-pals-vccv-for-gal-06

Yes

(Deborah Brungard)

No Objection

(Alissa Cooper)
(Alvaro Retana)
(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.

Alia Atlas Former IESG member
Yes
Yes (2015-09-16 for -05) Unknown
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 IESG member
Yes
Yes (for -05) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2015-09-14 for -05) Unknown
Is there a particular reason to request that the assigned MPLS VCCV CC Type be bit 3?
Jari Arkko Former IESG member
No Objection
No Objection (2015-09-17 for -05) Unknown
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 IESG member
No Objection
No Objection (for -05) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2015-09-15 for -05) Unknown
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 IESG member
No Objection
No Objection (for -05) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -05) Unknown