headers
Srivatsan Raghavan | 1 Jul 2010 13:27
Favicon

Co-routed bidirectional XC entries

Hi all

RFC 4802/03 introduces the gmplsTunnelDirection object which has an additional enumeration to specify a
bidirectional tunnel.
This I assume, is used for co-routed bidirectional tunnels , independent of whether the tunnel is static or signalled.
So there is one tunnel row instance, and there is no reference as such to a remote tunnel number.
Is this understanding right ?

Secondly,
As per RFC 4803, for such a [ co-routed ] bidirectional tunnel, there are two XC entries, [for each of the directions]
Both these XC entries share the same XC index and that is how these two XC entries are co-related. In that
sense the example in RFC 4803 needs to be corrected [ it shows
two different XC indices

example below :
In mplsXCTable:

{
mplsXCIndex = 0x01,
mplsXCInSegmentIndex = 0x00000015,
mplsXCOutSegmentIndex = 0x00000012,
 ... < snip>
}

In mplsXCTable:
{
mplsXCIndex = 0x02,   ===> should also read 0x01
mplsXCInSegmentIndex = 0x00000016,
mplsXCOutSegmentIndex = 0x00000013,
.. < snip >
(Continue reading)

Permalink | Reply | 0 comments |
headers
PELOSO, PIERRE (PIERRE | 1 Jul 2010 16:54
Favicon

Proposed contribution to draft-bernstein-ccamp-wson-signaling-06

Hi ccampers and Greg,

During the latest meeting in Anaheim, I was asked to propose on the list for discussion some text dealing
with the re-introduction of wavelength metric inside the signalling draft by Greg. The wavelength
metric object is to be used inside the path message when performing LSP request.
The interest of the metric is to enrich the information collected on the wavelength availability, which
could be used to perform wavelength differentiations according varying criteria.

So here is the text that I find fitting properly the needs, it actually is a slight adaptation of the text that
was contained inside the first version of this draft:

   Distributed wavelength assignment makes extensive use of the label
   set object/TLV of [RFC3471]. Some wavelength assignment algorithms 
   require supplemental information concerning the potential lambdas to
   be used. An ordered set of TLVs in correspondence with the group of
   one or more label set TLVs can be used to convey this information in
   the form of a general wavelength "acceptability" metric.

   Note that the label set syntax of [RFC3471] allows group of
   wavelengths into ranges. For the purpose of supplementing this
   information with wavelength count only those wavelengths with the
   same counts could be grouped.

   The general format for supplemental wavelength selection information
   could be as follows:

   The information carried in a Wavelength Set Metric TLV is:

       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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lou Berger | 2 Jul 2010 16:08
Favicon

Re: please consider draft-villamizar-mpls-tp-multipath as WG item

Curtis,
	This is certainly and interesting document.  As it covers TP data plane 
functions, it really belongs in the MPLS WG and not the CCAMP WG.  I 
suggest you ask for a slot in the mpls WG as part of the MPLS-TP session.

Lou

On 6/30/2010 3:02 AM, Curtis Villamizar wrote:
> CCAMP WG,
>
> Please consider adopting draft-villamizar-mpls-tp-multipath-00 as a WG
> item.
>
> Lou, Deb,
>
> Even though this is just beyond 24 hours after you asked that time
> slots be requested, please try to fit in a short time slot at IETF78.
>
> Curtis
>
>
> ------- Forwarded Message [multiple blank lines removed]
>
> From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org]
> Sent: Tuesday, June 29, 2010 9:51 PM
> To: Curtis Villamizar
> Subject: New Version Notification for draft-villamizar-mpls-tp-multipath-00
>
> A new version of I-D, draft-villamizar-mpls-tp-multipath-00.txt has been successfully submitted by
Curtis Villamizar and posted to the IETF repository.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fatai Zhang | 5 Jul 2010 11:42
Favicon

New drafts uploaded

Hi ccampers,
 
We just submited three new drafts, which are:
 
draft-zhang-ccamp-gmpls-h-lsp-mln-00.txt
draft-zhang-ccamp-srlg-fa-configuration-00.txt
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt
 
 
Hope you can review these drafts and any comments are appreciated.
 
 

Best Regards
 
Fatai
 
 
 
 
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Permalink | Reply | 0 comments |
headers
Ashok K | 6 Jul 2010 13:14
Picon

Query on RFC-4202 (Routing Extensions in support of GMPLS)

Hi CCAMPers,

I have a question regarding the intrepretation of an illustration (pertaining to SDH ISCD) in RFC-4202 (Routing Extensions in support of GMPLS).

Refer to the following ISCD encoding example specified in the section 3.2 of RFC-4202 (Page-15):

<SNIP>

3.4.  STM-64 SDH Interface on a Digital Cross Connect with Two Types of
      SDH Multiplexing Hierarchy Supported

      Interface Switching Capability Descriptor 1:
         Interface Switching Capability = TDM [Standard SDH]
         Encoding = SDH
         Min LSP Bandwidth = VC-3
         Max LSP Bandwidth[p] = STM-64, for all p

      Interface Switching Capability Descriptor 2:
         Interface Switching Capability = TDM [Arbitrary SDH]
         Encoding = SDH
         Min LSP Bandwidth = VC-4
         Max LSP Bandwidth[p] = STM-64, for all p

   If multiple links with such interfaces at both ends were to be
   advertised as one TE link, link bundling techniques should be used.

</SNIP>


Does the above mean that the ISCDs pertaining to both VC-3 and VC-4 should be encoded if both are supported on a given interface?

Here "Switching Capability" and "Encoding type" of both the ISCDs are exactly the same. The only distinguishing attribute here is the Min-LSP-Bandwidth which is encoded as a part of "Switch Capability Specific Information". I somehow got the impression that "Switch Capability" and "Encoding type" combination should be unique for an ISCD (within Link TLV).

If the answer is Yes, Can we generalize this as follows?

TE-LSA  Link-TLV can contain multilple ISCD Sub-TLVs with same "Switching Capability" and "Encoding type" - but distinguished solely through one or more attribute(s) encoded in their "Switch Capability Specific Information".

It would be of great help if the authors/someone in the mailing-list clarifies this.

Thanks,
Ashok 
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Permalink | Reply | 1 comment |
headers
Snigdho Bardalai | 6 Jul 2010 21:59
Favicon

Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hello,

 

I have a comment and a question on Section 3.1.2.1. This section describes the link-parameters that are required for OTN service routing purposes.

 

My comment is how are we going to advertise the low-order ODUj availability within a higher-order container. For example, consider an OTU3 link which has 16 time-slots of 2.5G granularity and then we establish an ODU2 service over the link. At this point in time the OTU3 link has 12 time-slots available for ODU2 services and up to 12+4 time-slots available for ODU1 services (4 ODU1s are contained over the ODU2). So it is obvious from this example that the number of time-slots available is different based on the signal-type (i.e. ODU1 and ODU2). How do we address this issue based on the approach specified in the draft?

 

My other question is why not simply advertize the available number of ODU0, ODU1, ODU2, …, ODU4 container instances or the equivalent bandwidth in bytes/sec within a link? This approach seems to be more in-line with the general approach outlined in RFC-4202. Refer to section 3.4 in RFC 4202 for an example that shows multiple ISCDs being advertised per VC rate for an SDH link. The additional benefit is that the advertisement is TS size independent and hence will simplify the implementation.

 

Regards

Snigdho

 

 

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Permalink | Reply | 87 comments |
headers
Fatai Zhang | 7 Jul 2010 12:29
Favicon

comments requested on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi CCAMPers,
 
The requirements of multi-stage muxing for OTN networks (i.e., Data Plane) were discussed in the last SG15 plenary meeting.
 
The editors of this draft are planing to update [OTN-FWK] to reflect something about multi-stage muxing.
 
If you are interested in this topic, hope you can send the comments or suggestions to the editors or mailing list.
 
 
Best Regards
 
Fatai
 
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Permalink | Reply | 0 comments |
headers
BRUNGARD, DEBORAH A (ATTLABS | 7 Jul 2010 16:57
Picon
Favicon

Last call on draft-ietf-ccamp-mpls-tp-cp-framework-02.txt

This begins a joint ccamp and pwe3 last call on
draft-ietf-ccamp-mpls-tp-cp-framework-02.txt:
http://www.ietf.org/id/draft-ietf-ccamp-mpls-tp-cp-framework-02.txt

The last call ends on July 21, 2010 at 24:00 UTC.

Please send comments to the ccamp and pwe3 lists.

Deborah and Andy and Matthew
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Permalink | Reply | 0 comments |
headers
Lou Berger | 7 Jul 2010 17:37
Favicon

Re: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snigdho,
	I believe there has been some off-line discussion on how to better 
align the work with 4202.  Use of common approaches is of course one of 
the main objectives of *C*CAMP.  I look forward to hearing from the 
draft and discussion contributors on there progress on this point.

Lou

On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
> Hello,
>
> I have a comment and a question on Section 3.1.2.1. This section
> describes the link-parameters that are required for OTN service routing
> purposes.
>
> My comment is how are we going to advertise the low-order ODUj
> availability within a higher-order container. For example, consider an
> OTU3 link which has 16 time-slots of 2.5G granularity and then we
> establish an ODU2 service over the link. At this point in time the OTU3
> link has 12 time-slots available for ODU2 services and up to 12+4
> time-slots available for ODU1 services (4 ODU1s are contained over the
> ODU2). So it is obvious from this example that the number of time-slots
> available is different based on the signal-type (i.e. ODU1 and ODU2).
> How do we address this issue based on the approach specified in the draft?
>
> My other question is why not simply advertize the available number of
> ODU0, ODU1, ODU2, …, ODU4 container instances or the equivalent
> bandwidth in bytes/sec within a link? This approach seems to be more
> in-line with the general approach outlined in RFC-4202. Refer to section
> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
> advertised per VC rate for an SDH link. The additional benefit is that
> the advertisement is TS size independent and hence will simplify the
> implementation.
>
> Regards
>
> Snigdho
>
>
>
> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Permalink | Reply | 86 comments |
headers
Snigdho Bardalai | 7 Jul 2010 17:43
Favicon

Re: Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Hi Lou

Thanks, I also would like to hear about the same.

Snigdho

-----Original Message-----
From: Lou Berger [mailto:lberger <at> labn.net] 
Sent: Wednesday, July 07, 2010 8:37 AM
To: Snigdho Bardalai
Cc: ccamp <at> ietf.org; draft-ietf-ccamp-gmpls-g709-framework <at> tools.ietf.org
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-gmpls-g709-framework-01.txt

Snigdho,
	I believe there has been some off-line discussion on how to better 
align the work with 4202.  Use of common approaches is of course one of 
the main objectives of *C*CAMP.  I look forward to hearing from the 
draft and discussion contributors on there progress on this point.

Lou

On 7/6/2010 3:59 PM, Snigdho Bardalai wrote:
> Hello,
>
> I have a comment and a question on Section 3.1.2.1. This section
> describes the link-parameters that are required for OTN service routing
> purposes.
>
> My comment is how are we going to advertise the low-order ODUj
> availability within a higher-order container. For example, consider an
> OTU3 link which has 16 time-slots of 2.5G granularity and then we
> establish an ODU2 service over the link. At this point in time the OTU3
> link has 12 time-slots available for ODU2 services and up to 12+4
> time-slots available for ODU1 services (4 ODU1s are contained over the
> ODU2). So it is obvious from this example that the number of time-slots
> available is different based on the signal-type (i.e. ODU1 and ODU2).
> How do we address this issue based on the approach specified in the draft?
>
> My other question is why not simply advertize the available number of
> ODU0, ODU1, ODU2, ..., ODU4 container instances or the equivalent
> bandwidth in bytes/sec within a link? This approach seems to be more
> in-line with the general approach outlined in RFC-4202. Refer to section
> 3.4 in RFC 4202 for an example that shows multiple ISCDs being
> advertised per VC rate for an SDH link. The additional benefit is that
> the advertisement is TS size independent and hence will simplify the
> implementation.
>
> Regards
>
> Snigdho
>
>
>
> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Permalink | Reply | 85 comments |

Gmane