[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt-regardingISID error handling



Hi
Thanks Attila
A bit of clarification. (Hopefully)


From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On Behalf Of Attila Takacs
Sent: Monday, October 26, 2009 3:18 PM
To: choudarypally.subramanyam at wipro.com
Cc: ccamp at ietf.org
Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt-regardingISID error handling

Hi Choudarypally,
Please see inline.
Thanks and best regards,
Attila


From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On Behalf Of choudarypally.subramanyam at wipro.com
Sent: Thursday, October 22, 2009 1:51 AM
To: ccamp at ietf.org
Subject: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error handling

Hi ,

I am currently working on draft “draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt” and I write this email to seek some help from experts. I have two questions regarding the Section 3 paragraph 6.

1) It say “An IB-BEB receiving a PATH message specifying one
   of its CNPs can locally determine which CBPs have internal
   connectivity to the I-component supporting the given CNP.”

How does the CSPF function select egress CNP, based on what criteria?  

 

The CNP is the port to which clients of the PBB-TE domain are connected to. CSPF should consider which clients the Eth-LSP is meant to support. 

The Customer network port(s) CNP are the ones that are associated with the Customer Backbone Port PBB-TE MAC address.  We are really only signaling A TE service instance.  A TE service instance is supported by two point-to-point
ESPs where the ESPs' endpoints have the same CBP MAC addresses.

 

2) Further it says “On the other hand, if there is information on
   the service (I-SID) that the given ESP will support, then the IB-BEB
   MUST first determine which PIP and CBP is configured with the I-SID
   and MUST assign that CBP to the ESP”

a) What should be action taken if ISID received in PATH message is not configured? Do I need to send PATH ERR message?  

Then the ISID should be "dynamically" configured to an appropriate CBP that is connected to the CNP. 

At one point we were considering signaling I-SID information. However I believe we removed that from the document.  I-SIDs should be configured locally and should be consistent but the signaling does not carry this information.  It is purely up to the local implementation to use I-SIDs.  So multiple I-SIDs could go to several CNPs (one or more each).
b) Assuming that I have received more than one ISID and each one belong to different CBP port, in such case what should be the behavior? 

This should not happen provided the path computation and the service (ISID) allocation is done properly.

In case it would happen, one can try to reconfigure the CBP ISID allocations on the egress, if this is not possible then an error should be raised and sent in Path_Err. I couldn't find a good error value for this on the registry, if we want to account for this case explicitly we possibly need a new error value  Routing Problem / Invalid Service ID 

Since we don't signal I-SIDs I'm having a hard time parsing this scenario.

Don

 

 

 I am doing the manual configuration and association of ISID to CBP.

Regards
Choudarypally