Re: FW: [PWE3] Last Call: <draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt> (Using the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/05/11 05:47, Yaakov Stein wrote:
>
> 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.
>
This is correct. This document was not meant to have a discussion about OAM.
Thanks Yaakov.

Luca

> 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@xxxxxxxxx> <mailto:stbryant@xxxxxxxxx>
>
> *Reply-To: *
>
> 	
>
> stbryant@xxxxxxxxx <mailto:stbryant@xxxxxxxxx>
>
> *To: *
>
> 	
>
> Yaakov Stein <yaakov_s@xxxxxxx> <mailto:yaakov_s@xxxxxxx>
>
> *CC: *
>
> 	
>
> ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> <ietf@xxxxxxxx>
> <mailto:ietf@xxxxxxxx>
>
> …
>
> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]