Subject: Re: [PWE3] Clarification request on VCCV CC types usage per PW

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 19 Jul 2010 19:57:53 +0200

Hi Carlos,

Thanks for your reply.

> -----Original Message-----
> From: Carlos Pignataro [mailto:[email-masked]]
> Sent: 15 July 2010 17:44
>
> Matthew,
>
> Thanks for the follow-up.
>
> Please see inline; as this is more foundational than the initial
> "cc_type_to_pass_ds = cc_type_received && local_capabilities" topic,
> let's see if there's convergence.

Yes,  agree this is rather more fundamental.

>
> On 7/15/2010 7:15 AM, Bocci, Matthew (Matthew) wrote:
> > (Chairs hat off)
> >
> > Carlos,
> >
> > TTL expiry at the S-PEs is agnostic to whether CC type 3 or
> CC type 1
> > is in use along the MS-PW. CC type 1 does not use DPI at the S-PEs.
>
> Yes and no. As I think there are two potential interpretations. Yes,
> TTL expiration happens at S-PEs, including (when crafted that way) to
> VCCV packets. But by definition, "CC Type" means the way in which the
> VCCV packet is intercepted. This means, IMHO, that if the interception
> of the VCCV packet to local inspection/processing at an S-PE happens
> due to TTL expiry, then that's CC Type 3; if that PW uses a CW, then
> that CW needs to include the first nibble as
> 0x1 matching CC Type 1 syntax. But that does not mean it's CC Type 1.
>
> http://tools.ietf.org/html/rfc5085#section-5.1.3
>
> "5.1.3.  TTL Expiry VCCV (Type 3)
> ...
>    If the Control Word is in use on this PW, it MUST also be included
>    before the VCCV message.  This is done to avoid the different ECMP
>    hashing behavior.  In this case, the CW uses the PW-ACH format
>    described in Section 5.1.1 (see Figures 3 and 4).  If the Control
>    Word is not in use on this PW, the VCCV message follows the PW
> Label
>    directly."
>
> Conversely, if a VCCV packet uses the PW-ACH with the first nibble as
> 0x1, as in CC Type 1, with a high TTL (e.g., 255), then at an S-PE,
> just by mere switching of PW Label the S-PE would not see the "CC Type
> 1", unless it's inspecting beyond the actual function that is doing
> (what I meant and didn't explain in detail as "DPI"). IOW, to have CC
> Type 1 at S-PE we'd need an additional (deeper) forwarding behavior.
>
> Do you agree?

I think draft-ietf-pwe3-segmented-pw effectively updates this behavior so that all VCCV CC-Types must use TTL expiry at the S-PE. But this is a consequence of handling standard MPLS label operation over multiple hops and is not specific to VCCV packets. All user and OAM packets must have their PW label decremented by each hop and if they expire they should be extracted. This does means that Type 3 + CW and Type 1 behave in the same way at an S-PE. However, they do not behave in the same way at the T-PE. I do agree with you that when VCCV was written in in pre-MS-PW days, when S-PEs didn't exist, CC-Type did strictly mean the intercept mechanism that should be used, but that meaning has been superseded in the sense that I suppose Type 1 means that at a T-PE 'On label pop, also inspect first nibble of CW that follows'. There is a PW label swap at an S-PE, so this part of the behavior does not apply there, and the only way to further inspect any PW traffic is through a TTL expiry, irrespective of the CC-Type that the T-PEs advertise.

>
> >
> > One issue for me is how you guarantee that the VCCV packet flow is
> > bounded to the span of the PW. As you point out below, you
> can use the
> > S-PE TLV to help set the TTL correctly, but only if every
> S-PE along
> > the MS-PW sends that TLV. However, the S-PE TLV is
> optional, primarily
> > for security reasons, so I do not think this is a reliable
> method of
> > determining how many hops away the T-PE is. Do you really
> need to know
> > the topology of the MS-PW for one end to ping the far end?
>
> This is correct, I agree, see below.
>
> >
> > Also, I think we should remember that a major application
> for MS-PWs
> > is inter-provider services. Is it safe that a T-PE should accept
> > traffic onto an AC if an intermediate S-PE that is in another
> > provider's domain sets the TTL incorrectly?
>
> Yes, so perhaps the most comprehensive solution is to scope the
> applicability of preferred modes? E.g., utilizing the S-PE TLV and TTL
> setting for intra-AS scenarios, and other in inter-AS.
>

I am not sure you can generalise to inter/intra AS as there are no-doubt intra-AS scenarios where security is still important, and there are inter-AS scenarios where the full path of the ms-pw can be determined e.g. single operators with multiple AS's. I think we should be more specific e.g. stating whether the full hop count can be reliably determined and whether an intermediate S-PE could insert VCCV traffic with the wrong TTL.

> Like you say it's not safe to send traffic onto the AC; but would that
> argue for managing the capability spaces independently between
> end-to-end ping and intermediate-hop trace, and preferring CC Type 1
> for T-PE termination?

Yes, although I am not sure we can manage them completely independently, but certainly it does make sense to say that while Type 1 is important at the T-PEs, Type 1 and Type 3 (with CW) are really equivalent at the S-Pes, and that they can interoperate. Nodes that only support TTL==1 + CW, could advertise Type 1 for PWs for which they act as an S-PE and interoperate if the Type 1 nodes accept it e.g. as follows:

[T-PE1]-------[S-PE]---------[T-PE2]
 Type 1       Type 3+CW       Type 1

Let's say the S-PE supports only Type 3+ CW, but advertises both Type 3 and Type 1 to the T-Pes. It also accepts the type 1 advertisement from
T-PE1 and T-PE2. T-PE1 and T-PE2 use only Type 1 for the reasons discussed above. So the PW segments both come up.

T-PE1 can ping the S-PE because it assumes TTL expiry for pinging an intermediate S-PE.

T-PE1 can still ping T-PE2 because they both agree on Type 1.

The S-PE can ping the T-PEs because it sets the first nibble of the VCCV CW correctly, which means that when they pop the PW label, they generate the correct exception.

Regards

Matthew

>
> Thanks,
>
> -- Carlos.
>
> >
> > Thanks,
> >
> > Matthew
> >
> >
> --------------------------------------------------------------
> ----------
> >     *From:* [email-masked] [mailto:[email-masked]] *On
> >     Behalf Of *Carlos Pignataro (cpignata)
> >     *Sent:* 15 July 2010 02:59
> >     *To:* Aissaoui, Mustapha (Mustapha)
> >     *Cc:* [email-masked]; venkatesan mahalingam
> >     *Subject:* Re: [PWE3] Clarification request on VCCV CC
> types usage
> >     per PW
> >
> >     Mustapha,
> >
> >     Thanks for your response.
> >
> >     I understood you said that (paraphrasing) "an S-PE
> takes the VCCV
> >     capability it received from a T-PE, clears the bits it does not
> >     support and passes it downstream to the next S-PE/T-PE". I
> >     understood that from when you wrote:
> >>
> >>>>         An S-PE node passes the VCCV capability signaled
> by the T-PE
> >>>>         transparently and removes any type it does not support.
> >
> >     I was saying that that method can blackhole
> capabilities. This is
> >     because there is a different switching function at T-PE
> (push/pop)
> >     than S-PE (swap). Therefore:
> >     . CW is transparent (invisible) to S-PEs unless DPI.
> >     . TTL-- and check is inherent to the S-PE function
> >     . RA will result is interception at every S-PE.
> >
> >     And as such, TTL expiry interception seems to make more sense at
> >     S-PEs, but if not supported at T-PEs then it appears
> the "passing
> >     capability and clearing" would not work.
> >
> >     Please find some more comments inline.
> >
> >     Thumb typed by Carlos Pignataro.
> >
> >     On Jul 14, 2010, at 10:48 AM, "Aissaoui, Mustapha (Mustapha)"
> >     <[email-masked]
> >     <mailto:[email-masked]>> wrote:
> >
> >>     Carlos/Sam,
> >>     in fact TTL decrementing of the PW label is a
> fundamental part of
> >>     the MS-PW operation and applies to both data and OAM
> packets. Any
> >>     packet which TTL expired at a node must be extracted and
> >>     examined. The TTL of a VCCV ping, regardless of which
> >>     encapsulation method is used, must be set to the
> appropriate value
> >>     if you want to ping an intermediate node.
> >
> >     This means type 3 support at S-PEs, even if not
> supported at T-PEs,
> >     correct?
> >
> >>
> >>     The CW is a way of guaranteeing that the egress T-PE
> can identify
> >>     and extract the packet even if the TTL is set to 255.
> A ping will
> >>     typically use a TTL value of 255 since the user does
> not need to
> >>     know how many hops away is the egress T-PE from the
> node, a T-PE
> >>     or an S-PE, where the ping is issued.
> >
> >     I'm not sure about qualifying as "typically", but the
> [TS]-PE does
> >     know how many S-PE hops away.
> >
> >
> >>     The TTL=1 method is not safe from this perspective since if the
> >>     TTL is set to a higher value than the number of hops
> to the egress
> >>     T-PE, the egress T-PE will actually forward the VCCV
> packet over
> >>     the AC.
> >
> >     Then, would not setting the TTL higher than the number
> of switching
> >     hops inferred from the Swithing Point TLV solve the issue?
> >
> >>
> >>     You are correct that the CW is absolutely not required
> if you are
> >>     pinging an intermediate node in the path of a MS-PW since the
> >>     control plane can parse the payload, e.g., MPLS echo request
> >>     message based on destination UDP port. However, since
> a ping can
> >>     be destined to any node in the network, including the
> egress T-PE,
> >>     it was easier to allow for the singaling of a single
> encapsulation
> >>     format to be used across all segments of the MS-PW.
> >
> >     I am not sure I understand the above para.
> >
> >>
> >>     When working on the VCCV section of
> draft-ietf-pwe3-segmented-pw,
> >>     we originally described the CW option only. This however meant
> >>     that the control word must be enabled on the PW even
> when the CW
> >>     was optional, e.g., Ethernet PW. We later added the
> TTL=1 method
> >>     mostly because of some deployment cases where the control word
> >>     could not be enabled on PW types for which the control
> word is not
> >>     mandatory, e.g., due to no support on the deployed routers.
> >>     However, it is not a safe method as explained above.
> >
> >     The question I still have is why the interception
> method must be the
> >     same for T-PEs (e2e) than from probing an S-PE (where
> ttl seems to
> >     be the natural choice).
> >
> >     Thanks,
> >
> >     -- Carlos.
> >
> >>     Regards,
> >>     Mustapha.
> >>
> >>
> --------------------------------------------------------------
> ----------
> >>         *From:* Sam   [mailto:[email-masked]]
> >>         *Sent:* Tuesday, July 13, 2010 10:57 PM
> >>         *To:* Carlos Pignataro
> >>         *Cc:* Aissaoui, Mustapha (Mustapha); Anup Kumar Vasudevan;
> >>         [email-masked] <mailto:[email-masked]>; venkatesan mahalingam
> >>         *Subject:* Re: [PWE3] Clarification request on
> VCCV CC types
> >>         usage per PW
> >>
> >>         Couldn't agree more, Carlos.
> >>
> >>         In other perspective, having TTL support (type3)
> is implicitly
> >>         a must to have in the case of MS-PW.
> >>         Presence of CW(type1) or not, one should able to support
> >>         type3, in order to effectively ping/trace SPE's
> and TPE in MS-PW.
> >>
> >>         Using RA label (type2) cannot work in MS-PW, as it
> will make
> >>         packet to be punted at the very next hop(SPE).
> >>         Once comment inline with %SAM.
> >>
> >>         On Jul 13, 2010, at 6:54 PM, Carlos Pignataro
> (cpignata) wrote:
> >>
> >>>         I don't think that an "intersection of all sets"
> is the right
> >>>         approach for VCCV for MS-PW. Specifically, I think that:
> >>>         1. We should differentiate e2e (T-PE to T-PE) from T-PE to
> >>>         S-PE-n in the capability intersection set; i.e.,
> ability to
> >>>         trigger a specific S-PE to intercept the VCCV packet.
> >>>         2. It is different at S-PEs than SS-PW, because
> there is just
> >>>         switching and "deep inspection" of the CW is more
> expensive
> >>>         and RA would trigger every S-PE. A VCCV packet
> should be able
> >>>         to trigger which S-PE to process but be of zero
> cost to other
> >>>         S-PEs.
> >>>
> >>>         Therefore, would it be sensible to craft the TTL value for
> >>>         S-PE probing, but use CW for e2e? And not optimal
> to use say
> >>>         CW for S-PEs but still maintain T-PE capability of CW?
> >>         %SAM - Even if CW is present, while pinging SPE's, setting
> >>         right TTL value will not cause any overhead or
> cost to other
> >>         SPE's as the packet will get switched till the ttl
> is expired
> >>         or reached TPE (whichever comes first). That way
> one need not
> >>         chose different cc type for SPE and TPE. This is
> the point I
> >>         was making i.e. type1+type3 could co-exist.
> >>
> >>         -sam
> >>>
> >>>         Just my $0.02. Thanks,
> >>>
> >>>         Thumb typed by Carlos Pignataro.
> >>>
> >>>         On Jul 13, 2010, at 1:08 PM, "Aissaoui, Mustapha
> (Mustapha)"
> >>>         <
> >>>
> <mailto:[email-masked]>mustapha.aissaoui
> @alcatel-lucent.com
> >>>         <mailto:[email-masked]>> wrote:
> >>>
> >>>>         Sam,
> >>>>         it is actually valid in the case of a MS-PW too. An S-PE
> >>>>         node passes the VCCV capability signaled by the T-PE
> >>>>         transparently and removes any type it does not
> support. Thus
> >>>>         assuming that the S-PE node supports both CW and TTL=1
> >>>>         methods, the two T-PE nodes will advertise their
> capability
> >>>>         and select one of the two (CW or TTL=1) to be used
> >>>>         end-to-end across all segments of the MS-PW as
> if they were
> >>>>         directly connected.
> >>>>
> >>>>         Regards,
> >>>>         Mustapha.
> >>>>
> >>>>
> --------------------------------------------------------------
> ----------
> >>>>             *From:*
> >>>>             <mailto:[email-masked]>[email-masked]
> >>>>             <mailto:[email-masked]> [
> >>>>
> <mailto:[email-masked]>mailto:[email-masked]]
> >>>>             *On Behalf Of *Sam Aldrin
> >>>>             *Sent:* Monday, July 12, 2010 11:56 AM
> >>>>             *To:* Anup Kumar Vasudevan
> >>>>             *Cc:* <mailto:[email-masked]>[email-masked]
> >>>>             <mailto:[email-masked]>; venkatesan mahalingam
> >>>>             *Subject:* Re: [PWE3] Clarification request
> on VCCV CC
> >>>>             types usage per PW
> >>>>
> >>>>             I don't think section 7 of RFC is entirely valid for
> >>>>             multi-segment scenarios, where it says
> >>>>             "When multiple capabilities match, onlyone
> CC Type MUST
> >>>>             be used."
> >>>>
> >>>>             One could have CC type 1 (CW) along with CC
> type 3 (ttl)
> >>>>             i.e. type1+type3 could co-exist at the same
> time and the
> >>>>             packets could be encapsulated that way.
> >>>>
> >>>>             -sam
> >>>>
> >>>>             On Jul 12, 2010, at 8:35 AM, Anup Kumar Vasudevan
> >>>>             (anuvasud) wrote:
> >>>>
> >>>>>             Hi
> >>>>>             I believe that when multiple CC types are
> supported, it
> >>>>>             is upto the vendor implemtation to advertise what is
> >>>>>             needed i.e. if vendor supports all 3 modes
> then it can
> >>>>>             advertise all the 3 modes. If another
> vendor supports
> >>>>>             only 1 then it needs to advertise only that.
> >>>>>             Now in a signaling case between the above 2 vendors,
> >>>>>             the common implementation can be selected
> via signaling.
> >>>>>             Additionally if both support all the cases
> then this is
> >>>>>             the priority used to select -
> >>>>>                1.  Type 1: PWE3 Control Word with 0001b as first
> >>>>>             nibble (i.e. ACH)
> >>>>>                2.  Type 2: MPLS Router Alert Label
> >>>>>                3.  Type 3: MPLS PW Label with TTL == 1
> >>>>>             Pl. see section 4 and 7 of the RFC for more details.
> >>>>>             Thanks
> >>>>>             Anup
> >>>>>             *From:*  <mailto:[email-masked]>
> >>>>>             <mailto:[email-masked]>[email-masked]
> >>>>>             <mailto:[email-masked]> [
> >>>>>             <mailto:[email-masked]>
> >>>>>
> <mailto:[email-masked]>mailto:[email-masked]] *On
> >>>>>             Behalf Of *venkatesan mahalingam
> >>>>>             *Sent:* Monday, July 12, 2010 2:57 PM
> >>>>>             *To:*  <mailto:[email-masked]>
> >>>>>             <mailto:[email-masked]>[email-masked]
> <mailto:[email-masked]>
> >>>>>             *Subject:* [PWE3] Clarification request on VCCV CC
> >>>>>             types usage per PW
> >>>>>             Hi PWE3 group,
> >>>>>             In RFC-5085, section 5.3 VCCV capability
> advertisement
> >>>>>             for MPLS PWs, there is no clarity about the CC type
> >>>>>             usage per PW.
> >>>>>             So, can we have different CC type
> configurations per PW
> >>>>>             if the node supports more than one CC types?
> >>>>>             Example:
> >>>>>             MPLS capable PW originating node supports
> all three CC
> >>>>>             types [1. ACH 2. Router alert label 3. TTL
> expiry] for
> >>>>>             OAM packets demultiplexing.
> >>>>>             In this case, please clarify the below
> configurations
> >>>>>             per PW is valid.
> >>>>>             Can 3 PWs be setup with below configurations even
> >>>>>             though the PW originating node supports all
> CC types?
> >>>>>             1. PW-1 setup with ACH as CC type
> >>>>>             2. PW-2 setup with Router alert label as CC type
> >>>>>             3. PW-3 setup with TTL expiry as CC type
> >>>>>             or
> >>>>>             Does RFC mandate to send all supported CC
> types in all
> >>>>>             the three PWs?
> >>>>>
> >>>>>
> >>>>>             --
> >>>>>             Best Regards,
> >>>>>             Venkatesan Mahalingam.
> >>>>>             _______________________________________________
> >>>>>             pwe3 mailing list
> >>>>>             <mailto:[email-masked]>
> >>>>>             <mailto:[email-masked]>[email-masked]
> <mailto:[email-masked]>
> >>>>>             <https://www.ietf.org/mailman/listinfo/pwe3>
> >>>>>
> >>>>>
> <https://www.ietf.org/mailman/listinfo/pwe3>https://www.ietf.org/m
> >>>>> ailman/listinfo/pwe3
> >>>>
> >>>>         _______________________________________________
> >>>>         pwe3 mailing list
> >>>>         <mailto:[email-masked]>[email-masked]
> <mailto:[email-masked]>
> >>>>
> >>>>
> <https://www.ietf.org/mailman/listinfo/pwe3>https://www.ietf.org/ma
> >>>> ilman/listinfo/pwe3
> >>
>

---

From: Carlos Pignataro <[email-masked]>
Date: Sat, 24 Jul 2010 21:24:17 -0400

Hi Matthew,

Many thanks for your follow-up responses and expanded details, please
see inline.

On 7/19/2010 1:57 PM, Bocci, Matthew (Matthew) wrote:
> Hi Carlos,
> 
> Thanks for your reply.
> 
>> -----Original Message----- From: Carlos Pignataro
>> [mailto:[email-masked]] Sent: 15 July 2010 17:44
>> 
>> Matthew,
>> 
>> "cc_type_to_pass_ds = cc_type_received && local_capabilities"
>> topic, let's see if there's convergence.
> 
>> Yes and no. As I think there are two potential interpretations.
>> Yes, TTL expiration happens at S-PEs, including (when crafted that
>> way) to VCCV packets. But by definition, "CC Type" means the way in
>> which the VCCV packet is intercepted. This means, IMHO, that if the
>> interception of the VCCV packet to local inspection/processing at
>> an S-PE happens due to TTL expiry, then that's CC Type 3; if that
>> PW uses a CW, then that CW needs to include the first nibble as 0x1
>> matching CC Type 1 syntax. But that does not mean it's CC Type 1.
>> 
>> "5.1.3.  TTL Expiry VCCV (Type 3) ... If the Control Word is in use
>> on this PW, it MUST also be included before the VCCV message.  This
>> is done to avoid the different ECMP hashing behavior.  In this
>> case, the CW uses the PW-ACH format described in Section 5.1.1 (see
>> Figures 3 and 4).  If the Control Word is not in use on this PW,
>> the VCCV message follows the PW Label directly."
>> 
>> Conversely, if a VCCV packet uses the PW-ACH with the first nibble
>> as 0x1, as in CC Type 1, with a high TTL (e.g., 255), then at an
>> S-PE, just by mere switching of PW Label the S-PE would not see the
>> "CC Type 1", unless it's inspecting beyond the actual function that
>> is doing (what I meant and didn't explain in detail as "DPI"). IOW,
>> to have CC Type 1 at S-PE we'd need an additional (deeper)
>> forwarding behavior.
>> 
>> Do you agree?
> 
> I think draft-ietf-pwe3-segmented-pw effectively updates this
> behavior so that all VCCV CC-Types must use TTL expiry at the S-PE.

I think that implicitly updating a standards-track functionality with an
implicitly included new behavior adds two degrees of potential confusion.

> But this is a consequence of handling standard MPLS label operation
> over multiple hops and is not specific to VCCV packets. All user and
> OAM packets must have their PW label decremented by each hop and if
> they expire they should be extracted.

IMHO, yes and no. Perhaps this is the point that needs further
clarification to fully converge;

Yes, TTL decrementing and TTL processing (including expiration) is
standard MPLS operation. But if they expire, they MUST NOT be further
forwarded, and the processing is defined at
<http://tools.ietf.org/html/rfc3032#section-2.4.2>:

   If the outgoing TTL of a labeled packet is 0, then the labeled packet
   MUST NOT be further forwarded; nor may the label stack be stripped
   off and the packet forwarded as an unlabeled packet.  The packet's
   lifetime in the network is considered to have expired.

   Depending on the label value in the label stack entry, the packet MAY
   be simply discarded, or it may be passed to the appropriate
   "ordinary" network layer for error processing (e.g., for the
   generation of an ICMP error message, see section 2.3).

I do not see the direct explicit connection. Does this mean that, at an
S-PE, for a PW with CW then the first nibble is inspected and if is 0x1
then it is treated as OAM, regardless of VCCV negotiation, in a required
fashion? And what should happen if the PW that TTL-expired does not have
a CW (the document describes assuming an MPLS Echo LSP-Ping packet, that
seems is not enough solid of an assumption)?

> This does means that Type 3 +
> CW and Type 1 behave in the same way at an S-PE.

IMHO, I actually see it as mean that Type 1 does not exist at S-PE
(because there is no interception/extraction per CW). I might be reading
too much into the actual definition (of this document)? Have in mind
though that Type 3 can exist with or without CW.

I think I see why you say that Type 3 for PWs with CW is equivalent to
Type 1. However, does this mean that S-PEs need to advertise both when
CW and only Type 3 if not CW? And really, what purpose would that serve
(saying S-PEs use only TTL expiration and the rest is to reach T-PEs is
functionally equivalent but simpler on the wire).

> However, they do not
> behave in the same way at the T-PE. I do agree with you that when
> VCCV was written in in pre-MS-PW days, when S-PEs didn't exist,
> CC-Type did strictly mean the intercept mechanism that should be
> used, but that meaning has been superseded in the sense that I
> suppose Type 1 means that at a T-PE 'On label pop, also inspect first
> nibble of CW that follows'.

I agree with the applicability (after label pop) of the definition; but
would this imply that either there is not VCCV negotiation at S-PEs or
that Type 1 is simply not possible at S-PEs?

> There is a PW label swap at an S-PE, so
> this part of the behavior does not apply there, and the only way to
> further inspect any PW traffic is through a TTL expiry, irrespective
> of the CC-Type that the T-PEs advertise.

Yes. Exactly. I was assuming that the simplest definition (from an
interop perspective) is to say explicitly that i. the VCCV CC
negotiation is end-to-end (T-PE to T-PE), ii. to reach an S-PE only TTL
value setting is used (i.e., always only "Type 3" to a segment), and
iii. using CC Type 1 (to reach the remote T-PE) MUST use a large enough
TTL value in the PW label.

Part of the problem is, I think, that the proposal to clear unsupported
CC Types at an S-PE, given the above, would always negate Type 1.
Reading more specifics:

9.5.2.1. End to End Connectivity Verification Between T-PEs

http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-15#section-9.5.2.1

   Note that there is no
   requirement for the S-PE to inspect the CW. Thus, the end-to-end
   connectivity of the multi-segment pseudowire can be verified by
   performing all of the following steps:
...
       -ii. T-PE sets the inner PW label TTL to the exact value to allow
            the packet to reach the far end T-PE. ( the value is
            determined by counting the number of S-PEs from the control
            plane information ) Alternatively, if CC type 1 is supported
            the packet can be encapsulated according to CC type 1 in
            [RFC5085]
...
        -v. There is no requirement for the S-PE to inspect the CW.

I think that functional description is great, but in essence is not
defining what to do (or how it applies) to CC Type negotiation. When
setting the "inner PW label TTL to the exact value to allow the packet
to reach the far end T-PE", then T-PEs should have negotiated Type 3.
and if "there is no requirement for the S-PE to inspect the CW" then
S-PEs cannot negotiate Type 1. Or again make explicit that: i. there is
no CC Type VCCV negotiation at S-PEs, it is only and always Type 3
behavior, ii. S-PEs pass VCCV signaling so that it applies end-to-end
only, and iii. Type 1 MUST use high enough TTL.

The next section starts:

9.5.2.2. Partial Connectivity Verification from T-PE

   In order to trace part of the multi-segment pseudowire, the TTL of
   the PW label may be used to force the VCCV message to 'pop out' at an
   intermediate node. When the TTL expires, the S-PE can determine that
   the packet is a VCCV packet by either checking the control word (CW),
   or if the CW is not in use by checking for a valid IP header with UDP
   destination port 3503.  The packet should then be diverted to VCCV
   processing.

I agree with the use in the first sentence. I was not able to find how
the negotiation of CC Types allows this. In fact, I think that
<http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-15#section-9.3>
prevents it:

   The local processing of
   the VCCV parameter removes CC Types specified by the originating T-PE
   that are not supported on the S-PE. For example, if T-PE1 indicates
   supports CC Types 1,2,3 and the Then the S-PE removes the Router
   Alert CC Type=2, leaving the rest of the TLV unchanged, and passes
   the modified VCCV parameter to the next S-PE along the path.

   The far end T-PE (T-PE2) receives the VCCV parameter indicating only
   the CC types that are supported by the initial T-PE (T-PE1) and all
   S-PEs along the PW path.

I think these two paragraphs can null-out all VCCV CCs.

I also think there is another detail: If there is no CW, the processing
says to "check for a valid IP header with UDP destination port 3503".
What if the payload contains:
. An IPL2 PW with a CE-CE UDP packet with destination port 3503? False
  positive, mis-processing.
. A VCCV packet not using MPLS Echo (lsp-ping) but ICMP or BFD (CV
  Types)? Missed OAM.

This might go back to RFC3032's:

   Depending on the label value in the label stack entry, the packet MAY
   be simply discarded, or it may be passed to the appropriate
   "ordinary" network layer for error processing (e.g., for the
   generation of an ICMP error message, see section 2.3).

What is the "ordinary" processing (since it seems it is not explicitly
spec'd/required)?

> 
>>> One issue for me is how you guarantee that the VCCV packet flow
>>> is bounded to the span of the PW. As you point out below, you
>> can use the
>> applicability of preferred modes? E.g., utilizing the S-PE TLV and
>> TTL setting for intra-AS scenarios, and other in inter-AS.
>> 
> 
> I am not sure you can generalise to inter/intra AS as there are
> no-doubt intra-AS scenarios where security is still important, and
> there are inter-AS scenarios where the full path of the ms-pw can be
> determined e.g. single operators with multiple AS's. I think we
> should be more specific e.g. stating whether the full hop count can
> be reliably determined and whether an intermediate S-PE could insert
> VCCV traffic with the wrong TTL.

I agree.

> 
>> Like you say it's not safe to send traffic onto the AC; but would
>> that argue for managing the capability spaces independently between
>>  end-to-end ping and intermediate-hop trace, and preferring CC Type
>> 1 for T-PE termination?
> 
> Yes, although I am not sure we can manage them completely
> independently, but certainly it does make sense to say that while
> Type 1 is important at the T-PEs, Type 1 and Type 3 (with CW) are
> really equivalent at the S-Pes, and that they can interoperate.

This is tricky, I think, because where the document says:
http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-15#section-9.4.1

   When using CC type 1 for MS-PWs the PE transmitting
   the VCCV packet MUST set the TTL to the appropriate value to reach
   the destination S-PE.

Does a T-PE know if Type 1 is supported 3 S-PE hops downstream? Does a
T-PE know what each S-PE support in regards of CC Types? Using Type 3
for a PW with CW, sets the first nibble to 0x1 but it is still Type 3,
not Type 1. Would it be simpler to just spec only and always Type 3 at
S-PEs, and nego happen end-to-end only? I am not sure (as per above) of
the equivalence you say (and also not clear how a T-PE would know what
each one of the S-PEs supports).

> Nodes
> that only support TTL==1 + CW, could advertise Type 1 for PWs for
> which they act as an S-PE and interoperate if the Type 1 nodes accept
> it e.g. as follows:
> 
> 
> Let's say the S-PE supports only Type 3+ CW, but advertises both Type
> 3 and Type 1 to the T-Pes. 

If I understand your example correctly (and I may be misunderstanding),
advertising something that is not supported at an S-PE would be against
the spec.

Based on the spec, if the S-PE supports only Type 3, then there is no
VCCV because the S-PE (as written) has to clear unsupported bits and
pass downstream.

Similarly, if you add to the ASCII art another intermediate S-PE that
wants to not advertise VCCV (local capabilities == null), then
end-to-end breaks again. No?

> It also accepts the type 1 advertisement
> from T-PE1 and T-PE2. T-PE1 and T-PE2 use only Type 1 for the reasons
> discussed above. So the PW segments both come up.
> 

If reaching S-PEs is solely based on this "assumption", why not remove
it as "assumption" and make it explicit? In which case, what is the
purpose of "negotiating" at S-PE?

> The S-PE can ping the T-PEs because it sets the first nibble of the
> VCCV CW correctly, which means that when they pop the PW label, they
> generate the correct exception.

I see it as follows: there are a few specific scenarios in which the
description works (and arguably very common ones). But there are cases
(as I think I show above) the current description breaks.

I think another gap is in regards to use of BFD as a CV Type.

Thanks,

-- Carlos.

>>> Behalf Of *Carlos Pignataro (cpignata) *Sent:* 15 July 2010 02:59
>>>  *To:* Aissaoui, Mustapha (Mustapha) *Cc:* [email-masked];
>>> venkatesan mahalingam *Subject:* Re: [PWE3] Clarification request
>>> on VCCV CC
>> types usage
>>> per PW
>>> 
>>> Mustapha,
>>> 
>>> than S-PE (swap). Therefore: . CW is transparent (invisible) to
>>> S-PEs unless DPI. . TTL-- and check is inherent to the S-PE
>>> function . RA will result is interception at every S-PE.
>>> 
>>>> Carlos/Sam, in fact TTL decrementing of the PW label is a
>> fundamental part of
>>>> Regards, Mustapha.
>>>> *From:* Sam   [mailto:[email-masked]] *Sent:* Tuesday, July
>>>> 13, 2010 10:57 PM *To:* Carlos Pignataro *Cc:* Aissaoui,
>>>> Mustapha (Mustapha); Anup Kumar Vasudevan; [email-masked]
>>>> <mailto:[email-masked]>; venkatesan mahalingam *Subject:* Re:
>>>> [PWE3] Clarification request on
>> VCCV CC types
>>>> usage per PW
>>>> 
>>>> a must to have in the case of MS-PW. Presence of CW(type1) or
>>>> not, one should able to support type3, in order to effectively
>>>> ping/trace SPE's
>> and TPE in MS-PW.
>>>> packet to be punted at the very next hop(SPE). Once comment
>>>> inline with %SAM.
>>>> 
>>>>> approach for VCCV for MS-PW. Specifically, I think that: 1.
>>>>> We should differentiate e2e (T-PE to T-PE) from T-PE to 
>>>>> trigger a specific S-PE to intercept the VCCV packet. 2. It
>>>>> is different at S-PEs than SS-PW, because
>> there is just
>>>>>> Sam, it is actually valid in the case of a MS-PW too. An
>>>>>> S-PE node passes the VCCV capability signaled by the T-PE 
>>>>>> Regards, Mustapha.
>>>>>> *From:* <mailto:[email-masked]>[email-masked]
>>>>>> *On Behalf Of *Sam Aldrin *Sent:* Monday, July 12, 2010
>>>>>> 11:56 AM *To:* Anup Kumar Vasudevan *Cc:*
>>>>>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>;
>>>>>> venkatesan mahalingam *Subject:* Re: [PWE3] Clarification
>>>>>> request
>> on VCCV CC
>>>>>> types usage per PW
>>>>>> 
>>>>>> multi-segment scenarios, where it says "When multiple
>>>>>> capabilities match, onlyone
>> CC Type MUST
>>>>>> be used."
>>>>>> 
>>>>>>> Hi I believe that when multiple CC types are
>> supported, it
>>>>>>> only 1 then it needs to advertise only that. Now in a
>>>>>>> signaling case between the above 2 vendors, the common
>>>>>>> implementation can be selected
>> via signaling.
>>>>>>> the priority used to select - 1.  Type 1: PWE3 Control
>>>>>>> Word with 0001b as first nibble (i.e. ACH) 2.  Type 2:
>>>>>>> MPLS Router Alert Label 3.  Type 3: MPLS PW Label with
>>>>>>> TTL == 1 Pl. see section 4 and 7 of the RFC for more
>>>>>>> details. Thanks Anup *From:*
>>>>>>> Behalf Of *venkatesan mahalingam *Sent:* Monday, July 12,
>>>>>>> 2010 2:57 PM *To:*  <mailto:[email-masked]> 
>>>>>>> *Subject:* [PWE3] Clarification request on VCCV CC types
>>>>>>> usage per PW Hi PWE3 group, In RFC-5085, section 5.3 VCCV
>>>>>>> capability
>> advertisement
>>>>>>> for MPLS PWs, there is no clarity about the CC type usage
>>>>>>> per PW. So, can we have different CC type
>> configurations per PW
>>>>>>> if the node supports more than one CC types? Example: 
>>>>>>> OAM packets demultiplexing. In this case, please clarify
>>>>>>> the below
>> configurations
>>>>>>> per PW is valid. Can 3 PWs be setup with below
>>>>>>> configurations even though the PW originating node
>>>>>>> supports all
>> CC types?
>>>>>>> 1. PW-1 setup with ACH as CC type 2. PW-2 setup with
>>>>>>> Router alert label as CC type 3. PW-3 setup with TTL
>>>>>>> expiry as CC type or Does RFC mandate to send all
>>>>>>> supported CC
>> types in all
>>>>>>> the three PWs?
>>>>>>> 
>>>>>>> 
>>>>>>> -- Best Regards, Venkatesan Mahalingam. 
>>>>>>> _______________________________________________ pwe3
>>>>>>> mailing list <mailto:[email-masked]> 
>>>>>> _______________________________________________ pwe3
>>>>>> mailing list <mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>
>>>>>>