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

[Alia Atlas <[e-mail]>]

Hi Stewart,

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

> On 16/09/2015 18:33, Alia Atlas wrote:
>
>>
>>
>> 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.
>>
>> 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 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
> 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.
>

 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."

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.
>

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.


> 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.


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

Regards,
Alia



> - Stewart
>
>
>
>
>