Vancouver slides

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Dec 18, = 2007, at 9:55 AM, Orly Nicklass wrote:

Finally got = the time to handle the comments.
Tnx for the = detailed review.
New draft will be issued = shortly

Orly Nicklass, = Ph.D
Head of Research & = Development
3 Hanagar St. Neve Ne'eman = B
Hod Hasharon, Israel
Tel: +972-9-7751290
: +972-54-2209565
From: WIJNEN, Bert (Bert) = [
Sent: Wednesday, October 17, 2007 = 16:40
To: Orly Nicklass
Cc: pwe3@ietf.org; dromasca@avaya.com; MIB Doctors = (E-mail)
MIB Doctor review of: = draft-ietf-pwe3-tdm-mib-08.txt

First, I am not subscribed = to the WG mailing list, so pls copy me if you want me to see any = comments/responses.

Pls note that revision 8 has expired. I have = reviewed the copy I still had on my machine.

Here are my = comments.

C:\bwijnen\smicng\work>smicng = pwTdm.inc

E: f(pwTdm.mi2), (855,24) Index item = "pwTDMPerfIntervalNumber" must
     be defined = with syntax that includes a range
E: f(pwTdm.mi2), (1027,23) = Index item "pwTDMPerf1DayIntervalNumber"
     = must be defined with syntax that includes a range

The above two = SMICng errors can/should be fixed:

   = pwTDMPerfIntervalNumber OBJECT-TYPE
     = SYNTAX        = Unsigned32
     MAX-ACCESS    = not-accessible
     = STATUS        = current
     = DESCRIPTION
         "A = number (normally between 1 and 96 to cover a 24 = hour
          period) = which identifies the interval for which the = set
          of = statistics is available. The interval identified by = 1
          is the most = recently completed 15 minute interval, = and
          the = interval identified by N is the interval = immediately
          = preceding the one identified by N-1. The minimum range = of
          N is 1 = through 4. The default range is 1 through 32. = The
          maximum = value of N is 1 through 96."
     ::=3D { = pwTDMPerfIntervalEntry 1 }

The DESCRIPTION clause already states = that a SYNTAX of
     = SYNTAX        Unsigned32 = (1..96)
makes sense
[[Orly Nicklass]] done
And = for

   pwTDMPerf1DayIntervalNumber = OBJECT-TYPE
     = SYNTAX        = Unsigned32
     MAX-ACCESS    = not-accessible
     = STATUS        = current
     = DESCRIPTION
         "The = number of interval, where 1 indicates current = day
          measured = period and 2 and above indicate previous = days
          = respectively"
     ::=3D { = pwTDMPerf1DayIntervalEntry 1 }
[[Orly = Nicklass]]
left as = is

I see
     ::=3D { transmission = XXX }
   -- RFC Editor: replace XXX with IANA-assigned = number & remove this
   -- note. Please see IANA = considerations section

And again I wonder if allocation under = transmission is correct/justified.
You do not want a PW to be an = entry in the ifTable. And transmission is for media-specific MIB data = for an interface of a specific ifType.
SO I think allocation under = mib-2 makes more sense.[[Orly = Nicklass]] done

I = see:
   -- Tables, Scalars
   = pwTDMObjects       OBJECT = IDENTIFIER
          =             &n= bsp;         ::=3D { pwTDMMIB 1 = }
   -- Notifications
   pwTDMNotifications = OBJECT = IDENTIFIER
          =             &n= bsp;         ::=3D { pwTDMMIB 2 = }

   -- Conformance
   = pwTDMConformance   OBJECT = IDENTIFIER
          =             &n= bsp;         ::=3D { pwTDMMIB 3 = }

Why not follow RFC4181 suggestion (so all MIB modules are = more
consistent)
and use instead:
   -- = Notifications
   pwTDMNotifications OBJECT = IDENTIFIER
          =             &n= bsp;         ::=3D { pwTDMMIB 0 = }

   -- Tables, Scalars
   = pwTDMObjects       OBJECT = IDENTIFIER
          =             &n= bsp;         ::=3D { pwTDMMIB 1 = }
   -- Conformance
   = pwTDMConformance   OBJECT = IDENTIFIER
          =             &n= bsp;         ::=3D { pwTDMMIB 2 = }
[[Orly Nicklass]] done
- In = pwTDMEntry DESCRIPTION clause I = see:
          Unless = otherwise specified, all RW objects in this = table
          MUST NOT = be changed after row activation (see = [PWMIB])
          and = should remain unchanged after reboot."

I guess that RW = means read-write (or better writable)
I guess with "should = remain unchanged after reboot" you mean
that the values must = persis over a restart/reboot? I would
make that wording a bit = clearer then.
I am not sure what "row activation" means = here.
The row gets created by the agent according to your = description
clause. So to me it seems that the row then is = "active", no?[[Orly Nicklass]] no
= Maybe you mean that the row becomes active once/if the base
= row in the generic pwTable becomes active?[[Orly = Nicklass]] yes
= Anyway, you want to be cleaerer as to what you mean here.
It = is better to not use citations (like [PWMIB]) in DESCRIPTION
= clauses.
[[Orly Nicklass]] done
- = For
   pwTDMCfgIndex   = OBJECT-TYPE
     = SYNTAX        = PwTDMCfgIndex
     MAX-ACCESS    = not-accessible
     = STATUS        = current
     = DESCRIPTION
         "Index = to an entry in this table. The value is a copy of = the
          assigned = pwTDMCfgIndexNext"
     ::=3D { pwTDMCfgEntry 1 = }

I am not sure I would use such a DESCRIPTION clause. = Maybe better
would be somethink = aka:
     = DESCRIPTION
         "Index = to an entry in this table. When an NMS wants to = create
          a new = entry/row in this table, it best makes use of the = value
          of the = pwTDMCfgIndexNext object in order to find a free = or
          available = index value."[[Orly Nicklass]] done

- = I see
   pwTDMCfgRowStatus    = OBJECT-TYPE
     = SYNTAX           &n= bsp;   RowStatus
     = MAX-ACCESS           = read-create
     = STATUS           &n= bsp;   current
     = DESCRIPTION
         "Object = used for creating, modifying, and = deleting
          a row = from this table. The following objects should not = be
          modified if = the entry is in used and the status is = active:
          = pwTDMCfgPayloadSize, = pwTDMCfgRtpHdrUsed,
        &nb= sp; pwTDMCfgJtrBfrDepth, and = pwTDMCfgPayloadSuppression.
       &= nbsp; The row should not be deleted if the entry is in = used"

The wording about "should not be modified" indeed = belongs here
(and so I think some text in pwTDMCfgEntry = DESCRIPTiON can
   be removed, = namely:
          Unless = otherwise specified, all objects in this = table
          MUST NOT = be changed after row activation (see = [PWMIB])
          if = the row index is in used by an entry in pwTDMTable.[[Orly Nicklass]] left = in
I would also reword the text here a bit and = instead of
"should not be modfied" I would say "cannot be = modified" or
"MUST NOT be modified". That shows to agent = implementers that
they can reject such a change request, = where-as a "should not"
seems to be just friendly advise to an = NMS.
Just my subjective reading I guess.

The = last sentence again, I would say the row cannot be deleted.
or = the row MUST NOT be deleted.
[[Orly = Nicklass]] [[Orly Nicklass]] done
- = For
   pwTDMCfgPktReorder = OBJECT-TYPE
     = SYNTAX        = TruthValue
     MAX-ACCESS    = read-create
     = STATUS        = current

     = DESCRIPTION
         "If set = True: as CE bound packets are queued in = the
          jitter = buffer, out of order packets are re-ordered. = The
          maximum = sequence number differential (i.e., the range = in
          which = re-sequencing can occur) is dependant on the = depth
          of the = jitter buffer. See = pwTDMCfgJtrBfrDepth.

       &nbs= p; NOTE: Some implementations may not support this = feature.
          The = agent is then required to set this to = False."
     ::=3D { pwTDMCfgEntry 5 = }

I think I would change the last sentence = to
          The agent = should then reject a SET request for true.[[Orly = Nicklass]] [[Orly Nicklass]] done

- = This one
   pwTDMCfgPayloadSuppression = OBJECT-TYPE
     = SYNTAX        = INTEGER
          &nb= sp;         = {
           &nb= sp;           = enable ( = 1),
           &= nbsp;           = disable ( = 2)
           &n= bsp;        }
Could also be = represented with a SYNTAX of TruthValue, for = example
     = pwTDMCfgEnablePayloadSuppression = OBJECT-TYPE
        = SYNTAX        TruthValue
= That would mean re-use of an already existing TC.
Not a major = issue, just better re-use.[[Orly Nicklass]] stays as is due to existing = implementations

- W.r.t.
   = pwTDMCfgConsecPktsInSynch        &= nbsp; OBJECT-TYPE
     = SYNTAX        = Unsigned32
     MAX-ACCESS    = read-create
     = STATUS        = current
     = DESCRIPTION
         "The = number of consecutive packets with = sequential
          = sequence numbers that are required to exit = the
          LOPS = state.
          = Object MAY be changed when the related PW = is
          defined as = not active."
     = REFERENCE
         = "SATOP"
     DEFVAL { 2 = }
     ::=3D { pwTDMCfgEntry 9 = }

   pwTDMCfgConsecMissPktsOutSynch = OBJECT-TYPE
     = SYNTAX        = Unsigned32
     MAX-ACCESS    = read-create
     = STATUS        = current
     = DESCRIPTION
         "The = number of consecutive missing packets that = are
          required = to enter the LOPS = state.
          = Object MAY be changed when the related PW = is
          defined as = not active."
     REFERENCE

I am = not sure if the value zero makes sense (ever)?[[Orly Nicklass]] no
= If not, then I would exclude it. If it does, then may
be some = explanatory text is needed.
I also wonder if there is some = sensible upper limit
lowe than 4 billion (as is now the = case).

Also the "May be changed" ?? I wonder if you = mean
"MAY only be changed". or "Can only be changed"
= or "MUST NOT be changed when ... is active"?[[Orly Nicklass]] [[Orly Nicklass]] not = really

- For
   pwTDMCfgAlarmThreshold = OBJECT-TYPE
     = SYNTAX        = Unsigned32
     MAX-ACCESS    = read-create
     = STATUS        = current
     = DESCRIPTION
         "Alarms = are only reported when the defect state = persists
          for = the length of time specified by this = object.
          The = object's unit is millisec.

maybe add a UNITS = clause
same for pwTDMCfgClearAlarmThreshold[[Orly Nicklass]] done

- = FOr
   pwTDMCfgStorageType = OBJECT-TYPE
     = SYNTAX            = StorageType
     = MAX-ACCESS        = read-create
     = STATUS            = current
     = DESCRIPTION
         "This = variable indicates the storage type for = this
          = row."
     ::=3D { pwTDMCfgEntry 19 = }

The DESCRIPTION clause must state if (and if so which) = any
columnds MUST be writeable for 'permanent' = entries.

- For
   pwTDMCfgPktFiller = OBJECT-TYPE

      = SYNTAX        Unsigned32 = (0..255)
      MAX-ACCESS    = read-create
      = STATUS        = current
      = DESCRIPTION
          = "Filler byte pattern played out on the TDM

Is this really = an unsigned32, or would OCTET STRING (SIZE (1)) be
a better = representation. I can live with what you have. I am just
= thinking/wondering aloud.[[Orly Nicklass]] will stay as = is

- I can live with this SEQUENCE
   = PwTDMCfgEntry ::=3D SEQUENCE = {
        = pwTDMCfgIndex          &= nbsp;         = PwTDMCfgIndex,
        = pwTDMCfgRowStatus         &nb= sp;      = RowStatus,
        = pwTDMCfgPayloadSize         &= nbsp;    = Unsigned32,
        = pwTDMCfgPktReorder         &n= bsp;     = TruthValue,
        = pwTDMCfgRtpHdrUsed         &n= bsp;     = TruthValue,
        = pwTDMCfgJtrBfrDepth         &= nbsp;    = Unsigned32,
        = pwTDMCfgPayloadSuppression       = INTEGER,

        = pwTDMCfgConsecPktsInSynch        = Unsigned32,
        = pwTDMCfgConsecMissPktsOutSynch   = Unsigned32,
        = pwTDMCfgSetUp2SynchTimeOut       = Unsigned32,

        = pwTDMCfgPktReplacePolicy         = INTEGER,

        = pwTDMCfgAvePktLossTimeWindow     = Integer32,
        = pwTDMCfgExcessivePktLossThreshold   = Unsigned32,

        = pwTDMCfgAlarmThreshold        &nbs= p; Unsigned32,
        = pwTDMCfgClearAlarmThreshold      = Unsigned32,

        = pwTDMCfgMissingPktsToSes         = Unsigned32,

        = pwTDMCfgTimestampMode         = ;   INTEGER,
        = pwTDMCfgStorageType         &= nbsp;    = StorageType,
        = pwTDMCfgPktFiller         &nb= sp;      = Unsigned32,
        = pwTDMCfgName          &n= bsp;          = SnmpAdminString
        = }
But since this is the initial revision of the MIB = module,
would it not make sense to locate the StoragType = and
RowStatus close to each other? Just wondering = aloud.
It would be more consistent with other IETF defined = MIB
modules.[[Orly Nicklass]] will stay as is due to = existing implementations

- For
   = pwTDMPerfIntervalDuration OBJECT-TYPE
      = SYNTAX      Unsigned32

   = Might want to add a UNITS clause

same for = pwTDMPerf1DayIntervalDuration[[Orly = Nicklass]] done for = both

- For this
   = pwTDMGroups      OBJECT IDENTIFIER ::=3D { = pwTDMConformance 1 }
   pwTDMCompliances OBJECT IDENTIFIER = ::=3D { pwTDMConformance 2 }

I would follow RFC4181 and = turn the sequence around, i.e.

   pwTDMCompliances = OBJECT IDENTIFIER ::=3D { pwTDMConformance 1 }
   = pwTDMGroups      OBJECT IDENTIFIER ::=3D { = pwTDMConformance 2 }

- In = MODULE-COMPLIANCE

        &= nbsp;           OBJECT = pwGenTDMCfgIndex
         =            MIN-ACCESS = read-only
          &= nbsp;         = DESCRIPTION
          = ;            &= nbsp; "The ability to set the an index = pointer
          &nb= sp;            = ; is not required."

typo: s/the an index/an = index/[[Orly Nicklass]]   I = like yours somewhat better, cause it is more explicit as
to = what the reault of read-only access is.

Several comments are = made once, but apply to other places as well.
Pls do check for = similar occurences.

----- admib/bureaucratic/typos etc

- = no citations to two referenced documents:
!! Missing citation = for Normative reference:
P040 L023:    = [G.704]      ITU-T Recommendation G.704 (10/98) = -
Synchronous frame

!! Missing citation for Normative = reference:
P040 L027:    [ITU-T-G.826] ITU-T = G.826: Error performance parameters
and

- In security = Considerations Section, pls s/IPSec/IPsec/
sec must be all = lowercase.
[[Orly Nicklass]] done for the last = 3

Bert = Wijnen
___________________________= ____________________
pwe3 mailing list
pwe3@ietf.org
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51GM-00060w-HG; Wed, 19 Dec 2007 10:55:14 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J51GL-0005yQ-R2 for pwe3-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 10:55:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51GL-0005yA-H4 for pwe3@ietf.org; Wed, 19 Dec 2007 10:55:13 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J51GK-0000UV-Od for pwe3@ietf.org; Wed, 19 Dec 2007 10:55:13 -0500 X-IronPort-AV: E=Sophos;i="4.24,185,1196636400"; d="scan'208";a="1327802" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Dec 2007 16:55:12 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBJFtB89016331; Wed, 19 Dec 2007 16:55:11 +0100 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp4103.cisco.com [10.61.80.6]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBJFt6AC016981; Wed, 19 Dec 2007 15:55:07 GMT Message-ID: <47693EDA.7050908@cisco.com> Date: Wed, 19 Dec 2007 15:55:06 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Huub van Helvoort References: <4766ED8D.5040207@chello.nl> <47670240.5040809@cisco.com> <47670687.90206@chello.nl> In-Reply-To: <47670687.90206@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2663; t=1198079711; x=1198943711; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20progress=20of=20G.8113=20and=20G.8114 |Sender:=20; bh=wnSog0j6QhoQxSpSY85a0CFVUWWs276oMuaCOurJxdw=; b=qdAPMb82Fcqx4GNa0VbTaegKz/gdlPGTp5H/x97laH5oLl+v2gFB4gJ677 7o+nWSS7Lp5pEORqLPS7h7xoKtxMd8Z97BEMAbBHGZQc3fqlGhbrlIibaZy/ DwevZf2K/L; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Q5/13 , t-mpls-dt@testbed.se, pwe3 Subject: [PWE3] Re: progress of G.8113 and G.8114 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Huub The change that you propose is a fundamental change to the whole rational for designing an OAM specifically for T-MPLS rather than reusing an existing pseudowire OAM design. It has always been asserted by the T-MPLS designers that T-MPLS has special failure modes that did not apply to PWE3/MPLS and therefore existing OAM mechanisms such as RFC5085 (VCCV) were not appropriate. When challenged to specify these, none have been provided and now it is proposed to answer this long outstanding AAP issue by changing the language to indicate that there are no special T-MPLS failure modes. This change to the requirements demonstrates that the fundamental technical basis for rejecting the IETF OAM methods was flawed, and this decision therefore needs to be revisited. G.8113 and G.8114 should now be put on hold whilst the implications of this are properly evaluated. The least that you should do is to change the text of the requirement to "T-MPLS provides a connection-oriented layer network and hence there will be failure modes that are only relevant to the T-MPLS layer. Detection of these failure modes is possible through the use of RFC5085" and then to add RFC5085 as a candidate solution in G.8114 using the text that has already been provided. However designing a second OAM for pseudowire is not in the best interests of the operator community and it would be better to abandon this approach and to bring any additional requirements to the IETF for incorporation in VCCV. Stewart Huub van Helvoort wrote: > Hello Steward, > > Thank you for helping me. > > You wrote: > >>> Unfortunately there are still comments that are not resolved. >>> Are there any other proposals that will help to resolve the >>> open issues and get G.8113 and G.8114 approved. >> Just looking at the first unresolved comment, you could list >> the failure modes that apply to T-MPLS but not to MPLS >> as requested in the issue. >> >> Alternatively you could state that there are no failure >> modes that apply to T-MPLS that do not apply to >> one or more MPLS modes. > > Your comment made me read the original text very carefully, and > I found that the sentence: > > "T-MPLS provides a connection-oriented layer network and hence > there will be failure modes that are only relevant to T-MPLS." > > is the cause of your question. > It should have been: > "T-MPLS provides a connection-oriented layer network and hence > there will be failure modes that are only relevant to > the T-MPLS layer." > > I will make this change to resolve this issue. > > Cheers, Huub. > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 19 12:45:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52z2-0000Dt-Ks; Wed, 19 Dec 2007 12:45:28 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J52z2-0000Dl-1I for pwe3-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 12:45:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52z1-0000D8-NW for pwe3@ietf.org; Wed, 19 Dec 2007 12:45:27 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J52yz-0003Ax-O0 for pwe3@ietf.org; Wed, 19 Dec 2007 12:45:27 -0500 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 17:45:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Dec 2007 17:45:25 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C019E5E16@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <7281A4AFD0208245879A42E99F5340F2C79CAD@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: progress of G.8113 and G.8114 Thread-Index: AchCV42SKMIppQeHQoGmQ6XC0YdhvwAB3VwgAAFBIeA= From: To: , , X-OriginalArrivalTime: 19 Dec 2007 17:45:46.0364 (UTC) FILETIME=[FC18CBC0:01C84266] X-Spam-Score: -1.0 (-) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: tsg13q5@itu.int, t-mpls-dt@testbed.se, pwe3@ietf.org Subject: [PWE3] RE: progress of G.8113 and G.8114 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Guys, Think we need to be a little more precise here. PWs may have started life as some form of adaptation, primarily to deal with the fact that MPLS does not treat all its clients the same (and some problems are exposed when attempting to use ECMP techniques because of this), but PWs are now developing into a full blown layer network in their own right. More specifcally we cannot say that the functional components of MPLS are the same as those of PWs. And if we take the PW OAM component then this runs in a muxed-in channel with the control-word. Trying to be even more accurate, what we have in the case of PWs (and only PWs, ie does not apply to MPLS) is the emergence of a PID field occuring in the first nibble after the PW labelled header...and it is this field (when it takes on the value 0001) that indicates 'PW OAM' So, to put this more succintly: MPLS OAM !=3D PW OAM. If this is not clear, then consider the effect of misconnectivity beween a LSP carrying a PW and a 'normal' MPLS LSP. And to be super accurate here, we should also note that the CI (Characteristic Information) of the traffic unit in the 2 cases is not the same in other respects, eg the 'normal' label of an MPLS LSP is a proxy for a destination address (ie forwarding semantic) whilst the label of a PW LSP is a proxy for a source adddress (ie a demerging semantic....necessary if LDP is being used).=20 T-MPLS OAM is something else all together. So we can extend to say: MPLS OAM !=3D PW OAM !=3D T-MPLS OAM. Then there is the issue of PWs over T-MPLS....so what do we have here? Think some clarity is required in being precise as to *which* layer network one is talking about when discussing the OAM. Hope you can understand the points I'm making here. regards, Neil > -----Original Message----- > From: owner-tsg13q5@itu.int [mailto:owner-tsg13q5@itu.int] On=20 > Behalf Of J. Rao Cherukuri > Sent: 19 December 2007 16:52 > To: stbryant@cisco.com; Huub van Helvoort > Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 > Subject: RE: progress of G.8113 and G.8114 >=20 >=20 > Stewart, >=20 > I agree with your proposed suggestion. This is inline with=20 > one of the Juniper AAP comment not yet resolved. >=20 > Regards > Rao Cherukuri=20 >=20 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: Wednesday, December 19, 2007 10:55 AM > To: Huub van Helvoort > Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 > Subject: Re: progress of G.8113 and G.8114 >=20 >=20 >=20 > Huub >=20 > The change that you propose is a fundamental change > to the whole rational for designing an OAM specifically > for T-MPLS rather than reusing an existing pseudowire > OAM design. >=20 > It has always been asserted by the T-MPLS designers > that T-MPLS has special failure modes that did not > apply to PWE3/MPLS and therefore existing OAM > mechanisms such as RFC5085 (VCCV) were not appropriate. > When challenged to specify these, none have been provided > and now it is proposed to answer this long outstanding > AAP issue by changing the language to indicate that > there are no special T-MPLS failure modes. >=20 > This change to the requirements demonstrates that > the fundamental technical basis for rejecting the > IETF OAM methods was flawed, and this decision therefore > needs to be revisited. >=20 > G.8113 and G.8114 should now be put on hold whilst the=20 > implications of this are properly evaluated. >=20 > The least that you should do is to change the text > of the requirement to >=20 > "T-MPLS provides a connection-oriented layer network and=20 > hence there will be failure modes that are only relevant to=20 > the T-MPLS layer. Detection of these failure modes is=20 > possible through the use of RFC5085" >=20 > and then to add RFC5085 as a candidate solution in G.8114=20 > using the text that has already been provided. >=20 > However designing a second OAM for pseudowire is not in the=20 > best interests of the operator community and it would be=20 > better to abandon this approach and to bring any additional=20 > requirements to the IETF for incorporation in VCCV. >=20 > Stewart >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Huub van Helvoort wrote: > > Hello Steward, > > > > Thank you for helping me. > > > > You wrote: > > > >>> Unfortunately there are still comments that are not resolved. Are=20 > >>> there any other proposals that will help to resolve the=20 > open issues=20 > >>> and get G.8113 and G.8114 approved. > >> Just looking at the first unresolved comment, you could list the=20 > >> failure modes that apply to T-MPLS but not to MPLS as requested in=20 > >> the issue. > >> > >> Alternatively you could state that there are no failure modes that=20 > >> apply to T-MPLS that do not apply to one or more MPLS modes. > > > > Your comment made me read the original text very carefully, and I=20 > > found that the sentence: > > > > "T-MPLS provides a connection-oriented layer network and=20 > hence there=20 > > will be failure modes that are only relevant to T-MPLS." > > > > is the cause of your question. > > It should have been: > > "T-MPLS provides a connection-oriented layer network and=20 > hence there=20 > > will be failure modes that are only relevant to the T-MPLS layer." > > > > I will make this change to resolve this issue. > > > > Cheers, Huub. > > >=20 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 19 13:36:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53mT-000835-Hb; Wed, 19 Dec 2007 13:36:33 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J53mR-000830-Ru for pwe3-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 13:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53mR-00082s-IC for pwe3@ietf.org; Wed, 19 Dec 2007 13:36:31 -0500 Received: from static-72-71-250-34.cncdnh.fios.verizon.net ([72.71.250.34] helo=lucidvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J53mM-0004RF-Sl for pwe3@ietf.org; Wed, 19 Dec 2007 13:36:31 -0500 Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 1E3EA75A29; Wed, 19 Dec 2007 10:36:41 -0800 (PST) Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05588-03; Wed, 19 Dec 2007 10:36:40 -0800 (PST) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 2916275A17; Wed, 19 Dec 2007 10:36:40 -0800 (PST) Message-Id: From: Thomas Nadeau To: In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C019E5E16@E03MVB2-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [PWE3] RE: progress of G.8113 and G.8114 Date: Wed, 19 Dec 2007 13:36:21 -0500 References: <2ECAA42C79676B42AEBAC11229CA7D0C019E5E16@E03MVB2-UKBR.domain1.systemhost.net> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: tsg13q5@itu.int, pwe3@ietf.org, cherukuri@juniper.net, t-mpls-dt@testbed.se, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Dec 19, 2007, at 12:45 PM, wrote: > Guys, > > Think we need to be a little more precise here. PWs may have started > life as some form of adaptation, primarily to deal with the fact that > MPLS does not treat all its clients the same (and some problems are > exposed when attempting to use ECMP techniques because of this), but > PWs > are now developing into a full blown layer network in their own right. > More specifcally we cannot say that the functional components of MPLS > are the same as those of PWs. And if we take the PW OAM component > then > this runs in a muxed-in channel with the control-word. Trying to be > even more accurate, what we have in the case of PWs (and only PWs, ie > does not apply to MPLS) is the emergence of a PID field occuring in > the > first nibble after the PW labelled header...and it is this field (when > it takes on the value 0001) that indicates 'PW OAM' > > So, to put this more succintly: MPLS OAM != PW OAM. Agreed. > If this is not clear, then consider the effect of misconnectivity > beween > a LSP carrying a PW and a 'normal' MPLS LSP. And to be super accurate > here, we should also note that the CI (Characteristic Information) of > the traffic unit in the 2 cases is not the same in other respects, eg > the 'normal' label of an MPLS LSP is a proxy for a destination address > (ie forwarding semantic) whilst the label of a PW LSP is a proxy for a > source adddress (ie a demerging semantic....necessary if LDP is being > used). > > T-MPLS OAM is something else all together. So we can extend to say: > MPLS OAM != PW OAM != T-MPLS OAM. I am not sure I follow your argument here. > Then there is the issue of PWs over T-MPLS....so what do we have here? > > Think some clarity is required in being precise as to *which* layer > network one is talking about when discussing the OAM. > > Hope you can understand the points I'm making here. Partially. *) --Tom > > > regards, Neil > >> -----Original Message----- >> From: owner-tsg13q5@itu.int [mailto:owner-tsg13q5@itu.int] On >> Behalf Of J. Rao Cherukuri >> Sent: 19 December 2007 16:52 >> To: stbryant@cisco.com; Huub van Helvoort >> Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 >> Subject: RE: progress of G.8113 and G.8114 >> >> >> Stewart, >> >> I agree with your proposed suggestion. This is inline with >> one of the Juniper AAP comment not yet resolved. >> >> Regards >> Rao Cherukuri >> >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Wednesday, December 19, 2007 10:55 AM >> To: Huub van Helvoort >> Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 >> Subject: Re: progress of G.8113 and G.8114 >> >> >> >> Huub >> >> The change that you propose is a fundamental change >> to the whole rational for designing an OAM specifically >> for T-MPLS rather than reusing an existing pseudowire >> OAM design. >> >> It has always been asserted by the T-MPLS designers >> that T-MPLS has special failure modes that did not >> apply to PWE3/MPLS and therefore existing OAM >> mechanisms such as RFC5085 (VCCV) were not appropriate. >> When challenged to specify these, none have been provided >> and now it is proposed to answer this long outstanding >> AAP issue by changing the language to indicate that >> there are no special T-MPLS failure modes. >> >> This change to the requirements demonstrates that >> the fundamental technical basis for rejecting the >> IETF OAM methods was flawed, and this decision therefore >> needs to be revisited. >> >> G.8113 and G.8114 should now be put on hold whilst the >> implications of this are properly evaluated. >> >> The least that you should do is to change the text >> of the requirement to >> >> "T-MPLS provides a connection-oriented layer network and >> hence there will be failure modes that are only relevant to >> the T-MPLS layer. Detection of these failure modes is >> possible through the use of RFC5085" >> >> and then to add RFC5085 as a candidate solution in G.8114 >> using the text that has already been provided. >> >> However designing a second OAM for pseudowire is not in the >> best interests of the operator community and it would be >> better to abandon this approach and to bring any additional >> requirements to the IETF for incorporation in VCCV. >> >> Stewart >> >> >> >> >> >> >> >> >> Huub van Helvoort wrote: >>> Hello Steward, >>> >>> Thank you for helping me. >>> >>> You wrote: >>> >>>>> Unfortunately there are still comments that are not resolved. Are >>>>> there any other proposals that will help to resolve the >> open issues >>>>> and get G.8113 and G.8114 approved. >>>> Just looking at the first unresolved comment, you could list the >>>> failure modes that apply to T-MPLS but not to MPLS as requested in >>>> the issue. >>>> >>>> Alternatively you could state that there are no failure modes that >>>> apply to T-MPLS that do not apply to one or more MPLS modes. >>> >>> Your comment made me read the original text very carefully, and I >>> found that the sentence: >>> >>> "T-MPLS provides a connection-oriented layer network and >> hence there >>> will be failure modes that are only relevant to T-MPLS." >>> >>> is the cause of your question. >>> It should have been: >>> "T-MPLS provides a connection-oriented layer network and >> hence there >>> will be failure modes that are only relevant to the T-MPLS layer." >>> >>> I will make this change to resolve this issue. >>> >>> Cheers, Huub. >>> >> >> > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 19 14:09:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54ID-0003Ub-Vy; Wed, 19 Dec 2007 14:09:21 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J54ID-0003UW-4K for pwe3-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:09:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54IC-0003UO-Qk for pwe3@ietf.org; Wed, 19 Dec 2007 14:09:20 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J54IA-00050c-Kn for pwe3@ietf.org; Wed, 19 Dec 2007 14:09:20 -0500 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 19:09:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] RE: progress of G.8113 and G.8114 Date: Wed, 19 Dec 2007 19:09:18 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C019E5E3F@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] RE: progress of G.8113 and G.8114 Thread-Index: AchCbiLxoc48K9BjTfqTU0UESWDYOgAAu++w From: To: X-OriginalArrivalTime: 19 Dec 2007 19:09:39.0305 (UTC) FILETIME=[B3F6A590:01C84272] X-Spam-Score: -1.0 (-) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: tsg13q5@itu.int, pwe3@ietf.org, cherukuri@juniper.net, t-mpls-dt@testbed.se, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thanks Tom...please see in-line: Thomas Nadeau wrote 19 December 2007 18:36 > On Dec 19, 2007, at 12:45 PM, wrote: >=20 > > Guys, > > > > Think we need to be a little more precise here. PWs may=20 > have started=20 > > life as some form of adaptation, primarily to deal with the=20 > fact that=20 > > MPLS does not treat all its clients the same (and some problems are=20 > > exposed when attempting to use ECMP techniques because of this), but > > PWs > > are now developing into a full blown layer network in their=20 > own right. > > More specifcally we cannot say that the functional=20 > components of MPLS > > are the same as those of PWs. And if we take the PW OAM component =20 > > then > > this runs in a muxed-in channel with the control-word. Trying to be > > even more accurate, what we have in the case of PWs (and=20 > only PWs, ie > > does not apply to MPLS) is the emergence of a PID field=20 > occuring in =20 > > the > > first nibble after the PW labelled header...and it is this=20 > field (when > > it takes on the value 0001) that indicates 'PW OAM' > > > > So, to put this more succintly: MPLS OAM !=3D PW OAM. >=20 > Agreed. >=20 > > If this is not clear, then consider the effect of misconnectivity > > beween > > a LSP carrying a PW and a 'normal' MPLS LSP. And to be=20 > super accurate > > here, we should also note that the CI (Characteristic=20 > Information) of > > the traffic unit in the 2 cases is not the same in other=20 > respects, eg > > the 'normal' label of an MPLS LSP is a proxy for a=20 > destination address > > (ie forwarding semantic) whilst the label of a PW LSP is a=20 > proxy for a > > source adddress (ie a demerging semantic....necessary if=20 > LDP is being > > used). > > > > T-MPLS OAM is something else all together. So we can=20 > extend to say:=20 > > MPLS OAM !=3D PW OAM !=3D T-MPLS OAM. >=20 > I am not sure I follow your argument here. NH=3D> All I am saying here is that, for whatever reason, the authors of T-MPLS decided to generate a new form of OAM that does not have its roots in MPLS nor PW. Indeed T-MPLS was predicated on what had gone before for Ethernet (in Y.1731)......which is clearly not the same as MPLS OAM or PW OAM. Moreover, the fact that Ethernet is cl-ps and T-MPLS is co-ps seems to be dismissed as a 'minor issue'.....but not in my mind it isn't. >=20 > > Then there is the issue of PWs over T-MPLS....so what do we=20 > have here? > > > > Think some clarity is required in being precise as to *which* layer=20 > > network one is talking about when discussing the OAM. > > > > Hope you can understand the points I'm making here. >=20 > Partially. *) >=20 > --Tom NH=3D> Hope the above explanation helps. The key points are this: - if one creates a layer network (any mode) it will have its own OAM; - several technologies can belong to the same network mode but they might not have the same OAM....or other func components for that matter....that is largely an issue of which body specified the technology (some are done better than others); technologies that do NOT belong to same network mode will have a mismatch in func components....just the way it is (physics)....so trying to force one component (eg OAM) to fit all modes is very silly. regards, Neil >=20 >=20 > > > > > > regards, Neil > > > >> -----Original Message----- > >> From: owner-tsg13q5@itu.int [mailto:owner-tsg13q5@itu.int]=20 > On Behalf=20 > >> Of J. Rao Cherukuri > >> Sent: 19 December 2007 16:52 > >> To: stbryant@cisco.com; Huub van Helvoort > >> Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 > >> Subject: RE: progress of G.8113 and G.8114 > >> > >> > >> Stewart, > >> > >> I agree with your proposed suggestion. This is inline with=20 > one of the=20 > >> Juniper AAP comment not yet resolved. > >> > >> Regards > >> Rao Cherukuri > >> > >> -----Original Message----- > >> From: Stewart Bryant [mailto:stbryant@cisco.com] > >> Sent: Wednesday, December 19, 2007 10:55 AM > >> To: Huub van Helvoort > >> Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 > >> Subject: Re: progress of G.8113 and G.8114 > >> > >> > >> > >> Huub > >> > >> The change that you propose is a fundamental change > >> to the whole rational for designing an OAM specifically > >> for T-MPLS rather than reusing an existing pseudowire > >> OAM design. > >> > >> It has always been asserted by the T-MPLS designers > >> that T-MPLS has special failure modes that did not > >> apply to PWE3/MPLS and therefore existing OAM > >> mechanisms such as RFC5085 (VCCV) were not appropriate. > >> When challenged to specify these, none have been provided=20 > and now it=20 > >> is proposed to answer this long outstanding AAP issue by=20 > changing the=20 > >> language to indicate that there are no special T-MPLS=20 > failure modes. > >> > >> This change to the requirements demonstrates that > >> the fundamental technical basis for rejecting the > >> IETF OAM methods was flawed, and this decision therefore=20 > needs to be=20 > >> revisited. > >> > >> G.8113 and G.8114 should now be put on hold whilst the=20 > implications=20 > >> of this are properly evaluated. > >> > >> The least that you should do is to change the text > >> of the requirement to > >> > >> "T-MPLS provides a connection-oriented layer network and=20 > hence there=20 > >> will be failure modes that are only relevant to the T-MPLS layer.=20 > >> Detection of these failure modes is possible through the use of=20 > >> RFC5085" > >> > >> and then to add RFC5085 as a candidate solution in G.8114=20 > using the=20 > >> text that has already been provided. > >> > >> However designing a second OAM for pseudowire is not in the best=20 > >> interests of the operator community and it would be better=20 > to abandon=20 > >> this approach and to bring any additional requirements to the IETF=20 > >> for incorporation in VCCV. > >> > >> Stewart > >> > >> > >> > >> > >> > >> > >> > >> > >> Huub van Helvoort wrote: > >>> Hello Steward, > >>> > >>> Thank you for helping me. > >>> > >>> You wrote: > >>> > >>>>> Unfortunately there are still comments that are not=20 > resolved. Are=20 > >>>>> there any other proposals that will help to resolve the > >> open issues > >>>>> and get G.8113 and G.8114 approved. > >>>> Just looking at the first unresolved comment, you could list the=20 > >>>> failure modes that apply to T-MPLS but not to MPLS as=20 > requested in=20 > >>>> the issue. > >>>> > >>>> Alternatively you could state that there are no failure=20 > modes that=20 > >>>> apply to T-MPLS that do not apply to one or more MPLS modes. > >>> > >>> Your comment made me read the original text very carefully, and I=20 > >>> found that the sentence: > >>> > >>> "T-MPLS provides a connection-oriented layer network and > >> hence there > >>> will be failure modes that are only relevant to T-MPLS." > >>> > >>> is the cause of your question. > >>> It should have been: > >>> "T-MPLS provides a connection-oriented layer network and > >> hence there > >>> will be failure modes that are only relevant to the T-MPLS layer." > >>> > >>> I will make this change to resolve this issue. > >>> > >>> Cheers, Huub. > >>> > >> > >> > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >=20 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 19 14:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54y8-00050w-LV; Wed, 19 Dec 2007 14:52:40 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J54y7-00050q-Ra for pwe3-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 14:52:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54y7-00050i-GX for pwe3@ietf.org; Wed, 19 Dec 2007 14:52:39 -0500 Received: from viefep25-int.chello.at ([62.179.121.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J54y6-0003Pm-Ji for pwe3@ietf.org; Wed, 19 Dec 2007 14:52:39 -0500 Received: from edge.upc.biz ([192.168.13.237]) by viefep25-int.chello.at (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20071219195236.JLLW24682.viefep25-int.chello.at@edge.upc.biz>; Wed, 19 Dec 2007 20:52:36 +0100 Received: from [192.168.17.2] ([80.56.44.70]) by edge.upc.biz with edge02 id SjsW1Y01F1WqUeg0100000; Wed, 19 Dec 2007 20:52:32 +0100 X-SourceIP: 80.56.44.70 Message-ID: <4769767F.8040102@chello.nl> Date: Wed, 19 Dec 2007 20:52:31 +0100 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: stbryant@cisco.com References: <4766ED8D.5040207@chello.nl> <47670240.5040809@cisco.com> <47670687.90206@chello.nl> <47693EDA.7050908@cisco.com> In-Reply-To: <47693EDA.7050908@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Q5/13 , t-mpls-dt@testbed.se, pwe3 Subject: [PWE3] Re: progress of G.8113 and G.8114 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Stewart, See my repondse to your reply in-line [hvh]: > The change that you propose is a fundamental change > to the whole rational for designing an OAM specifically > for T-MPLS rather than reusing an existing pseudowire > OAM design. [hvh] This is NOT a fundamental change, it is a clarification because I detected a mis-interpretation. T-MPLS is developed by SG15, SG15 uses layered network models, hence T-MPLS is one of the layer technologies they develop. And reference to T-MPLS implies the T-MPLS layer, to make sure that everybody understands that I made the correction. > It has always been asserted by the T-MPLS designers > that T-MPLS has special failure modes that did not > apply to PWE3/MPLS and therefore existing OAM > mechanisms such as RFC5085 (VCCV) were not appropriate. [hvh] Indeed. The failure modes of T-MPLS are related to the transport functionality and based on the experience with other transport technologies. > When challenged to specify these, none have been provided > and now it is proposed to answer this long outstanding > AAP issue by changing the language to indicate that > there are no special T-MPLS failure modes. [hvh] Then you are still mis-interpreting the sentence, It is stating that the failure modes are confined to the T-MPLS layer. (and this is a generic requirement for layered transport networks). What the failure modes are is out of scope for these recommendations, that is the responsability of the equipment specification G.8121. > This change to the requirements demonstrates that > the fundamental technical basis for rejecting the > IETF OAM methods was flawed, and this decision therefore > needs to be revisited. [hvh] Again, there is NO change, it is a correction to avoid mis-interpretation. (as is clear from your comment) > G.8113 and G.8114 should now be put on hold whilst the > implications of this are properly evaluated. [hvh] There are NO implications that need to be re-evaluated. > The least that you should do is to change the text > of the requirement to > > "T-MPLS provides a connection-oriented layer network and hence > there will be failure modes that are only relevant to > the T-MPLS layer. Detection of these failure modes is possible > through the use of RFC5085" [hvh] the addition of the last sentence restricts the requirement by providing a solution, solutions are out of scope for G.8113. > and then to add RFC5085 as a candidate solution in G.8114 using > the text that has already been provided. [hvh] this is a technical change beyond what can be addressed by AAP comments. > However designing a second OAM for pseudowire is not in the > best interests of the operator community and it would be better > to abandon this approach and to bring any additional > requirements to the IETF for incorporation in VCCV. [hvh] there was already a response from an operator confirming that the correction I propose is in line with transport technology. Reagrds, Huub. >================================= > Huub van Helvoort wrote: >> Hello Steward, >> >> Thank you for helping me. >> >> You wrote: >> >>>> Unfortunately there are still comments that are not resolved. >>>> Are there any other proposals that will help to resolve the >>>> open issues and get G.8113 and G.8114 approved. >>> Just looking at the first unresolved comment, you could list >>> the failure modes that apply to T-MPLS but not to MPLS >>> as requested in the issue. >>> >>> Alternatively you could state that there are no failure >>> modes that apply to T-MPLS that do not apply to >>> one or more MPLS modes. >> >> Your comment made me read the original text very carefully, and >> I found that the sentence: >> >> "T-MPLS provides a connection-oriented layer network and hence >> there will be failure modes that are only relevant to T-MPLS." >> >> is the cause of your question. >> It should have been: >> "T-MPLS provides a connection-oriented layer network and hence >> there will be failure modes that are only relevant to >> the T-MPLS layer." >> >> I will make this change to resolve this issue. >> >> Cheers, Huub. >> > > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 19 15:03:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J558l-0003Mr-3I; Wed, 19 Dec 2007 15:03:39 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J558j-0003Mj-Cb for pwe3-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 15:03:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J558j-0003Mb-2m for pwe3@ietf.org; Wed, 19 Dec 2007 15:03:37 -0500 Received: from static-72-71-250-34.cncdnh.fios.verizon.net ([72.71.250.34] helo=lucidvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J558h-00061E-Ft for pwe3@ietf.org; Wed, 19 Dec 2007 15:03:37 -0500 Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id D371975DA0; Wed, 19 Dec 2007 12:03:52 -0800 (PST) Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05993-05; Wed, 19 Dec 2007 12:03:51 -0800 (PST) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id A12CA75D8C; Wed, 19 Dec 2007 12:03:51 -0800 (PST) Message-Id: <6497D910-FA28-4F3B-9C12-B573D480C522@lucidvision.com> From: Thomas Nadeau To: In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C019E5E3F@E03MVB2-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [PWE3] RE: progress of G.8113 and G.8114 Date: Wed, 19 Dec 2007 15:03:33 -0500 References: <2ECAA42C79676B42AEBAC11229CA7D0C019E5E3F@E03MVB2-UKBR.domain1.systemhost.net> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: tsg13q5@itu.int, pwe3@ietf.org, cherukuri@juniper.net, t-mpls-dt@testbed.se, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Dec 19, 2007, at 2:09 PM, wrote: > Thanks Tom...please see in-line: > > Thomas Nadeau wrote 19 December 2007 18:36 >> On Dec 19, 2007, at 12:45 PM, wrote: >> >>> Guys, >>> >>> Think we need to be a little more precise here. PWs may >> have started >>> life as some form of adaptation, primarily to deal with the >> fact that >>> MPLS does not treat all its clients the same (and some problems are >>> exposed when attempting to use ECMP techniques because of this), but >>> PWs >>> are now developing into a full blown layer network in their >> own right. >>> More specifcally we cannot say that the functional >> components of MPLS >>> are the same as those of PWs. And if we take the PW OAM component >>> then >>> this runs in a muxed-in channel with the control-word. Trying to be >>> even more accurate, what we have in the case of PWs (and >> only PWs, ie >>> does not apply to MPLS) is the emergence of a PID field >> occuring in >>> the >>> first nibble after the PW labelled header...and it is this >> field (when >>> it takes on the value 0001) that indicates 'PW OAM' >>> >>> So, to put this more succintly: MPLS OAM != PW OAM. >> >> Agreed. >> >>> If this is not clear, then consider the effect of misconnectivity >>> beween >>> a LSP carrying a PW and a 'normal' MPLS LSP. And to be >> super accurate >>> here, we should also note that the CI (Characteristic >> Information) of >>> the traffic unit in the 2 cases is not the same in other >> respects, eg >>> the 'normal' label of an MPLS LSP is a proxy for a >> destination address >>> (ie forwarding semantic) whilst the label of a PW LSP is a >> proxy for a >>> source adddress (ie a demerging semantic....necessary if >> LDP is being >>> used). >>> >>> T-MPLS OAM is something else all together. So we can >> extend to say: >>> MPLS OAM != PW OAM != T-MPLS OAM. >> >> I am not sure I follow your argument here. > NH=> All I am saying here is that, for whatever reason, the authors of > T-MPLS decided to generate a new form of OAM that does not have its > roots in MPLS nor PW. True! > Indeed T-MPLS was predicated on what had gone > before for Ethernet (in Y.1731)......which is clearly not the same as > MPLS OAM or PW OAM. Moreover, the fact that Ethernet is cl-ps and > T-MPLS is co-ps seems to be dismissed as a 'minor issue'.....but not > in > my mind it isn't. OK. My confusion was in thinking that T-MPLS <= MPLS. If it is defined in this way, then the PW OAM + MPLS OAM will work just fine. BUT if T- MPLS > MPLS, then you are right, you get some strange variant. --Tom > >> >>> Then there is the issue of PWs over T-MPLS....so what do we >> have here? >>> >>> Think some clarity is required in being precise as to *which* layer >>> network one is talking about when discussing the OAM. >>> >>> Hope you can understand the points I'm making here. >> >> Partially. *) >> >> --Tom > NH=> Hope the above explanation helps. The key points are this: > - if one creates a layer network (any mode) it will have its own > OAM; > - several technologies can belong to the same network mode but > they might not have the same OAM....or other func components for that > matter....that is largely an issue of which body specified the > technology (some are done better than others); > technologies that do NOT belong to same network mode will have a > mismatch in func components....just the way it is (physics)....so > trying > to force one component (eg OAM) to fit all modes is very silly. > > regards, Neil >> >> >>> >>> >>> regards, Neil >>> >>>> -----Original Message----- >>>> From: owner-tsg13q5@itu.int [mailto:owner-tsg13q5@itu.int] >> On Behalf >>>> Of J. Rao Cherukuri >>>> Sent: 19 December 2007 16:52 >>>> To: stbryant@cisco.com; Huub van Helvoort >>>> Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 >>>> Subject: RE: progress of G.8113 and G.8114 >>>> >>>> >>>> Stewart, >>>> >>>> I agree with your proposed suggestion. This is inline with >> one of the >>>> Juniper AAP comment not yet resolved. >>>> >>>> Regards >>>> Rao Cherukuri >>>> >>>> -----Original Message----- >>>> From: Stewart Bryant [mailto:stbryant@cisco.com] >>>> Sent: Wednesday, December 19, 2007 10:55 AM >>>> To: Huub van Helvoort >>>> Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 >>>> Subject: Re: progress of G.8113 and G.8114 >>>> >>>> >>>> >>>> Huub >>>> >>>> The change that you propose is a fundamental change >>>> to the whole rational for designing an OAM specifically >>>> for T-MPLS rather than reusing an existing pseudowire >>>> OAM design. >>>> >>>> It has always been asserted by the T-MPLS designers >>>> that T-MPLS has special failure modes that did not >>>> apply to PWE3/MPLS and therefore existing OAM >>>> mechanisms such as RFC5085 (VCCV) were not appropriate. >>>> When challenged to specify these, none have been provided >> and now it >>>> is proposed to answer this long outstanding AAP issue by >> changing the >>>> language to indicate that there are no special T-MPLS >> failure modes. >>>> >>>> This change to the requirements demonstrates that >>>> the fundamental technical basis for rejecting the >>>> IETF OAM methods was flawed, and this decision therefore >> needs to be >>>> revisited. >>>> >>>> G.8113 and G.8114 should now be put on hold whilst the >> implications >>>> of this are properly evaluated. >>>> >>>> The least that you should do is to change the text >>>> of the requirement to >>>> >>>> "T-MPLS provides a connection-oriented layer network and >> hence there >>>> will be failure modes that are only relevant to the T-MPLS layer. >>>> Detection of these failure modes is possible through the use of >>>> RFC5085" >>>> >>>> and then to add RFC5085 as a candidate solution in G.8114 >> using the >>>> text that has already been provided. >>>> >>>> However designing a second OAM for pseudowire is not in the best >>>> interests of the operator community and it would be better >> to abandon >>>> this approach and to bring any additional requirements to the IETF >>>> for incorporation in VCCV. >>>> >>>> Stewart >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Huub van Helvoort wrote: >>>>> Hello Steward, >>>>> >>>>> Thank you for helping me. >>>>> >>>>> You wrote: >>>>> >>>>>>> Unfortunately there are still comments that are not >> resolved. Are >>>>>>> there any other proposals that will help to resolve the >>>> open issues >>>>>>> and get G.8113 and G.8114 approved. >>>>>> Just looking at the first unresolved comment, you could list the >>>>>> failure modes that apply to T-MPLS but not to MPLS as >> requested in >>>>>> the issue. >>>>>> >>>>>> Alternatively you could state that there are no failure >> modes that >>>>>> apply to T-MPLS that do not apply to one or more MPLS modes. >>>>> >>>>> Your comment made me read the original text very carefully, and I >>>>> found that the sentence: >>>>> >>>>> "T-MPLS provides a connection-oriented layer network and >>>> hence there >>>>> will be failure modes that are only relevant to T-MPLS." >>>>> >>>>> is the cause of your question. >>>>> It should have been: >>>>> "T-MPLS provides a connection-oriented layer network and >>>> hence there >>>>> will be failure modes that are only relevant to the T-MPLS layer." >>>>> >>>>> I will make this change to resolve this issue. >>>>> >>>>> Cheers, Huub. >>>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >> >> > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Dec 20 04:13:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5HTU-0001jD-NC; Thu, 20 Dec 2007 04:13:52 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5HTS-0001bo-Kt for pwe3-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 04:13:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5HTS-0001bg-6X for pwe3@ietf.org; Thu, 20 Dec 2007 04:13:50 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5HTQ-0004qQ-JM for pwe3@ietf.org; Thu, 20 Dec 2007 04:13:49 -0500 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 09:14:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] RE: progress of G.8113 and G.8114 Date: Thu, 20 Dec 2007 09:13:51 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C019E5F0C@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <6497D910-FA28-4F3B-9C12-B573D480C522@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] RE: progress of G.8113 and G.8114 Thread-Index: AchCekuRwOTlf3KRRiOdRbhA0nH2JgAZawIw From: To: X-OriginalArrivalTime: 20 Dec 2007 09:14:09.0649 (UTC) FILETIME=[ADD78E10:01C842E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: tsg13q5@itu.int, pwe3@ietf.org, cherukuri@juniper.net, t-mpls-dt@testbed.se, stbryant@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thanks Tom, Let me try and see if I can help a bit further here with this observation you made: > My confusion was in thinking that T-MPLS <=3D MPLS.=20 > If it is defined in this way, then the PW OAM + MPLS OAM will=20 > work just fine. BUT if T-=20 > MPLS > MPLS, > then you are right, you get some strange variant. If one understands what is becoming increasingly clear from the work on unified modelling, there is a deeper physics (with its roots in Information Theory) to the way in which networks are forced to be created......this is all about how one carves-up space, freq or time resource partitions and labels them (so that multiple users of the network resource can be distinguished and, where appropriate/required, allocated adequate resource). Indeed, this is precisely why we see the 3 network modes of cl-ps, co-ps and co-cs in the real world. One of the biggest mistakes we can make is to assume that one mode/technology can do-it-all. A related mistake is to assume that we can impose the same/identical set of functional components on all the modes. If I look to the IETF for example, they have been wrestling for many years now with the notion of forcing a common CP on networks (IP to Optics).....but it won't work (for many reasons, and not just technical ones). And in relation to this topic, some folks in ITU hold the mistaken view that we can have a common type of OAM component in all modes/technologies.....this too is just plain wrong. As a general observation the 3 network modes arise, and are different, for very good reasons (of physics)....so folks should stop trying to unify them, and instead seek ways of optimally specifying them so that their unique/different properties can be optimally exploited when the 3 modes work in concert. There is a better way...we have all just not seen it yet. So that is the general framework. Now let's consider the co-ps mode. *In principle* there is a best-of-breed solution here (in terms of DP traffic unit structure and selection of DP/CP/MP components). So far however, as an industry, we have not been able to create this beast. And the reason for this is that each co-ps technology (examples being X.25, FR, ATM, MPLS, T-MPLS, PBB-TE) has been designed by folks with a specific set of goals in mind.....they did not design these technologies with the principles of unified modelling in mind (though to be strictly accurate PBB-TE was conceived with these principles strongly in mind). So it is no surprise to find that the DP addressing, the traffic unit structure, the higher 'message/file/stream application to 1st layer adaptations' and OAM (and indeed all the CP and MP components) are all somewhat different for each of these co-ps mode technologies. And no one really baulks when we observe that they form different co-ps layer networks....we can intuitively see they are 'different' (and by design). Now in the case of MPLS and T-MPLS we can observe that they start with the same DP traffic unit. And so there is a tendency to jump to the conclusion that 'they should be the same, or at least as closely harmonised as possible'....but this does not follow. One can have a completely different set of functional components applied to T-MPLS from those applied to MPLS (DP, CP and MP). Is this a good thing? Well, it depends on whether you consider the functional components of MPLS or T-MPLS to be 'better'. If I am brutally honest here I would say that from an objective appraisal of each technology's components neither is very good...when compared to what the ideal co-ps mode should look like. Now I'm not going to provide such an analysis here...it is not appropriate. However, I think folks are currently talking past each other. Bottom-line: There is no need for T-MPLS to look the same as MPLS.....indeed, there is no such thing as 'MPLS singular'....and although different spins of MPLS may share the same DP traffic unit they do diverge quite significantly thereafter (in CP components, OAM, label semantics). =20 So it is wrong to claim that T-MPLS is subset of MPLS *if* there are conscious decisions being made to have quite different functional components and behaviours....here OAM is the component at issue, but as I've tried to show its a more complex issue that just this. They may start with the same DP traffic unit but thereafter one can diverge as much as one chooses. Hope that helped. regards, Neil > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 > Sent: 19 December 2007 20:04 > To: Harrison,N,Neil,DMN R > Cc: cherukuri@juniper.net; stbryant@cisco.com;=20 > hhelvoort@chello.nl; tsg13q5@itu.int; t-mpls-dt@testbed.se;=20 > pwe3@ietf.org > Subject: Re: [PWE3] RE: progress of G.8113 and G.8114 >=20 >=20 >=20 > On Dec 19, 2007, at 2:09 PM, wrote: >=20 > > Thanks Tom...please see in-line: > > > > Thomas Nadeau wrote 19 December 2007 18:36 > >> On Dec 19, 2007, at 12:45 PM, wrote: > >> > >>> Guys, > >>> > >>> Think we need to be a little more precise here. PWs may > >> have started > >>> life as some form of adaptation, primarily to deal with the > >> fact that > >>> MPLS does not treat all its clients the same (and some=20 > problems are=20 > >>> exposed when attempting to use ECMP techniques because of=20 > this), but=20 > >>> PWs are now developing into a full blown layer network in their > >> own right. > >>> More specifcally we cannot say that the functional > >> components of MPLS > >>> are the same as those of PWs. And if we take the PW OAM=20 > component=20 > >>> then this runs in a muxed-in channel with the=20 > control-word. Trying=20 > >>> to be even more accurate, what we have in the case of PWs (and > >> only PWs, ie > >>> does not apply to MPLS) is the emergence of a PID field > >> occuring in > >>> the > >>> first nibble after the PW labelled header...and it is this > >> field (when > >>> it takes on the value 0001) that indicates 'PW OAM' > >>> > >>> So, to put this more succintly: MPLS OAM !=3D PW OAM. > >> > >> Agreed. > >> > >>> If this is not clear, then consider the effect of misconnectivity=20 > >>> beween a LSP carrying a PW and a 'normal' MPLS LSP. And to be > >> super accurate > >>> here, we should also note that the CI (Characteristic > >> Information) of > >>> the traffic unit in the 2 cases is not the same in other > >> respects, eg > >>> the 'normal' label of an MPLS LSP is a proxy for a > >> destination address > >>> (ie forwarding semantic) whilst the label of a PW LSP is a > >> proxy for a > >>> source adddress (ie a demerging semantic....necessary if > >> LDP is being > >>> used). > >>> > >>> T-MPLS OAM is something else all together. So we can > >> extend to say: > >>> MPLS OAM !=3D PW OAM !=3D T-MPLS OAM. > >> > >> I am not sure I follow your argument here. > > NH=3D> All I am saying here is that, for whatever reason, the=20 > authors of=20 > > T-MPLS decided to generate a new form of OAM that does not have its=20 > > roots in MPLS nor PW. >=20 > True! >=20 > > Indeed T-MPLS was predicated on what had gone > > before for Ethernet (in Y.1731)......which is clearly not=20 > the same as=20 > > MPLS OAM or PW OAM. Moreover, the fact that Ethernet is cl-ps and=20 > > T-MPLS is co-ps seems to be dismissed as a 'minor issue'.....but not > > in > > my mind it isn't. >=20 > OK. My confusion was in thinking that T-MPLS <=3D MPLS.=20 > If it is defined in this way, then the PW OAM + MPLS OAM will=20 > work just fine. BUT if T-=20 > MPLS > MPLS, > then you are right, you get some strange variant. >=20 > --Tom >=20 >=20 > > > >> > >>> Then there is the issue of PWs over T-MPLS....so what do we > >> have here? > >>> > >>> Think some clarity is required in being precise as to=20 > *which* layer=20 > >>> network one is talking about when discussing the OAM. > >>> > >>> Hope you can understand the points I'm making here. > >> > >> Partially. *) > >> > >> --Tom > > NH=3D> Hope the above explanation helps. The key points are this: > > - if one creates a layer network (any mode) it will have its own > > OAM; > > - several technologies can belong to the same network mode but > > they might not have the same OAM....or other func=20 > components for that=20 > > matter....that is largely an issue of which body specified the=20 > > technology (some are done better than others); > > technologies that do NOT belong to same network mode=20 > will have a=20 > > mismatch in func components....just the way it is (physics)....so > > trying > > to force one component (eg OAM) to fit all modes is very silly. > > > > regards, Neil > >> > >> > >>> > >>> > >>> regards, Neil > >>> > >>>> -----Original Message----- > >>>> From: owner-tsg13q5@itu.int [mailto:owner-tsg13q5@itu.int] > >> On Behalf > >>>> Of J. Rao Cherukuri > >>>> Sent: 19 December 2007 16:52 > >>>> To: stbryant@cisco.com; Huub van Helvoort > >>>> Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 > >>>> Subject: RE: progress of G.8113 and G.8114 > >>>> > >>>> > >>>> Stewart, > >>>> > >>>> I agree with your proposed suggestion. This is inline with > >> one of the > >>>> Juniper AAP comment not yet resolved. > >>>> > >>>> Regards > >>>> Rao Cherukuri > >>>> > >>>> -----Original Message----- > >>>> From: Stewart Bryant [mailto:stbryant@cisco.com] > >>>> Sent: Wednesday, December 19, 2007 10:55 AM > >>>> To: Huub van Helvoort > >>>> Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 > >>>> Subject: Re: progress of G.8113 and G.8114 > >>>> > >>>> > >>>> > >>>> Huub > >>>> > >>>> The change that you propose is a fundamental change > >>>> to the whole rational for designing an OAM specifically=20 > for T-MPLS=20 > >>>> rather than reusing an existing pseudowire OAM design. > >>>> > >>>> It has always been asserted by the T-MPLS designers > >>>> that T-MPLS has special failure modes that did not > >>>> apply to PWE3/MPLS and therefore existing OAM > >>>> mechanisms such as RFC5085 (VCCV) were not appropriate. When=20 > >>>> challenged to specify these, none have been provided > >> and now it > >>>> is proposed to answer this long outstanding AAP issue by > >> changing the > >>>> language to indicate that there are no special T-MPLS > >> failure modes. > >>>> > >>>> This change to the requirements demonstrates that > >>>> the fundamental technical basis for rejecting the > >>>> IETF OAM methods was flawed, and this decision therefore > >> needs to be > >>>> revisited. > >>>> > >>>> G.8113 and G.8114 should now be put on hold whilst the > >> implications > >>>> of this are properly evaluated. > >>>> > >>>> The least that you should do is to change the text > >>>> of the requirement to > >>>> > >>>> "T-MPLS provides a connection-oriented layer network and > >> hence there > >>>> will be failure modes that are only relevant to the=20 > T-MPLS layer.=20 > >>>> Detection of these failure modes is possible through the use of=20 > >>>> RFC5085" > >>>> > >>>> and then to add RFC5085 as a candidate solution in G.8114 > >> using the > >>>> text that has already been provided. > >>>> > >>>> However designing a second OAM for pseudowire is not in the best=20 > >>>> interests of the operator community and it would be better > >> to abandon > >>>> this approach and to bring any additional requirements=20 > to the IETF=20 > >>>> for incorporation in VCCV. > >>>> > >>>> Stewart > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Huub van Helvoort wrote: > >>>>> Hello Steward, > >>>>> > >>>>> Thank you for helping me. > >>>>> > >>>>> You wrote: > >>>>> > >>>>>>> Unfortunately there are still comments that are not > >> resolved. Are > >>>>>>> there any other proposals that will help to resolve the > >>>> open issues > >>>>>>> and get G.8113 and G.8114 approved. > >>>>>> Just looking at the first unresolved comment, you=20 > could list the=20 > >>>>>> failure modes that apply to T-MPLS but not to MPLS as > >> requested in > >>>>>> the issue. > >>>>>> > >>>>>> Alternatively you could state that there are no failure > >> modes that > >>>>>> apply to T-MPLS that do not apply to one or more MPLS modes. > >>>>> > >>>>> Your comment made me read the original text very=20 > carefully, and I=20 > >>>>> found that the sentence: > >>>>> > >>>>> "T-MPLS provides a connection-oriented layer network and > >>>> hence there > >>>>> will be failure modes that are only relevant to T-MPLS." > >>>>> > >>>>> is the cause of your question. > >>>>> It should have been: > >>>>> "T-MPLS provides a connection-oriented layer network and > >>>> hence there > >>>>> will be failure modes that are only relevant to the=20 > T-MPLS layer." > >>>>> > >>>>> I will make this change to resolve this issue. > >>>>> > >>>>> Cheers, Huub. > >>>>> > >>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> pwe3 mailing list > >>> pwe3@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pwe3 > >>> > >> > >> > > >=20 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Dec 20 05:36:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5IlS-00021r-Nl; Thu, 20 Dec 2007 05:36:30 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5IlR-0001vV-9W for pwe3-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 05:36:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5IlQ-0001kB-90 for pwe3@ietf.org; Thu, 20 Dec 2007 05:36:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5IlP-00076l-7q for pwe3@ietf.org; Thu, 20 Dec 2007 05:36:28 -0500 X-IronPort-AV: E=Sophos;i="4.24,188,1196636400"; d="scan'208";a="1394085" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Dec 2007 11:36:17 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBKAaH34009239; Thu, 20 Dec 2007 11:36:17 +0100 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp777.cisco.com [10.61.67.9]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBKAaBqs021642; Thu, 20 Dec 2007 10:36:11 GMT Message-ID: <476A459D.8080009@cisco.com> Date: Thu, 20 Dec 2007 10:36:13 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Huub van Helvoort References: <4766ED8D.5040207@chello.nl> <47670240.5040809@cisco.com> <47670687.90206@chello.nl> <47693EDA.7050908@cisco.com> <4769767F.8040102@chello.nl> In-Reply-To: <4769767F.8040102@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6266; t=1198146977; x=1199010977; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20progress=20of=20G.8113=20and=20G.8114 |Sender:=20; bh=aaTU5IsegYfwG0xzHIqFTMR9veTOw0Cf1pFMuEmIoKE=; b=i4b4a9FdIJtcfpCt3paD+0GnuUfFklH7X7Uc7RPGYF+syKWfN78J1wf6Ao Fl+ysi4UVMm/NWiJHhRUxKnJKdDmxru/fJrAppBAyy9ptwSGcSNHvXKRY4oH QxXW2Ezc7a; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Q5/13 , t-mpls-dt@testbed.se, pwe3 Subject: [PWE3] Re: progress of G.8113 and G.8114 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Huub van Helvoort wrote: > Hi Stewart, > > See my repondse to your reply in-line [hvh]: > >> The change that you propose is a fundamental change >> to the whole rational for designing an OAM specifically >> for T-MPLS rather than reusing an existing pseudowire >> OAM design. > > [hvh] This is NOT a fundamental change, it is a clarification because I > detected a mis-interpretation. > T-MPLS is developed by SG15, SG15 uses layered network models, hence > T-MPLS is one of the layer technologies they develop. And reference > to T-MPLS implies the T-MPLS layer, to make sure that everybody > understands that I made the correction. SB>The original text said SB> SB>The major motivations for T-MPLS OAM are discussed further below. SB>1) T-MPLS provides a unique connection-oriented layer network and hence SB>there will be failure modes that are only relevant to T-MPLS SB> SB>Are there failure modes that apply to T-MPLS but do not apply SB>to PWE3/MPLS? > >> It has always been asserted by the T-MPLS designers >> that T-MPLS has special failure modes that did not >> apply to PWE3/MPLS and therefore existing OAM >> mechanisms such as RFC5085 (VCCV) were not appropriate. > > [hvh] Indeed. The failure modes of T-MPLS are related to the transport > functionality and based on the experience with other transport > technologies. SB> Either T-MPLS is a subset (i.e. profile ) of PWE3/MPLS or it is not. SB> If it is, then the failure modes ought to be the failure modes that SB> you get in PWE3 over connection oriented MPLS. If there are SB> other failure modes then please list them. If you are unable to SB> list them, then we have to conclude that there are none. SB> SB> On the other hand you may assert that T-MPLS is not a subset of SB> PWE3/MPLS. In which case you have two choices: SB> Bring the requirements to the IETF and use the MPLS change SB> process to enhance PWE3/MPLS, or take Option2. SB> > >> When challenged to specify these, none have been provided >> and now it is proposed to answer this long outstanding >> AAP issue by changing the language to indicate that >> there are no special T-MPLS failure modes. > > [hvh] Then you are still mis-interpreting the sentence, It is stating > that the failure modes are confined to the T-MPLS layer. > (and this is a generic requirement for layered transport networks). > > What the failure modes are is out of scope for these recommendations, > that is the responsability of the equipment specification G.8121. > SB> This is supposed to be the requirements document. How can SB> the failure modes be out of scope? SB> If they are in G.8121, then please provide the section SB> references and add them to G.8113. >> This change to the requirements demonstrates that >> the fundamental technical basis for rejecting the >> IETF OAM methods was flawed, and this decision therefore >> needs to be revisited. > > [hvh] Again, there is NO change, it is a correction to avoid > mis-interpretation. (as is clear from your comment) SB> I disagree. > >> G.8113 and G.8114 should now be put on hold whilst the >> implications of this are properly evaluated. > > [hvh] There are NO implications that need to be re-evaluated. > SB> Again I disagree >> The least that you should do is to change the text >> of the requirement to >> >> "T-MPLS provides a connection-oriented layer network and hence >> there will be failure modes that are only relevant to >> the T-MPLS layer. Detection of these failure modes is possible >> through the use of RFC5085" > > [hvh] the addition of the last sentence restricts the requirement by > providing a solution, solutions are out of scope for G.8113. SB> The scope of G.8113 is the surely the OAM requirements SB> for a profile of PWE3/MPLS. How can the use of IETF SB> OAMs be out of scope? SB> SB> The only way that they can be out of scope is either: SB> SB> a) If the scope of G.8113 is to create an OAM that is different SB> from the IETF OAMs, or SB> SB> b) T-MPLS is not a profile of PWE3/MPLS. > >> and then to add RFC5085 as a candidate solution in G.8114 using >> the text that has already been provided. > > [hvh] this is a technical change beyond what can be addressed by > AAP comments. SB> In which case the document should be pulled out of AAP and SB> corrected. > > >> However designing a second OAM for pseudowire is not in the >> best interests of the operator community and it would be better >> to abandon this approach and to bring any additional >> requirements to the IETF for incorporation in VCCV. > > [hvh] there was already a response from an operator confirming that the > correction I propose is in line with transport technology. SB> Firstly one responder is not consensus, and so cannot be used SB> to claim closure of the issue. SB> SB> Secondly I believe that same operator suggested that T-MPLS != MPLS SB> in which case, if you follow that line, you are into option 2. Stewart > > Reagrds, Huub. > >> ================================= Huub van Helvoort wrote: >>> Hello Steward, >>> >>> Thank you for helping me. >>> >>> You wrote: >>> >>>>> Unfortunately there are still comments that are not resolved. >>>>> Are there any other proposals that will help to resolve the >>>>> open issues and get G.8113 and G.8114 approved. >>>> Just looking at the first unresolved comment, you could list >>>> the failure modes that apply to T-MPLS but not to MPLS >>>> as requested in the issue. >>>> >>>> Alternatively you could state that there are no failure >>>> modes that apply to T-MPLS that do not apply to >>>> one or more MPLS modes. >>> >>> Your comment made me read the original text very carefully, and >>> I found that the sentence: >>> >>> "T-MPLS provides a connection-oriented layer network and hence >>> there will be failure modes that are only relevant to T-MPLS." >>> >>> is the cause of your question. >>> It should have been: >>> "T-MPLS provides a connection-oriented layer network and hence >>> there will be failure modes that are only relevant to >>> the T-MPLS layer." >>> >>> I will make this change to resolve this issue. >>> >>> Cheers, Huub. >>> >> >> > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Dec 20 08:08:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5L8b-0005lT-Tv; Thu, 20 Dec 2007 08:08:33 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J52Io-0008R2-Se for pwe3-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 12:01:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52Io-0008Qt-Hc for pwe3@ietf.org; Wed, 19 Dec 2007 12:01:50 -0500 Received: from exprod7og106.obsmtp.com ([64.18.2.165] helo=psmtp.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J52In-0007JC-Tb for pwe3@ietf.org; Wed, 19 Dec 2007 12:01:50 -0500 Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Dec 2007 09:00:38 PST Received: from emailcorp2.jnpr.net ([66.129.254.12]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:00:51 -0800 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:00:30 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Dec 2007 08:52:10 -0800 Message-ID: <7281A4AFD0208245879A42E99F5340F2C79CAD@emailcorp3.jnpr.net> In-Reply-To: <47693EDA.7050908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: progress of G.8113 and G.8114 Thread-Index: AchCV42SKMIppQeHQoGmQ6XC0YdhvwAB3Vwg From: "J. Rao Cherukuri" To: , "Huub van Helvoort" X-OriginalArrivalTime: 19 Dec 2007 17:00:30.0529 (UTC) FILETIME=[A9554310:01C84260] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 X-Mailman-Approved-At: Thu, 20 Dec 2007 08:08:33 -0500 Cc: Q5/13 , t-mpls-dt@testbed.se, pwe3 Subject: [PWE3] RE: progress of G.8113 and G.8114 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, I agree with your proposed suggestion. This is inline with one of the Juniper AAP comment not yet resolved. Regards Rao Cherukuri=20 -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Wednesday, December 19, 2007 10:55 AM To: Huub van Helvoort Cc: Q5/13; t-mpls-dt@testbed.se; pwe3 Subject: Re: progress of G.8113 and G.8114 Huub The change that you propose is a fundamental change to the whole rational for designing an OAM specifically for T-MPLS rather than reusing an existing pseudowire OAM design. It has always been asserted by the T-MPLS designers that T-MPLS has special failure modes that did not apply to PWE3/MPLS and therefore existing OAM mechanisms such as RFC5085 (VCCV) were not appropriate. When challenged to specify these, none have been provided and now it is proposed to answer this long outstanding AAP issue by changing the language to indicate that there are no special T-MPLS failure modes. This change to the requirements demonstrates that the fundamental technical basis for rejecting the IETF OAM methods was flawed, and this decision therefore needs to be revisited. G.8113 and G.8114 should now be put on hold whilst the implications of this are properly evaluated. The least that you should do is to change the text of the requirement to "T-MPLS provides a connection-oriented layer network and hence there will be failure modes that are only relevant to the T-MPLS layer. Detection of these failure modes is possible through the use of RFC5085" and then to add RFC5085 as a candidate solution in G.8114 using the text that has already been provided. However designing a second OAM for pseudowire is not in the best interests of the operator community and it would be better to abandon this approach and to bring any additional requirements to the IETF for incorporation in VCCV. Stewart Huub van Helvoort wrote: > Hello Steward, > > Thank you for helping me. > > You wrote: > >>> Unfortunately there are still comments that are not resolved. >>> Are there any other proposals that will help to resolve the >>> open issues and get G.8113 and G.8114 approved.=20 >> Just looking at the first unresolved comment, you could list >> the failure modes that apply to T-MPLS but not to MPLS >> as requested in the issue. >> >> Alternatively you could state that there are no failure >> modes that apply to T-MPLS that do not apply to >> one or more MPLS modes. > > Your comment made me read the original text very carefully, and > I found that the sentence: > > "T-MPLS provides a connection-oriented layer network and hence > there will be failure modes that are only relevant to T-MPLS." > > is the cause of your question. > It should have been: > "T-MPLS provides a connection-oriented layer network and hence > there will be failure modes that are only relevant to > the T-MPLS layer." > > I will make this change to resolve this issue. > > Cheers, Huub. > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Dec 20 11:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5OE9-0008Ud-8o; Thu, 20 Dec 2007 11:26:29 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5OE7-0008Tg-Vm for pwe3-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 11:26:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5OE7-0008Ri-JF for pwe3@ietf.org; Thu, 20 Dec 2007 11:26:27 -0500 Received: from viefep18-int.chello.at ([213.46.255.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5OE6-0001TL-EP for pwe3@ietf.org; Thu, 20 Dec 2007 11:26:27 -0500 Received: from edge.upc.biz ([192.168.13.239]) by viefep18-int.chello.at (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20071220162624.EYH1072.viefep18-int.chello.at@edge.upc.biz>; Thu, 20 Dec 2007 17:26:24 +0100 Received: from [192.168.17.2] ([80.56.44.70]) by edge.upc.biz with edge04 id T4Rx1Y01Y1WqUeg0100000; Thu, 20 Dec 2007 17:25:59 +0100 X-SourceIP: 80.56.44.70 Message-ID: <476A97AB.2090902@chello.nl> Date: Thu, 20 Dec 2007 17:26:19 +0100 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: stbryant@cisco.com References: <4766ED8D.5040207@chello.nl> <47670240.5040809@cisco.com> <47670687.90206@chello.nl> <47693EDA.7050908@cisco.com> <4769767F.8040102@chello.nl> <476A459D.8080009@cisco.com> In-Reply-To: <476A459D.8080009@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Q5/13 , t-mpls-dt@testbed.se, pwe3 Subject: [PWE3] Re: progress of G.8113 and G.8114 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hello Stewart, You replied: >>> The change that you propose is a fundamental change >>> to the whole rational for designing an OAM specifically >>> for T-MPLS rather than reusing an existing pseudowire >>> OAM design. >> >> [hvh] This is NOT a fundamental change, it is a clarification because I >> detected a mis-interpretation. >> T-MPLS is developed by SG15, SG15 uses layered network models, hence >> T-MPLS is one of the layer technologies they develop. And reference >> to T-MPLS implies the T-MPLS layer, to make sure that everybody >> understands that I made the correction. > SB>The original text said > SB> > SB>The major motivations for T-MPLS OAM are discussed further below. > SB>1) T-MPLS provides a unique connection-oriented layer network and hence > SB>there will be failure modes that are only relevant to T-MPLS > SB> > SB>Are there failure modes that apply to T-MPLS but do not apply > SB>to PWE3/MPLS? [hvh2] the word "unique" was removed and agreed by LC2-1 a). The last word "T-MPLS" has to be replaced by "the T-MPLS layer" because it causes confusion. It is a generic transport network requirement that failuire modes applicable to a certain layer shall be confined to that particular layer. Different layers can have the same, or totally different, or partially different, or partially equivalent failure modes. >>> It has always been asserted by the T-MPLS designers >>> that T-MPLS has special failure modes that did not >>> apply to PWE3/MPLS and therefore existing OAM >>> mechanisms such as RFC5085 (VCCV) were not appropriate. >> >> [hvh] Indeed. The failure modes of T-MPLS are related to the transport >> functionality and based on the experience with other transport >> technologies. > SB> Either T-MPLS is a subset (i.e. profile ) of PWE3/MPLS or it is not. > SB> If it is, then the failure modes ought to be the failure modes that > SB> you get in PWE3 over connection oriented MPLS. If there are > SB> other failure modes then please list them. If you are unable to > SB> list them, then we have to conclude that there are none. > SB> > SB> On the other hand you may assert that T-MPLS is not a subset of > SB> PWE3/MPLS. In which case you have two choices: > SB> Bring the requirements to the IETF and use the MPLS change > SB> process to enhance PWE3/MPLS, or take Option2. [hvh2} The following is extracted from the Q5/13 meeting report (SG13 plenary meeting April 2007): "The Q5/13 experts spent a significant amount of time considering the IETF specified MPLS OAM for inclusion and concluded that thes cannot be used in the way they are currently defined. Understanding and, if necessary, adapting the current IETF definitions to match the Y.17tom OAM functions described in clauses 7, 8 and 9 will require close cooperation with IETF. Q5/13 is willing to work together with the IETF experts to resolve the issues. Input by contribution for the next meeting is invited." This text was reviewed and accepted without objection. >>> When challenged to specify these, none have been provided >>> and now it is proposed to answer this long outstanding >>> AAP issue by changing the language to indicate that >>> there are no special T-MPLS failure modes. >> >> [hvh] Then you are still mis-interpreting the sentence, It is stating >> that the failure modes are confined to the T-MPLS layer. >> (and this is a generic requirement for layered transport networks). >> >> What the failure modes are is out of scope for these recommendations, >> that is the responsability of the equipment specification G.8121. > > SB> This is supposed to be the requirements document. How can > SB> the failure modes be out of scope? > SB> If they are in G.8121, then please provide the section > SB> references and add them to G.8113. [hvh2] the OAM requiremnts are intended to be used to develop OAM mechanisms. The equipemt specification wil refer to the OAM mechnisms that are used by specific (adaptation/termination/connection) functions. Both G.8113 and G.8114 were liaised to Q9/15 for commnets. The reponse liaison (TD 196 wp4/13) states that G.8114 contains a comprehensive set of T-MPLS OAM PDUs. There were no objections in the SG15 meeting to send this liaison. >>> This change to the requirements demonstrates that >>> the fundamental technical basis for rejecting the >>> IETF OAM methods was flawed, and this decision therefore >>> needs to be revisited. >> >> [hvh] Again, there is NO change, it is a correction to avoid >> mis-interpretation. (as is clear from your comment) > SB> I disagree. [hvh2] this change is to improve the quality, this is not a technological change. >>> G.8113 and G.8114 should now be put on hold whilst the >>> implications of this are properly evaluated. >> >> [hvh] There are NO implications that need to be re-evaluated. >> > SB> Again I disagree >>> The least that you should do is to change the text >>> of the requirement to >>> >>> "T-MPLS provides a connection-oriented layer network and hence >>> there will be failure modes that are only relevant to >>> the T-MPLS layer. Detection of these failure modes is possible >>> through the use of RFC5085" >> >> [hvh] the addition of the last sentence restricts the requirement by >> providing a solution, solutions are out of scope for G.8113. > SB> The scope of G.8113 is the surely the OAM requirements > SB> for a profile of PWE3/MPLS. How can the use of IETF > SB> OAMs be out of scope? > SB> > SB> The only way that they can be out of scope is either: > SB> > SB> a) If the scope of G.8113 is to create an OAM that is different > SB> from the IETF OAMs, or > SB> > SB> b) T-MPLS is not a profile of PWE3/MPLS. [hvh2] during the evaluation (as mentioned above) they do not comply with the generic transport requirement that they should be confined to a single layer. >>> and then to add RFC5085 as a candidate solution in G.8114 using >>> the text that has already been provided. >> >> [hvh] this is a technical change beyond what can be addressed by >> AAP comments. > SB> In which case the document should be pulled out of AAP and > SB> corrected. [hvh2] what you propose is not a correction, it is an addition. additions can be made after a recommendation has been approved. >>> However designing a second OAM for pseudowire is not in the >>> best interests of the operator community and it would be better >>> to abandon this approach and to bring any additional >>> requirements to the IETF for incorporation in VCCV. >> >> [hvh] there was already a response from an operator confirming that the >> correction I propose is in line with transport technology. > SB> Firstly one responder is not consensus, and so cannot be used > SB> to claim closure of the issue. > SB> > SB> Secondly I believe that same operator suggested that T-MPLS != MPLS > SB> in which case, if you follow that line, you are into option 2. [hvh2] I read someting else: "Think we need to be a little more precise here" "MPLS OAM != PW OAM != T-MPLS OAM" "Think some clarity is required in being precise as to *which* layer network one is talking about when discussing the OAM The suggestion is: The OAMs are not equal because they are confined to their own layer. Regards, Huub. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Dec 21 08:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5hqJ-0001bJ-Da; Fri, 21 Dec 2007 08:23:11 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5hqI-0001bE-9A for pwe3-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 08:23:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5hqH-0001b6-Vi for pwe3@ietf.org; Fri, 21 Dec 2007 08:23:09 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5hqH-0007S5-FK for pwe3@ietf.org; Fri, 21 Dec 2007 08:23:09 -0500 X-IronPort-AV: E=Sophos;i="4.24,194,1196636400"; d="scan'208";a="1525082" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Dec 2007 14:23:09 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBLDN8nI004040; Fri, 21 Dec 2007 14:23:08 +0100 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp536.cisco.com [10.61.66.24]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBLDN54j014503; Fri, 21 Dec 2007 13:23:05 GMT Message-ID: <476BBE3C.2070907@cisco.com> Date: Fri, 21 Dec 2007 13:23:08 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1852; t=1198243388; x=1199107388; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20FW=3A=20liaison=20text |Sender:=20; bh=Jvhx3pA/TmV8h6P/b+jKD2+2Qhn0V2PPCXbtKBOwFf8=; b=McNrAaxo2iY7TWwyLXHcJJpmbA9zIckGCEu9D/gLeiet11ACb7LMFfsedj XYUNg847DPHzdS2GjADsfedQP0YhCX7fsD1ITrK1UGgmXVLaw3NMxYQN4QeP lWVTRRqh+H; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Mark Townsley , t-mpls-dt@testbed.se, Yaakov Stein , Danny McPherson Subject: [PWE3] FW: liaison text X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org We have an outstanding action to respond to SG13 on this liaison: Use of term "pseudowire" and definition of stitching function https://datatracker.ietf.org/liaison/329/ We need to get this to the ITU by their meeting that starts on the 14th January. I have been working with Yaakov Stein, who is on the receiving end of this liaison, and we propose the following text: Please can you provide comments by 7th January. Thanks Stewart ===== We would like to thank you for the information on your draft new Recommendation. We agree that what you call a Generic Adaptation Layer (GAL) is either a single segment PW, or a multisegment PW. We would appreciate your using the term "pseudowire" (PW), and believe that standardizing terminology is best for the industry. In addition, although the focus of this document is the multisegment case, we advise adding (for reference) figures prior to Figures 6-1 and 6-2 depicting the single segment case. Furthermore, we feel it would be useful to specifically state that the subnetwork connection inside the S-IWF can potentially modify the PW label. Although this is implicit in the switching capability at the PW layer, this is the new feature of the MS-PW. Regarding your question about the use of a single S-PE or a pair of S-PEs connected by a simple link, we feel that both cases are possible. In the MS-PW architecture draft (draft-ietf-pwe3-ms-pw-arch-03.txt) we differentiate between the intra-provider and inter-provider cases. The inter-provider reference model of figure 5 of this draft maps to your Figure 6-3 when "PW segment 2" is a link. On the other hand, for the intra-provider case, or when two providers have a relationship of trust, the single S-PE case is feasible. ===== _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Dec 21 10:19:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5jdx-0000ja-Ly; Fri, 21 Dec 2007 10:18:33 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5jdv-0000hO-Pm for pwe3-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 10:18:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5jdv-0000gu-EE; Fri, 21 Dec 2007 10:18:31 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J5jdq-00012t-2p; Fri, 21 Dec 2007 10:18:30 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2f476c1bca; Fri, 21 Dec 2007 23:31:39 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm23476713d7; Tue, 18 Dec 2007 05:31:21 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 18 Dec 2007 05:31:20 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MMj-0004Cs-FJ; Mon, 17 Dec 2007 15:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MMg-00046b-8M; Mon, 17 Dec 2007 15:15:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4MMf-0007WL-Rq; Mon, 17 Dec 2007 15:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A39CA26E65; Mon, 17 Dec 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4MMf-0007m9-IZ; Mon, 17 Dec 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 17 Dec 2007 15:15:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 4.9 (++++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-ms-pw-requirements-06.txt X-BeenThere: pwe3@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) Author(s) : M. Bocci, L. Martini Filename : draft-ietf-pwe3-ms-pw-requirements-06.txt Pages : 28 Date : 2007-12-17 This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-ms-pw-requirements-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-ms-pw-requirements-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-17145010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-ms-pw-requirements-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-ms-pw-requirements-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-17145010.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Fri Dec 21 11:16:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kWy-0008QA-T2; Fri, 21 Dec 2007 11:15:24 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5kWe-0007YF-5d for pwe3-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 11:15:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kWd-0007VW-Ea; Fri, 21 Dec 2007 11:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5kWc-0001wq-D0; Fri, 21 Dec 2007 11:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 37D0126E63; Fri, 21 Dec 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J5kWc-0002ff-0s; Fri, 21 Dec 2007 11:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Dec 2007 11:15:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-tdm-mib-09.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Managed Objects for TDM over Packet Switched Network (PSN) Author(s) : O. Nicklass Filename : draft-ietf-pwe3-tdm-mib-09.txt Pages : 42 Date : 2007-12-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-mib-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-tdm-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-tdm-mib-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-21104512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-tdm-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-tdm-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-21104512.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Fri Dec 21 14:28:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5nWy-00061T-SH; Fri, 21 Dec 2007 14:27:36 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5nWw-0005qt-Mj for pwe3-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 14:27:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5nWw-0005oi-AV for pwe3@ietf.org; Fri, 21 Dec 2007 14:27:34 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5nWv-0002Vs-OR for pwe3@ietf.org; Fri, 21 Dec 2007 14:27:34 -0500 X-IronPort-AV: E=Sophos;i="4.24,196,1196636400"; d="scan'208";a="1558956" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Dec 2007 20:27:25 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBLJROV7000987; Fri, 21 Dec 2007 20:27:24 +0100 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp536.cisco.com [10.61.66.24]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBLJRI4j016196; Fri, 21 Dec 2007 19:27:24 GMT Message-ID: <476C139A.6090400@cisco.com> Date: Fri, 21 Dec 2007 19:27:22 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pwe3 , Danny McPherson Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3366; t=1198265244; x=1199129244; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20SG15Q12=20liaison=20on=20MS-PW=20requirements=2 0-=20second=20attempt |Sender:=20; bh=WaUjQf99r3NypfNMpBfCt693z2hGnhgQN3bcE/kbChA=; b=Z0hxEJLQBE41tMKzg/tmaYX6ruh6O2ziuqy0gnJKKTf2S6c5SGyYLrl9F2 DnWgWAmfsOIj7pI212NDeBXqgqCWb3XdvVijYFoPUAL8kficWt6x0n4DjXQQ Un2/mfVrAM; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Mark Townsley , t-mpls-dt@testbed.se Subject: [PWE3] SG15Q12 liaison on MS-PW requirements - second attempt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Here is a second attempt at the response to this liaison. The response was due on tuesday, but we are clearly not going to achieve that. I propose to send this formally to SG15 on 11th January. The reason that SG15 requested a response by Christmas was a contribution deadline for the Geneva meeting in February, so I propose to address that by posting a pointer to this thread to their mailing list. Please review and I will incorporate comments. Thanks Stewart ============================================================ That you for your liaison of 14 September 2007 entitled "Liaison Statement to IETF PWE3 WG on MS-PW over T-MPLS " https://datatracker.ietf.org/liaison/372/ We apologizes for the late response, but as you are aware members or PWE3 have had a considerable number of other TMPLS related tasks to work on. The review of this document was particularly difficult because it was not expressed in terms of the language that we use to define pseudowires, and we request that the proposed design be restated in the same language and notation that is used in RFC3985 and so that members of the IETF PWE3 WG can fully understand the proposal. The T-MPLS segment that you propose in Figure 1 must be indistinguishable from an IETF MS-PW segment, and we would appreciate it if you could confirm that this is the case. We would draw your attention to ongoing work on multisegment pseudowire signaling draft-ietf-pwe3-dynamic-ms-pw , and draft-ietf-pwe3-segmented-pw . We are concerned that peering arrangement that you propose will require interworking of the PWE3 and T-MPLS signaling with associated complexities. We do not understand why in Figure 2 you use a TMC/PW rather than an MPLS/PW. Members of the IETF PWE3 have expressed difficulty in understanding the paragraph: "Inside the T-MPLS network there is a 1:1 relationship between the MPLS MS-PW and the T-MPLS Channel trail; therefore the TMC/PW_A function is not required to insert a PW label. The reason is that the functionality of multiplexing (for vertical scalability reasons) multiple pseudo-wires over a single trunk is performed at the TMP level (by multiplexing multiple TMCs over a TMP)." and the continuing text to the end of the section. Please could you indicate the label stack at each stage of the packet transit and indicate the purpose of each label, it's purpose and how it is allocated. Given that the OAM in the PWE3 segments will need to be based on RFC5085 (VCCV) we are confused as to why you do not work with on the extension of VCCV to support multi-segment PWs and thus allow a single OWN to be used in this configuration rather than undertaking the more complex task of interworking the two OAMs. This problem is clearly within the remit of the proposed joint working team, and should be referred to them. Any modifications to MPLS technology needed are of course the subject of RFC4929. Regards etc PWE3 co-chairs _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Dec 21 14:51:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5nta-0004pD-0b; Fri, 21 Dec 2007 14:50:58 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5ntY-0004oa-Ej for pwe3-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 14:50:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ntY-0004oS-4q for pwe3@ietf.org; Fri, 21 Dec 2007 14:50:56 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5ntW-0007km-8m for pwe3@ietf.org; Fri, 21 Dec 2007 14:50:56 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lBLJmgb5020084; Fri, 21 Dec 2007 20:48:42 +0100 Received: from itvimn0i34082 ([151.98.70.19]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Dec 2007 20:50:26 +0100 From: "Italo Busi" To: , "'pwe3'" , "'Danny McPherson'" References: <476C139A.6090400@cisco.com> Subject: RE: [PWE3] SG15Q12 liaison on MS-PW requirements - second attempt Date: Fri, 21 Dec 2007 20:50:50 +0100 Message-ID: <028801c8440a$ca02c500$13466297@vim.tlt.alcatel.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <476C139A.6090400@cisco.com> Thread-Index: AchEB5xughou5GYSTz+KsGXPqSLjdAAAjGpQ X-OriginalArrivalTime: 21 Dec 2007 19:50:26.0272 (UTC) FILETIME=[BB4BAE00:01C8440A] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: 'Mark Townsley' , t-mpls-dt@testbed.se X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, It seems a good starting point for the LS reply. I have the following comments: 1) Add the reference the MS-PW Requirements draft and explicitly asks for an identification of any additional requirements to cover this application 2) Remove the sentence: " Given that the OAM in the PWE3 segments will need to be based on RFC5085 (VCCV) we are confused as to why you do not work with on the extension of VCCV to support multi-segment PWs and thus allow a single OWN to be used in this configuration rather than undertaking the more complex task of interworking the two OAMs. " It does not add/remove any argument to the current thread on Y.1373/G.8114 and it is technically incorrect because the LS is not identifying any complex interworking between the two OAM toolsets. Thanks, Italo > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, December 21, 2007 8:27 PM > To: pwe3; Danny McPherson > Cc: Mark Townsley; t-mpls-dt@testbed.se > Subject: [PWE3] SG15Q12 liaison on MS-PW requirements - second attempt > > Here is a second attempt at the response to this > liaison. > > The response was due on tuesday, but we are > clearly not going to achieve that. I propose > to send this formally to SG15 on 11th January. > The reason that SG15 requested a response by > Christmas was a contribution deadline for > the Geneva meeting in February, so I propose > to address that by posting a pointer to > this thread to their mailing list. > > Please review and I will incorporate comments. > > Thanks > > Stewart > > ============================================================ > > That you for your liaison of 14 September 2007 > entitled "Liaison Statement to IETF PWE3 WG on > > MS-PW over T-MPLS > " > > > https://datatracker.ietf.org/liaison/372/ > > We apologizes for the late response, but as you are aware members > or PWE3 have had a considerable number of other TMPLS related > tasks to work on. > > The review of this document was particularly difficult because it was > not expressed in terms of the language that we use to define > pseudowires, and we request that the proposed design be restated > in the same language and notation that is used in RFC3985 and > so that members of the IETF > > PWE3 WG can fully understand the proposal. > > The T-MPLS segment that you propose in Figure 1 must > be indistinguishable from an IETF MS-PW segment, and we > would appreciate it if you could confirm that this is the case. > > We would draw your attention to ongoing work on > multisegment pseudowire signaling draft-ietf-pwe3-dynamic-ms-pw > , and > draft-ietf-pwe3-segmented-pw > . We are > concerned that peering > arrangement that you propose will require interworking of the > PWE3 and T-MPLS signaling with associated complexities. > > We do not understand why in Figure 2 you use a TMC/PW rather > than an MPLS/PW. > > Members of the IETF PWE3 have expressed difficulty in > understanding the paragraph: > > "Inside the T-MPLS network there is a 1:1 > relationship between the MPLS MS-PW and the > T-MPLS Channel trail; therefore the TMC/PW_A > function is not required to insert a PW label. > The reason is that the functionality of multiplexing > (for vertical scalability reasons) multiple pseudo-wires > over a single trunk is performed at the TMP level > (by multiplexing multiple TMCs over a TMP)." > > and the continuing text to the end of the section. > > Please could you indicate the label stack at > each stage of the packet transit and indicate > the purpose of each label, it's purpose > and how it is allocated. > > Given that the OAM in the PWE3 segments will need to > be based on RFC5085 (VCCV) we are confused as > to why you do not work with on the extension > of VCCV to support multi-segment PWs and thus > allow a single OWN to be used in this configuration > rather than undertaking the more complex task > of interworking the two OAMs. > > This problem is clearly within the remit of the > proposed joint working team, and should be > referred to them. Any modifications to MPLS > technology needed are of course the subject of > RFC4929. > > Regards etc > PWE3 co-chairs > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Dec 21 15:31:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5oVy-0001VG-CN; Fri, 21 Dec 2007 15:30:38 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5oVx-0001VB-QD for pwe3-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 15:30:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5oVx-0001V3-GX for pwe3@ietf.org; Fri, 21 Dec 2007 15:30:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5oVx-0000Ya-4j for pwe3@ietf.org; Fri, 21 Dec 2007 15:30:37 -0500 X-IronPort-AV: E=Sophos;i="4.24,196,1196636400"; d="scan'208";a="1561201" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Dec 2007 21:30:36 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBLKUabj004162; Fri, 21 Dec 2007 21:30:36 +0100 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp536.cisco.com [10.61.66.24]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBLKUZ4j000812; Fri, 21 Dec 2007 20:30:35 GMT Message-ID: <476C226E.4000403@cisco.com> Date: Fri, 21 Dec 2007 20:30:38 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Italo Busi Subject: Re: [PWE3] SG15Q12 liaison on MS-PW requirements - second attempt References: <476C139A.6090400@cisco.com> <028801c8440a$ca02c500$13466297@vim.tlt.alcatel.it> In-Reply-To: <028801c8440a$ca02c500$13466297@vim.tlt.alcatel.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1341; t=1198269036; x=1199133036; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20SG15Q12=20liaison=20on=20MS-PW =20requirements=20-=20second=20attempt |Sender:=20; bh=Ljp/yzepz3zodFDDk6lPRs7MFV2ne44n9ADJzVjjl4o=; b=VVOdc51dspdVC8qkG+JXuwNQck9giKE7dSqiGE9mh67+sydu3edmV+PSFS hOJeCBCo3I7emga3JCcVCbfuYHGiMaigEGjJlnYI917VKUU4IAyaP1DlFFQs oKutpms6ch; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Mark Townsley' , t-mpls-dt@testbed.se, 'pwe3' , 'Danny McPherson' X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Italo Busi wrote: > Stewart, > > It seems a good starting point for the LS reply. > > I have the following comments: > > 1) Add the reference the MS-PW Requirements draft and explicitly asks for an > identification of any additional requirements to cover this application > I will certainly add this - it was in the first version of the liaison. > 2) Remove the sentence: > " > Given that the OAM in the PWE3 segments will need to > be based on RFC5085 (VCCV) we are confused as > to why you do not work with on the extension > of VCCV to support multi-segment PWs and thus > allow a single OWN to be used in this configuration > rather than undertaking the more complex task > of interworking the two OAMs. > " > > It does not add/remove any argument to the current thread on Y.1373/G.8114 and > it is technically incorrect because the LS is not identifying any complex > interworking between the two OAM toolsets. > It is not the intent to make this an adjunct to the Y.1373/G.8114 ongoing discussion, however I do want to understand the implications of two OAMs in this environment. I therefore think that we need some clarity on how the multi-segment OAM will work. Perhaps we should say: Please clarify any interactions that you anticipate between the PWE3 and T-MPLS OAMs. Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Dec 21 17:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5q4N-000614-6S; Fri, 21 Dec 2007 17:10:15 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5q4M-0005xC-7X for pwe3-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 17:10:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5q4L-0005tP-MA for pwe3@ietf.org; Fri, 21 Dec 2007 17:10:13 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5q4L-0007py-3r for pwe3@ietf.org; Fri, 21 Dec 2007 17:10:13 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lBLM8PoJ000864; Fri, 21 Dec 2007 23:08:25 +0100 Received: from itvimn0i34082 ([151.98.70.19]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Dec 2007 23:10:09 +0100 From: "Italo Busi" To: References: <476C139A.6090400@cisco.com> <028801c8440a$ca02c500$13466297@vim.tlt.alcatel.it> <476C226E.4000403@cisco.com> Subject: RE: [PWE3] SG15Q12 liaison on MS-PW requirements - second attempt Date: Fri, 21 Dec 2007 23:10:33 +0100 Message-ID: <02b701c8441e$4e71af00$13466297@vim.tlt.alcatel.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <476C226E.4000403@cisco.com> Thread-Index: AchEEFz44lHH91/NTB25ZUXIwQUNbAADeZKg X-OriginalArrivalTime: 21 Dec 2007 22:10:09.0089 (UTC) FILETIME=[3FD80B10:01C8441E] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 'Mark Townsley' , t-mpls-dt@testbed.se, 'pwe3' , 'Danny McPherson' X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, The rephrase sounds reasonable to me Thanks, Italo > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, December 21, 2007 9:31 PM > To: Italo Busi > Cc: 'pwe3'; 'Danny McPherson'; 'Mark Townsley'; t-mpls-dt@testbed.se > Subject: Re: [PWE3] SG15Q12 liaison on MS-PW requirements - > second attempt > > Italo Busi wrote: > > Stewart, > > > > It seems a good starting point for the LS reply. > > > > I have the following comments: > > > > 1) Add the reference the MS-PW Requirements draft and > explicitly asks for an > > identification of any additional requirements to cover this > application > > > > I will certainly add this - it was in the first version of > the liaison. > > 2) Remove the sentence: > > " > > Given that the OAM in the PWE3 segments will need to > > be based on RFC5085 (VCCV) we are confused as > > to why you do not work with on the extension > > of VCCV to support multi-segment PWs and thus > > allow a single OWN to be used in this configuration > > rather than undertaking the more complex task > > of interworking the two OAMs. > > " > > > > It does not add/remove any argument to the current thread > on Y.1373/G.8114 and > > it is technically incorrect because the LS is not > identifying any complex > > interworking between the two OAM toolsets. > > > It is not the intent to make this an adjunct to the Y.1373/G.8114 > ongoing discussion, > however I do want to understand the implications of two OAMs in this > environment. I therefore think that we need some clarity on how the > multi-segment > OAM will work. > > Perhaps we should say: > > Please clarify any interactions that you anticipate between > the PWE3 and > T-MPLS > OAMs. > > Stewart > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Dec 21 18:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qpO-0007uM-El; Fri, 21 Dec 2007 17:58:50 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5qpL-0007sl-Cd for pwe3-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 17:58:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qpK-0007sO-WB; Fri, 21 Dec 2007 17:58:47 -0500 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5qpK-0003BU-He; Fri, 21 Dec 2007 17:58:46 -0500 Received: by bosco.isi.edu (Postfix, from userid 70) id 44F981052BB; Fri, 21 Dec 2007 14:58:46 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071221225846.44F981052BB@bosco.isi.edu> Date: Fri, 21 Dec 2007 14:58:46 -0800 (PST) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 5085 on Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5085 Title: Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires Author: T. Nadeau, Ed., C. Pignataro, Ed. Status: Standards Track Date: December 2007 Mailbox: tnadeau@lucidvision.com, cpignata@cisco.com Pages: 30 Characters: 67847 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-vccv-15.txt URL: http://www.rfc-editor.org/rfc/rfc5085.txt This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Dec 23 20:58:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6cYw-0002oP-JC; Sun, 23 Dec 2007 20:57:02 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J6cYv-0002gO-48 for pwe3-confirm+ok@megatron.ietf.org; Sun, 23 Dec 2007 20:57:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6cYu-0002fN-Nf for pwe3@ietf.org; Sun, 23 Dec 2007 20:57:00 -0500 Received: from david.sha.siemens.com.cn ([194.138.203.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6cYo-0008Qb-Nv for pwe3@ietf.org; Sun, 23 Dec 2007 20:57:00 -0500 Received: from mail.sha.siemens.com.cn (mail.sha.siemens.com.cn [194.138.237.116]) by david.sha.siemens.com.cn (8.11.7/8.11.7) with ESMTP id lBO1udh02496; Mon, 24 Dec 2007 09:56:40 +0800 (CST) Received: from ssmcmail07.cn001.siemens.net ([140.231.196.47]) by mail.sha.siemens.com.cn (8.11.7/8.11.7) with ESMTP id lBO1uZI22398; Mon, 24 Dec 2007 09:56:36 +0800 (CST) Received: by ssmcmail07.cn001.siemens.net with Internet Mail Service (5.5.2657.72) id ; Mon, 24 Dec 2007 09:56:35 +0800 Message-ID: <83678987E699AF4F88FE1DA70BA9359F07E17A2D@ssmcmail05.cn001.siemens.net> From: "Jin Li Zhong, PB SHA" To: stbryant@cisco.com Subject: RE: [PWE3] SG15Q12 liaison on MS-PW requirements - second attempt Date: Mon, 24 Dec 2007 09:56:30 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.7 (++) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0236490021==" Errors-To: pwe3-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0236490021== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C845D0.33FD2A57" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C845D0.33FD2A57 Content-Type: text/plain Dear Stewart I have some commets, as follows. In the liaison, the motivation of this MS-PW across T-MPLS solution is not mentioned. Because there are other solutions for MS-PW across T-MPLS. So a detail analysis of motivation, comparison, advantage and disvantage of this solution should be added. Best Regards Lizhong JIN Nokia Siemens Networks Building 89, 1122 North QinZhou Road, Shanghai, 200211, P.R.China ---------------------------------------------------------------------- Message: 1 Date: Fri, 21 Dec 2007 19:27:22 +0000 From: Stewart Bryant Subject: [PWE3] SG15Q12 liaison on MS-PW requirements - second attempt To: pwe3 , Danny McPherson Cc: Mark Townsley , t-mpls-dt@testbed.se Message-ID: <476C139A.6090400@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Here is a second attempt at the response to this liaison. The response was due on tuesday, but we are clearly not going to achieve that. I propose to send this formally to SG15 on 11th January. The reason that SG15 requested a response by Christmas was a contribution deadline for the Geneva meeting in February, so I propose to address that by posting a pointer to this thread to their mailing list. Please review and I will incorporate comments. Thanks Stewart ============================================================ That you for your liaison of 14 September 2007 entitled "Liaison Statement to IETF PWE3 WG on MS-PW over T-MPLS " https://datatracker.ietf.org/liaison/372/ We apologizes for the late response, but as you are aware members or PWE3 have had a considerable number of other TMPLS related tasks to work on. The review of this document was particularly difficult because it was not expressed in terms of the language that we use to define pseudowires, and we request that the proposed design be restated in the same language and notation that is used in RFC3985 and so that members of the IETF PWE3 WG can fully understand the proposal. The T-MPLS segment that you propose in Figure 1 must be indistinguishable from an IETF MS-PW segment, and we would appreciate it if you could confirm that this is the case. We would draw your attention to ongoing work on multisegment pseudowire signaling draft-ietf-pwe3-dynamic-ms-pw , and draft-ietf-pwe3-segmented-pw . We are concerned that peering arrangement that you propose will require interworking of the PWE3 and T-MPLS signaling with associated complexities. We do not understand why in Figure 2 you use a TMC/PW rather than an MPLS/PW. Members of the IETF PWE3 have expressed difficulty in understanding the paragraph: "Inside the T-MPLS network there is a 1:1 relationship between the MPLS MS-PW and the T-MPLS Channel trail; therefore the TMC/PW_A function is not required to insert a PW label. The reason is that the functionality of multiplexing (for vertical scalability reasons) multiple pseudo-wires over a single trunk is performed at the TMP level (by multiplexing multiple TMCs over a TMP)." and the continuing text to the end of the section. Please could you indicate the label stack at each stage of the packet transit and indicate the purpose of each label, it's purpose and how it is allocated. Given that the OAM in the PWE3 segments will need to be based on RFC5085 (VCCV) we are confused as to why you do not work with on the extension of VCCV to support multi-segment PWs and thus allow a single OWN to be used in this configuration rather than undertaking the more complex task of interworking the two OAMs. This problem is clearly within the remit of the proposed joint working team, and should be referred to them. Any modifications to MPLS technology needed are of course the subject of RFC4929. Regards etc PWE3 co-chairs ------_=_NextPart_001_01C845D0.33FD2A57 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [PWE3] SG15Q12 liaison on MS-PW requirements - second = attempt
Dear Stewart

I have some commets, as follows.

In the liaison, the motivation of this MS-PW across = T-MPLS solution is not mentioned. Because there are other solutions for = MS-PW across T-MPLS. So a detail analysis of motivation, comparison, = advantage and disvantage of this solution should be added.

Best Regards
Lizhong JIN

Nokia Siemens Networks
Building 89, 1122 North QinZhou Road,
Shanghai, 200211, P.R.China

---------------------------------------------------------------= -------

Message: 1
Date: Fri, 21 Dec 2007 19:27:22 +0000
From: Stewart Bryant = <stbryant@cisco.com>
Subject: [PWE3] SG15Q12 liaison on MS-PW = requirements - second attempt
To: pwe3 <pwe3@ietf.org>, Danny McPherson = <danny@tcb.net>
Cc: Mark Townsley <townsley@cisco.com>, = t-mpls-dt@testbed.se
Message-ID: = <476C139A.6090400@cisco.com>
Content-Type: text/plain; charset=3DISO-8859-1; = format=3Dflowed

Here is a second attempt at the response to = this
liaison.

The response was due on tuesday, but we are
clearly not going to achieve that. I propose
to send this formally to SG15 on 11th = January.
The reason that SG15 requested a response by
Christmas was a contribution deadline for
the Geneva meeting in February, so I propose
to address that by posting a pointer to
this thread to their mailing list.

Please review and I will incorporate comments.

Thanks

Stewart

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

That you for your liaison of 14 September 2007
entitled "Liaison Statement to IETF PWE3 WG = on <https://datatracker.ietf.org/documents/LIAISON/file486= .doc>
MS-PW over T-MPLS <https://datatracker.ietf.org/documents/LIAISON/file486= .doc>"

https://datatracker.ietf.org/liaison/372/

We apologizes for the late response, but as you are = aware members
or PWE3 have had a considerable number of = other TMPLS related
tasks to work on.

The review of this document was particularly = difficult because it was
not expressed in terms of the language that we use = to define
pseudowires, and we request that the proposed design = be restated
in the same language and notation that is used in = RFC3985 and
<draft-ietf-pwe3-ms-pw-arch> so that members = of the IETF
<http://tools.ietf.org/html/draft-ietf-pwe3-ms-pw-arch-= 03.txt>
PWE3 WG can fully understand the proposal.

The T-MPLS segment that you propose in Figure 1 = must
be indistinguishable from an IETF MS-PW segment, and = we
would appreciate it if you could confirm that this = is the case.

We would draw your attention to ongoing work = on
multisegment pseudowire signaling = draft-ietf-pwe3-dynamic-ms-pw
<http://tools.ietf.org/wg/pwe3/draft-ietf-pwe3-dynamic-= ms-pw/>, and
draft-ietf-pwe3-segmented-pw
<http://tools.ietf.org/wg/pwe3/draft-ietf-pwe3-segmente= d-pw/>. We are
concerned that peering
arrangement that you propose will require = interworking of the
PWE3 and T-MPLS signaling with associated = complexities.

We do not understand why in Figure 2 you use a TMC/PW = rather
than an MPLS/PW.

Members of the IETF PWE3 have expressed difficulty = in
understanding the paragraph:

"Inside the T-MPLS network there is a 1:1
relationship between the MPLS MS-PW and the
T-MPLS Channel trail; therefore the TMC/PW_A
function is not required to insert a PW = label.
The reason is that the functionality of = multiplexing
(for vertical scalability reasons) multiple = pseudo-wires
over a single trunk is performed at the TMP = level
(by multiplexing multiple TMCs over a = TMP)."

and the continuing text to the end of the = section.

Please could you indicate the label stack at
each stage of the packet transit and indicate
the purpose of each label, it's purpose
and how it is allocated.

Given that the OAM in the PWE3 segments will need = to
be based on RFC5085 (VCCV) we are confused as
to why you do not work with on the extension
of VCCV to support multi-segment PWs and thus
allow a single OWN to be used in this = configuration
rather than undertaking the more complex task
of interworking the two OAMs.

This problem is clearly within the remit of = the
proposed joint working team, and should be
referred to them. Any modifications to MPLS
technology needed are of course the subject = of
RFC4929.

Regards etc
PWE3 co-chairs

------_=_NextPart_001_01C845D0.33FD2A57-- --===============0236490021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0236490021==-- From pwe3-bounces@ietf.org Thu Dec 27 06:40:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7r5I-0002WE-S5; Thu, 27 Dec 2007 06:39:32 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J7r5H-0002Uc-DI for pwe3-confirm+ok@megatron.ietf.org; Thu, 27 Dec 2007 06:39:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7r5H-0002Sf-2Z for pwe3@ietf.org; Thu, 27 Dec 2007 06:39:31 -0500 Received: from [212.199.240.16] (helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7r5F-0006Zq-00 for pwe3@ietf.org; Thu, 27 Dec 2007 06:39:31 -0500 Received: from exrad3.ad.rad.co.il ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 27 Dec 2007 13:39:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Dec 2007 13:39:26 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D05FA4F8C@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question on the "independent mode" of draft-muley-dutta Thread-Index: AchIfSJbSRsrzEjmQvK3SviAkQnm5w== From: "Yaakov Stein" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Keren Zik-Meirom Subject: [PWE3] question on the "independent mode" of draft-muley-dutta X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0418928844==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0418928844== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8487D.225D8191" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8487D.225D8191 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all (and especially co-authors of draft-muley-dutta) =20 Section 4.1. (Independent Mode) In draft-muley-dutta-pwe3-redundancy-bit-02 says: =20 PW endpoint nodes independently select which PW they intend to make=20 active and which PWs they intend to make standby. They advertise the=20 corresponding Active/Standby forwarding state for each PW. Each PW=20 endpoint compares local and remote status and uses the PW that is=20 operationally UP at both endpoints and that shows Active states at=20 both the local and remote endpoint. =20 After which there is a discussion about what happens if an active PW is not found. =20 I have a question about what happens when there are two perfectly good PWs. =20 What happens if initially the two endpoints choose different PWs as the active ones ? I am assuming that an endpoint, seeing that the other declares the PW it intended as backup to be the active one, then chooses to switch and sends an active indication on the other PW. Meanwhile the other endpoint does the same, causing infinite flapping. =20 Did I misunderstand something ? =20 Y(J)S ------_=_NextPart_001_01C8487D.225D8191 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all = (and=20 especially co-authors of draft-muley-dutta)

Section 4.1. (Independent Mode) In draft-muley-dutta-pwe3-redundancy-bit-02 says:

   PW = endpoint=20 nodes independently select which PW they intend to make
   = active=20 and which PWs they intend to make standby. They advertise the =
  =20 corresponding Active/Standby forwarding state for each PW. Each PW=20
   endpoint compares local and remote status and uses the = PW that=20 is
   operationally UP at both endpoints and that = shows=20 Active states at
   both the local and remote=20 endpoint.

After = which there is=20 a discussion about what happens if an active PW is not=20 found.

I have = a question=20 about what happens when there are two perfectly good = PWs.

What = happens if=20 initially the two endpoints choose different PWs as the active ones=20 ?

I = am=20 assuming that an endpoint, seeing that the other declares the = PW it=20 intended as backup

to be = the active=20 one, then chooses to switch and sends an active indication on the other=20 PW.

Meanwhile the other=20 endpoint does the same, causing infinite flapping.

Did I=20 misunderstand something ?

Y(J)S
------_=_NextPart_001_01C8487D.225D8191-- --===============0418928844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0418928844==-- From pwe3-bounces@ietf.org Thu Dec 27 06:53:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7rHi-0007hX-Qu; Thu, 27 Dec 2007 06:52:22 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J7rHh-0007gp-CQ for pwe3-confirm+ok@megatron.ietf.org; Thu, 27 Dec 2007 06:52:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7rHg-0007ee-TD for pwe3@ietf.org; Thu, 27 Dec 2007 06:52:20 -0500 Received: from eci-iron1.ecitele.com ([147.234.242.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7rHf-00007i-Jm for pwe3@ietf.org; Thu, 27 Dec 2007 06:52:20 -0500 Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 27 Dec 2007 14:06:10 +0200 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Dec 2007 13:52:18 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.210) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.240.5; Thu, 27 Dec 2007 13:52:17 +0200 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] question on the "independent mode" of draft-muley-dutta Date: Thu, 27 Dec 2007 13:52:16 +0200 Message-ID: <64122293A6365B4A9794DC5636F9ACFD0252EE2A@ilptex01.ecitele.com> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D05FA4F8C@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] question on the "independent mode" of draft-muley-dutta Thread-Index: AchIfSJbSRsrzEjmQvK3SviAkQnm5wAAM97A References: <457D36D9D89B5B47BC06DA869B1C815D05FA4F8C@exrad3.ad.rad.co.il> From: Alexander Vainshtein To: "Yaakov Stein" X-OriginalArrivalTime: 27 Dec 2007 11:52:18.0350 (UTC) FILETIME=[EE70ACE0:01C8487E] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: Keren Zik-Meirom , pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0178863631==" Errors-To: pwe3-bounces@ietf.org --===============0178863631== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8487E.EDCF659F" ------_=_NextPart_001_01C8487E.EDCF659F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaakov and all, The cited section defines two PW states: o Active State =09 A PW is considered to be in Active state when the PW labels are=20 exchanged between its two endpoints in control plane, and the status=20 bits exchanged between the endpoints indicate the PW is UP and Active=20 at both endpoints. In this state user traffic can flow over the PW in=20 both directions.=20 =09 o Standby State=20 =09 A PW is considered to be in Standby state when the PW labels are=20 exchanged between its two endpoints in the control plane, but the=20 status bits exchanged indicate the PW is in Standby state at one or=20 both endpoints. In this state the endpoints MUST NOT forward data=20 traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be=20 sent and received in order to test the liveliness of standby PWs My conclusion from these definitions is that, in the scenario described in Yaakov's message, both PWs shall be in the Standby state (without any flapping) because each one shall be declared as Standby by one of the EPs. As a consequence, no traffic will be forwarded to any of the two PWs.=20 =20 Did I miss something? =20 Regards, Sasha =20 ________________________________ From: Yaakov Stein [mailto:yaakov_s@rad.com]=20 Sent: Thursday, December 27, 2007 1:39 PM To: pwe3@ietf.org Cc: Keren Zik-Meirom Subject: [PWE3] question on the "independent mode" of draft-muley-dutta Hi all (and especially co-authors of draft-muley-dutta) =20 Section 4.1. (Independent Mode) In draft-muley-dutta-pwe3-redundancy-bit-02 says: =20 PW endpoint nodes independently select which PW they intend to make=20 active and which PWs they intend to make standby. They advertise the=20 corresponding Active/Standby forwarding state for each PW. Each PW=20 endpoint compares local and remote status and uses the PW that is=20 operationally UP at both endpoints and that shows Active states at=20 both the local and remote endpoint. =20 After which there is a discussion about what happens if an active PW is not found. =20 I have a question about what happens when there are two perfectly good PWs. =20 What happens if initially the two endpoints choose different PWs as the active ones ? I am assuming that an endpoint, seeing that the other declares the PW it intended as backup to be the active one, then chooses to switch and sends an active indication on the other PW. Meanwhile the other endpoint does the same, causing infinite flapping. =20 Did I misunderstand something ? =20 Y(J)S ------_=_NextPart_001_01C8487E.EDCF659F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yaakov=20 and all,

The=20 cited section defines two PW states:

<quote>

  =20 o Active=20 = State           &n= bsp;           &nb= sp;           &nbs= p;            = ; =20

   A PW is considered to be in Active state when the = PW=20 labels are
   exchanged between its two endpoints in = control=20 plane, and the status
   bits exchanged between the = endpoints=20 indicate the PW is UP and Active
   at both endpoints. = In this=20 state user traffic can flow over the PW in
   both = directions.=20

   o Standby State

   A PW is = considered=20 to be in Standby state when the PW labels are
   = exchanged=20 between its two endpoints in the control plane, but the =
  =20 status bits exchanged indicate the PW is in Standby state at one or=20
   both endpoints. In this state the endpoints MUST NOT = forward=20 data
   traffic over the PW but MAY allow PW OAM = packets, e.g.,=20 VCCV, to be
   sent and received in order to test the = liveliness=20 of standby PWs

<end quote>

My=20 conclusion from these definitions is that, in the scenario described in = Yaakov's=20 message, both PWs shall be in the=20 Standby state (without any flapping) because each = one=20 shall be declared as Standby by one of the EPs. As a consequence, = no=20 traffic will be forwarded to any of the two PWs.

Did I=20 miss something?

Regards,

       &nbs= p;      =20 Sasha

From: Yaakov Stein = [mailto:yaakov_s@rad.com]=20
Sent: Thursday, December 27, 2007 1:39 PM
To:=20 pwe3@ietf.org
Cc: Keren Zik-Meirom
Subject: [PWE3] = question=20 on the "independent mode" of draft-muley-dutta

Hi all = (and=20 especially co-authors of draft-muley-dutta)

Section 4.1. (Independent Mode) In draft-muley-dutta-pwe3-redundancy-bit-02 says:

   PW = endpoint=20 nodes independently select which PW they intend to make
   = active=20 and which PWs they intend to make standby. They advertise the =
  =20 corresponding Active/Standby forwarding state for each PW. Each PW=20
   endpoint compares local and remote status and uses the = PW that=20 is
   operationally UP at both endpoints and that = shows=20 Active states at
   both the local and remote=20 endpoint.

After = which there is=20 a discussion about what happens if an active PW is not=20 found.

I have = a question=20 about what happens when there are two perfectly good = PWs.

What = happens if=20 initially the two endpoints choose different PWs as the active ones=20 ?

I = am=20 assuming that an endpoint, seeing that the other declares the = PW it=20 intended as backup

to be = the active=20 one, then chooses to switch and sends an active indication on the other=20 PW.

Meanwhile the other=20 endpoint does the same, causing infinite flapping.

Did I=20 misunderstand something ?

Y(J)S
------_=_NextPart_001_01C8487E.EDCF659F-- --===============0178863631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0178863631==-- From pwe3-bounces@ietf.org Fri Dec 28 09:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8GLG-0005b6-25; Fri, 28 Dec 2007 09:37:42 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J5M47-0001og-Jq for pwe3-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 09:07:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5M47-0001oY-7S for pwe3@ietf.org; Thu, 20 Dec 2007 09:07:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5M46-0003iz-Ac for pwe3@ietf.org; Thu, 20 Dec 2007 09:07:59 -0500 X-IronPort-AV: E=Sophos;i="4.24,189,1196636400"; d="scan'208";a="1421331" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Dec 2007 15:07:57 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBKE7vuE009820; Thu, 20 Dec 2007 15:07:57 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBKE7sqw018101; Thu, 20 Dec 2007 14:07:55 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 15:07:55 +0100 Received: from 10.21.123.11 ([10.21.123.11]) by xmb-ams-33a.emea.cisco.com ([144.254.231.85]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Thu, 20 Dec 2007 14:07:54 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 20 Dec 2007 06:07:53 -0800 From: Monique Morrow To: Huub van Helvoort , Message-ID: Thread-Topic: progress of G.8113 and G.8114 Thread-Index: AchDEbYt9MvtiK8EEdyRtgAX8tV3kA== In-Reply-To: <4769767F.8040102@chello.nl> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Dec 2007 14:07:55.0046 (UTC) FILETIME=[B765B460:01C84311] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4748; t=1198159677; x=1199023677; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmorrow@cisco.com; z=From:=20Monique=20Morrow=20 |Subject:=20Re=3A=20progress=20of=20G.8113=20and=20G.8114 |Sender:=20; bh=rPnxKL86ZtwhGuyN9hSAzksycde/5ayWj5KIvmAUzhk=; b=pPqKs/kPycHrXlvtE5Y1cL13PwAa7L+kxWWvlJOuxEMVcRqBuujWfGz7r7 t/WitT/m9cPbSkhvfjUkYj3Zf4XmBUCywWPYHJoUceWbfziqtfrp5iQ9PTVh 8iYkMn/wcb; Authentication-Results: ams-dkim-2; header.From=mmorrow@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 X-Mailman-Approved-At: Fri, 28 Dec 2007 09:37:40 -0500 Cc: Q5/13 , t-mpls-dt@testbed.se, pwe3 Subject: [PWE3] Re: progress of G.8113 and G.8114 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Huub, [hvh] there was already a response from an operator confirming that the > correction I propose is in line with transport technology. I am unsure whether or not I saw a confirmation from an operator to this effect. I have seen dialogue from an operator but NOT a confirmation therein. Could please point out specifically where there is actually a confirmation? Regards, Monique On 12/19/07 11:52 AM, "Huub van Helvoort" wrote: > Hi Stewart, > > See my repondse to your reply in-line [hvh]: > >> The change that you propose is a fundamental change >> to the whole rational for designing an OAM specifically >> for T-MPLS rather than reusing an existing pseudowire >> OAM design. > > [hvh] This is NOT a fundamental change, it is a clarification because I > detected a mis-interpretation. > T-MPLS is developed by SG15, SG15 uses layered network models, hence > T-MPLS is one of the layer technologies they develop. And reference > to T-MPLS implies the T-MPLS layer, to make sure that everybody > understands that I made the correction. > >> It has always been asserted by the T-MPLS designers >> that T-MPLS has special failure modes that did not >> apply to PWE3/MPLS and therefore existing OAM >> mechanisms such as RFC5085 (VCCV) were not appropriate. > > [hvh] Indeed. The failure modes of T-MPLS are related to the transport > functionality and based on the experience with other transport > technologies. > >> When challenged to specify these, none have been provided >> and now it is proposed to answer this long outstanding >> AAP issue by changing the language to indicate that >> there are no special T-MPLS failure modes. > > [hvh] Then you are still mis-interpreting the sentence, It is stating > that the failure modes are confined to the T-MPLS layer. > (and this is a generic requirement for layered transport networks). > > What the failure modes are is out of scope for these recommendations, > that is the responsability of the equipment specification G.8121. > >> This change to the requirements demonstrates that >> the fundamental technical basis for rejecting the >> IETF OAM methods was flawed, and this decision therefore >> needs to be revisited. > > [hvh] Again, there is NO change, it is a correction to avoid > mis-interpretation. (as is clear from your comment) > >> G.8113 and G.8114 should now be put on hold whilst the >> implications of this are properly evaluated. > > [hvh] There are NO implications that need to be re-evaluated. > >> The least that you should do is to change the text >> of the requirement to >> >> "T-MPLS provides a connection-oriented layer network and hence >> there will be failure modes that are only relevant to >> the T-MPLS layer. Detection of these failure modes is possible >> through the use of RFC5085" > > [hvh] the addition of the last sentence restricts the requirement by > providing a solution, solutions are out of scope for G.8113. > >> and then to add RFC5085 as a candidate solution in G.8114 using >> the text that has already been provided. > > [hvh] this is a technical change beyond what can be addressed by > AAP comments. > >> However designing a second OAM for pseudowire is not in the >> best interests of the operator community and it would be better >> to abandon this approach and to bring any additional >> requirements to the IETF for incorporation in VCCV. > > Huub > Reagrds, Huub. > >> ================================= >> Huub van Helvoort wrote: >>> Hello Steward, >>> >>> Thank you for helping me. >>> >>> You wrote: >>> >>>>> Unfortunately there are still comments that are not resolved. >>>>> Are there any other proposals that will help to resolve the >>>>> open issues and get G.8113 and G.8114 approved. >>>> Just looking at the first unresolved comment, you could list >>>> the failure modes that apply to T-MPLS but not to MPLS >>>> as requested in the issue. >>>> >>>> Alternatively you could state that there are no failure >>>> modes that apply to T-MPLS that do not apply to >>>> one or more MPLS modes. >>> >>> Your comment made me read the original text very carefully, and >>> I found that the sentence: >>> >>> "T-MPLS provides a connection-oriented layer network and hence >>> there will be failure modes that are only relevant to T-MPLS." >>> >>> is the cause of your question. >>> It should have been: >>> "T-MPLS provides a connection-oriented layer network and hence >>> there will be failure modes that are only relevant to >>> the T-MPLS layer." >>> >>> I will make this change to resolve this issue. >>> >>> Cheers, Huub. >>> >> >> _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Dec 30 06:26:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8wHx-0007mF-9a; Sun, 30 Dec 2007 06:25:05 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J8wHv-0007m8-Gq for pwe3-confirm+ok@megatron.ietf.org; Sun, 30 Dec 2007 06:25:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8wHv-0007m0-70 for pwe3@ietf.org; Sun, 30 Dec 2007 06:25:03 -0500 Received: from mx2-q.rad.co.il ([80.74.100.144] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8wHs-0000sw-B9 for pwe3@ietf.org; Sun, 30 Dec 2007 06:25:03 -0500 Received: from exrad3.ad.rad.co.il ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 30 Dec 2007 13:24:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] question on the "independent mode" of draft-muley-dutta Date: Sun, 30 Dec 2007 13:24:56 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D0604DE0F@exrad3.ad.rad.co.il> In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD0252EE2A@ilptex01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] question on the "independent mode" of draft-muley-dutta Thread-Index: AchIfSJbSRsrzEjmQvK3SviAkQnm5wAAM97AAJYYA2A= From: "Yaakov Stein" To: "Alexander Vainshtein" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: Keren Zik-Meirom , pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1449722059==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1449722059== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84AD6.9AF66164" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84AD6.9AF66164 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha =20 Yes, I agree that yours is another possible interpretation. =20 However, I'm not sure that the behavior is much better. =20 \personal ON Glad to see that you are still monitoring PWE at your new email address. \personal OFF =20 Y(J)S =20 ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, December 27, 2007 1:52 PM To: Yaakov Stein Cc: Keren Zik-Meirom; pwe3@ietf.org Subject: RE: [PWE3] question on the "independent mode" of draft-muley-dutta Yaakov and all, The cited section defines two PW states: o Active State =09 A PW is considered to be in Active state when the PW labels are=20 exchanged between its two endpoints in control plane, and the status=20 bits exchanged between the endpoints indicate the PW is UP and Active=20 at both endpoints. In this state user traffic can flow over the PW in=20 both directions.=20 =09 o Standby State=20 =09 A PW is considered to be in Standby state when the PW labels are=20 exchanged between its two endpoints in the control plane, but the=20 status bits exchanged indicate the PW is in Standby state at one or=20 both endpoints. In this state the endpoints MUST NOT forward data=20 traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be=20 sent and received in order to test the liveliness of standby PWs My conclusion from these definitions is that, in the scenario described in Yaakov's message, both PWs shall be in the Standby state (without any flapping) because each one shall be declared as Standby by one of the EPs. As a consequence, no traffic will be forwarded to any of the two PWs.=20 =20 Did I miss something? =20 Regards, Sasha =20 ________________________________ From: Yaakov Stein [mailto:yaakov_s@rad.com]=20 Sent: Thursday, December 27, 2007 1:39 PM To: pwe3@ietf.org Cc: Keren Zik-Meirom Subject: [PWE3] question on the "independent mode" of draft-muley-dutta Hi all (and especially co-authors of draft-muley-dutta) =20 Section 4.1. (Independent Mode) In draft-muley-dutta-pwe3-redundancy-bit-02 says: =20 PW endpoint nodes independently select which PW they intend to make=20 active and which PWs they intend to make standby. They advertise the=20 corresponding Active/Standby forwarding state for each PW. Each PW=20 endpoint compares local and remote status and uses the PW that is=20 operationally UP at both endpoints and that shows Active states at=20 both the local and remote endpoint. =20 After which there is a discussion about what happens if an active PW is not found. =20 I have a question about what happens when there are two perfectly good PWs. =20 What happens if initially the two endpoints choose different PWs as the active ones ? I am assuming that an endpoint, seeing that the other declares the PW it intended as backup to be the active one, then chooses to switch and sends an active indication on the other PW. Meanwhile the other endpoint does the same, causing infinite flapping. =20 Did I misunderstand something ? =20 Y(J)S ------_=_NextPart_001_01C84AD6.9AF66164 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sasha

Yes, I=20 agree that yours is another possible interpretation.

However, I'm not sure that the behavior is much=20 better.

\personal ON

Glad to see that you are still monitoring PWE at your new = email=20 address.

\personal OFF

Y(J)S

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, = December=20 27, 2007 1:52 PM
To: Yaakov Stein
Cc: Keren = Zik-Meirom;=20 pwe3@ietf.org
Subject: RE: [PWE3] question on the "independent = mode"=20 of draft-muley-dutta

Yaakov=20 and all,

The=20 cited section defines two PW states:

<quote>

  =20 o Active=20 = State           &n= bsp;           &nb= sp;           &nbs= p;            = ; =20

   A PW is considered to be in Active state when the = PW=20 labels are
   exchanged between its two endpoints in = control=20 plane, and the status
   bits exchanged between the = endpoints=20 indicate the PW is UP and Active
   at both endpoints. = In this=20 state user traffic can flow over the PW in
   both = directions.=20

   o Standby State

   A PW is = considered=20 to be in Standby state when the PW labels are
   = exchanged=20 between its two endpoints in the control plane, but the =
  =20 status bits exchanged indicate the PW is in Standby state at one or=20
   both endpoints. In this state the endpoints MUST NOT = forward=20 data
   traffic over the PW but MAY allow PW OAM = packets, e.g.,=20 VCCV, to be
   sent and received in order to test the = liveliness=20 of standby PWs

<end quote>

My=20 conclusion from these definitions is that, in the scenario described in = Yaakov's=20 message, both PWs shall be in the=20 Standby state (without any flapping) because each = one=20 shall be declared as Standby by one of the EPs. As a consequence, = no=20 traffic will be forwarded to any of the two PWs.

Did I=20 miss something?

Regards,

       &nbs= p;      =20 Sasha

From: Yaakov Stein = [mailto:yaakov_s@rad.com]=20
Sent: Thursday, December 27, 2007 1:39 PM
To:=20 pwe3@ietf.org
Cc: Keren Zik-Meirom
Subject: [PWE3] = question=20 on the "independent mode" of draft-muley-dutta

Hi all = (and=20 especially co-authors of draft-muley-dutta)

Section 4.1. (Independent Mode) In draft-muley-dutta-pwe3-redundancy-bit-02 says:

   PW = endpoint=20 nodes independently select which PW they intend to make
   = active=20 and which PWs they intend to make standby. They advertise the =
  =20 corresponding Active/Standby forwarding state for each PW. Each PW=20
   endpoint compares local and remote status and uses the = PW that=20 is
   operationally UP at both endpoints and that = shows=20 Active states at
   both the local and remote=20 endpoint.

After = which there is=20 a discussion about what happens if an active PW is not=20 found.

I have = a question=20 about what happens when there are two perfectly good = PWs.

What = happens if=20 initially the two endpoints choose different PWs as the active ones=20 ?

I = am=20 assuming that an endpoint, seeing that the other declares the = PW it=20 intended as backup

to be = the active=20 one, then chooses to switch and sends an active indication on the other=20 PW.

Meanwhile the other=20 endpoint does the same, causing infinite flapping.

Did I=20 misunderstand something ?

Y(J)S
------_=_NextPart_001_01C84AD6.9AF66164-- --===============1449722059== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1449722059==-- From pwe3-bounces@ietf.org Sun Dec 30 07:00:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8wpb-0005XL-Qc; Sun, 30 Dec 2007 06:59:51 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J8wpa-0005WI-3j for pwe3-confirm+ok@megatron.ietf.org; Sun, 30 Dec 2007 06:59:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8wpZ-0005WA-NT for pwe3@ietf.org; Sun, 30 Dec 2007 06:59:49 -0500 Received: from eci-iron1.ecitele.com ([147.234.242.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8wpY-0007Ot-2Z for pwe3@ietf.org; Sun, 30 Dec 2007 06:59:49 -0500 Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 30 Dec 2007 14:14:17 +0200 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Dec 2007 13:59:38 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.240.5; Sun, 30 Dec 2007 13:59:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] question on the "independent mode" of draft-muley-dutta Date: Sun, 30 Dec 2007 13:59:34 +0200 Message-ID: <64122293A6365B4A9794DC5636F9ACFD025819DE@ILPTEX02.ecitele.com> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D0604DE0F@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] question on the "independent mode" of draft-muley-dutta Thread-Index: AchIfSJbSRsrzEjmQvK3SviAkQnm5wAAM97AAJYYA2AAARFD4A== References: <64122293A6365B4A9794DC5636F9ACFD0252EE2A@ilptex01.ecitele.com> <457D36D9D89B5B47BC06DA869B1C815D0604DE0F@exrad3.ad.rad.co.il> From: Alexander Vainshtein To: "Yaakov Stein" X-OriginalArrivalTime: 30 Dec 2007 11:59:38.0627 (UTC) FILETIME=[741ADD30:01C84ADB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Cc: Keren Zik-Meirom , pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0035698327==" Errors-To: pwe3-bounces@ietf.org --===============0035698327== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84ADB.73AB0CF8" ------_=_NextPart_001_01C84ADB.73AB0CF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaakov, I did not claim that my interpretation provides for better behavior in the data plane. Control plane-wise it is probably better (no churn). But this is hardly of any interest. =20 Regards, Sasha =20 =20 ________________________________ From: Yaakov Stein [mailto:yaakov_s@rad.com]=20 Sent: Sunday, December 30, 2007 1:25 PM To: Alexander Vainshtein Cc: Keren Zik-Meirom; pwe3@ietf.org Subject: RE: [PWE3] question on the "independent mode" of draft-muley-dutta Sasha =20 Yes, I agree that yours is another possible interpretation. =20 However, I'm not sure that the behavior is much better. =20 \personal ON Glad to see that you are still monitoring PWE at your new email address. \personal OFF =20 Y(J)S =20 ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, December 27, 2007 1:52 PM To: Yaakov Stein Cc: Keren Zik-Meirom; pwe3@ietf.org Subject: RE: [PWE3] question on the "independent mode" of draft-muley-dutta Yaakov and all, The cited section defines two PW states: o Active State =09 A PW is considered to be in Active state when the PW labels are=20 exchanged between its two endpoints in control plane, and the status=20 bits exchanged between the endpoints indicate the PW is UP and Active=20 at both endpoints. In this state user traffic can flow over the PW in=20 both directions.=20 =09 o Standby State=20 =09 A PW is considered to be in Standby state when the PW labels are=20 exchanged between its two endpoints in the control plane, but the=20 status bits exchanged indicate the PW is in Standby state at one or=20 both endpoints. In this state the endpoints MUST NOT forward data=20 traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be=20 sent and received in order to test the liveliness of standby PWs My conclusion from these definitions is that, in the scenario described in Yaakov's message, both PWs shall be in the Standby state (without any flapping) because each one shall be declared as Standby by one of the EPs. As a consequence, no traffic will be forwarded to any of the two PWs.=20 =20 Did I miss something? =20 Regards, Sasha =20 ________________________________ From: Yaakov Stein [mailto:yaakov_s@rad.com]=20 Sent: Thursday, December 27, 2007 1:39 PM To: pwe3@ietf.org Cc: Keren Zik-Meirom Subject: [PWE3] question on the "independent mode" of draft-muley-dutta Hi all (and especially co-authors of draft-muley-dutta) =20 Section 4.1. (Independent Mode) In draft-muley-dutta-pwe3-redundancy-bit-02 says: =20 PW endpoint nodes independently select which PW they intend to make=20 active and which PWs they intend to make standby. They advertise the=20 corresponding Active/Standby forwarding state for each PW. Each PW=20 endpoint compares local and remote status and uses the PW that is=20 operationally UP at both endpoints and that shows Active states at=20 both the local and remote endpoint. =20 After which there is a discussion about what happens if an active PW is not found. =20 I have a question about what happens when there are two perfectly good PWs. =20 What happens if initially the two endpoints choose different PWs as the active ones ? I am assuming that an endpoint, seeing that the other declares the PW it intended as backup to be the active one, then chooses to switch and sends an active indication on the other PW. Meanwhile the other endpoint does the same, causing infinite flapping. =20 Did I misunderstand something ? =20 Y(J)S ------_=_NextPart_001_01C84ADB.73AB0CF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yaakov,

I did=20 not claim that my interpretation provides for better behavior in the = data=20 plane.

Control plane-wise it is probably better (no churn). But this = is hardly=20 of any interest.

Regards,

          &nbs= p;       =20 Sasha

From: Yaakov Stein = [mailto:yaakov_s@rad.com]=20
Sent: Sunday, December 30, 2007 1:25 PM
To: = Alexander=20 Vainshtein
Cc: Keren Zik-Meirom; = pwe3@ietf.org
Subject: RE:=20 [PWE3] question on the "independent mode" of=20 draft-muley-dutta

Sasha

Yes, I=20 agree that yours is another possible interpretation.

However, I'm not sure that the behavior is much=20 better.

\personal ON

Glad to see that you are still monitoring PWE at your new = email=20 address.

\personal OFF

Y(J)S

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, = December=20 27, 2007 1:52 PM
To: Yaakov Stein
Cc: Keren = Zik-Meirom;=20 pwe3@ietf.org
Subject: RE: [PWE3] question on the "independent = mode"=20 of draft-muley-dutta

Yaakov=20 and all,

The=20 cited section defines two PW states:

<quote>

  =20 o Active=20 = State           &n= bsp;           &nb= sp;           &nbs= p;            = ; =20

   A PW is considered to be in Active state when the = PW=20 labels are
   exchanged between its two endpoints in = control=20 plane, and the status
   bits exchanged between the = endpoints=20 indicate the PW is UP and Active
   at both endpoints. = In this=20 state user traffic can flow over the PW in
   both = directions.=20

   o Standby State

   A PW is = considered=20 to be in Standby state when the PW labels are
   = exchanged=20 between its two endpoints in the control plane, but the =
  =20 status bits exchanged indicate the PW is in Standby state at one or=20
   both endpoints. In this state the endpoints MUST NOT = forward=20 data
   traffic over the PW but MAY allow PW OAM = packets, e.g.,=20 VCCV, to be
   sent and received in order to test the = liveliness=20 of standby PWs

<end quote>

My=20 conclusion from these definitions is that, in the scenario described in = Yaakov's=20 message, both PWs shall be in the=20 Standby state (without any flapping) because each = one=20 shall be declared as Standby by one of the EPs. As a consequence, = no=20 traffic will be forwarded to any of the two PWs.

Did I=20 miss something?

Regards,

       &nbs= p;      =20 Sasha

From: Yaakov Stein = [mailto:yaakov_s@rad.com]=20
Sent: Thursday, December 27, 2007 1:39 PM
To:=20 pwe3@ietf.org
Cc: Keren Zik-Meirom
Subject: [PWE3] = question=20 on the "independent mode" of draft-muley-dutta

Hi all = (and=20 especially co-authors of draft-muley-dutta)

Section 4.1. (Independent Mode) In draft-muley-dutta-pwe3-redundancy-bit-02 says:

   PW = endpoint=20 nodes independently select which PW they intend to make
   = active=20 and which PWs they intend to make standby. They advertise the =
  =20 corresponding Active/Standby forwarding state for each PW. Each PW=20
   endpoint compares local and remote status and uses the = PW that=20 is
   operationally UP at both endpoints and that = shows=20 Active states at
   both the local and remote=20 endpoint.

After = which there is=20 a discussion about what happens if an active PW is not=20 found.

I have = a question=20 about what happens when there are two perfectly good = PWs.

What = happens if=20 initially the two endpoints choose different PWs as the active ones=20 ?

I = am=20 assuming that an endpoint, seeing that the other declares the = PW it=20 intended as backup

to be = the active=20 one, then chooses to switch and sends an active indication on the other=20 PW.

Meanwhile the other=20 endpoint does the same, causing infinite flapping.

Did I=20 misunderstand something ?

Y(J)S
------_=_NextPart_001_01C84ADB.73AB0CF8-- --===============0035698327== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0035698327==-- From pwe3-bounces@ietf.org Mon Dec 31 11:59:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9NyY-0004yv-M0; Mon, 31 Dec 2007 11:58:54 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1J9NyX-0004yq-Du for pwe3-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 11:58:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9NyX-0004yg-0d for pwe3@ietf.org; Mon, 31 Dec 2007 11:58:53 -0500 Received: from sacmail4.verizon.com ([192.76.84.42]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9NyW-0001MU-2O for pwe3@ietf.org; Mon, 31 Dec 2007 11:58:52 -0500 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id lBVGwnhW005270 for ; Mon, 31 Dec 2007 11:58:50 -0500 (EST) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id lBVGwnVP017430 for ; Mon, 31 Dec 2007 11:58:49 -0500 (EST) Received: from tpaintrmemf3.verizon.com (unknown [127.0.0.1]) by tpaintrmemf3.verizon.com (Symantec Mail Security) with ESMTP id EA8AC528002 for ; Mon, 31 Dec 2007 11:58:48 -0500 (EST) X-AuditID: 8a53433a-ae382bb000000944-fa-47791fc86a52 Received: from coregate2.verizon.com (unknown [138.83.34.48]) by tpaintrmemf3.verizon.com (EMF) with ESMTP id BD4C84E4005 for ; Mon, 31 Dec 2007 11:58:48 -0500 (EST) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id lBVH1D76014743 for ; Mon, 31 Dec 2007 11:01:50 -0600 (CST) Received: from FHDP1CCMXCV01.us.one.verizon.com ([166.68.240.11]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Dec 2007 11:58:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Dec 2007 11:58:46 -0500 Message-ID: <029583E37562274699DC24FB7663A5FC25BF87@FHDP1CCMXCV01.us.one.verizon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: general comments on draft-muley-dutta draft thread-index: AchK2550HI7PTN49SuSbAOHJRpocpAA4to1Q From: To: X-OriginalArrivalTime: 31 Dec 2007 16:58:47.0402 (UTC) FILETIME=[68D254A0:01C84BCE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Subject: [PWE3] RE: general comments on draft-muley-dutta draft X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org =20 Few comments that may help in clarification of the language in draft-muley-dutta: ( some of these points may have been discussed earlier but I did not see it so I am reading the=20 current document as it is..)I do not see comments as purely stylistic as my intention is to have a text clear and not open to interpretations where not intended. ---------- Section 2 Motivation=20 In the following paragraph:=20 " In the absence of faults, all PWs are operationally UP both locally=20 and remotely and a PE node needs to select a single PW to forward=20 user packets to. >>>This is referred to as the active PW. All other PWs=20 will be in standby and must not be used to forward user packets.<<<"=20 I propose to change not a very precise >>>This is ...." into=20 " The PW into which user packets will be forwarded will be the active PW. All other PWs will be passive or in standby mode and must not be used to forward user packets." I propose to rework the following sentence: " In order for both ends of the service to select the same PW for=20 forwarding user packets, >>> it is proposed that a PE node communicates a=20 new status bit to indicate the forwarding state of a PW to its peer=20 PE node." Into something like this ".... it is proposed that a PE node communicates a new status bit to its peer=20 PE node to indicate the forwarding state of a PW ." Or ".... it is proposed that a PE node communicates to its peer=20 PE node a new status bit to indicate the forwarding state of a PW ." Section 3 - Terminology ------- Is "Active PW: An UP PW used for forwarding user traffic. " Change to=20 " Active PW: An UP PW that is used for forwarding user traffic." ----------- Is " PW Endpoint: A PE where a PW terminates on an NSP e.g. A SS-PW PE, an=20 MS-PW T-PE, or a VPLS MTU or PE-r. " I propose to use some kind of designation for the PW endpoint at the risk of having too many of=20 them in Pwe documents - at least as a macro for "A SS-PW PE, an MS-PW T-PE, or a VPLS MTU or PE-r" in this document - for example E-PE or even better - END-PE and use it consistently across the document. ----------- Section 4: Modes of Operation Is: "There are two modes of operation for the use of the PW preferential=20 forwarding status bits: " I suggest: "There are two modes of operation (in which) the PW preferential=20 forwarding status bits COULD ( SHALL ) be used: " --------- Section 4.1 Independent mode: Is: PW endpoint nodes independently select which PW they intend to make=20 active and which PWs they intend to make standby. They advertise the=20 corresponding Active/Standby forwarding state for each PW. Each PW=20 endpoint compares local and remote status and uses the PW that is=20 operationally UP at both endpoints and that shows Active states at=20 both the local and remote endpoint. =20 I suggest adding END-PE designations: PW endpoint nodes (END-PE)independently select which PW they intend to make=20 active and which PWs they intend to make standby. They advertise the corresponding Active/Standby forwarding state for each PW to corresponding Nodes ( END-PEs). Each PW endpoint (END-PE) compares local and remote status and uses the PW that is operationally UP at both endpoints and that shows Active states at both the local and remote endpoint (END-PE). =20 ----------- Is: " In steady state, a PE will always find an Active PW. However, it ..." "Steady state" - term is not referred to in the document thus it may be open to interpretations. But this may be obvious... So I do not feel strongly about it. -------- Section 4.2 Master/slave mode: Is: One endpoint node of the redundant set of PWs is designated the=20 Master and is responsible for selecting which PW both endpoints must=20 use to forward user traffic. Suggested: One endpoint node (END-PE) of the redundant set of PWs is designated the Master [the other end point ( END-PE) is selected a s a slave] and is responsible for selecting which PW endpoints (Master node and slave node) must use to forward user traffic. ------ Is: This status is indicated to the Slave node by setting the preferential forwarding=20 status bit in the status bit TLV to Active.=20 Would this addition clarify the proposal: "This status is indicated to the Slave node by setting the preferential forwarding status bit in the status bit TLV to Active (Status field in PWE Status TLV in LDP Notification Message". ---------- IS: "One endpoint of the PW, the Master, actively selects which PW to=20 activate and uses it for forwarding user traffic. This status is=20 indicated to the Slave node by setting the preferential forwarding=20 status bit in the status bit TLV to Active. >>>>It does forward user=20 traffic to any other of the PW's in the redundant set to the slave=20 node and indicates this by setting the preferential forwarding status bit in the status bit TLV to Standby for those PWs. <<<< The master node=20 MUST ignore any Active/Standby status bits received from the Slave=20 nodes. =20 I refer to the sentence between >>>.. <<< =20 It does not seem clear to me - " It does forward.." refers to - the Master ? If yes, better to write it as " The Master node forwards user traffic.. "=20 As well, the whole sentence needs some reworking as it seems confusing: Maybe this would be OK: " The Master node forwards user (may ? has or should ?) traffic to any ( one of, any or all ?) (delete -other of) the PW's in the redundant set (available on the master node) to the slave node and indicates this ( indicates this to whom - to the slave node in the notification message) assume) by setting the preferential forwarding status bit in the status bit TLV to Standby for those PWs." ----- The same section: Is: The Slave endpoint(s) are required to act on the status bits received=20 from the Master. When the received status bit transitions from Active to Standby, a Slave node MUST stop forwarding over the previously=20 active PW.=20 We should add: The Slave endpoint(s) are required to act on the status bits received=20 from the Master. When the received status bit transitions from Active to Standby, a Slave node MUST stop forwarding over the previously=20 active PW. >> A slave node, upon changing state from active to standby must initiate AC down signaling to directly attached AC end node or PW if this is SS-PE<<<< --------- Section 5.1 Is: Each endpoint compares the updated local and remote status and=20 effectively activates the PW which is "effectively" needs either an explanation or is redundant=20 ---- Thx rmk _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3