Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFEF21F853D; Wed, 11 Jul 2012 21:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8+caJ3aTNEL; Wed, 11 Jul 2012 21:28:34 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id BF1A621F8534; Wed, 11 Jul 2012 21:28:33 -0700 (PDT) Received: from [85.158.143.35:61968] by server-3.bemta-4.messagelabs.com id AB/0F-05808-1925EFF4; Thu, 12 Jul 2012 04:29:05 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1342067344!16515552!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 21391 invoked from network); 12 Jul 2012 04:29:04 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-14.tower-21.messagelabs.com with SMTP; 12 Jul 2012 04:29:04 -0000 X-AuditID: a8571402-b7f116d0000051b6-71-4ffe4e2df43a Received: from FRIDWPPCH001.ecitele.com (Unknown_Domain [10.1.16.52]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 97.95.20918.D2E4EFF4; Thu, 12 Jul 2012 06:10:21 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 12 Jul 2012 06:29:03 +0200 From: Alexander Vainshtein To: Gregory Mirsky Thread-Topic: [mpls] Doubts in allocation of a new G-ACH type for Thread-Index: AQHNX3sSiCn3X34i4EqIXHysnGrWUpckVUkBgABrAmCAAE5VBQ== Date: Thu, 12 Jul 2012 04:29:03 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA0209A4F2FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa2wMURh159GdVoexrfZ2IzG58YjHsuuVRbdRVWyidrVNiFDG7rU77M6u nfWohNQrqGoIf2yISouutyLqFbFBaFL8KKmlDVpplBJFqEeZ6VBNxPw69zvn+865M98wpH6P zsCIUggHJcGL4hKoBNDLYDTO7rSbNt9JsrQ0FwNL7HCEtpS2n6emkDO/fnoYN7OiooNwEPOL QLogSf6QEMK8C8tOK3IExVWCsxDxosuKzIgPeAUn9mEpZEVCIIAlF8pI4P950hWZKPFYcvpd ouS2Ilue3WixjJ9oNKOMfI8o89joE0Qv78OyLLgxr1TUyJJr8SnSUx55qwts3wLWRJrf0UVg 64piEM9AbhwsaW2L03AKfNB4WsEJjJ6rAfDy2xZaO1QAeL+jjlJVcZwVVh1v6OpI5kzwyZGj pCoiuXIA68qekCqRxE2B0Z0HaE2UCffeeENpeCq8XFJLqJjiBsOfpZ+69CyXA082fNNpbhEC nqg/3yWK5+bBtovtOhUDJd/nmhNddZJLhbHmg4SWm4MVV++TGu4PXzV10hoeCM9daKI1vR/e rY7qNLN+8O6+ZkrTpMEblfXULpAS7jE23KMl3KNFq5vgu3sHSQ2PgEcOvf6NR8OzH2tBz3oZ 0B0DcHqubdoshyNvqsk0ZlR2li0/e1b2qCx7ThVQ9qhybjJRDTY9NkcBxwCUyDLHftj1tLBK LvRFQRpDoP5snaPTru+zxO8q9AiyZ1FwpRfLUQAZEiWzY7IUjnUJhWtx0P+Hylbe7m7S0Nvp Vz9/aNFYk+n/B5TKFuRm2PWcW1nQ5RgHcPDPnAEMgyB7Z45i0S+I3XjNUtEb+ksTTLwaI1GJ EVU1rBwQfLLo1vgaMILZ3xKLAab8WmMM6CnJL2FDKntLlXKq1LNS6p7WClKV6yex5SqbqKxt 95xWxYJQLMoOf1ctlN+omzIUAfbmcl2ZvOv95pNfPhQbA01oWMq2XIc3sz3lUmmxtcpmyxoS rly9Ycdk2Tj00fXQS7DgddSSeW9dzN/59Hbfh7tfTJw0v/7zMhypzRtbcMX+HIWc+YOKIuGN 8c/MuWltNFiS3/jI8nxIQwcfW/DAvL6gOmdkwULrjAnpaSX0ijMtiJI9gnk4GZSFX486HTgm BAAA Cc: Mishael Wexler , "mpls@ietf.org" , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: Re: [PWE3] [mpls] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 04:28:36 -0000 --_000_F9336571731ADE42A5397FC831CEAA0209A4F2FRIDWPPMB001ecite_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Greg, Lots of thanks for a prompt and highly informative response! Regards, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Thursday, July 12, 2012 2:04 AM To: Alexander Vainshtein Cc: mpls@ietf.org; Mishael Wexler; pwe3 (pwe3@ietf.org); Rotem Cohen Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for Hi Sasha, if one is interested only in CC monitoring on bi-directional p2p LSP in coor= dinated mode, then, IMHO, use PW-ACH ecapsulation is as good as MPLS-TP CC c= ode point. In Section 3.3 of RFC 6428 I read (apologies for a lengthy quote): "CC and CV operations are simultaneously employed on a maintenance entity (ME) within a single BFD session. The expected usage is that normal operation is to send CC BFD protocol data units (PDUs) interleaved with a CV BFD PDU (augmented with a Source MEP-ID and identified as requiring additional processing by the different ACh channel types)." Yes, though there is no MUST or even CAN but I'd interpret it as SHOULD. At= the same time MPLS-TP CC ACh MAY be used, by mutual agreement between the e= nd points, as CC only, without expectation of CV messages. AFAIK, http://too= ls.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08 supports explic= it CC and CC/CV configuration. Regards, Greg ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 10:30 AM To: Gregory Mirsky; David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org)= ; Rotem Cohen Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for Greg, Lots of thanks for a prompt response. Regarding your first point - ability to maintain independent BFD sessions fo= r associated unidirectional LSPs: Do you imply that, as far as co-routed bid= irectional LSPs are concerned, G-ACh Type =3D 7 is as good as G-ACh Type =3D= 22? As for ability to deduce from receiving something with G-ACh Type =3D 22 tha= t you should be also reqdy to receive something with G-ACh Type =3D 23 (CV),= I do not think that this is explicitly specified anywhere. From my point of= view, ability to support CV MUST be explicitly synchronized between the LSP= endpoints (by configuration or signaling). My 2c, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Wednesday, July 11, 2012 5:37 PM To: Alexander Vainshtein; David Allan I; swallow@cisco.com; jdrake@juniper.n= et Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org)= ; Rotem Cohen Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for Dear Sasha, et al., I think that one of differences between CC defined in RFC 5885 and RFC 6428= in introduction of independent mode to monitor associated bi-directional p2= p connections. Then there's FSMs fo coordinated and independent modes, Fig.7= and Fig.8 in RFC 6428, that are different from FSM of RFC 5880. Then, IMHO,= using G-ACh from RFC 6428 indicates possible use of RFC 6428-based CV while= there's no CV for neither Control Channel 0x07. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org)= ; Rotem Cohen Subject: [mpls] Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mess= age in RFC 6428. Looking at both this RFC and RFC 5885, i= t seems that the format of the MPLS-TP CC packet and the format of the raw B= FD packet in VCCV is exactly the same. However, two different G-ACH types ha= ve been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, es= pecially with progress of the new VCCV Type (using GAL) for PWs. The text in= Section 3.1 of 6428 that refers to existing capability to run BFD over LSP= with the G-ACh using Channel Type 7 only adds to the confusion IMO, since i= t uses un-capitalized =93may=94 and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA0209A4F2FRIDWPPMB001ecite_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

Greg,

Lots of thanks for a prompt and highly informative response!

 

Regards,

     Sasha

From: Gregory Mirsky [gregory.mirsky@ericsso= n.com]
Sent: Thursday, July 12, 2012 2:04 AM
To: Alexander Vainshtein
Cc: mpls@ietf.org; Mishael Wexler; pwe3 (pwe3@ietf.org); Rotem Cohen<= br> Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

Hi Sasha,
if one is interested only in CC mon= itoring on bi-directional p2p LSP in coordinated mode, then, IMHO, use PW-AC= H ecapsulation is as good as MPLS-TP CC code point.
In Section 3.3 of RFC 6428 I read (= apologies for a lengthy quote):
  "CC and CV operations a= re simultaneously employed on a maintenance
   entity (ME) within a single BFD session.  The expected usa= ge is that
   normal operation is to send CC BFD protocol data units (PDUs)    interleaved with a CV BFD PDU (augmented with a Source MEP-ID a= nd
   identified as requiring additional processing by the different= ACh
   channel types)."
Yes, though there is no MUST or eve= n CAN but I'd interpret it as SHOULD. At the same time MPLS-TP CC ACh MAY be= used, by mutual agreement between the end points, as CC only, without expectation of CV messages. AFAIK, http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08&n= bsp;supports explicit CC and CC/CV configuration.
 
 &nb= sp;  Regards,
 &nb= sp;      Greg
 
From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 10:30 AM
To: Gregory Mirsky; David Allan I; swallow@cisco.com; jdrake@juniper.= net
Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ie= tf.org); Rotem Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

Greg,

Lots of thanks for a prompt response.

 

Regarding your first point - ability to maintain independent BFD sessions= for associated unidirectional LSPs: Do you imply that, as far as co-routed= bidirectional LSPs are concerned, G-ACh Type =3D 7 is as good as G-A= Ch Type =3D 22?

 

As for ability to deduce from receiving something with G-ACh Type= =3D 22 that you should be also reqdy to receive something with= G-ACh Type =3D 23 (CV), I do not think that this is explicitly speci= fied anywhere. From my point of view, ability to support CV MUST be explicitly synchronized between the LSP endpoints (by= configuration or signaling).

 

My 2c,

     Sasha

From: Gregory Mirsky [gregory.mirsky@ericsso= n.com]
Sent: Wednesday, July 11, 2012 5:37 PM
To: Alexander Vainshtein; David Allan I; swallow@cisco.com; jdrake@ju= niper.net
Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ie= tf.org); Rotem Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

 
Dear Sasha, et al.,
I think that one of differences between CC defined in RFC 5885 and RFC 6428 in introduct= ion of independent mode to monitor associated bi-directional p2p connections= . Then there's FSMs fo coordinated and independent modes, Fig.7 and Fig.8 in= RFC 6428, that are different from FSM of RFC 5880. Then, IMHO, using G-ACh from RFC 6428 indicates possi= ble use of RFC 6428-based CV while there's no CV for neither Control Channel= 0x07.
 
    Regards,
        Greg

From: mpls-bounces@ietf.org [mailto:= mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; swallow@cisco.com; jdrake@juniper.net
Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ie= tf.org); Rotem Cohen
Subject: [mpls] Doubts in allocation of a new G-ACH type for

Hi all,

I have doubts regarding allocation of the G-ACH type= for the MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, it seems that the format of the MPLS-TP CC packet and the form= at of the raw BFD packet in VCCV is exactly the same. However, two different= G-ACH types have been allocated by IANA for these two cases.

 

IMHO and FWIW such duplication can only create intero= perability problems, especially with progress of the new VCCV Type (using GA= L) for PWs. The text in Section 3.1 of 6428 that refers to existing capabili= ty to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses un= -capitalized =93may=94 and not one of the IETF reserved requirement level wo= rds.

 

Clarification of intentions by the editors of RFC 642= 8 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA0209A4F2FRIDWPPMB001ecite_--