Stewart
I will answer your specific questions below.
I have no specific objection to the new text that you proposed on the PWE3 list
:
In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
LSPs, Concatenated Segments of LSPs, and with Sections, and
MAY be used with PWs. The presence of a GAL indicates that
an ACH immediately follows the MPLS label stack.
as it has become so generic (does not explain where the GAL is placed) as to be
noncontroversial.
However, please be aware that this simply postpones the true discussion.
I would still like the wording
According to the MPLS-TP requirement document [RFC5654], it is
necessary that MPLS-TP mechanisms and capabilities be able to
interoperate with the existing IETF MPLS [RFC3031] and IETF PWE3
[RFC3985] architectures appropriate.
to be removed, as I believe that it does not correctly describe the purpose of
this draft.
It should be replaced with the text that appears further on
The inconsistency between the usage of the GAL with MPLS PWs and
MPLS-TP PWs may cause unnecessary implementation differences and is
in disagreement with the MPLS-TP requirements.
Please see a few more remarks interleaved below.
Y(J)S
-------- Original Message --------
Subject:
Re: FW: [PWE3] Last Call: (Using the Generic Associated Channel Label for
Pseudowire in MPLS-TP) to Proposed Standard
Date:
Thu, 01 Sep 2011 16:40:16 +0100
From:
Stewart Bryant
<stbryant(_at_)cisco(_dot_)com><mailto:stbryant(_at_)cisco(_dot_)com>
Reply-To:
stbryant(_at_)cisco(_dot_)com<mailto:stbryant(_at_)cisco(_dot_)com>
To:
Yaakov Stein <yaakov_s(_at_)rad(_dot_)com><mailto:yaakov_s(_at_)rad(_dot_)com>
CC:
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>
<ietf(_at_)ietf(_dot_)org><mailto:ietf(_at_)ietf(_dot_)org>
...
However, you did not address my other final comment that a PW that starts in an
MPLS-TP domain,
can easily leak into a non-TP domain.
What does one do then ?
That is a general issue rather than a TP issue.
When you get to the PW label and you would find that it was not BOS.
If you you are not running FAT that that is a detectable.
If you are running FAT the presence of the GAL (which is not an
allowed FAT label) is also a detectable.
[YJS] I believe the simultaneous use of FAT and GAL is ruled out by the TP
framework document.
...
You say:
"Bottom of stack has been the label position of the PW label for many years,
and this position is mandated by multiple RFCs, e.g. 3985 and 4447
Note that the PW label must always
be at the bottom of the packet's label stack."
That is no longer true with the introduction of FAT.
[YJS]
As you know I proposed an alternative mechanism,
however, in any case the FAT case is different from the GAL.
Each load balanced flow label is actually a "partial-PW' and thus the flow
label is a type of PW label,
albeit a PW carrying only a subset of the user flows that exist in the original
PW.
On the other hand the GAL is a modifier, meaning that the rest of the payload
has a different format.
Then you say:
"Present PW implementations receiving the PW label with stack bit cleared,
and a GAL at the bottom position will choke and, at best, discard the packet.
At worst, the GAL may coincide with a legitimate PW label, and the customer
will be
flooded with garbage."
Your first case is sort of correct - the packet should be silently
discarded as it was clearly not intended for that PW - but it had
better not choke as this would be an attack vector.
[YJS] By "choke" I meant either discard or flood the impersonated PW with what
it believes to be VCCV packets.
You second case cannot happen because a GAL is a reserved label and
a reserved label can never be a legitimate PW label.
[YJS]
My second case CAN happen (I expected this question).
Please remember that before MS-PWs were proposed, PW labels were never
considered "real" MPLS labels,
and many implementations did not religiously apply the MPLS restrictions to
them.
Stewart
[YJS]
I DO have a proposal that is completely consistent with the goals of this draft
AND the PWE RFCs.
The GAL can be placed in one of 2 positions
1) ABOVE the PW label (just as the router alert is placed above the PW
label in VCCV Type 2)
2) INSTEAD of the PW label (thus making a single "OAM PW", reducing the
OAM load)
Note 1 - this is essentially the same as using the GAL for the MPLS tunnel into
which the PWs are placed.
Note 2 - this is close to my original proposal for PW OAM, that was abandoned
when VCCV "per-PW OAM" won out.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf