Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB07A3A68D5; Sun, 8 Aug 2010 04:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3MN348RkXJr; Sun, 8 Aug 2010 04:11:19 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id AC91B3A684C; Sun, 8 Aug 2010 04:11:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o78BBmrh026091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Aug 2010 13:11:48 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o78BBldf011020; Sun, 8 Aug 2010 13:11:48 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Aug 2010 13:11:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB36EA.7D5EE650" Date: Sun, 8 Aug 2010 13:11:44 +0200 Message-ID: <62D9AC1F11702146A0387CBFF3A8CD3D027E7568@DEMUEXC030.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Association of PSC messages to a protection path Thread-Index: Acs1RcRY1T4kxQyeTOu2eqn6OvSLKgBo8aAQ References: From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext venkatesan mahalingam" , , "mpls" X-OriginalArrivalTime: 08 Aug 2010 11:11:47.0387 (UTC) FILETIME=[7DF868B0:01CB36EA] Subject: Re: [mpls] Association of PSC messages to a protection path X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 11:11:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB36EA.7D5EE650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Venkat, hi =20 Thank you for your question - sorry for the slight delay in responding, however, I was on vacation last week. =20 Regarding your question - Yes the association of the PSC message to the protection path is via the LSP Label. In answer to your more specific questions: 1. As stated in draft-ietf-mpls-tp-data-plane (section 3.1.1) PHP MUST be disabled on MPLS-TP LSP's, therefore the situation that you describe is not relevant to MPLS-TP. As to applicability to other MPLS networks, it would need to be addressed separately. (Although I would assume that use of the control-plane protection would be more applicable.) =20 2. As stated in the draft the applicability to 1:n protection is out-of-scope for this document and should be addressed in a future document. =20 Hope this helps, yaacov =20 ________________________________ From: ext venkatesan mahalingam [mailto:venkatflex@gmail.com]=20 Sent: Friday, August 06, 2010 12:00 To: mpls-tp@ietf.org; mpls; Weingarten, Yaacov (NSN - IL/Hod HaSharon) Subject: Re: Association of PSC messages to a protection path =20 Hi, Can protection switching guys please answer the below query? Thanks, Venkat. =20 On Thu, Aug 5, 2010 at 1:05 PM, venkatesan mahalingam wrote: Hi, =20 Please clarify the below query regarding how to associate the PSC message with a protection path. =20 Below are the details. =20 Format of the PSC control message is as follows: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type =3D MPLS-TP PSC = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|Request|PT |R| Reserved | FPath | Path | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of PSC packet with a G-ACh header (draft-ietf-mpls-tp-linear-protection-02) =20 Transmission of PSC control packets: The PSC packet will be encapsulated with the MPLS label and next hop mac and will be sent over the out going interface related to the protection path. =20 Reception of PSC control packets: The PSC control packets will be 'label switched' at the intermediate LSRs (based on the protection LSP's label) and thus will reach the LER. =20 The questions are: 1) Associating PSC with protection path based on the label stack: =20 Should the LER which receives the PSC packet, associate the PSC message with the MEG/MEP corresponding to the protection LSP - based on the label stack? =20 If the answer is 'yes', then how this association be done in case if Penultimate Hop Popping (PHP) is enabled where the label in the PSC packet will be stripped off when the LER receives the PSC packet. =20 (OR) =20 Associating PSC with protection path based on the MEG/MEP in optional TLV : =20 A) Should 'Remote MEG/MEP' information of the protection LSP be sent in the 'Optional TLV' from the transmitting LER?=20 If this information is available in the PSC packet, then even if PHP is enabled, the LER will be able to associate the PSC packet with MEG/MEP and so with a protection path. =20 (OR) =20 B) 'Source MEP TLV" should be sent in the 'optional TLV' in the PSC packet ? =20 2) In case of shared protection path in 1:n architecture where n>1: Here the understanding is that one protection path is being shared by 'n' working transport paths. In this case, should the PSC message hold any additional information in the optional TLVs so as to associate the status conveyed in the PSC message against a particular working transport path ? =20 (eg) if LSP1, LSP2, LSP3 are being protected by the LSP100, then PSC messages will be transmitted on LSP100.=20 In this case, the information such as : PSC request, Fault Path (FPath), Data path (Path) exchanged in the PSC message should be for LSP1 (or) LSP2 (or) LSP3 ? Should it be discriminated by exchanging relevant information in the 'optional TLV' ? --=20 Best Regards, Venkatesan Mahalingam. --=20 Best Regards, Venkatesan Mahalingam. ------_=_NextPart_001_01CB36EA.7D5EE650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Venkat, hi

 

Thank = you for your question – sorry for the slight delay in responding, however, = I was on vacation last week.

 

Regarding your question – Yes the association of the PSC message to the = protection path is via the LSP Label.

In = answer to your more specific questions:

1. As = stated in draft-ietf-mpls-tp-data-plane (section 3.1.1) PHP MUST be disabled on = MPLS-TP LSP's, therefore the situation that you describe is not relevant to = MPLS-TP.  As to applicability to other MPLS networks, it would need to be = addressed separately.  (Although I would assume that use of the control-plane = protection would be more applicable.)

 

2. As = stated in the draft the applicability to 1:n protection is out-of-scope for this = document and should be addressed in a future = document.

 

Hope = this helps,

yaacov

 

From: ext venkatesan mahalingam [mailto:venkatflex@gmail.com]
Sent: Friday, August 06, = 2010 12:00
To: mpls-tp@ietf.org; = mpls; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: Association = of PSC messages to a protection path

 

Hi,

Can protection switching guys please answer = the below query?

Thanks,

Venkat.

 

On Thu, Aug 5, 2010 at 1:05 PM, venkatesan = mahalingam <venkatflex@gmail.com> = wrote:

Hi,

 

Please clarify the below query regarding = how to associate the PSC = message with a protection = path.

 

Below are the details.

 

Format of the PSC control message is as = follows:

 

0         = ;          1            =        2            =        3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|Version|  Reserved     |   Channel Type =3D MPLS-TP = PSC  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            =             &= nbsp; ACH TLV = Header           &= nbsp;           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~            =              Optional = TLVs           &nb= sp;           &nbs= p; ~
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver|Request|PT |R|  Reserved   |     = FPath     |     Path      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

Figure 2: Format of PSC packet with a G-ACh header = (draft-ietf-mpls-tp-linear-protection-02)

 

Transmission of PSC control = packets:

The PSC packet will be encapsulated with the MPLS = label and next hop mac and will be sent over the out going interface related to = the protection path.

 

Reception of PSC control = packets:

The PSC control packets will be ‘label = switched’ at the intermediate LSRs (based on the protection LSP’s label) and thus = will reach the LER.

 

The = questions are:

1)     =   Associating PSC with protection path based on the = label stack:

 

Should the LER which = receives the PSC packet, associate the PSC message with the MEG/MEP corresponding to = the protection LSP - based on the label = stack?

 

If the answer is ‘yes’, then how this = association be done in case if Penultimate Hop Popping (PHP) is enabled where the label in the PSC packet will be stripped = off when the LER receives the PSC packet.

 

(OR)=

    &nbs= p;

      Associating PSC with protection path based on the MEG/MEP in optional TLV = :

 

A) Should ‘Remote MEG/MEP’ information of the = protection LSP be sent in the ‘Optional TLV’ = from the transmitting LER?

If this information is = available in the PSC packet, then even if PHP is enabled, the LER will be able to = associate the PSC packet with MEG/MEP and so with a protection = path.

 

(OR)

 

B) ‘Source MEP TLV” should be sent in the ‘optional TLV’ in the PSC packet = ?

 

 2)     =   In case of shared  protection path in 1:n architecture where = n>1:

Here the understanding is = that one protection path is being shared by ‘n’ working transport = paths.

In this case, should the PSC message hold any additional = information in the optional TLVs so as to associate the status conveyed in the PSC = message against a particular working transport path = ?

 

(eg) if  LSP1, LSP2, = LSP3 are being protected by the LSP100, then PSC messages will be transmitted on = LSP100.

In this case, the = information such as : PSC request, Fault Path (FPath), Data path (Path) exchanged in the = PSC message should be for LSP1 (or) LSP2 (or) LSP3 = ?

Should it be discriminated = by exchanging relevant information in the ‘optional TLV’  = ?



--
Best Regards,
Venkatesan = Mahalingam.




--
Best Regards,
Venkatesan Mahalingam.

------_=_NextPart_001_01CB36EA.7D5EE650--