Subject: RE: Proposed new working group draft

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 3 Oct 2007 18:40:37 +0200

adrian   

- support - 

-d.
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Saturday, September 29, 2007 2:32 PM
> To: [email-masked]
> Subject: Proposed new working group draft
> 
> Hi,
> 
> Now that the MLN requirements and protocol evaluation have 
> completed last 
> call with just a couple of comments, and now that we have 
> more or less 
> reached stability with our liaisons to the ITU-T on this 
> subject, we need to 
> look for a solutions I-D.
> 
> http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-
> gmpls-mrn-extensions-04.txt 
> has been running for some time and tracking both the 
> requirements and the 
> lacunae identified by the evaluation draft. It seems that 
> this provides a 
> good basis for the protocol work in CCAMP even if some elements might 
> change.
> 
> Please express your support or otherwise for this I-D to 
> become a WG draft.
> 
> Thanks,
> Adrian 
> 
> 
> 
>

---

From: Kohei Shiomoto <[email-masked]>
Date: Thu, 04 Oct 2007 15:49:37 +0900

Hi,

Yes, I agree to make it WG document.

Kohei

> Hi,
> 
> Now that the MLN requirements and protocol evaluation have completed 
> last call with just a couple of comments, and now that we have more or 
> less reached stability with our liaisons to the ITU-T on this subject, 
> we need to look for a solutions I-D.
> 
> http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-mrn-extensions-04.txt 
> has been running for some time and tracking both the requirements and 
> the lacunae identified by the evaluation draft. It seems that this 
> provides a good basis for the protocol work in CCAMP even if some 
> elements might change.
> 
> Please express your support or otherwise for this I-D to become a WG draft.
> 
> Thanks,
> Adrian
> 
> 
> 
>

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 04 Oct 2007 09:49:09 +0200

Adrian,

I do support this I-D.

martin

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Thu, 4 Oct 2007 09:53:42 +0200

Hi all.

I support this ID which deserves its WG status.

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel

Hi,

Now that the MLN requirements and protocol evaluation have completed last 
call with just a couple of comments, and now that we have more or less 
reached stability with our liaisons to the ITU-T on this subject, we need to 
look for a solutions I-D.

http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-mrn-extensions-04.txt 
has been running for some time and tracking both the requirements and the 
lacunae identified by the evaluation draft. It seems that this provides a 
good basis for the protocol work in CCAMP even if some elements might 
change.

Thanks,
Adrian

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 4 Oct 2007 09:59:45 +0200

Hi Adrian, all

I strongly support this ID, I'm co-author :-)

Regards

JL 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Martin Vigoureux
> Envoyé : jeudi 4 octobre 2007 09:49
> À : [email-masked]
> Cc : [email-masked]
> Objet : Re: Proposed new working group draft
> 
> Adrian,
> 
> I do support this I-D.
> 
> martin
> 
> 
> Adrian Farrel a écrit :
> > Hi,
> > 
> completed 
> http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-mr
> > n-extensions-04.txt has been running for some time and 
> tracking both 
> > the requirements and the lacunae identified by the 
> evaluation draft. 
> > It seems that this provides a good basis for the protocol work in 
> > CCAMP even if some elements might change.
> >

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 04 Oct 2007 17:17:03 +0900

Yes, I support.

Ichiro

 >> Adrian Farrel a 馗rit :

---

From: "FUJIHARA Kazuhiro" <[email-masked]>
Date: Thu, 04 Oct 2007 19:20:07 +0900

Hi,

I support this ID.

Kazuhiro

On Sat, 29 Sep 2007 13:31:38 +0100

-- 
FUJIHARA Kazuhiro

---

From: Young Lee <[email-masked]>
Date: Thu, 04 Oct 2007 08:47:40 -0500

I support this I-D. 

Young 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Saturday, September 29, 2007 7:32 AM
To: [email-masked]
Subject: Proposed new working group draft

Hi,

http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-mrn-exte
nsions-04.txt 
has been running for some time and tracking both the requirements and the 
lacunae identified by the evaluation draft. It seems that this provides a 
good basis for the protocol work in CCAMP even if some elements might 
change.

Thanks,
Adrian

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 4 Oct 2007 11:17:14 -0400

- Support - 

Thanks

Regards... Zafar  

> requirements and 
> become a WG 
> > draft.

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 04 Oct 2007 12:57:54 -0700

I support this becoming a WG draft.   I think those interested in 
VCAT/LCAS will also be interested in the advertising of adaptation 
capabilities mentioned in the draft.

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: Tomonori TAKEDA <[email-masked]>
Date: Fri, 05 Oct 2007 10:00:05 +0900

Support

Tomonori

call with just a couple of comments, and now that we have more or less 
reached stability with our liaisons to the ITU-T on this subject, we need 
to look for a solutions I-D.
has been running for some time and tracking both the requirements and the 
lacunae identified by the evaluation draft. It seems that this provides a 
good basis for the protocol work in CCAMP even if some elements might change.

---

From: "Itaru Nishioka" <[email-masked]>
Date: Fri, 5 Oct 2007 17:01:17 +0900

I support this draft.

Thanks,
Itaru.
/=======================================
/ Itaru Nishioka  
/ e-mail:[email-masked] 
/ Tel. +81-44-396-3287 ext. 8-22-72647 
/ System Platforms Research Labs. 
/ NEC Corporation 
/======================================= 

> Sent: Saturday, September 29, 2007 9:32 PM
> To: [email-masked]
> completed last call with just a couple of comments, and now 
> that we have more or less reached stability with our liaisons 
> to the ITU-T on this subject, we need to look for a solutions I-D.
> 
> requirements and the lacunae identified by the evaluation 
> draft. It seems that this provides a good basis for the 
> protocol work in CCAMP even if some elements might change.
>

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 05 Oct 2007 17:04:37 +0200

Hello,

I support progressing this document as WG draft,
for the same reasons as mentioned by Greg.

Cheers, Huub.

Greg Bernstein wrote:
=====================

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: "NIGER Philippe RD-RESA-LAN" <[email-masked]>
Date: Mon, 8 Oct 2007 08:49:25 +0200

Hi,

I support this I-D as WG draft.

Philippe.

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 08 Oct 2007 16:07:14 -0700

Hi all looking at the MRN extensions draft I've got two specific 
examples of "adaptation" I'd like to understand how to encode.
(a) SDH/SONET VCAT higher order (VC-3, VC-4) only supported
(b) SDH/SONET finer granularity switching capability. For example the 
ability to pull VT1.5, VT2 our of VC-3/VC-4 switch them and possibly 
pack them in.

Currently the draft has:

    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  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   | Switching Cap |   Encoding    | Switching Cap |   Encoding    |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                  Max LSP Bandwidth at priority 0              |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
  ---snip---
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                  Max LSP Bandwidth at priority 7              |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |        Adaptation Capability-specific information             |  
   |                  (variable)                                   |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

In both the cases mentioned above the Switching Cap (1 and 2) would be 
the same TDM, similarly the encoding types in both (1 and 2) would be SDH.
So what would be in the Adaptation Capability specific info field?

Also, to get from SDH to Ethernet via VCAT and GFP (or whatever) would 
require multiple adaptations would those be represented in a single 
stack within the Adaptation Capability specific info field?

Regards

Greg B.

---

From: Eiji Oki <[email-masked]>
Date: Tue, 09 Oct 2007 20:49:14 +0900

Support.

Eiji

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 10 Oct 2007 10:07:42 +0200

Dear Greg,

both of your (a) and (b) examples correspond to operations
performed within a switching capability (i.e. TDM-SC)
while the sub-TLV here defined is designed and intended
to be used for cross-region operations, i.e. when passing
from a given switching capability to a different one.
"Adaptation" here describes a transition (from SCx to SCy with x!=y)
capability.

hope it clarifies.

best regards,

Greg Bernstein a écrit :
>    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    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    | 
> Switching Cap |   Encoding    | Switching Cap |   Encoding    |

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Oct 2007 14:58:34 +0100

Hi,

Definitely good support for this. Thanks.

Authors, please submit as draft-ietf-ccamp-gmpls-mln-extensions-00.txt

Thanks,
Adrian

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 10 Oct 2007 08:23:42 -0700

Hi Martin, I thought that multi-layer would also be supported in 
addition to multi-region...  Typically VCAT is used as part (but needs 
other adaptations such as GFP or POS) to get from a higher layer such as 
IP or Ethernet into the SDH server layer. It seems like we need a 
systematic way to describe multiple adaptations without having to 
describe all possible permutations. Hence I thought a list of supported 
adaptations whether between regions or layers would be more efficient.
Also, for TDM hierarchies, I'd really want to know which ports have 
access to a finer granularity fabric and which don't. What would be 
wrong with having adaptations within a region?  Its done all the time in 
the data plane.

Regards

Greg B.

Martin Vigoureux wrote:
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In 
>> both the cases mentioned above the Switching Cap (1 and 2) would be 
>> Also, to get from SDH to Ethernet via VCAT and GFP (or whatever) 
>> would require multiple adaptations would those be represented in a 
>> single stack within the Adaptation Capability specific info field?
>>
>> Regards
>>
>> Greg B.
>>
>> Adrian Farrel wrote:
>>> Hi,
>>>
>>> last call with just a couple of comments, and now that we have more 
>>> or less reached stability with our liaisons to the ITU-T on this 
>>> subject, we need to look for a solutions I-D.
>>>
>>> has been running for some time and tracking both the requirements 
>>> and the lacunae identified by the evaluation draft. It seems that 
>>> this provides a good basis for the protocol work in CCAMP even if 
>>> some elements might change.
>>>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 10 Oct 2007 10:40:08 -0700 (PDT)

Hi,

I completely agree with Greg. As far as adaptation capability is concerned there should be no difference between:
a) server and client layers belong to different regions;
b) server and client layer belong to the same region

Igor

Greg Bernstein <[email-masked]> wrote: Hi Martin, I thought that multi-layer would also be supported in 

Regards

Greg B.

       
---------------------------------
Yahoo! oneSearch: Finally,  mobile search that gives answers, not web links.