Subject: RE: [PWE3] VCCV-12 last call

From: "O'Connor, Don" <[email-masked]>
Date: Mon, 29 Jan 2007 14:40:01 -0600

With respect to the topic raised by Neil, I think that for multi-segment pseudowires, the same CV type should be used for each pseudowire segment and the end to end pseudowire. The VCCV capability negotiation for multi-segment pseudowires should insure this uniformity.

I also believe that for multi-segment pseudowires, it should be possible to use concurrent LSP Ping + BFD. BFD for a continuous continuity check and LSP Ping for ping and path trace. For multi-domain MS-PW applications, ideally it should be possible to have an EE BFD session and additional BFD sessions for the portions of the MS-PW that traverse each provider's domain.

On the subject of MS-PW OAM, the minutes of the November PWE3 session indicate - draft-ietf-pwe3-segmented-pw-04.txt - "Will be published shortly". In there any word on when -04 will appear?

I would still suggest that Multi-Segment VCCV should be in separate draft and should address both single domain and multi-domain. For multi-domain, security issues should be considered. 

Regards

Don

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Friday, January 26, 2007 9:08 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] VCCV-12 last call

> Sorry Tom that I was not clear.....what I meant was what happens if  
> you
> use different OAM options on different LSPs/PWs and then one has
> misconnectivity between them?  I presume this has been considered?

	Yes, I think it has. I think the choice of which type of
VCCV to use for each PW is up to the PW/configuration. I don't
see how mandating that all PWs that ride on the same LSP use
the same VCCV mode needs to be mandatory. If you want to configure
this once deployed based on local policy, that is possible.
However, there might be other reasons why people might want
to deploy different modes on different PWs (say based on the
AC type), which I think is reasonable to allow as well.

> Note - If one is using a consistent OAM function on all LSPs/PWs then
> one should (however see later) have predictable behaviour under
> misconnectivity, ie the traffic unit fields relating to the OAM  
> function
> have a consistent semantic.  However, this is a more general point for
> all the fields in a traffic unit, and not just OAM (any network
> mode/technology).  For example, also see my post of yesterday on the
> thread "RE: [PWE3] Y.1720 liased text".....I attach the text for  
> ease of
> reference below:

	Again, I think that the spec. does allow for making
things consistent, if you so choose to configure your LSRs
this way.  I do know of other operators however, that wish
to use different methods on different PWs based on the AC
type.  But in the end the spec. is flexible enough to
accommodate both your and their requirements.

	--Tom

>
> ===
>
> Well, there are certainly some issues when the semantic of a specific
> field in a traffic unit is NOT consistent in any layer network.  For
> example, the MPLS label field can currently take on at least 3  
> different
> semantics, viz:
> -	a proxy for destination identifier (ie the usual
> label-swapping/forwarding paradigm)
> -	a proxy for a source identifier (ie a necessary consequence of
> (lower level) LSP merging)
> -	a 'functional action', eg various labels in the reserved
> code-space 0-15.
>
> This is not good practice IMO....and one observation here would be  
> that
> under misconnectivity incorrect downstream decisions could arise  
> (noting
> that this may not simply be between LSPs at the same level but also
> across LSPs at different levels).  Though to be strictly accurate,  
> since
> the 'functional action' labels (0-15) are partitioned from the rest of
> the label space the consequence has some certainty of (incorrect)
> action.
>
> I am not familiar with the content of Y.1720, but from what you  
> describe
> below it seems we can add yet another semantic to the label  
> field.....or
> at least *its interpretation as a label field*, under misconnectivity,
> by some LSR that unexpectedly receives it (but also see Note below).
> Does not sound very good to me.
>
> Note - If S=1 in the preceding MPLS header then there seems less of a
> problem than if S=0.....which may appear an odd observation to  
> make, but
> I do so because of this specific text Stewart extracted from Y.1720
> Appendix II (note the highlighted word 'any'):
>
> "Note that packet 1+1 can be provided at *any* level of the  
> hierarchy of
> a nested LSP."
>
> ===
>
> regards, Neil
>
>
>> -----Original Message-----
>> From: Thomas D. Nadeau [mailto:[email-masked]]
>> Sent: 25 January 2007 21:11
>> To: Harrison,N,Neil,JCGA1 R
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [PWE3] VCCV-12 last call
>>
>>
>>
>> 	I don't understand what you mean. Can you be
>> more specific in your example?
>>
>> 	--Tom
>>
>>
>>> what happens if you subsequently get misconnectivity between LSPs
>>> using
>>> different options?
>>>
>>> regards, Neil
>>>
>>>> -----Original Message-----
>>>> From: Thomas D. Nadeau [mailto:[email-masked]]
>>>> Sent: 25 January 2007 19:15
>>>> To: O'Connor, Don
>>>> Cc: pwe3; Stewart Bryant
>>>> Subject: Re: [PWE3] VCCV-12 last call
>>>>
>>>>
>>>>
>>>> On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote:
>>>>
>>>>> My reading of VCCV - 12 is that
>>>>>
>>>>> 1) It only supports BFD Base and not MPLS BFD. It can be
>> noted that
>>>>> draft-ietf-bfd-mpls-03.txt. is not listed among the references
>>>>
>>>> 	BFD-base is only required because the bootstrapping
>>>> rules required to setup BFD/VCCV are single-hop style.
>>>>
>>>>> 2) It is only possible to negotiate (by LDP) one CV
>> protocol - ICMP
>>>>> Ping, LSP Ping, or BFD (Base). So it is not possible to
>> support MPLS
>>>>> BFD which enables concurrent use of LSP Ping and BFD
>>>>
>>>> 	You do not negotiate anything per se; you advertise
>> capabilities for
>>>> VCCV. You may advertise none, one or all of the different CC/CV
>>>> combinations,
>>>> which means you are willing to accept any of those combinations
>>>> (within the
>>>> rules stipulated in the draft). The receiving side is then
>>>> free to send any of those combinations (within the rules
>>>> stipulated in the draft),
>>>> but
>>>> once one is successfully sent (and acked), no others are
>>>> allowed, and no "re-negotiation" is allowed without bringing
>>>> down the PW.  The latter
>>>> comes
>>>> specifically from the rules stipulated in RFC 4447.
>>>>
>>>> 	--Tom
>>>>
>>>>
>>>>
>>>>>
>>>>> Is my understanding accurate ?
>>>>>
>>>>> Regards
>>>>>
>>>>> Don
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stewart Bryant [mailto:[email-masked]]
>>>>> Sent: Monday, January 22, 2007 7:35 AM
>>>>> To: pwe3
>>>>> Subject: [PWE3] VCCV-12 last call
>>>>>
>>>>>
>>>>> This is the start of last call for
>>>>>
>>>>> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
>>>>>
>>>>> last call will end 6th February.
>>>>>
>>>>> There are a couple of issues that I have with regard to
>> IANA policy
>>>>> that is raised by this draft, but I will ask my questions
>> in another
>>>>> thread.
>>>>>
>>>>> Regards
>>>>>
>>>>> Stewart
>>>>>
>>>>> _______________________________________________
>>>>> pwe3 mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>>>>
>>>>> _______________________________________________
>>>>> pwe3 mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>>>
>>>> _______________________________________________
>>>> pwe3 mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>>>
>>

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 30 Jan 2007 13:57:18 -0500

> With respect to the topic raised by Neil, I think that for multi- 
> segment pseudowires, the same CV type should be used for each  
> pseudowire segment and the end to end pseudowire. The VCCV  
> capability negotiation for multi-segment pseudowires should insure  
> this uniformity.

	In practice, I see this as quite difficult to enforce given how MH
PWs work. Remember that the LSP used to get traffic across of one AS
can change, as long as the end points are the same. This means that
the PE would have to monitor the LSPs used, and make sure that no
LSPs are picked with PWs that have mixed CC/CV types.  If an operator
like Neil would like consistency, I suggest doing this through
configuration, of which there are a number of options. For example,
you can set up TE tunnels between the PEs, and explicitly tell
one subset of PWs to use one tunnel, and another the other tunnel.
Each tunnel could represent a different CC/CV configuration.

> I also believe that for multi-segment pseudowires, it should be  
> possible to use concurrent LSP Ping + BFD. BFD for a continuous  
> continuity check and LSP Ping for ping and path trace. For multi- 
> domain MS-PW applications, ideally it should be possible to have an  
> EE BFD session and additional BFD sessions for the portions of the  
> MS-PW that traverse each provider's domain.
>
> On the subject of MS-PW OAM, the minutes of the November PWE3  
> session indicate - draft-ietf-pwe3-segmented-pw-04.txt - "Will be  
> published shortly". In there any word on when -04 will appear?

	Still editing.

> I would still suggest that Multi-Segment VCCV should be in separate  
> draft and should address both single domain and multi-domain.

	I leave this up to the chairs/WG.

> For multi-domain, security issues should be considered.

	Good point.

	--Tom