Subject: [PWE3] Comments - Re: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

From: Sri <[email-masked]>
Date: Mon, 1 Aug 2011 14:59:31 -0700

Hello Tom and other authors,

Some comments on the draft

1. Why is it called 'unified', and what exactly is it unifying. Seems
to be applicable only when control-word is not used.
2. There is no text on whether this VCCV type is inband. If it is not,
then data packets and OAM packets may not fate share. What is the
applicability of this VCCV in such a case.
3. Section 3 figure does not show bottom of stack bit.
4. Why is the PW label TTL setting to 1 a must ? To reach the T-PE
shouldn't any value of TTL >= number of PW hops work ?
5. Can this proposal result in a packet having multiple GAL labels ?

Thanks

On Thu, Jul 28, 2011 at 11:02 AM, Bocci, Matthew (Matthew)
<[email-masked]> wrote:
> This email begins a two week poll to help assess if there is consensus to
> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.
> Please indicate whether or not you support adoption of this draft, and also
> send any comments to the PWE3 list.
> This poll will end on Friday 12th August.
> Regards,
> Matthew & Andy
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

-- 
Sriganesh Kini (Sri)

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 2 Aug 2011 07:57:27 -0400

Hi!

> to be applicable only when control-word is not used.

	The term "unified" was used a bit tongue-and-cheek; it should be
more along the lines of "simplified".

> applicability of this VCCV in such a case.

	There is no change to the operation of VCCV as its already defined
for the CW case. The only thing we've added is the use of the GAL for
the cases where you do not want to use a CW so that you can still reliably 
identify OAM packets.

> 3. Section 3 figure does not show bottom of stack bit.

	Thanks.

> shouldn't any value of TTL >= number of PW hops work ?

	This was to handle the MSPW case.

> 5. Can this proposal result in a packet having multiple GAL labels ?

	No, I do not think so. 

	--Tom

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 02 Aug 2011 10:24:10 -0400

In message <[email-masked]>
> > 5. Can this proposal result in a packet having multiple GAL labels ?

It generally won't because LSP OAM will never take the label stack
from PW OAM and put it underneath the LSP OAM label stack.

Even if it did, the only GAL label that counts is the one that is
immediately below the label being acted on.  If it is TTL expired and
the label below the one with TTL expiring is GAL, then it is OAM for
that label.  If a label POP is done and the next label is GAL, it is
OAM for the label just popped.  That can be handled by a reasonably
flexible parser.

I can't really think of any case where the PW GAL, or any lower layer
GAL would be included to check to see if the "skip over GAL when
hashing" processing was happenning right at every point along the
path.  Generally you would expect to see every GAL skipped or none
skipped in the hash.

If there were a use for more than one GAL we would already have that
use in hierarchical LSP and we don't see it.

Curtis

---

From: Sri <[email-masked]>
Date: Tue, 2 Aug 2011 14:05:03 -0700

See inline

- Sri

Sent from my iPad

> more along the lines of "simplified".

Ok. Maybe "simplified no CW" mode would reflect it better.

> the cases where you do not want to use a CW so that you can still reliably

All the VCCV types in RFC5085 state ECMP behavior. So to be consistent
it needs to be stated for this proposed vccv type too.
IMO it is useful to examine if it can ensure fate-sharing with the PW
payload. If
the connectivity verification cannot be guaranteed for a given flow on the
PW then its applicability is limited.

>    This was to handle the MSPW case.

Even in MSPW why wouldn't PW label TTL >= number of PW segments work
to reach the T-PE ?

>> 5. Can this proposal result in a packet having multiple GAL labels ?

Another comment

In section 3 it is stated "The first nibble of the next field is set
to 0001b to indicate an ACH associated with a pseudowire..."

If the GAL is indicating the presence of an ACh, then the first nibble
is not needed for the same purpose. Its use would be to prevent
incorrect interpretation by an intermediate LSR that examines the
first nibble to perform forwarding decisions.