Subject: Re: [PWE3] VCCV usage

From: [email-masked]
Date: Thu, 18 Nov 2010 23:29:53 +0800

Hi Yaakov and all,
This long discussion is valuable, and I think we may make some agreement 
and clarification in draft-delregno-pwe3-vccv-mandatory-features according 
this discussion.

Lizhong

---------
> 
> Message: 2
> Date: Wed, 17 Nov 2010 11:40:38 +0000
> From: Yaakov Stein <[email-masked]>
> Subject: Re: [PWE3] VCCV usage
> To: Alexander Vainshtein <[email-masked]>,
>    "[email-masked]" <[email-masked]>
> Cc: "[email-masked]"
>    <[email-masked]>,   "[email-masked]"
>    <[email-masked]>, "[email-masked]" <[email-masked]>,
>    "[email-masked]" <[email-masked]>
> Message-ID:
>    <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> Wow, this has turned out to be a long and contentious thread.
> Too bad we didn't discuss this issue more when we had f2f time.
> 
> I agree with Sasha that additional clarification is needed.
> However, let's consider what makes sense here.
> 
> I personally think that 0001 in the first nibble after the label stack 
should
> ALWAYS be interpreted as an associated channel packet, even if not 
negotiated.
> After all, this nibble is registered with this meaning,
> and this behavior is the norm for statically configured PWs.
> 
> TTL expiry always triggers special treatment for an IP or MPLS packet.
> I think I have seen agreement here that PW TTL expiry should always 
trigger
> a check to see if the packet is an associated channel packet
> (the alternative being to discard the packet unless explicitly 
negotiated).
> If, as Sasha suggested, the payload is "type 1" encoded,
> then this check can be done unambiguously, and discarding without 
> observing doesn't make sense.
> Once again, this should happen even if type 3 was not negotiated
> (what would the proper behavior be for a statically configured PW?).
> 
> How, what about type 2 ? If not negotiated, since the RA label 
> appears above the PW label,
> it is not clear that this would be properly interpreted as a PW-
> related indication.
> So, type 2 requires negotiation.
> 
> If we deprecate type 2 (which is what I originally suggested, Luca 
> said that he wanted to do
> but didn't want to change 5085, and Sasha is pushing for now), then 
> in fact the negotiation
> of VCCV type becomes a luxury.
> If the need for additional clarification triggers a respin of 5085,
> then I assume that Luca will not mind deprecating.
> 
> So, I go back to my original suggestion. Both type 1 and type 3 are 
> required to be supported,
> with the usage preference being CW marking (since it helps with ECMP, 
...).
> 
> TTL expiry is the only behavior when the CW is not used.
> For the special case of segmental OAM for MS-PWs, there is an 
> elegance advantage
> to using TTL expiry, but I don't think that should change the 
> default behavior.
> 
> Y(J)S
> 
> 
> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: Wednesday, November 17, 2010 09:11
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; mustapha.
> [email-masked]; [email-masked]; Yaakov Stein
> Subject: RE: [PWE3] VCCV usage
> 
> Lizhong,
> I agree that what you say is a possible interpretation of RFC 5085.
> But I would like to see it explicitly specified.
> 
> And, IMO, when a PE advertizes VCCV Type 3 it advertizes its 
> transmit capability as well as its receive capability.
> 
> Regards,
>      Sasha
> 
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.