RE: draft-balus-mh-pw-control-protocol-00.txt

We find this = same wording in=20 all the drafts -=20

if the entire = packet needs=20 padding, then there MUST=20
So if=20 this is authoritative, it goes against your thesis.

[Sasha] Bearing in mind my previous comment on = "the other=20 drafts", I'd say that this is a common bug. <= /SPAN>=

=

Bug is in the eye of the beholder=20 :><= /SPAN>
<= /SPAN>=

Y(J)S

------_=_NextPart_001_01C519D6.5680A961-- --===============1059255701== 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 --===============1059255701==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Stewart Bryant Subject: PWE3 @ IETF62 provisional agenda Date: Tue, 22 Feb 2005 11:09:52 +0000 Lines: 64 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Thu Feb 24 05:35:58 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: pwe3 X-Spam-Score: 2.0 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Here is the first cut of the PWE3 agenda for IETF62. Have I missed anthing, anything else that needs to be raised? As usual, please can Danny and I have the slides before the meeting. Thanks Stewart Pseudo Wire Emulation Edge to Edge (pwe3) ========================================= WEDNESDAY, March 9, 2005, (1530-1730) CHAIR: "Danny McPherson" "Stewart Bryant" AGENDA: Administrivia Chairs (Stewart & Danny) Agenda Bashing Minutes Blue Sheets WG Document Status Danny McPherson Stewart Bryant Pseudowire Setup and Maintenance using LDP and Ethernet over MPLS Luca Martini draft-ietf-pwe3-control-protocol-15.txt draft-ietf-pwe3-ethernet-encap-09.txt Restructure of drafts folloing AD review Frame Relay over Pseudo-Wires Luca Martini draft-ietf-pwe3-frame-relay-04.txt Update on the rewrite PW Control Word Stewart Bryant Resolve any outstanding comments Requirements for inter domain Pseudo-Wires Nabil Bitar draft-martini-pwe3-MH-PW-requirements-00.txt Multi-hop Pseudowire Setup and Maintenance using LDP David McDysan&Florin Balus Discuss new LDP extensions, end to end signaling procedures to address the related requirements specified in the MH-PWE3 Requirements draft. The procedures described in the draft enable the usage of addressing schemes (L2FECs) and other TLVs already defined for PWs in PW Control PWE3 Applications & OAM Scenarios Simon Delord draft-delord-pwe3-oam-applications-00.txt Introduction to Key Issues From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Yaakov Stein" Subject: RE: FW: AD review of draft-ietf-pwe3-cw-01.txt - comment 5 Date: Wed, 23 Feb 2005 17:47:09 +0200 Lines: 733 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0440003388==" X-From: pwe3-bounces@ietf.org Thu Feb 24 05:38:48 2005 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Thread-Topic: FW: [PWE3] AD review of draft-ietf-pwe3-cw-01.txt - comment 5 Thread-Index: AcUZezROi9VqWgZtRc+F+C57FYacKgAEOU6w To: "pwe3" X-Spam-Score: 0.3 (/) X-Scan-Signature: 4ad60914b71abd47c285b3604f8c8304 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org This is a multi-part message in MIME format. --===============0440003388== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C519BE.EFEDAE8F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C519BE.EFEDAE8F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha,=20 =20 Since the emails have become unwieldly, I will just snip the parts I want to discuss. =20 ---------------------------------------------------------------- [Sasha] Sorry, but I do not think this answers my question: if subjected to=20 the test I have proposed, shall the AAL2 mode of TDMoIP pass it, or shall it not?=20 =20 Of course it does for channelized TDM. The AAL2 mechanism couldn't care what is in the channels. However, based on the channel content you can add advanced features. =20 ---------------------------------------------------------------- [Sasha] The PW de-capsulator should not, IMHO, assume that the tunnel label has been popped (or has not been popped) as this may vary. But presumably it could inspect the entrire label stack to find the bottom label and the CW. =20 =20 In my opinion the PW IWF MUST assume that all tunnel labels have been removed. Otherwise we have a clear layer violation. =20 ---------------------------------------------------------------- [Sasha] IMHO (we should ask the authors) this is why the lower-case "must" is used in this fragment, while the IETF capitalized MUST states that the LEN field is set if the size of the payload + the size of the CW is <=3D 63 bytes (and hence is potentially, but not necessarily, paddable).=20 =20 Look at the HDLC draft. There it is a MUST not a must. So I doubt that there is deep meaning to this lack of capitalization. Authors ?? =20 [Sasha] The TDM PWs (at least ones using fixed size payload) can do with MAY instead of MUST. =20 That means only SAToP, since all the others have exceptions to the rule. =20 ---------------------------------------------------------------- [Sasha] The following is a quote from the latest FR encap draft (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-04.txt) : 7.7.2. Processing of the Length Field by the Receiver Any padding octet, if present, in the payload field of a PW packet received MUST be removed before forwarding the data. - If the Length field is set to zero then there are no padding Characters following the payload field. - Else if the payload is longer then the length specified in the control word padding characters are removed based on the length field. It does not say anything about the packet itslef being short or long, just "if the LEN field is set, trust it". I also would prefer treating the case described here as a malformed packet, and reported this to the list. But the authors of the draft presumably do not think so.=20 =20 As I said in a separate email, I believe the handling of padding in the FR draft (and in X.84 version) is incorrect.=20 The padding should NOT be a function of the PW IWF (once again a layer violation). Also, we don't see similarly wording in the other drafts. =20 In any case, this wording says something else too - if there is a zero length field, then there is no padding! We find this same wording in all the drafts -=20 if the entire packet needs padding, then there MUST=20 So if this is authoritative, it goes against your thesis. =20 Y(J)S =20 =20 =20 ------_=_NextPart_001_01C519BE.EFEDAE8F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sasha,=20

Since=20 the emails have become unwieldly, I will just snip the = parts

I want=20 to discuss.

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

[Sasha] Sorry, but I do=20 not think this answers my question: if subjected to

the=20 test I have proposed, shall the AAL2 mode of TDMoIP pass it, or shall it = not?

Of=20 course it does for=20 channelized TDM.

The=20 AAL2 mechanism couldn't care what is in the=20 channels.<= /DIV>

However, based on the channel content you can = add=20 advanced=20 features.<= /DIV>

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

[Sasha] The=20 PW de-capsulator should not, IMHO, assume that the tunnel label has = been
popped (or has = not been=20 popped) as this may vary. But presumably it could inspect the=20 entrire

label stack = to find the=20 bottom label and the CW. <= /SPAN>

=

In my opinion the PW IWF MUST = assume that all=20 tunnel=20 labels

have been removed. Otherwise we have a clear = layer=20 violation.=
=

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

[Sasha] IMHO (we = should ask the=20 authors) this is why the lower-case "must"=20 is<= /FONT>

used in this = fragment, while=20 the IETF capitalized MUST states that the=20 LEN=

field is set = if the size of=20 the payload + the size of the CW is <=3D 63=20 bytes<= /DIV>
(and hence=20 is potentially, but not necessarily, paddable).

=

Look at the HDLC draft. = There it is=20 a MUST not a=20 must.

So I doubt=20 that there is deep meaning to this lack of=20 capitalization.
Authors=20 ??<= /FONT>

<= /SPAN>

[Sasha] The TDM PWs (at least = ones using=20 fixed size payload)=20 can do=20 with

MAY instead of MUST.
That means only SAToP, = since all=20 the others have exceptions to the=20 rule.

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

[Sasha] The following is a quote from the = latest FR=20 encap draft

(http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-04= .txt):

<quote>

7.7.2. Processing of the Length Field by the = Receiver

  =20 Any padding octet, if present, in the payload field of a PW=20 packet
   received MUST be removed before forwarding the=20 data.
     - If the Length field is set to zero = then=20 there are no padding
       Characters=20 following the payload field.
     - Else if the = payload=20 is longer then the length specified in=20 the
       control word padding = characters are=20 removed based on the length
      =20 field.

<end=20 quote>

It does not say anything about the packet = itslef being=20 short or long, just = "if the LEN field is set, trust=20 it".

I also = would prefer=20 treating the case described here as a malformed packet, and reported = this to the=20 list. But the authors of the draft presumably do not think so.

As I said = in a separate=20 email, I believe the handling of=20 padding

in the = FR draft (and=20 in X.84 version) is incorrect.=20

The = padding should NOT=20 be a function of=20 the PW = IWF (once again=20 a layer=20 violation).

Also, we = don't see=20 similarly wording in the other=20 drafts.

In any = case,=20 this wording says=20 something<= /SPAN>

else too - if = there is a=20 zero length field, then there is no=20 padding!

We find this = same wording in=20 all the drafts -=20
if the entire = packet needs=20 padding, then there MUST=20
So if this is = authoritative,=20 it goes against your=20 thesis.

Y(J)S

------_=_NextPart_001_01C519BE.EFEDAE8F-- --===============0440003388== 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 --===============0440003388==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Sasha Vainshtein Subject: RE: FW: AD review of draft-ietf-pwe3-cw-01.txt - comment 5 Date: Wed, 23 Feb 2005 12:18:19 +0200 Lines: 1591 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2012829540==" Cc: Maximilian.Riegel@icn.siemens.de, "PWE3 WG $E-mail$" , Alik Shimelmits , Ron Insler , Ronen Shaashoua , stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Feb 24 06:15:04 2005 To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.2 (/) X-Scan-Signature: 3b020e0f057e453d607c237c778eab5c 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.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. --===============2012829540== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51990.FF1999A0" 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_01C51990.FF1999A0 Content-Type: text/plain; charset="ISO-8859-8" Yaakov, Please see more inline (bold purple this time). Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 -----Original Message----- From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Wednesday, February 23, 2005 11:59 AM To: Sasha Vainshtein Cc: pwe3@ietf.com; stbryant@cisco.com; Alik Shimelmits; Maximilian.Riegel@icn.siemens.de; Ronen Shaashoua; Ron Insler Subject: RE: FW: [PWE3] AD review of draft-ietf-pwe3-cw-01.txt - comment 5 Sasha, Since the emails have become unwieldly, I will just snip the parts I want to discuss. ---------------------------------------------------------------- [Sasha] Sorry, but I do not think this answers my question: if subjected to the test I have proposed, shall the AAL2 mode of TDMoIP pass it, or shall it not? Of course it does for channelized TDM. The AAL2 mechanism couldn't care what is in the channels. However, based on the channel content you can add advanced features. [Sasha] I do on understand your reference to "Channelized TDM". Do you mean that if you run HDLC over a bundle of timeslots (not a separate HDLC flow per TS!) and pass this bundle through a PW using the AAL2 mode of TDMoIP, HDLC would still be OK at the other side of the PW? ---------------------------------------------------------------- [Sasha] The PW de-capsulator should not, IMHO, assume that the tunnel label has been popped (or has not been popped) as this may vary. But presumably it could inspect the entrire label stack to find the bottom label and the CW. In my opinion the PW IWF MUST assume that all tunnel labels have been removed. Otherwise we have a clear layer violation. [Sasha] IMHO this is an implementation issue, the PW IWF simply must know where the PW part (after the PW label) starts and how many bytes it spans. And as far as layer violations are concerned, I'd say that the IWF should not be interested in the PW label as well - it is only required for demultiplexing, not for interworking. ---------------------------------------------------------------- [Sasha] IMHO (we should ask the authors) this is why the lower-case "must" is used in this fragment, while the IETF capitalized MUST states that the LEN field is set if the size of the payload + the size of the CW is <= 63 bytes (and hence is potentially, but not necessarily, paddable). Look at the HDLC draft. There it is a MUST not a must. So I doubt that there is deep meaning to this lack of capitalization. Authors ?? [Sasha] I can only join your call to the authors and suggest that these issues should be preferably written once (say, in the CW draft?) and not replicated with variations in each encapsulation draft... And as for looking at the HDLC/PPP draft, it has expired. I hope it has been re-posted with the latest bunch of the WG drafts and slowly makes its way through the pre-meeting I-D jam. [Sasha] The TDM PWs (at least ones using fixed size payload) can do with MAY instead of MUST. That means only SAToP, since all the others have exceptions to the rule. [Sasha] Trunk-specific NxDS0 with CAS in CESoPSN can use the FRG bits to define if the signaling structure has been added or not. And AAL1 mode of TDMoIP can use the "multiples of 48" rule. But I believe that we are converging here. ---------------------------------------------------------------- [Sasha] The following is a quote from the latest FR encap draft ( http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-04.txt ): 7.7.2. Processing of the Length Field by the Receiver Any padding octet, if present, in the payload field of a PW packet received MUST be removed before forwarding the data. - If the Length field is set to zero then there are no padding Characters following the payload field. - Else if the payload is longer then the length specified in the control word padding characters are removed based on the length field. It does not say anything about the packet itslef being short or long, just "if the LEN field is set, trust it". I also would prefer treating the case described here as a malformed packet, and reported this to the list. But the authors of the draft presumably do not think so. As I said in a separate email, I believe the handling of padding in the FR draft (and in X.84 version) is incorrect. The padding should NOT be a function of the PW IWF (once again a layer violation). [Sasha] I agree that padding is not the PW IWF function. But please note that I was quoting the latest FR draft where padding has been removed by Luca. Also, we don't see similarly wording in the other drafts. [Sasha] Which ones? With the HDLC draft expired, this only leaves AAL5 mode of the ATM draft. And it is conveniently silent wrt the LEN field processing. In any case, this wording says something else too - if there is a zero length field, then there is no padding! We find this same wording in all the drafts - if the entire packet needs padding, then there MUST So if this is authoritative, it goes against your thesis. [Sasha] Bearing in mind my previous comment on "the other drafts", I'd say that this is a common bug. Y(J)S ------_=_NextPart_001_01C51990.FF1999A0 Content-Type: text/html; charset="ISO-8859-8" Content-Transfer-Encoding: quoted-printable
Yaakov,

Please=20 see more inline (bold purple this=20 time).

Regards,

          &nb= sp;           &nb= sp;          =20 Sasha Vainshtein

email:         &nb= sp;           &nb= sp;  =20 sasha@axerra.com

phone:         &nb= sp;           &nb= sp;=20 +972-3-7569993 (office)

fax:          = ;            = ;     =20 +972-3-6487779

mobile:         &n= bsp;           &n= bsp;+972-52-8674833=20

-----Original Message-----
From: Yaakov Stein=20 [mailto:yaakov_s@rad.com]
Sent: Wednesday, February 23, = 2005 11:59=20 AM
To: Sasha Vainshtein
Cc: pwe3@ietf.com;=20 stbryant@cisco.com; Alik Shimelmits; = Maximilian.Riegel@icn.siemens.de; Ronen=20 Shaashoua; Ron Insler
Subject: RE: FW: [PWE3] AD review of=20 draft-ietf-pwe3-cw-01.txt - comment 5

Sasha,

Since the emails have become unwieldly, I will just snip the = parts

I=20 want to discuss.

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

[Sasha]  Sorry, but I=20 do not think this answers my question: if subjected to <= /FONT>

the test I have proposed, shall the AAL2 = mode of=20 TDMoIP pass it, or shall it not? <= /FONT>

Of course = it does for=20 = channelized TDM.

The AAL2 = mechanism=20 couldn't care what is in the=20 = channels.=

However, based on the channel content you can add advanced=20 features.

[Sasha] I do on understand = your=20 reference to "Channelized=20 = TDM".
Do you mean that if you run HDLC = over a=20 bundle=20 = of timeslots

(not a separate HDLC flow per TS!) = = and pass this bundle=20 =

through a PW using = the AAL2 mode of=20 TDMoIP,=20

HDLC would=20 = still be OK at the other side = of the=20 = PW?

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

[Sasha]  The=20 PW de-capsulator should not, IMHO, assume that the tunnel label = has=20 = been=

popped (or = has not been=20 popped) as this may vary. But presumably it could inspect the=20 = entrire

label stack to find the bottom label and the CW.

In my = opinion the PW IWF MUST assume that all tunnel=20 = labels
have = been removed.=20 Otherwise we have a clear layer=20 = violation.<= /DIV>
[Sasha] IMHO this is an = implementation=20 issue, the PW=20 = IWF

simply must know where the PW part = (after the=20 PW label)=20 = starts<= /SPAN>

and how many bytes it spans. And = as far as=20 layer violations=20 = are

concerned, I'd say that the IWF = should not be=20 interested in the=20 = PW=

label as well - it is only = required for=20 demultiplexing, not for=20 = interworking.<= /SPAN>

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

[Sasha]  = IMHO (we = should ask the=20 authors) this is why the lower-case "must"=20 = is=
used in = this fragment,=20 while the IETF capitalized MUST states that the=20 = LEN<= /DIV>
field is = set if the size=20 of the payload + the size of the CW is <=3D 63=20 = bytes

(and hence is potentially, but not necessarily,=20 paddable). <= /SPAN>

Look = at the HDLC=20 draft. There it is a MUST not a=20 = must.
=
So I doubt that there is deep meaning to = this lack of=20 = capitalization.<= /SPAN>
Authors ??

[Sasha] I can only join your = call to the=20 authors and suggest that=20 = these<= /SPAN>

issues should be preferably = written once=20 (say, in the CW draft?) and=20 = not<= /FONT>

replicated with variations in each = encapsulation draft...=20 = =

And as for looking at the HDLC/PPP = = = draft, it has expired. I hope it = has=20 = been=

re-posted with the latest bunch of = the WG=20 drafts and slowly makes its=20 = way<= /FONT>

through the pre-meeting I-D=20 = jam.=

[Sasha] = The TDM PWs=20 (at least ones using fixed size payload)=20 = can do=20 with

MAY instead of=20 MUST.
That means only SAToP, since all the others have exceptions = to the=20 rule.

[Sasha] Trunk-specific NxDS0 = with CAS in=20 CESoPSN can use the FRG=20 = bits=

= to define if the signaling structure has been = added or=20 not. And AAL1=20 mode

of TDMoIP = can use the=20 "multiples of 48" rule. But I believe that we are=20 converging

here. =

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

[Sasha] = The following=20 is a quote from the latest FR encap=20 draft

(http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-= 04.txt):

<quote>

7.7.2. Processing of the Length Field = by the=20 Receiver

   Any padding octet, if present, in the = payload=20 field of a PW packet
   received MUST be removed before=20 forwarding the data.
     - If the Length = field is set=20 to zero then there are no = padding
      =20 Characters following the payload field.
     - = Else if=20 the payload is longer then the length specified in=20 the
       control word padding = characters=20 are removed based on the = length
      =20 field.

<end=20 quote>

It does = not say=20 anything about the packet itslef being short or long, just=20 "if the LEN field is set, trust=20 it".

I also would prefer treating the case described here as a = malformed=20 packet, and reported this to the list. But the authors of the draft = presumably=20 do not think so. <= /FONT>

As I said in a separate email, I = believe the=20 handling of=20 = padding

in the FR draft (and = in X.84=20 version) is incorrect.=20 =

The padding should = NOT be a=20 function of=20 = the=20 PW IWF (once again a layer violation).

[Sasha] I agree that padding = is not the=20 PW IWF function. But please note=20 = that=

I was quoting the latest FR draft where padding = has been=20 removed by=20 = Luca.

Also, we don't see similarly wording = in the=20 other=20 = drafts.

[Sasha] Which ones? With the = HDLC=20 draft expired, this only leaves AAL5 mode of the ATM=20 = draft.<= /SPAN>=

And it is conveniently silent = wrt the=20 LEN field=20 = processing.=

In any case, = this wording=20 says=20 = something=

else too - if there is a zero length = field, then=20 there is no=20 = padding!<= /SPAN>

We find this same wording in all the = drafts -=20 =
if the entire packet needs padding, then = there MUST=20 =
So if this is authoritative, it goes = against your=20 thesis.

[Sasha] Bearing in mind my = previous=20 comment on "the other drafts", I'd say that this is a common=20 = bug.=

Y(J)S

------_=_NextPart_001_01C51990.FF1999A0-- --===============2012829540== 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 --===============2012829540==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Shahram Davari Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Wed, 23 Feb 2005 06:45:09 -0800 Lines: 19 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 24 06:58:58 2005 To: "'Luca Martini'" , Mustapha Aissaoui X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Luca, > >Luca, > >However, it all appears that if the label withdraw PW status > method is used, > >then a label is withdrawn if say a AIS cell is received from > the local ATM > >network or LMI indicated a fault. Am I wrong? > > > > > > > yes. This is correct, then the remote end would re-generate > the AIS alarm. > How does the other end know whether this is an administrative withdrwal for removing the service (in which case it should not generate AIS) or it is a withdrawal caused by a fault (in which case it should generate AIS)? -Shahram From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Mustapha Aissaoui" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Wed, 23 Feb 2005 10:09:07 -0500 Lines: 36 References: <4B6D09F3B826D411A67300D0B706EFDE0115D48F@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 24 07:01:06 2005 To: "'Shahram Davari'" , "'Luca Martini'" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <4B6D09F3B826D411A67300D0B706EFDE0115D48F@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-index: AcUZtk01NnK6W/S9RG6LJbkyR/Sz8AAAwsgA X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Shahram, This is why I asked that we should only withdraw the label when the AC is administrativley DOWN when the label withdraw method is used. Operational status should be updated by AIS/RDI which gets passed transparently if the label is not whithdrawn. Mustapha. -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, February 23, 2005 9:45 AM To: 'Luca Martini'; Mustapha Aissaoui Cc: neil.2.harrison@bt.com; pwe3@ietf.org Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to PW st atus. Luca, > >Luca, > >However, it all appears that if the label withdraw PW status > method is used, > >then a label is withdrawn if say a AIS cell is received from > the local ATM > >network or LMI indicated a fault. Am I wrong? > > > > > > > yes. This is correct, then the remote end would re-generate the AIS > alarm. > How does the other end know whether this is an administrative withdrwal for removing the service (in which case it should not generate AIS) or it is a withdrawal caused by a fault (in which case it should generate AIS)? -Shahram From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: neil.2.harrison@bt.com Subject: RE: Control protocol draft - section 5.3.1 change to PWst atus. Date: Thu, 24 Feb 2005 08:42:35 -0000 Lines: 78 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 24 09:40:13 2005 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] Control protocol draft - section 5.3.1 change to PWst atus. Thread-Index: AcUZtk01NnK6W/S9RG6LJbkyR/Sz8AAAwsgAACR9GNA= To: , , X-OriginalArrivalTime: 24 Feb 2005 08:42:35.0940 (UTC) FILETIME=[CA09BE40:01C51A4C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Mutatapha...It is not correct or acceptable to simply focus on one facet here (ie OAM) of a client/server layer network relationship. The clear requirement is simply this: A client layer network (all planes) should be transported tranparently over any server layer network. I do not think is useful to simply home-in on the OAM aspects only....and even then just the 'always-on' defect detection/handling OAM, as there is also 'on-demand' OAM, eg PM probes, diagnostics. Note - One has to accept that in the past not all layer networks have been functionally well-specified. However, this is no reason or excuse to continue this problem into next generation networks. Sadly I think we are some way of achieving this (and in fact some things are getting worse not better IMO), and speaking as an operator I am not happy this is the case....esp when its rather obvious IMO what is required to do things correctly, based on knowldege gained over many years and by using formal network modelling techniques like functional architecture. regards, Neil > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Mustapha Aissaoui > Sent: 23 February 2005 15:09 > To: 'Shahram Davari'; 'Luca Martini' > Cc: Harrison,N,Neil,IKM1 R; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to PWst atus. >=20 >=20 > Shahram, > This is why I asked that we should only withdraw the label=20 > when the AC is administrativley DOWN when the label withdraw=20 > method is used. Operational status should be updated by=20 > AIS/RDI which gets passed transparently if the label is not=20 > whithdrawn. >=20 > Mustapha. >=20 > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, February 23, 2005 9:45 AM > To: 'Luca Martini'; Mustapha Aissaoui > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to PW st atus. >=20 > Luca, >=20 > > >Luca, > > >However, it all appears that if the label withdraw PW status > > method is used, > > >then a label is withdrawn if say a AIS cell is received from > > the local ATM > > >network or LMI indicated a fault. Am I wrong? > > > > > > > > > > > yes. This is correct, then the remote end would re-generate the AIS=20 > > alarm. > > >=20 > How does the other end know whether this is an administrative=20 > withdrwal for removing the service (in which case it should=20 > not generate AIS) or it is a withdrawal caused by a fault (in=20 > which case it should generate AIS)? >=20 > -Shahram >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Kulkarni, Hrishikesh (Hrishikesh)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 14:34:29 +0530 Lines: 70 Mime-Version: 1.0 Content-Type: text/plain Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 24 10:05:21 2005 To: "'Mustapha Aissaoui'" , "'Shahram Davari'" , "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Mustapha, The problem of when multiple AC are going through a singe N:1 PWE3 remains unsolved. if we withdraw the label when one AC is admin down, what about other AC. Rishi > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of > Mustapha Aissaoui > Sent: Wednesday, February 23, 2005 8:39 PM > To: 'Shahram Davari'; 'Luca Martini' > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Shahram, > This is why I asked that we should only withdraw the label > when the AC is > administrativley DOWN when the label withdraw method is used. > Operational > status should be updated by AIS/RDI which gets passed > transparently if the > label is not whithdrawn. > > Mustapha. > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, February 23, 2005 9:45 AM > To: 'Luca Martini'; Mustapha Aissaoui > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW st > atus. > > Luca, > > > >Luca, > > >However, it all appears that if the label withdraw PW status > > method is used, > > >then a label is withdrawn if say a AIS cell is received from > > the local ATM > > >network or LMI indicated a fault. Am I wrong? > > > > > > > > > > > yes. This is correct, then the remote end would re-generate the AIS > > alarm. > > > > How does the other end know whether this is an administrative > withdrwal for > removing the service (in which case it should not generate > AIS) or it is a > withdrawal caused by a fault (in which case it should generate AIS)? > > -Shahram > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "David Allan" Subject: RESEND RE: Control protocol draft - section 5.3.1 change t o PW status. Date: Thu, 24 Feb 2005 07:33:41 -0500 Lines: 244 Cc: "'neil.2.harrison@bt.com'" , "'pwe3@ietf.org'" X-From: pwe3-bounces@ietf.org Thu Feb 24 13:31:50 2005 To: "David Allan" , "'Luca Martini'" , "'Mustapha Aissaoui'" X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 4.3 (++++) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org I've never been happy with label withdraw, esp. when either AIS or RDI termination at a PE is indicative of an AC fault and if not ignored, withdrawl on RDI will ultimately lock down the PW (as withdrawl escalates all faults to AIS at the far AC). I would agree with Mustapha's concerns, backwards compatibility with somthing that is broken is not really a good idea. cheers Dave > > >Luca, > > >However, it all appears that if the label withdraw PW status > > method is > > >used, then a label is withdrawn if say a AIS cell is > > received from the > > >local ATM network or LMI indicated a fault. Am I wrong? > > > > > > > > > > > yes. This is correct, then the remote end would re-generate > > the AIS alarm. > > > > >Also, how should we interpret the new text? Initially, you > advertize > > >the label regardless of the state of AC. Then, if the PW status > > >negotiation results in the use of the label withdraw PW > > status method, > > >would you immediately withdraw the label because the AC is > > not active? > > > > > > > > > > > That would be my understanding. Some state needs to be kept > > for this PW, > > for the life of the LDP session, to indicate that the PW uses label > > withdraw method. > > > > > > >I would like to see a simplification to the procedures. The > > reason why > > >label withdrawal is to be avoided as much as possible is because it > > >confuses a fault condition with an adiministrative > > operation. We do not > > >want to have the network react to some unstable CPE or L2 network > > >condition. > > > > > > > > > > > For this reason we have PW status TLV infrastructure. > > Remember that this > > is a MUST implement, therefore this is what is going to be > > used by ALL > > PWE3 implementations. > > > > >I suggest that regardless of the PW status method used, a label is > > >withdrawan only if the user configures the AC administrative > > state to > > >DOWN. Any other fault condition should raise an alarm to the > > management > > >system but should not cause a label withdrawal. > > > > > > > > > > > This would break any status notification. > > The intent is not to break current deployments. After all > > they must be > > working fine with just the label withdraw method. > > Whether this text is there or not , the implementations will > > implement > > label withdraw anyway. We all agree that if there is no label > > advertisement the PW is down. > > That is the main point. > > Why are you so keen in disabling the backward compatibility ? > > I would like this standard to be implemented, not the old > > draft-martini. > > > > Luca > > > > >Mustapha. > > > > > >-----Original Message----- > > >From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On Behalf Of > > >Luca Martini > > >Sent: Friday, February 18, 2005 10:45 AM > > >To: neil.2.harrison@bt.com > > >Cc: pwe3@ietf.org > > >Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > > change to PW > > >status. > > > > > >neil.2.harrison@bt.com wrote: > > > > > > > > > > > >>Luca asked: Please let me know if you have any comments > about this > > >>text. > > >> > > >>Question: Is there is any inference in this text (or > other text in > > >>this draft, or in any other draft for that matter) that a > > PW must be > > >>taken down in response to a failure on an AC? If there is > > then its wrong. > > >> > > >> > > >> > > >> > > >In the new PW status design, described here , the PW is not "taken > > >down ", but instead attachment circuit status is > communicated to the > > >remote end of the PW. So the answer is no. Example ATM AIS > > alarm. The > > >AIS OAM cells will be passed along the PW , additionally a > PW status > > >TLV "interface Receive Fault" will also be transmitted in > > the control > > >protocol. > > > > > >Luca > > > > > > > > > > > >>One should NEVER take down a server layer trail in response to a > > >>defect > > >>in some client layer link connection. Just think if we did > > this for > > >>all nested layer networks right down to optics! > > >> > > >>regards, Neil > > >> > > >> > > >> > > >> > > >> > > >>>-----Original Message----- > > >>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > > On Behalf > > >>>Of Luca Martini > > >>>Sent: 17 February 2005 23:35 > > >>>To: PWE3 WG (E-mail) > > >>>Subject: [PWE3] Control protocol draft - section 5.3.1 > > change to PW > > >>>status. > > >>> > > >>> > > >>>In this section , we were asked to make the implementation > > of the PW > > >>>status messages/TLV mandatory. > > >>>Also all "CE-facing port" terminology will be changed to > > "attachment > > >>>circuit". > > >>> > > >>>5.3.1. Use of Label Mappings. > > >>> > > >>> The PEs MUST send PW label mapping messages to their > > peers as soon > > >>>as > > >>> the PW is configured and administratively enabled, > regardless of > > >>>the > > >>> CE-facing interface state. The PW label should not be withdrawn > > >>> unless the user administratively configures the > > CE-facing interface > > >>> down (or the PW configuration is deleted entirely). Using the > > >>> procedures outlined in this section a simple label > > withdraw method > > >>> MAY also be supported as a primitive means of signaling > > PW status. > > >>>It > > >>> is strongly RECOMMENDED that the PW status signaling procedures > > >>>below > > >>> be fully implemented. In any case if the Label mapping is not > > >>> available the PW MUST be considered in the down state. > > >>> > > >>>will change to: > > >>> > > >>>5.3.1. Use of Label Mappings. > > >>>The PEs MUST send PW label mapping messages to their peers > > as soon as > > >>>the PW is configured and administratively enabled, > > regardless of the > > >>>attachment circuit state. The PW label should not be > > withdrawn unless > > >>>the user administratively configures the CE-facing > > interface down (or > > >>>the PW configuration is deleted entirely). Using the procedures > > >>>outlined in this section a simple label withdraw method > > MUST also be > > >>>supported as a primitive means of signaling PW status. In > > any case if > > >>>the Label mapping is not available the PW MUST be > > considered in the > > >>>down state. > > >>> > > >>>Once, the PW status negotiation procedures are completed > > and if they > > >>>result in the use of the label withdraw method for PW status > > >>>communication, the label withdraw PW status method MUST be > > used. This > > >>>will result in the PW label mapping message being > > advertised only if > > >>>the attachment circuit becomes active. The PW status signaling > > >>>procedures described in this section MUST be fully implemented. > > >>> > > >>> > > >>>Please let me know if you have any comments about this text. Luca > > >>> > > >>>_______________________________________________ > > >>>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 > > >> > > >> > > >> > > >> > > >> > > > > > >_______________________________________________ > > >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 27 15:58:25 2006 From: "Mustapha Aissaoui" Subject: RE: Control protocol draft - section 5.3.1 change to PWst atus. Date: Thu, 24 Feb 2005 09:55:26 -0500 Lines: 102 References: <0536FC9B908BEC4597EE721BE6A353890A9F195A@i2km07-ukbr.domain1.systemhost.net> Cc: lmartini@cisco.com, Shahram_Davari@pmc-sierra.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 24 15:54:01 2005 To: X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <0536FC9B908BEC4597EE721BE6A353890A9F195A@i2km07-ukbr.domain1.systemhost.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-index: AcUZtk01NnK6W/S9RG6LJbkyR/Sz8AAAwsgAACR9GNAADQlqkA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Neil, it is understood that other ATM OAM capabilities are carried transparently over the server layer. This is clearly described in draft-ietf-pwe3-oam-msg-map-02.txt. However, I do not think that such a general requirement can easily be met with all client layer technologies. For example, FR OAM (FRF.19) has been specified late in the game anf there has not been much deployment out there. Therefore, in the above draft, we allow the translation of FR PVC status into either PW status signaling or into BFD status. This is just a pragmatic approach to deal with some of the realities of the existing link layer techonologies. Regards, Mustapha. -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Thursday, February 24, 2005 3:43 AM To: Mustapha.Aissaoui@alcatel.com; Shahram_Davari@pmc-sierra.com; lmartini@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to PWst atus. Mutatapha...It is not correct or acceptable to simply focus on one facet here (ie OAM) of a client/server layer network relationship. The clear requirement is simply this: A client layer network (all planes) should be transported tranparently over any server layer network. I do not think is useful to simply home-in on the OAM aspects only....and even then just the 'always-on' defect detection/handling OAM, as there is also 'on-demand' OAM, eg PM probes, diagnostics. Note - One has to accept that in the past not all layer networks have been functionally well-specified. However, this is no reason or excuse to continue this problem into next generation networks. Sadly I think we are some way of achieving this (and in fact some things are getting worse not better IMO), and speaking as an operator I am not happy this is the case....esp when its rather obvious IMO what is required to do things correctly, based on knowldege gained over many years and by using formal network modelling techniques like functional architecture. regards, Neil > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of Mustapha Aissaoui > Sent: 23 February 2005 15:09 > To: 'Shahram Davari'; 'Luca Martini' > Cc: Harrison,N,Neil,IKM1 R; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to > PWst atus. > > > Shahram, > This is why I asked that we should only withdraw the label when the AC > is administrativley DOWN when the label withdraw method is used. > Operational status should be updated by AIS/RDI which gets passed > transparently if the label is not whithdrawn. > > Mustapha. > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, February 23, 2005 9:45 AM > To: 'Luca Martini'; Mustapha Aissaoui > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to > PW st atus. > > Luca, > > > >Luca, > > >However, it all appears that if the label withdraw PW status > > method is used, > > >then a label is withdrawn if say a AIS cell is received from > > the local ATM > > >network or LMI indicated a fault. Am I wrong? > > > > > > > > > > > yes. This is correct, then the remote end would re-generate the AIS > > alarm. > > > > How does the other end know whether this is an administrative > withdrwal for removing the service (in which case it should not > generate AIS) or it is a withdrawal caused by a fault (in which case > it should generate AIS)? > > -Shahram > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Mustapha Aissaoui" Subject: RE: Control protocol draft - section 5.3.1 change to PW status. Date: Thu, 24 Feb 2005 10:01:28 -0500 Lines: 88 References: <6733C768256DEC42A72BAFEFA9CF06D20B4918E8@ii0015exch002u.iprc.lucent.com> Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 24 16:01:48 2005 To: "'Kulkarni, Hrishikesh $Hrishikesh$'" , "'Shahram Davari'" , "'Luca Martini'" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <6733C768256DEC42A72BAFEFA9CF06D20B4918E8@ii0015exch002u.iprc.lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-index: AcUaUAon8Np6M512TvyiIsJJD/0J7QAMOvUA X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Rishi, I am not sure you have read my response to your message last week. I was telling you the case of N:1 VC-to-PW is hypthetical. The current ATM draft only deals with a single VC per PW when using the N:1 cell mode encapsulation encapsulation. In other words, the ATM VC and the ATM PW are peers. The server layer is the PSN tunnel. Now, if one wants to implement a true N:1 VC-to-PW, then the PW becomes a server layer to the ATM VCs. The PW is pre-established and is used as a tunnel. In that case, you will not withdraw the PW label in response to administrative or operational state of the individual ATM VCs. Mustapha. -----Original Message----- From: Kulkarni, Hrishikesh (Hrishikesh) [mailto:hkulkarni@lucent.com] Sent: Thursday, February 24, 2005 4:04 AM To: 'Mustapha Aissaoui'; 'Shahram Davari'; 'Luca Martini' Cc: neil.2.harrison@bt.com; pwe3@ietf.org Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to PW status. Mustapha, The problem of when multiple AC are going through a singe N:1 PWE3 remains unsolved. if we withdraw the label when one AC is admin down, what about other AC. Rishi > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of > Mustapha Aissaoui > Sent: Wednesday, February 23, 2005 8:39 PM > To: 'Shahram Davari'; 'Luca Martini' > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to > PW st atus. > > > Shahram, > This is why I asked that we should only withdraw the label when the AC > is administrativley DOWN when the label withdraw method is used. > Operational > status should be updated by AIS/RDI which gets passed transparently if > the label is not whithdrawn. > > Mustapha. > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, February 23, 2005 9:45 AM > To: 'Luca Martini'; Mustapha Aissaoui > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to > PW st atus. > > Luca, > > > >Luca, > > >However, it all appears that if the label withdraw PW status > > method is used, > > >then a label is withdrawn if say a AIS cell is received from > > the local ATM > > >network or LMI indicated a fault. Am I wrong? > > > > > > > > > > > yes. This is correct, then the remote end would re-generate the AIS > > alarm. > > > > How does the other end know whether this is an administrative > withdrwal for removing the service (in which case it should not > generate > AIS) or it is a > withdrawal caused by a fault (in which case it should generate AIS)? > > -Shahram > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Shah, Himanshu" Subject: RE: PWE3 @ IETF62 provisional agenda Date: Thu, 24 Feb 2005 10:48:22 -0500 Lines: 92 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Thu Feb 24 16:46:53 2005 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 @ IETF62 provisional agenda Thread-Index: AcUaKwuI9zhVPYSQRrqpW21skwrKzgAXRK/w To: "Stewart Bryant" , "pwe3" X-OriginalArrivalTime: 24 Feb 2005 15:48:23.0449 (UTC) FILETIME=[458A4090:01C51A88] X-Spam-Score: 2.0 (++) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org I requested a timeslot for PW QOS signaling yesterday. Sorry for the late notice. Hope you can add me in. thanks, himanshu > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of > Stewart Bryant > Sent: Tuesday, February 22, 2005 6:10 AM > To: pwe3 > Subject: [PWE3] PWE3 @ IETF62 provisional agenda >=20 >=20 > Here is the first cut of the PWE3 agenda for IETF62. >=20 > Have I missed anthing, anything else that needs to be raised? >=20 > As usual, please can Danny and I have the slides before the > meeting. >=20 > Thanks >=20 > Stewart >=20 > Pseudo Wire Emulation Edge to Edge (pwe3) > = =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 >=20 > WEDNESDAY, March 9, 2005, (1530-1730) >=20 > CHAIR: "Danny McPherson" > "Stewart Bryant" >=20 > AGENDA: >=20 > Administrivia > Chairs (Stewart & Danny) > Agenda Bashing > Minutes > Blue Sheets >=20 > WG Document Status > Danny McPherson > Stewart Bryant >=20 > Pseudowire Setup and Maintenance using LDP and Ethernet over MPLS > Luca Martini > draft-ietf-pwe3-control-protocol-15.txt > draft-ietf-pwe3-ethernet-encap-09.txt > Restructure of drafts folloing AD review >=20 > Frame Relay over Pseudo-Wires > Luca Martini > draft-ietf-pwe3-frame-relay-04.txt > Update on the rewrite >=20 > PW Control Word > Stewart Bryant > > Resolve any outstanding comments >=20 > Requirements for inter domain Pseudo-Wires > Nabil Bitar > draft-martini-pwe3-MH-PW-requirements-00.txt >=20 > Multi-hop Pseudowire Setup and Maintenance using LDP > David McDysan&Florin Balus > > Discuss new LDP extensions, end to end signaling > procedures to address the related requirements specified > in the MH-PWE3 Requirements draft. The procedures described > in the draft enable the usage of addressing schemes (L2FECs) > and other TLVs already defined for PWs in PW Control >=20 > PWE3 Applications & OAM Scenarios > Simon Delord > draft-delord-pwe3-oam-applications-00.txt > Introduction to Key Issues >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: neil.2.harrison@bt.com Subject: RE: Control protocol draft - section 5.3.1 change to PWst atus. Date: Thu, 24 Feb 2005 15:48:20 -0000 Lines: 156 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: lmartini@cisco.com, Shahram_Davari@pmc-sierra.com, pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 24 16:47:29 2005 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] Control protocol draft - section 5.3.1 change to PWst atus. Thread-Index: AcUZtk01NnK6W/S9RG6LJbkyR/Sz8AAAwsgAACR9GNAADQlqkAABphXg To: X-OriginalArrivalTime: 24 Feb 2005 15:48:20.0779 (UTC) FILETIME=[43F2D7B0:01C51A88] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Mutahpha...please see below. > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com]=20 > Sent: 24 February 2005 14:55 > To: Harrison,N,Neil,IKM1 R > Cc: pwe3@ietf.org; Shahram_Davari@pmc-sierra.com; lmartini@cisco.com > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to PWst atus. >=20 >=20 > Neil, > it is understood that other ATM OAM capabilities are carried=20 > transparently over the server layer. This is clearly=20 > described in draft-ietf-pwe3-oam-msg-map-02.txt. NH=3D> Transparency is a general requirement of any XoverY. This ought = to be a non-issue. Why on earth folks decided to start compressing clients (and in so many ways in some cases) is quite beyond me. Have you ever looked at the load points at which real networks run, and understood why this is so? BW squeezing is not a key requirement....avoiding complexity and layer violations is however.=20 >=20 > However, I do not think that such a general requirement can=20 > easily be met with all client layer technologies. NH=3D> This was precisely my point below. BUT, we should not use this = as an excuse to continue to get it wrong. > For=20 > example, FR OAM (FRF.19) has been specified late in the game=20 NH=3D> And largely by the vendor community....sound familiar? > and there has not been much deployment out there. NH=3D> Don't you think MPLS was also rather 'late in the game' at doing anything about OAM?..despite multiple efforts by BT to get folks looking at this stuff several years ago. And I'd still like to know where all the defect cases are specified in terms of entry/exit criteria and consequent actions....inc stuff like the still open issue on persistent Seq No abberation. Can you tell me when this is going to be addressed please?=20 > Therefore,=20 > in the above draft, we allow the translation of FR PVC status=20 > into either PW status signaling or into BFD status. > This is just a pragmatic approach to deal with some of the realities=20 > of the existing link layer techonologies. NH=3D> They are NOT link layer technologies.....these are proper layer networks (despite how poorly specified some are). If you want to talk about section layer technologies that is different, ie stuff that is not networked and sits right at the bottom of the stack, eg optical, electrical line codes on Tx media. regards, Neil =20 >=20 > Regards, > Mustapha. >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Thursday, February 24, 2005 3:43 AM > To: Mustapha.Aissaoui@alcatel.com;=20 > Shahram_Davari@pmc-sierra.com; lmartini@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to PWst atus. >=20 > Mutatapha...It is not correct or acceptable to simply focus=20 > on one facet here (ie OAM) of a client/server layer network=20 > relationship. The clear requirement is simply this: >=20 > A client layer network (all planes) should be=20 > transported tranparently over any server layer network. >=20 > I do not think is useful to simply home-in on the OAM aspects=20 > only....and even then just the 'always-on' defect=20 > detection/handling OAM, as there is also 'on-demand' OAM, eg=20 > PM probes, diagnostics. >=20 > Note - One has to accept that in the past not all layer=20 > networks have been functionally well-specified. However,=20 > this is no reason or excuse to continue this problem into=20 > next generation networks. Sadly I think we are some way of=20 > achieving this (and in fact some things are getting worse not=20 > better IMO), and speaking as an operator I am not happy this=20 > is the case....esp when its rather obvious IMO what is=20 > required to do things correctly, based on knowldege gained=20 > over many years and by using formal network modelling=20 > techniques like functional architecture. >=20 > regards, Neil >=20 > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]=20 > On Behalf=20 > > Of Mustapha Aissaoui > > Sent: 23 February 2005 15:09 > > To: 'Shahram Davari'; 'Luca Martini' > > Cc: Harrison,N,Neil,IKM1 R; pwe3@ietf.org > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to=20 > > PWst atus. > > > > > > Shahram, > > This is why I asked that we should only withdraw the label=20 > when the AC=20 > > is administrativley DOWN when the label withdraw method is used.=20 > > Operational status should be updated by AIS/RDI which gets passed=20 > > transparently if the label is not whithdrawn. > > > > Mustapha. > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, February 23, 2005 9:45 AM > > To: 'Luca Martini'; Mustapha Aissaoui > > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to=20 > > PW st atus. > > > > Luca, > > > > > >Luca, > > > >However, it all appears that if the label withdraw PW status > > > method is used, > > > >then a label is withdrawn if say a AIS cell is received from > > > the local ATM > > > >network or LMI indicated a fault. Am I wrong? > > > > > > > > > > > > > > > yes. This is correct, then the remote end would=20 > re-generate the AIS=20 > > > alarm. > > > > > > > How does the other end know whether this is an administrative=20 > > withdrwal for removing the service (in which case it should not=20 > > generate AIS) or it is a withdrawal caused by a fault (in=20 > which case=20 > > it should generate AIS)? > > > > -Shahram > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Thomas D. Nadeau" Subject: Re: RESEND RE: Control protocol draft - section 5.3.1 change t o PW status. Date: Thu, 24 Feb 2005 10:53:43 -0500 Lines: 263 References: <87AC5F88F03E6249AEA68D40BD3E00BE03192D68@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" , "'neil.2.harrison@bt.com'" , 'Luca Martini' , 'Mustapha Aissaoui' X-From: pwe3-bounces@ietf.org Thu Feb 24 16:50:44 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE03192D68@zcarhxm2.corp.nortel.com> To: "David Allan" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org > I've never been happy with label withdraw, esp. when either > AIS or RDI termination at a PE is indicative of an AC fault > and if not ignored, withdrawl on RDI will ultimately lock > down the PW (as withdrawl escalates all faults to AIS at the far AC). > > I would agree with Mustapha's concerns, backwards > compatibility with somthing that is broken is not really a good idea. I have to disagree and agree with Luca's original assertion. There are too many deployments in the field that are working just fine to disallow this as an option going forward. Ultimately folks may choose to not configure this behavior once all of the status signaling is implemented, but we should not preclude those that are working today and want to keep with what they have. --Tom > > cheers > Dave > >>>> Luca, >>>> However, it all appears that if the label withdraw PW status >>> method is >>>> used, then a label is withdrawn if say a AIS cell is >>> received from the >>>> local ATM network or LMI indicated a fault. Am I wrong? >>>> >>>> >>>> >>> yes. This is correct, then the remote end would re-generate >>> the AIS alarm. >>> >>>> Also, how should we interpret the new text? Initially, you >> advertize >>>> the label regardless of the state of AC. Then, if the PW status >>>> negotiation results in the use of the label withdraw PW >>> status method, >>>> would you immediately withdraw the label because the AC is >>> not active? >>>> >>>> >>>> >>> That would be my understanding. Some state needs to be kept >>> for this PW, >>> for the life of the LDP session, to indicate that the PW uses label >>> withdraw method. >>> >>> >>>> I would like to see a simplification to the procedures. The >>> reason why >>>> label withdrawal is to be avoided as much as possible is because it >>>> confuses a fault condition with an adiministrative >>> operation. We do not >>>> want to have the network react to some unstable CPE or L2 network >>>> condition. >>>> >>>> >>>> >>> For this reason we have PW status TLV infrastructure. >>> Remember that this >>> is a MUST implement, therefore this is what is going to be >>> used by ALL >>> PWE3 implementations. >>> >>>> I suggest that regardless of the PW status method used, a label is >>>> withdrawan only if the user configures the AC administrative >>> state to >>>> DOWN. Any other fault condition should raise an alarm to the >>> management >>>> system but should not cause a label withdrawal. >>>> >>>> >>>> >>> This would break any status notification. >>> The intent is not to break current deployments. After all >>> they must be >>> working fine with just the label withdraw method. >>> Whether this text is there or not , the implementations will >>> implement >>> label withdraw anyway. We all agree that if there is no label >>> advertisement the PW is down. >>> That is the main point. >>> Why are you so keen in disabling the backward compatibility ? >>> I would like this standard to be implemented, not the old >>> draft-martini. >>> >>> Luca >>> >>>> Mustapha. >>>> >>>> -----Original Message----- >>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>> On Behalf Of >>>> Luca Martini >>>> Sent: Friday, February 18, 2005 10:45 AM >>>> To: neil.2.harrison@bt.com >>>> Cc: pwe3@ietf.org >>>> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>> change to PW >>>> status. >>>> >>>> neil.2.harrison@bt.com wrote: >>>> >>>> >>>> >>>>> Luca asked: Please let me know if you have any comments >> about this >>>>> text. >>>>> >>>>> Question: Is there is any inference in this text (or >> other text in >>>>> this draft, or in any other draft for that matter) that a >>> PW must be >>>>> taken down in response to a failure on an AC? If there is >>> then its wrong. >>>>> >>>>> >>>>> >>>>> >>>> In the new PW status design, described here , the PW is not "taken >>>> down ", but instead attachment circuit status is >> communicated to the >>>> remote end of the PW. So the answer is no. Example ATM AIS >>> alarm. The >>>> AIS OAM cells will be passed along the PW , additionally a >> PW status >>>> TLV "interface Receive Fault" will also be transmitted in >>> the control >>>> protocol. >>>> >>>> Luca >>>> >>>> >>>> >>>>> One should NEVER take down a server layer trail in response to a >>>>> defect >>>>> in some client layer link connection. Just think if we did >>> this for >>>>> all nested layer networks right down to optics! >>>>> >>>>> regards, Neil >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>> On Behalf >>>>>> Of Luca Martini >>>>>> Sent: 17 February 2005 23:35 >>>>>> To: PWE3 WG (E-mail) >>>>>> Subject: [PWE3] Control protocol draft - section 5.3.1 >>> change to PW >>>>>> status. >>>>>> >>>>>> >>>>>> In this section , we were asked to make the implementation >>> of the PW >>>>>> status messages/TLV mandatory. >>>>>> Also all "CE-facing port" terminology will be changed to >>> "attachment >>>>>> circuit". >>>>>> >>>>>> 5.3.1. Use of Label Mappings. >>>>>> >>>>>> The PEs MUST send PW label mapping messages to their >>> peers as soon >>>>>> as >>>>>> the PW is configured and administratively enabled, >> regardless of >>>>>> the >>>>>> CE-facing interface state. The PW label should not be withdrawn >>>>>> unless the user administratively configures the >>> CE-facing interface >>>>>> down (or the PW configuration is deleted entirely). Using the >>>>>> procedures outlined in this section a simple label >>> withdraw method >>>>>> MAY also be supported as a primitive means of signaling >>> PW status. >>>>>> It >>>>>> is strongly RECOMMENDED that the PW status signaling procedures >>>>>> below >>>>>> be fully implemented. In any case if the Label mapping is not >>>>>> available the PW MUST be considered in the down state. >>>>>> >>>>>> will change to: >>>>>> >>>>>> 5.3.1. Use of Label Mappings. >>>>>> The PEs MUST send PW label mapping messages to their peers >>> as soon as >>>>>> the PW is configured and administratively enabled, >>> regardless of the >>>>>> attachment circuit state. The PW label should not be >>> withdrawn unless >>>>>> the user administratively configures the CE-facing >>> interface down (or >>>>>> the PW configuration is deleted entirely). Using the procedures >>>>>> outlined in this section a simple label withdraw method >>> MUST also be >>>>>> supported as a primitive means of signaling PW status. In >>> any case if >>>>>> the Label mapping is not available the PW MUST be >>> considered in the >>>>>> down state. >>>>>> >>>>>> Once, the PW status negotiation procedures are completed >>> and if they >>>>>> result in the use of the label withdraw method for PW status >>>>>> communication, the label withdraw PW status method MUST be >>> used. This >>>>>> will result in the PW label mapping message being >>> advertised only if >>>>>> the attachment circuit becomes active. The PW status signaling >>>>>> procedures described in this section MUST be fully implemented. >>>>>> >>>>>> >>>>>> Please let me know if you have any comments about this text. Luca >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: neil.2.harrison@bt.com Subject: RE: Control protocol draft - section 5.3.1 change to PW status. Date: Thu, 24 Feb 2005 16:05:14 -0000 Lines: 129 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 24 17:06:14 2005 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] Control protocol draft - section 5.3.1 change to PW status. Thread-Index: AcUaUAon8Np6M512TvyiIsJJD/0J7QAMOvUAAAIPt4A= To: , , , X-OriginalArrivalTime: 24 Feb 2005 16:05:15.0265 (UTC) FILETIME=[A0A11F10:01C51A8A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Mustapha, Mustapha Aissaoui wrote 24 February 2005 15:01 >=20 > Rishi, > I am not sure you have read my response to your message last=20 > week. I was telling you the case of N:1 VC-to-PW is=20 > hypthetical. The current ATM draft only deals with a single=20 > VC per PW when using the N:1 cell mode encapsulation=20 > encapsulation. In other words, the ATM VC and the ATM PW are=20 > peers. NH=3D> This is incorrect. There are 2 MPLS LSPs. The top level LSP is not there for any primary considerations of 'hierarchy' it is a FORCED p2p construct to make sure there is demerging from any lower mp2p constructs. Note also that in a proper client/server case there is only a requirement for a single server layer construct, no matter how many clients are muxed into it, eg 63 VC_12 clients into a single server VC_4 in SDH say. However, it is still a server layer construct wrt to the (in this case) ATM client. There are NOT in any way peers. Note - if they were to be considered as peers, you would also have to have (for example) signaling protocol conversion between the partitions. In general however, peer-partition i/w is not a good idea...one has some chance for technologies belonging to the same network mode, but almost no chance for technologies belonging to differenmt modes (because of the function/feature mismatch). > The server layer is the PSN tunnel. NH=3D> Not strictly correct. The 'PSN tunnel' is a server construct to the higher LSP entity. However, the 2 LSPs are NOT seperate layer networks.....not sure if you get this, ring me if not clear....though you could check out MPLS func arch in G.8110. Final point. A SH-PW was not a layer network. It was an adaptation function between X and MPLS (or IP). MH-PWs are now changing this, ie a new layer network is now being created in all but name. regards, Neil >=20 > Now, if one wants to implement a true N:1 VC-to-PW, then the=20 > PW becomes a server layer to the ATM VCs. The PW is=20 > pre-established and is used as a tunnel. In that case, you=20 > will not withdraw the PW label in response to administrative=20 > or operational state of the individual ATM VCs. >=20 > Mustapha. >=20 > -----Original Message----- > From: Kulkarni, Hrishikesh (Hrishikesh) [mailto:hkulkarni@lucent.com] > Sent: Thursday, February 24, 2005 4:04 AM > To: 'Mustapha Aissaoui'; 'Shahram Davari'; 'Luca Martini' > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to PW status. >=20 > Mustapha, >=20 > The problem of when multiple AC are going through a singe N:1=20 > PWE3 remains unsolved. if we withdraw the label when one AC=20 > is admin down, what about other AC. >=20 > Rishi >=20 >=20 > > -----Original Message----- > > From: pwe3-bounces@ietf.org=20 > [mailto:pwe3-bounces@ietf.org]On Behalf Of=20 > > Mustapha Aissaoui > > Sent: Wednesday, February 23, 2005 8:39 PM > > To: 'Shahram Davari'; 'Luca Martini' > > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to=20 > > PW st atus. > > > > > > Shahram, > > This is why I asked that we should only withdraw the label=20 > when the AC=20 > > is administrativley DOWN when the label withdraw method is used.=20 > > Operational status should be updated by AIS/RDI which gets passed=20 > > transparently if the label is not whithdrawn. > > > > Mustapha. > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, February 23, 2005 9:45 AM > > To: 'Luca Martini'; Mustapha Aissaoui > > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to=20 > > PW st atus. > > > > Luca, > > > > > >Luca, > > > >However, it all appears that if the label withdraw PW status > > > method is used, > > > >then a label is withdrawn if say a AIS cell is received from > > > the local ATM > > > >network or LMI indicated a fault. Am I wrong? > > > > > > > > > > > > > > > yes. This is correct, then the remote end would=20 > re-generate the AIS=20 > > > alarm. > > > > > > > How does the other end know whether this is an administrative=20 > > withdrwal for removing the service (in which case it should not=20 > > generate > > AIS) or it is a > > withdrawal caused by a fault (in which case it should generate AIS)? > > > > -Shahram > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Mustapha Aissaoui" Subject: RE: RESEND RE: Control protocol draft - section 5.3.1 change to PW status. Date: Thu, 24 Feb 2005 11:07:15 -0500 Lines: 282 References: <5e72e148f343d0a9a81b089ca45f0c77@cisco.com> Cc: neil.2.harrison@bt.com, pwe3@ietf.org, 'Luca Martini' X-From: pwe3-bounces@ietf.org Thu Feb 24 17:08:33 2005 To: "'Thomas D. Nadeau'" , "'David Allan'" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <5e72e148f343d0a9a81b089ca45f0c77@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-index: AcUaiZTYfe9SJPk7TmWA5nWUGQz0HgAAMSkQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Tom, I am not not suggesting to remove the label withdrawal method. My suggestion is to withdraw a label when the AC's administrative status is DOWN but not when its operational status is DOWN. In the latter case, keeping the label will allow the transparent tunneling of received or locally generate AIS/RDI over the PW to the remote PE. Mustapha. -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Thursday, February 24, 2005 10:54 AM To: David Allan Cc: 'pwe3@ietf.org'; 'neil.2.harrison@bt.com'; 'Luca Martini'; 'Mustapha Aissaoui' Subject: Re: RESEND RE: [PWE3] Control protocol draft - section 5.3.1 change to PW status. > I've never been happy with label withdraw, esp. when either AIS or > RDI termination at a PE is indicative of an AC fault and if not > ignored, withdrawl on RDI will ultimately lock down the PW (as > withdrawl escalates all faults to AIS at the far AC). > > I would agree with Mustapha's concerns, backwards compatibility with > somthing that is broken is not really a good idea. I have to disagree and agree with Luca's original assertion. There are too many deployments in the field that are working just fine to disallow this as an option going forward. Ultimately folks may choose to not configure this behavior once all of the status signaling is implemented, but we should not preclude those that are working today and want to keep with what they have. --Tom > > cheers > Dave > >>>> Luca, >>>> However, it all appears that if the label withdraw PW status >>> method is >>>> used, then a label is withdrawn if say a AIS cell is >>> received from the >>>> local ATM network or LMI indicated a fault. Am I wrong? >>>> >>>> >>>> >>> yes. This is correct, then the remote end would re-generate the AIS >>> alarm. >>> >>>> Also, how should we interpret the new text? Initially, you >> advertize >>>> the label regardless of the state of AC. Then, if the PW status >>>> negotiation results in the use of the label withdraw PW >>> status method, >>>> would you immediately withdraw the label because the AC is >>> not active? >>>> >>>> >>>> >>> That would be my understanding. Some state needs to be kept for this >>> PW, for the life of the LDP session, to indicate that the PW uses >>> label withdraw method. >>> >>> >>>> I would like to see a simplification to the procedures. The >>> reason why >>>> label withdrawal is to be avoided as much as possible is because it >>>> confuses a fault condition with an adiministrative >>> operation. We do not >>>> want to have the network react to some unstable CPE or L2 network >>>> condition. >>>> >>>> >>>> >>> For this reason we have PW status TLV infrastructure. >>> Remember that this >>> is a MUST implement, therefore this is what is going to be used by >>> ALL >>> PWE3 implementations. >>> >>>> I suggest that regardless of the PW status method used, a label is >>>> withdrawan only if the user configures the AC administrative >>> state to >>>> DOWN. Any other fault condition should raise an alarm to the >>> management >>>> system but should not cause a label withdrawal. >>>> >>>> >>>> >>> This would break any status notification. >>> The intent is not to break current deployments. After all they must >>> be working fine with just the label withdraw method. >>> Whether this text is there or not , the implementations will >>> implement label withdraw anyway. We all agree that if there is no >>> label advertisement the PW is down. >>> That is the main point. >>> Why are you so keen in disabling the backward compatibility ? >>> I would like this standard to be implemented, not the old >>> draft-martini. >>> >>> Luca >>> >>>> Mustapha. >>>> >>>> -----Original Message----- >>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>> On Behalf Of >>>> Luca Martini >>>> Sent: Friday, February 18, 2005 10:45 AM >>>> To: neil.2.harrison@bt.com >>>> Cc: pwe3@ietf.org >>>> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>> change to PW >>>> status. >>>> >>>> neil.2.harrison@bt.com wrote: >>>> >>>> >>>> >>>>> Luca asked: Please let me know if you have any comments >> about this >>>>> text. >>>>> >>>>> Question: Is there is any inference in this text (or >> other text in >>>>> this draft, or in any other draft for that matter) that a >>> PW must be >>>>> taken down in response to a failure on an AC? If there is >>> then its wrong. >>>>> >>>>> >>>>> >>>>> >>>> In the new PW status design, described here , the PW is not "taken >>>> down ", but instead attachment circuit status is >> communicated to the >>>> remote end of the PW. So the answer is no. Example ATM AIS >>> alarm. The >>>> AIS OAM cells will be passed along the PW , additionally a >> PW status >>>> TLV "interface Receive Fault" will also be transmitted in >>> the control >>>> protocol. >>>> >>>> Luca >>>> >>>> >>>> >>>>> One should NEVER take down a server layer trail in response to a >>>>> defect in some client layer link connection. Just think if we did >>> this for >>>>> all nested layer networks right down to optics! >>>>> >>>>> regards, Neil >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>> On Behalf >>>>>> Of Luca Martini >>>>>> Sent: 17 February 2005 23:35 >>>>>> To: PWE3 WG (E-mail) >>>>>> Subject: [PWE3] Control protocol draft - section 5.3.1 >>> change to PW >>>>>> status. >>>>>> >>>>>> >>>>>> In this section , we were asked to make the implementation >>> of the PW >>>>>> status messages/TLV mandatory. >>>>>> Also all "CE-facing port" terminology will be changed to >>> "attachment >>>>>> circuit". >>>>>> >>>>>> 5.3.1. Use of Label Mappings. >>>>>> >>>>>> The PEs MUST send PW label mapping messages to their >>> peers as soon >>>>>> as >>>>>> the PW is configured and administratively enabled, >> regardless of >>>>>> the >>>>>> CE-facing interface state. The PW label should not be withdrawn >>>>>> unless the user administratively configures the >>> CE-facing interface >>>>>> down (or the PW configuration is deleted entirely). Using the >>>>>> procedures outlined in this section a simple label >>> withdraw method >>>>>> MAY also be supported as a primitive means of signaling >>> PW status. >>>>>> It >>>>>> is strongly RECOMMENDED that the PW status signaling procedures >>>>>> below be fully implemented. In any case if the Label mapping is >>>>>> not available the PW MUST be considered in the down state. >>>>>> >>>>>> will change to: >>>>>> >>>>>> 5.3.1. Use of Label Mappings. >>>>>> The PEs MUST send PW label mapping messages to their peers >>> as soon as >>>>>> the PW is configured and administratively enabled, >>> regardless of the >>>>>> attachment circuit state. The PW label should not be >>> withdrawn unless >>>>>> the user administratively configures the CE-facing >>> interface down (or >>>>>> the PW configuration is deleted entirely). Using the procedures >>>>>> outlined in this section a simple label withdraw method >>> MUST also be >>>>>> supported as a primitive means of signaling PW status. In >>> any case if >>>>>> the Label mapping is not available the PW MUST be >>> considered in the >>>>>> down state. >>>>>> >>>>>> Once, the PW status negotiation procedures are completed >>> and if they >>>>>> result in the use of the label withdraw method for PW status >>>>>> communication, the label withdraw PW status method MUST be >>> used. This >>>>>> will result in the PW label mapping message being >>> advertised only if >>>>>> the attachment circuit becomes active. The PW status signaling >>>>>> procedures described in this section MUST be fully implemented. >>>>>> >>>>>> >>>>>> Please let me know if you have any comments about this text. Luca >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > > _______________________________________________ > 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 27 15:58:25 2006 From: neil.2.harrison@bt.com Subject: RE: RESEND RE: Control protocol draft - section 5.3.1 change t o PW status. Date: Thu, 24 Feb 2005 16:18:00 -0000 Lines: 302 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, lmartini@cisco.com, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 17:16:00 2005 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message Thread-Topic: RESEND RE: [PWE3] Control protocol draft - section 5.3.1 change t o PW status. Thread-Index: AcUaiQzoXhr2Sr4sTEeWidUGujZbNgAAr6wA To: , X-OriginalArrivalTime: 24 Feb 2005 16:18:01.0194 (UTC) FILETIME=[69289CA0:01C51A8C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Tom...IMO this statement does nothing to help IETFs stature as a body producing standards operators can confidently rely on. Simply being backwards compatible with already implemented stuff (as a direct consequence of 'rough consensus and running code') that is obviously not correct is no excuse. Your argument boils down to saying ' we won't do anything about it until its proved broken' is not acceptable IMO....esp when it obviously not right in the 1st place. Just look at what happened with OAM. 2+ years ago I can recall being clearly told this was not required....then operational experience showed otherwise....now its too late to properly get the base protocol structures/net-arch right...so we are required (no choice) to accept more fixes. It really is not good enough IMO. regards, neil > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]=20 > Sent: 24 February 2005 15:54 > To: David Allan > Cc: 'Mustapha Aissaoui'; 'Luca Martini'; Harrison,N,Neil,IKM1=20 > R; 'pwe3@ietf.org' > Subject: Re: RESEND RE: [PWE3] Control protocol draft -=20 > section 5.3.1 change t o PW status. >=20 >=20 >=20 >=20 > > I've never been happy with label withdraw, esp. when=20 > either AIS or=20 > > RDI termination at a PE is indicative of an AC fault and if not=20 > > ignored, withdrawl on RDI will ultimately lock down the PW (as=20 > > withdrawl escalates all faults to AIS at the far AC). > > > > I would agree with Mustapha's concerns, backwards =20 > compatibility with=20 > > somthing that is broken is not really a good idea. >=20 > I have to disagree and agree with Luca's original=20 > assertion. There are too many deployments in the field that=20 > are working just fine to disallow this as an option going=20 > forward. Ultimately folks may choose to not configure this=20 > behavior once all of the status signaling is implemented, but=20 > we should not preclude those that are working today and want=20 > to keep with what they have. >=20 > --Tom >=20 >=20 >=20 >=20 > > > > cheers > > Dave > > > >>>> Luca, > >>>> However, it all appears that if the label withdraw PW status > >>> method is > >>>> used, then a label is withdrawn if say a AIS cell is > >>> received from the > >>>> local ATM network or LMI indicated a fault. Am I wrong? > >>>> > >>>> > >>>> > >>> yes. This is correct, then the remote end would=20 > re-generate the AIS=20 > >>> alarm. > >>> > >>>> Also, how should we interpret the new text? Initially, you > >> advertize > >>>> the label regardless of the state of AC. Then, if the PW status=20 > >>>> negotiation results in the use of the label withdraw PW > >>> status method, > >>>> would you immediately withdraw the label because the AC is > >>> not active? > >>>> > >>>> > >>>> > >>> That would be my understanding. Some state needs to be=20 > kept for this=20 > >>> PW, for the life of the LDP session, to indicate that the PW uses=20 > >>> label withdraw method. > >>> > >>> > >>>> I would like to see a simplification to the procedures. The > >>> reason why > >>>> label withdrawal is to be avoided as much as possible is=20 > because it=20 > >>>> confuses a fault condition with an adiministrative > >>> operation. We do not > >>>> want to have the network react to some unstable CPE or=20 > L2 network=20 > >>>> condition. > >>>> > >>>> > >>>> > >>> For this reason we have PW status TLV infrastructure.=20 > Remember that=20 > >>> this is a MUST implement, therefore this is what is going to be > >>> used by ALL > >>> PWE3 implementations. > >>> > >>>> I suggest that regardless of the PW status method used,=20 > a label is=20 > >>>> withdrawan only if the user configures the AC administrative > >>> state to > >>>> DOWN. Any other fault condition should raise an alarm to the > >>> management > >>>> system but should not cause a label withdrawal. > >>>> > >>>> > >>>> > >>> This would break any status notification. > >>> The intent is not to break current deployments. After all=20 > they must=20 > >>> be working fine with just the label withdraw method. > >>> Whether this text is there or not , the implementations will > >>> implement > >>> label withdraw anyway. We all agree that if there is no label > >>> advertisement the PW is down. > >>> That is the main point. > >>> Why are you so keen in disabling the backward compatibility ? > >>> I would like this standard to be implemented, not the old > >>> draft-martini. > >>> > >>> Luca > >>> > >>>> Mustapha. > >>>> > >>>> -----Original Message----- > >>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>> On Behalf Of > >>>> Luca Martini > >>>> Sent: Friday, February 18, 2005 10:45 AM > >>>> To: neil.2.harrison@bt.com > >>>> Cc: pwe3@ietf.org > >>>> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > >>> change to PW > >>>> status. > >>>> > >>>> neil.2.harrison@bt.com wrote: > >>>> > >>>> > >>>> > >>>>> Luca asked: Please let me know if you have any comments > >> about this > >>>>> text. > >>>>> > >>>>> Question: Is there is any inference in this text (or > >> other text in > >>>>> this draft, or in any other draft for that matter) that a > >>> PW must be > >>>>> taken down in response to a failure on an AC? If there is > >>> then its wrong. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> In the new PW status design, described here , the PW is=20 > not "taken=20 > >>>> down ", but instead attachment circuit status is > >> communicated to the > >>>> remote end of the PW. So the answer is no. Example ATM AIS > >>> alarm. The > >>>> AIS OAM cells will be passed along the PW , additionally a > >> PW status > >>>> TLV "interface Receive Fault" will also be transmitted in > >>> the control > >>>> protocol. > >>>> > >>>> Luca > >>>> > >>>> > >>>> > >>>>> One should NEVER take down a server layer trail in=20 > response to a=20 > >>>>> defect in some client layer link connection. Just=20 > think if we did > >>> this for > >>>>> all nested layer networks right down to optics! > >>>>> > >>>>> regards, Neil > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>> On Behalf > >>>>>> Of Luca Martini > >>>>>> Sent: 17 February 2005 23:35 > >>>>>> To: PWE3 WG (E-mail) > >>>>>> Subject: [PWE3] Control protocol draft - section 5.3.1 > >>> change to PW > >>>>>> status. > >>>>>> > >>>>>> > >>>>>> In this section , we were asked to make the implementation > >>> of the PW > >>>>>> status messages/TLV mandatory. > >>>>>> Also all "CE-facing port" terminology will be changed to > >>> "attachment > >>>>>> circuit". > >>>>>> > >>>>>> 5.3.1. Use of Label Mappings. > >>>>>> > >>>>>> The PEs MUST send PW label mapping messages to their > >>> peers as soon > >>>>>> as > >>>>>> the PW is configured and administratively enabled, > >> regardless of > >>>>>> the > >>>>>> CE-facing interface state. The PW label should not be=20 > withdrawn =20 > >>>>>> unless the user administratively configures the > >>> CE-facing interface > >>>>>> down (or the PW configuration is deleted entirely). Using the=20 > >>>>>> procedures outlined in this section a simple label > >>> withdraw method > >>>>>> MAY also be supported as a primitive means of signaling > >>> PW status. > >>>>>> It > >>>>>> is strongly RECOMMENDED that the PW status signaling=20 > procedures=20 > >>>>>> below be fully implemented. In any case if the Label=20 > mapping is=20 > >>>>>> not available the PW MUST be considered in the down state. > >>>>>> > >>>>>> will change to: > >>>>>> > >>>>>> 5.3.1. Use of Label Mappings. > >>>>>> The PEs MUST send PW label mapping messages to their peers > >>> as soon as > >>>>>> the PW is configured and administratively enabled, > >>> regardless of the > >>>>>> attachment circuit state. The PW label should not be > >>> withdrawn unless > >>>>>> the user administratively configures the CE-facing > >>> interface down (or > >>>>>> the PW configuration is deleted entirely). Using the=20 > procedures=20 > >>>>>> outlined in this section a simple label withdraw method > >>> MUST also be > >>>>>> supported as a primitive means of signaling PW status. In > >>> any case if > >>>>>> the Label mapping is not available the PW MUST be > >>> considered in the > >>>>>> down state. > >>>>>> > >>>>>> Once, the PW status negotiation procedures are completed > >>> and if they > >>>>>> result in the use of the label withdraw method for PW status=20 > >>>>>> communication, the label withdraw PW status method MUST be > >>> used. This > >>>>>> will result in the PW label mapping message being > >>> advertised only if > >>>>>> the attachment circuit becomes active. The PW status signaling=20 > >>>>>> procedures described in this section MUST be fully implemented. > >>>>>> > >>>>>> > >>>>>> Please let me know if you have any comments about this=20 > text. Luca > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > >> > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Shahram Davari Subject: RE: RESEND RE: Control protocol draft - section 5.3.1 chan ge t o PW status. Date: Thu, 24 Feb 2005 08:22:51 -0800 Lines: 296 Mime-Version: 1.0 Content-Type: text/plain Cc: "'neil.2.harrison@bt.com'" , "'pwe3@ietf.org'" , 'Mustapha Aissaoui' , 'Luca Martini' X-From: pwe3-bounces@ietf.org Thu Feb 24 17:20:32 2005 To: "'Thomas D. Nadeau'" , David Allan X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org If a rather broken feature is not in the RFC, it doesn't mean it is disallowed. specially when such feature doesn't need any codepoint, or IANA assignment. Those that feel they would have competitive advantage could still implement and sell it. I think it is time for IETF to consider architectural principles that could ensure simplicity and future reuse of its standards, rather than short term kludges. -Shahram > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of > Thomas D. Nadeau > Sent: Thursday, February 24, 2005 10:54 AM > To: David Allan > Cc: 'pwe3@ietf.org'; 'neil.2.harrison@bt.com'; 'Luca > Martini'; 'Mustapha > Aissaoui' > Subject: Re: RESEND RE: [PWE3] Control protocol draft - section 5.3.1 > change t o PW status. > > > > > > I've never been happy with label withdraw, esp. when either > > AIS or RDI termination at a PE is indicative of an AC fault > > and if not ignored, withdrawl on RDI will ultimately lock > > down the PW (as withdrawl escalates all faults to AIS at > the far AC). > > > > I would agree with Mustapha's concerns, backwards > > compatibility with somthing that is broken is not really a > good idea. > > I have to disagree and agree with Luca's original assertion. > There are too many deployments in the field that are working > just fine to disallow this as an option going forward. Ultimately > folks may choose to not configure this behavior once all of the > status signaling is implemented, but we should not preclude > those that are working today and want to keep with what they have. > > --Tom > > > > > > > > cheers > > Dave > > > >>>> Luca, > >>>> However, it all appears that if the label withdraw PW status > >>> method is > >>>> used, then a label is withdrawn if say a AIS cell is > >>> received from the > >>>> local ATM network or LMI indicated a fault. Am I wrong? > >>>> > >>>> > >>>> > >>> yes. This is correct, then the remote end would re-generate > >>> the AIS alarm. > >>> > >>>> Also, how should we interpret the new text? Initially, you > >> advertize > >>>> the label regardless of the state of AC. Then, if the PW status > >>>> negotiation results in the use of the label withdraw PW > >>> status method, > >>>> would you immediately withdraw the label because the AC is > >>> not active? > >>>> > >>>> > >>>> > >>> That would be my understanding. Some state needs to be kept > >>> for this PW, > >>> for the life of the LDP session, to indicate that the PW > uses label > >>> withdraw method. > >>> > >>> > >>>> I would like to see a simplification to the procedures. The > >>> reason why > >>>> label withdrawal is to be avoided as much as possible is > because it > >>>> confuses a fault condition with an adiministrative > >>> operation. We do not > >>>> want to have the network react to some unstable CPE or L2 network > >>>> condition. > >>>> > >>>> > >>>> > >>> For this reason we have PW status TLV infrastructure. > >>> Remember that this > >>> is a MUST implement, therefore this is what is going to be > >>> used by ALL > >>> PWE3 implementations. > >>> > >>>> I suggest that regardless of the PW status method used, > a label is > >>>> withdrawan only if the user configures the AC administrative > >>> state to > >>>> DOWN. Any other fault condition should raise an alarm to the > >>> management > >>>> system but should not cause a label withdrawal. > >>>> > >>>> > >>>> > >>> This would break any status notification. > >>> The intent is not to break current deployments. After all > >>> they must be > >>> working fine with just the label withdraw method. > >>> Whether this text is there or not , the implementations will > >>> implement > >>> label withdraw anyway. We all agree that if there is no label > >>> advertisement the PW is down. > >>> That is the main point. > >>> Why are you so keen in disabling the backward compatibility ? > >>> I would like this standard to be implemented, not the old > >>> draft-martini. > >>> > >>> Luca > >>> > >>>> Mustapha. > >>>> > >>>> -----Original Message----- > >>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>> On Behalf Of > >>>> Luca Martini > >>>> Sent: Friday, February 18, 2005 10:45 AM > >>>> To: neil.2.harrison@bt.com > >>>> Cc: pwe3@ietf.org > >>>> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > >>> change to PW > >>>> status. > >>>> > >>>> neil.2.harrison@bt.com wrote: > >>>> > >>>> > >>>> > >>>>> Luca asked: Please let me know if you have any comments > >> about this > >>>>> text. > >>>>> > >>>>> Question: Is there is any inference in this text (or > >> other text in > >>>>> this draft, or in any other draft for that matter) that a > >>> PW must be > >>>>> taken down in response to a failure on an AC? If there is > >>> then its wrong. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> In the new PW status design, described here , the PW is > not "taken > >>>> down ", but instead attachment circuit status is > >> communicated to the > >>>> remote end of the PW. So the answer is no. Example ATM AIS > >>> alarm. The > >>>> AIS OAM cells will be passed along the PW , additionally a > >> PW status > >>>> TLV "interface Receive Fault" will also be transmitted in > >>> the control > >>>> protocol. > >>>> > >>>> Luca > >>>> > >>>> > >>>> > >>>>> One should NEVER take down a server layer trail in response to a > >>>>> defect > >>>>> in some client layer link connection. Just think if we did > >>> this for > >>>>> all nested layer networks right down to optics! > >>>>> > >>>>> regards, Neil > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>> On Behalf > >>>>>> Of Luca Martini > >>>>>> Sent: 17 February 2005 23:35 > >>>>>> To: PWE3 WG (E-mail) > >>>>>> Subject: [PWE3] Control protocol draft - section 5.3.1 > >>> change to PW > >>>>>> status. > >>>>>> > >>>>>> > >>>>>> In this section , we were asked to make the implementation > >>> of the PW > >>>>>> status messages/TLV mandatory. > >>>>>> Also all "CE-facing port" terminology will be changed to > >>> "attachment > >>>>>> circuit". > >>>>>> > >>>>>> 5.3.1. Use of Label Mappings. > >>>>>> > >>>>>> The PEs MUST send PW label mapping messages to their > >>> peers as soon > >>>>>> as > >>>>>> the PW is configured and administratively enabled, > >> regardless of > >>>>>> the > >>>>>> CE-facing interface state. The PW label should not be > withdrawn > >>>>>> unless the user administratively configures the > >>> CE-facing interface > >>>>>> down (or the PW configuration is deleted entirely). Using the > >>>>>> procedures outlined in this section a simple label > >>> withdraw method > >>>>>> MAY also be supported as a primitive means of signaling > >>> PW status. > >>>>>> It > >>>>>> is strongly RECOMMENDED that the PW status signaling > procedures > >>>>>> below > >>>>>> be fully implemented. In any case if the Label mapping is not > >>>>>> available the PW MUST be considered in the down state. > >>>>>> > >>>>>> will change to: > >>>>>> > >>>>>> 5.3.1. Use of Label Mappings. > >>>>>> The PEs MUST send PW label mapping messages to their peers > >>> as soon as > >>>>>> the PW is configured and administratively enabled, > >>> regardless of the > >>>>>> attachment circuit state. The PW label should not be > >>> withdrawn unless > >>>>>> the user administratively configures the CE-facing > >>> interface down (or > >>>>>> the PW configuration is deleted entirely). Using the procedures > >>>>>> outlined in this section a simple label withdraw method > >>> MUST also be > >>>>>> supported as a primitive means of signaling PW status. In > >>> any case if > >>>>>> the Label mapping is not available the PW MUST be > >>> considered in the > >>>>>> down state. > >>>>>> > >>>>>> Once, the PW status negotiation procedures are completed > >>> and if they > >>>>>> result in the use of the label withdraw method for PW status > >>>>>> communication, the label withdraw PW status method MUST be > >>> used. This > >>>>>> will result in the PW label mapping message being > >>> advertised only if > >>>>>> the attachment circuit becomes active. The PW status signaling > >>>>>> procedures described in this section MUST be fully implemented. > >>>>>> > >>>>>> > >>>>>> Please let me know if you have any comments about this > text. Luca > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > >> > > > > _______________________________________________ > > 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 27 15:58:25 2006 From: "Thomas D. Nadeau" Subject: Re: RESEND RE: Control protocol draft - section 5.3.1 chan ge t o PW status. Date: Thu, 24 Feb 2005 11:42:40 -0500 Lines: 323 References: <4B6D09F3B826D411A67300D0B706EFDE0115D49E@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Thu Feb 24 17:52:04 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,114,1107763200"; d="scan'208"; a="163175502:sNHT1886036860" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115D49E@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> To: "'pwe3@ietf.org' ((E-mail))" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org > If a rather broken feature is not in the RFC, it doesn't mean it is > disallowed. specially when such feature doesn't need any codepoint, or > IANA assignment. Those that feel they would have competitive advantage > could still implement and sell it. The problem with this approach is that it eliminates the possibility for backwards compatibility for standard implementations. > I think it is time for IETF to consider architectural principles that > could ensure simplicity and future reuse of its standards, rather than > short term kludges. A while back some said that IP was a kludge, and again recently MPLS. So I wouldn't say that all kludges are necessarily bad because they are not architecturally pure. That is IMHO not what the IETF is all about. :P --Tom > > -Shahram > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of >> Thomas D. Nadeau >> Sent: Thursday, February 24, 2005 10:54 AM >> To: David Allan >> Cc: 'pwe3@ietf.org'; 'neil.2.harrison@bt.com'; 'Luca >> Martini'; 'Mustapha >> Aissaoui' >> Subject: Re: RESEND RE: [PWE3] Control protocol draft - section 5.3.1 >> change t o PW status. >> >> >> >> >>> I've never been happy with label withdraw, esp. when either >>> AIS or RDI termination at a PE is indicative of an AC fault >>> and if not ignored, withdrawl on RDI will ultimately lock >>> down the PW (as withdrawl escalates all faults to AIS at >> the far AC). >>> >>> I would agree with Mustapha's concerns, backwards >>> compatibility with somthing that is broken is not really a >> good idea. >> >> I have to disagree and agree with Luca's original assertion. >> There are too many deployments in the field that are working >> just fine to disallow this as an option going forward. Ultimately >> folks may choose to not configure this behavior once all of the >> status signaling is implemented, but we should not preclude >> those that are working today and want to keep with what they have. >> >> --Tom >> >> >> >> >>> >>> cheers >>> Dave >>> >>>>>> Luca, >>>>>> However, it all appears that if the label withdraw PW status >>>>> method is >>>>>> used, then a label is withdrawn if say a AIS cell is >>>>> received from the >>>>>> local ATM network or LMI indicated a fault. Am I wrong? >>>>>> >>>>>> >>>>>> >>>>> yes. This is correct, then the remote end would re-generate >>>>> the AIS alarm. >>>>> >>>>>> Also, how should we interpret the new text? Initially, you >>>> advertize >>>>>> the label regardless of the state of AC. Then, if the PW status >>>>>> negotiation results in the use of the label withdraw PW >>>>> status method, >>>>>> would you immediately withdraw the label because the AC is >>>>> not active? >>>>>> >>>>>> >>>>>> >>>>> That would be my understanding. Some state needs to be kept >>>>> for this PW, >>>>> for the life of the LDP session, to indicate that the PW >> uses label >>>>> withdraw method. >>>>> >>>>> >>>>>> I would like to see a simplification to the procedures. The >>>>> reason why >>>>>> label withdrawal is to be avoided as much as possible is >> because it >>>>>> confuses a fault condition with an adiministrative >>>>> operation. We do not >>>>>> want to have the network react to some unstable CPE or L2 network >>>>>> condition. >>>>>> >>>>>> >>>>>> >>>>> For this reason we have PW status TLV infrastructure. >>>>> Remember that this >>>>> is a MUST implement, therefore this is what is going to be >>>>> used by ALL >>>>> PWE3 implementations. >>>>> >>>>>> I suggest that regardless of the PW status method used, >> a label is >>>>>> withdrawan only if the user configures the AC administrative >>>>> state to >>>>>> DOWN. Any other fault condition should raise an alarm to the >>>>> management >>>>>> system but should not cause a label withdrawal. >>>>>> >>>>>> >>>>>> >>>>> This would break any status notification. >>>>> The intent is not to break current deployments. After all >>>>> they must be >>>>> working fine with just the label withdraw method. >>>>> Whether this text is there or not , the implementations will >>>>> implement >>>>> label withdraw anyway. We all agree that if there is no label >>>>> advertisement the PW is down. >>>>> That is the main point. >>>>> Why are you so keen in disabling the backward compatibility ? >>>>> I would like this standard to be implemented, not the old >>>>> draft-martini. >>>>> >>>>> Luca >>>>> >>>>>> Mustapha. >>>>>> >>>>>> -----Original Message----- >>>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>> On Behalf Of >>>>>> Luca Martini >>>>>> Sent: Friday, February 18, 2005 10:45 AM >>>>>> To: neil.2.harrison@bt.com >>>>>> Cc: pwe3@ietf.org >>>>>> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>>>> change to PW >>>>>> status. >>>>>> >>>>>> neil.2.harrison@bt.com wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Luca asked: Please let me know if you have any comments >>>> about this >>>>>>> text. >>>>>>> >>>>>>> Question: Is there is any inference in this text (or >>>> other text in >>>>>>> this draft, or in any other draft for that matter) that a >>>>> PW must be >>>>>>> taken down in response to a failure on an AC? If there is >>>>> then its wrong. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> In the new PW status design, described here , the PW is >> not "taken >>>>>> down ", but instead attachment circuit status is >>>> communicated to the >>>>>> remote end of the PW. So the answer is no. Example ATM AIS >>>>> alarm. The >>>>>> AIS OAM cells will be passed along the PW , additionally a >>>> PW status >>>>>> TLV "interface Receive Fault" will also be transmitted in >>>>> the control >>>>>> protocol. >>>>>> >>>>>> Luca >>>>>> >>>>>> >>>>>> >>>>>>> One should NEVER take down a server layer trail in response to a >>>>>>> defect >>>>>>> in some client layer link connection. Just think if we did >>>>> this for >>>>>>> all nested layer networks right down to optics! >>>>>>> >>>>>>> regards, Neil >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>> On Behalf >>>>>>>> Of Luca Martini >>>>>>>> Sent: 17 February 2005 23:35 >>>>>>>> To: PWE3 WG (E-mail) >>>>>>>> Subject: [PWE3] Control protocol draft - section 5.3.1 >>>>> change to PW >>>>>>>> status. >>>>>>>> >>>>>>>> >>>>>>>> In this section , we were asked to make the implementation >>>>> of the PW >>>>>>>> status messages/TLV mandatory. >>>>>>>> Also all "CE-facing port" terminology will be changed to >>>>> "attachment >>>>>>>> circuit". >>>>>>>> >>>>>>>> 5.3.1. Use of Label Mappings. >>>>>>>> >>>>>>>> The PEs MUST send PW label mapping messages to their >>>>> peers as soon >>>>>>>> as >>>>>>>> the PW is configured and administratively enabled, >>>> regardless of >>>>>>>> the >>>>>>>> CE-facing interface state. The PW label should not be >> withdrawn >>>>>>>> unless the user administratively configures the >>>>> CE-facing interface >>>>>>>> down (or the PW configuration is deleted entirely). Using the >>>>>>>> procedures outlined in this section a simple label >>>>> withdraw method >>>>>>>> MAY also be supported as a primitive means of signaling >>>>> PW status. >>>>>>>> It >>>>>>>> is strongly RECOMMENDED that the PW status signaling >> procedures >>>>>>>> below >>>>>>>> be fully implemented. In any case if the Label mapping is not >>>>>>>> available the PW MUST be considered in the down state. >>>>>>>> >>>>>>>> will change to: >>>>>>>> >>>>>>>> 5.3.1. Use of Label Mappings. >>>>>>>> The PEs MUST send PW label mapping messages to their peers >>>>> as soon as >>>>>>>> the PW is configured and administratively enabled, >>>>> regardless of the >>>>>>>> attachment circuit state. The PW label should not be >>>>> withdrawn unless >>>>>>>> the user administratively configures the CE-facing >>>>> interface down (or >>>>>>>> the PW configuration is deleted entirely). Using the procedures >>>>>>>> outlined in this section a simple label withdraw method >>>>> MUST also be >>>>>>>> supported as a primitive means of signaling PW status. In >>>>> any case if >>>>>>>> the Label mapping is not available the PW MUST be >>>>> considered in the >>>>>>>> down state. >>>>>>>> >>>>>>>> Once, the PW status negotiation procedures are completed >>>>> and if they >>>>>>>> result in the use of the label withdraw method for PW status >>>>>>>> communication, the label withdraw PW status method MUST be >>>>> used. This >>>>>>>> will result in the PW label mapping message being >>>>> advertised only if >>>>>>>> the attachment circuit becomes active. The PW status signaling >>>>>>>> procedures described in this section MUST be fully implemented. >>>>>>>> >>>>>>>> >>>>>>>> Please let me know if you have any comments about this >> text. Luca >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: RESEND RE: Control protocol draft - section 5.3.1 change to PW status. Date: Thu, 24 Feb 2005 10:09:18 -0700 Lines: 493 References: <200502241607.j1OG7Nsn020648@tm3.ca.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, "'Thomas D. Nadeau'" , neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Thu Feb 24 18:11:58 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,114,1107752400"; d="scan'208"; a="38250588:sNHT25034520" User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: Mustapha Aissaoui In-Reply-To: <200502241607.j1OG7Nsn020648@tm3.ca.alcatel.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Mustapha Aissaoui wrote: >Tom, >I am not not suggesting to remove the label withdrawal method. My suggestion >is to withdraw a label when the AC's administrative status is DOWN but not >when its operational status is DOWN. In the latter case, keeping the label >will allow the transparent tunneling of received or locally generate AIS/RDI >over the PW to the remote PE. > > > I never heard of ethernet AIS/RDI ...... , or HDLC AIS/RDI .... Are you talking about making an exception for the ATM case only ? I think that the rest of the WG might be able to accept that just for ATM. In which case we would put some text in the ATM draft , in the service specific section. Luca >Mustapha. > >-----Original Message----- >From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >Thomas D. Nadeau >Sent: Thursday, February 24, 2005 10:54 AM >To: David Allan >Cc: 'pwe3@ietf.org'; 'neil.2.harrison@bt.com'; 'Luca Martini'; 'Mustapha >Aissaoui' >Subject: Re: RESEND RE: [PWE3] Control protocol draft - section 5.3.1 change >to PW status. > > > > > >> I've never been happy with label withdraw, esp. when either AIS or >>RDI termination at a PE is indicative of an AC fault and if not >>ignored, withdrawl on RDI will ultimately lock down the PW (as >>withdrawl escalates all faults to AIS at the far AC). >> >> I would agree with Mustapha's concerns, backwards compatibility with >>somthing that is broken is not really a good idea. >> >> > > I have to disagree and agree with Luca's original assertion. >There are too many deployments in the field that are working just fine to >disallow this as an option going forward. Ultimately folks may choose to >not configure this behavior once all of the status signaling is implemented, >but we should not preclude those that are working today and want to keep >with what they have. > > --Tom > > > > > > >> cheers >> Dave >> >> >> >>>>>Luca, >>>>>However, it all appears that if the label withdraw PW status >>>>> >>>>> >>>>method is >>>> >>>> >>>>>used, then a label is withdrawn if say a AIS cell is >>>>> >>>>> >>>>received from the >>>> >>>> >>>>>local ATM network or LMI indicated a fault. Am I wrong? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>yes. This is correct, then the remote end would re-generate the AIS >>>>alarm. >>>> >>>> >>>> >>>>>Also, how should we interpret the new text? Initially, you >>>>> >>>>> >>>advertize >>> >>> >>>>>the label regardless of the state of AC. Then, if the PW status >>>>>negotiation results in the use of the label withdraw PW >>>>> >>>>> >>>>status method, >>>> >>>> >>>>>would you immediately withdraw the label because the AC is >>>>> >>>>> >>>>not active? >>>> >>>> >>>>> >>>>> >>>>> >>>>That would be my understanding. Some state needs to be kept for this >>>>PW, for the life of the LDP session, to indicate that the PW uses >>>>label withdraw method. >>>> >>>> >>>> >>>> >>>>>I would like to see a simplification to the procedures. The >>>>> >>>>> >>>>reason why >>>> >>>> >>>>>label withdrawal is to be avoided as much as possible is because it >>>>>confuses a fault condition with an adiministrative >>>>> >>>>> >>>>operation. We do not >>>> >>>> >>>>>want to have the network react to some unstable CPE or L2 network >>>>>condition. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>For this reason we have PW status TLV infrastructure. >>>>Remember that this >>>>is a MUST implement, therefore this is what is going to be used by >>>>ALL >>>>PWE3 implementations. >>>> >>>> >>>> >>>>>I suggest that regardless of the PW status method used, a label is >>>>>withdrawan only if the user configures the AC administrative >>>>> >>>>> >>>>state to >>>> >>>> >>>>>DOWN. Any other fault condition should raise an alarm to the >>>>> >>>>> >>>>management >>>> >>>> >>>>>system but should not cause a label withdrawal. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>This would break any status notification. >>>>The intent is not to break current deployments. After all they must >>>>be working fine with just the label withdraw method. >>>>Whether this text is there or not , the implementations will >>>>implement label withdraw anyway. We all agree that if there is no >>>>label advertisement the PW is down. >>>>That is the main point. >>>>Why are you so keen in disabling the backward compatibility ? >>>>I would like this standard to be implemented, not the old >>>>draft-martini. >>>> >>>>Luca >>>> >>>> >>>> >>>>>Mustapha. >>>>> >>>>>-----Original Message----- >>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>> >>>>> >>>>On Behalf Of >>>> >>>> >>>>>Luca Martini >>>>>Sent: Friday, February 18, 2005 10:45 AM >>>>>To: neil.2.harrison@bt.com >>>>>Cc: pwe3@ietf.org >>>>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>>>> >>>>> >>>>change to PW >>>> >>>> >>>>>status. >>>>> >>>>>neil.2.harrison@bt.com wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Luca asked: Please let me know if you have any comments >>>>>> >>>>>> >>>about this >>> >>> >>>>>>text. >>>>>> >>>>>>Question: Is there is any inference in this text (or >>>>>> >>>>>> >>>other text in >>> >>> >>>>>>this draft, or in any other draft for that matter) that a >>>>>> >>>>>> >>>>PW must be >>>> >>>> >>>>>>taken down in response to a failure on an AC? If there is >>>>>> >>>>>> >>>>then its wrong. >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>In the new PW status design, described here , the PW is not "taken >>>>>down ", but instead attachment circuit status is >>>>> >>>>> >>>communicated to the >>> >>> >>>>>remote end of the PW. So the answer is no. Example ATM AIS >>>>> >>>>> >>>>alarm. The >>>> >>>> >>>>>AIS OAM cells will be passed along the PW , additionally a >>>>> >>>>> >>>PW status >>> >>> >>>>>TLV "interface Receive Fault" will also be transmitted in >>>>> >>>>> >>>>the control >>>> >>>> >>>>>protocol. >>>>> >>>>>Luca >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>One should NEVER take down a server layer trail in response to a >>>>>>defect in some client layer link connection. Just think if we did >>>>>> >>>>>> >>>>this for >>>> >>>> >>>>>>all nested layer networks right down to optics! >>>>>> >>>>>>regards, Neil >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>>>> >>>>>>> >>>>On Behalf >>>> >>>> >>>>>>>Of Luca Martini >>>>>>>Sent: 17 February 2005 23:35 >>>>>>>To: PWE3 WG (E-mail) >>>>>>>Subject: [PWE3] Control protocol draft - section 5.3.1 >>>>>>> >>>>>>> >>>>change to PW >>>> >>>> >>>>>>>status. >>>>>>> >>>>>>> >>>>>>>In this section , we were asked to make the implementation >>>>>>> >>>>>>> >>>>of the PW >>>> >>>> >>>>>>>status messages/TLV mandatory. >>>>>>>Also all "CE-facing port" terminology will be changed to >>>>>>> >>>>>>> >>>>"attachment >>>> >>>> >>>>>>>circuit". >>>>>>> >>>>>>>5.3.1. Use of Label Mappings. >>>>>>> >>>>>>> The PEs MUST send PW label mapping messages to their >>>>>>> >>>>>>> >>>>peers as soon >>>> >>>> >>>>>>>as >>>>>>> the PW is configured and administratively enabled, >>>>>>> >>>>>>> >>>regardless of >>> >>> >>>>>>>the >>>>>>> CE-facing interface state. The PW label should not be withdrawn >>>>>>>unless the user administratively configures the >>>>>>> >>>>>>> >>>>CE-facing interface >>>> >>>> >>>>>>> down (or the PW configuration is deleted entirely). Using the >>>>>>>procedures outlined in this section a simple label >>>>>>> >>>>>>> >>>>withdraw method >>>> >>>> >>>>>>> MAY also be supported as a primitive means of signaling >>>>>>> >>>>>>> >>>>PW status. >>>> >>>> >>>>>>>It >>>>>>> is strongly RECOMMENDED that the PW status signaling procedures >>>>>>>below be fully implemented. In any case if the Label mapping is >>>>>>>not available the PW MUST be considered in the down state. >>>>>>> >>>>>>>will change to: >>>>>>> >>>>>>>5.3.1. Use of Label Mappings. >>>>>>>The PEs MUST send PW label mapping messages to their peers >>>>>>> >>>>>>> >>>>as soon as >>>> >>>> >>>>>>>the PW is configured and administratively enabled, >>>>>>> >>>>>>> >>>>regardless of the >>>> >>>> >>>>>>>attachment circuit state. The PW label should not be >>>>>>> >>>>>>> >>>>withdrawn unless >>>> >>>> >>>>>>>the user administratively configures the CE-facing >>>>>>> >>>>>>> >>>>interface down (or >>>> >>>> >>>>>>>the PW configuration is deleted entirely). Using the procedures >>>>>>>outlined in this section a simple label withdraw method >>>>>>> >>>>>>> >>>>MUST also be >>>> >>>> >>>>>>>supported as a primitive means of signaling PW status. In >>>>>>> >>>>>>> >>>>any case if >>>> >>>> >>>>>>>the Label mapping is not available the PW MUST be >>>>>>> >>>>>>> >>>>considered in the >>>> >>>> >>>>>>>down state. >>>>>>> >>>>>>>Once, the PW status negotiation procedures are completed >>>>>>> >>>>>>> >>>>and if they >>>> >>>> >>>>>>>result in the use of the label withdraw method for PW status >>>>>>>communication, the label withdraw PW status method MUST be >>>>>>> >>>>>>> >>>>used. This >>>> >>>> >>>>>>>will result in the PW label mapping message being >>>>>>> >>>>>>> >>>>advertised only if >>>> >>>> >>>>>>>the attachment circuit becomes active. The PW status signaling >>>>>>>procedures described in this section MUST be fully implemented. >>>>>>> >>>>>>> >>>>>>>Please let me know if you have any comments about this text. Luca >>>>>>> >>>>>>>_______________________________________________ >>>>>>>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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>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 >>>> >>>> >>>> >>>> >>_______________________________________________ >>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 > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "David Allan" Subject: RE: RESEND RE: Control protocol draft - section 5.3.1 chan ge to PW status. Date: Thu, 24 Feb 2005 12:15:00 -0500 Lines: 532 Cc: "'Thomas D. Nadeau'" , pwe3@ietf.org, neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Thu Feb 24 18:12:10 2005 To: "'Luca Martini'" , Mustapha Aissaoui X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4297a3b9ddbbc388d94c1425bc2288b8 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org FYI, would also apply to unstructured TDM...and Ethernet 802.1ag/Y.17ethoam, SATOP I believe would also prefer the PW be held up to maintain clock synch... Dave > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Thursday, February 24, 2005 12:09 PM > To: Mustapha Aissaoui > Cc: 'Thomas D. Nadeau'; Allan, David [CAR:NS00:EXCH]; > neil.2.harrison@bt.com; pwe3@ietf.org > Subject: Re: RESEND RE: [PWE3] Control protocol draft - > section 5.3.1 change to PW status. > > > Mustapha Aissaoui wrote: > > >Tom, > >I am not not suggesting to remove the label withdrawal method. My > >suggestion is to withdraw a label when the AC's > administrative status > >is DOWN but not when its operational status is DOWN. In the latter > >case, keeping the label will allow the transparent tunneling of > >received or locally generate AIS/RDI over the PW to the remote PE. > > > > > > > I never heard of ethernet AIS/RDI ...... , or HDLC AIS/RDI > .... Are you talking about making an exception for the ATM > case only ? I think that the rest of the WG might be able to > accept that just for > ATM. In which case we would put some text in the ATM draft , in the > service specific section. > > Luca > > > >Mustapha. > > > >-----Original Message----- > >From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > On Behalf Of > >Thomas D. Nadeau > >Sent: Thursday, February 24, 2005 10:54 AM > >To: David Allan > >Cc: 'pwe3@ietf.org'; 'neil.2.harrison@bt.com'; 'Luca Martini'; > >'Mustapha Aissaoui' > >Subject: Re: RESEND RE: [PWE3] Control protocol draft - > section 5.3.1 > >change to PW status. > > > > > > > > > > > >> I've never been happy with label withdraw, esp. when > either AIS or > >>RDI termination at a PE is indicative of an AC fault and if not > >>ignored, withdrawl on RDI will ultimately lock down the PW (as > >>withdrawl escalates all faults to AIS at the far AC). > >> > >> I would agree with Mustapha's concerns, backwards > compatibility with > >>somthing that is broken is not really a good idea. > >> > >> > > > > I have to disagree and agree with Luca's original > assertion. There are > >too many deployments in the field that are working just fine to > >disallow this as an option going forward. Ultimately folks > may choose > >to not configure this behavior once all of the status signaling is > >implemented, but we should not preclude those that are working today > >and want to keep with what they have. > > > > --Tom > > > > > > > > > > > > > >> cheers > >> Dave > >> > >> > >> > >>>>>Luca, > >>>>>However, it all appears that if the label withdraw PW status > >>>>> > >>>>> > >>>>method is > >>>> > >>>> > >>>>>used, then a label is withdrawn if say a AIS cell is > >>>>> > >>>>> > >>>>received from the > >>>> > >>>> > >>>>>local ATM network or LMI indicated a fault. Am I wrong? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>yes. This is correct, then the remote end would > re-generate the AIS > >>>>alarm. > >>>> > >>>> > >>>> > >>>>>Also, how should we interpret the new text? Initially, you > >>>>> > >>>>> > >>>advertize > >>> > >>> > >>>>>the label regardless of the state of AC. Then, if the PW status > >>>>>negotiation results in the use of the label withdraw PW > >>>>> > >>>>> > >>>>status method, > >>>> > >>>> > >>>>>would you immediately withdraw the label because the AC is > >>>>> > >>>>> > >>>>not active? > >>>> > >>>> > >>>>> > >>>>> > >>>>> > >>>>That would be my understanding. Some state needs to be > kept for this > >>>>PW, for the life of the LDP session, to indicate that the PW uses > >>>>label withdraw method. > >>>> > >>>> > >>>> > >>>> > >>>>>I would like to see a simplification to the procedures. The > >>>>> > >>>>> > >>>>reason why > >>>> > >>>> > >>>>>label withdrawal is to be avoided as much as possible is > because it > >>>>>confuses a fault condition with an adiministrative > >>>>> > >>>>> > >>>>operation. We do not > >>>> > >>>> > >>>>>want to have the network react to some unstable CPE or > L2 network > >>>>>condition. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>For this reason we have PW status TLV infrastructure. > Remember that > >>>>this is a MUST implement, therefore this is what is going > to be used > >>>>by ALL > >>>>PWE3 implementations. > >>>> > >>>> > >>>> > >>>>>I suggest that regardless of the PW status method used, > a label is > >>>>>withdrawan only if the user configures the AC administrative > >>>>> > >>>>> > >>>>state to > >>>> > >>>> > >>>>>DOWN. Any other fault condition should raise an alarm to the > >>>>> > >>>>> > >>>>management > >>>> > >>>> > >>>>>system but should not cause a label withdrawal. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>This would break any status notification. > >>>>The intent is not to break current deployments. After all > they must > >>>>be working fine with just the label withdraw method. Whether this > >>>>text is there or not , the implementations will implement label > >>>>withdraw anyway. We all agree that if there is no label > >>>>advertisement the PW is down. That is the main point. > >>>>Why are you so keen in disabling the backward compatibility ? > >>>>I would like this standard to be implemented, not the old > >>>>draft-martini. > >>>> > >>>>Luca > >>>> > >>>> > >>>> > >>>>>Mustapha. > >>>>> > >>>>>-----Original Message----- > >>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>>>> > >>>>> > >>>>On Behalf Of > >>>> > >>>> > >>>>>Luca Martini > >>>>>Sent: Friday, February 18, 2005 10:45 AM > >>>>>To: neil.2.harrison@bt.com > >>>>>Cc: pwe3@ietf.org > >>>>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > >>>>> > >>>>> > >>>>change to PW > >>>> > >>>> > >>>>>status. > >>>>> > >>>>>neil.2.harrison@bt.com wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Luca asked: Please let me know if you have any comments > >>>>>> > >>>>>> > >>>about this > >>> > >>> > >>>>>>text. > >>>>>> > >>>>>>Question: Is there is any inference in this text (or > >>>>>> > >>>>>> > >>>other text in > >>> > >>> > >>>>>>this draft, or in any other draft for that matter) that a > >>>>>> > >>>>>> > >>>>PW must be > >>>> > >>>> > >>>>>>taken down in response to a failure on an AC? If there is > >>>>>> > >>>>>> > >>>>then its wrong. > >>>> > >>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>In the new PW status design, described here , the PW is > not "taken > >>>>>down ", but instead attachment circuit status is > >>>>> > >>>>> > >>>communicated to the > >>> > >>> > >>>>>remote end of the PW. So the answer is no. Example ATM AIS > >>>>> > >>>>> > >>>>alarm. The > >>>> > >>>> > >>>>>AIS OAM cells will be passed along the PW , additionally a > >>>>> > >>>>> > >>>PW status > >>> > >>> > >>>>>TLV "interface Receive Fault" will also be transmitted in > >>>>> > >>>>> > >>>>the control > >>>> > >>>> > >>>>>protocol. > >>>>> > >>>>>Luca > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>One should NEVER take down a server layer trail in > response to a > >>>>>>defect in some client layer link connection. Just > think if we did > >>>>>> > >>>>>> > >>>>this for > >>>> > >>>> > >>>>>>all nested layer networks right down to optics! > >>>>>> > >>>>>>regards, Neil > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>-----Original Message----- > >>>>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>>>>>> > >>>>>>> > >>>>On Behalf > >>>> > >>>> > >>>>>>>Of Luca Martini > >>>>>>>Sent: 17 February 2005 23:35 > >>>>>>>To: PWE3 WG (E-mail) > >>>>>>>Subject: [PWE3] Control protocol draft - section 5.3.1 > >>>>>>> > >>>>>>> > >>>>change to PW > >>>> > >>>> > >>>>>>>status. > >>>>>>> > >>>>>>> > >>>>>>>In this section , we were asked to make the implementation > >>>>>>> > >>>>>>> > >>>>of the PW > >>>> > >>>> > >>>>>>>status messages/TLV mandatory. > >>>>>>>Also all "CE-facing port" terminology will be changed to > >>>>>>> > >>>>>>> > >>>>"attachment > >>>> > >>>> > >>>>>>>circuit". > >>>>>>> > >>>>>>>5.3.1. Use of Label Mappings. > >>>>>>> > >>>>>>> The PEs MUST send PW label mapping messages to their > >>>>>>> > >>>>>>> > >>>>peers as soon > >>>> > >>>> > >>>>>>>as > >>>>>>> the PW is configured and administratively enabled, > >>>>>>> > >>>>>>> > >>>regardless of > >>> > >>> > >>>>>>>the > >>>>>>> CE-facing interface state. The PW label should not be > withdrawn > >>>>>>>unless the user administratively configures the > >>>>>>> > >>>>>>> > >>>>CE-facing interface > >>>> > >>>> > >>>>>>> down (or the PW configuration is deleted entirely). Using the > >>>>>>>procedures outlined in this section a simple label > >>>>>>> > >>>>>>> > >>>>withdraw method > >>>> > >>>> > >>>>>>> MAY also be supported as a primitive means of signaling > >>>>>>> > >>>>>>> > >>>>PW status. > >>>> > >>>> > >>>>>>>It > >>>>>>> is strongly RECOMMENDED that the PW status signaling > procedures > >>>>>>>below be fully implemented. In any case if the Label > mapping is > >>>>>>>not available the PW MUST be considered in the down state. > >>>>>>> > >>>>>>>will change to: > >>>>>>> > >>>>>>>5.3.1. Use of Label Mappings. > >>>>>>>The PEs MUST send PW label mapping messages to their peers > >>>>>>> > >>>>>>> > >>>>as soon as > >>>> > >>>> > >>>>>>>the PW is configured and administratively enabled, > >>>>>>> > >>>>>>> > >>>>regardless of the > >>>> > >>>> > >>>>>>>attachment circuit state. The PW label should not be > >>>>>>> > >>>>>>> > >>>>withdrawn unless > >>>> > >>>> > >>>>>>>the user administratively configures the CE-facing > >>>>>>> > >>>>>>> > >>>>interface down (or > >>>> > >>>> > >>>>>>>the PW configuration is deleted entirely). Using the > procedures > >>>>>>>outlined in this section a simple label withdraw method > >>>>>>> > >>>>>>> > >>>>MUST also be > >>>> > >>>> > >>>>>>>supported as a primitive means of signaling PW status. In > >>>>>>> > >>>>>>> > >>>>any case if > >>>> > >>>> > >>>>>>>the Label mapping is not available the PW MUST be > >>>>>>> > >>>>>>> > >>>>considered in the > >>>> > >>>> > >>>>>>>down state. > >>>>>>> > >>>>>>>Once, the PW status negotiation procedures are completed > >>>>>>> > >>>>>>> > >>>>and if they > >>>> > >>>> > >>>>>>>result in the use of the label withdraw method for PW status > >>>>>>>communication, the label withdraw PW status method MUST be > >>>>>>> > >>>>>>> > >>>>used. This > >>>> > >>>> > >>>>>>>will result in the PW label mapping message being > >>>>>>> > >>>>>>> > >>>>advertised only if > >>>> > >>>> > >>>>>>>the attachment circuit becomes active. The PW status signaling > >>>>>>>procedures described in this section MUST be fully implemented. > >>>>>>> > >>>>>>> > >>>>>>>Please let me know if you have any comments about this > text. Luca > >>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>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 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>_______________________________________________ > >>>>>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 > >>>> > >>>> > >>>> > >>>> > >>_______________________________________________ > >>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 > > > > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 12:16:50 -0500 Lines: 380 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 18:15:11 2005 To: =?iso-8859-1?Q?=27Benny_Ammitzb=F8ll=27?= , Luca Martini , neil.2.harrison@bt.com X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org > -----Original Message----- > From: Benny Ammitzb=F8ll [mailto:Benny.Ammitzboell@tpack.net] > Sent: Wednesday, February 23, 2005 4:29 AM > To: Luca Martini; neil.2.harrison@bt.com > Cc: pwe3@ietf.org; mustapha.aissaoui@alcatel.com > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to PW > status. >=20 >=20 > Sorry if I jump in in the middle of this, but I believe that=20 > Neils point is > that the PW is the server and what the PW carries inside is=20 > the client. This > also IMO means that the AC is client and the state of the AC=20 > should not > affect the server layer, i.e. the PW. >=20 > I think it would help to stress more clearly in section 5.3.1 that = the > coupling between AC state and PW state is NOT the desired=20 > behaviour, but it > is only there because of backwards compatability with non-standard > equipment. >=20 > My proposal for a new text: >=20 > The PEs MUST send PW label mapping messages to their peers=20 > as soon as > the PW is configured and administratively enabled,=20 > regardless of the > attachment circuit state. The PW label should not be=20 > withdrawn unless > the user administratively configures the PW down (or the=20 > PW configuration > is deleted entirely). If the Label mapping is not=20 > available the PW MUST > be considered in the down state. >=20 > For backwards compatability a simple label withdraw method=20 > MUST also be I have made this point in an earlier email, but I think it is worth = repeating. I believe that this MUST should be a MAY. Label mapping, label withdraw and the use of PW Status are all = functions that are implemented in software. Therefore, it may be true = that there are legacy devices today that only support label withdraw, = but there is no reason why vendors would not be able to support PW = Status in future software releases. PW Status is mandatory and future = software releases must support it to be standards-compliant. Considering the fact that PWE is a relatively new and rapidly expanding = technology, does anybody believe that five years from now there will be = products in the field that were installed pre 2003 and that still run = their original R1 software load? > supported as a legacy means of signaling PW status. When=20 > the PW status > negotiation procedures are completed and if they result in=20 > not using the > PW Status TVL, the label withdraw PW status method MUST be=20 > used. This > will result in the PW label mapping message being=20 > advertised only if > the attachment circuit becomes active. The PW status signaling > procedures described in this section MUST be fully implemented. >=20 > /Benny >=20 >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf = Of > Luca Martini > Sent: 22. februar 2005 20:35 > To: neil.2.harrison@bt.com > Cc: pwe3@ietf.org; mustapha.aissaoui@alcatel.com > Subject: Re: [PWE3] Control protocol draft - section 5.3.1=20 > change to PW > status. >=20 >=20 > neil.2.harrison@bt.com wrote: >=20 > >Mustapha, > > > >This is precisely why I raised this point.....but please do=20 > not overlook > >the more fundamantal point that 'defect events' in any client layer > >should never result in 'events' in any server layer. One should not > >violate principles like these just because its expedient. =20 > If everyone > >had taken this attitude we could, in theory, cause 'events' at the > >optics layer (maybe in someone else's network even) for=20 > 'defect events' > >in some client perhaps several layers removed (upwards). =20 > Clearly this > >is a nonsense. > > > >regards, Neil > > > > > > > Neil, I agree, however the PW is not a client of the PW control > protocol. I see the PW an adaptation of the=20 > atm/frame/ethernet etc. to MPLS. > So we are not causing an alarm in the RSVP LSP , or in the=20 > IGP protocol..... >=20 > Luca >=20 > >>-----Original Message----- > >>From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > >>Sent: 22 February 2005 15:05 > >>To: 'Luca Martini'; Harrison,N,Neil,IKM1 R > >>Cc: pwe3@ietf.org > >>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > >>change to PW status. > >> > >> > >>Luca, > >>However, it all appears that if the label withdraw PW status > >>method is used, then a label is withdrawn if say a AIS cell > >>is received from the local ATM network or LMI indicated a > >>fault. Am I wrong? > >> > >>Also, how should we interpret the new text? Initially, you > >>advertize the label regardless of the state of AC. Then, if > >>the PW status negotiation results in the use of the label > >>withdraw PW status method, would you immediately withdraw the > >>label because the AC is not active? > >> > >>I would like to see a simplification to the procedures. The > >>reason why label withdrawal is to be avoided as much as > >>possible is because it confuses a fault condition with an > >>adiministrative operation. We do not want to have the network > >>react to some unstable CPE or L2 network condition. > >> > >>I suggest that regardless of the PW status method used, a > >>label is withdrawan only if the user configures the AC > >>administrative state to DOWN. Any other fault condition > >>should raise an alarm to the management system but should not > >>cause a label withdrawal. > >> > >>Mustapha. > >> > >>-----Original Message----- > >>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > >>Behalf Of Luca Martini > >>Sent: Friday, February 18, 2005 10:45 AM > >>To: neil.2.harrison@bt.com > >>Cc: pwe3@ietf.org > >>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > >>change to PW status. > >> > >>neil.2.harrison@bt.com wrote: > >> > >> > >> > >>>Luca asked: Please let me know if you have any comments about = this > >>>text. > >>> > >>>Question: Is there is any inference in this text (or other text = in > >>>this draft, or in any other draft for that matter) that a=20 > PW must be > >>>taken down in response to a failure on an AC? If there is > >>> > >>> > >>then its wrong. > >> > >> > >>> > >>> > >>> > >>> > >>In the new PW status design, described here , the PW is not > >>"taken down ", but instead attachment circuit status is > >>communicated to the remote end of the PW. So the answer is > >>no. Example ATM AIS alarm. The AIS OAM cells will be passed > >>along the PW , additionally a PW status TLV "interface > >>Receive Fault" will also be transmitted in the control protocol. > >> > >>Luca > >> > >> > >> > >>>One should NEVER take down a server layer trail in response > >>> > >>> > >>to a defect > >> > >> > >>>in some client layer link connection. Just think if we=20 > did this for > >>>all nested layer networks right down to optics! > >>> > >>>regards, Neil > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: pwe3-bounces@ietf.org=20 > [mailto:pwe3-bounces@ietf.org] On Behalf > >>>>Of Luca Martini > >>>>Sent: 17 February 2005 23:35 > >>>>To: PWE3 WG (E-mail) > >>>>Subject: [PWE3] Control protocol draft - section 5.3.1=20 > change to PW > >>>>status. > >>>> > >>>> > >>>>In this section , we were asked to make the=20 > implementation of the PW > >>>>status messages/TLV mandatory. > >>>>Also all "CE-facing port" terminology will be changed to > >>>> > >>>> > >>"attachment > >> > >> > >>>>circuit". > >>>> > >>>>5.3.1. Use of Label Mappings. > >>>> > >>>> The PEs MUST send PW label mapping messages to their > >>>> > >>>> > >>peers as soon > >> > >> > >>>>as > >>>> the PW is configured and administratively enabled, regardless = of > >>>>the > >>>> CE-facing interface state. The PW label should not be withdrawn > >>>> unless the user administratively configures the > >>>> > >>>> > >>CE-facing interface > >> > >> > >>>> down (or the PW configuration is deleted entirely). Using the > >>>> procedures outlined in this section a simple label > >>>> > >>>> > >>withdraw method > >> > >> > >>>> MAY also be supported as a primitive means of signaling > >>>> > >>>> > >>PW status. > >> > >> > >>>>It > >>>> is strongly RECOMMENDED that the PW status signaling procedures > >>>>below > >>>> be fully implemented. In any case if the Label mapping is not > >>>> available the PW MUST be considered in the down state. > >>>> > >>>>will change to: > >>>> > >>>>5.3.1. Use of Label Mappings. > >>>>The PEs MUST send PW label mapping messages to their peers > >>>> > >>>> > >>as soon as > >> > >> > >>>>the PW is configured and administratively enabled, > >>>> > >>>> > >>regardless of the > >> > >> > >>>>attachment circuit state. The PW label should not be > >>>> > >>>> > >>withdrawn unless > >> > >> > >>>>the user administratively configures the CE-facing > >>>> > >>>> > >>interface down (or > >> > >> > >>>>the PW configuration is deleted entirely). Using the procedures > >>>>outlined in this section a simple label withdraw method > >>>> > >>>> > >>MUST also be > >> > >> > >>>>supported as a primitive means of signaling PW status. In > >>>> > >>>> > >>any case if > >> > >> > >>>>the Label mapping is not available the PW MUST be=20 > considered in the > >>>>down state. > >>>> > >>>>Once, the PW status negotiation procedures are completed=20 > and if they > >>>>result in the use of the label withdraw method for PW status > >>>>communication, the label withdraw PW status method MUST be > >>>> > >>>> > >>used. This > >> > >> > >>>>will result in the PW label mapping message being > >>>> > >>>> > >>advertised only if > >> > >> > >>>>the attachment circuit becomes active. The PW status signaling > >>>>procedures described in this section MUST be fully implemented. > >>>> > >>>> > >>>>Please let me know if you have any comments about this text. Luca > >>>> > >>>>_______________________________________________ > >>>>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 > >>> > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> > >> > >> > > > > > > >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Mustapha Aissaoui" Subject: RE: RESEND RE: Control protocol draft - section 5.3.1 change to PW status. Date: Thu, 24 Feb 2005 12:18:05 -0500 Lines: 518 References: <421E0A3E.9080605@cisco.com> Cc: "'Thomas D. Nadeau'" , pwe3@ietf.org, neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Thu Feb 24 18:15:19 2005 To: "'Luca Martini'" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <421E0A3E.9080605@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-index: AcUak9lp/cAxJ/JOQ4usCZJfLf3P6QAAFXlA X-Spam-Score: 0.0 (/) X-Scan-Signature: 3da7e5d5ca82d58872786934e4963616 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Luca, This proposal is not geared towards ATM. The fact the AIS/RDI can continue to flow is a good property but not the main driver. The main driver for the proposed change is to isolate the PSN from unstabilities in the CPE and access network. This is why withdrawing label on operational status change is not a good idea. Withdrawing the label on administrative status change is OK. Mustapha. -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Luca Martini Sent: Thursday, February 24, 2005 12:09 PM To: Mustapha Aissaoui Cc: pwe3@ietf.org; 'Thomas D. Nadeau'; neil.2.harrison@bt.com Subject: Re: RESEND RE: [PWE3] Control protocol draft - section 5.3.1 change to PW status. Mustapha Aissaoui wrote: >Tom, >I am not not suggesting to remove the label withdrawal method. My >suggestion is to withdraw a label when the AC's administrative status >is DOWN but not when its operational status is DOWN. In the latter >case, keeping the label will allow the transparent tunneling of >received or locally generate AIS/RDI over the PW to the remote PE. > > > I never heard of ethernet AIS/RDI ...... , or HDLC AIS/RDI .... Are you talking about making an exception for the ATM case only ? I think that the rest of the WG might be able to accept that just for ATM. In which case we would put some text in the ATM draft , in the service specific section. Luca >Mustapha. > >-----Original Message----- >From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >Thomas D. Nadeau >Sent: Thursday, February 24, 2005 10:54 AM >To: David Allan >Cc: 'pwe3@ietf.org'; 'neil.2.harrison@bt.com'; 'Luca Martini'; >'Mustapha Aissaoui' >Subject: Re: RESEND RE: [PWE3] Control protocol draft - section 5.3.1 >change to PW status. > > > > > >> I've never been happy with label withdraw, esp. when either AIS or >>RDI termination at a PE is indicative of an AC fault and if not >>ignored, withdrawl on RDI will ultimately lock down the PW (as >>withdrawl escalates all faults to AIS at the far AC). >> >> I would agree with Mustapha's concerns, backwards compatibility with >>somthing that is broken is not really a good idea. >> >> > > I have to disagree and agree with Luca's original assertion. >There are too many deployments in the field that are working just fine >to disallow this as an option going forward. Ultimately folks may >choose to not configure this behavior once all of the status signaling >is implemented, but we should not preclude those that are working today >and want to keep with what they have. > > --Tom > > > > > > >> cheers >> Dave >> >> >> >>>>>Luca, >>>>>However, it all appears that if the label withdraw PW status >>>>> >>>>> >>>>method is >>>> >>>> >>>>>used, then a label is withdrawn if say a AIS cell is >>>>> >>>>> >>>>received from the >>>> >>>> >>>>>local ATM network or LMI indicated a fault. Am I wrong? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>yes. This is correct, then the remote end would re-generate the AIS >>>>alarm. >>>> >>>> >>>> >>>>>Also, how should we interpret the new text? Initially, you >>>>> >>>>> >>>advertize >>> >>> >>>>>the label regardless of the state of AC. Then, if the PW status >>>>>negotiation results in the use of the label withdraw PW >>>>> >>>>> >>>>status method, >>>> >>>> >>>>>would you immediately withdraw the label because the AC is >>>>> >>>>> >>>>not active? >>>> >>>> >>>>> >>>>> >>>>> >>>>That would be my understanding. Some state needs to be kept for this >>>>PW, for the life of the LDP session, to indicate that the PW uses >>>>label withdraw method. >>>> >>>> >>>> >>>> >>>>>I would like to see a simplification to the procedures. The >>>>> >>>>> >>>>reason why >>>> >>>> >>>>>label withdrawal is to be avoided as much as possible is because it >>>>>confuses a fault condition with an adiministrative >>>>> >>>>> >>>>operation. We do not >>>> >>>> >>>>>want to have the network react to some unstable CPE or L2 network >>>>>condition. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>For this reason we have PW status TLV infrastructure. >>>>Remember that this >>>>is a MUST implement, therefore this is what is going to be used by >>>>ALL >>>>PWE3 implementations. >>>> >>>> >>>> >>>>>I suggest that regardless of the PW status method used, a label is >>>>>withdrawan only if the user configures the AC administrative >>>>> >>>>> >>>>state to >>>> >>>> >>>>>DOWN. Any other fault condition should raise an alarm to the >>>>> >>>>> >>>>management >>>> >>>> >>>>>system but should not cause a label withdrawal. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>This would break any status notification. >>>>The intent is not to break current deployments. After all they must >>>>be working fine with just the label withdraw method. >>>>Whether this text is there or not , the implementations will >>>>implement label withdraw anyway. We all agree that if there is no >>>>label advertisement the PW is down. >>>>That is the main point. >>>>Why are you so keen in disabling the backward compatibility ? >>>>I would like this standard to be implemented, not the old >>>>draft-martini. >>>> >>>>Luca >>>> >>>> >>>> >>>>>Mustapha. >>>>> >>>>>-----Original Message----- >>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>> >>>>> >>>>On Behalf Of >>>> >>>> >>>>>Luca Martini >>>>>Sent: Friday, February 18, 2005 10:45 AM >>>>>To: neil.2.harrison@bt.com >>>>>Cc: pwe3@ietf.org >>>>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>>>> >>>>> >>>>change to PW >>>> >>>> >>>>>status. >>>>> >>>>>neil.2.harrison@bt.com wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Luca asked: Please let me know if you have any comments >>>>>> >>>>>> >>>about this >>> >>> >>>>>>text. >>>>>> >>>>>>Question: Is there is any inference in this text (or >>>>>> >>>>>> >>>other text in >>> >>> >>>>>>this draft, or in any other draft for that matter) that a >>>>>> >>>>>> >>>>PW must be >>>> >>>> >>>>>>taken down in response to a failure on an AC? If there is >>>>>> >>>>>> >>>>then its wrong. >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>In the new PW status design, described here , the PW is not "taken >>>>>down ", but instead attachment circuit status is >>>>> >>>>> >>>communicated to the >>> >>> >>>>>remote end of the PW. So the answer is no. Example ATM AIS >>>>> >>>>> >>>>alarm. The >>>> >>>> >>>>>AIS OAM cells will be passed along the PW , additionally a >>>>> >>>>> >>>PW status >>> >>> >>>>>TLV "interface Receive Fault" will also be transmitted in >>>>> >>>>> >>>>the control >>>> >>>> >>>>>protocol. >>>>> >>>>>Luca >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>One should NEVER take down a server layer trail in response to a >>>>>>defect in some client layer link connection. Just think if we did >>>>>> >>>>>> >>>>this for >>>> >>>> >>>>>>all nested layer networks right down to optics! >>>>>> >>>>>>regards, Neil >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>>>> >>>>>>> >>>>On Behalf >>>> >>>> >>>>>>>Of Luca Martini >>>>>>>Sent: 17 February 2005 23:35 >>>>>>>To: PWE3 WG (E-mail) >>>>>>>Subject: [PWE3] Control protocol draft - section 5.3.1 >>>>>>> >>>>>>> >>>>change to PW >>>> >>>> >>>>>>>status. >>>>>>> >>>>>>> >>>>>>>In this section , we were asked to make the implementation >>>>>>> >>>>>>> >>>>of the PW >>>> >>>> >>>>>>>status messages/TLV mandatory. >>>>>>>Also all "CE-facing port" terminology will be changed to >>>>>>> >>>>>>> >>>>"attachment >>>> >>>> >>>>>>>circuit". >>>>>>> >>>>>>>5.3.1. Use of Label Mappings. >>>>>>> >>>>>>> The PEs MUST send PW label mapping messages to their >>>>>>> >>>>>>> >>>>peers as soon >>>> >>>> >>>>>>>as >>>>>>> the PW is configured and administratively enabled, >>>>>>> >>>>>>> >>>regardless of >>> >>> >>>>>>>the >>>>>>> CE-facing interface state. The PW label should not be withdrawn >>>>>>>unless the user administratively configures the >>>>>>> >>>>>>> >>>>CE-facing interface >>>> >>>> >>>>>>> down (or the PW configuration is deleted entirely). Using the >>>>>>>procedures outlined in this section a simple label >>>>>>> >>>>>>> >>>>withdraw method >>>> >>>> >>>>>>> MAY also be supported as a primitive means of signaling >>>>>>> >>>>>>> >>>>PW status. >>>> >>>> >>>>>>>It >>>>>>> is strongly RECOMMENDED that the PW status signaling procedures >>>>>>>below be fully implemented. In any case if the Label mapping is >>>>>>>not available the PW MUST be considered in the down state. >>>>>>> >>>>>>>will change to: >>>>>>> >>>>>>>5.3.1. Use of Label Mappings. >>>>>>>The PEs MUST send PW label mapping messages to their peers >>>>>>> >>>>>>> >>>>as soon as >>>> >>>> >>>>>>>the PW is configured and administratively enabled, >>>>>>> >>>>>>> >>>>regardless of the >>>> >>>> >>>>>>>attachment circuit state. The PW label should not be >>>>>>> >>>>>>> >>>>withdrawn unless >>>> >>>> >>>>>>>the user administratively configures the CE-facing >>>>>>> >>>>>>> >>>>interface down (or >>>> >>>> >>>>>>>the PW configuration is deleted entirely). Using the procedures >>>>>>>outlined in this section a simple label withdraw method >>>>>>> >>>>>>> >>>>MUST also be >>>> >>>> >>>>>>>supported as a primitive means of signaling PW status. In >>>>>>> >>>>>>> >>>>any case if >>>> >>>> >>>>>>>the Label mapping is not available the PW MUST be >>>>>>> >>>>>>> >>>>considered in the >>>> >>>> >>>>>>>down state. >>>>>>> >>>>>>>Once, the PW status negotiation procedures are completed >>>>>>> >>>>>>> >>>>and if they >>>> >>>> >>>>>>>result in the use of the label withdraw method for PW status >>>>>>>communication, the label withdraw PW status method MUST be >>>>>>> >>>>>>> >>>>used. This >>>> >>>> >>>>>>>will result in the PW label mapping message being >>>>>>> >>>>>>> >>>>advertised only if >>>> >>>> >>>>>>>the attachment circuit becomes active. The PW status signaling >>>>>>>procedures described in this section MUST be fully implemented. >>>>>>> >>>>>>> >>>>>>>Please let me know if you have any comments about this text. Luca >>>>>>> >>>>>>>_______________________________________________ >>>>>>>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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>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 >>>> >>>> >>>> >>>> >>_______________________________________________ >>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 > > > >_______________________________________________ >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 27 15:58:25 2006 From: Shahram Davari Subject: RE: RESEND RE: Control protocol draft - section 5.3.1 chan ge t o PW status. Date: Thu, 24 Feb 2005 09:22:31 -0800 Lines: 353 Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-bounces@ietf.org Thu Feb 24 18:21:08 2005 To: "'Thomas D. Nadeau'" , "'pwe3@ietf.org' ((E-mail))" X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org > > If a rather broken feature is not in the RFC, it doesn't mean it is > > disallowed. specially when such feature doesn't need any > codepoint, or > > IANA assignment. Those that feel they would have > competitive advantage > > could still implement and sell it. > > The problem with this approach is that it eliminates the > possibility for backwards compatibility for standard > implementations. No it doesn't. It only eliminates the possibility for backward compatibility for products that ONLY implement this RFC. So one could still claim Standards compliance if they implement extra functions. > > > I think it is time for IETF to consider architectural > principles that > > could ensure simplicity and future reuse of its standards, > rather than > > short term kludges. > > A while back some said that IP was a kludge, > and again recently MPLS. So I wouldn't say that > all kludges are necessarily bad because they are > not architecturally pure. That is IMHO not what > the IETF is all about. :P I never heard anybody suggest that the Kludge that we are talking about is good. -Shahram > > --Tom > > > > > > > > -Shahram > > > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org > [mailto:pwe3-bounces@ietf.org]On Behalf Of > >> Thomas D. Nadeau > >> Sent: Thursday, February 24, 2005 10:54 AM > >> To: David Allan > >> Cc: 'pwe3@ietf.org'; 'neil.2.harrison@bt.com'; 'Luca > >> Martini'; 'Mustapha > >> Aissaoui' > >> Subject: Re: RESEND RE: [PWE3] Control protocol draft - > section 5.3.1 > >> change t o PW status. > >> > >> > >> > >> > >>> I've never been happy with label withdraw, esp. when either > >>> AIS or RDI termination at a PE is indicative of an AC fault > >>> and if not ignored, withdrawl on RDI will ultimately lock > >>> down the PW (as withdrawl escalates all faults to AIS at > >> the far AC). > >>> > >>> I would agree with Mustapha's concerns, backwards > >>> compatibility with somthing that is broken is not really a > >> good idea. > >> > >> I have to disagree and agree with Luca's original assertion. > >> There are too many deployments in the field that are working > >> just fine to disallow this as an option going forward. Ultimately > >> folks may choose to not configure this behavior once all of the > >> status signaling is implemented, but we should not preclude > >> those that are working today and want to keep with what they have. > >> > >> --Tom > >> > >> > >> > >> > >>> > >>> cheers > >>> Dave > >>> > >>>>>> Luca, > >>>>>> However, it all appears that if the label withdraw PW status > >>>>> method is > >>>>>> used, then a label is withdrawn if say a AIS cell is > >>>>> received from the > >>>>>> local ATM network or LMI indicated a fault. Am I wrong? > >>>>>> > >>>>>> > >>>>>> > >>>>> yes. This is correct, then the remote end would re-generate > >>>>> the AIS alarm. > >>>>> > >>>>>> Also, how should we interpret the new text? Initially, you > >>>> advertize > >>>>>> the label regardless of the state of AC. Then, if the PW status > >>>>>> negotiation results in the use of the label withdraw PW > >>>>> status method, > >>>>>> would you immediately withdraw the label because the AC is > >>>>> not active? > >>>>>> > >>>>>> > >>>>>> > >>>>> That would be my understanding. Some state needs to be kept > >>>>> for this PW, > >>>>> for the life of the LDP session, to indicate that the PW > >> uses label > >>>>> withdraw method. > >>>>> > >>>>> > >>>>>> I would like to see a simplification to the procedures. The > >>>>> reason why > >>>>>> label withdrawal is to be avoided as much as possible is > >> because it > >>>>>> confuses a fault condition with an adiministrative > >>>>> operation. We do not > >>>>>> want to have the network react to some unstable CPE or > L2 network > >>>>>> condition. > >>>>>> > >>>>>> > >>>>>> > >>>>> For this reason we have PW status TLV infrastructure. > >>>>> Remember that this > >>>>> is a MUST implement, therefore this is what is going to be > >>>>> used by ALL > >>>>> PWE3 implementations. > >>>>> > >>>>>> I suggest that regardless of the PW status method used, > >> a label is > >>>>>> withdrawan only if the user configures the AC administrative > >>>>> state to > >>>>>> DOWN. Any other fault condition should raise an alarm to the > >>>>> management > >>>>>> system but should not cause a label withdrawal. > >>>>>> > >>>>>> > >>>>>> > >>>>> This would break any status notification. > >>>>> The intent is not to break current deployments. After all > >>>>> they must be > >>>>> working fine with just the label withdraw method. > >>>>> Whether this text is there or not , the implementations will > >>>>> implement > >>>>> label withdraw anyway. We all agree that if there is no label > >>>>> advertisement the PW is down. > >>>>> That is the main point. > >>>>> Why are you so keen in disabling the backward compatibility ? > >>>>> I would like this standard to be implemented, not the old > >>>>> draft-martini. > >>>>> > >>>>> Luca > >>>>> > >>>>>> Mustapha. > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>>>> On Behalf Of > >>>>>> Luca Martini > >>>>>> Sent: Friday, February 18, 2005 10:45 AM > >>>>>> To: neil.2.harrison@bt.com > >>>>>> Cc: pwe3@ietf.org > >>>>>> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > >>>>> change to PW > >>>>>> status. > >>>>>> > >>>>>> neil.2.harrison@bt.com wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Luca asked: Please let me know if you have any comments > >>>> about this > >>>>>>> text. > >>>>>>> > >>>>>>> Question: Is there is any inference in this text (or > >>>> other text in > >>>>>>> this draft, or in any other draft for that matter) that a > >>>>> PW must be > >>>>>>> taken down in response to a failure on an AC? If there is > >>>>> then its wrong. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> In the new PW status design, described here , the PW is > >> not "taken > >>>>>> down ", but instead attachment circuit status is > >>>> communicated to the > >>>>>> remote end of the PW. So the answer is no. Example ATM AIS > >>>>> alarm. The > >>>>>> AIS OAM cells will be passed along the PW , additionally a > >>>> PW status > >>>>>> TLV "interface Receive Fault" will also be transmitted in > >>>>> the control > >>>>>> protocol. > >>>>>> > >>>>>> Luca > >>>>>> > >>>>>> > >>>>>> > >>>>>>> One should NEVER take down a server layer trail in > response to a > >>>>>>> defect > >>>>>>> in some client layer link connection. Just think if we did > >>>>> this for > >>>>>>> all nested layer networks right down to optics! > >>>>>>> > >>>>>>> regards, Neil > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>>>> On Behalf > >>>>>>>> Of Luca Martini > >>>>>>>> Sent: 17 February 2005 23:35 > >>>>>>>> To: PWE3 WG (E-mail) > >>>>>>>> Subject: [PWE3] Control protocol draft - section 5.3.1 > >>>>> change to PW > >>>>>>>> status. > >>>>>>>> > >>>>>>>> > >>>>>>>> In this section , we were asked to make the implementation > >>>>> of the PW > >>>>>>>> status messages/TLV mandatory. > >>>>>>>> Also all "CE-facing port" terminology will be changed to > >>>>> "attachment > >>>>>>>> circuit". > >>>>>>>> > >>>>>>>> 5.3.1. Use of Label Mappings. > >>>>>>>> > >>>>>>>> The PEs MUST send PW label mapping messages to their > >>>>> peers as soon > >>>>>>>> as > >>>>>>>> the PW is configured and administratively enabled, > >>>> regardless of > >>>>>>>> the > >>>>>>>> CE-facing interface state. The PW label should not be > >> withdrawn > >>>>>>>> unless the user administratively configures the > >>>>> CE-facing interface > >>>>>>>> down (or the PW configuration is deleted entirely). > Using the > >>>>>>>> procedures outlined in this section a simple label > >>>>> withdraw method > >>>>>>>> MAY also be supported as a primitive means of signaling > >>>>> PW status. > >>>>>>>> It > >>>>>>>> is strongly RECOMMENDED that the PW status signaling > >> procedures > >>>>>>>> below > >>>>>>>> be fully implemented. In any case if the Label > mapping is not > >>>>>>>> available the PW MUST be considered in the down state. > >>>>>>>> > >>>>>>>> will change to: > >>>>>>>> > >>>>>>>> 5.3.1. Use of Label Mappings. > >>>>>>>> The PEs MUST send PW label mapping messages to their peers > >>>>> as soon as > >>>>>>>> the PW is configured and administratively enabled, > >>>>> regardless of the > >>>>>>>> attachment circuit state. The PW label should not be > >>>>> withdrawn unless > >>>>>>>> the user administratively configures the CE-facing > >>>>> interface down (or > >>>>>>>> the PW configuration is deleted entirely). Using the > procedures > >>>>>>>> outlined in this section a simple label withdraw method > >>>>> MUST also be > >>>>>>>> supported as a primitive means of signaling PW status. In > >>>>> any case if > >>>>>>>> the Label mapping is not available the PW MUST be > >>>>> considered in the > >>>>>>>> down state. > >>>>>>>> > >>>>>>>> Once, the PW status negotiation procedures are completed > >>>>> and if they > >>>>>>>> result in the use of the label withdraw method for PW status > >>>>>>>> communication, the label withdraw PW status method MUST be > >>>>> used. This > >>>>>>>> will result in the PW label mapping message being > >>>>> advertised only if > >>>>>>>> the attachment circuit becomes active. The PW status > signaling > >>>>>>>> procedures described in this section MUST be fully > implemented. > >>>>>>>> > >>>>>>>> > >>>>>>>> Please let me know if you have any comments about this > >> text. Luca > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>>> > >>>>> > >>>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > 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 27 15:58:25 2006 From: Luca Martini Subject: Re: RESEND RE: Control protocol draft - section 5.3.1 change t o PW status. Date: Thu, 24 Feb 2005 10:25:01 -0700 Lines: 586 References: <0536FC9B908BEC4597EE721BE6A353890A9F1974@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, tnadeau@cisco.com, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 18:25:03 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F1974@i2km07-ukbr.domain1.systemhost.net> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Neil, Right now , the design gives you exactly what you require. Disabling backward compatibility does not help you in any way. However it will make it very likely that implementations will ignore this text , and keep the backward compatibility. In which case this text will be changed back anyway at the proposed standard review time. Right now I do not see a consensus to remove the backward status messaging compatibility. I would like to hear from the rest of the WG, including most of the contributors to these documents. We have gone past last call , and at last call we had the PW status messaging as strongly RECOMMENDED only. The AD asked me to change it to a MUST. The label withdraw method was always a MUST. So if we had a problem with this text it should have been argued at , or before last call . Not now. Luca neil.2.harrison@bt.com wrote: >Tom...IMO this statement does nothing to help IETFs stature as a body >producing standards operators can confidently rely on. Simply being >backwards compatible with already implemented stuff (as a direct >consequence of 'rough consensus and running code') that is obviously not >correct is no excuse. Your argument boils down to saying ' we won't do >anything about it until its proved broken' is not acceptable IMO....esp >when it obviously not right in the 1st place. Just look at what >happened with OAM. 2+ years ago I can recall being clearly told this >was not required....then operational experience showed otherwise....now >its too late to properly get the base protocol structures/net-arch >right...so we are required (no choice) to accept more fixes. > >It really is not good enough IMO. > >regards, neil > > > >>-----Original Message----- >>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>Sent: 24 February 2005 15:54 >>To: David Allan >>Cc: 'Mustapha Aissaoui'; 'Luca Martini'; Harrison,N,Neil,IKM1 >>R; 'pwe3@ietf.org' >>Subject: Re: RESEND RE: [PWE3] Control protocol draft - >>section 5.3.1 change t o PW status. >> >> >> >> >> >> >>> I've never been happy with label withdraw, esp. when >>> >>> >>either AIS or >> >> >>>RDI termination at a PE is indicative of an AC fault and if not >>>ignored, withdrawl on RDI will ultimately lock down the PW (as >>>withdrawl escalates all faults to AIS at the far AC). >>> >>> I would agree with Mustapha's concerns, backwards >>> >>> >>compatibility with >> >> >>>somthing that is broken is not really a good idea. >>> >>> >> I have to disagree and agree with Luca's original >>assertion. There are too many deployments in the field that >>are working just fine to disallow this as an option going >>forward. Ultimately folks may choose to not configure this >>behavior once all of the status signaling is implemented, but >>we should not preclude those that are working today and want >>to keep with what they have. >> >> --Tom >> >> >> >> >> >> >>> cheers >>> Dave >>> >>> >>> >>>>>>Luca, >>>>>>However, it all appears that if the label withdraw PW status >>>>>> >>>>>> >>>>>method is >>>>> >>>>> >>>>>>used, then a label is withdrawn if say a AIS cell is >>>>>> >>>>>> >>>>>received from the >>>>> >>>>> >>>>>>local ATM network or LMI indicated a fault. Am I wrong? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>yes. This is correct, then the remote end would >>>>> >>>>> >>re-generate the AIS >> >> >>>>>alarm. >>>>> >>>>> >>>>> >>>>>>Also, how should we interpret the new text? Initially, you >>>>>> >>>>>> >>>>advertize >>>> >>>> >>>>>>the label regardless of the state of AC. Then, if the PW status >>>>>>negotiation results in the use of the label withdraw PW >>>>>> >>>>>> >>>>>status method, >>>>> >>>>> >>>>>>would you immediately withdraw the label because the AC is >>>>>> >>>>>> >>>>>not active? >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>That would be my understanding. Some state needs to be >>>>> >>>>> >>kept for this >> >> >>>>>PW, for the life of the LDP session, to indicate that the PW uses >>>>>label withdraw method. >>>>> >>>>> >>>>> >>>>> >>>>>>I would like to see a simplification to the procedures. The >>>>>> >>>>>> >>>>>reason why >>>>> >>>>> >>>>>>label withdrawal is to be avoided as much as possible is >>>>>> >>>>>> >>because it >> >> >>>>>>confuses a fault condition with an adiministrative >>>>>> >>>>>> >>>>>operation. We do not >>>>> >>>>> >>>>>>want to have the network react to some unstable CPE or >>>>>> >>>>>> >>L2 network >> >> >>>>>>condition. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>For this reason we have PW status TLV infrastructure. >>>>> >>>>> >>Remember that >> >> >>>>>this is a MUST implement, therefore this is what is going to be >>>>>used by ALL >>>>>PWE3 implementations. >>>>> >>>>> >>>>> >>>>>>I suggest that regardless of the PW status method used, >>>>>> >>>>>> >>a label is >> >> >>>>>>withdrawan only if the user configures the AC administrative >>>>>> >>>>>> >>>>>state to >>>>> >>>>> >>>>>>DOWN. Any other fault condition should raise an alarm to the >>>>>> >>>>>> >>>>>management >>>>> >>>>> >>>>>>system but should not cause a label withdrawal. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>This would break any status notification. >>>>>The intent is not to break current deployments. After all >>>>> >>>>> >>they must >> >> >>>>>be working fine with just the label withdraw method. >>>>>Whether this text is there or not , the implementations will >>>>>implement >>>>>label withdraw anyway. We all agree that if there is no label >>>>>advertisement the PW is down. >>>>>That is the main point. >>>>>Why are you so keen in disabling the backward compatibility ? >>>>>I would like this standard to be implemented, not the old >>>>>draft-martini. >>>>> >>>>>Luca >>>>> >>>>> >>>>> >>>>>>Mustapha. >>>>>> >>>>>>-----Original Message----- >>>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>>> >>>>>> >>>>>On Behalf Of >>>>> >>>>> >>>>>>Luca Martini >>>>>>Sent: Friday, February 18, 2005 10:45 AM >>>>>>To: neil.2.harrison@bt.com >>>>>>Cc: pwe3@ietf.org >>>>>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>>>>> >>>>>> >>>>>change to PW >>>>> >>>>> >>>>>>status. >>>>>> >>>>>>neil.2.harrison@bt.com wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Luca asked: Please let me know if you have any comments >>>>>>> >>>>>>> >>>>about this >>>> >>>> >>>>>>>text. >>>>>>> >>>>>>>Question: Is there is any inference in this text (or >>>>>>> >>>>>>> >>>>other text in >>>> >>>> >>>>>>>this draft, or in any other draft for that matter) that a >>>>>>> >>>>>>> >>>>>PW must be >>>>> >>>>> >>>>>>>taken down in response to a failure on an AC? If there is >>>>>>> >>>>>>> >>>>>then its wrong. >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>In the new PW status design, described here , the PW is >>>>>> >>>>>> >>not "taken >> >> >>>>>>down ", but instead attachment circuit status is >>>>>> >>>>>> >>>>communicated to the >>>> >>>> >>>>>>remote end of the PW. So the answer is no. Example ATM AIS >>>>>> >>>>>> >>>>>alarm. The >>>>> >>>>> >>>>>>AIS OAM cells will be passed along the PW , additionally a >>>>>> >>>>>> >>>>PW status >>>> >>>> >>>>>>TLV "interface Receive Fault" will also be transmitted in >>>>>> >>>>>> >>>>>the control >>>>> >>>>> >>>>>>protocol. >>>>>> >>>>>>Luca >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>One should NEVER take down a server layer trail in >>>>>>> >>>>>>> >>response to a >> >> >>>>>>>defect in some client layer link connection. Just >>>>>>> >>>>>>> >>think if we did >> >> >>>>>this for >>>>> >>>>> >>>>>>>all nested layer networks right down to optics! >>>>>>> >>>>>>>regards, Neil >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>>>>> >>>>>>>> >>>>>On Behalf >>>>> >>>>> >>>>>>>>Of Luca Martini >>>>>>>>Sent: 17 February 2005 23:35 >>>>>>>>To: PWE3 WG (E-mail) >>>>>>>>Subject: [PWE3] Control protocol draft - section 5.3.1 >>>>>>>> >>>>>>>> >>>>>change to PW >>>>> >>>>> >>>>>>>>status. >>>>>>>> >>>>>>>> >>>>>>>>In this section , we were asked to make the implementation >>>>>>>> >>>>>>>> >>>>>of the PW >>>>> >>>>> >>>>>>>>status messages/TLV mandatory. >>>>>>>>Also all "CE-facing port" terminology will be changed to >>>>>>>> >>>>>>>> >>>>>"attachment >>>>> >>>>> >>>>>>>>circuit". >>>>>>>> >>>>>>>>5.3.1. Use of Label Mappings. >>>>>>>> >>>>>>>> The PEs MUST send PW label mapping messages to their >>>>>>>> >>>>>>>> >>>>>peers as soon >>>>> >>>>> >>>>>>>>as >>>>>>>> the PW is configured and administratively enabled, >>>>>>>> >>>>>>>> >>>>regardless of >>>> >>>> >>>>>>>>the >>>>>>>> CE-facing interface state. The PW label should not be >>>>>>>> >>>>>>>> >>withdrawn >> >> >>>>>>>>unless the user administratively configures the >>>>>>>> >>>>>>>> >>>>>CE-facing interface >>>>> >>>>> >>>>>>>> down (or the PW configuration is deleted entirely). Using the >>>>>>>>procedures outlined in this section a simple label >>>>>>>> >>>>>>>> >>>>>withdraw method >>>>> >>>>> >>>>>>>> MAY also be supported as a primitive means of signaling >>>>>>>> >>>>>>>> >>>>>PW status. >>>>> >>>>> >>>>>>>>It >>>>>>>> is strongly RECOMMENDED that the PW status signaling >>>>>>>> >>>>>>>> >>procedures >> >> >>>>>>>>below be fully implemented. In any case if the Label >>>>>>>> >>>>>>>> >>mapping is >> >> >>>>>>>>not available the PW MUST be considered in the down state. >>>>>>>> >>>>>>>>will change to: >>>>>>>> >>>>>>>>5.3.1. Use of Label Mappings. >>>>>>>>The PEs MUST send PW label mapping messages to their peers >>>>>>>> >>>>>>>> >>>>>as soon as >>>>> >>>>> >>>>>>>>the PW is configured and administratively enabled, >>>>>>>> >>>>>>>> >>>>>regardless of the >>>>> >>>>> >>>>>>>>attachment circuit state. The PW label should not be >>>>>>>> >>>>>>>> >>>>>withdrawn unless >>>>> >>>>> >>>>>>>>the user administratively configures the CE-facing >>>>>>>> >>>>>>>> >>>>>interface down (or >>>>> >>>>> >>>>>>>>the PW configuration is deleted entirely). Using the >>>>>>>> >>>>>>>> >>procedures >> >> >>>>>>>>outlined in this section a simple label withdraw method >>>>>>>> >>>>>>>> >>>>>MUST also be >>>>> >>>>> >>>>>>>>supported as a primitive means of signaling PW status. In >>>>>>>> >>>>>>>> >>>>>any case if >>>>> >>>>> >>>>>>>>the Label mapping is not available the PW MUST be >>>>>>>> >>>>>>>> >>>>>considered in the >>>>> >>>>> >>>>>>>>down state. >>>>>>>> >>>>>>>>Once, the PW status negotiation procedures are completed >>>>>>>> >>>>>>>> >>>>>and if they >>>>> >>>>> >>>>>>>>result in the use of the label withdraw method for PW status >>>>>>>>communication, the label withdraw PW status method MUST be >>>>>>>> >>>>>>>> >>>>>used. This >>>>> >>>>> >>>>>>>>will result in the PW label mapping message being >>>>>>>> >>>>>>>> >>>>>advertised only if >>>>> >>>>> >>>>>>>>the attachment circuit becomes active. The PW status signaling >>>>>>>>procedures described in this section MUST be fully implemented. >>>>>>>> >>>>>>>> >>>>>>>>Please let me know if you have any comments about this >>>>>>>> >>>>>>>> >>text. Luca >> >> >>>>>>>>_______________________________________________ >>>>>>>>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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>_______________________________________________ >>>>>>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 >>>>> >>>>> >>>>> >>>>> >>>_______________________________________________ >>>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 27 15:58:25 2006 From: Luca Martini Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 10:30:57 -0700 Lines: 519 References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: neil.2.harrison@bt.com, pwe3@ietf.org, =?ISO-8859-1?Q?=27Benny_Ammitzb=F8ll=27?= , mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 18:29:27 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,114,1107752400"; d="scan'208"; a="38256216:sNHT26565862" User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: "Busschbach, Peter B (Peter)" In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 27f32072baa9c4fb41949212e86ea6d2 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA20363 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Busschbach, Peter B (Peter) wrote: > =20 > >>-----Original Message----- >>From: Benny Ammitzb=F8ll [mailto:Benny.Ammitzboell@tpack.net] >>Sent: Wednesday, February 23, 2005 4:29 AM >>To: Luca Martini; neil.2.harrison@bt.com >>Cc: pwe3@ietf.org; mustapha.aissaoui@alcatel.com >>Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 >>change to PW >>status. >> >> >>Sorry if I jump in in the middle of this, but I believe that=20 >>Neils point is >>that the PW is the server and what the PW carries inside is=20 >>the client. This >>also IMO means that the AC is client and the state of the AC=20 >>should not >>affect the server layer, i.e. the PW. >> >>I think it would help to stress more clearly in section 5.3.1 that the >>coupling between AC state and PW state is NOT the desired=20 >>behaviour, but it >>is only there because of backwards compatability with non-standard >>equipment. >> >>My proposal for a new text: >> >> The PEs MUST send PW label mapping messages to their peers=20 >>as soon as >> the PW is configured and administratively enabled,=20 >>regardless of the >> attachment circuit state. The PW label should not be=20 >>withdrawn unless >> the user administratively configures the PW down (or the=20 >>PW configuration >> is deleted entirely). If the Label mapping is not=20 >>available the PW MUST >> be considered in the down state. >> >> For backwards compatability a simple label withdraw method=20 >>MUST also be >> =20 >> > >I have made this point in an earlier email, but I think it is worth repe= ating. I believe that this MUST should be a MAY. > >Label mapping, label withdraw and the use of PW Status are all functions= that are implemented in software. Therefore, it may be true that there a= re legacy devices today that only support label withdraw, but there is no= reason why vendors would not be able to support PW Status in future soft= ware releases. PW Status is mandatory and future software releases must s= upport it to be standards-compliant. > >Considering the fact that PWE is a relatively new and rapidly expanding = technology, does anybody believe that five years from now there will be p= roducts in the field that were installed pre 2003 and that still run thei= r original R1 software load? > > > > =20 > Yes , I can agree with a MAY. This would allow backward compatibility=20 until it is no longer needed for migration. However I still would like to hear fro the rest f the WG. Luca > > > > =20 > >> supported as a legacy means of signaling PW status. When=20 >>the PW status >> negotiation procedures are completed and if they result in=20 >>not using the >> PW Status TVL, the label withdraw PW status method MUST be=20 >>used. This >> will result in the PW label mapping message being=20 >>advertised only if >> the attachment circuit becomes active. The PW status signaling >> procedures described in this section MUST be fully implemented. >> >>/Benny >> >> >>-----Original Message----- >>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of >>Luca Martini >>Sent: 22. februar 2005 20:35 >>To: neil.2.harrison@bt.com >>Cc: pwe3@ietf.org; mustapha.aissaoui@alcatel.com >>Subject: Re: [PWE3] Control protocol draft - section 5.3.1=20 >>change to PW >>status. >> >> >>neil.2.harrison@bt.com wrote: >> >> =20 >> >>>Mustapha, >>> >>>This is precisely why I raised this point.....but please do=20 >>> =20 >>> >>not overlook >> =20 >> >>>the more fundamantal point that 'defect events' in any client layer >>>should never result in 'events' in any server layer. One should not >>>violate principles like these just because its expedient. =20 >>> =20 >>> >>If everyone >> =20 >> >>>had taken this attitude we could, in theory, cause 'events' at the >>>optics layer (maybe in someone else's network even) for=20 >>> =20 >>> >>'defect events' >> =20 >> >>>in some client perhaps several layers removed (upwards). =20 >>> =20 >>> >>Clearly this >> =20 >> >>>is a nonsense. >>> >>>regards, Neil >>> >>> >>> >>> =20 >>> >>Neil, I agree, however the PW is not a client of the PW control >>protocol. I see the PW an adaptation of the=20 >>atm/frame/ethernet etc. to MPLS. >>So we are not causing an alarm in the RSVP LSP , or in the=20 >>IGP protocol..... >> >>Luca >> >> =20 >> >>>>-----Original Message----- >>>>From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] >>>>Sent: 22 February 2005 15:05 >>>>To: 'Luca Martini'; Harrison,N,Neil,IKM1 R >>>>Cc: pwe3@ietf.org >>>>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 >>>>change to PW status. >>>> >>>> >>>>Luca, >>>>However, it all appears that if the label withdraw PW status >>>>method is used, then a label is withdrawn if say a AIS cell >>>>is received from the local ATM network or LMI indicated a >>>>fault. Am I wrong? >>>> >>>>Also, how should we interpret the new text? Initially, you >>>>advertize the label regardless of the state of AC. Then, if >>>>the PW status negotiation results in the use of the label >>>>withdraw PW status method, would you immediately withdraw the >>>>label because the AC is not active? >>>> >>>>I would like to see a simplification to the procedures. The >>>>reason why label withdrawal is to be avoided as much as >>>>possible is because it confuses a fault condition with an >>>>adiministrative operation. We do not want to have the network >>>>react to some unstable CPE or L2 network condition. >>>> >>>>I suggest that regardless of the PW status method used, a >>>>label is withdrawan only if the user configures the AC >>>>administrative state to DOWN. Any other fault condition >>>>should raise an alarm to the management system but should not >>>>cause a label withdrawal. >>>> >>>>Mustapha. >>>> >>>>-----Original Message----- >>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >>>>Behalf Of Luca Martini >>>>Sent: Friday, February 18, 2005 10:45 AM >>>>To: neil.2.harrison@bt.com >>>>Cc: pwe3@ietf.org >>>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>>>change to PW status. >>>> >>>>neil.2.harrison@bt.com wrote: >>>> >>>> >>>> >>>> =20 >>>> >>>>>Luca asked: Please let me know if you have any comments about this >>>>>text. >>>>> >>>>>Question: Is there is any inference in this text (or other text in >>>>>this draft, or in any other draft for that matter) that a=20 >>>>> =20 >>>>> >>PW must be >> =20 >> >>>>>taken down in response to a failure on an AC? If there is >>>>> >>>>> >>>>> =20 >>>>> >>>>then its wrong. >>>> >>>> >>>> =20 >>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>In the new PW status design, described here , the PW is not >>>>"taken down ", but instead attachment circuit status is >>>>communicated to the remote end of the PW. So the answer is >>>>no. Example ATM AIS alarm. The AIS OAM cells will be passed >>>>along the PW , additionally a PW status TLV "interface >>>>Receive Fault" will also be transmitted in the control protocol. >>>> >>>>Luca >>>> >>>> >>>> >>>> =20 >>>> >>>>>One should NEVER take down a server layer trail in response >>>>> >>>>> >>>>> =20 >>>>> >>>>to a defect >>>> >>>> >>>> =20 >>>> >>>>>in some client layer link connection. Just think if we=20 >>>>> =20 >>>>> >>did this for >> =20 >> >>>>>all nested layer networks right down to optics! >>>>> >>>>>regards, Neil >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>>>-----Original Message----- >>>>>>From: pwe3-bounces@ietf.org=20 >>>>>> =20 >>>>>> >>[mailto:pwe3-bounces@ietf.org] On Behalf >> =20 >> >>>>>>Of Luca Martini >>>>>>Sent: 17 February 2005 23:35 >>>>>>To: PWE3 WG (E-mail) >>>>>>Subject: [PWE3] Control protocol draft - section 5.3.1=20 >>>>>> =20 >>>>>> >>change to PW >> =20 >> >>>>>>status. >>>>>> >>>>>> >>>>>>In this section , we were asked to make the=20 >>>>>> =20 >>>>>> >>implementation of the PW >> =20 >> >>>>>>status messages/TLV mandatory. >>>>>>Also all "CE-facing port" terminology will be changed to >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>"attachment >>>> >>>> >>>> =20 >>>> >>>>>>circuit". >>>>>> >>>>>>5.3.1. Use of Label Mappings. >>>>>> >>>>>> The PEs MUST send PW label mapping messages to their >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>peers as soon >>>> >>>> >>>> =20 >>>> >>>>>>as >>>>>> the PW is configured and administratively enabled, regardless of >>>>>>the >>>>>> CE-facing interface state. The PW label should not be withdrawn >>>>>> unless the user administratively configures the >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>CE-facing interface >>>> >>>> >>>> =20 >>>> >>>>>> down (or the PW configuration is deleted entirely). Using the >>>>>> procedures outlined in this section a simple label >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>withdraw method >>>> >>>> >>>> =20 >>>> >>>>>> MAY also be supported as a primitive means of signaling >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>PW status. >>>> >>>> >>>> =20 >>>> >>>>>>It >>>>>> is strongly RECOMMENDED that the PW status signaling procedures >>>>>>below >>>>>> be fully implemented. In any case if the Label mapping is not >>>>>> available the PW MUST be considered in the down state. >>>>>> >>>>>>will change to: >>>>>> >>>>>>5.3.1. Use of Label Mappings. >>>>>>The PEs MUST send PW label mapping messages to their peers >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>as soon as >>>> >>>> >>>> =20 >>>> >>>>>>the PW is configured and administratively enabled, >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>regardless of the >>>> >>>> >>>> =20 >>>> >>>>>>attachment circuit state. The PW label should not be >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>withdrawn unless >>>> >>>> >>>> =20 >>>> >>>>>>the user administratively configures the CE-facing >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>interface down (or >>>> >>>> >>>> =20 >>>> >>>>>>the PW configuration is deleted entirely). Using the procedures >>>>>>outlined in this section a simple label withdraw method >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>MUST also be >>>> >>>> >>>> =20 >>>> >>>>>>supported as a primitive means of signaling PW status. In >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>any case if >>>> >>>> >>>> =20 >>>> >>>>>>the Label mapping is not available the PW MUST be=20 >>>>>> =20 >>>>>> >>considered in the >> =20 >> >>>>>>down state. >>>>>> >>>>>>Once, the PW status negotiation procedures are completed=20 >>>>>> =20 >>>>>> >>and if they >> =20 >> >>>>>>result in the use of the label withdraw method for PW status >>>>>>communication, the label withdraw PW status method MUST be >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>used. This >>>> >>>> >>>> =20 >>>> >>>>>>will result in the PW label mapping message being >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>advertised only if >>>> >>>> >>>> =20 >>>> >>>>>>the attachment circuit becomes active. The PW status signaling >>>>>>procedures described in this section MUST be fully implemented. >>>>>> >>>>>> >>>>>>Please let me know if you have any comments about this text. Luca >>>>>> >>>>>>_______________________________________________ >>>>>>pwe3 mailing list >>>>>>pwe3@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>_______________________________________________ >>>>>pwe3 mailing list >>>>>pwe3@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>_______________________________________________ >>>>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 >> >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> =20 >> > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > =20 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Mustapha Aissaoui" Subject: RE: Control protocol draft - section 5.3.1 change to PW status. Date: Thu, 24 Feb 2005 12:42:11 -0500 Lines: 153 References: <0536FC9B908BEC4597EE721BE6A353890A9F1972@i2km07-ukbr.domain1.systemhost.net> Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 24 18:43:51 2005 To: , , , X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <0536FC9B908BEC4597EE721BE6A353890A9F1972@i2km07-ukbr.domain1.systemhost.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-index: AcUaUAon8Np6M512TvyiIsJJD/0J7QAMOvUAAAIPt4AAAS3CYA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Neil, I agree that the SH-PW has been designed as an adaptation function into a PSN. However, in theory this does not mean it cannot be considered a layer of its own. In ATM, AAL is both an adaptation function and a layer of its own. Though there was a lot of resistance to making it a full blown layer entity with OAM, etc., because it is redundant. Coming back to the issue in this email, if one uses N:1 cell mode encapsulation with a single ATM connection per PW, yes the ATM PW is strictly speaking not a peer to the ATM VC/VP. I was explaining that in that case, one may release the label if the AC administrative status changed to DOWN because of the 1-to-1 relationship. If one carries multiple VCs in a PW, then changing the Admin status of a single VC, or even all configured VCs, should not automatically cause a label withdrawal. This is because, the PW is still able to carry a newly configured VC. Mustapha. -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Thursday, February 24, 2005 11:05 AM To: Mustapha.Aissaoui@alcatel.com; hkulkarni@lucent.com; Shahram_Davari@pmc-sierra.com; lmartini@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to PW status. Mustapha, Mustapha Aissaoui wrote 24 February 2005 15:01 > > Rishi, > I am not sure you have read my response to your message last week. I > was telling you the case of N:1 VC-to-PW is hypthetical. The current > ATM draft only deals with a single VC per PW when using the N:1 cell > mode encapsulation encapsulation. In other words, the ATM VC and the > ATM PW are peers. NH=> This is incorrect. There are 2 MPLS LSPs. The top level LSP is not there for any primary considerations of 'hierarchy' it is a FORCED p2p construct to make sure there is demerging from any lower mp2p constructs. Note also that in a proper client/server case there is only a requirement for a single server layer construct, no matter how many clients are muxed into it, eg 63 VC_12 clients into a single server VC_4 in SDH say. However, it is still a server layer construct wrt to the (in this case) ATM client. There are NOT in any way peers. Note - if they were to be considered as peers, you would also have to have (for example) signaling protocol conversion between the partitions. In general however, peer-partition i/w is not a good idea...one has some chance for technologies belonging to the same network mode, but almost no chance for technologies belonging to differenmt modes (because of the function/feature mismatch). > The server layer is the PSN tunnel. NH=> Not strictly correct. The 'PSN tunnel' is a server construct to the higher LSP entity. However, the 2 LSPs are NOT seperate layer networks.....not sure if you get this, ring me if not clear....though you could check out MPLS func arch in G.8110. Final point. A SH-PW was not a layer network. It was an adaptation function between X and MPLS (or IP). MH-PWs are now changing this, ie a new layer network is now being created in all but name. regards, Neil > > Now, if one wants to implement a true N:1 VC-to-PW, then the PW > becomes a server layer to the ATM VCs. The PW is pre-established and > is used as a tunnel. In that case, you will not withdraw the PW label > in response to administrative or operational state of the individual > ATM VCs. > > Mustapha. > > -----Original Message----- > From: Kulkarni, Hrishikesh (Hrishikesh) [mailto:hkulkarni@lucent.com] > Sent: Thursday, February 24, 2005 4:04 AM > To: 'Mustapha Aissaoui'; 'Shahram Davari'; 'Luca Martini' > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to > PW status. > > Mustapha, > > The problem of when multiple AC are going through a singe N:1 > PWE3 remains unsolved. if we withdraw the label when one AC is admin > down, what about other AC. > > Rishi > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org > [mailto:pwe3-bounces@ietf.org]On Behalf Of > > Mustapha Aissaoui > > Sent: Wednesday, February 23, 2005 8:39 PM > > To: 'Shahram Davari'; 'Luca Martini' > > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to > > PW st atus. > > > > > > Shahram, > > This is why I asked that we should only withdraw the label > when the AC > > is administrativley DOWN when the label withdraw method is used. > > Operational status should be updated by AIS/RDI which gets passed > > transparently if the label is not whithdrawn. > > > > Mustapha. > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, February 23, 2005 9:45 AM > > To: 'Luca Martini'; Mustapha Aissaoui > > Cc: neil.2.harrison@bt.com; pwe3@ietf.org > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to > > PW st atus. > > > > Luca, > > > > > >Luca, > > > >However, it all appears that if the label withdraw PW status > > > method is used, > > > >then a label is withdrawn if say a AIS cell is received from > > > the local ATM > > > >network or LMI indicated a fault. Am I wrong? > > > > > > > > > > > > > > > yes. This is correct, then the remote end would > re-generate the AIS > > > alarm. > > > > > > > How does the other end know whether this is an administrative > > withdrwal for removing the service (in which case it should not > > generate > > AIS) or it is a > > withdrawal caused by a fault (in which case it should generate AIS)? > > > > -Shahram > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Thomas D. Nadeau" Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 13:21:39 -0500 Lines: 400 References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: neil.2.harrison@bt.com, Luca Martini , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, =?ISO-8859-1?Q?'Benny_Ammitzb=F8ll'?= X-From: pwe3-bounces@ietf.org Thu Feb 24 19:30:05 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,115,1107734400"; d="scan'208"; a="228856145:sNHT33372716" In-Reply-To: To: "Busschbach, Peter B (Peter)" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org On Feb 24, 2005, at 12:16 PM, Busschbach, Peter B (Peter) wrote: > > >> -----Original Message----- >> From: Benny Ammitzb=F8ll [mailto:Benny.Ammitzboell@tpack.net] >> Sent: Wednesday, February 23, 2005 4:29 AM >> To: Luca Martini; neil.2.harrison@bt.com >> Cc: pwe3@ietf.org; mustapha.aissaoui@alcatel.com >> Subject: RE: [PWE3] Control protocol draft - section 5.3.1 >> change to PW >> status. >> >> >> Sorry if I jump in in the middle of this, but I believe that >> Neils point is >> that the PW is the server and what the PW carries inside is >> the client. This >> also IMO means that the AC is client and the state of the AC >> should not >> affect the server layer, i.e. the PW. >> >> I think it would help to stress more clearly in section 5.3.1 that = the >> coupling between AC state and PW state is NOT the desired >> behaviour, but it >> is only there because of backwards compatability with non-standard >> equipment. >> >> My proposal for a new text: >> >> The PEs MUST send PW label mapping messages to their peers >> as soon as >> the PW is configured and administratively enabled, >> regardless of the >> attachment circuit state. The PW label should not be >> withdrawn unless >> the user administratively configures the PW down (or the >> PW configuration >> is deleted entirely). If the Label mapping is not >> available the PW MUST >> be considered in the down state. >> >> For backwards compatability a simple label withdraw method >> MUST also be > > I have made this point in an earlier email, but I think it is worth=20 > repeating. I believe that this MUST should be a MAY. Peter, This seems reasonable (and flexible) to me. In fact, I thought we all agreed to a MAY a while back. --Tom > > Label mapping, label withdraw and the use of PW Status are all=20 > functions that are implemented in software. Therefore, it may be true=20= > that there are legacy devices today that only support label withdraw,=20= > but there is no reason why vendors would not be able to support PW=20 > Status in future software releases. PW Status is mandatory and future=20= > software releases must support it to be standards-compliant. > > Considering the fact that PWE is a relatively new and rapidly=20 > expanding technology, does anybody believe that five years from now=20 > there will be products in the field that were installed pre 2003 and=20= > that still run their original R1 software load? > > > > > > > >> supported as a legacy means of signaling PW status. When >> the PW status >> negotiation procedures are completed and if they result in >> not using the >> PW Status TVL, the label withdraw PW status method MUST be >> used. This >> will result in the PW label mapping message being >> advertised only if >> the attachment circuit becomes active. The PW status signaling >> procedures described in this section MUST be fully implemented. >> >> /Benny >> >> >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf = Of >> Luca Martini >> Sent: 22. februar 2005 20:35 >> To: neil.2.harrison@bt.com >> Cc: pwe3@ietf.org; mustapha.aissaoui@alcatel.com >> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >> change to PW >> status. >> >> >> neil.2.harrison@bt.com wrote: >> >>> Mustapha, >>> >>> This is precisely why I raised this point.....but please do >> not overlook >>> the more fundamantal point that 'defect events' in any client layer >>> should never result in 'events' in any server layer. One should not >>> violate principles like these just because its expedient. >> If everyone >>> had taken this attitude we could, in theory, cause 'events' at the >>> optics layer (maybe in someone else's network even) for >> 'defect events' >>> in some client perhaps several layers removed (upwards). >> Clearly this >>> is a nonsense. >>> >>> regards, Neil >>> >>> >>> >> Neil, I agree, however the PW is not a client of the PW control >> protocol. I see the PW an adaptation of the >> atm/frame/ethernet etc. to MPLS. >> So we are not causing an alarm in the RSVP LSP , or in the >> IGP protocol..... >> >> Luca >> >>>> -----Original Message----- >>>> From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] >>>> Sent: 22 February 2005 15:05 >>>> To: 'Luca Martini'; Harrison,N,Neil,IKM1 R >>>> Cc: pwe3@ietf.org >>>> Subject: RE: [PWE3] Control protocol draft - section 5.3.1 >>>> change to PW status. >>>> >>>> >>>> Luca, >>>> However, it all appears that if the label withdraw PW status >>>> method is used, then a label is withdrawn if say a AIS cell >>>> is received from the local ATM network or LMI indicated a >>>> fault. Am I wrong? >>>> >>>> Also, how should we interpret the new text? Initially, you >>>> advertize the label regardless of the state of AC. Then, if >>>> the PW status negotiation results in the use of the label >>>> withdraw PW status method, would you immediately withdraw the >>>> label because the AC is not active? >>>> >>>> I would like to see a simplification to the procedures. The >>>> reason why label withdrawal is to be avoided as much as >>>> possible is because it confuses a fault condition with an >>>> adiministrative operation. We do not want to have the network >>>> react to some unstable CPE or L2 network condition. >>>> >>>> I suggest that regardless of the PW status method used, a >>>> label is withdrawan only if the user configures the AC >>>> administrative state to DOWN. Any other fault condition >>>> should raise an alarm to the management system but should not >>>> cause a label withdrawal. >>>> >>>> Mustapha. >>>> >>>> -----Original Message----- >>>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >>>> Behalf Of Luca Martini >>>> Sent: Friday, February 18, 2005 10:45 AM >>>> To: neil.2.harrison@bt.com >>>> Cc: pwe3@ietf.org >>>> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>>> change to PW status. >>>> >>>> neil.2.harrison@bt.com wrote: >>>> >>>> >>>> >>>>> Luca asked: Please let me know if you have any comments about = this >>>>> text. >>>>> >>>>> Question: Is there is any inference in this text (or other text = in >>>>> this draft, or in any other draft for that matter) that a >> PW must be >>>>> taken down in response to a failure on an AC? If there is >>>>> >>>>> >>>> then its wrong. >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>> In the new PW status design, described here , the PW is not >>>> "taken down ", but instead attachment circuit status is >>>> communicated to the remote end of the PW. So the answer is >>>> no. Example ATM AIS alarm. The AIS OAM cells will be passed >>>> along the PW , additionally a PW status TLV "interface >>>> Receive Fault" will also be transmitted in the control protocol. >>>> >>>> Luca >>>> >>>> >>>> >>>>> One should NEVER take down a server layer trail in response >>>>> >>>>> >>>> to a defect >>>> >>>> >>>>> in some client layer link connection. Just think if we >> did this for >>>>> all nested layer networks right down to optics! >>>>> >>>>> regards, Neil >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: pwe3-bounces@ietf.org >> [mailto:pwe3-bounces@ietf.org] On Behalf >>>>>> Of Luca Martini >>>>>> Sent: 17 February 2005 23:35 >>>>>> To: PWE3 WG (E-mail) >>>>>> Subject: [PWE3] Control protocol draft - section 5.3.1 >> change to PW >>>>>> status. >>>>>> >>>>>> >>>>>> In this section , we were asked to make the >> implementation of the PW >>>>>> status messages/TLV mandatory. >>>>>> Also all "CE-facing port" terminology will be changed to >>>>>> >>>>>> >>>> "attachment >>>> >>>> >>>>>> circuit". >>>>>> >>>>>> 5.3.1. Use of Label Mappings. >>>>>> >>>>>> The PEs MUST send PW label mapping messages to their >>>>>> >>>>>> >>>> peers as soon >>>> >>>> >>>>>> as >>>>>> the PW is configured and administratively enabled, regardless of >>>>>> the >>>>>> CE-facing interface state. The PW label should not be withdrawn >>>>>> unless the user administratively configures the >>>>>> >>>>>> >>>> CE-facing interface >>>> >>>> >>>>>> down (or the PW configuration is deleted entirely). Using the >>>>>> procedures outlined in this section a simple label >>>>>> >>>>>> >>>> withdraw method >>>> >>>> >>>>>> MAY also be supported as a primitive means of signaling >>>>>> >>>>>> >>>> PW status. >>>> >>>> >>>>>> It >>>>>> is strongly RECOMMENDED that the PW status signaling procedures >>>>>> below >>>>>> be fully implemented. In any case if the Label mapping is not >>>>>> available the PW MUST be considered in the down state. >>>>>> >>>>>> will change to: >>>>>> >>>>>> 5.3.1. Use of Label Mappings. >>>>>> The PEs MUST send PW label mapping messages to their peers >>>>>> >>>>>> >>>> as soon as >>>> >>>> >>>>>> the PW is configured and administratively enabled, >>>>>> >>>>>> >>>> regardless of the >>>> >>>> >>>>>> attachment circuit state. The PW label should not be >>>>>> >>>>>> >>>> withdrawn unless >>>> >>>> >>>>>> the user administratively configures the CE-facing >>>>>> >>>>>> >>>> interface down (or >>>> >>>> >>>>>> the PW configuration is deleted entirely). Using the procedures >>>>>> outlined in this section a simple label withdraw method >>>>>> >>>>>> >>>> MUST also be >>>> >>>> >>>>>> supported as a primitive means of signaling PW status. In >>>>>> >>>>>> >>>> any case if >>>> >>>> >>>>>> the Label mapping is not available the PW MUST be >> considered in the >>>>>> down state. >>>>>> >>>>>> Once, the PW status negotiation procedures are completed >> and if they >>>>>> result in the use of the label withdraw method for PW status >>>>>> communication, the label withdraw PW status method MUST be >>>>>> >>>>>> >>>> used. This >>>> >>>> >>>>>> will result in the PW label mapping message being >>>>>> >>>>>> >>>> advertised only if >>>> >>>> >>>>>> the attachment circuit becomes active. The PW status signaling >>>>>> procedures described in this section MUST be fully implemented. >>>>>> >>>>>> >>>>>> Please let me know if you have any comments about this text. Luca >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> >> >> >> _______________________________________________ >> 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 27 15:58:25 2006 From: Shahram Davari Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 10:37:43 -0800 Lines: 16 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, neil.2.harrison@bt.com, Luca Martini , mustapha.aissaoui@alcatel.com, 'Benny Ammitzboll' X-From: pwe3-bounces@ietf.org Thu Feb 24 19:35:35 2005 To: "'Thomas D. Nadeau'" , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org This is a reasonable suggestion. -Shahram > > I have made this point in an earlier email, but I think it is worth > > repeating. I believe that this MUST should be a MAY. > > Peter, > > This seems reasonable (and flexible) to me. In fact, > I thought we all agreed to a MAY a while back. > > --Tom > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 12:06:41 -0700 Lines: 49 References: <4B6D09F3B826D411A67300D0B706EFDE0115D4A0@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Thomas D. Nadeau'" , pwe3@ietf.org, 'Benny Ammitzboll' , "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 20:05:07 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115D4A0@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Excellent , it sound like we are converging. However we need to agree on the logic of this PW status procedure. If the PW status negotiation results in Label Withdraw method then : 1) we use label withdraw method ( MAY option ) 2) if label withdraw is not implemented , we disable the PW with a label release error message. 3) we do nothing. however in this case PW messaging would be broken. I think that we need #1 and #2 in the text with the corresponding error for #2 Do you agree ? Luca Shahram Davari wrote: >This is a reasonable suggestion. > >-Shahram > > > > >>>I have made this point in an earlier email, but I think it is worth >>>repeating. I believe that this MUST should be a MAY. >>> >>> >> Peter, >> >> This seems reasonable (and flexible) to me. In fact, >>I thought we all agreed to a MAY a while back. >> >> --Tom >> >> >> >> > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 14:08:23 -0500 Lines: 67 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'Thomas D. Nadeau'" , 'Benny Ammitzboll' , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Thu Feb 24 20:05:58 2005 To: "'Luca Martini'" , Shahram Davari X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Sounds good to me. > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Thursday, February 24, 2005 2:07 PM > To: Shahram Davari > Cc: 'Thomas D. Nadeau'; Busschbach, Peter B (Peter); pwe3@ietf.org; > neil.2.harrison@bt.com; mustapha.aissaoui@alcatel.com; 'Benny > Ammitzboll' > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Excellent , it sound like we are converging. > However we need to agree on the logic of this PW status procedure. > If the PW status negotiation results in Label Withdraw method then : > > 1) we use label withdraw method ( MAY option ) > 2) if label withdraw is not implemented , we disable the PW > with a label > release error message. > 3) we do nothing. however in this case PW messaging would be broken. > > I think that we need #1 and #2 in the text with the > corresponding error > for #2 > > Do you agree ? > > Luca > > > > > Shahram Davari wrote: > > >This is a reasonable suggestion. > > > >-Shahram > > > > > > > > > >>>I have made this point in an earlier email, but I think it > is worth > >>>repeating. I believe that this MUST should be a MAY. > >>> > >>> > >> Peter, > >> > >> This seems reasonable (and flexible) to me. In fact, > >>I thought we all agreed to a MAY a while back. > >> > >> --Tom > >> > >> > >> > >> > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Thomas D. Nadeau" Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 14:51:34 -0500 Lines: 57 References: <4B6D09F3B826D411A67300D0B706EFDE0115D4A0@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> <421E25C1.30401@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: Shahram Davari , pwe3@ietf.org, 'Benny Ammitzboll' , "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 20:50:01 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== In-Reply-To: <421E25C1.30401@cisco.com> To: Luca Martini X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Cool with me. So I think it should be worded like: If the PW status negotiation results in Label Withdraw method then you SHOULD use either 1) label withdraw method, or 2) if label withdraw is not implemented, we disable the PW with a label release error message. --tom > Excellent , it sound like we are converging. > However we need to agree on the logic of this PW status procedure. > If the PW status negotiation results in Label Withdraw method then : > > 1) we use label withdraw method ( MAY option ) > 2) if label withdraw is not implemented , we disable the PW with a > label release error message. > 3) we do nothing. however in this case PW messaging would be broken. > > I think that we need #1 and #2 in the text with the corresponding > error for #2 > > Do you agree ? > > Luca > > > > > Shahram Davari wrote: > >> This is a reasonable suggestion. >> >> -Shahram >> >> >> >>>> I have made this point in an earlier email, but I think it is worth >>>> repeating. I believe that this MUST should be a MAY. >>>> >>> Peter, >>> >>> This seems reasonable (and flexible) to me. In fact, >>> I thought we all agreed to a MAY a while back. >>> >>> --Tom >>> >>> >>> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Shahram Davari Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 11:56:31 -0800 Lines: 74 Mime-Version: 1.0 Content-Type: text/plain Cc: neil.2.harrison@bt.com, "Busschbach, Peter B $Peter$" , pwe3@ietf.org, 'Benny Ammitzboll' , mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 20:59:34 2005 To: "'Thomas D. Nadeau'" , Luca Martini X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org How can the negotiation result in Label Withdrawal, if it is not implemented? > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, February 24, 2005 2:52 PM > To: Luca Martini > Cc: 'Benny Ammitzboll'; Shahram Davari; pwe3@ietf.org; > mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > Busschbach, Peter > B (Peter) > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > > Cool with me. So I think it should be worded > like: > > If the PW status negotiation results in Label Withdraw method then > you SHOULD use either 1) label withdraw method, or 2) if > label withdraw is not implemented, we disable the PW with a label > release error message. > > --tom > > > > Excellent , it sound like we are converging. > > However we need to agree on the logic of this PW status procedure. > > If the PW status negotiation results in Label Withdraw method then : > > > > 1) we use label withdraw method ( MAY option ) > > 2) if label withdraw is not implemented , we disable the PW with a > > label release error message. > > 3) we do nothing. however in this case PW messaging would be broken. > > > > I think that we need #1 and #2 in the text with the corresponding > > error for #2 > > > > Do you agree ? > > > > Luca > > > > > > > > > > Shahram Davari wrote: > > > >> This is a reasonable suggestion. > >> > >> -Shahram > >> > >> > >> > >>>> I have made this point in an earlier email, but I think > it is worth > >>>> repeating. I believe that this MUST should be a MAY. > >>>> > >>> Peter, > >>> > >>> This seems reasonable (and flexible) to me. In fact, > >>> I thought we all agreed to a MAY a while back. > >>> > >>> --Tom > >>> > >>> > >>> > >> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pwe3 > >> > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 13:43:28 -0700 Lines: 101 References: <6733C768256DEC42A72BAFEFA9CF06D20B4918E8@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: neil.2.harrison@bt.com, 'Shahram Davari' , pwe3@ietf.org, 'Mustapha Aissaoui' X-From: pwe3-bounces@ietf.org Thu Feb 24 21:40:25 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: "Kulkarni, Hrishikesh (Hrishikesh)" In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D20B4918E8@ii0015exch002u.iprc.lucent.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Kulkarni, Hrishikesh (Hrishikesh) wrote: >Mustapha, > >The problem of when multiple AC are going through a singe N:1 PWE3 remains >unsolved. >if we withdraw the label when one AC is admin down, what about other AC. > >Rishi > > > > That PW type has not been defined. So once it is defined the problem can be solved. Luca >>-----Original Message----- >>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of >>Mustapha Aissaoui >>Sent: Wednesday, February 23, 2005 8:39 PM >>To: 'Shahram Davari'; 'Luca Martini' >>Cc: neil.2.harrison@bt.com; pwe3@ietf.org >>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 >>change to PW >>st atus. >> >> >>Shahram, >>This is why I asked that we should only withdraw the label >>when the AC is >>administrativley DOWN when the label withdraw method is used. >>Operational >>status should be updated by AIS/RDI which gets passed >>transparently if the >>label is not whithdrawn. >> >>Mustapha. >> >>-----Original Message----- >>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>Sent: Wednesday, February 23, 2005 9:45 AM >>To: 'Luca Martini'; Mustapha Aissaoui >>Cc: neil.2.harrison@bt.com; pwe3@ietf.org >>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 >>change to PW st >>atus. >> >>Luca, >> >> >> >>>>Luca, >>>>However, it all appears that if the label withdraw PW status >>>> >>>> >>>method is used, >>> >>> >>>>then a label is withdrawn if say a AIS cell is received from >>>> >>>> >>>the local ATM >>> >>> >>>>network or LMI indicated a fault. Am I wrong? >>>> >>>> >>>> >>>> >>>> >>>yes. This is correct, then the remote end would re-generate the AIS >>>alarm. >>> >>> >>> >>How does the other end know whether this is an administrative >>withdrwal for >>removing the service (in which case it should not generate >>AIS) or it is a >>withdrawal caused by a fault (in which case it should generate AIS)? >> >>-Shahram >> >> >> >>_______________________________________________ >>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 27 15:58:25 2006 From: Luca Martini Subject: Re: RESEND RE: Control protocol draft - section 5.3.1 change t o PW status. Date: Thu, 24 Feb 2005 13:46:12 -0700 Lines: 445 References: <87AC5F88F03E6249AEA68D40BD3E00BE03192D68@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'neil.2.harrison@bt.com'" , "'pwe3@ietf.org'" , 'Mustapha Aissaoui' X-From: pwe3-bounces@ietf.org Thu Feb 24 21:43:05 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: David Allan In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE03192D68@zcarhxm2.corp.nortel.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org David Allan wrote: > > I've never been happy with label withdraw, esp. when either > AIS or RDI termination at a PE is indicative of an AC fault > and if not ignored, withdrawl on RDI will ultimately lock > down the PW (as withdrawl escalates all faults to AIS at the far AC). > > > Yes I agree. I only meant withdraw on AIS, is that not what is specified in the atm document ? Luca > I would agree with Mustapha's concerns, backwards > compatibility with somthing that is broken is not really a good idea. > > cheers > Dave > > > >>>>Luca, >>>>However, it all appears that if the label withdraw PW status >>>> >>>> >>>method is >>> >>> >>>>used, then a label is withdrawn if say a AIS cell is >>>> >>>> >>>received from the >>> >>> >>>>local ATM network or LMI indicated a fault. Am I wrong? >>>> >>>> >>>> >>>> >>>> >>>yes. This is correct, then the remote end would re-generate >>>the AIS alarm. >>> >>> >>> >>>>Also, how should we interpret the new text? Initially, you >>>> >>>> >>advertize >> >> >>>>the label regardless of the state of AC. Then, if the PW status >>>>negotiation results in the use of the label withdraw PW >>>> >>>> >>>status method, >>> >>> >>>>would you immediately withdraw the label because the AC is >>>> >>>> >>>not active? >>> >>> >>>> >>>> >>>> >>>> >>>That would be my understanding. Some state needs to be kept >>>for this PW, >>>for the life of the LDP session, to indicate that the PW uses label >>>withdraw method. >>> >>> >>> >>> >>>>I would like to see a simplification to the procedures. The >>>> >>>> >>>reason why >>> >>> >>>>label withdrawal is to be avoided as much as possible is because it >>>>confuses a fault condition with an adiministrative >>>> >>>> >>>operation. We do not >>> >>> >>>>want to have the network react to some unstable CPE or L2 network >>>>condition. >>>> >>>> >>>> >>>> >>>> >>>For this reason we have PW status TLV infrastructure. >>>Remember that this >>>is a MUST implement, therefore this is what is going to be >>>used by ALL >>>PWE3 implementations. >>> >>> >>> >>>>I suggest that regardless of the PW status method used, a label is >>>>withdrawan only if the user configures the AC administrative >>>> >>>> >>>state to >>> >>> >>>>DOWN. Any other fault condition should raise an alarm to the >>>> >>>> >>>management >>> >>> >>>>system but should not cause a label withdrawal. >>>> >>>> >>>> >>>> >>>> >>>This would break any status notification. >>>The intent is not to break current deployments. After all >>>they must be >>>working fine with just the label withdraw method. >>>Whether this text is there or not , the implementations will >>>implement >>>label withdraw anyway. We all agree that if there is no label >>>advertisement the PW is down. >>>That is the main point. >>>Why are you so keen in disabling the backward compatibility ? >>>I would like this standard to be implemented, not the old >>>draft-martini. >>> >>>Luca >>> >>> >>> >>>>Mustapha. >>>> >>>>-----Original Message----- >>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>> >>>> >>>On Behalf Of >>> >>> >>>>Luca Martini >>>>Sent: Friday, February 18, 2005 10:45 AM >>>>To: neil.2.harrison@bt.com >>>>Cc: pwe3@ietf.org >>>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>>> >>>> >>>change to PW >>> >>> >>>>status. >>>> >>>>neil.2.harrison@bt.com wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Luca asked: Please let me know if you have any comments >>>>> >>>>> >>about this >> >> >>>>>text. >>>>> >>>>>Question: Is there is any inference in this text (or >>>>> >>>>> >>other text in >> >> >>>>>this draft, or in any other draft for that matter) that a >>>>> >>>>> >>>PW must be >>> >>> >>>>>taken down in response to a failure on an AC? If there is >>>>> >>>>> >>>then its wrong. >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>In the new PW status design, described here , the PW is not "taken >>>>down ", but instead attachment circuit status is >>>> >>>> >>communicated to the >> >> >>>>remote end of the PW. So the answer is no. Example ATM AIS >>>> >>>> >>>alarm. The >>> >>> >>>>AIS OAM cells will be passed along the PW , additionally a >>>> >>>> >>PW status >> >> >>>>TLV "interface Receive Fault" will also be transmitted in >>>> >>>> >>>the control >>> >>> >>>>protocol. >>>> >>>>Luca >>>> >>>> >>>> >>>> >>>> >>>>>One should NEVER take down a server layer trail in response to a >>>>>defect >>>>>in some client layer link connection. Just think if we did >>>>> >>>>> >>>this for >>> >>> >>>>>all nested layer networks right down to optics! >>>>> >>>>>regards, Neil >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] >>>>>> >>>>>> >>>On Behalf >>> >>> >>>>>>Of Luca Martini >>>>>>Sent: 17 February 2005 23:35 >>>>>>To: PWE3 WG (E-mail) >>>>>>Subject: [PWE3] Control protocol draft - section 5.3.1 >>>>>> >>>>>> >>>change to PW >>> >>> >>>>>>status. >>>>>> >>>>>> >>>>>>In this section , we were asked to make the implementation >>>>>> >>>>>> >>>of the PW >>> >>> >>>>>>status messages/TLV mandatory. >>>>>>Also all "CE-facing port" terminology will be changed to >>>>>> >>>>>> >>>"attachment >>> >>> >>>>>>circuit". >>>>>> >>>>>>5.3.1. Use of Label Mappings. >>>>>> >>>>>> The PEs MUST send PW label mapping messages to their >>>>>> >>>>>> >>>peers as soon >>> >>> >>>>>>as >>>>>> the PW is configured and administratively enabled, >>>>>> >>>>>> >>regardless of >> >> >>>>>>the >>>>>> CE-facing interface state. The PW label should not be withdrawn >>>>>> unless the user administratively configures the >>>>>> >>>>>> >>>CE-facing interface >>> >>> >>>>>> down (or the PW configuration is deleted entirely). Using the >>>>>>procedures outlined in this section a simple label >>>>>> >>>>>> >>>withdraw method >>> >>> >>>>>> MAY also be supported as a primitive means of signaling >>>>>> >>>>>> >>>PW status. >>> >>> >>>>>>It >>>>>> is strongly RECOMMENDED that the PW status signaling procedures >>>>>>below >>>>>> be fully implemented. In any case if the Label mapping is not >>>>>> available the PW MUST be considered in the down state. >>>>>> >>>>>>will change to: >>>>>> >>>>>>5.3.1. Use of Label Mappings. >>>>>>The PEs MUST send PW label mapping messages to their peers >>>>>> >>>>>> >>>as soon as >>> >>> >>>>>>the PW is configured and administratively enabled, >>>>>> >>>>>> >>>regardless of the >>> >>> >>>>>>attachment circuit state. The PW label should not be >>>>>> >>>>>> >>>withdrawn unless >>> >>> >>>>>>the user administratively configures the CE-facing >>>>>> >>>>>> >>>interface down (or >>> >>> >>>>>>the PW configuration is deleted entirely). Using the procedures >>>>>>outlined in this section a simple label withdraw method >>>>>> >>>>>> >>>MUST also be >>> >>> >>>>>>supported as a primitive means of signaling PW status. In >>>>>> >>>>>> >>>any case if >>> >>> >>>>>>the Label mapping is not available the PW MUST be >>>>>> >>>>>> >>>considered in the >>> >>> >>>>>>down state. >>>>>> >>>>>>Once, the PW status negotiation procedures are completed >>>>>> >>>>>> >>>and if they >>> >>> >>>>>>result in the use of the label withdraw method for PW status >>>>>>communication, the label withdraw PW status method MUST be >>>>>> >>>>>> >>>used. This >>> >>> >>>>>>will result in the PW label mapping message being >>>>>> >>>>>> >>>advertised only if >>> >>> >>>>>>the attachment circuit becomes active. The PW status signaling >>>>>>procedures described in this section MUST be fully implemented. >>>>>> >>>>>> >>>>>>Please let me know if you have any comments about this text. Luca >>>>>> >>>>>>_______________________________________________ >>>>>>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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>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 >>> >>> >>> >>> > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Andrew G. Malis" Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 15:50:04 -0500 Lines: 43 References: <4B6D09F3B826D411A67300D0B706EFDE0115D4A0@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> <421E25C1.30401@cisco.com> <461e0dd10eadb3895288659d38cadb11@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Shahram Davari , pwe3@ietf.org, 'Benny Ammitzboll' , "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, Luca Martini , mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 21:47:00 2005 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: "Thomas D. Nadeau" In-Reply-To: <461e0dd10eadb3895288659d38cadb11@cisco.com> References: <4B6D09F3B826D411A67300D0B706EFDE0115D4A0@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> <421E25C1.30401@cisco.com> <461e0dd10eadb3895288659d38cadb11@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org The SHOULD in Tom's text below needs to be a MUST, since if the negotiation results in using the Withdraw method, then you MUST follow Tom's algorithm. I would also prefer that implementations SHOULD implement Withdraw for backwards compatibility, rather than MAY, to encourage backwards compatibility without actually requiring it. When the Proposed Standard goes for Draft Standard, we can think about lessening the SHOULD to a MAY (or even removing it), since hopefully at that point the installed base would have migrated to the RFC. Cheers, Andy ------------ At 2/24/2005 02:51 PM -0500, Thomas D. Nadeau wrote: > Cool with me. So I think it should be worded >like: > >If the PW status negotiation results in Label Withdraw method then >you SHOULD use either 1) label withdraw method, or 2) if >label withdraw is not implemented, we disable the PW with a label >release error message. > > --tom > > >>Excellent , it sound like we are converging. >>However we need to agree on the logic of this PW status procedure. >>If the PW status negotiation results in Label Withdraw method then : >> >>1) we use label withdraw method ( MAY option ) >>2) if label withdraw is not implemented , we disable the PW with a label >>release error message. >>3) we do nothing. however in this case PW messaging would be broken. >> >>I think that we need #1 and #2 in the text with the corresponding error >>for #2 >> >>Do you agree ? >> >>Luca From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 16:50:32 -0500 Lines: 96 Mime-Version: 1.0 Content-Type: text/plain Cc: neil.2.harrison@bt.com, "Busschbach, Peter B $Peter$" , pwe3@ietf.org, 'Benny Ammitzboll' , mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 22:49:37 2005 To: "'Shahram Davari'" , "'Thomas D. Nadeau'" , Luca Martini X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Hi Shahram, See 5.3.3: Pseudowire Status Negotiation Procedures. Peter > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, February 24, 2005 2:57 PM > To: 'Thomas D. Nadeau'; Luca Martini > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; mustapha.aissaoui@alcatel.com; > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > How can the negotiation result in Label Withdrawal, if it is > not implemented? > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Thursday, February 24, 2005 2:52 PM > > To: Luca Martini > > Cc: 'Benny Ammitzboll'; Shahram Davari; pwe3@ietf.org; > > mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > > Busschbach, Peter > > B (Peter) > > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > > change to PW > > st atus. > > > > > > > > Cool with me. So I think it should be worded > > like: > > > > If the PW status negotiation results in Label Withdraw method then > > you SHOULD use either 1) label withdraw method, or 2) if > > label withdraw is not implemented, we disable the PW with a label > > release error message. > > > > --tom > > > > > > > Excellent , it sound like we are converging. > > > However we need to agree on the logic of this PW status procedure. > > > If the PW status negotiation results in Label Withdraw > method then : > > > > > > 1) we use label withdraw method ( MAY option ) > > > 2) if label withdraw is not implemented , we disable the > PW with a > > > label release error message. > > > 3) we do nothing. however in this case PW messaging would > be broken. > > > > > > I think that we need #1 and #2 in the text with the corresponding > > > error for #2 > > > > > > Do you agree ? > > > > > > Luca > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > >> This is a reasonable suggestion. > > >> > > >> -Shahram > > >> > > >> > > >> > > >>>> I have made this point in an earlier email, but I think > > it is worth > > >>>> repeating. I believe that this MUST should be a MAY. > > >>>> > > >>> Peter, > > >>> > > >>> This seems reasonable (and flexible) to me. In fact, > > >>> I thought we all agreed to a MAY a while back. > > >>> > > >>> --Tom > > >>> > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> pwe3 mailing list > > >> pwe3@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/pwe3 > > >> > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "David Allan" Subject: RE: RESEND RE: Control protocol draft - section 5.3.1 chan ge t o PW status. Date: Thu, 24 Feb 2005 16:55:08 -0500 Lines: 474 Cc: "'neil.2.harrison@bt.com'" , "'pwe3@ietf.org'" , 'Mustapha Aissaoui' X-From: pwe3-bounces@ietf.org Thu Feb 24 22:52:22 2005 To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: b612707e1a3f67df80ae89cdab1ba981 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Hi Luca: Technically if withrawal means broken, then both AIS and RDI mean broken. Only withdrawing on AIS has problems... rgds Dave > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Thursday, February 24, 2005 3:46 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: 'Mustapha Aissaoui'; 'neil.2.harrison@bt.com'; 'pwe3@ietf.org' > Subject: Re: RESEND RE: [PWE3] Control protocol draft - > section 5.3.1 change t o PW status. > > > David Allan wrote: > > > > > I've never been happy with label withdraw, esp. when either > > AIS or RDI termination at a PE is indicative of an AC fault > > and if not ignored, withdrawl on RDI will ultimately lock > > down the PW (as withdrawl escalates all faults to AIS at > the far AC). > > > > > > > Yes I agree. > I only meant withdraw on AIS, is that not what is specified > in the atm > document ? > Luca > > > > I would agree with Mustapha's concerns, backwards > > compatibility with somthing that is broken is not really a > good idea. > > > > cheers > > Dave > > > > > > > >>>>Luca, > >>>>However, it all appears that if the label withdraw PW status > >>>> > >>>> > >>>method is > >>> > >>> > >>>>used, then a label is withdrawn if say a AIS cell is > >>>> > >>>> > >>>received from the > >>> > >>> > >>>>local ATM network or LMI indicated a fault. Am I wrong? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>yes. This is correct, then the remote end would > re-generate the AIS > >>>alarm. > >>> > >>> > >>> > >>>>Also, how should we interpret the new text? Initially, you > >>>> > >>>> > >>advertize > >> > >> > >>>>the label regardless of the state of AC. Then, if the PW status > >>>>negotiation results in the use of the label withdraw PW > >>>> > >>>> > >>>status method, > >>> > >>> > >>>>would you immediately withdraw the label because the AC is > >>>> > >>>> > >>>not active? > >>> > >>> > >>>> > >>>> > >>>> > >>>> > >>>That would be my understanding. Some state needs to be > kept for this > >>>PW, for the life of the LDP session, to indicate that the PW uses > >>>label withdraw method. > >>> > >>> > >>> > >>> > >>>>I would like to see a simplification to the procedures. The > >>>> > >>>> > >>>reason why > >>> > >>> > >>>>label withdrawal is to be avoided as much as possible is > because it > >>>>confuses a fault condition with an adiministrative > >>>> > >>>> > >>>operation. We do not > >>> > >>> > >>>>want to have the network react to some unstable CPE or L2 network > >>>>condition. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>For this reason we have PW status TLV infrastructure. > Remember that > >>>this is a MUST implement, therefore this is what is going to be > >>>used by ALL > >>>PWE3 implementations. > >>> > >>> > >>> > >>>>I suggest that regardless of the PW status method used, a > label is > >>>>withdrawan only if the user configures the AC administrative > >>>> > >>>> > >>>state to > >>> > >>> > >>>>DOWN. Any other fault condition should raise an alarm to the > >>>> > >>>> > >>>management > >>> > >>> > >>>>system but should not cause a label withdrawal. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>This would break any status notification. > >>>The intent is not to break current deployments. After all > they must > >>>be working fine with just the label withdraw method. > >>>Whether this text is there or not , the implementations will > >>>implement > >>>label withdraw anyway. We all agree that if there is no label > >>>advertisement the PW is down. > >>>That is the main point. > >>>Why are you so keen in disabling the backward compatibility ? > >>>I would like this standard to be implemented, not the old > >>>draft-martini. > >>> > >>>Luca > >>> > >>> > >>> > >>>>Mustapha. > >>>> > >>>>-----Original Message----- > >>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>>> > >>>> > >>>On Behalf Of > >>> > >>> > >>>>Luca Martini > >>>>Sent: Friday, February 18, 2005 10:45 AM > >>>>To: neil.2.harrison@bt.com > >>>>Cc: pwe3@ietf.org > >>>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > >>>> > >>>> > >>>change to PW > >>> > >>> > >>>>status. > >>>> > >>>>neil.2.harrison@bt.com wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Luca asked: Please let me know if you have any comments > >>>>> > >>>>> > >>about this > >> > >> > >>>>>text. > >>>>> > >>>>>Question: Is there is any inference in this text (or > >>>>> > >>>>> > >>other text in > >> > >> > >>>>>this draft, or in any other draft for that matter) that a > >>>>> > >>>>> > >>>PW must be > >>> > >>> > >>>>>taken down in response to a failure on an AC? If there is > >>>>> > >>>>> > >>>then its wrong. > >>> > >>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>In the new PW status design, described here , the PW is > not "taken > >>>>down ", but instead attachment circuit status is > >>>> > >>>> > >>communicated to the > >> > >> > >>>>remote end of the PW. So the answer is no. Example ATM AIS > >>>> > >>>> > >>>alarm. The > >>> > >>> > >>>>AIS OAM cells will be passed along the PW , additionally a > >>>> > >>>> > >>PW status > >> > >> > >>>>TLV "interface Receive Fault" will also be transmitted in > >>>> > >>>> > >>>the control > >>> > >>> > >>>>protocol. > >>>> > >>>>Luca > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>One should NEVER take down a server layer trail in response to a > >>>>>defect in some client layer link connection. Just think > if we did > >>>>> > >>>>> > >>>this for > >>> > >>> > >>>>>all nested layer networks right down to optics! > >>>>> > >>>>>regards, Neil > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] > >>>>>> > >>>>>> > >>>On Behalf > >>> > >>> > >>>>>>Of Luca Martini > >>>>>>Sent: 17 February 2005 23:35 > >>>>>>To: PWE3 WG (E-mail) > >>>>>>Subject: [PWE3] Control protocol draft - section 5.3.1 > >>>>>> > >>>>>> > >>>change to PW > >>> > >>> > >>>>>>status. > >>>>>> > >>>>>> > >>>>>>In this section , we were asked to make the implementation > >>>>>> > >>>>>> > >>>of the PW > >>> > >>> > >>>>>>status messages/TLV mandatory. > >>>>>>Also all "CE-facing port" terminology will be changed to > >>>>>> > >>>>>> > >>>"attachment > >>> > >>> > >>>>>>circuit". > >>>>>> > >>>>>>5.3.1. Use of Label Mappings. > >>>>>> > >>>>>> The PEs MUST send PW label mapping messages to their > >>>>>> > >>>>>> > >>>peers as soon > >>> > >>> > >>>>>>as > >>>>>> the PW is configured and administratively enabled, > >>>>>> > >>>>>> > >>regardless of > >> > >> > >>>>>>the > >>>>>> CE-facing interface state. The PW label should not be > withdrawn > >>>>>>unless the user administratively configures the > >>>>>> > >>>>>> > >>>CE-facing interface > >>> > >>> > >>>>>> down (or the PW configuration is deleted entirely). Using the > >>>>>>procedures outlined in this section a simple label > >>>>>> > >>>>>> > >>>withdraw method > >>> > >>> > >>>>>> MAY also be supported as a primitive means of signaling > >>>>>> > >>>>>> > >>>PW status. > >>> > >>> > >>>>>>It > >>>>>> is strongly RECOMMENDED that the PW status signaling > procedures > >>>>>>below be fully implemented. In any case if the Label > mapping is > >>>>>>not available the PW MUST be considered in the down state. > >>>>>> > >>>>>>will change to: > >>>>>> > >>>>>>5.3.1. Use of Label Mappings. > >>>>>>The PEs MUST send PW label mapping messages to their peers > >>>>>> > >>>>>> > >>>as soon as > >>> > >>> > >>>>>>the PW is configured and administratively enabled, > >>>>>> > >>>>>> > >>>regardless of the > >>> > >>> > >>>>>>attachment circuit state. The PW label should not be > >>>>>> > >>>>>> > >>>withdrawn unless > >>> > >>> > >>>>>>the user administratively configures the CE-facing > >>>>>> > >>>>>> > >>>interface down (or > >>> > >>> > >>>>>>the PW configuration is deleted entirely). Using the procedures > >>>>>>outlined in this section a simple label withdraw method > >>>>>> > >>>>>> > >>>MUST also be > >>> > >>> > >>>>>>supported as a primitive means of signaling PW status. In > >>>>>> > >>>>>> > >>>any case if > >>> > >>> > >>>>>>the Label mapping is not available the PW MUST be > >>>>>> > >>>>>> > >>>considered in the > >>> > >>> > >>>>>>down state. > >>>>>> > >>>>>>Once, the PW status negotiation procedures are completed > >>>>>> > >>>>>> > >>>and if they > >>> > >>> > >>>>>>result in the use of the label withdraw method for PW status > >>>>>>communication, the label withdraw PW status method MUST be > >>>>>> > >>>>>> > >>>used. This > >>> > >>> > >>>>>>will result in the PW label mapping message being > >>>>>> > >>>>>> > >>>advertised only if > >>> > >>> > >>>>>>the attachment circuit becomes active. The PW status signaling > >>>>>>procedures described in this section MUST be fully implemented. > >>>>>> > >>>>>> > >>>>>>Please let me know if you have any comments about this > text. Luca > >>>>>> > >>>>>>_______________________________________________ > >>>>>>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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>_______________________________________________ > >>>>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 > >>> > >>> > >>> > >>> > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 16:56:03 -0500 Lines: 68 Mime-Version: 1.0 Content-Type: text/plain Cc: Shahram Davari , pwe3@ietf.org, 'Benny Ammitzboll' , "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, Luca Martini , mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Thu Feb 24 22:54:22 2005 To: "'Andrew G. Malis'" , "Thomas D. Nadeau" X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org I agree with Andy's proposal. Peter > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Thursday, February 24, 2005 3:50 PM > To: Thomas D. Nadeau > Cc: Luca Martini; Shahram Davari; pwe3@ietf.org; 'Benny Ammitzboll'; > Busschbach, Peter B (Peter); neil.2.harrison@bt.com; > mustapha.aissaoui@alcatel.com > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > The SHOULD in Tom's text below needs to be a MUST, since if > the negotiation > results in using the Withdraw method, then you MUST follow > Tom's algorithm. > > I would also prefer that implementations SHOULD implement > Withdraw for > backwards compatibility, rather than MAY, to encourage backwards > compatibility without actually requiring it. When the > Proposed Standard > goes for Draft Standard, we can think about lessening the > SHOULD to a MAY > (or even removing it), since hopefully at that point the > installed base > would have migrated to the RFC. > > Cheers, > Andy > > ------------ > > At 2/24/2005 02:51 PM -0500, Thomas D. Nadeau wrote: > > > Cool with me. So I think it should be worded > >like: > > > >If the PW status negotiation results in Label Withdraw method then > >you SHOULD use either 1) label withdraw method, or 2) if > >label withdraw is not implemented, we disable the PW with a label > >release error message. > > > > --tom > > > > > >>Excellent , it sound like we are converging. > >>However we need to agree on the logic of this PW status procedure. > >>If the PW status negotiation results in Label Withdraw method then : > >> > >>1) we use label withdraw method ( MAY option ) > >>2) if label withdraw is not implemented , we disable the PW > with a label > >>release error message. > >>3) we do nothing. however in this case PW messaging would be broken. > >> > >>I think that we need #1 and #2 in the text with the > corresponding error > >>for #2 > >> > >>Do you agree ? > >> > >>Luca > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 16:55:22 -0500 Lines: 118 Mime-Version: 1.0 Content-Type: text/plain Cc: "'neil.2.harrison@bt.com'" , "'pwe3@ietf.org'" , 'Benny Ammitzboll' , "'mustapha.aissaoui@alcatel.com'" X-From: pwe3-bounces@ietf.org Thu Feb 24 22:54:31 2005 To: "'Shahram Davari'" , "'Thomas D. Nadeau'" , "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Forgot to add something. Please see below. > -----Original Message----- > From: Busschbach, Peter B (Peter) > Sent: Thursday, February 24, 2005 4:51 PM > To: 'Shahram Davari'; 'Thomas D. Nadeau'; Luca Martini > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; mustapha.aissaoui@alcatel.com; > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Hi Shahram, > > See 5.3.3: Pseudowire Status Negotiation Procedures. If one of the two PEs indicates that it cannot support PW Status, Label Withdraw is the assumed mechanism. However, if the other PE does not support Label Withdraw, it must generate an alarm, as Luca proposed in an earlier email. > > Peter > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, February 24, 2005 2:57 PM > > To: 'Thomas D. Nadeau'; Luca Martini > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > mustapha.aissaoui@alcatel.com; > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > change to PW > > st atus. > > > > > > How can the negotiation result in Label Withdrawal, if it is > > not implemented? > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Thursday, February 24, 2005 2:52 PM > > > To: Luca Martini > > > Cc: 'Benny Ammitzboll'; Shahram Davari; pwe3@ietf.org; > > > mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > > > Busschbach, Peter > > > B (Peter) > > > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > > > change to PW > > > st atus. > > > > > > > > > > > > Cool with me. So I think it should be worded > > > like: > > > > > > If the PW status negotiation results in Label Withdraw method then > > > you SHOULD use either 1) label withdraw method, or 2) if > > > label withdraw is not implemented, we disable the PW with a label > > > release error message. > > > > > > --tom > > > > > > > > > > Excellent , it sound like we are converging. > > > > However we need to agree on the logic of this PW status > procedure. > > > > If the PW status negotiation results in Label Withdraw > > method then : > > > > > > > > 1) we use label withdraw method ( MAY option ) > > > > 2) if label withdraw is not implemented , we disable the > > PW with a > > > > label release error message. > > > > 3) we do nothing. however in this case PW messaging would > > be broken. > > > > > > > > I think that we need #1 and #2 in the text with the > corresponding > > > > error for #2 > > > > > > > > Do you agree ? > > > > > > > > Luca > > > > > > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > >> This is a reasonable suggestion. > > > >> > > > >> -Shahram > > > >> > > > >> > > > >> > > > >>>> I have made this point in an earlier email, but I think > > > it is worth > > > >>>> repeating. I believe that this MUST should be a MAY. > > > >>>> > > > >>> Peter, > > > >>> > > > >>> This seems reasonable (and flexible) to me. In fact, > > > >>> I thought we all agreed to a MAY a while back. > > > >>> > > > >>> --Tom > > > >>> > > > >>> > > > >>> > > > >> > > > >> _______________________________________________ > > > >> pwe3 mailing list > > > >> pwe3@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/pwe3 > > > >> > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Shahram Davari Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 13:57:31 -0800 Lines: 142 Mime-Version: 1.0 Content-Type: text/plain Cc: "'neil.2.harrison@bt.com'" , "'pwe3@ietf.org'" , 'Benny Ammitzboll' , "'mustapha.aissaoui@alcatel.com'" X-From: pwe3-bounces@ietf.org Thu Feb 24 22:55:39 2005 To: "'Busschbach, Peter B (Peter)'" , "'Thomas D. Nadeau'" , "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Thanks Peter, Isn't Label withdrawal a mandatory implementation in LDP? -Shahram > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Thursday, February 24, 2005 4:55 PM > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Forgot to add something. Please see below. > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) > > Sent: Thursday, February 24, 2005 4:51 PM > > To: 'Shahram Davari'; 'Thomas D. Nadeau'; Luca Martini > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > mustapha.aissaoui@alcatel.com; > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > change to PW > > st atus. > > > > > > Hi Shahram, > > > > See 5.3.3: Pseudowire Status Negotiation Procedures. > > > If one of the two PEs indicates that it cannot support PW > Status, Label Withdraw is the assumed mechanism. However, if > the other PE does not support Label Withdraw, it must > generate an alarm, as Luca proposed in an earlier email. > > > > > > Peter > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Thursday, February 24, 2005 2:57 PM > > > To: 'Thomas D. Nadeau'; Luca Martini > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > > mustapha.aissaoui@alcatel.com; > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > change to PW > > > st atus. > > > > > > > > > How can the negotiation result in Label Withdrawal, if it is > > > not implemented? > > > > > > > -----Original Message----- > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > Sent: Thursday, February 24, 2005 2:52 PM > > > > To: Luca Martini > > > > Cc: 'Benny Ammitzboll'; Shahram Davari; pwe3@ietf.org; > > > > mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > > > > Busschbach, Peter > > > > B (Peter) > > > > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > > > > change to PW > > > > st atus. > > > > > > > > > > > > > > > > Cool with me. So I think it should be worded > > > > like: > > > > > > > > If the PW status negotiation results in Label Withdraw > method then > > > > you SHOULD use either 1) label withdraw method, or 2) if > > > > label withdraw is not implemented, we disable the PW > with a label > > > > release error message. > > > > > > > > --tom > > > > > > > > > > > > > Excellent , it sound like we are converging. > > > > > However we need to agree on the logic of this PW status > > procedure. > > > > > If the PW status negotiation results in Label Withdraw > > > method then : > > > > > > > > > > 1) we use label withdraw method ( MAY option ) > > > > > 2) if label withdraw is not implemented , we disable the > > > PW with a > > > > > label release error message. > > > > > 3) we do nothing. however in this case PW messaging would > > > be broken. > > > > > > > > > > I think that we need #1 and #2 in the text with the > > corresponding > > > > > error for #2 > > > > > > > > > > Do you agree ? > > > > > > > > > > Luca > > > > > > > > > > > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > >> This is a reasonable suggestion. > > > > >> > > > > >> -Shahram > > > > >> > > > > >> > > > > >> > > > > >>>> I have made this point in an earlier email, but I think > > > > it is worth > > > > >>>> repeating. I believe that this MUST should be a MAY. > > > > >>>> > > > > >>> Peter, > > > > >>> > > > > >>> This seems reasonable (and flexible) to me. In fact, > > > > >>> I thought we all agreed to a MAY a while back. > > > > >>> > > > > >>> --Tom > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > >> _______________________________________________ > > > > >> pwe3 mailing list > > > > >> pwe3@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/pwe3 > > > > >> > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 17:07:07 -0500 Lines: 163 Mime-Version: 1.0 Content-Type: text/plain Cc: "'neil.2.harrison@bt.com'" , "'pwe3@ietf.org'" , 'Benny Ammitzboll' , "'mustapha.aissaoui@alcatel.com'" X-From: pwe3-bounces@ietf.org Thu Feb 24 23:04:55 2005 To: "'Shahram Davari'" , "'Thomas D. Nadeau'" , "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Yes, Label Withdraw is a mandatory part of LDP per se. However, the issue here is its usage in relation to OAM. If we didn't have the situation with legacy equipment, the OAM procedures are as described in the oam-msg-map draft, i.e. in case of failures, generate AIS or send PW Status. To deal with legacy equipment, the algorithm must now include a check on the capabilities of the peer: IF THEN ELSE Peter > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, February 24, 2005 4:58 PM > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau'; 'Luca Martini' > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Thanks Peter, > > Isn't Label withdrawal a mandatory implementation in LDP? > > -Shahram > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: Thursday, February 24, 2005 4:55 PM > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > change to PW > > st atus. > > > > > > Forgot to add something. Please see below. > > > > > -----Original Message----- > > > From: Busschbach, Peter B (Peter) > > > Sent: Thursday, February 24, 2005 4:51 PM > > > To: 'Shahram Davari'; 'Thomas D. Nadeau'; Luca Martini > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > > mustapha.aissaoui@alcatel.com; > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > change to PW > > > st atus. > > > > > > > > > Hi Shahram, > > > > > > See 5.3.3: Pseudowire Status Negotiation Procedures. > > > > > > If one of the two PEs indicates that it cannot support PW > > Status, Label Withdraw is the assumed mechanism. However, if > > the other PE does not support Label Withdraw, it must > > generate an alarm, as Luca proposed in an earlier email. > > > > > > > > > > Peter > > > > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Thursday, February 24, 2005 2:57 PM > > > > To: 'Thomas D. Nadeau'; Luca Martini > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > > > mustapha.aissaoui@alcatel.com; > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > change to PW > > > > st atus. > > > > > > > > > > > > How can the negotiation result in Label Withdrawal, if it is > > > > not implemented? > > > > > > > > > -----Original Message----- > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > Sent: Thursday, February 24, 2005 2:52 PM > > > > > To: Luca Martini > > > > > Cc: 'Benny Ammitzboll'; Shahram Davari; pwe3@ietf.org; > > > > > mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > > > > > Busschbach, Peter > > > > > B (Peter) > > > > > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > > > > > change to PW > > > > > st atus. > > > > > > > > > > > > > > > > > > > > Cool with me. So I think it should be worded > > > > > like: > > > > > > > > > > If the PW status negotiation results in Label Withdraw > > method then > > > > > you SHOULD use either 1) label withdraw method, or 2) if > > > > > label withdraw is not implemented, we disable the PW > > with a label > > > > > release error message. > > > > > > > > > > --tom > > > > > > > > > > > > > > > > Excellent , it sound like we are converging. > > > > > > However we need to agree on the logic of this PW status > > > procedure. > > > > > > If the PW status negotiation results in Label Withdraw > > > > method then : > > > > > > > > > > > > 1) we use label withdraw method ( MAY option ) > > > > > > 2) if label withdraw is not implemented , we disable the > > > > PW with a > > > > > > label release error message. > > > > > > 3) we do nothing. however in this case PW messaging would > > > > be broken. > > > > > > > > > > > > I think that we need #1 and #2 in the text with the > > > corresponding > > > > > > error for #2 > > > > > > > > > > > > Do you agree ? > > > > > > > > > > > > Luca > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > > >> This is a reasonable suggestion. > > > > > >> > > > > > >> -Shahram > > > > > >> > > > > > >> > > > > > >> > > > > > >>>> I have made this point in an earlier email, but I think > > > > > it is worth > > > > > >>>> repeating. I believe that this MUST should be a MAY. > > > > > >>>> > > > > > >>> Peter, > > > > > >>> > > > > > >>> This seems reasonable (and flexible) to me. In fact, > > > > > >>> I thought we all agreed to a MAY a while back. > > > > > >>> > > > > > >>> --Tom > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> pwe3 mailing list > > > > > >> pwe3@ietf.org > > > > > >> https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > >> > > > > > > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Shahram Davari Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 14:41:03 -0800 Lines: 197 Mime-Version: 1.0 Content-Type: text/plain Cc: "'neil.2.harrison@bt.com'" , "'pwe3@ietf.org'" , 'Benny Ammitzboll' , "'mustapha.aissaoui@alcatel.com'" X-From: pwe3-bounces@ietf.org Thu Feb 24 23:44:10 2005 To: "'Busschbach, Peter B (Peter)'" , "'Thomas D. Nadeau'" , "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Hi Peter, I know. But my question is regarding this statement: "However, if the other PE does not support Label Withdraw, it must generate an alarm, as Luca proposed in an earlier email." If label withdrawal is a mandatory part of LDP, then how is it possible that a PE may not support it? Thanks Shahram > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Thursday, February 24, 2005 5:07 PM > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Yes, Label Withdraw is a mandatory part of LDP per se. > However, the issue here is its usage in relation to OAM. > > If we didn't have the situation with legacy equipment, the > OAM procedures are as described in the oam-msg-map draft, > i.e. in case of failures, generate AIS or send PW Status. To > deal with legacy equipment, the algorithm must now include a > check on the capabilities of the peer: > > IF THEN ELSE > > > Peter > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, February 24, 2005 4:58 PM > > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau'; > 'Luca Martini' > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > change to PW > > st atus. > > > > > > Thanks Peter, > > > > Isn't Label withdrawal a mandatory implementation in LDP? > > > > -Shahram > > > > > -----Original Message----- > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > Sent: Thursday, February 24, 2005 4:55 PM > > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > change to PW > > > st atus. > > > > > > > > > Forgot to add something. Please see below. > > > > > > > -----Original Message----- > > > > From: Busschbach, Peter B (Peter) > > > > Sent: Thursday, February 24, 2005 4:51 PM > > > > To: 'Shahram Davari'; 'Thomas D. Nadeau'; Luca Martini > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > > > mustapha.aissaoui@alcatel.com; > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > change to PW > > > > st atus. > > > > > > > > > > > > Hi Shahram, > > > > > > > > See 5.3.3: Pseudowire Status Negotiation Procedures. > > > > > > > > > If one of the two PEs indicates that it cannot support PW > > > Status, Label Withdraw is the assumed mechanism. However, if > > > the other PE does not support Label Withdraw, it must > > > generate an alarm, as Luca proposed in an earlier email. > > > > > > > > > > > > > > Peter > > > > > > > > > -----Original Message----- > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Thursday, February 24, 2005 2:57 PM > > > > > To: 'Thomas D. Nadeau'; Luca Martini > > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > > > > mustapha.aissaoui@alcatel.com; > > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > > change to PW > > > > > st atus. > > > > > > > > > > > > > > > How can the negotiation result in Label Withdrawal, if it is > > > > > not implemented? > > > > > > > > > > > -----Original Message----- > > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > > Sent: Thursday, February 24, 2005 2:52 PM > > > > > > To: Luca Martini > > > > > > Cc: 'Benny Ammitzboll'; Shahram Davari; pwe3@ietf.org; > > > > > > mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > > > > > > Busschbach, Peter > > > > > > B (Peter) > > > > > > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > > > > > > change to PW > > > > > > st atus. > > > > > > > > > > > > > > > > > > > > > > > > Cool with me. So I think it should be worded > > > > > > like: > > > > > > > > > > > > If the PW status negotiation results in Label Withdraw > > > method then > > > > > > you SHOULD use either 1) label withdraw method, or 2) if > > > > > > label withdraw is not implemented, we disable the PW > > > with a label > > > > > > release error message. > > > > > > > > > > > > --tom > > > > > > > > > > > > > > > > > > > Excellent , it sound like we are converging. > > > > > > > However we need to agree on the logic of this PW status > > > > procedure. > > > > > > > If the PW status negotiation results in Label Withdraw > > > > > method then : > > > > > > > > > > > > > > 1) we use label withdraw method ( MAY option ) > > > > > > > 2) if label withdraw is not implemented , we disable the > > > > > PW with a > > > > > > > label release error message. > > > > > > > 3) we do nothing. however in this case PW messaging would > > > > > be broken. > > > > > > > > > > > > > > I think that we need #1 and #2 in the text with the > > > > corresponding > > > > > > > error for #2 > > > > > > > > > > > > > > Do you agree ? > > > > > > > > > > > > > > Luca > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > > > > >> This is a reasonable suggestion. > > > > > > >> > > > > > > >> -Shahram > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>>> I have made this point in an earlier email, > but I think > > > > > > it is worth > > > > > > >>>> repeating. I believe that this MUST should be a MAY. > > > > > > >>>> > > > > > > >>> Peter, > > > > > > >>> > > > > > > >>> This seems reasonable (and flexible) to > me. In fact, > > > > > > >>> I thought we all agreed to a MAY a while back. > > > > > > >>> > > > > > > >>> --Tom > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> pwe3 mailing list > > > > > > >> pwe3@ietf.org > > > > > > >> https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > >> > > > > > > > > > > > > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 17:48:21 -0500 Lines: 223 Mime-Version: 1.0 Content-Type: text/plain Cc: "'neil.2.harrison@bt.com'" , "'pwe3@ietf.org'" , 'Benny Ammitzboll' , "'mustapha.aissaoui@alcatel.com'" X-From: pwe3-bounces@ietf.org Thu Feb 24 23:46:12 2005 To: "'Shahram Davari'" , "'Thomas D. Nadeau'" , "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, February 24, 2005 5:41 PM > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau'; 'Luca Martini' > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Hi Peter, > > I know. But my question is regarding this statement: > > "However, if the other PE does not support Label Withdraw, it must > generate an alarm, as Luca proposed in an earlier email." > > If label withdrawal is a mandatory part of LDP, then how is > it possible > that a PE may not support it? Perhaps my wording was imprecise. It should have been "if the other PE does not support Label Withdraw as a mechanism to signal AC or PW failures". Does that help? > > Thanks > Shahram > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: Thursday, February 24, 2005 5:07 PM > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > change to PW > > st atus. > > > > > > Yes, Label Withdraw is a mandatory part of LDP per se. > > However, the issue here is its usage in relation to OAM. > > > > If we didn't have the situation with legacy equipment, the > > OAM procedures are as described in the oam-msg-map draft, > > i.e. in case of failures, generate AIS or send PW Status. To > > deal with legacy equipment, the algorithm must now include a > > check on the capabilities of the peer: > > > > IF THEN ELSE > > > > > > Peter > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Thursday, February 24, 2005 4:58 PM > > > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau'; > > 'Luca Martini' > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > change to PW > > > st atus. > > > > > > > > > Thanks Peter, > > > > > > Isn't Label withdrawal a mandatory implementation in LDP? > > > > > > -Shahram > > > > > > > -----Original Message----- > > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > > Sent: Thursday, February 24, 2005 4:55 PM > > > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > change to PW > > > > st atus. > > > > > > > > > > > > Forgot to add something. Please see below. > > > > > > > > > -----Original Message----- > > > > > From: Busschbach, Peter B (Peter) > > > > > Sent: Thursday, February 24, 2005 4:51 PM > > > > > To: 'Shahram Davari'; 'Thomas D. Nadeau'; Luca Martini > > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > > > > mustapha.aissaoui@alcatel.com; > > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > > change to PW > > > > > st atus. > > > > > > > > > > > > > > > Hi Shahram, > > > > > > > > > > See 5.3.3: Pseudowire Status Negotiation Procedures. > > > > > > > > > > > > If one of the two PEs indicates that it cannot support PW > > > > Status, Label Withdraw is the assumed mechanism. However, if > > > > the other PE does not support Label Withdraw, it must > > > > generate an alarm, as Luca proposed in an earlier email. > > > > > > > > > > > > > > > > > > Peter > > > > > > > > > > > -----Original Message----- > > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > Sent: Thursday, February 24, 2005 2:57 PM > > > > > > To: 'Thomas D. Nadeau'; Luca Martini > > > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > > > > > mustapha.aissaoui@alcatel.com; > > > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > > > change to PW > > > > > > st atus. > > > > > > > > > > > > > > > > > > How can the negotiation result in Label > Withdrawal, if it is > > > > > > not implemented? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > > > Sent: Thursday, February 24, 2005 2:52 PM > > > > > > > To: Luca Martini > > > > > > > Cc: 'Benny Ammitzboll'; Shahram Davari; pwe3@ietf.org; > > > > > > > mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > > > > > > > Busschbach, Peter > > > > > > > B (Peter) > > > > > > > Subject: Re: [PWE3] Control protocol draft - > section 5.3.1 > > > > > > > change to PW > > > > > > > st atus. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cool with me. So I think it should be worded > > > > > > > like: > > > > > > > > > > > > > > If the PW status negotiation results in Label Withdraw > > > > method then > > > > > > > you SHOULD use either 1) label withdraw method, or 2) if > > > > > > > label withdraw is not implemented, we disable the PW > > > > with a label > > > > > > > release error message. > > > > > > > > > > > > > > --tom > > > > > > > > > > > > > > > > > > > > > > Excellent , it sound like we are converging. > > > > > > > > However we need to agree on the logic of this PW status > > > > > procedure. > > > > > > > > If the PW status negotiation results in Label Withdraw > > > > > > method then : > > > > > > > > > > > > > > > > 1) we use label withdraw method ( MAY option ) > > > > > > > > 2) if label withdraw is not implemented , we > disable the > > > > > > PW with a > > > > > > > > label release error message. > > > > > > > > 3) we do nothing. however in this case PW > messaging would > > > > > > be broken. > > > > > > > > > > > > > > > > I think that we need #1 and #2 in the text with the > > > > > corresponding > > > > > > > > error for #2 > > > > > > > > > > > > > > > > Do you agree ? > > > > > > > > > > > > > > > > Luca > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > > > > > > >> This is a reasonable suggestion. > > > > > > > >> > > > > > > > >> -Shahram > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >>>> I have made this point in an earlier email, > > but I think > > > > > > > it is worth > > > > > > > >>>> repeating. I believe that this MUST should be a MAY. > > > > > > > >>>> > > > > > > > >>> Peter, > > > > > > > >>> > > > > > > > >>> This seems reasonable (and flexible) to > > me. In fact, > > > > > > > >>> I thought we all agreed to a MAY a while back. > > > > > > > >>> > > > > > > > >>> --Tom > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> pwe3 mailing list > > > > > > > >> pwe3@ietf.org > > > > > > > >> https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Thu, 24 Feb 2005 19:09:58 -0700 Lines: 129 References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , Shahram Davari , pwe3@ietf.org, 'Benny Ammitzboll' , neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Fri Feb 25 03:09:49 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,115,1107752400"; d="scan'208"; a="38355042:sNHT23334416" User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: "Busschbach, Peter B (Peter)" In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Ok, here is the section in question : --------------------------------------------- .Pc "Use of Label Mappings." The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the attachment circuit state. The PW label should not be withdrawn unless the user administratively configures the attachment circuit down (or the PW configuration is deleted entirely). Using the procedures outlined in this section a simple label withdraw method SHOULD also be supported as a legacy means of signaling PW status. In any case if the Label mapping is not available the PW MUST be considered in the down state. Once, the PW status negotiation procedures are completed and if they result in the use of the label withdraw method for PW status communication, and this method is not supported by the PE, then the PW MUST be disabled and a label release message MUST be sent to he remote PE with the following error: "Label Withdraw PW Status Method Not Supported" If the label withdraw method for PW status communication is selected for the PW, it will result in the PW label mapping message being advertised only if the attachment circuit becomes active. The PW status signaling procedures described in this section MUST be fully implemented. ---------------------------------------------------------- Is this ok ? I am in favor of the SHOULD myself , but it might not make the AD/IESG review. They will probably ask in what situation is this part not going to be implemented ? Luca Busschbach, Peter B (Peter) wrote: >I agree with Andy's proposal. > >Peter > > > >>-----Original Message----- >>From: Andrew G. Malis [mailto:andymalis@comcast.net] >>Sent: Thursday, February 24, 2005 3:50 PM >>To: Thomas D. Nadeau >>Cc: Luca Martini; Shahram Davari; pwe3@ietf.org; 'Benny Ammitzboll'; >>Busschbach, Peter B (Peter); neil.2.harrison@bt.com; >>mustapha.aissaoui@alcatel.com >>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>change to PW >>st atus. >> >> >>The SHOULD in Tom's text below needs to be a MUST, since if >>the negotiation >>results in using the Withdraw method, then you MUST follow >>Tom's algorithm. >> >>I would also prefer that implementations SHOULD implement >>Withdraw for >>backwards compatibility, rather than MAY, to encourage backwards >>compatibility without actually requiring it. When the >>Proposed Standard >>goes for Draft Standard, we can think about lessening the >>SHOULD to a MAY >>(or even removing it), since hopefully at that point the >>installed base >>would have migrated to the RFC. >> >>Cheers, >>Andy >> >>------------ >> >>At 2/24/2005 02:51 PM -0500, Thomas D. Nadeau wrote: >> >> >> >>> Cool with me. So I think it should be worded >>>like: >>> >>>If the PW status negotiation results in Label Withdraw method then >>>you SHOULD use either 1) label withdraw method, or 2) if >>>label withdraw is not implemented, we disable the PW with a label >>>release error message. >>> >>> --tom >>> >>> >>> >>> >>>>Excellent , it sound like we are converging. >>>>However we need to agree on the logic of this PW status procedure. >>>>If the PW status negotiation results in Label Withdraw method then : >>>> >>>>1) we use label withdraw method ( MAY option ) >>>>2) if label withdraw is not implemented , we disable the PW >>>> >>>> >>with a label >> >> >>>>release error message. >>>>3) we do nothing. however in this case PW messaging would be broken. >>>> >>>>I think that we need #1 and #2 in the text with the >>>> >>>> >>corresponding error >> >> >>>>for #2 >>>> >>>>Do you agree ? >>>> >>>>Luca >>>> >>>> > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "DELORD Simon RD-RESA-LAN" Subject: Precision concerning the agenda Date: Fri, 25 Feb 2005 09:41:49 +0100 Lines: 88 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0363820227==" X-From: pwe3-bounces@ietf.org Fri Feb 25 09:39:46 2005 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Thread-Topic: Precision concerning the agenda Thread-Index: AcUbFdjnK7Iw250aQlGP6M39alIIVQ== To: "pwe3" X-OriginalArrivalTime: 25 Feb 2005 08:41:50.0515 (UTC) FILETIME=[D9603030:01C51B15] X-Spam-Score: 0.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org This is a multi-part message in MIME format. --===============0363820227== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51B15.D9467945" This is a multi-part message in MIME format. ------_=_NextPart_001_01C51B15.D9467945 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, just a quick clarification for the agenda concerning the draft draft-delord-pwe3-oam-applications-00.txt This document considers aspects on both service architecture and service supervision (OAM) concerning deployment and monitoring of VPWS services=20 by describing different implementation solutions and detailing the Pros and Cons of each solution.=20 This document targets to provide clarification and applicability=20 guidelines for the on going OAM work.=20 Regards, Simon =20 =20 ------_=_NextPart_001_01C51B15.D9467945 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Dear all, just a quick clarification for the agenda concerning the = draft

draft-delord-pwe3-oam-applications-00.txt

This document considers aspects on both service architecture and = service=20 supervision (OAM)

concerning deployment and monitoring of VPWS services

by describing different implementation solutions and detailing the = Pros and=20 Cons of each solution.

This document targets to provide clarification and applicability

guidelines for the on going OAM work.

Regards,

Simon

------_=_NextPart_001_01C51B15.D9467945-- --===============0363820227== 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 --===============0363820227==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: =?iso-8859-1?Q?Benny_Ammitzb=F8ll?= Subject: RE: Control protocol draft - section 5.3.1 change to PW status. Date: Fri, 25 Feb 2005 10:34:39 +0100 Lines: 160 References: <421E88F6.7060307@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , Shahram Davari , mustapha.aissaoui@alcatel.com, neil.2.harrison@bt.com, "Busschbach, Peter B $Peter$" , Luca Martini X-From: pwe3-bounces@ietf.org Fri Feb 25 10:31:34 2005 To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <421E88F6.7060307@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org The sentence "The PW label should not be withdrawn unless the user administratively configures the attachment circuit down" stands on its own early on. It is confusing me - am I right in assuming that a PE that supports the Status message (and has negotiated to use the Status message) should *only* send a label withdraw if the PW itself is deleted or set to admin down? This sentence makes it sound like it is ok to send a label withdraw when the user sets the AC admin state down - even if the Status message is in use! I think we have to spell out very clearly that the label withdraw is not the way to signal AC state to the remote PE. For this reason I also think the SHOULD should just be a MAY. /Benny -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of Luca Martini Sent: 25. februar 2005 03:10 To: Busschbach, Peter B (Peter) Cc: Thomas D. Nadeau; Shahram Davari; pwe3@ietf.org; 'Benny Ammitzboll'; neil.2.harrison@bt.com; mustapha.aissaoui@alcatel.com Subject: Re: [PWE3] Control protocol draft - section 5.3.1 change to PW status. Ok, here is the section in question : --------------------------------------------- .Pc "Use of Label Mappings." The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the attachment circuit state. The PW label should not be withdrawn unless the user administratively configures the attachment circuit down (or the PW configuration is deleted entirely). Using the procedures outlined in this section a simple label withdraw method SHOULD also be supported as a legacy means of signaling PW status. In any case if the Label mapping is not available the PW MUST be considered in the down state. Once, the PW status negotiation procedures are completed and if they result in the use of the label withdraw method for PW status communication, and this method is not supported by the PE, then the PW MUST be disabled and a label release message MUST be sent to he remote PE with the following error: "Label Withdraw PW Status Method Not Supported" If the label withdraw method for PW status communication is selected for the PW, it will result in the PW label mapping message being advertised only if the attachment circuit becomes active. The PW status signaling procedures described in this section MUST be fully implemented. ---------------------------------------------------------- Is this ok ? I am in favor of the SHOULD myself , but it might not make the AD/IESG review. They will probably ask in what situation is this part not going to be implemented ? Luca Busschbach, Peter B (Peter) wrote: >I agree with Andy's proposal. > >Peter > > > >>-----Original Message----- >>From: Andrew G. Malis [mailto:andymalis@comcast.net] >>Sent: Thursday, February 24, 2005 3:50 PM >>To: Thomas D. Nadeau >>Cc: Luca Martini; Shahram Davari; pwe3@ietf.org; 'Benny Ammitzboll'; >>Busschbach, Peter B (Peter); neil.2.harrison@bt.com; >>mustapha.aissaoui@alcatel.com >>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>change to PW >>st atus. >> >> >>The SHOULD in Tom's text below needs to be a MUST, since if >>the negotiation >>results in using the Withdraw method, then you MUST follow >>Tom's algorithm. >> >>I would also prefer that implementations SHOULD implement >>Withdraw for >>backwards compatibility, rather than MAY, to encourage backwards >>compatibility without actually requiring it. When the >>Proposed Standard >>goes for Draft Standard, we can think about lessening the >>SHOULD to a MAY >>(or even removing it), since hopefully at that point the >>installed base >>would have migrated to the RFC. >> >>Cheers, >>Andy >> >>------------ >> >>At 2/24/2005 02:51 PM -0500, Thomas D. Nadeau wrote: >> >> >> >>> Cool with me. So I think it should be worded >>>like: >>> >>>If the PW status negotiation results in Label Withdraw method then >>>you SHOULD use either 1) label withdraw method, or 2) if >>>label withdraw is not implemented, we disable the PW with a label >>>release error message. >>> >>> --tom >>> >>> >>> >>> >>>>Excellent , it sound like we are converging. >>>>However we need to agree on the logic of this PW status procedure. >>>>If the PW status negotiation results in Label Withdraw method then : >>>> >>>>1) we use label withdraw method ( MAY option ) >>>>2) if label withdraw is not implemented , we disable the PW >>>> >>>> >>with a label >> >> >>>>release error message. >>>>3) we do nothing. however in this case PW messaging would be broken. >>>> >>>>I think that we need #1 and #2 in the text with the >>>> >>>> >>corresponding error >> >> >>>>for #2 >>>> >>>>Do you agree ? >>>> >>>>Luca >>>> >>>> > >_______________________________________________ >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 27 15:58:25 2006 From: neil.2.harrison@bt.com Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 10:37:36 -0000 Lines: 306 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, Benny.Ammitzboell@tpack.net, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Fri Feb 25 11:35:18 2005 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] Control protocol draft - section 5.3.1 change to PW st atus. Thread-Index: AcUawvTBiB0sPH25R5C+dGwtaY20ZgAXQ2mg To: , , , X-OriginalArrivalTime: 25 Feb 2005 10:37:37.0113 (UTC) FILETIME=[05DEEC90:01C51B26] X-Spam-Score: 0.3 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Let me repeat the key messsages: - in any client/server relationship one must be able to functionally decouple the client and server layer networks. And one corollary of this is that: - events in the client layer network should not affect the server layer network.... - ...and further, events in a given server layer trail that supports a specific client layer link-connection must not result in events in a *different* server layer trail that supports a *different* client layer link connection. Let me make sure the last point is understood (because this is effectively what is being sanctioned here). Assume a very simple client layer topology of 3 nodes A, B, and C with link-connections between them of A-B and B-C. Assume link-connection A-B is provided by a server trail in technology X and that link-connection B-C is provided by a server layer trail in technology Y (we can substitute SDH, PDH, ATM whatever for X and MPLS or whatever for Y). =20 Now suppose there is a failure of the server layer trail in X. Assuming technology X is correctly functionally specified (like SDH is for example) this will result in an FDI OAM message being mapped to the client (across the X->client adaptation function). Now this (FDI) should get transferred in the client completely transparently across all other link-connections....and in the very simple topology I gave this means the link-connection supported by the trail in technology Y. The arch that seems to be being agreed on here (without much operator agreement I might add) means that failures in technology X (ie not the client, that just get affected) get mapped to failure indications in technology Y....which itself is plain wrong....but worse, if there is the 'withdraw' notion, then failures in the server layer trail in technology X will result in the removal of the trail in technology Y.....now this is obviously very wrong, and speaking as an operator this would be wholly unacceptable as a general arch principle. You can now extend this argument to the case of >2 link-connections and some arbitrary meshed client layer topology.....at what point do you stop mapping a server layer failure in 1 technology supporting 1 client layer link-connection to failure indications in other technologies supporting a different client layer link-connection? Also, just think what this also means for trying to define a prot-sw strategy in the client layer network topology when server layer trails on non-affected client link-connections just 'get taken away'. The reason we are not seeing this consequence is that there are strict topological constraining assumptions, ie a pair of 1-hop client link-connections ('ACs') at each end (with unknown/undefined server layer support), and a 1-hop PW/MPLS server layer supporting the middle link connection (with unknown/undefined server layer support below MPLS). Any deviation from this to a more general case and the problems I have highlighted will bite you. If we had implemented what you guys are proposing as a general principle in our current networks we would be in complete mess now. regards, Neil > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]=20 > Sent: 24 February 2005 22:48 > To: 'Shahram Davari'; 'Thomas D. Nadeau'; 'Luca Martini' > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org';=20 > 'mustapha.aissaoui@alcatel.com'; Harrison,N,Neil,IKM1 R > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > change to PW st atus. >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, February 24, 2005 5:41 PM > > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau';=20 > 'Luca Martini' > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org';=20 > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > change to PW > > st atus. > >=20 > >=20 > > Hi Peter, > >=20 > > I know. But my question is regarding this statement: > >=20 > > "However, if the other PE does not support Label Withdraw, it must > > generate an alarm, as Luca proposed in an earlier email." > >=20 > > If label withdrawal is a mandatory part of LDP, then how is > > it possible > > that a PE may not support it? >=20 >=20 > Perhaps my wording was imprecise. It should have been "if the=20 > other PE does not support Label Withdraw as a mechanism to=20 > signal AC or PW failures". >=20 > Does that help? >=20 >=20 > >=20 > > Thanks > > Shahram > >=20 > > > -----Original Message----- > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > Sent: Thursday, February 24, 2005 5:07 PM > > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > > > change to PW > > > st atus. > > >=20 > > >=20 > > > Yes, Label Withdraw is a mandatory part of LDP per se.=20 > > > However, the issue here is its usage in relation to OAM. > > >=20 > > > If we didn't have the situation with legacy equipment, the=20 > > > OAM procedures are as described in the oam-msg-map draft,=20 > > > i.e. in case of failures, generate AIS or send PW Status. To=20 > > > deal with legacy equipment, the algorithm must now include a=20 > > > check on the capabilities of the peer: > > >=20 > > > IF THEN ELSE=20 > > > > > >=20 > > > Peter > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Thursday, February 24, 2005 4:58 PM > > > > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau';=20 > > > 'Luca Martini' > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > > > > change to PW > > > > st atus. > > > >=20 > > > >=20 > > > > Thanks Peter, > > > >=20 > > > > Isn't Label withdrawal a mandatory implementation in LDP? > > > >=20 > > > > -Shahram > > > >=20 > > > > > -----Original Message----- > > > > > From: Busschbach, Peter B (Peter)=20 > [mailto:busschbach@lucent.com] > > > > > Sent: Thursday, February 24, 2005 4:55 PM > > > > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > > > > > change to PW > > > > > st atus. > > > > >=20 > > > > >=20 > > > > > Forgot to add something. Please see below. > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Busschbach, Peter B (Peter)=20 > > > > > > Sent: Thursday, February 24, 2005 4:51 PM > > > > > > To: 'Shahram Davari'; 'Thomas D. Nadeau'; Luca Martini > > > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org;=20 > > > > > mustapha.aissaoui@alcatel.com; > > > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > > > > > > change to PW > > > > > > st atus. > > > > > >=20 > > > > > >=20 > > > > > > Hi Shahram, > > > > > >=20 > > > > > > See 5.3.3: Pseudowire Status Negotiation Procedures. > > > > >=20 > > > > >=20 > > > > > If one of the two PEs indicates that it cannot support PW=20 > > > > > Status, Label Withdraw is the assumed mechanism. However, if=20 > > > > > the other PE does not support Label Withdraw, it must=20 > > > > > generate an alarm, as Luca proposed in an earlier email.=20 > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > Peter > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Shahram Davari=20 > [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > > Sent: Thursday, February 24, 2005 2:57 PM > > > > > > > To: 'Thomas D. Nadeau'; Luca Martini > > > > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org;=20 > > > > > > mustapha.aissaoui@alcatel.com; > > > > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > > > > Subject: RE: [PWE3] Control protocol draft -=20 > section 5.3.1=20 > > > > > > > change to PW > > > > > > > st atus. > > > > > > >=20 > > > > > > >=20 > > > > > > > How can the negotiation result in Label=20 > > Withdrawal, if it is=20 > > > > > > > not implemented? > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > > > > Sent: Thursday, February 24, 2005 2:52 PM > > > > > > > > To: Luca Martini > > > > > > > > Cc: 'Benny Ammitzboll'; Shahram Davari; pwe3@ietf.org; > > > > > > > > mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com;=20 > > > > > > > > Busschbach, Peter > > > > > > > > B (Peter) > > > > > > > > Subject: Re: [PWE3] Control protocol draft -=20 > > section 5.3.1=20 > > > > > > > > change to PW > > > > > > > > st atus. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Cool with me. So I think it should be worded > > > > > > > > like: > > > > > > > >=20 > > > > > > > > If the PW status negotiation results in Label Withdraw=20 > > > > > method then > > > > > > > > you SHOULD use either 1) label withdraw method, or 2) if > > > > > > > > label withdraw is not implemented, we disable the PW=20 > > > > > with a label > > > > > > > > release error message. > > > > > > > >=20 > > > > > > > > --tom > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > > Excellent , it sound like we are converging. > > > > > > > > > However we need to agree on the logic of this=20 > PW status=20 > > > > > > procedure. > > > > > > > > > If the PW status negotiation results in Label=20 > Withdraw=20 > > > > > > > method then : > > > > > > > > > > > > > > > > > > 1) we use label withdraw method ( MAY option ) > > > > > > > > > 2) if label withdraw is not implemented , we=20 > > disable the=20 > > > > > > > PW with a=20 > > > > > > > > > label release error message. > > > > > > > > > 3) we do nothing. however in this case PW=20 > > messaging would=20 > > > > > > > be broken. > > > > > > > > > > > > > > > > > > I think that we need #1 and #2 in the text with the=20 > > > > > > corresponding=20 > > > > > > > > > error for #2 > > > > > > > > > > > > > > > > > > Do you agree ? > > > > > > > > > > > > > > > > > > Luca > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > > > > > > > > >> This is a reasonable suggestion. > > > > > > > > >> > > > > > > > > >> -Shahram > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>>> I have made this point in an earlier email,=20 > > > but I think=20 > > > > > > > > it is worth=20 > > > > > > > > >>>> repeating. I believe that this MUST should=20 > be a MAY. > > > > > > > > >>>> > > > > > > > > >>> Peter, > > > > > > > > >>> > > > > > > > > >>> This seems reasonable (and flexible) to=20 > > > me. In fact, > > > > > > > > >>> I thought we all agreed to a MAY a while back. > > > > > > > > >>> > > > > > > > > >>> --Tom > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> _______________________________________________ > > > > > > > > >> pwe3 mailing list > > > > > > > > >> pwe3@ietf.org > > > > > > > > >> https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > >> > > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "David Allan" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 07:24:17 -0500 Lines: 10 Cc: "Thomas D. Nadeau" , Shahram Davari , mustapha.aissaoui@alcatel.com, neil.2.harrison@bt.com, "Busschbach, Peter B $Peter$" , Luca Martini X-From: pwe3-bounces@ietf.org Fri Feb 25 13:22:13 2005 To: "'Benny Ammitzb�ll'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org > I think we have to spell out very clearly that the label > withdraw is not the way to signal AC state to the remote PE. > For this reason I also think the SHOULD should just be a MAY. I agree with this. There are clearly consequences to a label withdraw that must be supported, but it should not be used to communicate AC state (and IMO administative state). Dave From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Andrew G. Malis" Subject: RE: Control protocol draft - section 5.3.1 change to PW status. Date: Fri, 25 Feb 2005 07:58:21 -0500 Lines: 19 References: <87AC5F88F03E6249AEA68D40BD3E00BE03192D89@zcarhxm2.corp.nortel.com> <87AC5F88F03E6249AEA68D40BD3E00BE03192D89@zcarhxm2.corp.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Thomas D. Nadeau" , Shahram Davari , pwe3@ietf.org, =?iso-8859-1?Q?=22=27Benny_Ammitzb=F8ll=27=22?= , "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, Luca Martini , mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Fri Feb 25 13:57:27 2005 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: "David Allan" In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE03192D89@zcarhxm2.corp.nor tel.com> References: <87AC5F88F03E6249AEA68D40BD3E00BE03192D89@zcarhxm2.corp.nortel.com> X-Spam-Score: 3.6 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org OK, I give in to Benny and Dave. Let's incorporate Benny's clarification and make the "SHOULD" a "MAY". Thanks, Andy ----------- At 2/25/2005 07:24 AM -0500, David Allan wrote: > > I think we have to spell out very clearly that the label > > withdraw is not the way to signal AC state to the remote PE. > > For this reason I also think the SHOULD should just be a MAY. > >I agree with this. There are clearly consequences to a label withdraw that >must be supported, but it should not be used to communicate AC state (and >IMO administative state). > >Dave From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "DELORD Simon RD-RESA-LAN" Subject: RE : PWE3 @ IETF62 provisional agenda Date: Fri, 25 Feb 2005 09:10:03 +0100 Lines: 107 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Fri Feb 25 14:30:16 2005 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 @ IETF62 provisional agenda Thread-Index: AcUaKwuI9zhVPYSQRrqpW21skwrKzgAXRK/wACIaBvA= To: "Stewart Bryant" , "pwe3" X-OriginalArrivalTime: 25 Feb 2005 08:10:06.0018 (UTC) FILETIME=[6A350220:01C51B11] X-Spam-Score: 2.0 (++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 25 Feb 2005 08:32:31 -0500 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Dear all, just a quick clarification for the agenda concerning the draft draft-delord-pwe3-oam-applications-00.txt This document considers aspects on both service architecture and=20 service supervision (OAM)concerning deployment and monitoring of VPWS services by describing different implementation solutions and detailing the Pros and Cons of each solution.=20 This document targets to provide clarification and applicability=20 guidelines for the on going OAM work.=20 Regards, Simon > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of > Stewart Bryant > Sent: Tuesday, February 22, 2005 6:10 AM > To: pwe3 > Subject: [PWE3] PWE3 @ IETF62 provisional agenda >=20 >=20 > Here is the first cut of the PWE3 agenda for IETF62. >=20 > Have I missed anthing, anything else that needs to be raised? >=20 > As usual, please can Danny and I have the slides before the meeting. >=20 > Thanks >=20 > Stewart >=20 > Pseudo Wire Emulation Edge to Edge (pwe3)=20 > = =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 >=20 > WEDNESDAY, March 9, 2005, (1530-1730) >=20 > CHAIR: "Danny McPherson" > "Stewart Bryant" >=20 > AGENDA: >=20 > Administrivia > Chairs (Stewart & Danny) > Agenda Bashing > Minutes > Blue Sheets >=20 > WG Document Status > Danny McPherson > Stewart Bryant >=20 > Pseudowire Setup and Maintenance using LDP and Ethernet over MPLS > Luca Martini > draft-ietf-pwe3-control-protocol-15.txt > draft-ietf-pwe3-ethernet-encap-09.txt > Restructure of drafts folloing AD review >=20 > Frame Relay over Pseudo-Wires > Luca Martini > draft-ietf-pwe3-frame-relay-04.txt > Update on the rewrite >=20 > PW Control Word > Stewart Bryant > > Resolve any outstanding comments >=20 > Requirements for inter domain Pseudo-Wires > Nabil Bitar > draft-martini-pwe3-MH-PW-requirements-00.txt >=20 > Multi-hop Pseudowire Setup and Maintenance using LDP > David McDysan&Florin Balus > > Discuss new LDP extensions, end to end signaling > procedures to address the related requirements specified > in the MH-PWE3 Requirements draft. The procedures described > in the draft enable the usage of addressing schemes (L2FECs) > and other TLVs already defined for PWs in PW Control >=20 > PWE3 Applications & OAM Scenarios > Simon Delord > draft-delord-pwe3-oam-applications-00.txt > Introduction to Key Issues >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 08:45:27 -0500 Lines: 350 Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, Benny.Ammitzboell@tpack.net, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Fri Feb 25 14:46:49 2005 To: "'neil.2.harrison@bt.com'" , Shahram_Davari@pmc-sierra.com, tnadeau@cisco.com, lmartini@cisco.com X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Friday, February 25, 2005 5:38 AM > To: busschbach@lucent.com; Shahram_Davari@pmc-sierra.com; > tnadeau@cisco.com; lmartini@cisco.com > Cc: Benny.Ammitzboell@tpack.net; pwe3@ietf.org; > mustapha.aissaoui@alcatel.com > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Let me repeat the key messsages: > - in any client/server relationship one must be able to > functionally decouple the client and server layer networks. And one > corollary of this is that: > - events in the client layer network should not affect the server > layer network.... > - ...and further, events in a given server layer trail that > supports a specific client layer link-connection must not result in > events in a *different* server layer trail that supports a *different* > client layer link connection. > > Let me make sure the last point is understood (because this is > effectively what is being sanctioned here). Neil, I disagree with this statement. I hope you find time to read the latest version of the oam-msg-map draft. You will see that it attempts to prescribe the right behavior. Unfortunately, not all existing protocols are structured as SDH and ATM. Therefore, the behavior that you would like to see is not always possible. Frame Relay does not support AIS. Therefore the observation that a FR DLC is down needs to be conveyed by other means: PW Status. Another example is Ethernet. The current oam-msg-map draft is written for Ethernet applications that do not support Ethernet AIS. (Once the work in IEEE on Ethernet OAM progresses, we will probably write an extension to oam-msg-map that includes Ethernet AIS and that describes procedures similar to the ATM procedures described in oam-msg-map). In the absence of Ethernet AIS, one could consider that PWE is a form of service interworking: an Ethernet-over-ATM attachment circuit is connected to an Ethernet-over-PW pseudo wire, which in turn is connected to an Ethernet-over-FR attachment circuit. In that case, a defect in one attachment circuit could be translated to PW Status followed by AIS in the other attachment circuit. This may not be architecturally pure, but without Ethernet AIS it is the best one can do. Below you also devote a paragraph to label withdraw as a means to signal failures and conclude that it is "wholly unacceptable as a general arch principle". I think we all realize that. That is why all emails in the past days have explicitly stated that interoperability with legacy equipment the ONLY reason that this is still mentioned in the draft. If you and other operators feel that interoperability with legacy equipment is not important, it would be helpful if you would share that with the list. Peter > > Assume a very simple client layer topology of 3 nodes A, B, and C with > link-connections between them of A-B and B-C. Assume link-connection > A-B is provided by a server trail in technology X and that > link-connection B-C is provided by a server layer trail in > technology Y > (we can substitute SDH, PDH, ATM whatever for X and MPLS or > whatever for > Y). > > Now suppose there is a failure of the server layer trail in > X. Assuming > technology X is correctly functionally specified (like SDH is for > example) this will result in an FDI OAM message being mapped to the > client (across the X->client adaptation function). Now this (FDI) > should get transferred in the client completely transparently > across all > other link-connections....and in the very simple topology I gave this > means the link-connection supported by the trail in technology Y. > > The arch that seems to be being agreed on here (without much operator > agreement I might add) means that failures in technology X (ie not the > client, that just get affected) get mapped to failure indications in > technology Y....which itself is plain wrong....but worse, if there is > the 'withdraw' notion, then failures in the server layer trail in > technology X will result in the removal of the trail in technology > Y.....now this is obviously very wrong, and speaking as an > operator this > would be wholly unacceptable as a general arch principle. > > You can now extend this argument to the case of >2 > link-connections and > some arbitrary meshed client layer topology.....at what point do you > stop mapping a server layer failure in 1 technology > supporting 1 client > layer link-connection to failure indications in other technologies > supporting a different client layer link-connection? > > Also, just think what this also means for trying to define a prot-sw > strategy in the client layer network topology when server layer trails > on non-affected client link-connections just 'get taken away'. > > The reason we are not seeing this consequence is that there are strict > topological constraining assumptions, ie a pair of 1-hop client > link-connections ('ACs') at each end (with unknown/undefined server > layer support), and a 1-hop PW/MPLS server layer supporting the middle > link connection (with unknown/undefined server layer support below > MPLS). Any deviation from this to a more general case and > the problems > I have highlighted will bite you. > > If we had implemented what you guys are proposing as a > general principle > in our current networks we would be in complete mess now. > > regards, Neil > > > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: 24 February 2005 22:48 > > To: 'Shahram Davari'; 'Thomas D. Nadeau'; 'Luca Martini' > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > 'mustapha.aissaoui@alcatel.com'; Harrison,N,Neil,IKM1 R > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > change to PW st atus. > > > > > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Thursday, February 24, 2005 5:41 PM > > > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau'; > > 'Luca Martini' > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > change to PW > > > st atus. > > > > > > > > > Hi Peter, > > > > > > I know. But my question is regarding this statement: > > > > > > "However, if the other PE does not support Label > Withdraw, it must > > > generate an alarm, as Luca proposed in an earlier email." > > > > > > If label withdrawal is a mandatory part of LDP, then how is > > > it possible > > > that a PE may not support it? > > > > > > Perhaps my wording was imprecise. It should have been "if the > > other PE does not support Label Withdraw as a mechanism to > > signal AC or PW failures". > > > > Does that help? > > > > > > > > > > Thanks > > > Shahram > > > > > > > -----Original Message----- > > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > > Sent: Thursday, February 24, 2005 5:07 PM > > > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > change to PW > > > > st atus. > > > > > > > > > > > > Yes, Label Withdraw is a mandatory part of LDP per se. > > > > However, the issue here is its usage in relation to OAM. > > > > > > > > If we didn't have the situation with legacy equipment, the > > > > OAM procedures are as described in the oam-msg-map draft, > > > > i.e. in case of failures, generate AIS or send PW Status. To > > > > deal with legacy equipment, the algorithm must now include a > > > > check on the capabilities of the peer: > > > > > > > > IF THEN ELSE > > > > > > > > > > > > Peter > > > > > > > > > > > > > -----Original Message----- > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Thursday, February 24, 2005 4:58 PM > > > > > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau'; > > > > 'Luca Martini' > > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > > change to PW > > > > > st atus. > > > > > > > > > > > > > > > Thanks Peter, > > > > > > > > > > Isn't Label withdrawal a mandatory implementation in LDP? > > > > > > > > > > -Shahram > > > > > > > > > > > -----Original Message----- > > > > > > From: Busschbach, Peter B (Peter) > > [mailto:busschbach@lucent.com] > > > > > > Sent: Thursday, February 24, 2005 4:55 PM > > > > > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > > > change to PW > > > > > > st atus. > > > > > > > > > > > > > > > > > > Forgot to add something. Please see below. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Busschbach, Peter B (Peter) > > > > > > > Sent: Thursday, February 24, 2005 4:51 PM > > > > > > > To: 'Shahram Davari'; 'Thomas D. Nadeau'; Luca Martini > > > > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > > > > > > mustapha.aissaoui@alcatel.com; > > > > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > > > > Subject: RE: [PWE3] Control protocol draft - > section 5.3.1 > > > > > > > change to PW > > > > > > > st atus. > > > > > > > > > > > > > > > > > > > > > Hi Shahram, > > > > > > > > > > > > > > See 5.3.3: Pseudowire Status Negotiation Procedures. > > > > > > > > > > > > > > > > > > If one of the two PEs indicates that it cannot support PW > > > > > > Status, Label Withdraw is the assumed mechanism. > However, if > > > > > > the other PE does not support Label Withdraw, it must > > > > > > generate an alarm, as Luca proposed in an earlier email. > > > > > > > > > > > > > > > > > > > > > > > > > > Peter > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Shahram Davari > > [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > > > Sent: Thursday, February 24, 2005 2:57 PM > > > > > > > > To: 'Thomas D. Nadeau'; Luca Martini > > > > > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org; > > > > > > > mustapha.aissaoui@alcatel.com; > > > > > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > > > > > Subject: RE: [PWE3] Control protocol draft - > > section 5.3.1 > > > > > > > > change to PW > > > > > > > > st atus. > > > > > > > > > > > > > > > > > > > > > > > > How can the negotiation result in Label > > > Withdrawal, if it is > > > > > > > > not implemented? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > > > > > Sent: Thursday, February 24, 2005 2:52 PM > > > > > > > > > To: Luca Martini > > > > > > > > > Cc: 'Benny Ammitzboll'; Shahram Davari; pwe3@ietf.org; > > > > > > > > > mustapha.aissaoui@alcatel.com; > neil.2.harrison@bt.com; > > > > > > > > > Busschbach, Peter > > > > > > > > > B (Peter) > > > > > > > > > Subject: Re: [PWE3] Control protocol draft - > > > section 5.3.1 > > > > > > > > > change to PW > > > > > > > > > st atus. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cool with me. So I think it should be worded > > > > > > > > > like: > > > > > > > > > > > > > > > > > > If the PW status negotiation results in Label > Withdraw > > > > > > method then > > > > > > > > > you SHOULD use either 1) label withdraw > method, or 2) if > > > > > > > > > label withdraw is not implemented, we disable the PW > > > > > > with a label > > > > > > > > > release error message. > > > > > > > > > > > > > > > > > > --tom > > > > > > > > > > > > > > > > > > > > > > > > > > > > Excellent , it sound like we are converging. > > > > > > > > > > However we need to agree on the logic of this > > PW status > > > > > > > procedure. > > > > > > > > > > If the PW status negotiation results in Label > > Withdraw > > > > > > > > method then : > > > > > > > > > > > > > > > > > > > > 1) we use label withdraw method ( MAY option ) > > > > > > > > > > 2) if label withdraw is not implemented , we > > > disable the > > > > > > > > PW with a > > > > > > > > > > label release error message. > > > > > > > > > > 3) we do nothing. however in this case PW > > > messaging would > > > > > > > > be broken. > > > > > > > > > > > > > > > > > > > > I think that we need #1 and #2 in the text with the > > > > > > > corresponding > > > > > > > > > > error for #2 > > > > > > > > > > > > > > > > > > > > Do you agree ? > > > > > > > > > > > > > > > > > > > > Luca > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > > > > > > > > > > >> This is a reasonable suggestion. > > > > > > > > > >> > > > > > > > > > >> -Shahram > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>>> I have made this point in an earlier email, > > > > but I think > > > > > > > > > it is worth > > > > > > > > > >>>> repeating. I believe that this MUST should > > be a MAY. > > > > > > > > > >>>> > > > > > > > > > >>> Peter, > > > > > > > > > >>> > > > > > > > > > >>> This seems reasonable (and flexible) to > > > > me. In fact, > > > > > > > > > >>> I thought we all agreed to a MAY a while back. > > > > > > > > > >>> > > > > > > > > > >>> --Tom > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >> > > > > > > > > > >> _______________________________________________ > > > > > > > > > >> pwe3 mailing list > > > > > > > > > >> pwe3@ietf.org > > > > > > > > > >> https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Shahram Davari Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 06:33:49 -0800 Lines: 39 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "Thomas D. Nadeau" , pwe3@ietf.org, "\"'Benny Ammitzboll'\"" , neil.2.harrison@bt.com, "Busschbach, Peter B $Peter$" , Luca Martini , mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Fri Feb 25 15:30:51 2005 To: "'Andrew G. Malis'" , David Allan X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org I will also go with MAY. -Shahram > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Friday, February 25, 2005 7:58 AM > To: David Allan > Cc: "'Benny Ammitzboll'"; pwe3@ietf.org; Thomas D. Nadeau; Shahram > Davari; mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > Busschbach, Peter B (Peter); Luca Martini > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > change to PW > status. > > > OK, I give in to Benny and Dave. Let's incorporate Benny's > clarification > and make the "SHOULD" a "MAY". > > Thanks, > Andy > > ----------- > > At 2/25/2005 07:24 AM -0500, David Allan wrote: > > > > I think we have to spell out very clearly that the label > > > withdraw is not the way to signal AC state to the remote PE. > > > For this reason I also think the SHOULD should just be a MAY. > > > >I agree with this. There are clearly consequences to a label > withdraw that > >must be supported, but it should not be used to communicate > AC state (and > >IMO administative state). > > > >Dave > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Thomas D. Nadeau" Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 09:44:22 -0500 Lines: 130 References: <421E88F6.7060307@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: Shahram Davari , pwe3@ietf.org, 'Benny Ammitzboll' , "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Fri Feb 25 15:41:06 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,117,1107763200"; d="scan'208"; a="616708353:sNHT24053500" In-Reply-To: <421E88F6.7060307@cisco.com> To: Luca Martini X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org On Feb 24, 2005, at 9:09 PM, Luca Martini wrote: > Ok, > here is the section in question : > --------------------------------------------- > .Pc "Use of Label Mappings." > The PEs MUST send PW label mapping messages to their peers as soon as > the PW > is configured and administratively enabled, regardless of the > attachment > circuit state. The PW label should not be withdrawn unless the user > administratively configures the attachment circuit down (or the PW > configuration is deleted entirely). Using the procedures outlined in > this > section a simple label withdraw method SHOULD also be supported as a > legacy > means of signaling PW status. In any case if the Label mapping is not > available the PW MUST be considered in the down state. > > Once, the PW status negotiation procedures are completed and if they > result > in the use of the label withdraw method for PW status communication, > and > this method is not supported by the PE, then the PW MUST be disabled > and a > label release message MUST be sent to he remote PE with the following > error: ^^ the > > "Label Withdraw PW Status Method Not Supported" > > If the label withdraw method for PW status communication is selected > for the > PW, it will result in the PW label mapping message being advertised > only if > the attachment circuit becomes active. > The PW status signaling procedures described in this section MUST be > fully > implemented. > ---------------------------------------------------------- > > Is this ok ? > > I am in favor of the SHOULD myself , but it might not make the AD/IESG > review. They will probably ask in what situation is this part not > going to be implemented ? > > Luca > > > > Busschbach, Peter B (Peter) wrote: > >> I agree with Andy's proposal. >> >> Peter >> >> >>> -----Original Message----- >>> From: Andrew G. Malis [mailto:andymalis@comcast.net] >>> Sent: Thursday, February 24, 2005 3:50 PM >>> To: Thomas D. Nadeau >>> Cc: Luca Martini; Shahram Davari; pwe3@ietf.org; 'Benny Ammitzboll'; >>> Busschbach, Peter B (Peter); neil.2.harrison@bt.com; >>> mustapha.aissaoui@alcatel.com >>> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 change to >>> PW >>> st atus. >>> >>> >>> The SHOULD in Tom's text below needs to be a MUST, since if the >>> negotiation results in using the Withdraw method, then you MUST >>> follow Tom's algorithm. >>> >>> I would also prefer that implementations SHOULD implement Withdraw >>> for backwards compatibility, rather than MAY, to encourage backwards >>> compatibility without actually requiring it. When the Proposed >>> Standard goes for Draft Standard, we can think about lessening the >>> SHOULD to a MAY (or even removing it), since hopefully at that point >>> the installed base would have migrated to the RFC. >>> >>> Cheers, >>> Andy >>> >>> ------------ >>> >>> At 2/24/2005 02:51 PM -0500, Thomas D. Nadeau wrote: >>> >>> >>>> Cool with me. So I think it should be worded >>>> like: >>>> >>>> If the PW status negotiation results in Label Withdraw method then >>>> you SHOULD use either 1) label withdraw method, or 2) if >>>> label withdraw is not implemented, we disable the PW with a label >>>> release error message. >>>> >>>> --tom >>>> >>>> >>>> >>>>> Excellent , it sound like we are converging. >>>>> However we need to agree on the logic of this PW status procedure. >>>>> If the PW status negotiation results in Label Withdraw method then >>>>> : >>>>> >>>>> 1) we use label withdraw method ( MAY option ) >>>>> 2) if label withdraw is not implemented , we disable the PW >>> with a label >>>>> release error message. >>>>> 3) we do nothing. however in this case PW messaging would be >>>>> broken. >>>>> >>>>> I think that we need #1 and #2 in the text with the >>> corresponding error >>>>> for #2 >>>>> >>>>> Do you agree ? >>>>> >>>>> Luca >>>>> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: neil.2.harrison@bt.com Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 16:44:23 -0000 Lines: 409 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, Benny.Ammitzboell@tpack.net, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Fri Feb 25 17:43:28 2005 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] Control protocol draft - section 5.3.1 change to PW st atus. Thread-Index: AcUbSLIRH6aG5j4rRQa43WJBLHJXhAABEhXQ To: , , , X-OriginalArrivalTime: 25 Feb 2005 16:44:23.0674 (UTC) FILETIME=[42CDA5A0:01C51B59] X-Spam-Score: 0.3 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Thanks Peter for a good/reasoned repsonse....some remarks below. > >=20 > > Let me repeat the key messsages: > > - in any client/server relationship one must be able to > > functionally decouple the client and server layer networks.=20 > And one=20 > > corollary of this is that: > > - events in the client layer network should not affect the server > > layer network.... > > - ...and further, events in a given server layer trail that > > supports a specific client layer link-connection must not result in=20 > > events in a *different* server layer trail that supports a=20 > *different*=20 > > client layer link connection. > >=20 > > Let me make sure the last point is understood (because this is=20 > > effectively what is being sanctioned here). >=20 > Neil, >=20 > I disagree with this statement. NH=3D> I can understand why you might say this looking at the = relationship between a given a given client/server pair case and as per how PWs have grown up. But the above observations are general...and they are quite accurate as to what is happening here (if you work through it...as per the example I gave below in the preceding mail). > I hope you find time to read=20 > the latest version of the oam-msg-map draft. You will see=20 > that it attempts to prescribe the right behavior. NH=3D> I'll have a review of this at some point. Still like to see MPLS OAM done right irrespective of any mapping expediencies. >=20 > Unfortunately, not all existing protocols are structured as=20 > SDH and ATM. NH=3D> There are generic solutions in each mode. None have been done perfect to date. But there is little excuse NOT to get this largely right from now on is there?=20 > Therefore, the behavior that you would like to=20 > see is not always possible. Frame Relay does not support AIS.=20 > Therefore the observation that a FR DLC is down needs to be=20 > conveyed by other means: PW Status. NH=3D> OK, but this should not stop us getting OAM right in new layer network technologies. >=20 > Another example is Ethernet. The current oam-msg-map draft is=20 > written for Ethernet applications that do not support=20 > Ethernet AIS. (Once the work in IEEE on Ethernet OAM=20 > progresses, we will probably write an extension to=20 > oam-msg-map that includes Ethernet AIS and that describes=20 > procedures similar to the ATM procedures described in=20 > oam-msg-map). In the absence of Ethernet AIS, one could=20 > consider that PWE is a form of service interworking: an=20 > Ethernet-over-ATM attachment circuit is connected to an=20 > Ethernet-over-PW pseudo wire, which in turn is connected to=20 > an Ethernet-over-FR attachment circuit. In that case, a=20 > defect in one attachment circuit could be translated to PW=20 > Status followed by AIS in the other attachment circuit. This=20 > may not be architecturally pure, but without Ethernet AIS it=20 > is the best one can do. NH=3D> I am aware of the work on eth OAM that is attempting to overlay a co-ps behaviour on the native cl-ps behaviour. However, FDI is not really a valid OAM function in a true cl-ps mode network. >=20 > Below you also devote a paragraph to label withdraw as a=20 > means to signal failures and conclude that it is "wholly=20 > unacceptable as a general arch principle". I think we all=20 > realize that. That is why all emails in the past days have=20 > explicitly stated that interoperability with legacy equipment=20 > the ONLY reason that this is still mentioned in the draft. If=20 > you and other operators feel that interoperability with=20 > legacy equipment is not important, it would be helpful if you=20 > would share that with the list. NH=3D> IMO stds should reflect best-knowledge.....so if folks build early, and to a draft, then there is a risk they will not be in accordance with the finally ratified standard. I think its an abuse of standards to make them reflect what folks have built *if* there are known problems. =20 regards, Neil >=20 > Peter >=20 >=20 > >=20 > > Assume a very simple client layer topology of 3 nodes A, B,=20 > and C with=20 > > link-connections between them of A-B and B-C. Assume=20 > link-connection=20 > > A-B is provided by a server trail in technology X and that=20 > > link-connection B-C is provided by a server layer trail in=20 > technology=20 > > Y (we can substitute SDH, PDH, ATM whatever for X and MPLS or > > whatever for > > Y). =20 > >=20 > > Now suppose there is a failure of the server layer trail in > > X. Assuming > > technology X is correctly functionally specified (like SDH is for > > example) this will result in an FDI OAM message being mapped to the > > client (across the X->client adaptation function). Now this (FDI) > > should get transferred in the client completely transparently=20 > > across all > > other link-connections....and in the very simple topology I=20 > gave this > > means the link-connection supported by the trail in technology Y. > >=20 > > The arch that seems to be being agreed on here (without=20 > much operator=20 > > agreement I might add) means that failures in technology X=20 > (ie not the=20 > > client, that just get affected) get mapped to failure=20 > indications in=20 > > technology Y....which itself is plain wrong....but worse,=20 > if there is=20 > > the 'withdraw' notion, then failures in the server layer trail in=20 > > technology X will result in the removal of the trail in technology=20 > > Y.....now this is obviously very wrong, and speaking as an operator=20 > > this would be wholly unacceptable as a general arch principle. > >=20 > > You can now extend this argument to the case of >2 > > link-connections and > > some arbitrary meshed client layer topology.....at what point do you > > stop mapping a server layer failure in 1 technology=20 > > supporting 1 client > > layer link-connection to failure indications in other technologies > > supporting a different client layer link-connection? > >=20 > > Also, just think what this also means for trying to define=20 > a prot-sw=20 > > strategy in the client layer network topology when server=20 > layer trails=20 > > on non-affected client link-connections just 'get taken away'. > >=20 > > The reason we are not seeing this consequence is that there=20 > are strict=20 > > topological constraining assumptions, ie a pair of 1-hop client=20 > > link-connections ('ACs') at each end (with unknown/undefined server=20 > > layer support), and a 1-hop PW/MPLS server layer supporting=20 > the middle=20 > > link connection (with unknown/undefined server layer support below=20 > > MPLS). Any deviation from this to a more general case and the=20 > > problems I have highlighted will bite you. > >=20 > > If we had implemented what you guys are proposing as a > > general principle > > in our current networks we would be in complete mess now. > >=20 > > regards, Neil > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > Sent: 24 February 2005 22:48 > > > To: 'Shahram Davari'; 'Thomas D. Nadeau'; 'Luca Martini' > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org';=20 > > > 'mustapha.aissaoui@alcatel.com'; Harrison,N,Neil,IKM1 R > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > > > change to PW st atus. > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Thursday, February 24, 2005 5:41 PM > > > > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau'; > > > 'Luca Martini' > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > > > > change to PW > > > > st atus. > > > >=20 > > > >=20 > > > > Hi Peter, > > > >=20 > > > > I know. But my question is regarding this statement: > > > >=20 > > > > "However, if the other PE does not support Label > > Withdraw, it must > > > > generate an alarm, as Luca proposed in an earlier email." > > > >=20 > > > > If label withdrawal is a mandatory part of LDP, then how is it=20 > > > > possible that a PE may not support it? > > >=20 > > >=20 > > > Perhaps my wording was imprecise. It should have been "if the=20 > > > other PE does not support Label Withdraw as a mechanism to=20 > > > signal AC or PW failures". > > >=20 > > > Does that help? > > >=20 > > >=20 > > > >=20 > > > > Thanks > > > > Shahram > > > >=20 > > > > > -----Original Message----- > > > > > From: Busschbach, Peter B (Peter)=20 > [mailto:busschbach@lucent.com] > > > > > Sent: Thursday, February 24, 2005 5:07 PM > > > > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > > > > > change to PW > > > > > st atus. > > > > >=20 > > > > >=20 > > > > > Yes, Label Withdraw is a mandatory part of LDP per se.=20 > > > > > However, the issue here is its usage in relation to OAM. > > > > >=20 > > > > > If we didn't have the situation with legacy equipment, the=20 > > > > > OAM procedures are as described in the oam-msg-map draft,=20 > > > > > i.e. in case of failures, generate AIS or send PW Status. To=20 > > > > > deal with legacy equipment, the algorithm must now include a=20 > > > > > check on the capabilities of the peer: > > > > >=20 > > > > > IF THEN ELSE=20 > > > > > > > > > >=20 > > > > > Peter > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > Sent: Thursday, February 24, 2005 4:58 PM > > > > > > To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau';=20 > > > > > 'Luca Martini' > > > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > > > Subject: RE: [PWE3] Control protocol draft - section 5.3.1=20 > > > > > > change to PW > > > > > > st atus. > > > > > >=20 > > > > > >=20 > > > > > > Thanks Peter, > > > > > >=20 > > > > > > Isn't Label withdrawal a mandatory implementation in LDP? > > > > > >=20 > > > > > > -Shahram > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Busschbach, Peter B (Peter)=20 > > > [mailto:busschbach@lucent.com] > > > > > > > Sent: Thursday, February 24, 2005 4:55 PM > > > > > > > To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini' > > > > > > > Cc: 'Benny Ammitzboll'; 'pwe3@ietf.org'; > > > > > > > 'mustapha.aissaoui@alcatel.com'; 'neil.2.harrison@bt.com' > > > > > > > Subject: RE: [PWE3] Control protocol draft -=20 > section 5.3.1=20 > > > > > > > change to PW > > > > > > > st atus. > > > > > > >=20 > > > > > > >=20 > > > > > > > Forgot to add something. Please see below. > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Busschbach, Peter B (Peter)=20 > > > > > > > > Sent: Thursday, February 24, 2005 4:51 PM > > > > > > > > To: 'Shahram Davari'; 'Thomas D. Nadeau'; Luca Martini > > > > > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org;=20 > > > > > > > mustapha.aissaoui@alcatel.com; > > > > > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > > > > > Subject: RE: [PWE3] Control protocol draft -=20 > > section 5.3.1=20 > > > > > > > > change to PW > > > > > > > > st atus. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hi Shahram, > > > > > > > >=20 > > > > > > > > See 5.3.3: Pseudowire Status Negotiation Procedures. > > > > > > >=20 > > > > > > >=20 > > > > > > > If one of the two PEs indicates that it cannot support PW=20 > > > > > > > Status, Label Withdraw is the assumed mechanism.=20 > > However, if=20 > > > > > > > the other PE does not support Label Withdraw, it must=20 > > > > > > > generate an alarm, as Luca proposed in an earlier email.=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Peter > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: Shahram Davari=20 > > > [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > > > > Sent: Thursday, February 24, 2005 2:57 PM > > > > > > > > > To: 'Thomas D. Nadeau'; Luca Martini > > > > > > > > > Cc: 'Benny Ammitzboll'; pwe3@ietf.org;=20 > > > > > > > > mustapha.aissaoui@alcatel.com; > > > > > > > > > neil.2.harrison@bt.com; Busschbach, Peter B (Peter) > > > > > > > > > Subject: RE: [PWE3] Control protocol draft -=20 > > > section 5.3.1=20 > > > > > > > > > change to PW > > > > > > > > > st atus. > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > How can the negotiation result in Label=20 > > > > Withdrawal, if it is=20 > > > > > > > > > not implemented? > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > > > > > > > > Sent: Thursday, February 24, 2005 2:52 PM > > > > > > > > > > To: Luca Martini > > > > > > > > > > Cc: 'Benny Ammitzboll'; Shahram Davari;=20 > pwe3@ietf.org; > > > > > > > > > > mustapha.aissaoui@alcatel.com;=20 > > neil.2.harrison@bt.com;=20 > > > > > > > > > > Busschbach, Peter > > > > > > > > > > B (Peter) > > > > > > > > > > Subject: Re: [PWE3] Control protocol draft -=20 > > > > section 5.3.1=20 > > > > > > > > > > change to PW > > > > > > > > > > st atus. > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > Cool with me. So I think it should be worded > > > > > > > > > > like: > > > > > > > > > >=20 > > > > > > > > > > If the PW status negotiation results in Label=20 > > Withdraw=20 > > > > > > > method then > > > > > > > > > > you SHOULD use either 1) label withdraw=20 > > method, or 2) if > > > > > > > > > > label withdraw is not implemented, we=20 > disable the PW=20 > > > > > > > with a label > > > > > > > > > > release error message. > > > > > > > > > >=20 > > > > > > > > > > --tom > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > > Excellent , it sound like we are converging. > > > > > > > > > > > However we need to agree on the logic of this=20 > > > PW status=20 > > > > > > > > procedure. > > > > > > > > > > > If the PW status negotiation results in Label=20 > > > Withdraw=20 > > > > > > > > > method then : > > > > > > > > > > > > > > > > > > > > > > 1) we use label withdraw method ( MAY option ) > > > > > > > > > > > 2) if label withdraw is not implemented , we=20 > > > > disable the=20 > > > > > > > > > PW with a=20 > > > > > > > > > > > label release error message. > > > > > > > > > > > 3) we do nothing. however in this case PW=20 > > > > messaging would=20 > > > > > > > > > be broken. > > > > > > > > > > > > > > > > > > > > > > I think that we need #1 and #2 in the=20 > text with the=20 > > > > > > > > corresponding=20 > > > > > > > > > > > error for #2 > > > > > > > > > > > > > > > > > > > > > > Do you agree ? > > > > > > > > > > > > > > > > > > > > > > Luca > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shahram Davari wrote: > > > > > > > > > > > > > > > > > > > > > >> This is a reasonable suggestion. > > > > > > > > > > >> > > > > > > > > > > >> -Shahram > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>>> I have made this point in an earlier email,=20 > > > > > but I think=20 > > > > > > > > > > it is worth=20 > > > > > > > > > > >>>> repeating. I believe that this MUST should=20 > > > be a MAY. > > > > > > > > > > >>>> > > > > > > > > > > >>> Peter, > > > > > > > > > > >>> > > > > > > > > > > >>> This seems reasonable (and flexible) to=20 > > > > > me. In fact, > > > > > > > > > > >>> I thought we all agreed to a MAY a while back. > > > > > > > > > > >>> > > > > > > > > > > >>> --Tom > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >> > > > > > > > > > > >> _______________________________________________ > > > > > > > > > > >> pwe3 mailing list > > > > > > > > > > >> pwe3@ietf.org > > > > > > > > > > >> https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > >> > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 12:10:28 -0700 Lines: 91 References: <4B6D09F3B826D411A67300D0B706EFDE0115D4A6@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, 'Benny Ammitzboll' X-From: pwe3-bounces@ietf.org Fri Feb 25 20:09:10 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115D4A6@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Yes, as I said before the MAY will have more chances of passing the AD/IESG review. here is the text : ---------------------------------------------------------- .Pc "Use of Label Mappings." The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the attachment circuit state. The PW label should not be withdrawn unless the user administratively configures the pseudo wire down (or the PW configuration is deleted entirely). Using the procedures outlined in this section a simple label withdraw method MAY also be supported as a legacy means of signaling PW status. In any case if the Label mapping is not available the PW MUST be considered in the down state. Once, the PW status negotiation procedures are completed and if they result in the use of the label withdraw method for PW status communication, and this method is not supported by the PE, then the PW MUST be disabled and a label release message MUST be sent to the remote PE with the following error: "Label Withdraw PW Status Method Not Supported" If the label withdraw method for PW status communication is selected for the PW, it will result in the PW label mapping message being advertised only if the attachment circuit becomes active. The PW status signaling procedures described in this section MUST be fully implemented. ---------------------------------------------------- I also corrected the spelling error that Tom pointed out. Luca Shahram Davari wrote: >I will also go with MAY. > >-Shahram > > > >>-----Original Message----- >>From: Andrew G. Malis [mailto:andymalis@comcast.net] >>Sent: Friday, February 25, 2005 7:58 AM >>To: David Allan >>Cc: "'Benny Ammitzboll'"; pwe3@ietf.org; Thomas D. Nadeau; Shahram >>Davari; mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; >>Busschbach, Peter B (Peter); Luca Martini >>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 >>change to PW >>status. >> >> >>OK, I give in to Benny and Dave. Let's incorporate Benny's >>clarification >>and make the "SHOULD" a "MAY". >> >>Thanks, >>Andy >> >>----------- >> >>At 2/25/2005 07:24 AM -0500, David Allan wrote: >> >> >> >>>>I think we have to spell out very clearly that the label >>>>withdraw is not the way to signal AC state to the remote PE. >>>>For this reason I also think the SHOULD should just be a MAY. >>>> >>>> >>>I agree with this. There are clearly consequences to a label >>> >>> >>withdraw that >> >> >>>must be supported, but it should not be used to communicate >>> >>> >>AC state (and >> >> >>>IMO administative state). >>> >>>Dave >>> >>> From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 12:10:52 -0700 Lines: 91 References: <4B6D09F3B826D411A67300D0B706EFDE0115D4A6@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, 'Benny Ammitzboll' X-From: pwe3-bounces@ietf.org Fri Feb 25 20:10:32 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115D4A6@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Yes, as I said before the MAY will have more chances of passing the AD/IESG review. here is the text : ---------------------------------------------------------- .Pc "Use of Label Mappings." The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the attachment circuit state. The PW label should not be withdrawn unless the user administratively configures the pseudo wire down (or the PW configuration is deleted entirely). Using the procedures outlined in this section a simple label withdraw method MAY also be supported as a legacy means of signaling PW status. In any case if the Label mapping is not available the PW MUST be considered in the down state. Once, the PW status negotiation procedures are completed and if they result in the use of the label withdraw method for PW status communication, and this method is not supported by the PE, then the PW MUST be disabled and a label release message MUST be sent to the remote PE with the following error: "Label Withdraw PW Status Method Not Supported" If the label withdraw method for PW status communication is selected for the PW, it will result in the PW label mapping message being advertised only if the attachment circuit becomes active. The PW status signaling procedures described in this section MUST be fully implemented. ---------------------------------------------------- I also corrected the spelling error that Tom pointed out. Luca Shahram Davari wrote: >I will also go with MAY. > >-Shahram > > > >>-----Original Message----- >>From: Andrew G. Malis [mailto:andymalis@comcast.net] >>Sent: Friday, February 25, 2005 7:58 AM >>To: David Allan >>Cc: "'Benny Ammitzboll'"; pwe3@ietf.org; Thomas D. Nadeau; Shahram >>Davari; mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; >>Busschbach, Peter B (Peter); Luca Martini >>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 >>change to PW >>status. >> >> >>OK, I give in to Benny and Dave. Let's incorporate Benny's >>clarification >>and make the "SHOULD" a "MAY". >> >>Thanks, >>Andy >> >>----------- >> >>At 2/25/2005 07:24 AM -0500, David Allan wrote: >> >> >> >>>>I think we have to spell out very clearly that the label >>>>withdraw is not the way to signal AC state to the remote PE. >>>>For this reason I also think the SHOULD should just be a MAY. >>>> >>>> >>>I agree with this. There are clearly consequences to a label >>> >>> >>withdraw that >> >> >>>must be supported, but it should not be used to communicate >>> >>> >>AC state (and >> >> >>>IMO administative state). >>> >>>Dave >>> >>> From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Shahram Davari Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 11:38:31 -0800 Lines: 124 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "Thomas D. Nadeau" , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, 'Benny Ammitzboll' X-From: pwe3-bounces@ietf.org Fri Feb 25 20:37:27 2005 To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Luca, One more thing. When a PE withdraws a label, what should the other PE do? Should it generate AIS? and if so how does it know that this is an administrative label withdrawal or it is caused by AC being down? -Shahram > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Friday, February 25, 2005 2:11 PM > To: Shahram Davari > Cc: 'Andrew G. Malis'; David Allan; 'Benny Ammitzboll'; pwe3@ietf.org; > Thomas D. Nadeau; mustapha.aissaoui@alcatel.com; > neil.2.harrison@bt.com; > Busschbach, Peter B (Peter) > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Yes, as I said before the MAY will have more chances of passing the > AD/IESG review. > here is the text : > > ---------------------------------------------------------- > .Pc "Use of Label Mappings." > The PEs MUST send PW label mapping messages to their peers as > soon as the PW > is configured and administratively enabled, regardless of the > attachment > circuit state. The PW label should not be withdrawn unless the user > administratively configures the pseudo wire down (or the PW > configuration is deleted entirely). Using the procedures > outlined in this > section a simple label withdraw method MAY also be supported > as a legacy > means of signaling PW status. In any case if the Label mapping is not > available the PW MUST be considered in the down state. > > Once, the PW status negotiation procedures are completed and > if they result > in the use of the label withdraw method for PW status > communication, and > this method is not supported by the PE, then the PW MUST be > disabled and a > label release message MUST be sent to the remote PE with the > following > error: > > "Label Withdraw PW Status Method Not Supported" > > If the label withdraw method for PW status communication is > selected for the > PW, it will result in the PW label mapping message being > advertised only if > the attachment circuit becomes active. > The PW status signaling procedures described in this section > MUST be fully > implemented. > ---------------------------------------------------- > > I also corrected the spelling error that Tom pointed out. > > Luca > > > > Shahram Davari wrote: > > >I will also go with MAY. > > > >-Shahram > > > > > > > >>-----Original Message----- > >>From: Andrew G. Malis [mailto:andymalis@comcast.net] > >>Sent: Friday, February 25, 2005 7:58 AM > >>To: David Allan > >>Cc: "'Benny Ammitzboll'"; pwe3@ietf.org; Thomas D. Nadeau; Shahram > >>Davari; mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > >>Busschbach, Peter B (Peter); Luca Martini > >>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > >>change to PW > >>status. > >> > >> > >>OK, I give in to Benny and Dave. Let's incorporate Benny's > >>clarification > >>and make the "SHOULD" a "MAY". > >> > >>Thanks, > >>Andy > >> > >>----------- > >> > >>At 2/25/2005 07:24 AM -0500, David Allan wrote: > >> > >> > >> > >>>>I think we have to spell out very clearly that the label > >>>>withdraw is not the way to signal AC state to the remote PE. > >>>>For this reason I also think the SHOULD should just be a MAY. > >>>> > >>>> > >>>I agree with this. There are clearly consequences to a label > >>> > >>> > >>withdraw that > >> > >> > >>>must be supported, but it should not be used to communicate > >>> > >>> > >>AC state (and > >> > >> > >>>IMO administative state). > >>> > >>>Dave > >>> > >>> > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 14:44:20 -0500 Lines: 134 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "Thomas D. Nadeau" , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, 'Benny Ammitzboll' X-From: pwe3-bounces@ietf.org Fri Feb 25 20:41:53 2005 To: "'Luca Martini'" , Shahram Davari X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Hi Luca, Suggestions for a few minor modifications ... > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Friday, February 25, 2005 2:11 PM > To: Shahram Davari > Cc: 'Andrew G. Malis'; David Allan; 'Benny Ammitzboll'; pwe3@ietf.org; > Thomas D. Nadeau; mustapha.aissaoui@alcatel.com; > neil.2.harrison@bt.com; > Busschbach, Peter B (Peter) > Subject: Re: [PWE3] Control protocol draft - section 5.3.1 > change to PW > st atus. > > > Yes, as I said before the MAY will have more chances of passing the > AD/IESG review. > here is the text : > > ---------------------------------------------------------- > .Pc "Use of Label Mappings." > The PEs MUST send PW label mapping messages to their peers as > soon as the PW > is configured and administratively enabled, regardless of the > attachment > circuit state. The PW label should not be withdrawn unless the user I would use "operator" instead of "user". > administratively configures the pseudo wire down (or the PW > configuration is deleted entirely). Using the procedures > outlined in this > section a simple label withdraw method MAY also be supported > as a legacy > means of signaling PW status. Strictly speaking, it should be "PW and AC status" > In any case if the Label mapping is not > available the PW MUST be considered in the down state. > > Once, the PW status negotiation procedures are completed and > if they result > in the use of the label withdraw method for PW status > communication, and > this method is not supported by the PE, then the PW MUST be > disabled and a label release message MUST be sent to the > remote PE with the following error: I would prefer: "... this method is not supported by one of the PEs, than that PE must send a label release message to its peer with the following error ..." I consider this an improvement because: (a) it removes the ambiguity of which PE is supposed to release the PW, and (b) the term "disable" is not defined in the document . > > "Label Withdraw PW Status Method Not Supported" > > If the label withdraw method for PW status communication is > selected for the > PW, it will result in the PW label mapping message being > advertised only if > the attachment circuit becomes active. Perhaps it is more accurate to say "is active" instead of "becomes active". > The PW status signaling procedures described in this section > MUST be fully > implemented. > ---------------------------------------------------- > > I also corrected the spelling error that Tom pointed out. > > Luca > > > > Shahram Davari wrote: > > >I will also go with MAY. > > > >-Shahram > > > > > > > >>-----Original Message----- > >>From: Andrew G. Malis [mailto:andymalis@comcast.net] > >>Sent: Friday, February 25, 2005 7:58 AM > >>To: David Allan > >>Cc: "'Benny Ammitzboll'"; pwe3@ietf.org; Thomas D. Nadeau; Shahram > >>Davari; mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; > >>Busschbach, Peter B (Peter); Luca Martini > >>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 > >>change to PW > >>status. > >> > >> > >>OK, I give in to Benny and Dave. Let's incorporate Benny's > >>clarification > >>and make the "SHOULD" a "MAY". > >> > >>Thanks, > >>Andy > >> > >>----------- > >> > >>At 2/25/2005 07:24 AM -0500, David Allan wrote: > >> > >> > >> > >>>>I think we have to spell out very clearly that the label > >>>>withdraw is not the way to signal AC state to the remote PE. > >>>>For this reason I also think the SHOULD should just be a MAY. > >>>> > >>>> > >>>I agree with this. There are clearly consequences to a label > >>> > >>> > >>withdraw that > >> > >> > >>>must be supported, but it should not be used to communicate > >>> > >>> > >>AC state (and > >> > >> > >>>IMO administative state). > >>> > >>>Dave > >>> > >>> > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: Control protocol draft - section 5.3.1 change to PW status. Date: Fri, 25 Feb 2005 14:04:34 -0700 Lines: 202 References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "Thomas D. Nadeau" , Shahram Davari , pwe3@ietf.org, mustapha.aissaoui@alcatel.com, neil.2.harrison@bt.com, "Busschbach, Peter B $Peter$" X-From: pwe3-bounces@ietf.org Fri Feb 25 22:02:04 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,117,1107752400"; d="scan'208"; a="38484336:sNHT22460038" User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?Benny_Ammitzb=F8ll?= In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA01574 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Benny Ammitzb=F8ll wrote: >The sentence "The PW label should not be withdrawn unless the user >administratively configures the attachment circuit down" stands on its o= wn >early on. It is confusing me - am I right in assuming that a PE that >supports the Status message (and has negotiated to use the Status messag= e) >should *only* send a label withdraw if the PW itself is deleted or set t= o >admin down? This sentence makes it sound like it is ok to send a label >withdraw when the user sets the AC admin state down - even if the Status >message is in use! > =20 > yes I agree , I 'll change the text to be more clear. Luca >I think we have to spell out very clearly that the label withdraw is not= the >way to signal AC state to the remote PE. For this reason I also think th= e >SHOULD should just be a MAY. > >/Benny > >-----Original Message----- >From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of >Luca Martini >Sent: 25. februar 2005 03:10 >To: Busschbach, Peter B (Peter) >Cc: Thomas D. Nadeau; Shahram Davari; pwe3@ietf.org; 'Benny Ammitzboll'; >neil.2.harrison@bt.com; mustapha.aissaoui@alcatel.com >Subject: Re: [PWE3] Control protocol draft - section 5.3.1 change to PW >status. > > >Ok, >here is the section in question : >--------------------------------------------- >.Pc "Use of Label Mappings." >The PEs MUST send PW label mapping messages to their peers as soon as th= e PW >is configured and administratively enabled, regardless of the attachment >circuit state. The PW label should not be withdrawn unless the user >administratively configures the attachment circuit down (or the PW >configuration is deleted entirely). Using the procedures outlined in thi= s >section a simple label withdraw method SHOULD also be supported as a leg= acy >means of signaling PW status. In any case if the Label mapping is not >available the PW MUST be considered in the down state. > >Once, the PW status negotiation procedures are completed and if they res= ult >in the use of the label withdraw method for PW status communication, and >this method is not supported by the PE, then the PW MUST be disabled and= a >label release message MUST be sent to he remote PE with the following er= ror: > >"Label Withdraw PW Status Method Not Supported" > >If the label withdraw method for PW status communication is selected for= the >PW, it will result in the PW label mapping message being advertised onl= y if >the attachment circuit becomes active. >The PW status signaling procedures described in this section MUST be ful= ly >implemented. >---------------------------------------------------------- > >Is this ok ? > >I am in favor of the SHOULD myself , but it might not make the AD/IESG >review. They will probably ask in what situation is this part not going >to be implemented ? > >Luca > > > >Busschbach, Peter B (Peter) wrote: > > =20 > >>I agree with Andy's proposal. >> >>Peter >> >> >> >> =20 >> >>>-----Original Message----- >>>From: Andrew G. Malis [mailto:andymalis@comcast.net] >>>Sent: Thursday, February 24, 2005 3:50 PM >>>To: Thomas D. Nadeau >>>Cc: Luca Martini; Shahram Davari; pwe3@ietf.org; 'Benny Ammitzboll'; >>>Busschbach, Peter B (Peter); neil.2.harrison@bt.com; >>>mustapha.aissaoui@alcatel.com >>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>>change to PW >>>st atus. >>> >>> >>>The SHOULD in Tom's text below needs to be a MUST, since if >>>the negotiation >>>results in using the Withdraw method, then you MUST follow >>>Tom's algorithm. >>> >>>I would also prefer that implementations SHOULD implement >>>Withdraw for >>>backwards compatibility, rather than MAY, to encourage backwards >>>compatibility without actually requiring it. When the >>>Proposed Standard >>>goes for Draft Standard, we can think about lessening the >>>SHOULD to a MAY >>>(or even removing it), since hopefully at that point the >>>installed base >>>would have migrated to the RFC. >>> >>>Cheers, >>>Andy >>> >>>------------ >>> >>>At 2/24/2005 02:51 PM -0500, Thomas D. Nadeau wrote: >>> >>> >>> >>> =20 >>> >>>> Cool with me. So I think it should be worded >>>>like: >>>> >>>>If the PW status negotiation results in Label Withdraw method then >>>>you SHOULD use either 1) label withdraw method, or 2) if >>>>label withdraw is not implemented, we disable the PW with a label >>>>release error message. >>>> >>>> --tom >>>> >>>> >>>> >>>> >>>> =20 >>>> >>>>>Excellent , it sound like we are converging. >>>>>However we need to agree on the logic of this PW status procedure. >>>>>If the PW status negotiation results in Label Withdraw method then : >>>>> >>>>>1) we use label withdraw method ( MAY option ) >>>>>2) if label withdraw is not implemented , we disable the PW >>>>> >>>>> >>>>> =20 >>>>> >>>with a label >>> >>> >>> =20 >>> >>>>>release error message. >>>>>3) we do nothing. however in this case PW messaging would be broken. >>>>> >>>>>I think that we need #1 and #2 in the text with the >>>>> >>>>> >>>>> =20 >>>>> >>>corresponding error >>> >>> >>> =20 >>> >>>>>for #2 >>>>> >>>>>Do you agree ? >>>>> >>>>>Luca >>>>> >>>>> >>>>> =20 >>>>> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> =20 >> > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > =20 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 14:23:48 -0700 Lines: 181 References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , Shahram Davari , pwe3@ietf.org, 'Benny Ammitzboll' , neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Fri Feb 25 22:21:58 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,117,1107752400"; d="scan'208"; a="38487141:sNHT22258132" User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: "Busschbach, Peter B (Peter)" In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Very good , I added all suggestions below. Luca Busschbach, Peter B (Peter) wrote: >Hi Luca, > >Suggestions for a few minor modifications ... > > > >>-----Original Message----- >>From: Luca Martini [mailto:lmartini@cisco.com] >>Sent: Friday, February 25, 2005 2:11 PM >>To: Shahram Davari >>Cc: 'Andrew G. Malis'; David Allan; 'Benny Ammitzboll'; pwe3@ietf.org; >>Thomas D. Nadeau; mustapha.aissaoui@alcatel.com; >>neil.2.harrison@bt.com; >>Busschbach, Peter B (Peter) >>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>change to PW >>st atus. >> >> >>Yes, as I said before the MAY will have more chances of passing the >>AD/IESG review. >>here is the text : >> >>---------------------------------------------------------- >>.Pc "Use of Label Mappings." >>The PEs MUST send PW label mapping messages to their peers as >>soon as the PW >>is configured and administratively enabled, regardless of the >>attachment >>circuit state. The PW label should not be withdrawn unless the user >> >> > >I would use "operator" instead of "user". > > > >>administratively configures the pseudo wire down (or the PW >>configuration is deleted entirely). Using the procedures >>outlined in this >>section a simple label withdraw method MAY also be supported >>as a legacy >>means of signaling PW status. >> >> > >Strictly speaking, it should be "PW and AC status" > > > >>In any case if the Label mapping is not >>available the PW MUST be considered in the down state. >> >>Once, the PW status negotiation procedures are completed and >>if they result >>in the use of the label withdraw method for PW status >>communication, and >>this method is not supported by the PE, then the PW MUST be >>disabled and a label release message MUST be sent to the >>remote PE with the following error: >> >> > >I would prefer: "... this method is not supported by one of the PEs, than that PE must send a label release message to its peer with the following error ..." > >I consider this an improvement because: (a) it removes the ambiguity of which PE is supposed to release the PW, and (b) the term "disable" is not defined in the document . > > > >>"Label Withdraw PW Status Method Not Supported" >> >>If the label withdraw method for PW status communication is >>selected for the >>PW, it will result in the PW label mapping message being >>advertised only if >>the attachment circuit becomes active. >> >> > >Perhaps it is more accurate to say "is active" instead of "becomes active". > > > > >>The PW status signaling procedures described in this section >>MUST be fully >>implemented. >>---------------------------------------------------- >> >>I also corrected the spelling error that Tom pointed out. >> >>Luca >> >> >> >>Shahram Davari wrote: >> >> >> >>>I will also go with MAY. >>> >>>-Shahram >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Andrew G. Malis [mailto:andymalis@comcast.net] >>>>Sent: Friday, February 25, 2005 7:58 AM >>>>To: David Allan >>>>Cc: "'Benny Ammitzboll'"; pwe3@ietf.org; Thomas D. Nadeau; Shahram >>>>Davari; mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; >>>>Busschbach, Peter B (Peter); Luca Martini >>>>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 >>>>change to PW >>>>status. >>>> >>>> >>>>OK, I give in to Benny and Dave. Let's incorporate Benny's >>>>clarification >>>>and make the "SHOULD" a "MAY". >>>> >>>>Thanks, >>>>Andy >>>> >>>>----------- >>>> >>>>At 2/25/2005 07:24 AM -0500, David Allan wrote: >>>> >>>> >>>> >>>> >>>> >>>>>>I think we have to spell out very clearly that the label >>>>>>withdraw is not the way to signal AC state to the remote PE. >>>>>>For this reason I also think the SHOULD should just be a MAY. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I agree with this. There are clearly consequences to a label >>>>> >>>>> >>>>> >>>>> >>>>withdraw that >>>> >>>> >>>> >>>> >>>>>must be supported, but it should not be used to communicate >>>>> >>>>> >>>>> >>>>> >>>>AC state (and >>>> >>>> >>>> >>>> >>>>>IMO administative state). >>>>> >>>>>Dave >>>>> >>>>> >>>>> >>>>> > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus. Date: Fri, 25 Feb 2005 14:26:57 -0700 Lines: 164 References: <4B6D09F3B826D411A67300D0B706EFDE0115D4B1@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , pwe3@ietf.org, 'Benny Ammitzboll' , "Busschbach, Peter B $Peter$" , neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com X-From: pwe3-bounces@ietf.org Fri Feb 25 22:24:57 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115D4B1@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Shahram Davari wrote: >Luca, > >One more thing. When a PE withdraws a label, what should the other PE do? >Should it generate AIS? and if so how does it know that this is an > > yes, that should be specified in the technology specific draft. >administrative label withdrawal or it is caused by AC being down? > > > It does not , that is why we have the new "better" method of PW status signaling using a PW status TLV , that indicates precisely what is happening. Luca >-Shahram > > > >>-----Original Message----- >>From: Luca Martini [mailto:lmartini@cisco.com] >>Sent: Friday, February 25, 2005 2:11 PM >>To: Shahram Davari >>Cc: 'Andrew G. Malis'; David Allan; 'Benny Ammitzboll'; pwe3@ietf.org; >>Thomas D. Nadeau; mustapha.aissaoui@alcatel.com; >>neil.2.harrison@bt.com; >>Busschbach, Peter B (Peter) >>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 >>change to PW >>st atus. >> >> >>Yes, as I said before the MAY will have more chances of passing the >>AD/IESG review. >>here is the text : >> >>---------------------------------------------------------- >>.Pc "Use of Label Mappings." >>The PEs MUST send PW label mapping messages to their peers as >>soon as the PW >>is configured and administratively enabled, regardless of the >>attachment >>circuit state. The PW label should not be withdrawn unless the user >>administratively configures the pseudo wire down (or the PW >>configuration is deleted entirely). Using the procedures >>outlined in this >>section a simple label withdraw method MAY also be supported >>as a legacy >>means of signaling PW status. In any case if the Label mapping is not >>available the PW MUST be considered in the down state. >> >>Once, the PW status negotiation procedures are completed and >>if they result >>in the use of the label withdraw method for PW status >>communication, and >>this method is not supported by the PE, then the PW MUST be >>disabled and a >>label release message MUST be sent to the remote PE with the >>following >>error: >> >>"Label Withdraw PW Status Method Not Supported" >> >>If the label withdraw method for PW status communication is >>selected for the >>PW, it will result in the PW label mapping message being >>advertised only if >>the attachment circuit becomes active. >>The PW status signaling procedures described in this section >>MUST be fully >>implemented. >>---------------------------------------------------- >> >>I also corrected the spelling error that Tom pointed out. >> >>Luca >> >> >> >>Shahram Davari wrote: >> >> >> >>>I will also go with MAY. >>> >>>-Shahram >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Andrew G. Malis [mailto:andymalis@comcast.net] >>>>Sent: Friday, February 25, 2005 7:58 AM >>>>To: David Allan >>>>Cc: "'Benny Ammitzboll'"; pwe3@ietf.org; Thomas D. Nadeau; Shahram >>>>Davari; mustapha.aissaoui@alcatel.com; neil.2.harrison@bt.com; >>>>Busschbach, Peter B (Peter); Luca Martini >>>>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 >>>>change to PW >>>>status. >>>> >>>> >>>>OK, I give in to Benny and Dave. Let's incorporate Benny's >>>>clarification >>>>and make the "SHOULD" a "MAY". >>>> >>>>Thanks, >>>>Andy >>>> >>>>----------- >>>> >>>>At 2/25/2005 07:24 AM -0500, David Allan wrote: >>>> >>>> >>>> >>>> >>>> >>>>>>I think we have to spell out very clearly that the label >>>>>>withdraw is not the way to signal AC state to the remote PE. >>>>>>For this reason I also think the SHOULD should just be a MAY. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I agree with this. There are clearly consequences to a label >>>>> >>>>> >>>>> >>>>> >>>>withdraw that >>>> >>>> >>>> >>>> >>>>>must be supported, but it should not be used to communicate >>>>> >>>>> >>>>> >>>>> >>>>AC state (and >>>> >>>> >>>> >>>> >>>>>IMO administative state). >>>>> >>>>>Dave >>>>> >>>>> >>>>> >>>>> > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: Stewart Bryant Subject: PWE3 agenda for IETF62 Date: Mon, 28 Feb 2005 10:33:45 +0000 Lines: 90 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3 X-From: pwe3-bounces@ietf.org Mon Feb 28 11:32:18 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: agenda@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Pseudo Wire Emulation Edge to Edge (pwe3) ========================================= WEDNESDAY, March 9, 2005, (1530-1730) CHAIR: "Danny McPherson" "Stewart Bryant" AGENDA: 5 mins Administrivia Chairs (Stewart & Danny) Agenda Bashing Minutes Blue Sheets 5 mins WG Document Status Danny McPherson Stewart Bryant 20 mins Pseudowire Setup and Maintenance using LDP and Ethernet over MPLS Luca Martini draft-ietf-pwe3-control-protocol-15.txt draft-ietf-pwe3-ethernet-encap-09.txt Restructure of drafts following AD review 10 mins Frame Relay over Pseudo-Wires Luca Martini draft-ietf-pwe3-frame-relay-04.txt Update on the rewrite 5 mins PW Control Word Stewart Bryant Resolve any outstanding comments 15 mins Requirements for inter domain Pseudo-Wires Nabil Bitar draft-martini-pwe3-MH-PW-requirements-00.txt 10 mins Pseudo Wire (PW) OAM Message Mapping draft-ietf-pwe3-oam-msg-map-02.txt Mustapha Aissaoui 10 mins PWE3 Applications & OAM Scenarios Simon Delord draft-delord-pwe3-oam-applications-00.txt Introduction to Key Issues 10 mins Pseudowire QOS Signaling Himanshu Shah draft-shah-pwe3-PW-qos-signaling-02.txt Importance of QOS signaling, updates from last version and QOS signaling in MH-PW 10 mins Setup and Maintenance of Pseudowires using RSVP-TE Rahul Aggarwal draft-raggarwa-rsvpte-pw-01.txt This draft describes a mechanism for setting up Multi-Hop PWs and has been updated particularly to reflect the ongoing multi-hop PW requirements work in PWE3. 10 mins Multi-hop Pseudowire Setup and Maintenance using LDP David McDysan & Florin Balus Discuss new LDP extensions, end to end signaling procedures to address the related requirements specified in the MH-PWE3 Requirements draft. The procedures described in the draft enable the usage of addressing schemes (L2FECs) and other TLVs already defined for PWs in PW Control 5 mins The following item is subject to availability of time Multihop Pseudowire Signaling Himanshu Shah DRAFT TBS How LDP is used to signal primary and backup bidirectional MH-PW without having to configure switching PEs. From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: Padding REQUIREMENT removed from Frame relay draft Date: Mon, 28 Feb 2005 17:45:47 -0000 Lines: 28 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Mon Feb 28 18:43:10 2005 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] Padding REQUIREMENT removed from Frame relay draft Thread-Index: AcUZbfrOMhAn4DU0TkyAgAgpABN68AEThJPQ To: X-OriginalArrivalTime: 28 Feb 2005 17:45:47.0438 (UTC) FILETIME=[55BCACE0:01C51DBD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Tom, Folks, > I am a bit surprised by your comments given your active=20 > involvement in X.84. Also, I believe the IETF has made it=20 > clear on many occassions they address a different segment of=20 > the industry than ITU-T. =20 >=20 > Tom Indeed ITU address a different segment of the industry to IETF. However = I believe Neil's main point (which I support) is that two different SDOs = shouldn't produce a standard on the same thing. I appreciate that X.84 = contains lots of stuff that may not be in the IETF draft, but it also = contains lots of stuff that is already in the draft and that is likely = (definitely?) to cause headaches trying to keep the docs in sync. I am lead to believe that ETSI take a 'common sense' approach to this = sort of thing and reference the necessary sections of standards from = other SDOs and only include original text in ETSI's outputs. That seems = to me to be a good approach for all SDOs to take. I believe Neil's other point (which unsurprisingly I also support) is to = question whether ITU should ratify a standard when the document it is = based on (from IETF) is still a draft and not a standard. Anyway, I believe this is all out of scope for this list... Ben From pwe3-bounces@ietf.org Wed Dec 27 15:58:25 2006 From: "Walsh, Thomas D (Tom)" Subject: RE: Padding REQUIREMENT removed from Frame relay draft Date: Mon, 28 Feb 2005 12:57:25 -0500 Lines: 40 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Mon Feb 28 18:56:31 2005 To: "'benjamin.niven-jenkins@bt.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Ben Yes, Neil and I took it off list long ago. As far as what ITU should standardize, that is based on what contributions they get. ITU was doing Frame Relay long before IETF started pwe3. And FRF was doing FRF interworking long before IETF pwe3. At one point, about 3 plus years ago, there were one common draft between ITU-T, FRF, MPLS Forum and IETF with the same author. So the material was not exclusive to IETF. The other groups have long sinced finished their work. It will be nice when IETF finishes theirs. Any more comments will be off-line. Tom -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of benjamin.niven-jenkins@bt.com Sent: Monday, February 28, 2005 12:46 PM To: pwe3@ietf.org Cc: neil.2.harrison@bt.com Subject: RE: [PWE3] Padding REQUIREMENT removed from Frame relay draft Tom, Folks, > I am a bit surprised by your comments given your active > involvement in X.84. Also, I believe the IETF has made it > clear on many occassions they address a different segment of > the industry than ITU-T. > > Tom Indeed ITU address a different segment of the industry to IETF. However I believe Neil's main point (which I support) is that two different SDOs shouldn't produce a standard on the same thing. I appreciate that X.84 contains lots of stuff that may not be in the IETF draft, but it also contains lots of stuff that is already in the draft and that is likely (definitely?) to cause headaches trying to keep the docs in sync. I am lead to believe that ETSI take a 'common sense' approach to this sort of thing and reference the necessary sections of standards from other SDOs and only include original text in ETSI's outputs. That seems to me to be a good approach for all SDOs to take. I believe Neil's other point (which unsurprisingly I also support) is to question whether ITU should ratify a standard when the document it is based on (from IETF) is still a draft and not a standard. Anyway, I believe this is all out of scope for this list... Ben _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: m.rapoport@completel.fr Subject: Marc Rapoport est absent jusqu'au 7 =?iso-8859-1?q?F=E9vrier?= Date: Tue, 1 Feb 2005 01:01:20 +0100 Lines: 1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Tue Feb 01 01:29:34 2005 Return-path: To: pwe3@ietf.org X-MIMETrack: Serialize by Router on Notes01/CompleTel/fr(Release 5.0.10 |March 22, 2002) at 01/02/2005 01:01:21 X-Scan-Signature: 6d62ab47271805379d7172ee693a45db 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Je serai absent(e) du 31/01/2005 au 04/02/2005. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: FW: I-D ACTION:draft-ietf-pwe3-cesopsn-02.txt Date: Tue, 1 Feb 2005 09:38:22 +0200 Lines: 231 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C50831.018F10A0" Cc: Israel Sasson , "Prayson Pate $E-mail$" , "PWE3 WG $E-mail$" , "Eduard Metz $E-mail$" , "Tim Frost $E-mail$" X-From: pwe3-bounces@ietf.org Tue Feb 01 08:59:57 2005 To: "Stewart Bryant (E-mail)" , "Danny McPherson (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: 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. ------_=_NextPart_000_01C50831.018F10A0 Content-Type: text/plain; charset="windows-1255" Stewart, Danny and all, I've updated the CESoPSN draft in order to resolve the UDP usage issue mentioned in the latest PWE3 status report as a gate towards sending the draft to the IESG. The difference between the old and new UDP usage fragmens is shown below: <---The UDP usage fragment from the -01 draft starts---> Usage of UDP as the multiplexing mechanism is compliant with the traditional method used for multiplexing RTP flows, e.g.: 1. Each PE: a) Allocates one of the PE own IP addresses and a single UDP port for each local PW end point (CESoPSN IWF instance) b) Is aware (by configuration or via a signaling protocol) of the similar allocations associated with the remote peer PW end points 2. Each CESoPSN IWF instance uses the associated locally and remotely allocated UDP ports as correspondingly the Source and Destination UDP ports in all the CESoPSN packets its generates. <---The UDP usage fragment from the -01 draft ends----> <---The UDP usage fragment from the -02 draft starts---> UDP as the multiplexing mechanism for PWs SHOULD be used with manual configuration of both source and destination UDP ports. In addition, CESoPSN assumes that UDP-based demultiplexing is aligned with traditional demultiplexing of peer-to-peer applications, i.e.: 1. Each CESoPSN IWF instance is associated with ("local association"): a) One of the routable IP addresses of its containing PE. This IP address is treated as the local end-point of the PSN tunnel b) A unique (within the scope defined by this address) UDP port number that is used as the local demultiplexor of the CESoPSN PW packets within the corresponding PSN tunnel 2. Each CESoPSN IWF instance is aware (e.g., by configuration) of the similar association of its remote peer ("remote association") and, in each packet it generates, uses: a) The IP address and the UDP port number of its "remote" association as correspondingly the Destination IP address and UDP port b) The IP address and the UDP port number of its "local" association as correspondingly the Source IP address and UDP port. <---The UDP usage fragment from the -02 draft ends----> In addition, the references o other Internet-Drafts have been updated, the latest IPR disclosure boilerplate used, and, of course, the revision number and posting/epiration dates have been advanced. If you think that an additional WG Last Call on these changes is required, please announce it immediately. Otherwise IMO the draft could be sent to the IESG now. Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, January 31, 2005 10:46 PM > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: I-D ACTION:draft-ietf-pwe3-cesopsn-02.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Pseudo Wire Emulation Edge > to Edge Working Group of the IETF. > > Title : Structure-aware TDM Circuit Emulation > Service over > Packet Switched Network (CESoPSN) > Author(s) : S. Vainshtein, et al. > Filename : draft-ietf-pwe3-cesopsn-02.txt > Pages : 29 > Date : 2005-1-31 > > This document describes a method for encapsulating structured (NxDS0) > TDM signals as pseudo-wires over packet-switching networks (PSN). In > this regard, it complements similar work for structure-agnostic > emulation of TDM bit-streams [PWE3-SAToP]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-02.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-cesopsn-02.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-cesopsn-02.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_000_01C50831.018F10A0 Content-Type: message/rfc822 From foo@bar Wed Dec 27 15:58:27 2006 To: Subject: Date: Tue, 1 Feb 2005 09:38:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C50831.018F10A0" ------_=_NextPart_002_01C50831.018F10A0 Content-Type: text/plain ------_=_NextPart_002_01C50831.018F10A0 Content-Type: application/octet-stream; name="ATT27438.txt" Content-Disposition: attachment; filename="ATT27438.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: Multi-Hop Pseudo-Wires Signalling Using LDP Date: Tue, 01 Feb 2005 09:07:23 +0000 Lines: 6 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Tue Feb 01 10:13:20 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: pwe3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org The following draft was recently posted: Multi-Hop Pseudo-Wires Signalling Using LDP draft-yudong-pwe3-control-protocol-ext-01.txt Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: David McDysan Subject: RE: Multi-Hop Pseudo-Wires Signalling Using LDP Date: Tue, 01 Feb 2005 10:27:55 -0500 Lines: 81 References: <41FF46CB.1040405@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Tue Feb 01 16:41:01 2005 Return-path: In-reply-to: <41FF46CB.1040405@cisco.com> To: "'pwe3'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Interesting draft. A few comments and questions below. Dave Agree that hierarchy is an important driver. Suggest reference of the requirements I-D that describes the use cases for hierarchy in more = detail. draft-martini-pwe3-MH-PW-requirements-00.txt Should additional parameters be encoded in a separate TLV instead of augmenting the Generalized ID (GID) FEC already defined in draft-ietf-pwe3-control-protocol-11.txt? This could ease = interoperability considerations. The proposed next-Hop LSR ID TLV can be inferred from the LDP peer. Therefore, is this TLV necessary?=20 The proposed next-hop priority TLV could be learned from BGP (local = pref) or an IGP (metric) for the LDP peer. Therefore, is this TLV necessary? Does the "Reflector" in section 4.1, simple trunk mode, need to withdraw labels if a session with an LDP client fails? A few comments on section 4.2, "nexthop self" mode.=20 Suggest use of source/dest PE terminology defined at the end of section = 1 to improve readability throughout. Section 4.2 section uses terms such as "far-end" and "dest," and references to a particular PE are sometimes unclear later in the document. The "reflector" described with reference to Figure 4-2 appears to be = similar to a PW Switching PE (S-PE) function in the terminology defined in draft-martini-pwe3-MH-PW-requirements-00.txt where the PW FEC is the = same for all segments. Also, the S-PE determines the next hop toward the = target, as opposed to having to configure a "stitching" point. The "reflector" described with reference to Figure 4-3 appears to be = similar to PW Stitching of SH PW segments, which may have different PW FECs and different PSN tunnel types as described in draft-martini-pwe3-pw-switching-01.txt.=20 A unique aspect of the described approach is that the proposed = extenstion to PW LDP is used to "flood" the label binding from the source PE (i.e., = the PE distributing the PW label) to all "reflector" nodes until the target PE = is reached, creating the need for loop detection as described in section 9. This has the consequence that PW labels and other resources (e.g., = capacity if that is signaled) are reserved on all possible PW paths. This could = be inefficient in some topologies or applications. > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Stewart Bryant > Sent: Tuesday, February 01, 2005 4:07 AM > To: pwe3 > Subject: [PWE3] Multi-Hop Pseudo-Wires Signalling Using LDP >=20 >=20 > The following draft was recently posted: >=20 > Multi-Hop Pseudo-Wires Signalling Using LDP=20 > draft-yudong-pwe3-control-protocol-ext-01.txt >=20 > Stewart >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: David McDysan Subject: RE: Review of draft-martini-pwe3-MH-PW-requirements-00.txt Date: Tue, 01 Feb 2005 11:06:42 -0500 Lines: 75 References: <9473683187ADC049A855ED2DA739ABCA060CE40A@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Feb 01 17:31:08 2005 In-reply-to: <9473683187ADC049A855ED2DA739ABCA060CE40A@KCCLUST06EVS1.ugd.att.com> To: "'Ash, Gerald R (Jerry), ALABS'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Jerry, Finally had time to take a look at this I-D and the QSPEC template. IT = seems to include the functions and parameters (as well as many additional parameters) of which I was thinking.=20 I have not been following NSIS. Looking over the framework I-D, the = Network Transport Layer Protocol (NTLP) still seems to be only generally = defined. Would the proposed MH PW LDP be a viable candidate NTLP to determine = NSIS Element (NE) next hops? If not, is there some other NTLP that is being considered in NSIS that could be applicable to PW's? Dave > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > Sent: Wednesday, January 19, 2005 1:25 PM > To: David McDysan; Matthew.Bocci@alcatel.co.uk;=20 > benjamin.niven-jenkins@bt.com > Cc: Ash, Gerald R (Jerry), ALABS; pwe3-bounces@ietf.org;=20 > pwe3@ietf.org; Sasha@AXERRA.com > Subject: RE: [PWE3] Review of=20 > draft-martini-pwe3-MH-PW-requirements-00.txt >=20 >=20 > Dave, > Matthew, >=20 > > > Behalf Of Matthew.Bocci@alcatel.co.uk (MB) > > >=20 > > > 5) Section 6.3, 3rd paragraph: > > > "Ideally the PSN tunnel SHOULD have better QoS or same QoS > > > characteristics as the carried PW. However, in certain=20 > > > cases, an operator may need to bind a PW to a PSN tunnel with=20 > > > nominally lower QoS characteristics. > > >=20 > > > Is this saying that it is ok for a PW to expect a QoS of X > > > (which a customer is presumably paying for) and for that PW=20 > > > to be transported over a PSN tunnel with QoS of Y (where Y > > - doesn't seem right to me? > > >=20 > > > MB> In principle, I agree with you. However, I think the > > > text intended to refer to the fact that an operator may > > > choose to reroute a PW to a tunnel that doesn't strictly meet > > > the committed loss/delay characteristics if=20 > > > connectivity/availability is considered more important. In > > > any case, I'm not sure that such a discussion fits in a=20 > > > standardised requirements document. I think the simple=20 > > > statement that the PSN tunnel should have the same or better > > > QoS characteristics is adequate. >=20 > Dave> I recommend that we need to specify how the QoS > > characteristics are signaled. There needs to be some=20 > convention on how=20 > > to signal the requested QoS (in addition to traffic=20 > parameters (e.g.,=20 > > at least average rate, and possibly also burst duration and=20 > peak rate=20 > > (see RFC 2215). There are some drafts on a minimal set of Diffserv=20 > > PHBs and the associated semantics occurring in tsvwg and=20 > there is also > > an effort in the ITU-T updating Y.1540 and Y.1541 that may be > > relevant here. >=20 > If so, then NSIS-based QoS-NSLP signaling for Y.1541 QoS=20 > classes could also be relevant, see=20 > http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qsp-00.txt. >=20 > Thanks, > Jerry >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: David McDysan Subject: RE: Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt Date: Tue, 01 Feb 2005 12:10:37 -0500 Lines: 170 References: <0536FC9B908BEC4597EE721BE6A353890A9F1821@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Feb 01 18:42:47 2005 In-reply-to: <0536FC9B908BEC4597EE721BE6A353890A9F1821@i2km07-ukbr.domain1.systemhost.net> To: neil.2.harrison@bt.com X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Neil, Good to see that the thread is now related to (general) requirements. A few responses in line below trying to get to more specifics relevant = to the subject at hand. Regards, Dave > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Friday, January 28, 2005 5:22 AM > To: tnadeau@cisco.com; dave.mcdysan@mci.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Re: I-D=20 > ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt >=20 >=20 > Tom... >=20 > Wrt your mail 28 January 2005 06:49 >=20 > > > > > > > If you mean using (something like) VCCV to confirm data plane=20 > > > "liveliness" state of the PW and comparing this with the state=20 > > > determined by the control > > > signaling protocol then I agree. I think there are some additional > > > requirements related to MH-PW that were mentioned on this=20 > > thread that > > > relate > > > to being able do this on a SH PW segment basis of a MH PW > > in support > > > of at > > > least diagnostics and also performance measurement that I believe > > > should be > > > stated as a requirement. > >=20 > > This is something we should talk about when we > > can get together next (with Luca). We figured out > > how to do a lot of this already, just haven't > > released it. > >=20 > > --Tom > NH=3D> Well, I'm not convinced this has been 'figured out' to=20 > what I think are the key requirements to be met. Let me list=20 > some and you can tell me how well they are satisfied: >=20 > 1 In any client/server relationship (and PWs are for sure this) > one wants the management of the server to be independent of=20 > the client.....so that we can use the same (server)=20 > processing in all cases. Note functional=20 > re-use/simplification is a key goal to reduce complexity and=20 > opex (noting this plays through from NE to NMS/OSS efficacy). =20 As mentioned before, an Annex translating G.805 terminology to relevant = IETF terminology would be helpful. Approved documents communicate a message better than Email archives. My translation of the above is: MH PW = management should be independent of PSN tunnel management. >=20 > 2 In any client/server relationship the most basic requirement of > all is client (all planes) transparency over the server....or=20 > putting it another way, complete functional decoupling of the=20 > client and the server layer networks (this is NOT a specific=20 > OAM issue of course, its the most basic yet most important=20 > network arch requirement per se, but it does impact OAM). I need some help translating this one. >=20 > 4 There are 2 major types of OAM: (i) 'always on' defect > detection/handling and (ii) 'on-demand' diagnostics, PM. The=20 > former must be sorted before we can sensibly consider the=20 > latter, and the former must be simple/complete.....noting=20 > that the requirements to be met are NOT identical for each=20 > network mode. >=20 > 3 The defects that can affect each of the 3 network modes are > different. If we are dealing with MPLS as the server there=20 > should be breaks, swaps and mismerging defects specified in=20 > terms of clear entry/exit criteria and consequent=20 > actions....see next item. >=20 > 4 Defect detection/handling needs to be in the traffic data-plane > and unidirectional. In particular, consequent actions need=20 > to be taken at the trail sink. This is vital so that p2p and=20 > p2mp constructs can be handled similarly/scalably. 2 key=20 > consequent actions (if the client is > co) are (i) traffic suppression and (ii) FDI insertion to=20 > stop alarm storms. The precise syntax of FDI depends on the=20 > client technology. >=20 > 5 The activation/deactivation of the defect detection/handling > aspects of OAM must be done in concert with however the trail=20 > is set-up/taken-down (this can be via signalling or management). >=20 > 6 Before we can progress to PM we must have a clear definition of > the available state...as PM measurements (at least for any=20 > SLA purposes) are only valid when the trail is in the available state. >=20 > Note - Defects, availability and PM need to be standardised=20 > in order to have a common basis of specification for=20 > interworking and apportionment (of impairments) to tandemed=20 > operator domains. >=20 Is there anything incorrect or missing from section 6.6 of draft-martini-pwe3-MH-PW-requirements-00.txt? > 7 If either direction of a bi-directional trail enters the > unavailable state any PM measurements should be stopped for=20 > both directions. >=20 > 8 It should be possible to observe the defect/availability status > of both directions from a single end. >=20 > Note that Y.1711 was designed to meet the above requirements=20 > wrt basic defect detection/handling in the most simple way=20 > possible IMO. The above are not rocket-science nor are they=20 > unreasonable IMO....in fact I think they are rather simple=20 > and obvious requirements. Can you assure me that all these=20 > requirements can be met with some alternative OAM proposals? draft-ietf-pwe3-oam-msg-map-01.txt does not specify Y.1711 but specifies = LSP Ping instead. IMO, Y.1711 does not provide a means to communication detection of defects and associate them with the control protocol = signaled PW or PSN tunnel.=20 =20 >=20 > Maybe Dave doesn't care about some/any of this in his=20 > network....maybe others don't either, and I must admit I have=20 > been rather disappointed with the inputs (mainly lack of)=20 > that I have seen other operators on the topic of OAM in=20 > general in this forum. =20 To me it is a matter of practicality and priority. Coordinating control, data and management is important in many services, and I do not believe = that approaching them independently is a good architectural approach. Control protocols have detected a majority of faults in packet networks (connectionless and connection-oriented) for decades. Additional OAM protocols could detect some additional faults that control protocols do = not. In my experience with packet networks these OAM protocols would have detected faults that the control protocol and would have reduced unavailability on the order of 10^-6, if they were available.=20 > This does seem to be a persistent=20 > malaise of the operator community that they only seem to=20 > get-wise about stuff like OAM 'after the event'...when its=20 > usually too late to do much about it. OAM considerations=20 > should not be some afterthought, they should be designed-in=20 > to the architecture from t=3D0. The approach I prefer is to first (t=3D0) agree on the requirements of = what is to be done and then decide on the appropriate management approach at = t>0.=20 >=20 > regards, Neil >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Chris Metz Subject: Re: Multi-Hop Pseudo-Wires Signalling Using LDP Date: Tue, 01 Feb 2005 09:14:17 -0800 Lines: 20 References: <41FF46CB.1040405@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3 X-From: pwe3-bounces@ietf.org Tue Feb 01 18:44:14 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Stewart Bryant In-Reply-To: <41FF46CB.1040405@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org I can only find the -00 rev of this draft. http://www.ietf.org/internet-drafts/draft-yudong-pwe3-control-protocol-ext-00.txt Is there a rev -01? Thanks ... At 09:07 AM 2/1/2005 +0000, Stewart Bryant wrote: >The following draft was recently posted: > >Multi-Hop Pseudo-Wires Signalling Using LDP >draft-yudong-pwe3-control-protocol-ext-01.txt > >Stewart > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt Date: Wed, 2 Feb 2005 18:36:45 -0000 Lines: 258 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Feb 02 19:45:34 2005 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt Thread-Index: AcUIgThlAKFMCfYgTf6pvXv+Om1EwQALJHfw To: X-OriginalArrivalTime: 02 Feb 2005 18:36:45.0749 (UTC) FILETIME=[25E46650:01C50956] X-Spam-Score: 0.3 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Dave....Thanks for the response. But I'm not really sure where this is heading as I believe there is a fundamental mismatch of views/understanding of what network architecture is and why it is important. =20 > > 1 In any client/server relationship (and PWs are for sure this) > > one wants the management of the server to be independent of the > > client.....so that we can use the same (server) processing in all=20 > > cases. Note functional re-use/simplification is a key goal to reduce > > complexity and opex (noting this plays through from NE to NMS/OSS=20 > > efficacy). >=20 > As mentioned before, an Annex translating G.805 terminology to=20 > relevant IETF terminology would be helpful. Approved documents=20 > communicate a message better than Email archives. My translation of=20 > the above is: MH PW management should be independent of PSN tunnel=20 > management. NH=3D> Close in terms of what is required but sadly not possible. You = see MPLS is a digital wrapper. When we create a hierachy in MPLS all the stacked LSPs belong to the same layer network. I have explained why this is true before and why its a serious problem (MH PWs are simply exposing it....trying to do client/server between operators will also expose it). I can't translate G.805 to IETF arch because there isn't one.....not that I think the effort would bring any benefit anyway (wheel-reinvention).=20 >=20 > >=20 > > 2 In any client/server relationship the most basic requirement of > > all is client (all planes) transparency over the server....or > > putting it another way, complete functional decoupling of the client > > and the server layer networks (this is NOT a specific OAM issue of=20 > > course, its the most basic yet most important network arch=20 > > requirement per se, but it does impact OAM). >=20 > I need some help translating this one. NH=3D> OK....but its rather obvious, so please excuse me if it sounds = like I am teaching egg-sucking. Suppose I want to build some layer network...let's say an IP layer network though the choice of layer network is incidental. So I buy a load of routers say. I'm going to lease capacity of a several operators to connect these routers together. I don't really care what technology each of them uses just so long as it gives me the required BW, has reasonable delay/loss/errors and does not fail very often (be nice to have SLAs, but that needs OAM, consistent metrics, etc and I note you feel this is not important later). I have no interest in sharing any of my addressing, routing, whatever with any of these operators.....in fact its a strong commercial/operating requirement that I don't (and I can change suppliers at will this way). Each link-connection (ie the thing that connects adjacent nodes in my network) is provided by a trail (ie an end-end path) from some operator in some technology....could be FR on one link, ATM on another, SDH on another, PDH on another....can't be MPLS *directly* of course as MPLS does not do a network builder service per se because its a digital wrapper (though it carries others, ie I could get a 'ATM server trail over a PW' say...as this terminates the wrapper behaviour). This is the essence of G.805, ie client/server functional decoupling....its also the essence of the phrase 'IP over everything'. Indeed this phrase is *ONLY* true because we adopt a G.805 attitude to client/server relationships and don't going screwing around with the IP layer client. So my network has absolutely no functional relationship with any of the operator's networks from whom I lease capacity. This is the fundamantal essense of a network builder service and it is (and will always be) a key service capability requirement for all major operators....I suspect if you talk to your products guys they might have a similar view on this too. Hope that is clear now. >=20 > >=20 > > 4 There are 2 major types of OAM: (i) 'always on' defect > > detection/handling and (ii) 'on-demand' diagnostics, PM. The former > > must be sorted before we can sensibly consider the latter, and the=20 > > former must be simple/complete.....noting that the requirements to=20 > > be met are NOT identical for each network mode. > >=20 > > 3 The defects that can affect each of the 3 network modes are > > different. If we are dealing with MPLS as the server there should > > be breaks, swaps and mismerging defects specified in terms of clear=20 > > entry/exit criteria and consequent actions....see next item. > >=20 > > 4 Defect detection/handling needs to be in the traffic data-plane > > and unidirectional. In particular, consequent actions need to be > > taken at the trail sink. This is vital so that p2p and p2mp=20 > > constructs can be handled similarly/scalably. 2 key consequent=20 > > actions (if the client is > > co) are (i) traffic suppression and (ii) FDI insertion to > > stop alarm storms. The precise syntax of FDI depends on the=20 > > client technology. > >=20 > > 5 The activation/deactivation of the defect detection/handling > > aspects of OAM must be done in concert with however the trail is > > set-up/taken-down (this can be via signalling or management). > >=20 > > 6 Before we can progress to PM we must have a clear definition of > > the available state...as PM measurements (at least for any SLA > > purposes) are only valid when the trail is in the > available state. > >=20 > > Note - Defects, availability and PM need to be standardised in order > > to have a common basis of specification for interworking and=20 > > apportionment (of impairments) to tandemed operator domains. > >=20 >=20 > Is there anything incorrect or missing from section 6.6 of > draft-martini-pwe3-MH-PW-requirements-00.txt? NH=3D> I must say Luca (and Nabil) have done a pretty good job in capturing many of the requirements. Where it all starts to fall apart a bit however is when we get down to hard specifications and look at the base arch of the technology we are dealing with. Let's take the latter point 1st: - Some spins of MPLS don't have any good OAM solutions at all, ie LDP mp2p and PHP....these create a merging behaviour for which it is simply not possible to specify any meaningful defect conditions/actions. So I have to put these aside in a 'special' category; - Then we have some missing functional components. For example an OOB control/management plane ought to be an almost no-brainer requirement in a carrier grade network for several reasons (its forced in GMPLS, but that is property of the co-cs mode and its nmot a conscious design decision). This creates some important relationships between the control-plane protocols and the traffic data-plane that have to be dealt with. Further, we don't have any consistent way of addressing LSPs. I'll come back on this shortly in the context of BFD and the CV pkt of Y.1711. - Then we have the OAM indicate function. The OAM pkts should look just like traffic pkts between trail source and sink points and the OAM should be the same no matter what the client is.....this is required so that we can get as close as possible to monitoring what is happening to the traffic, and we can use exactly the same processing in all cases. This should have required 1 bit of the header (8 bits for TTL in a co-ps technology that should not even need this is a bit wasted IMO). Instead we have to resort to kludges like adding an extra reserved label, or using the CW or router alert in the case of PW clients. =20 - Finally we have the wrapper and its related issue of 'topology on the fly'. I have explained this in detail in past posts. I actually think this is the biggest problem with MPLS as this cannot be fixed....whereas the others could with the right will. Now let's look at some of the hard specification requirements. If we want to interoperate we ought to start with a basis of agreed defect entry/exit criteria and consequent actions. OK, we know we have to dump LDP mp2p and PHP at this point as these create a merging behaviour that cannot be specified in any meaningful manner. So assuming we can only have p2p and p2mp constructions let's look at their defects. Breaks, swaps, misbranching/mismerging. If we are going detect these in a consistent manner we need the same OAM on all LSPs. Not only that however, we need the same SA (Source Address) used in the CV function. This is required in Y.1711. Let me now contrast that with BFD. This uses a locally generated dicriminator field that looks a lot like a SA CV function. But as far as I understand it BFD only looks for 'expected' discrimiator fields and ignores any 'unexpected' ones...so it can't detect swaps or misbranching/mismerging. I also do not believe any FDI is specified in BFD nor is there a requirement for traffic suppression if dealing with any co mode clients. Further, being a local code the disciminator would not have immediate network relevance, ie is it obvious where an offending traffic stream was sourced from? Being a bi-directional protocol its not clear how BFD would easily adapt/scale to p2mp constructions either. >=20 > > 7 If either direction of a bi-directional trail enters the > > unavailable state any PM measurements should be stopped for both=20 > > directions. > >=20 > > 8 It should be possible to observe the defect/availability status > > of both directions from a single end. > >=20 > > Note that Y.1711 was designed to meet the above requirements wrt=20 > > basic defect detection/handling in the most simple way possible IMO. > > The above are not rocket-science nor are they unreasonable IMO....in > > fact I think they are rather simple and obvious requirements. Can=20 > > you assure me that all these requirements can be met with some=20 > > alternative OAM proposals? >=20 > draft-ietf-pwe3-oam-msg-map-01.txt does not specify Y.1711 but=20 > specifies LSP Ping instead. NH=3D> Think it rather majors on BFD. BFD is a Y.1711 lookalike (has = to, functional requirements are the same) for the simple 'always on' OAM bit....LSP-Ping however is a 'on demand' diagnostic tool IMO. So I think you are making the wrong comparison here. > IMO, Y.1711 does not provide a means to communication > detection of defects and associate them with the control=20 > protocol signaled > PW or PSN tunnel. NH=3D> Quite right....nor should it, as the OAM needs to be the same whether signalling protocol X, Y or Z or NMS set up the trail. The OAM should be the same in all cases, and it primary task it take executive action in the data-plane. Of course one can then inform the control-plane of this to effect prot-sw say. So not sure what your point is.=20 > =20 > >=20 > > Maybe Dave doesn't care about some/any of this in his=20 > > network....maybe others don't either, and I must admit I have=20 > > been rather disappointed with the inputs (mainly lack of)=20 > > that I have seen other operators on the topic of OAM in=20 > > general in this forum. =20 >=20 > To me it is a matter of practicality and priority.=20 > Coordinating control, > data and management is important in many services, and I do=20 > not believe that > approaching them independently is a good architectural=20 > approach. Control > protocols have detected a majority of faults in packet networks > (connectionless and connection-oriented) for decades. Additional OAM > protocols could detect some additional faults that control=20 > protocols do not. > In my experience with packet networks these OAM protocols would have > detected faults that the control protocol and would have reduced > unavailability on the order of 10^-6, if they were available. NH=3D> Hmm...seems not to tie up what what Tom say in earlier mail = across a sample of operators. Misconfiguration problems can be human, HW or SW in origin. But if what you say is true however, then what do we need BFD for either? And why is there all the efforts we see on OAM, not just here but also in other technologies, eg ethernet? Is your advice to all these folks 'pack-up as you are all wasting your time'? =20 >=20 > > This does seem to be a persistent=20 > > malaise of the operator community that they only seem to=20 > > get-wise about stuff like OAM 'after the event'...when its=20 > > usually too late to do much about it. OAM considerations=20 > > should not be some afterthought, they should be designed-in=20 > > to the architecture from t=3D0. >=20 > The approach I prefer is to first (t=3D0) agree on the=20 > requirements of what is > to be done and then decide on the appropriate management=20 > approach at t>0. NH=3D> But your requirements would seem to exclude OAM at the = outset...as you seem to think it is of little value. This means it would never be designed in from t=3D0. It was this type of argument we heard in a BOF = on MPLS OAM a few years OK, ie you simply don't need it. Seems experience of real networks has changed this view for many. But thank goodness we never followed this line of reasoning when SDH was defined....a big lesson learnt from PDH was make sure you design OAM right from the start. And its amazing how many folks now rely so heavily on the fact we did this. Indeed, one of the reasons SDH worked so well 'out of the box' is that the OAM that was built into it allowed a great deal of vendor debugging *BEFORE* we deployed it. regards, neil=20 >=20 > >=20 > > regards, Neil > >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: David McDysan Subject: RE: Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt Date: Wed, 02 Feb 2005 14:56:54 -0500 Lines: 281 References: <0536FC9B908BEC4597EE721BE6A353890A9F185E@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Feb 02 21:03:16 2005 In-reply-to: <0536FC9B908BEC4597EE721BE6A353890A9F185E@i2km07-ukbr.domain1.systemhost.net> To: neil.2.harrison@bt.com X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Neil, Thanks for taking the time to translate terminology and respond. It appears that you want to discuss architecture and not specific MH-PW requirements. In the context of MH-PW requirments, G.805 codifies = SDH/SONET and ATM experience - but I question whether this is the right approach = for IP-based networks. When interworking with TDM and ATM networks as in PW, then I agree that G.805 principles are applicable for at least PW = endpoints. I hope that we can work toward supporting an architecture that uses an IP-based set of control and management protocols as well as the G.805 architectural basis that you propose. In the past, I believe that = "manual" provisioning or configuration has been used to support the existence of = more than one architecture and operational model in vendor implementations = and operator networks. Possibly this is a way forward? A few responses in line below with respect to MH-PW requirements. Regards, Dave > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Wednesday, February 02, 2005 1:37 PM > To: dave.mcdysan@MCI.COM > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Re: I-D=20 > ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt >=20 >=20 > Dave....Thanks for the response. But I'm not really sure=20 > where this is heading as I believe there is a fundamental=20 > mismatch of views/understanding of what network architecture=20 > is and why it is important. =20 > > > >=20 > > > 4 There are 2 major types of OAM: (i) 'always on' defect > > > detection/handling and (ii) 'on-demand' diagnostics, PM. =20 > The former=20 > > > must be sorted before we can sensibly consider the=20 > latter, and the=20 > > > former must be simple/complete.....noting that the=20 > requirements to=20 > > > be met are NOT identical for each network mode. > > >=20 > > > 3 The defects that can affect each of the 3 network modes are > > > different. If we are dealing with MPLS as the server=20 > there should=20 > > > be breaks, swaps and mismerging defects specified in=20 > terms of clear=20 > > > entry/exit criteria and consequent actions....see next item. > > >=20 > > > 4 Defect detection/handling needs to be in the traffic data-plane > > > and unidirectional. In particular, consequent actions need to be=20 > > > taken at the trail sink. This is vital so that p2p and p2mp=20 > > > constructs can be handled similarly/scalably. 2 key consequent=20 > > > actions (if the client is > > > co) are (i) traffic suppression and (ii) FDI insertion to=20 > stop alarm=20 > > > storms. The precise syntax of FDI depends on the client=20 > technology. > > >=20 > > > 5 The activation/deactivation of the defect detection/handling > > > aspects of OAM must be done in concert with however the trail is=20 > > > set-up/taken-down (this can be via signalling or management). > > >=20 > > > 6 Before we can progress to PM we must have a clear definition of > > > the available state...as PM measurements (at least for any SLA > > > purposes) are only valid when the trail is in the > > available state. > > >=20 > > > Note - Defects, availability and PM need to be=20 > standardised in order=20 > > > to have a common basis of specification for interworking and=20 > > > apportionment (of impairments) to tandemed operator domains. > > >=20 > >=20 > > Is there anything incorrect or missing from section 6.6 of=20 > > draft-martini-pwe3-MH-PW-requirements-00.txt? > NH=3D> I must say Luca (and Nabil) have done a pretty good job=20 > in capturing many of the requirements. Where it all starts=20 > to fall apart a bit however is when we get down to hard=20 > specifications and look at the base arch of the technology we=20 > are dealing with. Let's take the latter point 1st: >=20 > Now let's look at some of the hard specification=20 > requirements. If we want to interoperate we ought to start=20 > with a basis of agreed defect entry/exit criteria and=20 > consequent actions. OK, we know we have to dump LDP mp2p and=20 > PHP at this point as these create a merging behaviour that=20 > cannot be specified in any meaningful manner. So assuming we=20 > can only have p2p and p2mp constructions let's look at their=20 > defects. Breaks, swaps, misbranching/mismerging. If we are=20 > going detect these in a consistent manner we need the same=20 > OAM on all LSPs. Not only that however, we need the same SA=20 > (Source Address) used in the CV function. This is required in=20 > Y.1711. Let me now contrast that with BFD. This uses a=20 > locally generated dicriminator field that looks a lot like a=20 > SA CV function. But as far as I understand it BFD only looks=20 > for 'expected' discrimiator fields and ignores any=20 > 'unexpected' ones...so it can't detect swaps or=20 > misbranching/mismerging. I also do not believe any FDI is=20 > specified in BFD nor is there a requirement for traffic=20 > suppression if dealing with any co mode clients. Further,=20 > being a local code the disciminator would not have immediate=20 > network relevance, ie is it obvious where an offending=20 > traffic stream was sourced from? Being a bi-directional=20 > protocol its not clear how BFD would easily adapt/scale to=20 > p2mp constructions either. Seems like the following are missing from section 6.6 for MH-PW - detect (unintended) PW label swaps - detect PW label merging (should not occur for pt-pt) These "defects" could be due to implementation errors, but I agree that = it would be desirable to detect them. >=20 > >=20 > > > 7 If either direction of a bi-directional trail enters the > > > unavailable state any PM measurements should be stopped for both > > > directions. > > >=20 > > > 8 It should be possible to observe the defect/availability status > > > of both directions from a single end. > > >=20 > > > Note that Y.1711 was designed to meet the above requirements wrt > > > basic defect detection/handling in the most simple way=20 > possible IMO. >=20 > > > The above are not rocket-science nor are they=20 > unreasonable IMO....in >=20 > > > fact I think they are rather simple and obvious requirements. Can > > > you assure me that all these requirements can be met with some=20 > > > alternative OAM proposals? > >=20 > > draft-ietf-pwe3-oam-msg-map-01.txt does not specify Y.1711 but > > specifies LSP Ping instead. > NH=3D> Think it rather majors on BFD. BFD is a Y.1711=20 > lookalike (has to, functional requirements are the same) for=20 > the simple 'always on' OAM bit....LSP-Ping however is a 'on=20 > demand' diagnostic tool IMO. So I think you are making the=20 > wrong comparison here. >=20 Yes, looked at the referenced draft again and it does focus on bfd for always on OAM. > > IMO, Y.1711 does not provide a means to communication detection of=20 > > defects and associate them with the control protocol signaled > > PW or PSN tunnel. > NH=3D> Quite right....nor should it, as the OAM needs to be the=20 > same whether signalling protocol X, Y or Z or NMS set up the=20 > trail. =20 As stated above, I hope this is something upon which we can agree. I = will be focusing on X=3DIP-based control protocols. > The OAM should be the same in all cases, and it=20 > primary task it take executive action in the data-plane. =20 Not sure what is meant by "executive action in the data-plane" in the = above. > Of=20 > course one can then inform the control-plane of this to=20 > effect prot-sw say. So not sure what your point is.=20 I believe this is a fundamental gap in the G.805 based approach for = networks that have a control protocol. The determination of the set of link connections that make up a network connection is not specified in G.805, = and my experience is that IP-like control protocols fill this architectural void. IMO, being able to correlate the OAM state with the desired state communicated via a control protocol is an essential requirement. > > =20 > > >=20 > > > Maybe Dave doesn't care about some/any of this in his > > > network....maybe others don't either, and I must admit I have=20 > > > been rather disappointed with the inputs (mainly lack of)=20 > > > that I have seen other operators on the topic of OAM in=20 > > > general in this forum. =20 > >=20 > > To me it is a matter of practicality and priority. > > Coordinating control, > > data and management is important in many services, and I do=20 > > not believe that > > approaching them independently is a good architectural=20 > > approach. Control > > protocols have detected a majority of faults in packet networks > > (connectionless and connection-oriented) for decades. Additional OAM > > protocols could detect some additional faults that control=20 > > protocols do not. > > In my experience with packet networks these OAM protocols would have > > detected faults that the control protocol and would have reduced > > unavailability on the order of 10^-6, if they were available. > NH=3D> Hmm...seems not to tie up what what Tom say in earlier=20 > mail across a sample of operators. =20 Consider this another input to that sample. > Misconfiguration problems=20 > can be human, HW or SW in origin. But if what you say is=20 > true however, then what do we need BFD for either? =20 See section 2.1 of draft-raggarwa-mpls-bfd-00.txt (could not find = updated version). Looks like bfd wg has no current active drafts. > And why=20 > is there all the efforts we see on OAM, not just here but=20 > also in other technologies, eg ethernet? Is your advice to=20 > all these folks 'pack-up as you are all wasting your time'? > =20 No, my point was that control protocols detect many defects. The events where it did not were quite painful (even if they did not contribute = greatly to unavailability). Getting the control and provisioning part correct = though is a prerequisite to minimizing the effects of manual configuration = errors and handling the most likely failure modes.=20 > >=20 > > > This does seem to be a persistent > > > malaise of the operator community that they only seem to=20 > > > get-wise about stuff like OAM 'after the event'...when its=20 > > > usually too late to do much about it. OAM considerations=20 > > > should not be some afterthought, they should be designed-in=20 > > > to the architecture from t=3D0. > >=20 > > The approach I prefer is to first (t=3D0) agree on the > > requirements of what is > > to be done and then decide on the appropriate management=20 > > approach at t>0. > NH=3D> But your requirements would seem to exclude OAM at the=20 > outset...as you seem to think it is of little value. This=20 > means it would never be designed in from t=3D0. It was this=20 > type of argument we heard in a BOF on MPLS OAM a few years=20 > OK, ie you simply don't need it. Seems experience of real=20 > networks has changed this view for many. But thank goodness=20 > we never followed this line of reasoning when SDH was=20 > defined....a big lesson learnt from PDH was make sure you=20 > design OAM right from the start. And its amazing how many=20 > folks now rely so heavily on the fact we did this. Indeed,=20 > one of the reasons SDH worked so well 'out of the box' is=20 > that the OAM that was built into it allowed a great deal of=20 > vendor debugging *BEFORE* we deployed it. >=20 Well, we are advancing both simultaneously in the MH-PW requirements = draft.=20 > regards, neil=20 > >=20 > > >=20 > > > regards, Neil > > >=20 > >=20 > >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt Date: Thu, 3 Feb 2005 08:49:48 -0000 Lines: 404 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 03 09:55:06 2005 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt Thread-Index: AcUJYZkVOn9O8rcARS6OR9Cxjh/IbAAYTpmg To: X-OriginalArrivalTime: 03 Feb 2005 08:49:49.0314 (UTC) FILETIME=[51AC9E20:01C509CD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Dave.... > It appears that you want to discuss architecture and not=20 > specific MH-PW requirements. NH=3D> You can't do one without the other IMO.....when you do you often get it wrong is my experience. Is not the current situation not evidence enough there is something quite awry here? Ever thought 'why' this is? > In the context of MH-PW=20 > requirments, G.805 codifies SDH/SONET and ATM experience - NH=3D> Not at all....this statement suggests that you do not understand what functional architecture is about or (more importantly) what its for. You may like to know that one of my colleagues has just completed the functional arch modelling of MPLS in SG15.....just what it says on the RFC tin. We have already done ethernet and folks are using it. =20 > but I question whether this is the right approach for=20 > IP-based networks. NH=3D> You right, G.805 is not appropriate....that's why G.809 exists to model the cl-ps mode. > When interworking with TDM and ATM=20 > networks as in PW, then I agree that G.805 principles are=20 > applicable for at least PW endpoints. NH=3D> The whole purpose of G.805/G.809 is to have a consistent/rigorous way to define layer networks. They only come in 3 basic modes and this stuff covers them all at an abstract level...specific standards are then produced per technology (and this shows up any weaknesses) and this is a key precursor to sound equipment standards and management information models. If you want good networking standards, sound equipment Recs and (most importantly of all) proper management information models you need this stuff. >=20 >=20 > I hope that we can work toward supporting an architecture=20 > that uses an IP-based set of control and management protocols=20 > as well as the G.805 architectural basis that you propose. NH=3D> Yes we can. But I am not sure here is the right place based on experience to date. > In=20 > the past, I believe that "manual" provisioning or=20 > configuration has been used to support the existence of more=20 > than one architecture and operational model in vendor=20 > implementations and operator networks. Possibly this is a way forward? NH=3D> Dave, its nothing to do with 'manual provisioning'. When we defined SDH way back we wanted to develop a control-plane for it even then (I am talking ~12+ years ago)......so the GMPLS idea is very old-hat to us. However, there was no strong commercial driver for this (and there still isn't if folks are honest).....its useful, (esp for operators who never developed strong NMS-based systems, and with an S-PVC approach it saves developing a prot-sw solution in the management plane in addition to a more UNI-based/SVC approach), but when you look at the call/holding considerations, what this would mean in terms of dimensioning (GoS), and (especially) how the 3 modes relate (which, if you understand it, tells you there are some problems about the notion of functionally crunching 'from IP to Optics') you realise its not such a big deal. We have a very good understanding of the relationships between all of the 3 traffic/control/management planes in all 3 networking modes and I'd like to think we know what we are talking about. >=20 > A few responses in line below with respect to MH-PW requirements. >=20 > Regards, >=20 > Dave >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Wednesday, February 02, 2005 1:37 PM > > To: dave.mcdysan@MCI.COM > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] Re: I-D=20 > > ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt > >=20 > >=20 > > Dave....Thanks for the response. But I'm not really sure > > where this is heading as I believe there is a fundamental=20 > > mismatch of views/understanding of what network architecture=20 > > is and why it is important. =20 > > >=20 > >=20 > > > >=20 > > > > 4 There are 2 major types of OAM: (i) 'always on' defect > > > > detection/handling and (ii) 'on-demand' diagnostics, PM. > > The former > > > > must be sorted before we can sensibly consider the > > latter, and the > > > > former must be simple/complete.....noting that the > > requirements to > > > > be met are NOT identical for each network mode. > > > >=20 > > > > 3 The defects that can affect each of the 3=20 > network modes are > > > > different. If we are dealing with MPLS as the server > > there should > > > > be breaks, swaps and mismerging defects specified in > > terms of clear > > > > entry/exit criteria and consequent actions....see next item. > > > >=20 > > > > 4 Defect detection/handling needs to be in the=20 > traffic data-plane > > > > and unidirectional. In particular, consequent actions=20 > need to be > > > > taken at the trail sink. This is vital so that p2p and p2mp=20 > > > > constructs can be handled similarly/scalably. 2 key consequent=20 > > > > actions (if the client is > > > > co) are (i) traffic suppression and (ii) FDI insertion to=20 > > stop alarm > > > > storms. The precise syntax of FDI depends on the client > > technology. > > > >=20 > > > > 5 The activation/deactivation of the defect=20 > detection/handling > > > > aspects of OAM must be done in concert with however the trail is > > > > set-up/taken-down (this can be via signalling or management). > > > >=20 > > > > 6 Before we can progress to PM we must have a=20 > clear definition of > > > > the available state...as PM measurements (at least for any SLA > > > > purposes) are only valid when the trail is in the > > > available state. > > > >=20 > > > > Note - Defects, availability and PM need to be > > standardised in order > > > > to have a common basis of specification for interworking and > > > > apportionment (of impairments) to tandemed operator domains. > > > >=20 > > >=20 > > > Is there anything incorrect or missing from section 6.6 of > > > draft-martini-pwe3-MH-PW-requirements-00.txt? > > NH=3D> I must say Luca (and Nabil) have done a pretty good job > > in capturing many of the requirements. Where it all starts=20 > > to fall apart a bit however is when we get down to hard=20 > > specifications and look at the base arch of the technology we=20 > > are dealing with. Let's take the latter point 1st: >=20 > > >=20 > > Now let's look at some of the hard specification > > requirements. If we want to interoperate we ought to start=20 > > with a basis of agreed defect entry/exit criteria and=20 > > consequent actions. OK, we know we have to dump LDP mp2p and=20 > > PHP at this point as these create a merging behaviour that=20 > > cannot be specified in any meaningful manner. So assuming we=20 > > can only have p2p and p2mp constructions let's look at their=20 > > defects. Breaks, swaps, misbranching/mismerging. If we are=20 > > going detect these in a consistent manner we need the same=20 > > OAM on all LSPs. Not only that however, we need the same SA=20 > > (Source Address) used in the CV function. This is required in=20 > > Y.1711. Let me now contrast that with BFD. This uses a=20 > > locally generated dicriminator field that looks a lot like a=20 > > SA CV function. But as far as I understand it BFD only looks=20 > > for 'expected' discrimiator fields and ignores any=20 > > 'unexpected' ones...so it can't detect swaps or=20 > > misbranching/mismerging. I also do not believe any FDI is=20 > > specified in BFD nor is there a requirement for traffic=20 > > suppression if dealing with any co mode clients. Further,=20 > > being a local code the disciminator would not have immediate=20 > > network relevance, ie is it obvious where an offending=20 > > traffic stream was sourced from? Being a bi-directional=20 > > protocol its not clear how BFD would easily adapt/scale to=20 > > p2mp constructions either. >=20 > Seems like the following are missing from section 6.6 for MH-PW > - detect (unintended) PW label swaps > - detect PW label merging (should not occur for pt-pt) >=20 > These "defects" could be due to implementation errors, but I=20 > agree that it would be desirable to detect them. NH=3D> We should make the basic 'always on' OAM stuff very simple and complete.....if you don't do it from the outset it won't get done later (too costly to re-engineer). Its not hard/difficult if you think it through. And I have been very disappointed at the tactics I have seen used in the past by some folks to slur what is in Y.1711. >=20 > >=20 > > >=20 > > > > 7 If either direction of a bi-directional trail enters the > > > > unavailable state any PM measurements should be stopped=20 > for both=20 > > > > directions. > > > >=20 > > > > 8 It should be possible to observe the=20 > defect/availability status > > > > of both directions from a single end. > > > >=20 > > > > Note that Y.1711 was designed to meet the above=20 > requirements wrt=20 > > > > basic defect detection/handling in the most simple way > > possible IMO. > >=20 > > > > The above are not rocket-science nor are they > > unreasonable IMO....in > >=20 > > > > fact I think they are rather simple and obvious=20 > requirements. Can=20 > > > > you assure me that all these requirements can be met with some=20 > > > > alternative OAM proposals? > > >=20 > > > draft-ietf-pwe3-oam-msg-map-01.txt does not specify Y.1711 but=20 > > > specifies LSP Ping instead. > > NH=3D> Think it rather majors on BFD. BFD is a Y.1711 > > lookalike (has to, functional requirements are the same) for=20 > > the simple 'always on' OAM bit....LSP-Ping however is a 'on=20 > > demand' diagnostic tool IMO. So I think you are making the=20 > > wrong comparison here. > >=20 >=20 > Yes, looked at the referenced draft again and it does focus on bfd for > always on OAM. >=20 > > > IMO, Y.1711 does not provide a means to communication=20 > detection of=20 > > > defects and associate them with the control protocol signaled > > > PW or PSN tunnel. > > NH=3D> Quite right....nor should it, as the OAM needs to be the=20 > > same whether signalling protocol X, Y or Z or NMS set up the=20 > > trail. =20 >=20 > As stated above, I hope this is something upon which we can=20 > agree. I will be > focusing on X=3DIP-based control protocols. NH=3D> You shouldn't. You need to focus on all 3 modes if you are a full-service operator. They are all important in different ways.....in fact its the differences that are the key bits. You simply cannot do everything you need in a single mode. The key issues are: - coming to terms with understanding the fundamental economic problems of networking.....this is nothing to do with technology directly (though the arch will either enable or disable your ability to address it), its simply an understanding that: o build/run costs of network are massive and almost invariant of load, ie marginal usage costs are tiny. o core networks are not the dominant cost/technical driver....access is o the only successful networks (not just telecoms) must have a pricing regime that is based on the value of the goods carried and not the resource used.....and if you are smart, you will then quickly figure out that chasing QoS is the wrong goal - applications only come in message, file or stream spins....this should also tell you you don't need lots of QoS/traffic classes - the arch must correctly address both public and private services (and must, as a min, be able to do network builder services in the private services space) I could say lots more on this topic...and have in the past, esp how this translates to modal arch requirements...so I'll stop here wrt the above issues. =20 >=20 > > The OAM should be the same in all cases, and it=20 > > primary task it take executive action in the data-plane. =20 >=20 > Not sure what is meant by "executive action in the=20 > data-plane" in the above. NH=3D> In essence, I mean the decision/action is a distributed function that is executed at trail sink points. >=20 > > Of=20 > > course one can then inform the control-plane of this to=20 > > effect prot-sw say. So not sure what your point is.=20 >=20 > I believe this is a fundamental gap in the G.805 based=20 > approach for networks > that have a control protocol. NH=3D> Then you have not understood the purpose of G.805. G.805 does = not deal with the control-plane arch (or indeed the management plane arch/perspective).....the control-plane arch is addressed in the ASON stuff. I would suggest a read of chapters 3 and 4 of BB networking by Reid/Sexton. This is by far the best explanation of these topics I know of. =20 > The determination of the set of link > connections that make up a network connection is not=20 > specified in G.805, and > my experience is that IP-like control protocols fill this=20 > architectural > void. NH=3D> You are specifically talking of a routing function here. I do = not dispute the fact we need this component (all WAN scalable modes do). However, its execution is quite different in the 3 modes and you simply cannot (despite what I have heard claimed in the past) run a single instance of routing from IP to Optics. There are many reasons why this is a flawed idea (both technical and commercial). > IMO, being able to correlate the OAM state with the=20 > desired state > communicated via a control protocol is an essential requirement. NH=3D> In the cl-ps mode you have no choice....a routing function is all that is at your disposal and one does not have the trail entity. So I can fully understand the mind-set of folks coming at the networking space from an IP-only background. Its not like this (ie so restricted) in the co-ps and co-cs modes. In fact as you approach the duct 'routing' becomes a far less important component than say data-plane OAM, ie the trail holding times must increase as one approaches the duct and simple routing solutions are perfectly fine.....but there is an increasing speed/accuracy requirement on the ability of OAM to react to failures and take executive action (inc prot-sw). And then there is the issue of OOB control/management here.....very different issues indeed. >=20 > > > =20 > > > >=20 > > > > Maybe Dave doesn't care about some/any of this in his > > > > network....maybe others don't either, and I must admit I have=20 > > > > been rather disappointed with the inputs (mainly lack of)=20 > > > > that I have seen other operators on the topic of OAM in=20 > > > > general in this forum. =20 > > >=20 > > > To me it is a matter of practicality and priority. > > > Coordinating control, > > > data and management is important in many services, and I do=20 > > > not believe that > > > approaching them independently is a good architectural=20 > > > approach. Control > > > protocols have detected a majority of faults in packet networks > > > (connectionless and connection-oriented) for decades.=20 > Additional OAM > > > protocols could detect some additional faults that control=20 > > > protocols do not. > > > In my experience with packet networks these OAM protocols=20 > would have > > > detected faults that the control protocol and would have reduced > > > unavailability on the order of 10^-6, if they were available. > > NH=3D> Hmm...seems not to tie up what what Tom say in earlier=20 > > mail across a sample of operators. =20 >=20 > Consider this another input to that sample. >=20 > > Misconfiguration problems=20 > > can be human, HW or SW in origin. But if what you say is=20 > > true however, then what do we need BFD for either? =20 >=20 > See section 2.1 of draft-raggarwa-mpls-bfd-00.txt (could not=20 > find updated > version). Looks like bfd wg has no current active drafts. >=20 > > And why=20 > > is there all the efforts we see on OAM, not just here but=20 > > also in other technologies, eg ethernet? Is your advice to=20 > > all these folks 'pack-up as you are all wasting your time'? > > =20 >=20 > No, my point was that control protocols detect many defects.=20 NH=3D> I don't dispute this may be the case...esp in the cl-ps mode. = But look at the co-cs mode, the routing protocol and signalling protocol is running in a disjoint network (at least logical if not physical) to the traffic...so this is plainly not true here. I'm going drop-out of this dialogue here....thanks. regards, Neil > The events > where it did not were quite painful (even if they did not=20 > contribute greatly > to unavailability). Getting the control and provisioning part=20 > correct though > is a prerequisite to minimizing the effects of manual=20 > configuration errors > and handling the most likely failure modes.=20 >=20 > > >=20 > > > > This does seem to be a persistent > > > > malaise of the operator community that they only seem to=20 > > > > get-wise about stuff like OAM 'after the event'...when its=20 > > > > usually too late to do much about it. OAM considerations=20 > > > > should not be some afterthought, they should be designed-in=20 > > > > to the architecture from t=3D0. > > >=20 > > > The approach I prefer is to first (t=3D0) agree on the > > > requirements of what is > > > to be done and then decide on the appropriate management=20 > > > approach at t>0. > > NH=3D> But your requirements would seem to exclude OAM at the=20 > > outset...as you seem to think it is of little value. This=20 > > means it would never be designed in from t=3D0. It was this=20 > > type of argument we heard in a BOF on MPLS OAM a few years=20 > > OK, ie you simply don't need it. Seems experience of real=20 > > networks has changed this view for many. But thank goodness=20 > > we never followed this line of reasoning when SDH was=20 > > defined....a big lesson learnt from PDH was make sure you=20 > > design OAM right from the start. And its amazing how many=20 > > folks now rely so heavily on the fact we did this. Indeed,=20 > > one of the reasons SDH worked so well 'out of the box' is=20 > > that the OAM that was built into it allowed a great deal of=20 > > vendor debugging *BEFORE* we deployed it. > >=20 >=20 > Well, we are advancing both simultaneously in the MH-PW=20 > requirements draft.=20 >=20 > > regards, neil=20 > > >=20 > > > >=20 > > > > regards, Neil > > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: Axerra IPR statements Date: Thu, 03 Feb 2005 09:58:05 +0000 Lines: 19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Thu Feb 03 11:07:10 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: pwe3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org FYI The following IPR stements have been filed by Axerra Networks re drafts submitted to the PWE3 WG. draft-ietf-pwe3-atm-encap-07.txt https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=525 The disclosure does not seem to point directly to a patent, but it looks like a reference to USP 6,728,261 draft-ietf-pwe3-frame-relay-03.txt https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=526 This points to USP 6,798,785 draft-ietf-pwe3-cesopsn-02.txt https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=527 Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-tdm-mib-02.txt Date: Thu, 03 Feb 2005 15:57:29 -0500 Lines: 139 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 03 23:06:02 2005 To: i-d-announce@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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire 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-02.txt Pages : 37 Date : 2005-2-3 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-02.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-02.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-02.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/mixed; boundary="OtherAccess" --OtherAccess Content-Type: text/plain; charset="ISO-8859-1"; name="Gmane-Attachment-Warning.txt" Content-Disposition: attachment; filename="Gmane-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Thu Feb 3 23:06:02 2005 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/= quarantine/20050203 (message 1Cwp6q-0003IG-QV). --=20 Postmaster Gmane gmane.org MailScanner thanks transtec Computers for their support --OtherAccess Content-Type: text/plain; charset="ISO-8859-1"; name="Gmane-Attachment-Warning.txt" Content-Disposition: attachment; filename="Gmane-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Thu Feb 3 23:06:02 2005 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/= quarantine/20050203 (message 1Cwp6q-0003IG-QV). --=20 Postmaster Gmane gmane.org MailScanner thanks transtec Computers for their support --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 Wed Dec 27 15:58:27 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-vccv-04.txt Date: Thu, 03 Feb 2005 15:57:39 -0500 Lines: 142 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Feb 03 23:08:54 2005 To: i-d-announce@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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) Author(s) : T. Nadeau, R. Aggarwal Filename : draft-ietf-pwe3-vccv-04.txt Pages : 16 Date : 2005-2-3 This document describes Virtual Circuit Connection Verification (VCCV) procedures for use with psuedowire connections. VCCV supports connection verification applications for pseudowire VCs regardless of the underlying MPLS or IP tunnel technology. VCCV makes use of IP based protocols such as Ping and MPLS-Ping to perform operations and maintenance functions. A network operator may use the VCCV procedures to test the network's forwarding plane liveliness. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-04.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-vccv-04.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-vccv-04.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/mixed; boundary="OtherAccess" --OtherAccess Content-Type: text/plain; charset="ISO-8859-1"; name="Gmane-Attachment-Warning.txt" Content-Disposition: attachment; filename="Gmane-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Thu Feb 3 23:08:54 2005 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/= quarantine/20050203 (message 1Cwp8O-0003Vj-7P). --=20 Postmaster Gmane gmane.org MailScanner thanks transtec Computers for their support --OtherAccess Content-Type: text/plain; charset="ISO-8859-1"; name="Gmane-Attachment-Warning.txt" Content-Disposition: attachment; filename="Gmane-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Thu Feb 3 23:08:54 2005 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/= quarantine/20050203 (message 1Cwp8O-0003Vj-7P). --=20 Postmaster Gmane gmane.org MailScanner thanks transtec Computers for their support --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 Wed Dec 27 15:58:27 2006 From: nabil.n.bitar@verizon.com Subject: RE: Re: I-D ACTION: draft-martini-pwe3-MH-PW-requirements-00.txt Date: Mon, 7 Feb 2005 06:23:25 -0500 Lines: 136 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: philippe.niger@francetelecom.com, ckoc@zteusa.com, yaakov_s@rad.com, 'Alik Shimelmits' , neil.2.harrison@bt.com, 'Luca Martini' , peter.j.willis@bt.com, richard.spencer@bt.com, 'Sasha Vainshtein' , dimitri.papadimitriou@alcatel.be, simon.delord@francetelecom.com, "'PWE3 WG $E-mail$'" , rahul@juniper.net, busschbach@lucent.com, 'Sharon Galtzur' , 'Ping Pan' , jdrake@calient.net, dbrungard@att.com, Matthew.Bocci@alcatel.co.uk X-From: pwe3-bounces@ietf.org Tue Feb 08 10:08:25 2005 X-Server-Uuid: 2F91DA65-DB13-41BC-8809-D657BCBC59D7 To: "David McDysan" X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.0.2CF2|July 23, 2003) at 02/07/2005 05:23:31 X-WSS-ID: 6E19903930S59448-01-01 X-Spam-Score: 0.3 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Feb 2005 04:07:04 -0500 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Comments in line. Thanks, Nabil |---------+----------------------------> | | "David McDysan" | | | | | | | | | 01/19/2005 12:49 | | | PM | | | | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------| | | | To: "'Luca Martini'" , "'Sasha Vainshtein'" | | cc: philippe.niger@francetelecom.com, ckoc@zteusa.com, yaakov_s@rad.com, "'Alik Shimelmits'" , "'PWE3 WG | | (E-mail)'" , busschbach@lucent.com, Nabil N. Bitar/EMPL/MA/Verizon@VZNotes, peter.j.willis@bt.com, | | richard.spencer@bt.com, dimitri.papadimitriou@alcatel.be, simon.delord@francetelecom.com, rahul@juniper.net, "'Sharon Galtzur'" | | , "'Ping Pan'" , neil.2.harrison@bt.com, jdrake@calient.net, dbrungard@att.com, | | Matthew.Bocci@alcatel.co.uk | | Subject: RE: [PWE3] Re: I-D ACTION: draft-martini-pwe3-MH-PW-requirements-00.txt | >--------------------------------------------------------------------------------------------------------------------------------------------| Some additional comments on draft-martini-pwe3-MH-PW-requirements-00.txt not covered in previous posts. Dave Section 5 Use cases, iv, PWs in Metro networks Suggest adding a sentence stating that the topology that connects a U-PE access metro device to an S-PE metro aggregation may be simple (e.g., single homed from a packet routing perspective) and that restoration may be handled at lower layers (e.g., SONET/SDH protection). NB> Can add that. Hoever, a valid configuration is also to setup a backup PW in certain cases if one NB> is to protect against S-PE failure. Section 6.2 Traffic Engineering Suggest stating the full set of TE parameters: capacity (at least average rate, possibly peak rate), burst duration (token bucket depth). Has the use of affinities (i.e., colors) been considered to support the diversity requirement in section 6.4, routing? NB> This is obviously important in the dynamic signaling of the PW (i.e., no NB> static provisioning at S-PEs). We can specify traffic parameters in the doc. NB> However, that raises another issue about mapping from the native AC to the NB> PW parameters that would need to mentioned as well. Any thoughts on that? Section 6.3 QoS This discussion needs to be converted into requirements language. Two requirements I read out of this are: 1) Mandatory request for QoS - if this cannot be met, then the MH-PW attempt is rejected 2) Desirable request for QoS - if this cannot be met, then another QoS characteristic can be provided. Suggest that in this case notification indicate the type of QoS that was provided. This would in general need to be a list if a number of domains are traversed. NB> We should tighten the anguage on QoS. I thought (1) is covered, but will doublecheck. Are you suggesting in (2) NB> (2) seems to add more complexity to the setup process and I am not sure that is needed. Of course, need to more precisely define what is meant by QoS and what standard convention would be used to communicate it. NB> The question in this case is whether we should signal delay and jitter requirements. If we do, NB> the remaining budget should be carried in the setup of the PW to help the S-PE select NB> a path. This will imply a speciic way of setting up the MH-PW. NB> The alternative is to be more laxed and signal the CoS only and assume that the performance parameter bounds NB> are implicit in that CoS definition. Fourth paragraph: Need more descriptive text on BW broker. Is there a reference to this concept that provides defines the concept and the proposed protocols? How would the BW broker interact with routing? 6.4 Routing Suggest adding a mandatory (SHALL) requirement where the sequence of S-PEs is explicitly specified. Specifying the sequence of S-PEs in the MH-PW path should be an option that contrain the path of a MH-PW. This is equivalent to adding an ERO and applies in the single-ended signaling requirement. Will work that in the draft. There are at least two ways of implementing this; via an object in the PW signaling message, or OSS provisioning of the intermediate S-PEs with the S-PE next hop using (part of) the generic FEC, possibly AGI to identify this explicit route. This explicit routing specification of S-PEs does not meet all resiliency scenarios, but would be useful in scenarios where topology and alternate routes are limited (e.g., a metro access network). It does help setting specifying a diversified alternate path for a backup. As mentioned in earlier posts, the general problem of designing another level of S-PE routing is not trivial and a simple solution that meets a simpler network environment as a subset of the full solution is desirable. Doesn't the static stitching at S-PEs of MH-PW segments satisfy this? From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: nabil.n.bitar@verizon.com Subject: Re: Re: I-D ACTION: draft-martini-pwe3-MH-PW-requirements-0 0.txt Date: Mon, 7 Feb 2005 11:12:11 -0500 Lines: 157 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: philippe.niger@francetelecom.com, ckoc@zteusa.com, yaakov_s@rad.com, Alik Shimelmits , neil.2.harrison@bt.com, 'Luca Martini' , peter.j.willis@bt.com, richard.spencer@bt.com, Sasha Vainshtein , dimitri.papadimitriou@alcatel.be, simon.delord@francetelecom.com, "PWE3 WG $E-mail$" , rahul@juniper.net, busschbach@lucent.com, Sharon Galtzur , Ping Pan , jdrake@calient.net, dbrungard@att.com, Matthew.Bocci@alcatel.co.uk X-From: pwe3-bounces@ietf.org Tue Feb 08 10:11:06 2005 X-Server-Uuid: 3A6621B7-3263-48CE-B234-243F618F6620 To: "Peter Willis" X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.0.2CF2|July 23, 2003) at 02/07/2005 10:12:15 X-WSS-ID: 6E194CEA1ZW115959-01-01 X-Spam-Score: 0.3 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Feb 2005 04:09:07 -0500 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Peter, Comments in line. Thanks, Nabil "Peter Willis" ng.bt.com> cc: "'Luca Martini'" , philippe.niger@francetelecom.com, ckoc@zteusa.com, yaakov_s@rad.com, "Alik Shimelmits" , 12/16/2004 12:05 busschbach@lucent.com, dbrungard@att.com, Nabil N. Bitar/EMPL/MA/Verizon@VZNotes, PM peter.j.willis@bt.com, richard.spencer@bt.com, dimitri.papadimitriou@alcatel.be, simon.delord@francetelecom.com, "PWE3 WG (E-mail)" , rahul@juniper.net, neil.2.harrison@bt.com, "Sharon Galtzur" , "Ping Pan" , jdrake@calient.net, Matthew.Bocci@alcatel.co.uk Subject: Re: [PWE3] Re: I-D ACTION: draft-martini-pwe3-MH-PW-requirements-0 0.txt > 2. Requirement (mentioned by several people in the discussion on the DT > list) > for "one-touch single-ended provisioning of an MH-PE". The draft in question > presents a weaker form of this requirement (Section 6.5., item ii), speaking > about > an option to signal a MH-PW using a minimal number of OSS touches, where > the minimal number" may be greater than 1. But if we tend for single-touch > provisioning, the following logic looks correct to me: > * The device to be touched MUST be one of the U-PEs > * It MUST receive the information containg unambiguous identification of the > remote > peer end point, including unambiguous identification of the remote U-PE > > Of course, one could argue that unambiguous identification of the remote > U-PE > does not have to be its IP address. But in real life, what other unambiguous > identification of devices do we have? Phone numbers? > > We should be clear whether the 1 touch single-ended provisioning of an MH-PW applies to both the intra-operator & inter-operator cases? If it only applied to the intra-operator case then the solution may be simpler. Agree. This is an important distinction from security and confidentiality view point. If we want 1 touch single-ended provisioning for the inter-operator case then I think we would want an AAA mechanism on the S-PEs (but we can abstract that and just say the S-PEs have a policy mechanism for policing the set-up of MH-PWs) and then I'm not sure whether authentication of the signalling entities between operators is sufficient or whether each MH-PW needs its own AAA. I suspect the later makes reusing PPP/radius like mechanisms easier? Did you mean single-ended provisioning or endpoint provisining and single-ended signaling? I do agree with the general poicing function at the interprovider boundaries. Authentication of the signaling entities is necessary. Regarding authentication per MH-PW, I can see a case where you may want to ensure that one source point for a MH-PW can actually connect to the destination it wants to connect to. Since the MH-PW can be entering the destination domain through one ore more S-PEs, one may want to autenticate that at the ingress ASBR (from signaling view point) or at the destination U-PE. If you look at PSTN style VoIP interconnects (see http://www.msforum.org/) you'll see examples of how IP connections are set-up between operators where the IP addresses of the infrastructures are hidden and a common identifier (the telephone number) is used to set-up the connection. I can see similar requirements for inter-operator MH-PWs, i.e. Operators will want to hide the IP addresses of their infrastructure (signalling & media connection points) from each other. Of course there is no reason why the MH-PW attachement points could not use IP addresses (I'd be ambitious and suggest IPv6 addresses) that have nothing to do with the IP addresses used for the control planes & the network infrastructure. The solution here will look very complex (something like the MSF solution?) so the requirement for single-ended provisioning of PWs inter-operator must be really strong to justify this. To do this hiding, there are many possible mechanisms and may depend on the way that that the MH-PW is setup. In the static stitching case between segments, I think that it is clear that the hiding that can be easily achieved, as the U-PE needs to signal for a PW segment that can be identified at an S-PE where the endpoint of the segment is configured. That is in turn can be statically correlated with the next statically configured segment. In that way, the signaling message is addressed to the S-PE (not the remote U-PE). This can repeat across boundaries. The issue here is related to single-end signaling and the contraint is the signaling message has to get finally to get to the remote U-PE through intermediate S-PEs. One possible way to achieve the hiding here is to include in something like a TAI an identifier for the destination (I think Others have indicated something along that line). That identifier can be of many form but may include something like (network address and a connection identifier in that context of that address. However that network addrees must be usable by the S-PE or some proxy to find an IP route to the destination. In addition, for the general case, that address should be globally unique so that an S-PE that happens to be the next domain ASBR can uniquely identify the destination. Otherwise, one has to configure translations or resolutions at every domain boundaries (which defeats the purpose of only endpoint provisioning), especially if the MH-PW crosses multiple provider domains (which one may argue it is the not the most common case). Thus, the simplest form is to have the network to be an IPv4 address based on existing network deployments. To perform the hiding, U-PEs can be assigned loopback addresses that are aggregatable and get used for this purpose for instance or have IPv4 addresses assigned to UNI ports etc. These aggregates can be advertised in BGP for instance, only the destination domain will have the host address reachability. The alternative of having an IPv6 address, NSAP, E.164 addresses are also possible. They will either require assigning the destination addresses or require some mapping or resolution of these addresses to U-PE addresses or routes that lead to the destination network where ultimately that endpoint network address is resolved to the U-PE IPv4 address. Regards, Peter Willis, Office of the BT Group CTO. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Thomas D. Nadeau" Subject: Re: Clarification Requestedd: draft-ieft-pwe3-vccv-03 (Section 6) Date: Tue, 8 Feb 2005 03:37:52 -0500 Lines: 39 References: <41F6679B.5040205@alcatel.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Feb 08 11:25:44 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== In-Reply-To: <41F6679B.5040205@alcatel.com> To: Mark Aberdeen X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org On Jan 25, 2005, at 10:36 AM, Mark Aberdeen wrote: > Section 6, Page 8 states the following: > > "The receiving PE agrees to accept any of the indicated > OAM types and options by virtue of establishing the PW. If > it does not or cannot support at least one of the options > specified, it MUST not establish the PW." > > Does this simply mean that the receiving PE will not complete the > label mapping? Or is the PW be established and with no OAM support? OAM parameters are advertised by one router to the other to indicate which VCCV types it can support and is expecting to receive; there is no negotiation per se. Once both sides have indicated which VCCV "mode" they support, both sides know which modes to both send to their peer, and what to expect from them. I am updating the draft to make this more clear. --Tom > -- > > Mark Aberdee, B.E., B.Sc., P.Eng. > 7670 RSP Software Development > Alcatel Canada > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Thomas D. Nadeau" Subject: Re: Clarification Requestedd: draft-ieft-pwe3-vccv-03 (Sec tion6) Date: Tue, 8 Feb 2005 11:26:14 -0500 Lines: 86 References: <9671A92C3C8B5744BC97F855F7CB646503153B25@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, Mark Aberdeen X-From: pwe3-bounces@ietf.org Tue Feb 08 17:34:41 2005 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646503153B25@zcarhxm1.corp.nortel.com> To: "Florin Balus" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org On Feb 8, 2005, at 11:09 AM, Florin Balus wrote: > > > Tom, > Not sure I am clear on what you're saying: let's assume that for PWID=20= > 40 PE1 supports OAM option X and PE 2 doesn't. > > Are you saying that PE1 and PE2 should reject the incoming LM=20 > messages from the remote peer because OAM option X does not match? No. It should accept them just fine, and remember what = preferences the remote PE sent it. It should then ONLY send that type of VCCV when/if the PW comes up to that peer. --Tom > Or that they should accept the LMs but should both revert to the=20 > common denominator (i.e. no OAM option X)? > > Regards, > Florin > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > > Behalf Of Thomas D. Nadeau > > Sent: Tuesday, February 08, 2005 3:38 AM > > To: Mark Aberdeen > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] Clarification Requestedd: > > draft-ieft-pwe3-vccv-03 (Section6) > > > > > > > > On Jan 25, 2005, at 10:36 AM, Mark Aberdeen wrote: > > > > > Section 6, Page 8 states the following: > > > > > >=A0=A0=A0 "The receiving PE agrees to accept any of the indicated > > >=A0=A0=A0 OAM types and options by virtue of establishing the PW.=A0 = If > > >=A0=A0=A0 it does not or cannot support at least one of the options > > >=A0=A0=A0 specified, it MUST not establish the PW." > > > > > > Does this simply mean that the receiving PE will not complete the > > > label mapping?=A0 Or is the PW be established and with no OAM=20 > support? > > > > =A0=A0=A0=A0=A0 OAM parameters are advertised by one router to the = other > > to indicate which VCCV types it can support and is expecting > > to receive; there is no negotiation per se.=A0 Once both sides > > have indicated which VCCV "mode" they support, both sides > > know which modes to both send to their peer, and what to > > expect from them. > > > > =A0=A0=A0=A0=A0 I am updating the draft to make this more clear. > > > > =A0=A0=A0=A0=A0 --Tom > > =A0=A0=A0=A0=A0 > > > > > -- > > > > > > Mark Aberdee, B.E., B.Sc., P.Eng. > > > 7670 RSP Software Development > > > Alcatel Canada > > > > > > > > > > > > > > > _______________________________________________ > > > 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 27 15:58:27 2006 From: David McDysan Subject: RE: Re: I-D ACTION: draft-martini-pwe3-MH-PW-requirements-0 0.txt Date: Wed, 09 Feb 2005 09:56:10 -0500 Lines: 249 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "'PWE3 WG $E-mail$'" X-From: pwe3-bounces@ietf.org Wed Feb 09 16:00:17 2005 In-reply-to: To: nabil.n.bitar@verizon.com, "'Peter Willis'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org A few responses in line. Dave > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of nabil.n.bitar@verizon.com > Sent: Monday, February 07, 2005 11:12 AM > To: Peter Willis > Cc: philippe.niger@francetelecom.com; ckoc@zteusa.com;=20 > yaakov_s@rad.com; Alik Shimelmits; neil.2.harrison@bt.com;=20 > 'Luca Martini'; peter.j.willis@bt.com;=20 > richard.spencer@bt.com; Sasha Vainshtein;=20 > dimitri.papadimitriou@alcatel.be;=20 > simon.delord@francetelecom.com; PWE3 WG (E-mail);=20 > rahul@juniper.net; busschbach@lucent.com; Sharon Galtzur;=20 > Ping Pan; jdrake@calient.net; dbrungard@att.com;=20 > Matthew.Bocci@alcatel.co.uk > Subject: Re: [PWE3] Re: I-D ACTION:=20 > draft-martini-pwe3-MH-PW-requirements-0 0.txt >=20 >=20 >=20 >=20 >=20 >=20 > Peter, > Comments in line. >=20 > Thanks, > Nabil >=20 >=20 >=20 >=20 > =20 > =20 > =20 > "Peter Willis" =20 > =20 > =20 > "Sasha Vainshtein" =20 > =20 > ng.bt.com> cc: =20 > "'Luca Martini'" ,=20 > philippe.niger@francetelecom.com, =20 > =20 > ckoc@zteusa.com, yaakov_s@rad.com, "Alik Shimelmits"=20 > , =20 > 12/16/2004 12:05 =20 > busschbach@lucent.com, dbrungard@att.com, Nabil N.=20 > Bitar/EMPL/MA/Verizon@VZNotes, =20 > PM =20 > peter.j.willis@bt.com, richard.spencer@bt.com,=20 > dimitri.papadimitriou@alcatel.be, =20 > =20 > simon.delord@francetelecom.com, "PWE3 WG (E-mail)"=20 > , =20 > =20 > rahul@juniper.net, neil.2.harrison@bt.com, "Sharon Galtzur"=20 > , =20 > "Ping Pan"=20 > , jdrake@calient.net, =20 > =20 > =20 > Matthew.Bocci@alcatel.co.uk =20 > =20 > Subject: Re:=20 > [PWE3] Re: I-D ACTION:=20 > draft-martini-pwe3-MH-PW-requirements-0 0.txt =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 >=20 > > 2. Requirement (mentioned by several people in the=20 > discussion on the=20 > > DT > > list) > > for "one-touch single-ended provisioning of an MH-PE". The draft in > question > > presents a weaker form of this requirement (Section 6.5., item ii), > speaking > > about > > an option to signal a MH-PW using a minimal number of OSS touches,=20 > > where the minimal number" may be greater than 1. But if we tend for > single-touch > > provisioning, the following logic looks correct to me: > > * The device to be touched MUST be one of the U-PEs > > * It MUST receive the information containg unambiguous=20 > identification=20 > > of > the > > remote > > peer end point, including unambiguous identification of the remote=20 > > U-PE > > > > Of course, one could argue that unambiguous identification of the=20 > > remote U-PE does not have to be its IP address. But in real=20 > life, what=20 > > other > unambiguous > > identification of devices do we have? Phone numbers? > > > >=20 > We should be clear whether the 1 touch single-ended=20 > provisioning of an MH-PW applies to both the intra-operator &=20 > inter-operator cases? If it only applied to the=20 > intra-operator case then the solution may be simpler. >=20 > Agree. This is an important distinction from security=20 > and confidentiality view point. >=20 Suggest that intra versus inter operator is more of a use case = description and that the requirements should focus on the protocol. For example a technical requirement could be use of IP addresses or some other to be specified identifier mentioned previously on this list (e.g., phone = number or something else). Either identifier could be employed in an inter or = intra operator context. > If we want 1 touch single-ended provisioning for the=20 > inter-operator case then I think we would want an AAA=20 > mechanism on the S-PEs (but we can abstract that and just say=20 > the S-PEs have a policy mechanism for policing the set-up of > MH-PWs) and then I'm not sure whether authentication of the=20 > signalling entities between operators is sufficient or=20 > whether each MH-PW needs its own AAA. I suspect the later=20 > makes reusing PPP/radius like mechanisms easier? >=20 > Did you mean single-ended provisioning or endpoint=20 > provisining and single-ended signaling? I do agree with=20 > the general poicing function at the interprovider =20 > boundaries. Authentication of the signaling entities is=20 > necessary. Regarding authentication per MH-PW, I can see=20 > a case where you may want to ensure that one source point for=20 > a MH-PW can actually connect to the destination it wants=20 > to connect to. Since the MH-PW can be entering the=20 > destination domain through one ore more S-PEs, one may=20 > want to autenticate that at the ingress ASBR (from signaling=20 > view point) or at the destination U-PE. >=20 > If you look at PSTN style VoIP interconnects (see=20 > http://www.msforum.org/) you'll see examples of how IP=20 > connections are set-up between operators where the IP=20 > addresses of the infrastructures are hidden and a common=20 > identifier (the telephone number) is used to set-up the=20 > connection. I can see similar requirements for inter-operator=20 > MH-PWs, i.e. Operators will want to hide the IP addresses of=20 > their infrastructure (signalling & media connection points) >=20 > from each other. Of course there is no reason why the MH-PW=20 > attachement points could not use IP addresses (I'd be=20 > ambitious and suggest IPv6 addresses) that have nothing to do=20 > with the IP addresses used for the control planes & the=20 > network infrastructure. The solution here will look very=20 > complex (something >=20 > like the MSF solution?) so the requirement for single-ended=20 > provisioning of >=20 > PWs inter-operator must be really strong to justify this. >=20 > To do this hiding, there are many possible mechanisms=20 > and may depend on the way that that the MH-PW is setup.=20 > In the static stitching case between segments, I think that=20 > it is clear that the hiding that can be easily achieved,=20 > as the U-PE needs to signal for a PW segment that can be=20 > identified at an S-PE where the endpoint of the segment =20 > is configured. That is in turn can be statically correlated=20 > with the next statically configured segment. In that=20 > way, the signaling message is addressed to the S-PE (not the=20 > remote U-PE). This can repeat across boundaries. =20 > The issue here is related to single-end signaling and the=20 > contraint is the signaling message has to get finally to=20 > get to the remote U-PE through intermediate S-PEs. One=20 > possible way to achieve the hiding here is to include in=20 > something like a TAI an identifier for the destination=20 > (I think Others have indicated something along that line).=20 Do we want to (re)define the TAI for this purpose, or consider defining another object? > That identifier can be of many form but may include=20 > something like (network address and a connection identifier=20 > in that context of that address. However that network=20 > addrees must be usable by the S-PE or some proxy to find an=20 > IP route to the destination. =20 Suggest^^^ toward > In addition, for the=20 > general case, that address should be globally unique so that=20 > an S-PE that happens to be the next domain ASBR can=20 > uniquely identify the destination. Otherwise, one has to=20 > configure translations or resolutions at every domain=20 > boundaries (which defeats the purpose of only endpoint=20 > provisioning), especially if the MH-PW crosses multiple=20 > provider domains (which one may argue it is the not the most=20 > common case). Thus, the simplest form is to have the=20 > network to be an IPv4 address based on existing network=20 suggest or IPv6 > deployments. To perform the hiding, U-PEs can be assigned=20 > loopback addresses that are aggregatable and get used=20 > for this purpose for instance or have IPv4 addresses assigned=20 > to UNI ports etc. These aggregates can be advertised in=20 > BGP for instance, only the destination domain will have the=20 > host address reachability.=20 Other IP routing protocols can be used for this purpose as well. > The alternative of having an=20 > IPv6 address, NSAP, E.164 addresses are also possible.=20 > They=20 > will either require assigning the destination addresses=20 > or require some mapping or resolution of these addresses=20 > to U-PE addresses or routes that lead to the destination=20 > network where ultimately that endpoint network address=20 > is resolved to the U-PE IPv4 address. Suggest that you add the essence of the above text to the next draft and attempt to use requirements verbs (SHALL, SHOULD). It is a good = description of what needs to be done. >=20 > Regards, > Peter Willis, > Office of the BT Group CTO. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: David McDysan Subject: RE: Re: I-D ACTION: draft-martini-pwe3-MH-PW-requirements-00.txt Date: Wed, 09 Feb 2005 09:56:10 -0500 Lines: 234 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "'PWE3 WG $E-mail$'" X-From: pwe3-bounces@ietf.org Wed Feb 09 16:00:24 2005 In-reply-to: To: nabil.n.bitar@verizon.com X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Nabil, Trimming distro to pwe3. A few responses in line below. Thanks, Dave > -----Original Message----- > From: nabil.n.bitar@verizon.com [mailto:nabil.n.bitar@verizon.com]=20 > Sent: Monday, February 07, 2005 6:23 AM > To: David McDysan > Cc: 'Alik Shimelmits'; busschbach@lucent.com;=20 > ckoc@zteusa.com; dbrungard@att.com;=20 > dimitri.papadimitriou@alcatel.be; jdrake@calient.net; 'Luca=20 > Martini'; Matthew.Bocci@alcatel.co.uk;=20 > neil.2.harrison@bt.com; peter.j.willis@bt.com;=20 > philippe.niger@francetelecom.com; 'Ping Pan'; 'PWE3 WG=20 > (E-mail)'; rahul@juniper.net; richard.spencer@bt.com; 'Sasha=20 > Vainshtein'; 'Sharon Galtzur';=20 > simon.delord@francetelecom.com; yaakov_s@rad.com > Subject: RE: [PWE3] Re: I-D ACTION:=20 > draft-martini-pwe3-MH-PW-requirements-00.txt >=20 >=20 >=20 >=20 >=20 >=20 > Comments in line. >=20 > Thanks, > Nabil >=20 >=20 >=20 > |---------+----------------------------> > | | "David McDysan" | > | | | | .com> | > | | | > | | 01/19/2005 12:49 | > | | PM | > | Subject: RE: [PWE3] Re: I-D ACTION:=20 > draft-martini-pwe3-MH-PW-requirements-00.txt =20 >=20 >=20 >=20 >=20 > Some additional comments on=20 > draft-martini-pwe3-MH-PW-requirements-00.txt > not > covered in previous posts. >=20 > Dave >=20 > Section 5 Use cases, iv, PWs in Metro networks >=20 > Suggest adding a sentence stating that the topology that=20 > connects a U-PE access metro device to an S-PE metro=20 > aggregation may be simple (e.g., single homed from a packet=20 > routing perspective) and that restoration may be handled at=20 > lower layers (e.g., SONET/SDH protection). >=20 > NB> Can add that. Hoever, a valid configuration is also to setup a=20 > NB> backup > PW in certain cases if one > NB> is to protect against S-PE failure. Agreed. Suggest that the document mention both cases: that is, U-PE = homed to a single S-PE and U-PE homed to two or more S-PEs. >=20 > Section 6.2 Traffic Engineering >=20 > Suggest stating the full set of TE parameters: capacity (at=20 > least average rate, possibly peak rate), burst duration=20 > (token bucket depth). Has the use of affinities (i.e.,=20 > colors) been considered to support the diversity requirement=20 > in section 6.4, routing? >=20 >=20 > NB> This is obviously important in the dynamic signaling of the PW=20 > NB> (i.e., > no > NB> static provisioning at S-PEs). We can specify traffic=20 > parameters in=20 > NB> the > doc. > NB> However, that raises another issue about mapping from the=20 > native AC=20 > NB> to > the > NB> PW parameters that would need to mentioned as well. Any=20 > thoughts on > that? I'm not sure that I understand the question about mapping native = Attachment circuit (AC) to the PW parameters with respect to TE parameters. One = that seems obvious is that the peak rate is less than or equal to the AC = physical transmission rate. If you have some other examples in mind, please elaborate. >=20 > Section 6.3 QoS >=20 > This discussion needs to be converted into requirements=20 > language. Two requirements I read out of this are: > 1) Mandatory request for QoS - if this cannot be=20 > met, then the MH-PW attempt is rejected > 2) Desirable request for QoS - if this cannot be=20 > met, then another QoS characteristic can be provided. Suggest=20 > that in this case notification indicate the type of QoS that=20 > was provided. This would in general need to be a list if a=20 > number of domains are traversed. >=20 > NB> We should tighten the anguage on QoS. I thought (1) is=20 > covered, but > will doublecheck. Are you suggesting in (2) > NB> (2) seems to add more complexity to the setup process and=20 > I am not=20 > NB> sure > that is needed. My comment was that requirements need to use SHALL, SHOULD, MAY.=20 A way of simplifying this could be if originator signals mandatory QoS, = and if that fails (need to have indication in signaling that indicates the reason) then originator resignals without QoS request. I think a similar approach was discussed for OAM on the list. >=20 > Of course, need to more precisely define what is meant by QoS=20 > and what standard convention would be used to communicate it. >=20 > NB> The question in this case is whether we should signal delay and=20 > NB> jitter > requirements. If we do, > NB> the remaining budget should be carried in the setup of the PW to=20 > NB> help > the S-PE select > NB> a path. This will imply a speciic way of setting up the=20 > MH-PW. The=20 > NB> alternative is to be more laxed and signal the CoS only and assume > that the performance parameter bounds > NB> are implicit in that CoS definition. As Jerry Ash pointed out, both of these methods are covered in the = following NSIS draft: http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qsp-00.txt. Suggest referencing this draft in the next version. Signaling the accumulated QoS parameter (latency, latency variation, = loss, etc.) is more general, yet more complex. The use of certain class or = service (CoS) (e.g., Y.1541) seems to implicitly assume a reference = configuraiton, which may or may not be appropriate. If this CoS method is used, would = be useful to track the domains traversed so that it could be mapped against = the reference model. Suggest that both methods: accumulate QoS parms and use CoS be mentioned = in the next version.=20 >=20 > Fourth paragraph: Need more descriptive text on BW broker. Is=20 > there a reference to this concept that provides defines the=20 > concept and the proposed protocols? How would the BW broker=20 > interact with routing? >=20 > 6.4 Routing >=20 > Suggest adding a mandatory (SHALL) requirement where the=20 > sequence of S-PEs is explicitly specified. >=20 > Specifying the sequence of S-PEs in the MH-PW path=20 > should be an option that contrain the path of a MH-PW.=20 > This is equivalent to adding an ERO and applies in the=20 > single-ended signaling requirement. Will work that in the draft. Suggest that the protocol definition must support this capability = (SHALL), however, the object and procedures need not be supported in every implementaiton (MAY). >=20 > There are at least two ways of implementing this; via an=20 > object in the PW signaling message, or OSS provisioning of=20 > the intermediate S-PEs with the S-PE next hop using (part of)=20 > the generic FEC, possibly AGI to identify this explicit route. >=20 > This explicit routing specification of S-PEs does not meet=20 > all resiliency scenarios, but would be useful in scenarios=20 > where topology and alternate routes are limited (e.g., a=20 > metro access network). >=20 > It does help setting specifying a diversified alternate=20 > path for a backup. >=20 > As mentioned in earlier posts, the general problem of=20 > designing another level of S-PE routing is not trivial and a=20 > simple solution that meets a simpler network environment as a=20 > subset of the full solution is desirable. >=20 > Doesn't the static stitching at S-PEs of MH-PW segments=20 > satisfy this? >=20 >=20 Partially. Believe this approach does not address at least the following issues: discovering S-PEs, selecting a path that meets constraints (QoS, = OAM capability, diversity, etc.), minimizing number of OSS touches (every stitching point must be configured). >=20 >=20 >=20 >=20 >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Florin Balus" Subject: RE: Clarification Requestedd: draft-ieft-pwe3-vccv-03 (Sec tion6) Date: Tue, 8 Feb 2005 11:09:06 -0500 Lines: 221 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0632472084==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Feb 09 17:59:33 2005 To: "Thomas D. Nadeau" , Mark Aberdeen X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 X-Mailman-Approved-At: Wed, 09 Feb 2005 11:57:30 -0500 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.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. --===============0632472084== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50DF8.84C242FD" 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_01C50DF8.84C242FD Content-Type: text/plain Tom, Not sure I am clear on what you're saying: let's assume that for PWID 40 PE1 supports OAM option X and PE 2 doesn't. Are you saying that PE1 and PE2 should reject the incoming LM messages from the remote peer because OAM option X does not match? Or that they should accept the LMs but should both revert to the common denominator (i.e. no OAM option X)? Regards, Florin > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Thomas D. Nadeau > Sent: Tuesday, February 08, 2005 3:38 AM > To: Mark Aberdeen > Cc: pwe3@ietf.org > Subject: Re: [PWE3] Clarification Requestedd: > draft-ieft-pwe3-vccv-03 (Section6) > > > > On Jan 25, 2005, at 10:36 AM, Mark Aberdeen wrote: > > > Section 6, Page 8 states the following: > > > > "The receiving PE agrees to accept any of the indicated > > OAM types and options by virtue of establishing the PW. If > > it does not or cannot support at least one of the options > > specified, it MUST not establish the PW." > > > > Does this simply mean that the receiving PE will not complete the > > label mapping? Or is the PW be established and with no OAM support? > > OAM parameters are advertised by one router to the other > to indicate which VCCV types it can support and is expecting > to receive; there is no negotiation per se. Once both sides > have indicated which VCCV "mode" they support, both sides > know which modes to both send to their peer, and what to > expect from them. > > I am updating the draft to make this more clear. > > --Tom > > > > -- > > > > Mark Aberdee, B.E., B.Sc., P.Eng. > > 7670 RSP Software Development > > Alcatel Canada > > > > > > > > > > _______________________________________________ > > 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 > > ------_=_NextPart_001_01C50DF8.84C242FD Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [PWE3] Clarification Requestedd: draft-ieft-pwe3-vccv-03 = (Section6)

Tom,
Not sure I am clear on what you're saying: let's = assume that for PWID 40 PE1 supports OAM option X and PE 2 doesn't. =

Are you saying that PE1 and PE2 should reject the = incoming LM messages from the remote peer because OAM option X does not = match?

Or that they should accept the LMs but should both = revert to the common denominator (i.e. no OAM option X)?

Regards,
Florin

> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = On
> Behalf Of Thomas D. Nadeau
> Sent: Tuesday, February 08, 2005 3:38 AM
> To: Mark Aberdeen
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] Clarification Requestedd: =
> draft-ieft-pwe3-vccv-03 (Section6)
>
>
>
> On Jan 25, 2005, at 10:36 AM, Mark Aberdeen = wrote:
>
> > Section 6, Page 8 states the = following:
> >
> >    "The receiving PE = agrees to accept any of the indicated
> >    OAM types and options by = virtue of establishing the PW. If
> >    it does not or cannot = support at least one of the options
> >    specified, it MUST not = establish the PW."
> >
> > Does this simply mean that the receiving = PE will not complete the
> > label mapping? Or is the PW be = established and with no OAM support?
>
>       OAM parameters = are advertised by one router to the other
> to indicate which VCCV types it can support and = is expecting
> to receive; there is no negotiation per = se. Once both sides
> have indicated which VCCV "mode" they = support, both sides
> know which modes to both send to their peer, = and what to
> expect from them.
>
>       I am updating = the draft to make this more clear.
>
>       --Tom
>
>
> > --
> >
> > Mark Aberdee, B.E., B.Sc., P.Eng.
> > 7670 RSP Software Development
> > Alcatel Canada
> >
> >
> >
> >
> > = _______________________________________________
> > 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=
>
>
------_=_NextPart_001_01C50DF8.84C242FD-- --===============0632472084== 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 --===============0632472084==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Prabakaran T Sampath" Subject: FW: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt Date: Fri, 11 Feb 2005 12:53:14 +0530 Lines: 163 Reply-To: prabakarts@future.futsoft.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0055_01C51038.A7134C80" X-From: pwe3-bounces@ietf.org Fri Feb 11 08:23:06 2005 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C51038.A7134C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear PWE3-WG, This is Prabakaran T.S. and Musthafa A.S. from FutureSoft, a Flextronics company. We have come up with some concept and contributed it as a IETF draft in VPLS. Kindly go through this draft and give us your valuable comments and feedback either in IETF VPLS/PWE3 working group or directly to us by email. Thanks in advance, Best regards, Prabakaran T.S. Musthafa A.S. FutureSoft, a Flextronics company, 480-481 Anna salai, Nandanam, Chennai-600035. INDIA. Ph: +91-44-24330550, extn: 459 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, 11 February 2005 2:18 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast Emulation over VPLS Author(s) : Prabakaran T.S, Musthafa A.S Filename : draft-praba-l2vpn-vpls-mcast-emul-00.txt Pages : 14 Date : 2005-2-10 In Virtual Private LAN Service (VPLS), the PE devices provide a logical interconnect such that CE devices belonging to a specific VPLS instance appear to be connected by a single LAN. A VPLS solution performs replication for multicast traffic at the ingress PE devices. When replicated at the ingress PE, multicast traffic wastes bandwidth when 1. Multicast traffic is sent to sites with no members, and 2. Pseudo wires to different sites go through a shared path. This document addresses the above cases by using LDP signaling to emulate Multicast operation over VPLS with out using IGMP and PIM snooping as described in [VPLS-MCAST]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-praba-l2vpn-vpls-mcast-emul-00.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-praba-l2vpn-vpls-mcast-emul-00.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-praba-l2vpn-vpls-mcast-emul-00.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. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0055_01C51038.A7134C80 Content-Type: Message/External-body; name="ATT00108.dat" Content-Disposition: attachment; filename="ATT00108.dat" Content-Transfer-Encoding: 7bit From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Prabakaran T Sampath" Subject: RE: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt Date: Fri, 11 Feb 2005 16:34:17 +0530 Lines: 206 References: Reply-To: prabakarts@future.futsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Prabakaran T Sampath - FS $E-mail$" , musthafaa@future.futsoft.com X-From: pwe3-bounces@ietf.org Fri Feb 11 12:03:47 2005 Return-path: To: , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Hi Venkat, Thanks for your wishes. Please see my inlined reply. Best regards, Prabakaran T.S. FutureSoft, a Flextronics company, 480-481 Anna salai, Nandanam, Chennai-600035. INDIA. Ph: +91-44-24330550, extn: 459 -----Original Message----- From: venkat.dabbara@wipro.com [mailto:venkat.dabbara@wipro.com] Sent: Friday, 11 February 2005 3:54 PM To: prabakarts@future.futsoft.com; musthafaa@future.futsoft.com Subject: RE: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt Hai , First of all...congratulations for doing a wonderful work.... I have a few doubts. If i understand correct... 1. This draft is a substitute for draft-serbest-l2vpn-vpls-mcast-01.txt where same issue is addressed using multicast protocols (IGMP and PIM). Is that right ? This draft is not a substitute for the draft-serbest-l2vpn-vpls-mcast-01.txt. The IGMP and PIM snooping protocol require examining each packet to perform the snooping function and this approach avoids that. 2. In you draft, how do you support dynamic join/leave of multicast group. What i mean is, suppose a node is not interested in multicast traffic anymore and wants to leave the group. How will it be taken care ? If i understand correct this will result in a LDP notification message with "MF emulation enable bit and MF un-register bit fields set " to the originator peer. Is that right? Yes, you are correct. Here we are controlling the multicast data flooding on the PWs using the MF emulation enable bit and MF un-register bit fields set/reset. Thus we are emulating the multicast group join/leave per vpls instance. 3. And in what way is your proposal superior to the one proposed in draft-serbest-l2vpn-vpls-mcast-01.txt ? Nothing to offend your idea. But just wanted to know the positives since i have two options available now. Our proposal will be very much useful in a place where the L2 switches were not interested in running IGMP and PIM or any other multicast protocol stacks. Basically, we are reducing the over head of multicast protocol stack operations to perform the basic filtering of multicast flooding onto the PWs. Also, both drafts can be implemented without any harm, but our aim is the IGMP and PIM snooping protocol require examining each packet to perform the snooping function and this approach avoids that. thanks Venkat ________________________________ From: l2vpn-bounces@ietf.org on behalf of Prabakaran T Sampath Sent: Fri 2/11/2005 12:52 PM To: l2vpn@ietf.org Subject: FW: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt Dear L2VPN-WG, This is Prabakaran T.S. and Musthafa A.S. from FutureSoft, a Flextronics company. We have come up with some concept and contributed it as a IETF draft in VPLS. Kindly go through this draft and give us your valuable comments and feedback either in IETF VPLS working group or directly to us by email. Thanks in advance, Best regards, Prabakaran T.S. Musthafa A.S. FutureSoft, a Flextronics company, 480-481 Anna salai, Nandanam, Chennai-600035. INDIA. Ph: +91-44-24330550, extn: 459 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, 11 February 2005 2:18 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast Emulation over VPLS Author(s) : Prabakaran T.S, Musthafa A.S Filename : draft-praba-l2vpn-vpls-mcast-emul-00.txt Pages : 14 Date : 2005-2-10 In Virtual Private LAN Service (VPLS), the PE devices provide a logical interconnect such that CE devices belonging to a specific VPLS instance appear to be connected by a single LAN. A VPLS solution performs replication for multicast traffic at the ingress PE devices. When replicated at the ingress PE, multicast traffic wastes bandwidth when 1. Multicast traffic is sent to sites with no members, and 2. Pseudo wires to different sites go through a shared path. This document addresses the above cases by using LDP signaling to emulate Multicast operation over VPLS with out using IGMP and PIM snooping as described in [VPLS-MCAST]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-praba-l2vpn-vpls-mcast-emul-00.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-praba-l2vpn-vpls-mcast-emul-00.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-praba-l2vpn-vpls-mcast-emul-00.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. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt Date: Fri, 11 Feb 2005 15:32:18 -0500 Lines: 137 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Feb 11 22:50:27 2005 To: i-d-announce@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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Fragmentation and Reassembly Author(s) : A. Malis, M. Townsley Filename : draft-ietf-pwe3-fragmentation-08.txt Pages : 14 Date : 2005-2-11 This document defines a generalized method of performing fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) protocols and services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-08.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-fragmentation-08.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-fragmentation-08.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/mixed; boundary="OtherAccess" --OtherAccess Content-Type: text/plain; charset="ISO-8859-1"; name="Gmane-Attachment-Warning.txt" Content-Disposition: attachment; filename="Gmane-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Fri Feb 11 22:50:26 2005 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/= quarantine/20050211 (message 1Czifo-0005oM-Ga). --=20 Postmaster Gmane gmane.org MailScanner thanks transtec Computers for their support --OtherAccess Content-Type: text/plain; charset="ISO-8859-1"; name="Gmane-Attachment-Warning.txt" Content-Disposition: attachment; filename="Gmane-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Fri Feb 11 22:50:26 2005 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/= quarantine/20050211 (message 1Czifo-0005oM-Ga). --=20 Postmaster Gmane gmane.org MailScanner thanks transtec Computers for their support --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 Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: TDM interface parameters ... Date: Fri, 11 Feb 2005 16:52:10 -0700 Lines: 7 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Sat Feb 12 01:04:58 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: "PWE3 WG (E-mail)" X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Sasha/Yakov, Can you please give me a list of what PW types the TDM interface parameters apply to ? Thanks. Luca From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Seung Yeop Yang Subject: RE: Re: I-D ACTION: draft-martini-pwe3-MH-PW-requirements-00.txt Date: Sun, 13 Feb 2005 02:37:59 -0800 (PST) Lines: 186 References: <000301c50eb7$7f2e4530$a1922799@mcilink.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0117330573==" X-From: pwe3-bounces@ietf.org Sun Feb 13 11:40:42 2005 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ziedQJGsxBbMOVVz0YKidh8+spDAyYVQKufvub3wdg8kYsk/XT6ugLZv7UtkeJpBI7Dg8NAVuDogZf+GyHBoJBKdaXJjnXqCUQor+dMlC9QXX2whzHoGVdTr39+7DyMLmNk3wv4JhqrLs4jgunCJkYSV2s4qg6djGSUhhytlsZI= ; To: "'PWE3 WG $E-mail$'" In-Reply-To: <000301c50eb7$7f2e4530$a1922799@mcilink.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org --===============0117330573== Content-Type: multipart/alternative; boundary="0-262613930-1108291079=:48264" --0-262613930-1108291079=:48264 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA11781 Hi- How about putting PW protection switching requirements in the document?=20 ++++++++++++++++++++++++++++++++++++++++++++++++++++++=20 6.7 Protection Switching Requirements =20 As PWE3 can provide a transport service for carrier L2 services, it is re= quired that PWE3 should provide =93carrier-class=94 availability.=20 High availability can be achieved through 1) increasing mean time between= failure (MTBF), 2) decreasing mean time to repair (MTTR), or providing r= edundancy such as protection switching.=20 =20 This PW protection switching is to apply primarily to the situations wher= e a underlying PSN protection switching does not exist or does not fulfil= l the condition of availability that is supposed to be provided by each e= mulated service. =20 PW protection switching should be independent from underlying PSN=92s fau= lt recovery procedures, but can coexist or corporate with them. =20 PW protection switching can provide a 1+1 or an m:n type protection. =20 PW protection switching can protect a complete multi-hop PW (MH-PW) or th= e segment of it. =20 PW protection switching may use PW OAM procedures to detect failures or s= ervice degradataions, or to switching to protecting entities for end-to-e= nd or segment of MH-PW. =20 PW protection switching may provide revertive and non-revertive switching. =20 PW protection switching does not preclude lockout of protection or forced= switching by operator. =20 PW protection switching may provide =93hold-off=94 time to delay beginnin= g of the protection action. =20 PW protection switching can provide hitless protection switching. ++++++++++++++++++++++++++++++++++++++++++++++++++++++=20 Regards, Seung Yeop. =09 --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' --0-262613930-1108291079=:48264 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA11781

Hi-

How about putting PW protection switching requirements in the doc= ument?

++++++++++++++++++++++++++++++++++++++++++++++++++++++ =

6.7 Protection Switching Requirements

As PWE3 can provide a transport service for carrier L2 = services, it is required that PWE3 shou= ld provide =93carrier-class=94 availability.

High availability can be achieved through 1) increasing= mean time between failure (MTBF), 2) d= ecreasing mean time to repair (MTTR), or providing redundancy such as protection switching.

This PW protection switching is to apply primarily to t= he situations where a underlying PSN protection switching does not exist = or does not fulfill the condition of availability that is supposed to be = provided by each emulated service.

PW protection switching should be independent from unde= rlying PSN=92s fault recovery procedures, but can coexist or corporate wi= th them.

PW protection switching can provide a 1+1 or an m:n typ= e protection.

PW protection switching can protect a complete multi-hop PW (MH-PW) or the segment = of it.

PW protection switching may use PW OAM procedures to de= tect failures or service degradataions, or to switching to protecting ent= ities for end-to-end or segment of MH-PW.

PW protection switching may provide revertive and non-r= evertive switching.

PW protection switching does not preclude lockout of pr= otection or forced switching by operator.

PW protection switching may provide =93hold-off=94 time= to delay beginning of the protection action.

PW protection switching can provide hitless protection = switching.

+++++++++++++++++++++++++++++++++++++++++++= +++++++++++

Regards,

Seung Yeop.

Do you Yahoo!?
=20 Yahoo! Search presents - Jib Jab's 'Se= cond Term' --0-262613930-1108291079=:48264-- --===============0117330573== 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 --===============0117330573==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: [Fwd: AD review of draft-ietf-pwe3-cw-01.txt] Date: Mon, 14 Feb 2005 10:43:33 +0000 Lines: 121 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Mon Feb 14 11:48:00 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: pwe3 , George Swallow X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org The following AD review comments were recently received WRT draft-ietf-pwe3-cw-01.txt Stewart ==================================================================== Document could be tighter. Some of the stuff here might be more appropriate in PW-specific documents. Not sure. Need to rereview in conjunction with other documents. expand abbreviations in abstract. > The standard MPLS encapsulations have no explicit protocol > identifier. In order for a pseudo wire (PW) [ARCH] to operate > correctly over an MPLS packet switched network (PSN) that performs > deep packet inspection, a PW packet must not appear to the LSR as if > it were an IP packet [BCP]. An example of an LSR that performs deep Is "deep packet inspection" defined somewhere? I don't see the word "deep" in the cited document. > though the PSN. This may result in misordered packet deliver to the > egress PE. The inability to ensure that all packets belonging to a s/deliver/being delivered/? > All IP packets [RFC791][RFC1883] start with a version number that is > checked by LSRs performing deep packet inspection. To prevent the > incorrect inspection of packets, PW packets carried over an MPLS PSN > SHOULD NOT start with the value 4 (IPv4) or the value 6 (IPv6) in > the first nibble [BCP]. Better (?): To prevent the incorrect processing of packets carried within a PW, PW packets carried over an MPLS PSN SHOULD NOT start with the value 4 (IPv4) or the value 6 (IPv6) in the first nibble [BCP], as those are assumed to carry normal IP. > When a PW-CW is used, it SHOULD have the following preferred form: s/SHOULD/has/ This document should just say this is how it is done. If something else is done, its not a PW-CW anymore. > These bits are available for per payload signalling. Their s/per payload/per-payload/ > FRG (bits 8 and 9): > > These bits are used when fragmenting a PW payload. Their use > is defined in [FRAG] which is currently work in progress. FRAG is listed as a normative reference. I suspect that is not what is desired (nor is it required). > If the MPLS > payload is between 46 bytes and 63 bytes the implementation > MAY either set to the length of the MPLS payload, or it MAY > set it to 0. > > Note to the reader: In the definition above, both the MUSTs > are needed to make the mechanism work, the MAY provides > backwards compatibility with deployed systems. Is this really what is needed? Seems like the spec should be saying. The sender MUST or SHOULD set it to (pick one or the other), but (and this is what is critical) on receipt should be prepared to handle _either_ value. That is what gives you interoperability. Or, if you want new implementation to work with old, than say the SHOULD (or MAY) also support sending a 0, but that this should be configurable??? Or something. Kind of depends on what you are trying to acheive. Is it interoperability with implementations that send a 0? Or those that expect 0 on receipt and don't handle the "correct" value? > If the sequence number is not used, it is set to zero by the > sender and ignored by the receiver. Otherwise it specifies > the sequence number of a packet. A circular list of sequence > numbers is used. A sequence number takes a value from 1 to > 65535 (2**16-1). The sequence number window size for packet > acceptance is dependent on the parameters of the PSN, and > SHOULD be configurable. The mechanism used by the > decapsulating PE to (re)acquire the correct sequence number > is implementation dependent. when you say "should be configurable" and "implementation dependent", is it really the case that this is PW-specific, with the details defined in those docs? IANA considerations for all these documents need to be synced up, as there are redundencies > 6. Security Considerations > > An application using this mechanism to provide an OAM [VCCV] or > other message channel MUST be aware that this can potentially be which mechanism does "this mechanism" refer to? > If a PW has been configured to operate without a CW, the PW > Associated Channel Type mechanism described in the document MUST NOT > be used. This is to prevent user payloads being fabricated in such a > way that they mimic the PW Associated Channel header, and thereby > provide a method of attacking the application that is using the > Associated Channel. what does "MUST NOT be used" mean? Is there a way to _prevent_ it from being used? > 10. Normative References I suspect many, if not most, of these references should be informative. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: TDM interface parameters ... Date: Mon, 14 Feb 2005 10:39:39 -0700 Lines: 74 References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Yaakov Stein $E-mail$'" , "'PWE3 WG $E-mail$'" X-From: pwe3-bounces@ietf.org Mon Feb 14 18:44:55 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: Sasha Vainshtein In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Actually my sendmail daemon had died ... However , can we be more specific ? example: does PW type 0x0011 use interface parameters 0x04 and 0x05 ? ( CEM [8] Payload Bytes, CEM options ) ? Luca Sasha Vainshtein wrote: >Luca and all, >Re-sending - looks like this message was not delivered. > >Regards, > Sasha Vainshtein >email: sasha@axerra.com >phone: +972-3-7569993 (office) >fax: +972-3-6487779 >mobile: +972-52-8674833 > > > > >>-----Original Message----- >>From: Sasha Vainshtein >>Sent: Saturday, February 12, 2005 6:00 PM >>To: 'Luca Martini' >>Cc: PWE3 WG (E-mail); Yaakov Stein (E-mail) >>Subject: RE: [PWE3] TDM interface parameters ... >> >> >>Luca, >>As far as I am concerned the TDM interface parameter applies >>to the following >>PW types: >> >> 0x0011 Structure-agnostic E1 over Packet (SAToP) >> 0x0012 Structure-agnostic T1 (DS1) over Packet (SAToP) >> 0x0013 Structure-agnostic E3 over Packet (SAToP) >> 0x0014 Structure-agnostic T3 (DS3) over Packet (SAToP) >> 0x0015 CESoPSN basic mode >> 0x0016 TDMoIP basic mode >> 0x0017 CESoPSN TDM with CAS >> 0x0018 TDMoIP TDM with CAS >> >>Yaakov, what do you think? >> >>Regards, >> Sasha >> >> >> >>>-----Original Message----- >>>From: Luca Martini [mailto:lmartini@cisco.com] >>>Sent: Saturday, February 12, 2005 1:52 AM >>>To: PWE3 WG (E-mail) >>>Subject: [PWE3] TDM interface parameters ... >>> >>> >>>Sasha/Yakov, >>> >>>Can you please give me a list of what PW types the TDM interface >>>parameters apply to ? >>> >>>Thanks. >>>Luca >>> >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: TDM interface parameters ... Date: Tue, 15 Feb 2005 01:18:23 -0800 (PST) Lines: 83 Reply-To: sasha@axerra.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1623943227==" Cc: sasha@axerra.com X-From: pwe3-bounces@ietf.org Tue Feb 15 10:21:30 2005 To: pwe3@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org --===============1623943227== Content-Type: multipart/alternative; boundary="0-794274500-1108459103=:58257" --0-794274500-1108459103=:58257 Content-Type: text/plain; charset=us-ascii Hi all, It looks as if my normal mailer canot reach pwe3@ietf.org. Re-sending the answers I've sent to Luca using my personal account: Luca, As far as I am concerned the TDM interface parameter applies to the following PW types: 0x0011 Structure-agnostic E1 over Packet (SAToP) 0x0012 Structure-agnostic T1 (DS1) over Packet (SAToP) 0x0013 Structure-agnostic E3 over Packet (SAToP) 0x0014 Structure-agnostic T3 (DS3) over Packet (SAToP) 0x0015 CESoPSN basic mode 0x0016 TDMoIP basic mode 0x0017 CESoPSN TDM with CAS 0x0018 TDMoIP TDM with CAS Yaakov, what do you think? Regards, Sasha Regards, Sasha Vainshtein email: sasha@axerra.com sashavainshtein@yahoo.com phone: +972-3-7659993 (office) +972-52-8674833 (mobile) --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' --0-794274500-1108459103=:58257 Content-Type: text/html; charset=us-ascii
Hi all,

It looks as if my normal mailer canot reach pwe3@ietf.org.

Re-sending the answers I've sent to Luca using my personal account:

Luca,

As far as I am concerned the TDM interface parameter applies to the following PW types:

0x0011 Structure-agnostic E1 over Packet (SAToP)

0x0012 Structure-agnostic T1 (DS1) over Packet (SAToP)

0x0013 Structure-agnostic E3 over Packet (SAToP)

0x0014 Structure-agnostic T3 (DS3) over Packet (SAToP)

0x0015 CESoPSN basic mode

0x0016 TDMoIP basic mode

0x0017 CESoPSN TDM with CAS

0x0018 TDMoIP TDM with CAS

Yaakov, what do you think?

Regards,

Sasha

Regards,
Sasha Vainshtein
email: sasha@axerra.com
sashavainshtein@yahoo.com
phone: +972-3-7659993 (office)
+972-52-8674833 (mobile)

Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term' --0-794274500-1108459103=:58257-- --===============1623943227== 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 --===============1623943227==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Yaakov Stein" Subject: RE: TDM interface parameters ... Date: Tue, 15 Feb 2005 13:41:25 +0200 Lines: 142 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "PWE3 WG $E-mail$" X-From: pwe3-bounces@ietf.org Tue Feb 15 12:45:36 2005 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] TDM interface parameters ... Thread-Index: AcUTRSpd3zJiv+tTTfiwOTClhkn49gADf0RQ To: "Sasha Vainshtein" , "Luca Martini" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org =20 We have (once again) forgotten the TDMoIP AAL2 mode (Y.1414). We need a PW type for that too. Y(J)S > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 > Sent: Tuesday, February 15, 2005 11:53 > To: 'Luca Martini' > Cc: Yaakov Stein; 'PWE3 WG (E-mail)' > Subject: RE: [PWE3] TDM interface parameters ... >=20 > Luca and all, > Here are the detailed answers based on > draft-vainshtein-pwe3-tdm-control-protocol-extensi-01.txt > (the draft has expired, I shall re-submit it later this week): >=20 > ------------------------------------------------------------- > PW Type | =20 > =20 > |----------------------------------- > |CEP/TDM |CEP/TDM |TDM Options | > |Payload |bit-rate | | > |Bytes | | | > |(0x04) |(0x07) | (0x0B | > -------------------------|----------|----------|------------| > 0x0011 SAToP - E1 |Mandatory |Optional |Optional | > 0x0012 SAToP - DS1 |Mandatory |Optional |Optional | > 0x0013 SAToP - E3 |Mandatory |Optional |Optional | > 0x0014 SAToP - DS3 |Mandatory |Optional |Optional | > 0x0015 CESoPSN basic |Mandatory |Mandatory |Optional | > 0x0016 TDMoIP basic |Mandatory |Mandatory | ??? | > 0x0017 CESoPSN with CAS |Mandatory |Mandatory |Mandatory | > 0x0018 TDMoIP with CAS |Mandatory |Mandatory | ??? | > ------------------------------------------------------------- >=20 > Yaakov, any ideas as how to fill in the question marks? >=20 > Regards, > Sasha Vainshtein > email: sasha@axerra.com=20 > > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 >=20 >=20 > > -----Original Message----- > > From: Luca Martini [mailto:lmartini@cisco.com] > > Sent: Monday, February 14, 2005 7:40 PM > > To: Sasha Vainshtein > > Cc: 'Yaakov Stein (E-mail)'; 'PWE3 WG (E-mail)' > > Subject: Re: [PWE3] TDM interface parameters ... > > > > > > Actually my sendmail daemon had died ... > > However , can we be more specific ? > > example: does PW type 0x0011 use interface parameters 0x04=20 > and 0x05 ? > > ( CEM [8] Payload Bytes, CEM options ) ? > > > > Luca > > > > Sasha Vainshtein wrote: > > > > >Luca and all, > > >Re-sending - looks like this message was not delivered. > > > > > >Regards, > > > Sasha Vainshtein > > >email: sasha@axerra.com > > > > >phone: +972-3-7569993 (office) > > >fax: +972-3-6487779 > > >mobile: +972-52-8674833 > > > > > > > > >=20 > > > > > >>-----Original Message----- > > >>From: Sasha Vainshtein > > >>Sent: Saturday, February 12, 2005 6:00 PM > > >>To: 'Luca Martini' > > >>Cc: PWE3 WG (E-mail); Yaakov Stein (E-mail) > > >>Subject: RE: [PWE3] TDM interface parameters ... > > >> > > >> > > >>Luca, > > >>As far as I am concerned the TDM interface parameter=20 > applies to the=20 > > >>following PW types: > > >> > > >> 0x0011 Structure-agnostic E1 over Packet (SAToP) > > >> 0x0012 Structure-agnostic T1 (DS1) over Packet (SAToP) > > >> 0x0013 Structure-agnostic E3 over Packet (SAToP) > > >> 0x0014 Structure-agnostic T3 (DS3) over Packet (SAToP) > > >> 0x0015 CESoPSN basic mode > > >> 0x0016 TDMoIP basic mode > > >> 0x0017 CESoPSN TDM with CAS > > >> 0x0018 TDMoIP TDM with CAS > > >> > > >>Yaakov, what do you think? > > >> > > >>Regards, > > >> Sasha > > >> > > >> =20 > > >> > > >>>-----Original Message----- > > >>>From: Luca Martini [mailto:lmartini@cisco.com] > > >>>Sent: Saturday, February 12, 2005 1:52 AM > > >>>To: PWE3 WG (E-mail) > > >>>Subject: [PWE3] TDM interface parameters ... > > >>> > > >>> > > >>>Sasha/Yakov, > > >>> > > >>>Can you please give me a list of what PW types the TDM=20 > interface=20 > > >>>parameters apply to ? > > >>> > > >>>Thanks. > > >>>Luca > > >>> > > >>>_______________________________________________ > > >>>pwe3 mailing list > > >>>pwe3@ietf.org > > >>>https://www1.ietf.org/mailman/listinfo/pwe3 > > >>> > > >>> =20 > > >>> > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Seung Yeop Yang Subject: Re: I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt Date: Tue, 15 Feb 2005 07:04:27 -0800 (PST) Lines: 131 References: <200502112032.PAA06366@ietf.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0127599012==" X-From: pwe3-bounces@ietf.org Tue Feb 15 16:08:56 2005 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=i3tE4zorEx2qUIN9EVSW6MY1tgvevnhpR2it1GaZVeh9em+JfMkM/+zgavfp5fyPeMpqQ/faXxERMTUGCZEZPaiIVv2Vv9P52TplAdFUZ8F9jnMfATAFqM4/GUmfub8KGhYVWY1wB4dkkuqQBmlt+PA9e+hCVNCfoVGvdsN7fTU= ; To: pwe3@ietf.org In-Reply-To: <200502112032.PAA06366@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org --===============0127599012== Content-Type: multipart/alternative; boundary="0-1061711935-1108479867=:41461" --0-1061711935-1108479867=:41461 Content-Type: text/plain; charset=us-ascii Hi all, I have a quick question for below (from Appendix A). ============================================================ RFC 1990 was designed for use in environments where packet fragments may arrive out of order due to their transmission on multiple parallel links, specifying that buffering be used to place the fragments in correct order. For PWE3, the ability to reorder fragments prior to reassembly is OPTIONAL; receivers MAY choose to drop frames when a lost fragment is detected. ============================================================ It looks like that the pwe3 fragmentation I-D excluded any fragment reordering case. Does it mean that it needs another I-D for Multilink Pseudo-Wire?, or it mean that Multilink PW is not necessary in PWE3? Regards, Seung Yeop. Internet-Drafts@ietf.org wrote:A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Fragmentation and Reassembly Author(s) : A. Malis, M. Townsley Filename : draft-ietf-pwe3-fragmentation-08.txt Pages : 14 Date : 2005-2-11 This document defines a generalized method of performing fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) protocols and services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-08.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-fragmentation-08.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-fragmentation-08.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. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1061711935-1108479867=:41461 Content-Type: text/html; charset=us-ascii

Hi all,

I have a quick question for below (from Appendix A).

============================================================

RFC 1990 was designed for use in environments where packet
    fragments may arrive out of order due to their transmission on
    multiple parallel links, specifying that buffering be used to place
    the fragments in correct order. For PWE3, the ability to reorder
    fragments prior to reassembly is OPTIONAL; receivers MAY choose to
    drop frames when a lost fragment is detected.

============================================================

It looks like that the pwe3 fragmentation I-D excluded any fragment reordering case. Does it mean that it needs another I-D for Multilink Pseudo-Wire?, or it mean that Multilink PW is not necessary in PWE3?

Regards,

Seung Yeop.

Internet-Drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

Title : PWE3 Fragmentation and Reassembly
Author(s) : A. Malis, M. Townsley
Filename : draft-ietf-pwe3-fragmentation-08.txt
Pages : 14
Date : 2005-2-11

This document defines a generalized method of performing
fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3)
protocols and services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-08.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.
Yo u 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-fragmentation-08.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-fragmentation-08.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 de! aling 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.
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-1061711935-1108479867=:41461-- --===============0127599012== 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 --===============0127599012==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "W. Mark Townsley" Subject: Re: I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt Date: Tue, 15 Feb 2005 11:09:47 -0500 Lines: 117 References: <20050215150428.42083.qmail@web53406.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Feb 15 20:30:47 2005 Return-path: X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,85,1107752400"; d="scan'208"; a="37049161:sNHT22532516" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en To: Seung Yeop Yang In-Reply-To: <20050215150428.42083.qmail@web53406.mail.yahoo.com> X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org Seung Yeop Yang wrote: > Hi all, > > I have a quick question for below (from Appendix A). > > ============================================================ > > RFC 1990 was designed for use in environments where packet > fragments may arrive out of order due to their transmission on > multiple parallel links, specifying that buffering be used to place > the fragments in correct order. For PWE3, the ability to reorder > fragments prior to reassembly is OPTIONAL; receivers MAY choose to > drop frames when a lost fragment is detected. > > ============================================================ > > It looks like that the pwe3 fragmentation I-D excluded any fragment > reordering case. Does it mean that it needs another I-D for > Multilink Pseudo-Wire?, or it mean that Multilink PW is not > necessary in PWE3? We were not trying to enable multilink PWs with this draft. It is strictly a workaround for MTU issues. Fragment reordering may be detected on a single PW by using the PW's native packet sequencing mechanism. - Mark > > Regards, > > Seung Yeop. > > > > > > */Internet-Drafts@ietf.org/* wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Pseudo Wire Emulation Edge to Edge > Working Group of the IETF. > > Title : PWE3 Fragmentation and Reassembly > Author(s) : A. Malis, M. Townsley > Filename : draft-ietf-pwe3-fragmentation-08.txt > Pages : 14 > Date : 2005-2-11 > > This document defines a generalized method of performing > fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) > protocols and services. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-08.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-fragmentation-08.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-fragmentation-08.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 de! aling 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. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Andrew G. Malis" Subject: Re: I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt Date: Tue, 15 Feb 2005 12:05:13 -0500 Lines: 323 References: <200502112032.PAA06366@ietf.org> <20050215150428.42083.qmail@web53406.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2113273980==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Feb 15 20:52:28 2005 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: Seung Yeop Yang In-Reply-To: <20050215150428.42083.qmail@web53406.mail.yahoo.com> References: <200502112032.PAA06366@ietf.org> <20050215150428.42083.qmail@web53406.mail.yahoo.com> X-Spam-Score: 3.6 (+++) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org --===============2113273980== Content-Type: multipart/alternative; boundary="=====================_253480185==.ALT" --=====================_253480185==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Seung Yeop, If the PW control word sequence number is used, then you have the same capabilities that are found in RFC 1990 and you can effectively have multilink PWs. Typically that would be implemented through the use of multilink traffic tunnels, rather than any additional mechanisms in the pseudowire encapsulation or signaling. Cheers, Andy ----------- At 2/15/2005 07:04 AM -0800, Seung Yeop Yang wrote: >Hi all, > >I have a quick question for below (from Appendix A). > >============================================================ > >RFC 1990 was designed for use in environments where packet > fragments may arrive out of order due to their transmission on > multiple parallel links, specifying that buffering be used to place > the fragments in correct order. For PWE3, the ability to reorder > fragments prior to reassembly is OPTIONAL; receivers MAY choose to > drop frames when a lost fragment is detected. > >============================================================ > >It looks like that the pwe3 fragmentation I-D excluded any fragment >reordering case. Does it mean that it needs another I-D for Multilink >Pseudo-Wire?, or it mean that Multilink PW is not necessary in PWE3? > >Regards, > >Seung Yeop. > > > > > >Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Pseudo Wire Emulation Edge to Edge >Working Group of the IETF. > >Title : PWE3 Fragmentation and Reassembly >Author(s) : A. Malis, M. Townsley >Filename : draft-ietf-pwe3-fragmentation-08.txt >Pages : 14 >Date : 2005-2-11 > >This document defines a generalized method of performing >fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) >protocols and services. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-08.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-fragmentation-08.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-fragmentation-08.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 de! aling 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. >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 --=====================_253480185==.ALT Content-Type: text/html; charset="us-ascii" Seung Yeop,

If the PW control word sequence number is used, then you have the same capabilities that are found in RFC 1990 and you can effectively have multilink PWs. Typically that would be implemented through the use of multilink traffic tunnels, rather than any additional mechanisms in the pseudowire encapsulation or signaling.

Cheers,
Andy

-----------

At 2/15/2005 07:04 AM -0800, Seung Yeop Yang wrote:

Hi all,

I have a quick question for below (from Appendix A).

============================================================

RFC 1990 was designed for use in environments where packet

    fragments may arrive out of order due to their transmission on

    multiple parallel links, specifying that buffering be used to place

    the fragments in correct order. For PWE3, the ability to reorder

    fragments prior to reassembly is OPTIONAL; receivers MAY choose to

    drop frames when a lost fragment is detected.

============================================================

It looks like that the pwe3 fragmentation I-D excluded any fragment reordering case. Does it mean that it needs another I-D for Multilink Pseudo-Wire?, or it mean that Multilink PW is not necessary in PWE3?

Regards,

Seung Yeop.

Internet-Drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

Title : PWE3 Fragmentation and Reassembly

Author(s) : A. Malis, M. Townsley

Filename : draft-ietf-pwe3-fragmentation-08.txt

Pages : 14

Date : 2005-2-11

This document defines a generalized method of performing

fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3)

protocols and services.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-08.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-fragmentation-08.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-fragmentation-08.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 de! aling 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.

_______________________________________________

pwe3 mailing list

pwe3@ietf.org

https://www1.ietf.org/mailman/listinfo/pwe3

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
--=====================_253480185==.ALT-- --===============2113273980== 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 --===============2113273980==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Seung Yeop Yang Subject: Re: I-D ACTION:draft-ietf-pwe3-fragmentation-08.txt Date: Tue, 15 Feb 2005 11:02:53 -0800 (PST) Lines: 283 References: <6.2.1.2.2.20050215115514.0761c220@mail.comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0724564942==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Feb 15 21:14:24 2005 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=LCQa8UV0uNg2m8RjFy3K5s5BRrd5Czc5r/ZGO00RdkLoL7O1QimiPUgNssT6KhtsMapSeOz4v7iom3ssPPRclGICyJExB8c4QAYJXzMlbTAhBe3PZpXDgOLCfsumlREOlgq0Ku9BHVUoQ7OwZWjjyBqfsqoZxjXsue7/OYyZ8wU= ; To: "Andrew G. Malis" In-Reply-To: <6.2.1.2.2.20050215115514.0761c220@mail.comcast.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org --===============0724564942== Content-Type: multipart/alternative; boundary="0-2053561851-1108494173=:65644" --0-2053561851-1108494173=:65644 Content-Type: text/plain; charset=us-ascii Thank you, Mark and Andy. Please, let me ask you another question. As this fragmentation document is related only MTU-issue, then it's the function of PWE3 demultiplexer layer as described in PWE3 architecture I-D, and multilink PW should be carried on PW encapsulation layer. Is my understanding correct? Then PW-CW is used for reassembly in demux layer, is it still valid to be used for PW encapsulation layer? Then where is the PW-CW termination layer, is it demultiplexer layer or encapsulation or both? Regards, Seung Yeop. "Andrew G. Malis" wrote: Seung Yeop, If the PW control word sequence number is used, then you have the same capabilities that are found in RFC 1990 and you can effectively have multilink PWs. Typically that would be implemented through the use of multilink traffic tunnels, rather than any additional mechanisms in the pseudowire encapsulation or signaling. Cheers, Andy ----------- At 2/15/2005 07:04 AM -0800, Seung Yeop Yang wrote: Hi all, I have a quick question for below (from Appendix A). ============================================================ RFC 1990 was designed for use in environments where packet fragments may arrive out of order due to their transmission on multiple parallel links, specifying that buffering be used to place the fragments in correct order. For PWE3, the ability to reorder fragments prior to reassembly is OPTIONAL; receivers MAY choose to drop frames when a lost fragment is detected. ============================================================ It looks like that the pwe3 fragmentation I-D excluded any fragment reordering case. Does it mean that it needs another I-D for Multilink Pseudo-Wire?, or it mean that Multilink PW is not necessary in PWE3? Regards, Seung Yeop. Internet-Drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Fragmentation and Reassembly Author(s) : A. Malis, M. Townsley Filename : draft-ietf-pwe3-fragmentation-08.txt Pages : 14 Date : 2005-2-11 This document defines a generalized method of performing fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) protocols and services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-08.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-fragmentation-08.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-fragmentation-08.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 de! aling 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. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-2053561851-1108494173=:65644 Content-Type: text/html; charset=us-ascii
Thank you, Mark and Andy.

Please, let me ask you another question.

As this fragmentation document is related only MTU-issue, then it's the function of PWE3 demultiplexer layer as described in PWE3 architecture I-D, and multilink PW should be carried on PW encapsulation layer.

Is my understanding correct?

Then PW-CW is used for reassembly in demux layer, is it still valid to be used for PW encapsulation layer?

Then where is the PW-CW termination layer, is it demultiplexer layer or encapsulation or both?

Regards,

Seung Yeop.

"Andrew G. Malis" <andymalis@comcast.net> wrote:

Seung Yeop,

If the PW control word sequence number is used, then you have the same capabilities that are found in RFC 1990 and you can effectively have multilink PWs. Typically that would be implemented through the use of multilink traffic tunnels, rather than any additional mechanisms in the pseudowire encapsulation or signaling.

Cheers,
Andy

-----------

At 2/15/2005 07:04 AM -0800, Seung Yeop Yang wrote:

Hi all,

I have a quick question for below (from Appendix A).

============================================================

RFC 1990 was designed for use in environments where packet

    fragments may arrive out of order due to their transmission on

    multiple parallel links, specifying that buffering be used to place

    the fragments in correct order. For PWE3, the ability to reorder

    fragments prior to reassembly is OPTIONAL; receivers MAY choose to

    drop frames when a lost fragment is detected.

============================================================

It looks like that the pwe3 fragmentation I-D excluded any fragment reordering case. Does it mean that it needs another I-D for Multilink Pseudo-Wire?, or it mean that Multilink PW is not necessary in PWE3?

Regards,

Seung Yeop.

Internet-Drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

Title : PWE3 Fragmentation and Reassembly

Author(s) : A. Malis, M. Townsley

Filename : draft-ietf-pwe3-fragmentation-08.txt

Pages : 14

Date : 2005-2-11

This document defines a generalized method of performing

fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3)

protocols and services.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-08.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-fragmentation-08.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-fragmentation-08.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 de! aling 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.

_______________________________________________

pwe3 mailing list

pwe3@ietf.org

https://www1.ietf.org/mailman/listinfo/pwe3

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-2053561851-1108494173=:65644-- --===============0724564942== 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 --===============0724564942==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: [Fwd: Re: PWE3 drafts] Date: Tue, 15 Feb 2005 16:58:46 -0700 Lines: 596 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Wed Feb 16 01:07:33 2005 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en To: "PWE3 WG (E-mail)" X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ce9c9805f9fd7f2a8e6eb8268c6b0fc Content-Transfer-Encoding: 7bit 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: , Sender: pwe3-bounces@ietf.org Errors-To: pwe3-bounces@ietf.org X-MailScanner-From: pwe3-bounces@ietf.org X-MailScanner-To: ietf-pwe3@gmane.org Wg, Here are the AD review comments , and my answers. Note that I also removed the text duplication in the IANA section of the control protocol document. ( also present in the iana allocation document ) Luca Thomas Narten wrote: [snip] > >I've reviewed the document. Here are my comments on it: > >High-level comments/questions > >Uses LDP; has the (appropriate) LDP WG looked at this? Would this be >MPLS? They need to sign off on this document, since it uses LDP. > > it was presented to them 4 years ago and we had no objections.... If you tell me how to get the official sign off I will pursue it. >I think draft-ietf-pwe3-iana-allocation-07.txt has been superceded by >events. Since control is now going forward, we don't need the separate >document. Indeed, the control document still has its own IANA >considerations (which is presumably old/incorrect). Get one version, >and I suspect it might as well just be in the control document. > > They are in sync ( no allocation information is duplicated ). I put the creation of the new IANA PWE3 specific registries in the control document for completeness. ( I hate documents that are hard to read , and point to too many references ... ) The only direct allocation suggestion to IANA are the LDP related codes. Note that there are no PWE3 allocations made in the control document. PWE3 allocation are in the "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)" document only. >The security section is week. Bottom line, what security is mandatory >to implement, should operators want to turn it on. I see only a >MAY. IESG will surely want a "MUST implement (optional to use)" in the >spec. > > The WG did not express any interest in this section. So myself and Eric wrote what is in the draft right now. I will make appropriate changes, as you suggest. >The document really needs a short overview of how the setup protocol >works. We can probably hammer this out pretty quickly (i.e., the >protocol seems to be pretty simple) > > This was more text there , but got pulled. It is still in the nroff source , I can easily put it back. >There are a bunch of normative references to other documents that > >aren't ready, and we probably _don't_ want the control document >dependent on them. In an ideal world, I would expect: > > 1) a control document that describes how to set up PWs > > 2) PW-specific documents, that explain the details specific to a > type of PW. That would include encapsulation, _plus_ any service > specific requirements. > > Actually the way it is subdivided right now fits several documents. The encapsulation documents do not have setup/control protocol related details in them as they are used by L2VPN WG documents that create PW services using BGP and no LDP signaling protocol. I agree that we could pull the text that references the encapsulation document, and move the reference to informative. ( would an informative reference block this document ? ) Still I believe that the control protocol details of the service belong in this document. We need something that glues this together as follows: control doc. atm encap doc control doc iana doc. "ATM AAL5 SDU VCC Transport" -> encapsulation ATM SDU mode -> Pw type description ->PW type 0x0002 >What I think has been done is have PW-specific encapsulation drafts, >but put some of the PW-service specific stuff in the control >document. That doesn't seem right. I.e, the control document >shouldn't need to have a normative reference to the TDM spec saying >how one does things. My assumption is that we should just move some >text that is in the control documents into the appropriate PW document. > >Detailed comments: > > >> is an MPLS label. Thus the packets which are transmitted from one end >> of the pseudowire to the other are MPLS packets must be transmitted >> through a PSN tunnel, however if the pseudowire endpoints are >> immediately adjacent, the PSN tunnel may not be necessary. Any sort >> > >doesn't parse. > > >> sort of tunnel which can carry MPLS packets. Procedures for setting >> up and maintaining the PSN tunnels are outside the scope of this >> document. >> > >do you mean "for setting up ... other than MPLS tunnels ..." ??? >I.e., isn't this document about LDP setting up MPLS tunnels (even if >you don't call them "tunnels")? > > PSN tunnels == MPLS LSP == MPLS tunnels no, this document is about setting up PWs. MPLS tunnels get setup with RSVP-TE , or LDP or .... Which one do you want me to use ? >> This document deals only with the setup and maintenance of point to >> point pseudowires. Neither point to multipoint nor multipoint to >> point pseudowires are discussed. >> >> > >should be point-to-point above. > > ID nits script barfs on it. If stewart stops complaining ;-) I'll put it back ... >> Note that the PW label must always be at the bottom of the packet's >> label stack and labels MUST be allocated from the per-platform label >> space. >> > >what does "per-platform" mean? > > Labels can be unique per interface , or per platform ( maybe per-PE is better ? ) >> In addition to the protocol specified herein, static assignment of PW >> labels MAY be used, and implementations of this protocol SHOULD >> provide support for static assignment. >> > >lower case MAY? (Its not an implementation MAY, but a user MAY. The >SHOULD is the advice to the implementor...) > > yes, my mistake. >>4.1. Frame Relay >> >> When emulating a frame relay service, the Frame Relay PDUs are >> encapsulated according to the procedures defined in [FRAME]. The PE >> MUST provide Frame Relay PVC status signaling to the Frame Relay >> network. If the PE detects a service-affecting condition for a >> particular DLCI, as defined in [ITUQ] Q.933 Annex A.5 sited in IA >> FRF1.1, the PE MUST communicate to the remote PE the status of the PW >> corresponds to the frame relay DLCI. The Egress PE SHOULD generate >> the corresponding errors and alarms as defined in [ITUQ] on the >> egress Frame relay PVC. There are two frame relay flags to control >> word bit mappings described in [FRAME]. The legacy bit ordering >> scheme will be used for a PW of type "Frame Relay DLCI ( Martini Mode >> )", while the new bit ordering scheme will be used for a PW of type >> "Frame Relay DLCI". >> > >Is the reference to FRAME normative? > > Yes. To build the PW service the frame-relay document needs to be normative. >Also, for "the PE MUST communicate...", what is the actual procedure >for doing that and where is it defined? > > In this document , in the PW status TLV/message section. >What would maybe help here is to talk about "ports" (?) so one can >talk about (say for PE1) which link/port is the FR one and which is >the PW, and then indicate on which port/link one is talking about. > > Let discuss this on a conf call. I'm not sure I understand the question. >> mode allows for concatenation ( grouping ) of multiple cells into a >> > >In several places, you have parenthesis with unneeded spaces. > > > Ha , editorial preferences ... I'll fix it. >> OPTIONAL for transmission at the ingress PE, PE1. If the Egress PE >> PE2 supports cell concatenation the ingress PE, PE1, MUST only >> > >s/concatenation/concatenation,/ > > fixed. >>4.2.4. OAM Cell Support >> >> OAM cells MAY be transported on the PW LSP. When the PE is operating >> in AAL5 CPCS-SDU transport mode if it does not support transport of >> ATM cells, the PE MUST discard incoming MPLS frames on an ATM PW LSP >> that contain a PW label with the T bit set [ATM]. When operating in >> AAL5 SDU transport mode an PE that supports transport of OAM cells >> using the T bit defined in [ATM], or an PE operating in any of the >> cell transport modes MUST follow the procedures outlined in [ATM] in >> addition to the applicable procedures specified in [ITUG]. >> > >Note: I'm a bit concerned that the above language really is making >normative references to the ATM document. Is that desired/necessary? >This may not be a problem, but it also means that this document can't >be published until the other ones are done. > >Shouldn't much of this sort of text be in the ATM-specific document? > > I think that this should be the last document published , or just go together with all the other encap documents. >>4.3. Ethernet Tagged Mode >> >> The Ethernet frame will be encapsulated according to the procedures >> in [ETH] tagged mode. It should be noted that if the VLAN identifier >> is modified by the egress PE, according to the procedures outlined >> above, the Ethernet spanning tree protocol might fail to work >> properly. If the PE detects a failure on the Ethernet physical port, >> or the port is administratively disabled, it MUST send PW status >> notification message for all PWs associated with the port. This mode >> uses service-delimiting tags to map input ethernet frames to >> respective PWs. >> > >Again, the above sure sounds like PWE3 Ethernet requires something >w.r.t. tagging. > there are 2 modes defined in the ethernet draft , this just select tagged mode encapsulation for this PW type. >Not sure what the second sentence refers to when >saying "outlined above". > > indeed , a long forgotten remnant for the draft-martini .... "outlined above"==[ETH] reference I'll fix it. >> Ethernet input port, or the port is administratively disabled, the PE >> MUST send a corresponding PW status notification message. >> > >Send it where? (presumably the other PE, but better to be explicit. > ok, will fix it. > >>4.5. HDLC and PPP >> >> HDLC and PPP frames are encapsulated according to the procedures in >> [PPPHDLC]. If the MPLS edge PE detects that the physical link has >> failed, or the port is administratively disabled, it MUST send a PW >> status notification message that corresponds to the HDLC or PPP PW. >> > >Is this section still needed? i.e., what document is this reference >to? > > PPP/HDLC PWs , it is actually one of the documents in your queue to read. ( or at least it should be ) >>4.6. IP Layer2 Transport >> >> This mode carries IP packets over a Pseudo-Wire. The encapsulation >> used is according to [RFC3032]. The PW control word MAY be inserted >> between the MPLS stack and the IP payload. IP interworking is >> implementation specific, part of the NSP function [ARCH], and is >> outside the scope of this document. >> >> > >What is this? > > This is the IP PW mode that we discussed. We "switch" IP packet in a PW, with just the IP header... Note that this is not a PW type that I came up with .... >> The PW label bindings are distributed using the LDP downstream >> unsolicited mode described in [LDP]. The PEs will establish an LDP >> session using the Extended Discovery mechanism described in [1, >> section 2.4.2 and 2.5]. >> > >What is this reference? > > Ha , a forgotten reference ... it's should be [LDP, section 2.4.2 and 2.5]. >> The Generalized ID FEC Element not contain anything corresponding to >> the "group id" of the PWid FEC element. The functionality of the >> > >doesn't parse > > yes , fixed. >> This document does not specify the SAII,TAII,AGI type field values; >> specification of the type field values to use for a particular >> application is part of the specification of that application. IANA >> will assign these values based on IETF consensus. >> > >Where are these defined, for say, ethernet? Also, move the last >sentence to an IANA considerations section... > > nowhere . This is actually a bug in the document I realized only a few weeks ago that we need to create a registry for these. On this subject.... I will move all registry creation to the iana document and just reference it here. >> remote PEs MUST implement support for wildcard messages. If the PW >> Grouping ID is not going to be used for wild card messages, it MAY be >> omitted. This TLV MAY only be used when sending the Generalized PW ID >> FEC. >> > >Both MAYs are suspect. The last one for sure. (are these >implementation MAYs?) > > second MAY is broken. I will change it to a MUST. the first MAY in my opinion is also broken ... the problem is that we MUST implement receiving this TLV but then we say we say it MAY be omitted. I will just remove the sentence. "If the PW Grouping ID is not going to be used for wild card messages, it MAY be omitted." >>5.3.1. Use of Label Mappings. >> >> The PEs MUST send PW label mapping messages to their peers as soon as >> the PW is configured and administratively enabled, regardless of the >> CE-facing interface state. The PW label should not be withdrawn >> unless the user administratively configures the CE-facing interface >> down (or the PW configuration is deleted entirely). Using the >> procedures outlined in this section a simple label withdraw method >> MAY also be supported as a primitive means of signaling PW status. It >> is strongly RECOMMENDED that the PW status signaling procedures below >> be fully implemented. In any case if the Label mapping is not >> available the PW MUST be considered in the down state. >> > >Hmm. Is all of 5.3 really optional (i.e, just SHOULD?) why not just >MUST and be done with it? Is this for backwards compatability or >something? > > yes. All implementations I know of , we not use that status TLV messaging yet. >> - Interface MTU >> > >This is a new "Parameter ID". This document should say that >explicitely, e.g., by saying the "Parameter ID is 1", and its symbolic >value is "Interface MTU". Might as well give the length here >too. I.e., some of what you have in the IANA considerations section >should just be here. > >Same comment applies to all the Parameter ID values. > > yes the length is actually give n in the text, along with the description... the length should probably not be in the IANA anyway.... IANA does not allocate storage ;-) >> - Payload Bytes >> >> A 2 octet value indicating the number of TDM payload octets >> contained in all packets on the CEM stream, from 48 to 1,023 >> octets. All of the packets in a given CEM stream have the same >> number of payload bytes. Note that there is a possibility that >> the packet size may exceed the SPE size in the case of an STS-1 >> SPE, which could cause two pointers to be needed in the CEM >> header, since the payload may contain two J1 bytes for >> consecutive SPEs. For this reason, the number of payload bytes >> must be less than or equal to 783 for STS-1 SPEs. >> > >So, is this only relevant to the TDM PW? If so, wouldn't it be better >to define this in the document that has TDM specific things in it? > > This needs to remain here so the the TDM PW document can be used with other control protocols, and does not get a normative reference back to here. >General: it would be good to list which PWs a Parameter ID is relevant >to. > > Yes we do , it's listed by PW type. > >> - CEP Options. >> >> An optional 16 Bit value of CEM Flags. See [8] for the definition >> of the bit values. >> > >what is [8] (indeed, fix all references with numeric citations). > > another miss of my regular expression search and replace ;-) will fix it. >> - Requested VLAN ID. >> >> An Optional 16 bit value indicating the requested VLAN ID. This >> parameter MUST be used by a PE that is incapable of rewriting the >> 802.1Q ethernet VLAN tag on output. If the ingress PE receives >> this request, it MUST rewrite the VLAN ID tag at the input to >> match the requested VLAN ID. If this is not possible, and the >> VLAN ID does not already match the configured ingress VLAN ID, >> the PW MUST not be enabled. This parameter is applicable only to >> PW type 4. >> > >sure sounds like munging VLAN tags are a part of PWE ... > > > or the interface ..... ;-) the point of interface parameters is to make sure that the PW endpoints are compatible so that we can actually establish a PW without doing any kind of Interworking function in the PW. >> An optional 16 bit value indicating the lenght of the frame-relay >> > >spelling. > > fixed >> As mentioned above the Group ID field of the PWid FEC element, or the >> > >s/above/above,/ > > fixed >> As mentioned above the Group ID field of the PWid FEC element, or the >> PW Grouping ID TLV used with the Generalized ID FEC element, can be >> used to withdraw all PW labels associated with a particular PW group. >> This procedure is OPTIONAL, and if it is implemented the LDP label >> withdraw message should be as follows: If the PWid FEC element is >> used, the PW information length field is set to 0, the PW ID field is >> not present, and the interface parameters field is not present. If >> the Generalized FEC element is used, the AGI, SAII, and TAII are not >> present,the PW information length field is set to 0, the PW Grouping >> ID TLV is included, and the Interface Parameters TLV is omitted. For >> the purpose of this document this is called the "wild card withdraw >> procedure", and all PEs implementing this design are REQUIRED to >> accept such withdrawn message, but are not required to send it. Note >> that the PW Grouping ID TLV only applies to PW using the Generalized >> ID FEC element, while the Group ID only applies to PWid FEC element. >> > >please clarify what is optional. Is it optional to implement on the >sender side? (well, OK, but that isn't something this document needs >to say, if there is an alternate way of achieving the same >results). Is it Required that everyone implement processing the >receipt of the message? (and if so, why is it necessary to make it >optional to send??) > > So this feature is kind of controversial. The reason for it is to have quick status messaging in case a port or hole card goes down. However it has not been popular in implementations. We would like to leave it in , and remove it in the standards process if it will never get implemented. >note: this document really would benefit from a one page overview of >what the protocol does. > > Ha we had that , but it was removed . I could write something back in the beginning of the document. Let discuss this on the phone >> release message MUST include only the group ID, or Grouping ID TLV. A >> Label Release message initiated from the imposition router must >> always include the PW ID. >> > >what is an "imposition router"???? > > == input >ditto for "disposition router". > > == output oops - cisco terminology will change it. > >> This document uses two new FEC element types, 128 and 129. IANA >> already maintains a registry of values of the "FEC Type Name Space" >> for the Label Distribution Protocol (LDP RFC3036). In that registry, >> values in the range 128-191 are assignable on a First Come, First >> Served basis. IANA should assign values 128 and 129 from that space >> as specified in this document. >> > >In the IANA considerations section, please remove all wording saying >what the assignment policy is you are asking for a code point >from. IANA knows what policy is in effect (and it might change >later...). Just say what namespace and the value needed. That >suffices. > > fixed >>7.4. Pseudowire Type >> >> IANA needs to set up a registry of "Pseudowire Type". These are 15- >> >> > >This text is duplicated in the other iana document... > >Note: I didn't read these carefully. Let's first figure out which text >is the definitive text... > > >> When a MPLS PSN is used to provide pseudowire service, there is a >> perception that security MUST be at least equal to the currently >> > >"there is a perception" is pretty poor wording, as it can easily be >read to mean the authors don't really think security is important. > > >> The three main security problem faced when using an MPLS network to >> > >s/problem/problems/ > > fixed >> transport PWs are spoofing, alteration, and inspection. First there >> is a possibility that the PW receive endpoint will get a PDU which >> appears to be from the PE encapsulating the PW into the PSN, but >> which was not actually transmitted by the PE originating the PW. >> > >"PW receive endpoint"?? can this be reworded? > > >> For a greater degree of security, the LDP MD5 authentication key >> option, as described in section 2.9 of RFC 3036, MAY be used. This >> > >seems like this should be "MUST be implemented, may be used by >operator". > I should not change the rfc3036 definition , ( which I think already specifies the MD5 Key ) but the MAY should be a may instead ... ok ?