Subject: [Pals] Alia Atlas' Yes on draft-ietf-pals-vccv-for-gal-05: (with COMMENT)

From: "Alia Atlas" <[email-masked]>
Date: Wed, 16 Sep 2015 08:22:41 -0700

Alia Atlas has entered the following ballot position for
draft-ietf-pals-vccv-for-gal-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pals-vccv-for-gal/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 16 Sep 2015 18:23:54 +0100

> https://datatracker.ietf.org/doc/draft-ietf-pals-vccv-for-gal/
Alia

We can agree on some text, BUT I would put it to you that the majority 
of the
currently deployed hardware acts like this, and that RFC7325 compliance is
currently the exception.

- Stewart
> .

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Alia Atlas <[email-masked]>
Date: Wed, 16 Sep 2015 13:33:34 -0400

Stewart,

On Wed, Sep 16, 2015 at 1:23 PM, Stewart Bryant <[email-masked]> wrote:

> We can agree on some text, BUT I would put it to you that the majority of
> the

After 10+ years of understanding that this is the correct behavior?
If you want to put in text indicating that hardware that doesn't conform to
RFC7325
may cause these VCCV Type 4 packets to be reordered compared to the data
flow,
that's fine.  But put the reference in indicating that this is a solved
problem as far
as standardization and technology goes - hardware always lags.

Regards,
Alia

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 17 Sep 2015 11:35:43 +0100

>           Can you please expand it the first time

Alia,

The first occurrence of LSE is in the second para of the introduction:

"In the event of an error
in the setting of the PW Label Stack Entry (LSE) TTL, VCCV packets"

Would you like me to leave it unexpanded there and expand it somewhere else?

In this case I think the expansion is something of a formality, since it
is difficult to image that any reader would look at this RFC without
a prior understanding of MPLS and hence knowledge of the term.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 17 Sep 2015 13:47:19 +0100

On 16/09/2015 18:33, Alia Atlas wrote:
> If you want to put in text indicating that hardware that doesn't 
> conform to RFC7325
> may cause these VCCV Type 4 packets to be reordered compared to the 
> data flow,
> that's fine.  But put the reference in indicating that this is a 
> solved problem as far
Alia

I was about to do the edit, when I noticed that RFC7325 is an informational
and thus an element of the technology in a standards track RFC cannot
really "conform" to it.

This sets the status of the RFC2119 language in the text you quote in a 
difficult
position since this Informational cannot be directive on an 
implementation of
RFC3031 which is standard that underpins vccv-for-gal and the LSPs that
it question assumes to be in use.

So I think we can note that if we are fortunate enough to be running 
over LSPs
provided by routers all of which operate according to the text you quote in
RFC7325 then the problem described does not exist. However I don't think we
can go any further, since as far as I can tell there is nothing in the 
formal specification
of MPLS that mandates RFC7325 behavior. In addition I am unaware of how
you would know that the LSP was behaving according to RFC7325 since this is
not signaled.

You will note that our attention was drawn to newly introduced MPLS 
hardware that
does not conform to RFC7325, which suggests that we need to proceed
with caution in terms of setting false expectations of the absence of 
the problem
we describe in this draft.

Thus whilst I should add a reference to RFC7325, the text will need to be
cautious, and perhaps more of an afterthought rather than primary
expectation.

- Stewart

---

From: Alia Atlas <[email-masked]>
Date: Thu, 17 Sep 2015 08:58:56 -0400

Hi Stewart,

> Would you like me to leave it unexpanded there and expand it somewhere

It's a little awkward, but ok.

> a prior understanding of MPLS and hence knowledge of the term.

I haven't actually seen LSE appear as an acronym for a while - so it took me
a few seconds  to figure out what it must be.  I agree that it's obvious to
someone who understands MPLS - but a trivial reminder is helpful.  There are
a lot of acronyms in our industry!

It's up to you - just a comment on readability.

thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 17 Sep 2015 09:16:00 -0400

Hi Stewart,

On Thu, Sep 17, 2015 at 8:47 AM, Stewart Bryant <[email-masked]> wrote:

>> If you want to put in text indicating that hardware that doesn't conform
>> to RFC7325
> position since this Informational cannot be directive on an implementation
> of
> it question assumes to be in u"se.
>

The text in question is:
" 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. "

This isn't exactly requiring conformance.  I haven't (yet) dug up a
standards-track
reference from RFC7325 that discusses this though certainly the Entropy
Label
RFC talks about not including reserved labels in the hash to get an Entropy
Label.

>
> So I think we can note that if we are fortunate enough to be running over
> LSPs

 Changing it to:

"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 may
cause
OAM packets to take a different path through the network
   from the corresponding PW data packets if there is equipment on the path
that
does not omit special purpose labels from the computation of a
load-balancing hash
as described in RFC7325.  If operating with such equipment and that is not
acceptable, then an alternative VCCV type needs to be used."

> with caution in terms of setting false expectations of the absence of the
> problem

Yes - happy to put in a caveat but also sad to learn of such new hardware.
With the amount of load-balancing in networks today, supporting easier
troubleshooting
is really important.

> cautious, and perhaps more of an afterthought rather than primary

I'd turn it around - an expection with a warning.

Regards,
Alia

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 17 Sep 2015 16:47:52 +0100

Hi Alia

How about:

Where the LSP used by the PW is subject to Equal-Cost Multi-path (ECMP)
load balancing, a problem arises if any LSR on that LSP treats special
purpose labels as ordinary labels in its
ECMP selection method. In these circumstances the inclusion of a GAL
following the PW LSE can cause the OAM packet to take a different path
through the network from the corresponding PW data packets. If the
LSP traverses such equipment and this behaviour is not acceptable,
then an alternative VCCV type needs to be used. The method of excluding
special purpose labels from the ECMP next hop decision is described in
[RFC7325].

- Stewart

---

From: Alia Atlas <[email-masked]>
Date: Thu, 17 Sep 2015 13:56:10 -0400

> special purpose labels from the ECMP next hop decision is described in

As I suggested, I'd flip what the default should be.

If you aren't happy with that, I would prefer it a bit stronger.

"The requirement to not include special-purpose labels in the
load-balancing decision
is described in "MPLS Forwarding Compliance and Performance
Requirements"[RFC7325].
For equipment that conforms to this, the VCCV type4 traffic will follow the
corresponding
PW data packets."

Regards,
Alia

- Stewart