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

From: <[email-masked]>
Date: Fri, 26 Jan 2007 07:31:58 -0000

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?

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:

===

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 26 Jan 2007 10:07:39 -0500

> 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.

> thread "RE: [PWE3] Y.1720 liased text".....I attach the text for  

	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