From wsopress@mail.com Fri Nov 14 21:52:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10782 for ; Fri, 14 Nov 2003 21:52:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKqY8-000121-00 for ccamp-archive@ietf.org; Fri, 14 Nov 2003 21:52:36 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AKqY7-00011x-00 for ccamp-archive@ietf.org; Fri, 14 Nov 2003 21:52:35 -0500 Received: from 200-101-176-035.mganm7005.t.brasiltelecom.net.br ([200.101.176.35] helo=ietf.org) by manatick with smtp (Exim 4.24) id 1AKqXo-00079E-8L for ccamp-archive@ietf.org; Fri, 14 Nov 2003 21:52:20 -0500 Reply-To: "ConstruNews" From: "Temas "Patrulhados"" To: ccamp-archive@ietf.org Subject: Lindenberg: opiniões "politicamente incorretas", vêm sendo marginalizadas no debate nacional ref.: rve User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 14 Nov 2003 21:52:20 -0500

sla EnEspañol - InEnglish

Temas "patrulhados"

Opiniões "politicamente incorretas" vêm sendo marginalizadas no debate nacional, diz Lindenberg

* Patrulhamento...

Em meios empresariais e religiosos continua repercutindo o livro "Os católicos e a economia de mercado", de autoria de Adolpho Lindenberg. O trabalho denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, comentários, livros, reportagens e opiniões "politicamente incorretas", não afinadas com as assim denominadas "causas sociais". Noutras palavras, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Antídoto

O antídoto para esta situação de violência psicológica e espiritual consiste na difusão - por meios alternativos, se preciso for - de informações idôneas, capazes de esclarecer a opinião pública e provocar debates construtivos. Com efeito, uma vez rompidos os anteparos da censura, cada um em seu próprio ambiente poderá, sem medo, manifestar sua opinião sobre os assuntos 'patrulhados'. É a proposta inovadora de um programa de libertação ideológica, impulsionado pela coragem, em defesa do esclarecimento popular.

* Esclarecimento!

Esse programa tem alcance prático, especialmente para os católicos. O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), que favorecem as invasões de terras promovidas pelos MST, bem como às repetidas críticas à Área de Livre Comércio das Américas (ALCA), às privatizações, à alegada ameaça das multinacionais e do capital estrangeiro, e até mesmo ao plantio de transgênicos, apresenta dois inconvenientes sérios. Em primeiro lugar, tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados. Em segundo, de que as teses da Teologia da Libertação têm fundamentos sólidos na doutrina católica. Tudo isso tem muita importância prática. Com efeito, na vasta rede de movimentos contestatários, ativa no país inteiro, a ala progressista religiosa se sobressai hoje como o setor mais ativo e mais radical nas proposições.

* Temáticas

Diante deste cenário e visando alertar a opinião pública católica, o livro acima citado procura debater as seguintes temáticas:

- Capitalismo, globalização, neoliberalismo e privatizações seriam os grandes responsáveis pelos bolsões de misérias, desigualdades sociais e dependência externa (isto é, dos Estados Unidos)?

- Os programas sociais estatais seriam a solução para combater a fome, o analfabetismo, o atraso e a indigência das classes mais pobres do Brasil?

- O materialismo, o anonimato, a exclusão social, o relacionamento burocrático entre as pessoas são causados muito especialmente pelo crescimento desordenado das cidades ou sobretudo pela descristianização de nossos hábitos?

* Informe-se!

Informe-se desses assuntos - e ainda de vários outros - no livro "Os católicos e a economia de mercado". Você pode adquiri-lo, clicando nos links abaixo. E complemente seus dados com artigos de Adolpho Lindenberg que lhe serão enviados gratuitamente (clique nos links abaixo). O autor analisa tais assuntos com base na doutrina social católica, expressa nas encíclicas: discorre sobre as relações entre a economia e a moral, liberdade e responsabilidade dos atos econômicos, direito de propriedade, respeito às leis naturais no mercado, liceidade do lucro, assistência social, relações humanas na empresa e na vida civil.

* Destaque

E, por fim, um ponto com merecido destaque em "Os católicos e a economia de mercado": como as reivindicações "sociais" têm como fim o socorro aos necessitados e a diminuição de desigualdades sociais, é indispensável ter em vista que esse objetivo só poderia ser alcançado com a elevação significativa do padrão de vida do povo (para o autor, por uma dose maior de capitalismo autêntico) e sobretudo pela recristianização da sociedade. A assistência aos necessitados deve, além do mais, sempre que possível, ter um tom pessoal, familiar, típico das sociedades orgânicas harmonicamente diferenciadas, das quais ainda se encontram reflexos vivos em antigas cidades do interior brasileiro. Ali ainda hoje subsistem hospitais, creches, asilos, de iniciativa religiosa e particular, que atendem aos necessitados de modo mais humano e eficaz que a assistência estatal prestada nas grandes metrópoles.

LINKS DE OPINIÃO:

Entre aqueles que enviarem sua valiosa opinião a respeito do texto acima, até 30 de novembro, usando qualquer um dos três links seguintes, serão sorteados 10 exemplares do livro "Os católicos e a economia de mercado". Os favorecidos serão comunicados por e-mail e deverão enviar o endereço postal para receberem os exemplares do livro, por Correio).

Lindenberg:Concordo (pode simplesmente enviar seu voto virtual, e acrescentar seu comentário caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirLivroEditora (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais SEDEX)

Lindenberg:DesejoAdquirirE-Book (para adquirir o livro, em formato Word, que será enviado por e-mail; receberá número de conta bancária para efetuar transferência; preço promocional do e-book, até 30 de novembro: R$ 8,80)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores

GratuitamenteProximosArtigos

GratuitamenteTodosOsArtigos

Para solicitar alguns títulos específicos:

Artigo1 "Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone"

Artigo2 "Moral e Economia"

Artigo3 "Assistência Social e Capitalismo não precisam estar em guerra: podem dar o abraço da paz"

Artigo4 "Intervencionismo estatal e fermentação revolucionária versus assistência particular e personalizada"

Próximos temas:

"Capitalismo, globalização, neoliberalismo, privatizações"

"Economia de Mercado, Neoliberalismo"

"Estatização da Economia"

LINK DE REMOÇÃO

ConstruNews:Remover ccamp-archive@ietf.org

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 

 

From cxjinfo@geocities.com Mon Nov 24 18:25:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10767; Mon, 24 Nov 2003 18:25:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQ4z-0000bk-00; Mon, 24 Nov 2003 18:25:17 -0500 Received: from adsl-64-218-142-244.dsl.rcsntx.swbell.net ([64.218.142.244] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AOQ4w-0000aT-00; Mon, 24 Nov 2003 18:25:16 -0500 From: "Informe Exclusivo" To: ccamp-archive@ietf.org Subject: Fórum Social Brasileiro: radiografia das esquerdas ref.: nzv X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Mon, 24 Nov 2003 18:25:16 -0500 c0311fsbavisop

epo EstaCartaEnCastellano - ThisLetterInEnglish

Amigos:

O Primeiro Fórum Social Brasileiro (FSB) efetuou-se de 6 a 9 de novembro pp. na cidade brasileira de Belo Horizonte. Organizado pelo conselho brasileiro do Fórum Social Mundial (FSM), contou com a participação de 1.200 organizações brasileiras, de 15 mil ativistas inscritos oficialmente e de outros 15 mil convidados, entre os quais, observadores de 22 países.

O importante evento, um dos maiores até aqui realizados pelas esquerdas brasileiras, passou desapercebido aos grandes meios de comunicação.

O FSB foi marcado por conferências de cunho comuno-anárquico no político, oposto à propriedade privada e a livre iniciativa; e permissivistas no moral, a favor do aborto, da homossexualidade e da "transversalidade". Constituiu uma oportunidade única para obter uma radiografia atualizada das esquerdas brasileiras, com suas novas e velhas estratégias, seus dilemas, suas utopias, suas contradições internas, seus problemas e seus temores. Uma radiografia indispensável para conhecer o que poderá passar no curto e médio prazo com o regime Lula, com o Brasil e, em boa medida, com a América do Sul.

Oferecemos-lhes gratuitamente um Informe Exclusivo, com 5 capítulos, sobre tal evento.

Cordialmente, Roberto Fernández-Lopez, Ámbito Iberoamericano, Madri.

FSB:InformeCompletoGratuito(EnCastellano)

FSB:InformeCompletoGratuito(EmPortugues)

FSB:FullReport(InEnglish)

Série Fórum Social Brasileiro: radiografia das esquerdas

(Belo Horizonte, Nov. 6-9, 2003)

 

1) FSB: radiografia das esquerdas

Importante congresso de movimentos contestátarios brasileiros passa desapercebido aos grandes meios de comunicação

2) FSB: esquerdas debatem utopias, estratégias e dilemas

Os fantasmas de governos de esquerda derrocados na América Latina ressurgem em meio de ásperos debates

3) FSB: conjuntura latino-americana e política externa lulista

Recolocar o socialismo como uma alternativa viável e derrotar os Estados Unidos são duas das metas internacionais das esquerdas no FSB

4) FSB: articulações de "esquerda católica", MST e indigenistas

Uma "nova lógica" de construção do poder, através de "redes" de ONGs, para controlar o Estado e a sociedade

5) FSB: a meta de "desconstrução" e "reinvenção" do homem e da sociedade

Uma mudança de mentalidades que afaste o mais possivel o ser humano dos Mandamentos da Lei de Deus

LINKS:

FSB:InformeCompletoGratuito(EmPortuguês)

FSB:FullReportInEnglish

FSB:InformeCompletoGratuito(EnCastellano)

FSB:MinhaOpinao

FSB:MinhaSugestao

FSB:Unsubscribe-Br

  

 

 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Nov 2003 00:35:40 +0000 Message-ID: <3FC5461C.7090800@alcatel.be> Date: Thu, 27 Nov 2003 01:32:28 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Jonathan Sadler Cc: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: Stable state on ASON signaling requirements? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed jonathan, all, see in-line Jonathan Sadler wrote: > Hi Adrian - > > Adrian Farrel wrote: > > >>You're right that developing solutions too far while requirements are not stable is a bad >>thing. >> >>However... >> >>We have had only one comment about the latest version of the requirements draft from the >>WG (in Minneapolis and on the list) suggesting that either the draft is stable or the WG >>doesn't care. (The amount of noise about the solution draft suggests the WG *does* care). > > >>So, is there any more requirements work to do, or are we at a stable state? > > > While only one comment may have been specifically logged against the document, the discussion > that has been going on regarding SPCs implicates the requirements document as not being > complete. imho comments are not logged *against*, they are logged to make progress within the scope of the wg > If the requirements were complete we wouldn't be debating: > - call addressing that allows service providers to keep network resource > names (SNPP and SNP names) and their formats private (3474 handles > this through TNA addresses, port identifier and egress label) would you clarify the functional requirement that is not currently covered in RFC 3471 that is needed to support this capability and that is not covered in the ason-requirement doc. ? [hint: support of TNA/Egress label (which includes the logical port identifier) as defined in 3474/76 is not really a functional requirement]. In other words where do you see from the current text that this capability can not be delivered ? > - the handling of SPCs through the same Call process as UNI requests > (which has implications for SPC/UNI interworking issues) would you please indicate where it has being said that the "null call" for SPC's and the call for SC's *must* be implemented as indicated in your statement ? isn't the above an implementation requirement rather than a functional requirement ? > To further amplify the separation of addressing mentioned above -- it is not the same as what > is discussed in the VPN draft. What the VPN draft provides is a way for a customer's address > space to be held separate from a single, global network address space. The separation > required by G.8080 goes further by allowing that the network address space within a network > domain be private to that domain. This means that a different network domains may have > network address spaces that: > - use different formats (potentially necessitated by the protocols being used in that > domain) section 4 intends to address this requirement - ditto: " This document provides signalling requirements for G.8080 distributed call and connection management based on GMPLS, within a GMPLS based control domain and between GMPLS based control domains. It does not restrict use of other protocols within a control domain. Interworking aspects, including mapping of non-GMPLS protocol signaling requests and support of non-GMPLS address formats, are strictly under the responsibility of the non-GMPLS control domain, and thus outside the scope of this document." > - reuses network address used in a different domain, but with different meaning > This is not discussed in the current document. please be more specific concerning the address space to which you refer and to which meanings you refer ? > Finally, it may be best to liaise the requirements document to SG12/15 for their review prior > to declaring it "stable state" and taking on solutions in the working group. It is certainly > possible that other subtle nuances of G.8080 have not been properly captured in the > requirements document. this is beyond the scope of the present discussion, liase the doc. is good thing but it doesn't preclude opening discussion on solutions > Jonathan Sadler > > > > ----------------------------------------- > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Nov 2003 21:45:23 +0000 Message-ID: <01c801c3b466$5e627300$03849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: draft-ietf-ccamp-gmpls-g709-04.txt Date: Wed, 26 Nov 2003 21:39:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, In Minneapolis we briefly raised the subject of this draft. Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control It was agreed that the draft was cooked, but it was very unclear whether there was actually any support for the contents. Could you please let me know (on or off list) whether you - have implemented or plan to implement - have deployed or plan to deploy - think its a topping idea, but won't actually use it yourself. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Nov 2003 19:30:25 +0000 Message-ID: <3FC4FEA5.6A49B04C@tellabs.com> Date: Wed, 26 Nov 2003 13:27:34 -0600 From: Jonathan Sadler MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Stable state on ASON signaling requirements? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi Adrian - Adrian Farrel wrote: > You're right that developing solutions too far while requirements are not stable is a bad > thing. > > However... > > We have had only one comment about the latest version of the requirements draft from the > WG (in Minneapolis and on the list) suggesting that either the draft is stable or the WG > doesn't care. (The amount of noise about the solution draft suggests the WG *does* care). > So, is there any more requirements work to do, or are we at a stable state? While only one comment may have been specifically logged against the document, the discussion that has been going on regarding SPCs implicates the requirements document as not being complete. If the requirements were complete we wouldn't be debating: - call addressing that allows service providers to keep network resource names (SNPP and SNP names) and their formats private (3474 handles this through TNA addresses, port identifier and egress label) - the handling of SPCs through the same Call process as UNI requests (which has implications for SPC/UNI interworking issues) To further amplify the separation of addressing mentioned above -- it is not the same as what is discussed in the VPN draft. What the VPN draft provides is a way for a customer's address space to be held separate from a single, global network address space. The separation required by G.8080 goes further by allowing that the network address space within a network domain be private to that domain. This means that a different network domains may have network address spaces that: - use different formats (potentially necessitated by the protocols being used in that domain) - reuses network address used in a different domain, but with different meaning This is not discussed in the current document. Finally, it may be best to liaise the requirements document to SG12/15 for their review prior to declaring it "stable state" and taking on solutions in the working group. It is certainly possible that other subtle nuances of G.8080 have not been properly captured in the requirements document. Jonathan Sadler ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Nov 2003 14:55:07 +0000 Message-Id: <4.3.2.7.2.20031126095216.05ed0d48@toque.cisco.com> Date: Wed, 26 Nov 2003 09:53:09 -0500 To: Kireeti Kompella , ccamp@ops.ietf.org From: Anca Zamfir Subject: Re: ASON RSVP-TE draft to WG doc Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:35 PM 11/23/2003 -0800, Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Generalized MPLS (GMPLS) >RSVP-TE Signalling in support of Automatically Switched Optical >Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is >ready to be a CCAMP WG document. This call ends Dec 7, 2003 at >midnight PST. > >A simple 'yes' or 'no' will be sufficient. yes. /Anca >Kireeti. >------- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Nov 2003 14:01:59 +0000 Message-ID: <002301c3b426$360bb640$90256497@coritel> From: "alessio d'achille" To: Subject: request of articles about "trap topology" Date: Wed, 26 Nov 2003 15:04:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C3B42E.93F35940" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C3B42E.93F35940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi to all, is there anyone who can tell me where i can find some articles or = journals about=20 the trap topology? In particular i need to find an article which demonstrate that the = problem=20 of trap topology is an effective problem in real networks. Thanks in advance Alessio D'Achille ------=_NextPart_000_001B_01C3B42E.93F35940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi to all,
 
is there anyone who can tell me where i = can find=20 some articles or journals about
the trap topology?
In particular i need to find an article = which=20 demonstrate that the problem
of trap topology is an effective = problem in real=20 networks.
 
Thanks in advance
 
Alessio = D'Achille
------=_NextPart_000_001B_01C3B42E.93F35940-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Nov 2003 13:10:30 +0000 Message-ID: <009b01c3b41e$6e4ceea0$03849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" Cc: Subject: Re: GRSVP-TE and MSSPRING Date: Wed, 26 Nov 2003 12:53:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Yes, that covers it. It is a sort of crankback. Adrian ----- Original Message ----- From: "Diego Caviglia" To: "Adrian Farrel" Cc: Sent: Wednesday, November 26, 2003 11:25 AM Subject: Re: GRSVP-TE and MSSPRING > > Hi Adrian, > some doubts about the solution you suggested arises in my mind. > > Suppose we are in the following scenario. > > | MSSPRING > | > TNE1<------>TNE2<------>TNE3<------>TNE4<------>TNE5<------>TNE6<------>TNE7<------>TNE8 > 1 1 1 > x > 2 2 2 > 2 > > TNEs 4, 5, 6, 7 and 8 are part of a MSSPRING. > Number below the Link indicates the Label availability an x indicates that > the Label is not available. > > Up to TNE 4 the signallin procedures as usual then TNE4 has to select the > UPSTREAM LABEL and it choose Label1. > > Label1 is good up to TNE 7 that refuses it (it refuses the Label1 because > it knows that is part of a MSSPRING and thus cannot change the Label, > otherwise for "normal" -"normal" menas no MSSPRING- signalling an UPSTREAM > LABEL with value 1 is good for TNE7) and issues a PathErr with > AcceptableLabelSet that indicates Label2. > > Now my concern is about who process the PathErr with the > AcceptableLabelSet. Is TNE6 is TNE1 or is TNE4? > > As far as I've understood is TNE 6. > > TNE6 removes the XC, if it created it, and propagates the PathErr Upstream. > > The Upstream propagation of the PathErr with the AccetableLabelSet is > fundamental for the procedure. > > TNE5 behave as TNE6. TNE4 now have the right information and can send out > a Path Message with Label2. Is my interpretation correct? > > If yes it seems a sort of crankback. > > Regards. > > Diego > > > > > "Adrian Farrel" on 25/11/2003 22.44.33 > > Please respond to "Adrian Farrel" > > To: , "Diego Caviglia" > cc: > > Subject: Re: GRSVP-TE and MSSPRING > > > Diego, > > I believe that if you use Label Set and Acceptable Label Set you will > arrive at the right > result. > It may take a few messages backwards and forwards to sort it out. > > Regards, > Adrian > ----- Original Message ----- > From: "Diego Caviglia" > To: > Sent: Tuesday, November 25, 2003 3:00 PM > Subject: GRSVP-TE and MSSPRING > > > > Hi all, > > MSSPRING has been defined in ITU-T G.841 and is widely used > > as inherent protection scheme in transport network (SDH). > > > > MSSPRING introduces some constraints to Label selection due to the > > impossibility to change TimeSlot (a.k.a. Label) inside a MSSPRING ring. > > > > In case of bi-directional LSP Upstream TNE has to choose the Label and > > signal it by means of the UPSTREAM Label obj but if the TNE is inside a > > MSSPRING ring it MUST choose a Label that is free on all the TNE > traversed > > by the LSP that are part of the MSSPRING ring. > > > > Of course the problem is that it does not have that information. > > > > My question is how can I signal, with GRSVP-TE, a bidirectional LSP that > > traverses an MSSPRING ring? > > > > My impression is that I can not. > > > > Any answer is welcome. > > > > Regards > > > > Diego > > > > > > > > ------------------------------------------ > > Diego Caviglia > > Marconi - Optical Networks > > ASTN/GMPLS - System Design Manager > > Via A. Negrone 1/A > > 16153 Genoa - Italy > > Phone: +390106003736 > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Nov 2003 11:28:08 +0000 Sensitivity: Subject: Re: GRSVP-TE and MSSPRING To: "Adrian Farrel" Cc: ccamp@ops.ietf.org From: "Diego Caviglia" Date: Wed, 26 Nov 2003 12:25:46 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi Adrian, some doubts about the solution you suggested arises in my mind. Suppose we are in the following scenario. | MSSPRING | TNE1<------>TNE2<------>TNE3<------>TNE4<------>TNE5<------>TNE6<------>TNE7<------>TNE8 1 1 1 x 2 2 2 2 TNEs 4, 5, 6, 7 and 8 are part of a MSSPRING. Number below the Link indicates the Label availability an x indicates that the Label is not available. Up to TNE 4 the signallin procedures as usual then TNE4 has to select the UPSTREAM LABEL and it choose Label1. Label1 is good up to TNE 7 that refuses it (it refuses the Label1 because it knows that is part of a MSSPRING and thus cannot change the Label, otherwise for "normal" -"normal" menas no MSSPRING- signalling an UPSTREAM LABEL with value 1 is good for TNE7) and issues a PathErr with AcceptableLabelSet that indicates Label2. Now my concern is about who process the PathErr with the AcceptableLabelSet. Is TNE6 is TNE1 or is TNE4? As far as I've understood is TNE 6. TNE6 removes the XC, if it created it, and propagates the PathErr Upstream. The Upstream propagation of the PathErr with the AccetableLabelSet is fundamental for the procedure. TNE5 behave as TNE6. TNE4 now have the right information and can send out a Path Message with Label2. Is my interpretation correct? If yes it seems a sort of crankback. Regards. Diego "Adrian Farrel" on 25/11/2003 22.44.33 Please respond to "Adrian Farrel" To: , "Diego Caviglia" cc: Subject: Re: GRSVP-TE and MSSPRING Diego, I believe that if you use Label Set and Acceptable Label Set you will arrive at the right result. It may take a few messages backwards and forwards to sort it out. Regards, Adrian ----- Original Message ----- From: "Diego Caviglia" To: Sent: Tuesday, November 25, 2003 3:00 PM Subject: GRSVP-TE and MSSPRING > Hi all, > MSSPRING has been defined in ITU-T G.841 and is widely used > as inherent protection scheme in transport network (SDH). > > MSSPRING introduces some constraints to Label selection due to the > impossibility to change TimeSlot (a.k.a. Label) inside a MSSPRING ring. > > In case of bi-directional LSP Upstream TNE has to choose the Label and > signal it by means of the UPSTREAM Label obj but if the TNE is inside a > MSSPRING ring it MUST choose a Label that is free on all the TNE traversed > by the LSP that are part of the MSSPRING ring. > > Of course the problem is that it does not have that information. > > My question is how can I signal, with GRSVP-TE, a bidirectional LSP that > traverses an MSSPRING ring? > > My impression is that I can not. > > Any answer is welcome. > > Regards > > Diego > > > > ------------------------------------------ > Diego Caviglia > Marconi - Optical Networks > ASTN/GMPLS - System Design Manager > Via A. Negrone 1/A > 16153 Genoa - Italy > Phone: +390106003736 > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Nov 2003 08:38:25 +0000 Subject: ASON RSVP-TE draft to WG doc - draft - dimitri To: ccamp@ops.ietf.org Cc: Kireeti@juniper.net Message-ID: From: "Ghani Abbas" Date: Wed, 26 Nov 2003 08:37:02 +0000 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" ----- Forwarded by Ghani Abbas/MAIN/MC1 on 26/11/03 08:35 ----- Ghani Abbas To: ccamp@ops.ietf.org 25/11/03 10:43 cc: Kireet@juniper.net Subject: ASON RSVP-TE draft to WG doc - draft - dimitri No. Ghani Abbas Marconi Communications Ltd., Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel. +44 115 906 4036 Fax +44 115 906 4346 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Nov 2003 08:14:28 +0000 Sensitivity: Subject: Re: GRSVP-TE and MSSPRING To: "Adrian Farrel" Cc: " From: "Diego Caviglia" Date: Wed, 26 Nov 2003 09:12:00 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi Adrian, I think you're right. Moreover seems that it is the only way to do that without enhancing the routing protocol. Regards. Diego "Adrian Farrel" on 25/11/2003 22.44.33 Please respond to "Adrian Farrel" To: , "Diego Caviglia" cc: Subject: Re: GRSVP-TE and MSSPRING Diego, I believe that if you use Label Set and Acceptable Label Set you will arrive at the right result. It may take a few messages backwards and forwards to sort it out. Regards, Adrian ----- Original Message ----- From: "Diego Caviglia" To: Sent: Tuesday, November 25, 2003 3:00 PM Subject: GRSVP-TE and MSSPRING > Hi all, > MSSPRING has been defined in ITU-T G.841 and is widely used > as inherent protection scheme in transport network (SDH). > > MSSPRING introduces some constraints to Label selection due to the > impossibility to change TimeSlot (a.k.a. Label) inside a MSSPRING ring. > > In case of bi-directional LSP Upstream TNE has to choose the Label and > signal it by means of the UPSTREAM Label obj but if the TNE is inside a > MSSPRING ring it MUST choose a Label that is free on all the TNE traversed > by the LSP that are part of the MSSPRING ring. > > Of course the problem is that it does not have that information. > > My question is how can I signal, with GRSVP-TE, a bidirectional LSP that > traverses an MSSPRING ring? > > My impression is that I can not. > > Any answer is welcome. > > Regards > > Diego > > > > ------------------------------------------ > Diego Caviglia > Marconi - Optical Networks > ASTN/GMPLS - System Design Manager > Via A. Negrone 1/A > 16153 Genoa - Italy > Phone: +390106003736 > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Nov 2003 00:32:09 +0000 From: "Vishal Sharma" To: "Adrian Farrel" , , "Diego Caviglia" Subject: RE: GRSVP-TE and MSSPRING Date: Tue, 25 Nov 2003 16:27:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Diego, Adrian, > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Adrian Farrel > Sent: Tuesday, November 25, 2003 1:45 PM > To: ccamp@ops.ietf.org; Diego Caviglia > Subject: Re: GRSVP-TE and MSSPRING > > > Diego, > > I believe that if you use Label Set and Acceptable Label Set you > will arrive at the right > result. > It may take a few messages backwards and forwards to sort it out. Or, alternatively, enhance the routing protocol to appropriately convey information about time slot availability to nodes in the MS-SPRING (and beyond, if the ring is embedded in a general mesh network), so that no trial and error (in searching for the right "label") is required. Note that this may not be easy to do for legacy BLSR/MS-SPRINGs. -Vishal PS: There are ways to signal LSPs for UPSRs, and one such solution is documented in a Journal of Optical Networking paper, "On the IP-Centric Control of UPSR-based Transport Networks, JON, March 2003, a copy of which is available at: http://www.metanoia-inc.com/Publications/UPSR_JON_March03.pdf > ----- Original Message ----- > From: "Diego Caviglia" > To: > Sent: Tuesday, November 25, 2003 3:00 PM > Subject: GRSVP-TE and MSSPRING > > > > Hi all, > > MSSPRING has been defined in ITU-T G.841 and is > widely used > > as inherent protection scheme in transport network (SDH). > > > > MSSPRING introduces some constraints to Label selection due to the > > impossibility to change TimeSlot (a.k.a. Label) inside a MSSPRING ring. > > > > In case of bi-directional LSP Upstream TNE has to choose the Label and > > signal it by means of the UPSTREAM Label obj but if the TNE is inside a > > MSSPRING ring it MUST choose a Label that is free on all the > TNE traversed > > by the LSP that are part of the MSSPRING ring. > > > > Of course the problem is that it does not have that information. > > > > My question is how can I signal, with GRSVP-TE, a bidirectional LSP that > > traverses an MSSPRING ring? > > > > My impression is that I can not. > > > > Any answer is welcome. > > > > Regards > > > > Diego > > > > > > > > ------------------------------------------ > > Diego Caviglia > > Marconi - Optical Networks > > ASTN/GMPLS - System Design Manager > > Via A. Negrone 1/A > > 16153 Genoa - Italy > > Phone: +390106003736 > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 23:41:17 +0000 Message-ID: <002e01c3b3ad$558c7b90$38849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ong, Lyndon" Cc: , "Jonathan Sadler" Subject: RE: Stable state on ASON signaling requirements? Date: Tue, 25 Nov 2003 23:38:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Lyndon, > Hi Adrian, > > You have a good point that most of the requirements work > is stable (I think Jonathan did have an outstanding > comment on call segments). Yes. This is what Dimitri fixed and circulated, so I think we may be close to done on the requirements. > However, it seems to me that we are still early in the > discussion of solutions. By making the RSVP draft a > WG draft, are we settling on its set of solutions? Well, I'm not sure. What does it mean for a draft to become a WG draft? It certainly means that the WG is interested in the work, and the work fits within the charter. It also means that the control of the content of the draft belongs to the whole WG, not just the authors. I suppose it also stops a draft going to the IESG "by the back door" and means that the draft is up for full debate in the WG. Do we have to have full agreement on all of the contents of the draft before it becomes a WG draft? Certainly not. If we did that, we'd go straight to WG last call! Cheers, Adrian > > wrt the ASON signaling solutions draft, you wrote > > > Its too early to have solutions as a working group item given that we > > > haven't achieved a "stable state" on the requirements. Working on > > > solutions at this time will only distract us, creating further negative > > > pressure. > > You're right that developing solutions too far while requirements are not > > stable is a bad thing. > > > > However... > > > > We have had only one comment about the latest version of the > > requirements draft from the WG (in Minneapolis and on the list) > > suggesting that either the draft is stable or the WG doesn't care. > > (The amount of noise about the solution draft suggests the WG > > *does* care). > > > > The one comment was from you in Minneapolis. Dimitri modified > > the text accordingly and circulated it. No-one has objected. > > > > So, is there any more requirements work to do, or are we at a > > stable state? > > Recall the draft is attempting to document the current state of the > > ASON requirements as they apply to GMPLS signaling and in terms > > that the IETF can grok. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 23:26:53 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE6263@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Adrian Farrel' , Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: RE: Stable state on ASON signaling requirements? Date: Tue, 25 Nov 2003 15:24:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Adrian, You have a good point that most of the requirements work is stable (I think Jonathan did have an outstanding comment on call segments). However, it seems to me that we are still early in the discussion of solutions. By making the RSVP draft a WG draft, are we settling on its set of solutions? Thanks, Lyndon -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Tuesday, November 25, 2003 2:00 PM To: Jonathan Sadler Cc: ccamp@ops.ietf.org Subject: Stable state on ASON signaling requirements? Hi Jonathan, wrt the ASON signaling solutions draft, you wrote > Its too early to have solutions as a working group item given that we > haven't achieved a "stable state" on the requirements. Working on > solutions at this time will only distract us, creating further negative > pressure. You're right that developing solutions too far while requirements are not stable is a bad thing. However... We have had only one comment about the latest version of the requirements draft from the WG (in Minneapolis and on the list) suggesting that either the draft is stable or the WG doesn't care. (The amount of noise about the solution draft suggests the WG *does* care). The one comment was from you in Minneapolis. Dimitri modified the text accordingly and circulated it. No-one has objected. So, is there any more requirements work to do, or are we at a stable state? Recall the draft is attempting to document the current state of the ASON requirements as they apply to GMPLS signaling and in terms that the IETF can grok. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 23:08:29 +0000 Message-ID: <3FC3E018.5010305@alcatel.be> Date: Wed, 26 Nov 2003 00:04:56 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org, Diego Caviglia Subject: Re: GRSVP-TE and MSSPRING Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed adrian, if the complete set of information (including label) is not available at the ingress, that's the way of doing this (the situation is here equivalent to the continuity principle that has led to the label set/ acceptable label set objects/processing), thanks, - dimitri. Adrian Farrel wrote: > Diego, > > I believe that if you use Label Set and Acceptable Label Set you will arrive at the right > result. > It may take a few messages backwards and forwards to sort it out. > > Regards, > Adrian > ----- Original Message ----- > From: "Diego Caviglia" > To: > Sent: Tuesday, November 25, 2003 3:00 PM > Subject: GRSVP-TE and MSSPRING > > > >>Hi all, >> MSSPRING has been defined in ITU-T G.841 and is widely used >>as inherent protection scheme in transport network (SDH). >> >>MSSPRING introduces some constraints to Label selection due to the >>impossibility to change TimeSlot (a.k.a. Label) inside a MSSPRING ring. >> >>In case of bi-directional LSP Upstream TNE has to choose the Label and >>signal it by means of the UPSTREAM Label obj but if the TNE is inside a >>MSSPRING ring it MUST choose a Label that is free on all the TNE traversed >>by the LSP that are part of the MSSPRING ring. >> >>Of course the problem is that it does not have that information. >> >>My question is how can I signal, with GRSVP-TE, a bidirectional LSP that >>traverses an MSSPRING ring? >> >>My impression is that I can not. >> >>Any answer is welcome. >> >>Regards >> >>Diego >> >> >> >>------------------------------------------ >>Diego Caviglia >>Marconi - Optical Networks >>ASTN/GMPLS - System Design Manager >>Via A. Negrone 1/A >>16153 Genoa - Italy >>Phone: +390106003736 >> >> >> >> >> >> > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 22:02:15 +0000 Message-ID: <002201c3b39f$6ff78410$38849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Jonathan Sadler" Cc: Subject: Stable state on ASON signaling requirements? Date: Tue, 25 Nov 2003 21:59:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Jonathan, wrt the ASON signaling solutions draft, you wrote > Its too early to have solutions as a working group item given that we > haven't achieved a "stable state" on the requirements. Working on > solutions at this time will only distract us, creating further negative > pressure. You're right that developing solutions too far while requirements are not stable is a bad thing. However... We have had only one comment about the latest version of the requirements draft from the WG (in Minneapolis and on the list) suggesting that either the draft is stable or the WG doesn't care. (The amount of noise about the solution draft suggests the WG *does* care). The one comment was from you in Minneapolis. Dimitri modified the text accordingly and circulated it. No-one has objected. So, is there any more requirements work to do, or are we at a stable state? Recall the draft is attempting to document the current state of the ASON requirements as they apply to GMPLS signaling and in terms that the IETF can grok. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 21:53:50 +0000 Message-ID: <000c01c3b39d$f601b410$38849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Diego Caviglia" Subject: Re: GRSVP-TE and MSSPRING Date: Tue, 25 Nov 2003 21:44:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Diego, I believe that if you use Label Set and Acceptable Label Set you will arrive at the right result. It may take a few messages backwards and forwards to sort it out. Regards, Adrian ----- Original Message ----- From: "Diego Caviglia" To: Sent: Tuesday, November 25, 2003 3:00 PM Subject: GRSVP-TE and MSSPRING > Hi all, > MSSPRING has been defined in ITU-T G.841 and is widely used > as inherent protection scheme in transport network (SDH). > > MSSPRING introduces some constraints to Label selection due to the > impossibility to change TimeSlot (a.k.a. Label) inside a MSSPRING ring. > > In case of bi-directional LSP Upstream TNE has to choose the Label and > signal it by means of the UPSTREAM Label obj but if the TNE is inside a > MSSPRING ring it MUST choose a Label that is free on all the TNE traversed > by the LSP that are part of the MSSPRING ring. > > Of course the problem is that it does not have that information. > > My question is how can I signal, with GRSVP-TE, a bidirectional LSP that > traverses an MSSPRING ring? > > My impression is that I can not. > > Any answer is welcome. > > Regards > > Diego > > > > ------------------------------------------ > Diego Caviglia > Marconi - Optical Networks > ASTN/GMPLS - System Design Manager > Via A. Negrone 1/A > 16153 Genoa - Italy > Phone: +390106003736 > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 20:13:14 +0000 From: Emmanuel.Desmet@alcatel.be Sensitivity: Subject: RE: ASON RSVP-TE draft to WG doc To: kireeti@juniper.net Cc: ccamp@ops.ietf.org Message-ID: Date: Tue, 25 Nov 2003 21:10:45 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Yes, @+ manu Hi, Please indicate whether you think that "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 19:06:55 +0000 Message-ID: <305D2EAC01C45448A7F3ECC487666F6C09F50CCA@md6370exch004u.nse.lucent.com> From: "Natale, Robert C (Bob)" To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Date: Tue, 25 Nov 2003 14:04:16 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Kireeti, No (both for the reason cited by Jonathan and because I believe that the issues identified by Eve need to be resolved/clarified first). Cheers, BobN > Kireeti Kompella wrote: > >Hi, > >Please indicate whether you think that "Generalized MPLS (GMPLS) >RSVP-TE Signalling in support of Automatically Switched Optical >Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is >ready to be a CCAMP WG document. This call ends Dec 7, 2003 at >midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 19:05:07 +0000 Message-ID: <6A08876E69B0D6119284000255917A3644808C@c3po.axiowave.com> From: Yanhe Fan To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Date: Tue, 25 Nov 2003 14:04:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > > A simple 'yes' or 'no' will be sufficient. > Yes. Yanhe Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 18:54:30 +0000 Message-ID: <3FC3A46B.9020506@tellabs.com> Date: Tue, 25 Nov 2003 12:50:19 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON RSVP-TE draft to WG doc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" Kireeti, No. Regards, Ben Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Generalized MPLS (GMPLS) >RSVP-TE Signalling in support of Automatically Switched Optical >Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is >ready to be a CCAMP WG document. This call ends Dec 7, 2003 at >midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- > > > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 18:52:23 +0000 Message-ID: <3FC3A425.39E0CFAD@tellabs.com> Date: Tue, 25 Nov 2003 12:49:09 -0600 From: Jonathan Sadler MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON RSVP-TE draft to WG doc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Kireeti- No. Its too early to have solutions as a working group item given that we haven't achieved a "stable state" on the requirements. Working on solutions at this time will only distract us, creating further negative pressure. Jonathan Sadler Kireeti Kompella wrote: > Hi, > > Please indicate whether you think that "Generalized MPLS (GMPLS) > RSVP-TE Signalling in support of Automatically Switched Optical > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 15:02:07 +0000 Sensitivity: Subject: GRSVP-TE and MSSPRING To: ccamp@ops.ietf.org From: "Diego Caviglia" Date: Tue, 25 Nov 2003 16:00:33 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi all, MSSPRING has been defined in ITU-T G.841 and is widely used as inherent protection scheme in transport network (SDH). MSSPRING introduces some constraints to Label selection due to the impossibility to change TimeSlot (a.k.a. Label) inside a MSSPRING ring. In case of bi-directional LSP Upstream TNE has to choose the Label and signal it by means of the UPSTREAM Label obj but if the TNE is inside a MSSPRING ring it MUST choose a Label that is free on all the TNE traversed by the LSP that are part of the MSSPRING ring. Of course the problem is that it does not have that information. My question is how can I signal, with GRSVP-TE, a bidirectional LSP that traverses an MSSPRING ring? My impression is that I can not. Any answer is welcome. Regards Diego ------------------------------------------ Diego Caviglia Marconi - Optical Networks ASTN/GMPLS - System Design Manager Via A. Negrone 1/A 16153 Genoa - Italy Phone: +390106003736 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 14:59:08 +0000 Date: Tue, 25 Nov 2003 23:57:00 +0900 From: Eiji Oki To: Kireeti Kompella Subject: Re: Crank-back signaling to WG doc Cc: ccamp@ops.ietf.org Message-Id: <20031125235627.0F71.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes. Eiji On Sun, 23 Nov 2003 15:38:27 -0800 (PST) Kireeti Kompella wrote: > Hi, > > Please indicate whether you think that "Crankback Signaling Extensions > for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to > become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 12:13:17 +0000 Message-ID: <3FC346DD.2010001@alcatel.fr> Date: Tue, 25 Nov 2003 13:11:09 +0100 From: Emmanuel.Dotaro@alcatel.fr Reply-To: Emmanuel.Dotaro@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Crank-back signaling to WG doc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed yes Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Crankback Signaling Extensions >for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to >become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 12:13:07 +0000 Message-ID: <3FC346EA.3070206@alcatel.fr> Date: Tue, 25 Nov 2003 13:11:22 +0100 From: Emmanuel.Dotaro@alcatel.fr Reply-To: Emmanuel.Dotaro@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON RSVP-TE draft to WG doc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed yes Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Generalized MPLS (GMPLS) >RSVP-TE Signalling in support of Automatically Switched Optical >Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is >ready to be a CCAMP WG document. This call ends Dec 7, 2003 at >midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 10:55:05 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : Crank-back signaling to WG doc Date: Tue, 25 Nov 2003 11:52:29 +0100 Message-ID: Thread-Topic: Crank-back signaling to WG doc Thread-Index: AcOyG5WPFjlhk9ACSQuwypCxz6ra5wBJpzJw From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "Kireeti Kompella" , Yes, JL -----Message d'origine----- De : Kireeti Kompella [mailto:kireeti@juniper.net]=20 Envoy=E9 : lundi 24 novembre 2003 00:38 =C0 : ccamp@ops.ietf.org Objet : Crank-back signaling to WG doc Hi, Please indicate whether you think that "Crankback Signaling Extensions = for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to = become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 10:54:47 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : ASON RSVP-TE draft to WG doc Date: Tue, 25 Nov 2003 11:52:43 +0100 Message-ID: Thread-Topic: ASON RSVP-TE draft to WG doc Thread-Index: AcOyHAndM22Zg8ZLQdmyHp0rBRJtLQBJjMqA From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: "Kireeti Kompella" , Yes, JL -----Message d'origine----- De : Kireeti Kompella [mailto:kireeti@juniper.net]=20 Envoy=E9 : lundi 24 novembre 2003 00:36 =C0 : ccamp@ops.ietf.org Objet : ASON RSVP-TE draft to WG doc Hi, Please indicate whether you think that "Generalized MPLS (GMPLS) RSVP-TE = Signalling in support of Automatically Switched Optical Network (ASON)" = (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be a CCAMP = WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 05:44:37 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E370A963187@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 16:38:22 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Kireeti, I do not think now is the right time for draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt to become a CCAMP WG document, as the current draft is leading us along a path of divergence among specifications for ASON extensions - something I view as not in our collective interests. Therefore, my input at this point is "no". Three technical issues have been under discussion on the mailing list that are related to draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt, which is using different approaches: o Treatment of ResvErr and ResvTear messages during the setup phase, as specified in Rec. G.7713.2 (i.e., "fatal flaw") o Usage of GENERALIZED_UNI object as specified in ITU-T G.7713.2 and its equivalent in G.7713.3, which was derived from OIF UNI 1.0 IA o Support for SPC using G_UNI as specified in ITU-T Rec. G.7713.2 and G.7713.3 Of these items, only for the treatment of ResvErr and ResvTear messages has there been any statement made suggesting a technical flaw. The "fatal flaw" characterization was first raised, as I recall, during Jan. '03 as part of the discussion of code point assignments, where it was suggested that there was an incompatibility in the treatment of ResvErr and ResvTear messages in the 3474 text. As a result, some text was removed. It is now eight months since that time, and to date, no one has given a full technical description of the issue either via email to ccamp, or via a liaison statement to ITU-T. Kam Lam, the Rapporteur of Q.14/15 has made a specific request for someone to identify the detailed message flows as defined in ASON, and point out which message sequence causes the problem. If there is a "fatal flaw", we need to provide the details to ITU-T as soon as possible so that they can make the necessary corrections to G.7713.2 via a Corrigendum. Let's get the facts! on the table rather than just reiterating this assertion so that, if there is a problem, something can be done about it. In terms of G_UNI and SPC using G_UNI, I think a bit of context is useful, as these were discussed and agreed to by a broad range of people and companies across the industry over the past few years. There has never been any claim of a technical flaw that "breaks GMPLS". These ASON extensions were not derived independent of participation from IETF experts. As has been noted within email discussions from last Jan. '03 when these issues were raised, many (approximately 10+ or so) of the major players from the CCAMP and MPLS WGs were contributing to the OIF LDP and RSVP specs for UNI 1.0. Quite a few have also been active in ITU-T, which has consistently communicated both ASON requirements and any potential solutions for feedback/input from IETF experts. This joint participation across standards and industry fora enabled a much higher degree of visibility and critical mass of expertise to work on and impact ASON signaling extensions. In particular, the GENERALIZED_UNI obje! ct received extensive discussion among experts cross-participating in multiple fora, and is included in the resultant agreed specifications: o Alignment on OIF-UNI-1.0 during 4Q01, with 78 companies approving the document at Principal Ballot. (Actually, many of the individuals who are raising objections to G_UNI are also on the contributor list of the OIF document and their companies voted "Yes" on the UNI 1.0 Principal Ballot.) o Consensus for Approval of ITU-T G.7713.2 and G.7713.3 March '03, using the code point assignments from RFCs 3474, 3475, and 3476. (The companies of several of the individuals raising objections who are members of the ITU-T also voted affirmatively to Consent G.7713.2 and G.7713.3.) I'd note the process the ITU-T uses allows for technical objections to be raised both during initial "Consent" and well as on the way to actual Approval. No comments or technical objections were raised to "Consent" of these Recommendations during the Jan. '03 meeting of ITU-T SG 15 (nor by the 189 member states, over 650 sector members, or 49 associate members who had the opportunity to review the text thereafter). Thus, at this time running code exists and interoperable implementations are available and have been publicly demo'd that use G_UNI. With draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt, we are consciously deciding to take a different path for the aforementioned areas in this regard. The question I think we need to ask ourselves is whether coming up with alternative approaches to working solutions that have been previously specified - introducing divergence among specifications for ASON extensions - is in the best interests of the IETF community and the industry. Best regards, Eve Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 04:31:35 +0000 Message-ID: <09fa01c3b30c$d0d0cc30$db818182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Draft minutes from Minneapolis Date: Tue, 25 Nov 2003 04:28:24 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Very many thanks to Eric Gray, Dimitri Papadimitriou and Deborah Brungard for taking minutes. Corrections ASAP. Please be gentle. ---------------- Draft minutes. CCAMP Working Group. 58th IETF Minneapolis Monday 10th November 2003 0900-11.30 CHAIRS: Kireeti Kompella Adrian Farrel Agenda bashing (chairs) ======================== Minute takers and blue sheets (chairs) ====================================== Minute takers: Dimitri Papadimitriou Deborah Brungard Eric Gray Kireeti: Thanks to Ron Bonica for co-chairing Thanks to Adrian Farrel for taking over as co-chair Old charter (chairs) ==================== Groundwork and critical work is completed, thus re-charter. New charter (chairs) ==================== - Multi-area/multi-as using tewg mpls requirements as input - GMPLS ASON (input from ITU-T) look at the requirements and then address them - Short charter for 6 months and move forward - Lots of interactions with the MPLS and IGP WG's - Short term focus of the WG on the charter milestones therefore new material at bottom of the agenda (thus take it to the list if this is not covered during this meeting) Drafts in 'final stages' (chairs) ================================= - Routing drafts: comments received from IESG (cleared yesterday) - 2 drafts in IETF 4 weeks last call: LMP-SONET-SDH and LMP-WDM - 2 drafts pending: LMP-MIB and SDH/SONET-Control (with Bert and Alex for review) Work in progress (chairs) ========================= - GMPLS UNI (overlay): needs one week WG last call - GMPLS for G.709: look for WG last call but positive comments needed to move forward so will ask via mailing list if there is interest or not in progressing and if any issues, - Routing exclusion: new version is imminent (revision to be published just after the meeting) Summary of interactions with other WGs (chairs) =============================================== - TE WG: Multi-area/AS requirements (mpls only) - MPLS WG: P2MP Requirements - OSPF/IS-IS WG: GMPLS extensions completed now starting new item on ASON Routing requirements (Design Team) - IPO WG: Framework document ITU-T Liaison (Wesam Alanqar) ============================= Discussions: - Kireeti Kompella: noted that an ITU Recommendation can have CR-LDP as a normative reference, that's ok, but for future need to discuss among chairs/ADs (this will be done off-line) - Alex Zinin: CR-LDP code-points liaison, for the time this normative reference is ok but for the future will need to clarify the liaison - Kam Lam: ITU-T SG15/Q14 Feb04 interim meeting, in San Jose or North Carolina (not decided yet) - invites participants from CCAMP - Kam Lam: setup of a common FTP server / website GMPLS MIBs (Tom Nadeau) ======================= - draft-ccamp-ietf-gmpls-tc-mib-01.txt - draft-ccamp-ietf-gmpls-lsr-mib-01.txt - draft-ccamp-ietf-gmpls-te-mib-01.txt Tom Nadeau presented an update on the GMPLS MIB status. - Three drafts - fairly stable, one more round of IESG review for MPLS MIBs (these MIBs depend on the status of the MPLS MIBs). - Will publish updated MIB IDs after this meeting. - Need to extend conformance, performance tables, consider how to expose more information about hops (tunnel heads, tails and intermediates), etc. - Need to determine whether or not discriminated unions should be supported. - Multiple objects from multiple label types - Also need to know who has done an implementation of these MIBs. Discussions: - Bert Wijnen: reaffirmed that need people to review mibs even if they are not MIB doctors to ensure it represents model of technology as needed. - Kireeti Kompella: who reads the MIBs? - How do you make people read MIBs? This is part of progress of the protocol the documents. We need feedback to know if we are going in the right directions. GMPLS-based Recovery (Dimitri Papadimitriou) ============================================ - draft-ietf-ccamp-gmpls-recovery-terminology-02.txt - draft-ietf-ccamp-gmpls-recovery-analysis-02.txt - draft-ietf-ccamp-gmpls-recovery-functional-01.txt - draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt Dimitri Papadimitriou provided a status on these i-d's (the terminology, analysis and functional specification are closed, the signaling needs to pass through a thorough review after becoming a working group i-d), also pointed out that these documents should be submitted to the IESG for the Dec'03 milestone (as per charter). Discussions: - Adrian Farrel: count of approx. 8 read the drafts, and no- one thought that the four drafts content overlapped e.g. that four were too many - authors will ask for consensus via mailing list. ASON Signaling Requirements (Jerry Ash) ======================================= - draft-ietf-ccamp-gmpls-ason-reqts-03.txt Jerry Ash presented an update status on the document (note: the ver. under discussion is v04.txt) authors believe that the document is ready for WG last call. Discussions: - Adrian Farrel: asked for count of who read document double digits (more than 12), and support for going to WG last call also shows double digits - Adrian Farrel: ask if there are any objections. - Jonathan Sadler: noted that the proposed definition of call segment is still being progressed at the ITU (thus should add this clarification in the document). ASON Interworking (Lyndon Ong) ============================== - draft-ong-ccamp-3473-3474-iw-00.txt Discussions: - Dimitri Papadimitriou: pointing to the penultimate slide, commented you have identified issues, and on mailing list were identified issues, and the authors have not responded to these issues. Proposing the RFC 3474 as an "existing RFC", but what is rationale for the CCAMP WG to deal w/ it since it has an informational status at IETF. - Lyndon Ong: it is there, and its tied with an ITU standard - Dimitri Papadimitriou: technically speaking the first issue we have to deal with is the usage of TNAs, but do not see any real rationale for introducing them. - Kireeti Kompella: issue I have is that we have an existing document, RFC 3473, which is by definition the baseline from which we are building on and then there is no interworking issue. - Kireeti Kompella (Question for CCAMP): do we want to interwork? Before we go into technical issues, we need to answer question what do we do with RFC 3474? What is its exact status? and then do we look at it for interworking? - Lou Berger: what is confusing me and is where do we start from: we have two RFCs - we have a long history of having RFCs which are informational, but there is a difference between a proposed standard and an informational RFC. Here we're using ITU as rationale, this is why we are having this discussion. As info RFC 3474 is an ITU work, what we should be doing is coordinating and ask what does it take to support it? Is the info RFC 3474 the only way for achieving these requirements? Do we have to support RFC 3473? The response is yes, since RFC 3473 has the standing here in CCAMP. He also wanted to know whether this work is representative of a number of people in ASON, or is it the work of a few people looking to do things a different way. - Lyndon Ong: ITU 7713.2 and RFC 3474 are tied to each other and they do not represent a minority view. - Bert Wijnen: Substantiated this point. - Lyndon Ong: Pointed out that this group could either start with what has been defined already or start over. The latter approach is more likely to produce divergence rather than convergence. - Deborah Brungard: this draft is missing consideration of backward compatibility aspects with RFC 3473 - CCAMP WG needs to consider RFC 3473 compatibility, not just compatibility with info RFC 3474. - Bert Wijnen: CCAMP WG needs to identify to ITU any fatal flaws with info RFC 3474, and work with them. - Kireeti Kompella: What will the IETF and ITU will if there is some vendor with 5K implementations with the "fatal flaw"? He then observed that the discussion is taking far longer than he had expected and asked that people at the mike should be the last and further discussion clearly needs to take place on the list. - Malcolm Betts: the emphasis should be on need to move forward and the definition of future capabilities. - Lou Berger: CCAMP WG needs to look at info RFC 3474 and identify the flaws, and work on a standard ASON GMPLS solution here in CCAMP. RSVP-TE ASON (Dimitri Papadimitriou) ==================================== - draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt - Lyndon Ong: disagrees with conclusion that the RFC 3474 is not backward compatible with RFC 3473, e.g. RFC 3474 does not require an intermediate node to support RFC 3474. And that RFC 3474 does not address all the requirements is immaterial, it was done at a certain time, and new capabilities will need to be added. - Dimitri Papadimitriou: you say need convergence but the 3474 extensions do not address the needed functionality and the analysis provided in the appendix of this i-d shows where the backward compatibility issues are if this is used. - Kireeti Kompella: take to list to discuss technical arguments if RFC 3474 compliant or not, and if it meets requirements or not. Will need to liaise with ITU - Lyndon Ong: need to take into account that this method is an already agreed ITU standard so question is why diverge from the RFC 3474 solution. - Kireeti Kompella: we also have to agreed on a standard from the IETF side. Lets look at technical arguments on 3474, and see how to get to an end point. MPLS Crankback (Adrian Farrel) ============================== - draft-iwata-mpls-crankback-07.txt. Adrian Farrel gave a short status update - The draft needs to deal with the fact that there are not enough flag bits in the Session Attributes object. - The authors need to define logical grouping of TLVs, remove the unnumbered component link IF_ID TLV from this draft (because it is more generally applicable). Discussions: - Adrian Farrel: ask who read the draft: good showing ask to become a WG document: no dissent - Kireeti Kompella: good support, should keep as separate document for now although will probably be part of an ASON "boxed set" We need feedback, Adrian will lead the discussion via mailing list. ASON Routing Requirements (Deborah Brungard) ============================================ - draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt - Liaison statement to ITU-T Discussions: - Zafir Ali: question if requirements are from service providers (and not only vendors) - Deborah Brungard: yes, providers and vendors participate in ITU. - Kireeti Kompella: we will start with the requirements from ITU and prioritize them - Deborah Brungard: important to understand terminology and dialogue on understanding requirements with ITU. - Kam Lam: will include G.7715.1 ? - Deborah Brungard: yes - Kireeti Kompella: waxed philosophical about the advantages of striving to attain a state of boredom in the CCAMP WG. Tunneling Protocol ================== - draft-bonica-tunproto-05.txt Not presented. - Adrian Farrel: Ron Bonica missed the submission deadline. This is now on our charter so we need to pay attention. Multi-Area/AS/Region ==================== Arthi Ayyangar - draft-ayyangar-inter-region-te-01.txt - Discussed some issue with terminology - specifically the over-loading of certain terms. She also talked about possible strategies related to the duplication of work in this and - the next - draft. JP Vasseur - draft-vasseur-inter-as-te-01.txt - He gave a brief status/history of the draft - what charter item it attempts to address, how long they have been working on it, etc. Discussions: - Dimitri Papadimitriou: Wanted to know whether or not we would first consider whether or not LSR PCS should be done before we consider how to do it. - JP Vasseur: Suggested that this is a question, among others, for the list. - Arthi Ayyangar: Pointed out that the discussion needs to focus on requirements before focus on a solution. - Kireeti Kompella: Looking for a single document for both models of signaling. He would also like this work to include applicability for each different model. - Arthi Ayyangar: Please clarify what set of drafts are expected. - Kireeti Kompella: Provided a breakdown of the documents and the issues with where the work might be done on each part of the set. - Adrian Farrel: Can we have a date by which the combined draft will be produced? He would like the groups involved to take some time this week to get started. - JP Vasseur (with good grace): January 16th 2004 - Kireeti Kompella (summarizing): Should we have inter-area and inter-as as one draft and include both solutions and show when applicable the different solutions for different scenarios? -> yes Should loose re-optimization go to CCAMP? It is related work. -> need to discuss this among the chairs/ADs Should this item address both packet and non-packet? -> yes Concerning PCS signaling need to discuss among chairs/ADs, and if agreement to add in the charter, need for re- chartering, and then address the technical aspects Communication of LSP Alarm Information (Lou Berger) =================================================== - draft-berger-ccamp-gmpls-alarm-spec-00.txt He said they do currently have some issues. A key issue is that the standard alarm information defined by Telcordia and ITU are mostly in the form of strings. Discussions: - Kam Lam: points to X.733/X.736 and M.3100, will discuss it offline - Kireeti Kompella: Might need to update charter before considering this item, chairs and ADs need to discuss. Also, not too many read draft, need to start thread on email list, need to get carriers to speak up. GMPLS Signaling for L2 LSP services ( Dimitri Papadimitriou) ============================================================ - draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt Dimitri talked about some work that they have recently started for L2SC in GMPLS. This work does not include use of PW over PSN. Discussions: - Chairs: - Ask who read the draft: 12 at least - Ask who feel it should be an item CCAMP should work on: 12 at least - Kireeti Kompella: Pointed out that this work is not in the CCAMP charter and it may be difficult to add it because there is no focus in the IETF for L2 services. - Kireeti Kompella: not in CCAMP charter to do technology- specific work, need to discuss if it can go in charter. Already have SDH and G.709. And we need to check is there no other layer 2 specific work in other IETF groups, then probably could be in CCAMP - Dimitri Papadimitriou: point out that even if there are no layer 2 specific documents, RFC 3473 and GMPLS Architecture covers L2SC LSP concept (in particular, ATM and FR). So this should equally be covered by the existing charter. He also asked what he would need to do to strengthen the argument for getting this work accepted by the ADs. - Kireeti Kompella: Consensus is a powerful argument. We need to discuss this with the ADs before moving forward Component Link Recording and Resource Control for GMPLS Link Bundles (Zafar Ali) ======================================================= - draft-zamfir-explicit-resource-control-bundle-02.txt Discussions: - Chairs: - ask who read the draft: 8 to 10 - ask who feel it should become a WG document: 8 to 10 - Kireeti Kompella: concerns about what it is trying to fix. Need reason to put this in ERO, so need to understand why we want to put this in the ERO - Adrian Farrel: would like to hear from providers on need to use this before trying to adopt it. Take it to the list Requirements for time-bounded notification of faults (Richard Rabbat) ==================================================== - draft-rabbat-expedited-flooding-00.txt Discussions: - Adrian Farrel: the discussion should be taken to the list in order to agree on requirements before looking at solutions. *** Meeting in adjourned *** Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 03:48:42 +0000 Date: Tue, 25 Nov 2003 12:46:47 +0900 From: Eiji Oki To: Kireeti Kompella Subject: Re: ASON RSVP-TE draft to WG doc Cc: ccamp@ops.ietf.org Message-Id: <20031125124621.2E7A.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes. Eiji On Sun, 23 Nov 2003 15:35:36 -0800 (PST) Kireeti Kompella wrote: > Hi, > > Please indicate whether you think that "Generalized MPLS (GMPLS) > RSVP-TE Signalling in support of Automatically Switched Optical > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 01:45:35 +0000 Message-ID: <3FC2B405.8070902@lab.ntt.co.jp> Date: Tue, 25 Nov 2003 10:44:37 +0900 From: Kohei Shiomoto Organization: NTT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Crank-back signaling to WG doc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yes, I feel that the document is ready to be a CCAMP WG document. Regards, Kohei Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Crankback Signaling Extensions >for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to >become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- > > > > -- Kohei Shiomoto, Ph.D NTT Network Innovation Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 6387 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 01:44:29 +0000 Message-ID: <3FC2B3BD.2070803@lab.ntt.co.jp> Date: Tue, 25 Nov 2003 10:43:25 +0900 From: Kohei Shiomoto Organization: NTT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON RSVP-TE draft to WG doc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit yes, I feel that the document is ready to be a CCAMP WG document. Kohei Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Generalized MPLS (GMPLS) >RSVP-TE Signalling in support of Automatically Switched Optical >Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is >ready to be a CCAMP WG document. This call ends Dec 7, 2003 at >midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- > > -- Kohei Shiomoto, Ph.D NTT Network Innovation Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 6387 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 01:17:59 +0000 From: "Hirokazu Ishimatsu" To: Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Date: Tue, 25 Nov 2003 10:16:53 +0900 MIME-Version: 1.0 Thread-Index: AcOy8c6YnkzvWhakRiaxBOztw2rhJw== Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi everybody, > In the morning's meeting the AD's asked to bring the proposed > Alarm communication extension to "the list". For today's > presentation see: > http://www.labn.net/docs/AlarmSpec00.pdf > > I believe the issues to be discussed are: > 1) Is there general interest in this work? Yes, I have a great interest in this work as a service provider because monitoring alarms is very important for service management. In addition performance monitoring should be considered in conjunction with alarm monitoring for total service management. I think the ccamp WG is an appropriate working group to discuss both aspects since the ccamp working group deals with the measurement plane. Thanks, Hiro Ishimatsu Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 01:02:36 +0000 From: "Hirokazu Ishimatsu" To: Subject: RE: ASON RSVP-TE draft to WG doc Date: Tue, 25 Nov 2003 10:01:10 +0900 MIME-Version: 1.0 Thread-Index: AcOyHDJYWaWHyov9SNC9owHPJO5+jwA00/1w Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Kireeti, Yes. Hiro Ishimatsu > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Monday, November 24, 2003 8:36 AM > To: ccamp@ops.ietf.org > Subject: ASON RSVP-TE draft to WG doc > > Hi, > > Please indicate whether you think that "Generalized MPLS > (GMPLS) RSVP-TE Signalling in support of Automatically > Switched Optical Network (ASON)" > (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to > be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Nov 2003 00:47:32 +0000 Message-ID: <9A1A304A69213E4E9CC08614134C7F7C535A2B@w2k04exg02.ciena.com> From: "Razdan, Rajender" To: kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 19:45:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" No Rajender Razdan -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Sunday, November 23, 2003 3:36 PM To: ccamp@ops.ietf.org Subject: ASON RSVP-TE draft to WG doc Hi, Please indicate whether you think that "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 23:41:55 +0000 Message-ID: <3FC296A5.7080406@alcatel.be> Date: Tue, 25 Nov 2003 00:39:17 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON RSVP-TE draft to WG doc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Yes. Kireeti Kompella wrote: > Hi, > > Please indicate whether you think that "Generalized MPLS (GMPLS) > RSVP-TE Signalling in support of Automatically Switched Optical > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 22:29:44 +0000 Message-ID: <3FC285F8.4050801@ieee.org> Date: Mon, 24 Nov 2003 17:28:08 -0500 From: George Newsome User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit No. George -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Sunday, November 23, 2003 3:36 PM To: ccamp@ops.ietf.org Subject: ASON RSVP-TE draft to WG doc Hi, Please indicate whether you think that "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 21:56:41 +0000 From: "Vishal Sharma" To: "Kireeti Kompella" , Subject: RE: Crank-back signaling to WG doc Date: Mon, 24 Nov 2003 13:54:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Kireeti, Yes. Thanks, -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Kireeti Kompella > Sent: Sunday, November 23, 2003 3:38 PM > To: ccamp@ops.ietf.org > Subject: Crank-back signaling to WG doc > > > Hi, > > Please indicate whether you think that "Crankback Signaling Extensions > for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to > become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 21:56:21 +0000 From: "Vishal Sharma" To: "Kireeti Kompella" , Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 13:53:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Kireeti, Adrian, et al, Sorry, about the boo-boo, I meant to say "Yes" on the crankback draft (too many calls being issued :-)). Just to make accounting easier, I'll send out a "Yes" separately for that. -Vishal PS: I thought some of the ASON details are still being discussed on the list, so I don't really have an opinion on that yet. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Vishal Sharma > Sent: Monday, November 24, 2003 10:55 AM > To: Kireeti Kompella; ccamp@ops.ietf.org > Subject: RE: ASON RSVP-TE draft to WG doc > > > Kireeti, > > Yes. > > -Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Kireeti Kompella > > Sent: Sunday, November 23, 2003 3:36 PM > > To: ccamp@ops.ietf.org > > Subject: ASON RSVP-TE draft to WG doc > > > > > > Hi, > > > > Please indicate whether you think that "Generalized MPLS (GMPLS) > > RSVP-TE Signalling in support of Automatically Switched Optical > > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > > midnight PST. > > > > A simple 'yes' or 'no' will be sufficient. > > > > Kireeti. > > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 18:57:16 +0000 From: "Vishal Sharma" To: "Kireeti Kompella" , Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 10:55:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kireeti, Yes. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Kireeti Kompella > Sent: Sunday, November 23, 2003 3:36 PM > To: ccamp@ops.ietf.org > Subject: ASON RSVP-TE draft to WG doc > > > Hi, > > Please indicate whether you think that "Generalized MPLS (GMPLS) > RSVP-TE Signalling in support of Automatically Switched Optical > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 18:07:32 +0000 From: "Eric W Gray" To: "'Kireeti Kompella'" , Subject: RE: Crank-back signaling to WG doc Date: Mon, 24 Nov 2003 12:13:08 -0500 Message-ID: <00e501c3b2ae$3b924080$8801a8c0@khumbu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Sunday, November 23, 2003 6:38 PM > To: ccamp@ops.ietf.org > Subject: Crank-back signaling to WG doc > > Hi, > > Please indicate whether you think that "Crankback Signaling Extensions > for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to > become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 17:58:19 +0000 From: "Richard Rabbat" To: "'Kireeti Kompella'" , Subject: RE: Crank-back signaling to WG doc Date: Mon, 24 Nov 2003 09:57:01 -0800 Message-ID: <000001c3b2b4$5d45f8b0$513ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, Richard. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of Kireeti Kompella > Sent: Sunday, November 23, 2003 3:38 PM > To: ccamp@ops.ietf.org > Subject: Crank-back signaling to WG doc >=20 > Hi, >=20 > Please indicate whether you think that "Crankback Signaling Extensions > for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to > become a CCAMP WG document. This call ends Dec 7, 2003 at midnight = PST. >=20 > A simple 'yes' or 'no' will be sufficient. >=20 > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 17:44:18 +0000 Message-Id: <200311241743.hAOHhUDM021308@rtp-core-2.cisco.com> To: "Brungard, Deborah A, ALABS" cc: "Kireeti Kompella" , ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 12:43:29 -0500 From: George Swallow Yes. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 17:40:56 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC011444BA@nimbus.chromisys.com> From: Ayan Banerjee To: ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 09:40:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yes. Ayan Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 17:40:11 +0000 From: "Eric W Gray" To: "'Kireeti Kompella'" , Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 12:12:08 -0500 Message-ID: <00e401c3b2ae$181419d0$8801a8c0@khumbu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Sunday, November 23, 2003 6:36 PM > To: ccamp@ops.ietf.org > Subject: ASON RSVP-TE draft to WG doc > > Hi, > > Please indicate whether you think that "Generalized MPLS (GMPLS) > RSVP-TE Signalling in support of Automatically Switched Optical > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 17:33:22 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE623F@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: Crank-back signaling to WG doc Date: Mon, 24 Nov 2003 09:32:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yes. Lyndon -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Sunday, November 23, 2003 3:38 PM To: ccamp@ops.ietf.org Subject: Crank-back signaling to WG doc Hi, Please indicate whether you think that "Crankback Signaling Extensions for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 17:33:01 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE623E@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 09:32:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" No. Cheers, Lyndon -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Sunday, November 23, 2003 3:36 PM To: ccamp@ops.ietf.org Subject: ASON RSVP-TE draft to WG doc Hi, Please indicate whether you think that "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 17:31:16 +0000 Date: Mon, 24 Nov 2003 09:29:21 -0800 (PST) From: Arthi Ayyangar To: Kireeti Kompella cc: ccamp@ops.ietf.org Subject: Re: ASON RSVP-TE draft to WG doc Message-ID: <20031124092853.H84830@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes. -arthi > Please indicate whether you think that "Generalized MPLS (GMPLS) > RSVP-TE Signalling in support of Automatically Switched Optical > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 16:47:55 +0000 Message-ID: <3FC235E4.4030105@pi.se> Date: Mon, 24 Nov 2003 17:46:28 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON RSVP-TE draft to WG doc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > > >A simple 'yes' or 'no' will be sufficient. > ja - not so simple but it is swedish for "yes" > > >Kireeti. >------- > > > > > -- Loa Andersson mobile +46 739 81 21 64 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 16:15:58 +0000 Message-ID: From: "Hamid Ould-Brahim" To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 11:13:25 -0500 > > A simple 'yes' or 'no' will be sufficient. > Yes. Hamid. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 16:12:19 +0000 Message-Id: <4.3.2.7.2.20031124111006.02285a00@mo-ex1> Date: Mon, 24 Nov 2003 11:10:20 -0500 To: Kireeti Kompella From: Lou Berger Subject: Re: ASON RSVP-TE draft to WG doc Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed yes. At 06:35 PM 11/23/2003, Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Generalized MPLS (GMPLS) >RSVP-TE Signalling in support of Automatically Switched Optical >Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is >ready to be a CCAMP WG document. This call ends Dec 7, 2003 at >midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 16:12:04 +0000 Message-Id: <4.3.2.7.2.20031124111023.024ecdb8@mo-ex1> Date: Mon, 24 Nov 2003 11:10:28 -0500 To: Kireeti Kompella From: Lou Berger Subject: Re: Crank-back signaling to WG doc Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed yes. At 06:38 PM 11/23/2003, Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Crankback Signaling Extensions >for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to >become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 15:42:34 +0000 From: "zafar ali" To: "'Kireeti Kompella'" , Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 10:41:31 -0500 Organization: Cisco Systems Message-ID: <002401c3b2a1$6f69a860$559ae440@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes! Thanks Regards... Zafar >-----Original Message----- >From: owner-ccamp@ops.ietf.org >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella >Sent: Sunday, November 23, 2003 6:36 PM >To: ccamp@ops.ietf.org >Subject: ASON RSVP-TE draft to WG doc > > >Hi, > >Please indicate whether you think that "Generalized MPLS >(GMPLS) RSVP-TE Signalling in support of Automatically >Switched Optical Network (ASON)" >(draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be >a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 15:30:31 +0000 From: "zafar ali" To: "'Brungard, Deborah A, ALABS'" , , "'Kireeti Kompella'" Cc: Subject: RE: ASON Routing Requirements to WG doc Date: Mon, 24 Nov 2003 10:29:22 -0500 Organization: Cisco Systems Message-ID: <002201c3b29f$bd146340$559ae440@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Deborah, DT, et al, Thanks for addressing these concerns. Much appreciated. I am also glade that the doc is now accepted by the WG :-) Thanks Regards... Zafar >-----Original Message----- >From: owner-ccamp@ops.ietf.org >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, >Deborah A, ALABS >Sent: Thursday, November 20, 2003 11:27 AM >To: v.sharma@ieee.org; Zafar Ali; Kireeti Kompella >Cc: ccamp@ops.ietf.org >Subject: RE: ASON Routing Requirements to WG doc > > >Zafar, Vishal, > >Much appreciate the feedback - and the early/early interest in >the DT document. > >Regardless if the document is agreed to be a WG doc or not, I >hope the interaction between ccamp and the DT continues. Send >any comments/clarifications via CCAMP or to one of the DT >members directly. This iterative dialogue is needed early in >the development if we want to quickly progress. > >As noted on a previous email, G7715.1 on ASON link state >routing requirements was just completed in October. The basis >of the work was to be protocol agnostic (PNNI, OSPF, ISIS) and >solution-independent, and as we all know that can be a very >difficult goal. Much late night drafting in Geneva to complete >;-) For companies also ITU members, G7715.1 is available under >the AAP process for comments until Dec 13. And via CCAMP's >ASON routing work and the liaison process, CCAMP can >cooperatively contribute to future improvements/versions of >the document. > >Deborah > >-----Original Message----- >From: Vishal Sharma [mailto:v.sharma@ieee.org] >Sent: Monday, November 17, 2003 1:05 PM >To: Zafar Ali; Kireeti Kompella >Cc: ccamp@ops.ietf.org >Subject: RE: ASON Routing Requirements to WG doc > > >Hi Kireeti, Zafar, et al, > >I think the idea of the DT working co-operatively with the >ITU-T, and having some room for the DT (and CCAMP) to >iteratively work on the routing requirements is a very good idea. > > >In fact, this ties back to the comment I had first made when >Deborah was drafting the liason statement on behalf of the WG >to send to the ITU-T a few weeks ago. Lyndon had clarified >then that some items in G.7715.1 were themselves "work in >progress", so I think this is the perfect time for CCAMP and IETF to : >(a) study the ASON docs. to determine what more is needed in >the GMPLS suite of protocols, >(b) seek clarifications from the ITU-T, and >(c) provide inputs to the ITU-T. > >So, I would definitely support the idea of having the DT (and, >in fact, the WG as a whole) >spending some time understanding the ASON routing requirements >(instead of merely >adopting them), and, if necessary, providing inputs to the >ITU-T SG15 relative to G.7715 >and G.7715.1. > >-Vishal > >-----Original Message----- >From: owner-ccamp@ops.ietf.org >[mailto:owner-ccamp@ops.ietf.org]On Behalf Of Zafar Ali >Sent: Monday, November 17, 2003 7:03 AM >To: Kireeti Kompella >Cc: ccamp@ops.ietf.org >Subject: Re: ASON Routing Requirements to WG doc > > >Hi Kireeti, > >I understand that the requirements that fall out of the scope >of ITU-T recommendations are NOT part of this document/ work. >However, I would like to understand some of the requirements >in the document a little better. Specifically, when the >document mentions that "- support multiple hierarchical >levels", my question how many level of hierarchy is implied >here? Similarly, when a requirement like, "- support >architectural evolution in terms of the number of levels of >hierarchies, aggregation and segmentation of (control ?) >domains" is stated, I would like to again understand the >notion of "levels of hierarchies". > >In short, I think there are a lots of TBD's in the document >that DT will be closing with ITU. I would like to see this as >an "interactive" process, rather than something like "here are >the requirements, period". I think for the sake of >prioritization and for providing cross-organization feedback, >it will be very important to have some "room" for DT and ccamp. > >Thanks > >Regards... Zafar > >================================================================= >Zafar Ali, Ph. D. 100 South >Main St. #200, >Technical Leader, Ann Arbor, >MI 48104, USA. >Cisco Systems. (734) 276-2459. >================================================================= > > >At 07:42 PM 11/16/2003 -0800, Kireeti Kompella wrote: > > >Hi Zafar, > >On Sun, 16 Nov 2003, Zafar Ali wrote: > >Thanks for your input! > >> Deborah made a very good point about goals of the design team during >> the WG meeting. Specifically, she mentioned that the DT will work >> closely with ITU to understand the requirements. > >Excellent. > >> I would really like to make sure that the >> requirements are coming from the service providers > >If you read the design team charter, you'll see that the >requirements come from the ITU, and that requirements *not* >from the ITU have no place, especially since the document is >entitled "ASON Routing Requirements". However, the assumption >is that the ITU got their input from service providers (or carriers). > >> and not from specific >> implementations. So, I would like to see more activity from >the DT in >> closing on the requirements in the light of the needs of service >> providers, before agreeing to the notion. > >Requirements from specific implementations and requirements >that the DT 'closes on ... [from] service providers' are not >relevant in this particular document. If there is a 'further >requirements for GMPLS routing', your concerns would be very >relevant and valuable. > >However, for this document, given the charter of the design >team, I would ask you to reconsider. > >Thanks, >Kireeti. >------- > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 15:26:27 +0000 From: "zafar ali" To: "'Kireeti Kompella'" , Subject: RE: Crank-back signaling to WG doc Date: Mon, 24 Nov 2003 10:25:10 -0500 Organization: Cisco Systems Message-ID: <002001c3b29f$276f84f0$559ae440@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes! Thanks Regards... Zafar >-----Original Message----- >From: owner-ccamp@ops.ietf.org >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella >Sent: Sunday, November 23, 2003 6:38 PM >To: ccamp@ops.ietf.org >Subject: Crank-back signaling to WG doc > > >Hi, > >Please indicate whether you think that "Crankback Signaling >Extensions for MPLS Signaling" >(draft-iwata-mpls-crankback-07.txt) is ready to become a CCAMP >WG document. This call ends Dec 7, 2003 at midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 15:26:11 +0000 From: "zafar ali" To: "'Kireeti Kompella'" , Subject: RE: Crank-back signaling to WG doc Date: Mon, 24 Nov 2003 10:25:10 -0500 Organization: Cisco Systems Message-ID: <002101c3b29f$2bcaefd0$559ae440@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes! Thanks Regards... Zafar >-----Original Message----- >From: owner-ccamp@ops.ietf.org >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella >Sent: Sunday, November 23, 2003 6:38 PM >To: ccamp@ops.ietf.org >Subject: Crank-back signaling to WG doc > > >Hi, > >Please indicate whether you think that "Crankback Signaling >Extensions for MPLS Signaling" >(draft-iwata-mpls-crankback-07.txt) is ready to become a CCAMP >WG document. This call ends Dec 7, 2003 at midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 15:16:55 +0000 Message-Id: <200311241515.hAOFFbX78889@merlot.juniper.net> To: ccamp@ops.ietf.org Subject: Re: ASON RSVP-TE draft to WG doc MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19049.1069686937.1@juniper.net> Date: Mon, 24 Nov 2003 07:15:37 -0800 From: Yakov Rekhter Kireeti, > Please indicate whether you think that "Generalized MPLS (GMPLS) > RSVP-TE Signalling in support of Automatically Switched Optical > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. I think that the document is ready to be a CCAMP WG document. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 15:15:27 +0000 Message-Id: <4.3.2.7.2.20031124101256.04a41690@wells.cisco.com> Date: Mon, 24 Nov 2003 10:13:20 -0500 To: Kireeti Kompella From: Jean Philippe Vasseur Subject: Re: ASON RSVP-TE draft to WG doc Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Yes ! JP. At 03:35 PM 11/23/2003 -0800, Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Generalized MPLS (GMPLS) >RSVP-TE Signalling in support of Automatically Switched Optical >Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is >ready to be a CCAMP WG document. This call ends Dec 7, 2003 at >midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 15:15:15 +0000 Message-Id: <4.3.2.7.2.20031124101333.04a47840@wells.cisco.com> Date: Mon, 24 Nov 2003 10:13:41 -0500 To: Kireeti Kompella From: Jean Philippe Vasseur Subject: Re: Crank-back signaling to WG doc Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Yes ! JP. At 03:38 PM 11/23/2003 -0800, Kireeti Kompella wrote: >Hi, > >Please indicate whether you think that "Crankback Signaling Extensions >for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to >become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > >A simple 'yes' or 'no' will be sufficient. > >Kireeti. >------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 14:44:51 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Crank-back signaling to WG doc Date: Mon, 24 Nov 2003 08:43:49 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0572A02C@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Crank-back signaling to WG doc Thread-Index: AcOyGxlVYZsRTVfHQHu46FfyLweY1QAfkCpw From: "Brungard, Deborah A, ALABS" To: "Kireeti Kompella" , Yes, Deborah -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Sunday, November 23, 2003 6:38 PM To: ccamp@ops.ietf.org Subject: Crank-back signaling to WG doc Hi, Please indicate whether you think that "Crankback Signaling Extensions for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 14:44:35 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 08:43:36 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0572A02B@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON RSVP-TE draft to WG doc Thread-Index: AcOyGxRZa/KbSTomTmGSpycS58y4SQAfjP3A From: "Brungard, Deborah A, ALABS" To: "Kireeti Kompella" , Yes, Deborah -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Sunday, November 23, 2003 6:36 PM To: ccamp@ops.ietf.org Subject: ASON RSVP-TE draft to WG doc Hi, Please indicate whether you think that "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 14:25:28 +0000 Message-ID: From: "Xu, Yangguang" To: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 09:22:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yes to both draft-iwata-mpls-crankback-07.txt draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Sunday, November 23, 2003 6:36 PM To: ccamp@ops.ietf.org Subject: ASON RSVP-TE draft to WG doc Hi, Please indicate whether you think that "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 14:20:32 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048DFA@nimbus.chromisys.com> From: John Drake To: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 06:17:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" yes > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Sunday, November 23, 2003 3:36 PM > To: ccamp@ops.ietf.org > Subject: ASON RSVP-TE draft to WG doc > > > Hi, > > Please indicate whether you think that "Generalized MPLS (GMPLS) > RSVP-TE Signalling in support of Automatically Switched Optical > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 14:20:13 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048DF9@nimbus.chromisys.com> From: John Drake To: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: Crank-back signaling to WG doc Date: Mon, 24 Nov 2003 06:16:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" yes > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Sunday, November 23, 2003 3:38 PM > To: ccamp@ops.ietf.org > Subject: Crank-back signaling to WG doc > > > Hi, > > Please indicate whether you think that "Crankback Signaling Extensions > for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to > become a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 14:10:24 +0000 Message-ID: <3FC21060.7050100@alcatel.be> Date: Mon, 24 Nov 2003 15:06:24 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Crank-back signaling to WG doc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi kireeti, et al. yes, definitelly, it may be also appropriate to let the multi-area/-as code-points "under discussion" until we get a multi- area/as spec w/i ccamp context thanks, - dimitri. Kireeti Kompella wrote: > Hi, > > Please indicate whether you think that "Crankback Signaling Extensions > for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to > become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 12:14:22 +0000 Message-ID: <006401c3b280$3d0128b0$bd88eed2@OTANINOTEPC> From: "Tomohiro Otani" To: "Kireeti Kompella" , Subject: Re: ASON RSVP-TE draft to WG doc Date: Mon, 24 Nov 2003 20:43:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Kireeti and everyone, Yes. Tomo ------------------------------------ Tomohiro Otani KDDI R&D Laboratories, Inc. Optical network lab. 2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan TEL: +81-49-278-7357 FAX: +81-49-278-7811 E-mail: otani@kddilabs.jp ------------------------------------ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 10:43:19 +0000 From: Bart.Rousseau@alcatel.be Sensitivity: Subject: Re: Crank-back signaling to WG doc To: Kireeti Kompella Cc: ccamp@ops.ietf.org Message-ID: Date: Mon, 24 Nov 2003 11:41:41 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Kireeti, Yes, but I would suggest to extract the gist of section 3 "Discussion" and include the rest in an appendix. Bart. Kireeti Kompella @ops.ietf.org on 24/11/2003 00:38= :27 Sent by: owner-ccamp@ops.ietf.org To: ccamp@ops.ietf.org cc: Subject: Crank-back signaling to WG doc Hi, Please indicate whether you think that "Crankback Signaling Extensions for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST= . A simple 'yes' or 'no' will be sufficient. Kireeti. ------- -----------------------------------------------------------------------= - Bart Rousseau - Research Engineer =A0=A0=A0=A0=A0 =A0= =A0 V Optical Networking - Network Strategy Group - CTO +---------------= + Alcatel,Francis Wellesplein 1,B-2018 Antwerpen,Belgium | A L C A T E L = | Tel:+32 3 240 70 69 - Fax:+32 3 240 48 88 +---------------= + = Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 09:42:36 +0000 Message-ID: <3FC1D224.AE0A8743@alcatel.de> Date: Mon, 24 Nov 2003 10:40:52 +0100 From: Gert Grammel Organization: Alcatel TND Product Strategy MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON RSVP-TE draft to WG doc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit yes Gert Kireeti Kompella wrote: > Hi, > > Please indicate whether you think that "Generalized MPLS (GMPLS) > RSVP-TE Signalling in support of Automatically Switched Optical > Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is > ready to be a CCAMP WG document. This call ends Dec 7, 2003 at > midnight PST. > > A simple 'yes' or 'no' will be sufficient. > > Kireeti. > ------- -- Alcatel Optical Network Division Gert Grammel Network Strategy phone: +49 711 821 47368 Lorenzstrasse 10 fax: +49 711 821 43169 D-70435 Stuttgart mailto:Gert.Grammel@alcatel.de Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 07:56:34 +0000 From: Bart.Rousseau@alcatel.be Sensitivity: Subject: Re: ASON RSVP-TE draft to WG doc To: Kireeti Kompella Cc: ccamp@ops.ietf.org Message-ID: Date: Mon, 24 Nov 2003 08:54:42 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Kireeti, Yes. Bart. Kireeti Kompella @ops.ietf.org on 24/11/2003 00:35= :36 Sent by: owner-ccamp@ops.ietf.org To: ccamp@ops.ietf.org cc: Subject: ASON RSVP-TE draft to WG doc Hi, Please indicate whether you think that "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- -----------------------------------------------------------------------= - Bart Rousseau - Research Engineer =A0=A0=A0=A0=A0 =A0= =A0 V Optical Networking - Network Strategy Group - CTO +---------------= + Alcatel,Francis Wellesplein 1,B-2018 Antwerpen,Belgium | A L C A T E L = | Tel:+32 3 240 70 69 - Fax:+32 3 240 48 88 +---------------= + = Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 06:49:05 +0000 Subject: RE: ASON RSVP-TE draft to WG doc Date: Sun, 23 Nov 2003 22:46:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <23F5FB9E8B1C734F9633D9E1D336E8851B6987@sb-exchange1.rinconnetworks.com> Content-Class: urn:content-classes:message Thread-Topic: ASON RSVP-TE draft to WG doc thread-index: AcOyHHg4aaA/C/LLSDqe05syHkQV1wAOdD8g From: "Jonathan Lang" To: "Kireeti Kompella" , Yes. Thanks, Jonathan=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Sunday, November 23, 2003 3:36 PM > To: ccamp@ops.ietf.org > Subject: ASON RSVP-TE draft to WG doc >=20 > Hi, >=20 > Please indicate whether you think that "Generalized MPLS=20 > (GMPLS) RSVP-TE Signalling in support of Automatically=20 > Switched Optical Network (ASON)"=20 > (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to=20 > be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. >=20 > A simple 'yes' or 'no' will be sufficient. >=20 > Kireeti. > ------- >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Nov 2003 01:13:06 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON RSVP-TE draft to WG doc Date: Sun, 23 Nov 2003 19:11:17 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA368E@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON RSVP-TE draft to WG doc Thread-Index: AcOyGxNI+UiJPyilRjKVvP5Vv87lqQADKEyA From: "Ash, Gerald R (Jerry), ALABS" To: "Kireeti Kompella" , Cc: "Ash, Gerald R (Jerry), ALABS" Kireeti, > A simple 'yes' or 'no' will be sufficient. Yes. Regards, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 23 Nov 2003 23:39:25 +0000 Date: Sun, 23 Nov 2003 15:38:27 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Crank-back signaling to WG doc Message-ID: <20031123153612.N8324@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Please indicate whether you think that "Crankback Signaling Extensions for MPLS Signaling" (draft-iwata-mpls-crankback-07.txt) is ready to become a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 23 Nov 2003 23:39:12 +0000 Date: Sun, 23 Nov 2003 15:35:36 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: ASON RSVP-TE draft to WG doc Message-ID: <20031123152754.V8324@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Please indicate whether you think that "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)" (draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt) is ready to be a CCAMP WG document. This call ends Dec 7, 2003 at midnight PST. A simple 'yes' or 'no' will be sufficient. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 22 Nov 2003 20:15:39 +0000 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "'Kireeti Kompella'" , "'adrian@olddog.co.uk'" Cc: "'Scott Bradner'" , "'Alex Zinin'" , "'Bill Fenner'" , "'betts01@nortelnetworks.com'" , "'tsg15q14@itu.int'" , "'tsg15q12@itu.int'" , ccamp@ops.ietf.org Subject: RE: ITU Liaison regarding ASON Requirements Design Team Date: Sat, 22 Nov 2003 15:11:23 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi, This is a resend to include the ccamp list as I got notices of Undelivery to some of the addressees from the Mail sever. Regards, Kam Lam ITU-T Q14/15 Rapporteur > -----Original Message----- > From: Lam, Hing-Kam (Kam) > Sent: Wednesday, November 19, 2003 8:51 AM > To: 'Kireeti Kompella'; 'adrian@olddog.co.uk' > Cc: 'Scott Bradner'; 'Alex Zinin'; 'Bill Fenner'; > 'betts01@nortelnetworks.com'; 'tsg15q14@itu.int'; 'tsg15q12@itu.int' > Subject: RE: ITU Liaison regarding ASON Requirements Design Team > > > Dear Mr. Kompella and Mr. Farrel, > > In addition to our request for your feedback on signalling > protocol extensions for ASON, we will also appreciate any > detail information related to your comments raised during the > June Q14/15 meeting regarding potential issues with G.7713.2. > In particular, the following would be very helpful: > To show the detailed message flows as defined in ASON, and > point out which message sequence causes the issues (and > reference the RFC text that conflicts -- thus causing > issues). The reference that would be relevant here would be > RFC 2205 (the original RSVP protocol definition), RFC 3209 > (RSVP-TE), RFC 3473 (GMPLS extensions), and RFC 2209 (an > informational document discussing the message processing rules). > > Regards, > Kam Lam > Q14/15 Rapporteur > > > -----Original Message----- > > From: Lam, Hing-Kam (Kam) > > Sent: Tuesday, November 18, 2003 3:36 PM > > To: 'Kireeti Kompella'; 'adrian@olddog.co.uk' > > Cc: Scott Bradner; Alex Zinin; Bill Fenner; > > betts01@nortelnetworks.com; > > 'tsg15q14@itu.int'; 'tsg15q12@itu.int' > > Subject: RE: ITU Liaison regarding ASON Requirements Design Team > > > > > > Dear Mr. Kompella and Mr. Farrel, > > > > Thank you for your liaison statement regarding ccamp's ASON > > Requirements Design Team. We are looking forward to reveiw > > its output when the document is available. > > > > Regarding ASON signalling protocol extensions, please note > > that in the June 2003 Q14/15 Chicago interim meeting, a > > liaison statement > > (ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltranspor > > t/COMMUNICATIONS/ccamp/IETF_ccamp_sigprotocol.html) > > was sent to ccamp. We will appreciate your feedback regarding > > SG15's suggestion on signalling protocol extensions for ASON. > > > > Regards, > > Kam Lam > > Q14/15 Rapporteur > > > > > -----Original Message----- > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > Sent: Saturday, November 15, 2003 4:02 PM > > > To: betts01@nortelnetworks.com; hklam@lucent.com > > > Cc: Scott Bradner; Alex Zinin; Bill Fenner; ccamp@ops.ietf.org > > > Subject: ITU Liaison regarding ASON Requirements Design Team > > > > > > > > > Dear Mr. Lam and Mr. Betts, > > > > > > We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has > > > initiated a Design Team on GMPLS ASON Routing Requirements. > > The GMPLS > > > ASON Routing Requirements Design Team's Charter is as follows: > > > > > > "To understand the requirements for ASON routing so as to capture > > > what's missing from current CCAMP work in a "GMPLS ASON Routing > > > Requirements" document. The ground rules are the same as for ASON > > > signaling requirements: no requirement will be considered in this > > > document that is not an ASON routing requirement (as > > decided by those > > > working on Questions 12 and 14 of Study Group 15). Requirements > > > should be justified briefly and prioritized. If needed, a > section on > > > terminology should be included. No attempt should be made in this > > > document to do protocol design or suggest protocol extensions." > > > > > > We expect to liaison to you a draft of the above WG > document during > > > Dec. 2003. We wish to work with you cooperatively on > this document > > > and we would appreciate your assistance in reviewing this draft. > > > > > > Thank you, > > > Kireeti Kompella & Adrian Farrel > > > CCAMP WG chairs, IETF > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 22 Nov 2003 14:39:15 +0000 Message-ID: <074901c3b105$2ba3be10$db818182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-ietf-tewg-interas-mpls-te-req-02.txt Date: Sat, 22 Nov 2003 14:29:51 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0746_01C3B105.17243EB0" This is a multi-part message in MIME format. ------=_NextPart_000_0746_01C3B105.17243EB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, Please be aware of this draft. It provides us with requirements to address in our inter-AS work and is (of course) closely related to the inter-area work we do. I believe that the tewg is planning to do a last call soon, so please send your feedback to the tewg mailing list or to the authors direct. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Wednesday, November 19, 2003 8:27 PM Subject: I-D ACTION:draft-ietf-tewg-interas-mpls-te-req-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Traffic Engineering Working Group of the IETF. > > Title : MPLS Inter-AS Traffic Engineering requirements > Author(s) : R. Zhang, J. Vasseur > Filename : draft-ietf-tewg-interas-mpls-te-req-02.txt > Pages : 26 > Date : 2003-11-19 > > This document discusses requirements for the support of inter-AS > MPLS Traffic Engineering (MPLS TE). The main objective of this > document is to present a set of requirements which would result in > a set of general guidelines in the definition, selection and > specification development for any technical solution(s) meeting > these requirements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tewg-interas-mpls-te-req-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-tewg-interas-mpls-te-req-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-tewg-interas-mpls-te-req-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------=_NextPart_000_0746_01C3B105.17243EB0 Content-Type: application/octet-stream; name="ATT01857.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01857.dat" Content-Type: text/plain Content-ID: <2003-11-19144652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tewg-interas-mpls-te-req-02.txt ------=_NextPart_000_0746_01C3B105.17243EB0 Content-Type: text/plain; name="draft-ietf-tewg-interas-mpls-te-req-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-tewg-interas-mpls-te-req-02.txt" Content-Type: text/plain Content-ID: <2003-11-19144652.I-D@ietf.org> ------=_NextPart_000_0746_01C3B105.17243EB0-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 22 Nov 2003 14:21:46 +0000 Message-ID: <06f801c3b102$dded6740$db818182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Non-member submission from ["Randy Presuhn" ] : Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Date: Sat, 22 Nov 2003 14:08:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Hi - > > > From: "Wijnen, Bert (Bert)" > > To: "Tom Petch" ; "Wijnen, Bert (Bert)" > > Cc: ; "Randy Presuhn" > > Sent: Wednesday, November 19, 2003 7:59 AM > > Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > > > I believe thatthe codepoints we are talking about are not > > under discussion. Add those are in a TC that is in a > > separate MIB module in that document and the intent is > > that IANA (see start of module on page 36) will maintain > > that module and keep it in sync with ITU-T (in fact values under > > 1024 are reserved for ITU-T). > > > > Hope this clarifies. > ... > > Bert's summary is correct. Disman is wrapping up the discussion > of the review comments on draft-ietf-disman-alarm-mib-15.txt, > and has made no structural changes. There have been a lot > of clarifications and some minor tweaks, such as handling of > out-of-memory conditions, but nothing drastic. > > I think it would be very interesting to describe how alarm information > communicated using the mechanisms described in > http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-00.txt > would be represented in the alarm MIB. However, I do not think that > it would make sense to wait for such an analysis to be completed > before handing the alarm MIB to the IESG, particularly since the > alarm report control document is in the RFC editor queue at this time. > Comments on possible mappings between the ccamp alarms and > the alarm MIB would be welcome on the disman@ietf.org mailing list, > and would be taken into account when the time comes to revisit the > alarm MIB, or, if there is sufficient need and support, as an extension > model. Of course, actually chartering such work would be up to the AD. > > Randy Presuhn > disman WG chair > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 22 Nov 2003 14:11:03 +0000 Message-ID: <06bf01c3b100$d4cb3770$db818182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: ASON Routing Requirements to WG doc Date: Sat, 22 Nov 2003 13:54:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit OK. What I'm hearing on this is... - this is work the WG should be doing - the current draft is a good start, but has a lot of blanks to fill in - it is essential that the design team consults fully with - SPs - the appropriate ITU-T SGs - the authors fully intend to consult. Given this, I think we're ready to make this a WG draft. Authors, please republish the existing version as a WG draft, and then fill in those blanks. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Nov 2003 20:51:35 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE622F@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'John Drake' , "'ccamp@ops.ietf.org'" Subject: RE: SPCs Date: Fri, 21 Nov 2003 12:49:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" In California, the up-to-date response might be "I'll be back!" -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Friday, November 21, 2003 4:39 AM To: Ong, Lyndon; 'ccamp@ops.ietf.org' Subject: RE: SPCs To quote a former President, "There you go again". We're done Thanks, John Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Nov 2003 20:50:21 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048DD2@nimbus.chromisys.com> From: John Drake To: 'Jonathan Sadler' Cc: "'Ong, Lyndon'" , "'ccamp@ops.ietf.org'" Subject: RE: SPCs Date: Fri, 21 Nov 2003 12:47:09 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B070.A1EAEF20" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3B070.A1EAEF20 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] Sent: Friday, November 21, 2003 9:24 AM To: John Drake Cc: 'Ong, Lyndon'; 'ccamp@ops.ietf.org' Subject: Re: SPCs John - To paraphrase a previous message in this discussion: Do you keep repeating yourself with the idea that it will make it so? Bringing this back to a technical discussion -- I don't believe that we have agreement regarding 3473 and: - a concept of call with call attributes (3474 handles this using the Generalized_UNI object) JD: No one claimed RFC3471/3473 supported calls. That's why we have draft-dimitri-ccamp-gmpls-rsvp-te-ason. RFC3474 handles one bundled call/connection. - a concept of call addressing that allows service providers to keep network resource names (SNPP and SNP names) and their formats private (3474 handles this through TNA addresses, port identifier and egress label) JD: This is handled in RFC3471/3473. The Sender Template/Session Object identifies the globally unique ingress/egress LSP endpoints. As you indicated, the egress label needs to be known globally, whether it is carried in the Generalized_UNI object or in the last hop of an ERO. Incidentally, the ERO either an RFC 3473 or an RFC 3474 multi-domain network is going to be the same except for the explicit label in the last hop. See http://www.ietf.org/internet-drafts/draft-ayyangar-inter-region-te-01.txt - the handling of SPCs through the same Call process as UNI requests (which has implications for SPC/UNI interworking issues) JD: According to G.7713, an SPC call is established in a completely different manner than an SVC call. Kireeti's proposed text for the overlay draft detailed UNI/SPC connection interworking. Emails on these issues have been sent to the without response. Perhaps we should continue the technical discussion. Jonathan Sadler John Drake wrote: To quote a former President, "There you go again". We're done Thanks, John > -----Original Message----- > From: Ong, Lyndon [ mailto:LyOng@Ciena.com ] > Sent: Thursday, November 20, 2003 11:18 PM > To: John Drake; 'ccamp@ops.ietf.org' > Subject: RE: SPCs > > > Hi John, > > Thanks for reading RFC 3474 :o) Note that it says "may provide > a mechanism" as opposed to "already defines a mechanism". No > one is arguing that explicit label control *cannot* be used > (with "clarification" as the editor has already suggested), > the argument is over whether it is already supported in 3473 > and whether this is the right mechanism compared to > an SPC_Label subobject. > > Note also neither 3471 or 3473 contain the terms "soft permanent > connection", "spc" or "egress label". > > Cheers, > > Lyndon > > > -----Original Message----- > From: John Drake [ mailto:jdrake@calient.net ] > Sent: Thursday, November 20, 2003 8:08 AM > To: 'ccamp@ops.ietf.org' > Subject: SPCs > > > I thought it might be useful to see what RFC3474 actually > says about SPCs: > > "The processing of the SPC_LABEL sub-object follows that of the > EGRESS_LABEL sub-object [OIF-UNI1]. Note that although > the explicit > label control described in [RFC3471] and [RFC3473] may provide a > mechanism to support specifying the egress label in the context of > supporting the GMPLS application, the SPC services support for the > ASON model uses the GENERALIZED_UNI object for this > extension to help > align the model for both switched connection and soft permanent > connection, as well as to use the service level and diversity > attributes of the GENERALIZED_UNI object." > > A few observations: > > 1) I don't think any clarifications to RFC3471/3473 wrt egress node > explicit label > control are required. If the authors of RFC3474 can figure > out the correct > behavior, > I'm sure anyone else can. > > 2) Any divergence between RFC3471/3473 and RFC3474 is clearly the > responsibility > of the authors of RFC3474. > > 3) 'call' vs 'connection' is not cited as one of the reasons for this > divergence. > In fact, once again 'connection' is used in the text. (I'm > not surprised, > as the > GENERALIZED_UNI object was defined in OIF UNI 1.0, which > doesn't support > calls.) > > 4) The diversity attribute is completely useless in the > multi-domain case, > since > it is a list of connections within the context of a specific > UNI. No border > node > is going to have any way to identify those connections or > determine how they > are > routed. > > 5) I thought "the SPC services support for the ASON model uses the > GENERALIZED_UNI > object" was rather imperious. It's pretty clear that the > GENERALIZED_UNI > object > is not required by the ASON model. > > Thanks, > > John > > John Drake > Calient Networks > 5853 Rue Ferrari > San Jose, CA 95138 > jdrake@calient.net > 408 972-3720 > _____ ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ ------_=_NextPart_001_01C3B070.A1EAEF20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
-----Original Message-----
From: Jonathan Sadler=20 [mailto:jonathan.sadler@tellabs.com]
Sent: Friday, November = 21, 2003=20 9:24 AM
To: John Drake
Cc: 'Ong, Lyndon';=20 'ccamp@ops.ietf.org'
Subject: Re: = SPCs

John=20 -=20

To paraphrase a previous message in this discussion:=20
  Do you keep repeating yourself with the idea that it = will make=20 it so?=20

Bringing this back to a technical discussion -- I don't = believe=20
that we have agreement regarding 3473 and: =
  - a=20 concept of call with call attributes (3474 handles this=20
      using the Generalized_UNI = object) 

JD:  No one claimed = RFC3471/3473=20 supported calls.  That's why

we have=20 draft-dimitri-ccamp-gmpls-rsvp-te-ason.  RFC3474 = handles

one bundled=20 call/connection.

  
  - a = concept of=20 call addressing that allows service providers to=20
      keep network resource names = (SNPP and=20 SNP names) and their formats =
     =20 private (3474 handles this through TNA addresses, port = identifier=20
      and egress = label)  

JD:  This is handled in RFC3471/3473.  The Sender=20 Template/Session Object identifies the globally

unique=20 ingress/egress LSP endpoints.  As you indicated, the egress = label needs=20 to be known globally,

whether it is carried in the Generalized_UNI object or in = the last hop=20 of an ERO.  Incidentally, the

ERO=20 either an RFC 3473 or an RFC 3474 multi-domain network is going to be = the same=20 except for

the=20 explicit label in the last hop.  See http://www.ietf.org/internet-drafts/draft-ayyangar-inter-regi= on-te-01.txt

 

 
  - the = handling=20 of SPCs through the same Call process as UNI requests=20
      (which has implications for = SPC/UNI=20 interworking issues) 

JD:  According to = G.7713, an SPC=20 call is established in a completely

different manner than an SVC = call. =20 Kireeti's proposed text for the

overlay draft = detailed UNI/SPC=20 connection interworking.

 

 

Emails on these issues have been sent to the without = response. =20 Perhaps we should continue the technical discussion.=20

Jonathan Sadler=20

John Drake wrote:=20

To quote a former President, "There you go = again".=20

We're done=20

Thanks,=20

John=20

> -----Original Message-----
> From: Ong, Lyndon [mailto:LyOng@Ciena.com] =
> Sent:=20 Thursday, November 20, 2003 11:18 PM
> To: John Drake;=20 'ccamp@ops.ietf.org'
> Subject: RE: SPCs
>
> =
>=20 Hi John,
>
> Thanks for reading RFC 3474 :o)  = Note that=20 it says "may provide
> a mechanism" as opposed to "already = defines a=20 mechanism". No
> one is arguing that explicit label control = *cannot*=20 be used
> (with "clarification" as the editor has already = suggested),=20
> the argument is over whether it is already supported in = 3473=20
> and whether this is the right mechanism compared to =
> an=20 SPC_Label subobject.
>
> Note also neither 3471 or = 3473=20 contain the terms "soft permanent
> connection", "spc" or = "egress=20 label".
>
> Cheers,
>
> Lyndon
> =
>=20
> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net] =
>=20 Sent: Thursday, November 20, 2003 8:08 AM
> To: = 'ccamp@ops.ietf.org'=20
> Subject: SPCs
>
>
> I thought it = might be=20 useful to see what RFC3474 actually
> says about SPCs: =
>=20
> "The processing of the SPC_LABEL sub-object follows that = of the=20
>    EGRESS_LABEL sub-object = [OIF-UNI1].  Note=20 that although
> the explicit
>    = label control=20 described in [RFC3471] and [RFC3473] may provide a=20
>    mechanism to support specifying the = egress label=20 in the context of
>    supporting the GMPLS=20 application, the SPC services support for the =
>   =20 ASON model uses the GENERALIZED_UNI object for this
> = extension to=20 help
>    align the model for both switched = connection=20 and soft permanent
>    connection, as well = as to use=20 the service level and diversity
>    = attributes of the=20 GENERALIZED_UNI object."
>
> A few observations: =
>=20
> 1)  I don't think any clarifications to RFC3471/3473 = wrt=20 egress node
> explicit label
> control are = required.  If=20 the authors of RFC3474 can figure
> out the correct
> = behavior,
> I'm sure anyone else can.
>
> = 2)  Any=20 divergence between RFC3471/3473 and RFC3474 is clearly the
> = responsibility
> of the authors of RFC3474.
> =
>=20 3)  'call' vs 'connection' is not cited as one of the reasons = for this=20
> divergence.
> In fact, once again 'connection' is = used in=20 the text.  (I'm
> not surprised,
> as the =
>=20 GENERALIZED_UNI object was defined in OIF UNI 1.0, which
> = doesn't=20 support
> calls.)
>
> 4)  The diversity = attribute=20 is completely useless in the
> multi-domain case,
> = since=20
> it is a list of connections within the context of a = specific=20
> UNI.  No border
> node
> is going to = have any=20 way to identify those connections or
> determine how they =
>=20 are
> routed.
>
> 5)  I thought "the SPC = services=20 support for the ASON model uses the
> GENERALIZED_UNI =
>=20 object" was rather imperious.  It's pretty clear that the =
>=20 GENERALIZED_UNI
> object
> is not required by the = ASON model.=20
>
> Thanks,
>
> John
>
> = John=20 Drake
> Calient Networks
> 5853 Rue Ferrari
> = San Jose,=20 CA 95138
> jdrake@calient.net
> 408 972-3720=20
>

=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The=20 information contained in this message may be privileged
and = confidential=20 and protected from disclosure. If the
reader of this message is = not the=20 intended recipient, or an
employee or agent responsible for = delivering=20 this message to
the intended recipient, you are hereby notified = that any=20
reproduction, dissemination or distribution of this =
communication is=20 strictly prohibited. If you have received
this communication in = error,=20 please notify us immediately by
replying to the message and = deleting it=20 from your computer.

Thank=20 = you.
Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C3B070.A1EAEF20-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Nov 2003 17:28:07 +0000 Message-ID: <3FBE4A27.D6649A1E@tellabs.com> Date: Fri, 21 Nov 2003 11:23:51 -0600 From: Jonathan Sadler MIME-Version: 1.0 To: John Drake CC: "'Ong, Lyndon'" , "'ccamp@ops.ietf.org'" Subject: Re: SPCs Content-Type: multipart/alternative; boundary="------------4F8211154EC0216A3B77CE97" --------------4F8211154EC0216A3B77CE97 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John - To paraphrase a previous message in this discussion: Do you keep repeating yourself with the idea that it will make it so? Bringing this back to a technical discussion -- I don't believe that we have agreement regarding 3473 and: - a concept of call with call attributes (3474 handles this using the Generalized_UNI object) - a concept of call addressing that allows service providers to keep network resource names (SNPP and SNP names) and their formats private (3474 handles this through TNA addresses, port identifier and egress label) - the handling of SPCs through the same Call process as UNI requests (which has implications for SPC/UNI interworking issues) Emails on these issues have been sent to the without response. Perhaps we should continue the technical discussion. Jonathan Sadler John Drake wrote: > To quote a former President, "There you go again". > > We're done > > Thanks, > > John > > > -----Original Message----- > > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > > Sent: Thursday, November 20, 2003 11:18 PM > > To: John Drake; 'ccamp@ops.ietf.org' > > Subject: RE: SPCs > > > > > > Hi John, > > > > Thanks for reading RFC 3474 :o) Note that it says "may provide > > a mechanism" as opposed to "already defines a mechanism". No > > one is arguing that explicit label control *cannot* be used > > (with "clarification" as the editor has already suggested), > > the argument is over whether it is already supported in 3473 > > and whether this is the right mechanism compared to > > an SPC_Label subobject. > > > > Note also neither 3471 or 3473 contain the terms "soft permanent > > connection", "spc" or "egress label". > > > > Cheers, > > > > Lyndon > > > > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: Thursday, November 20, 2003 8:08 AM > > To: 'ccamp@ops.ietf.org' > > Subject: SPCs > > > > > > I thought it might be useful to see what RFC3474 actually > > says about SPCs: > > > > "The processing of the SPC_LABEL sub-object follows that of the > > EGRESS_LABEL sub-object [OIF-UNI1]. Note that although > > the explicit > > label control described in [RFC3471] and [RFC3473] may provide a > > mechanism to support specifying the egress label in the context of > > supporting the GMPLS application, the SPC services support for the > > ASON model uses the GENERALIZED_UNI object for this > > extension to help > > align the model for both switched connection and soft permanent > > connection, as well as to use the service level and diversity > > attributes of the GENERALIZED_UNI object." > > > > A few observations: > > > > 1) I don't think any clarifications to RFC3471/3473 wrt egress node > > explicit label > > control are required. If the authors of RFC3474 can figure > > out the correct > > behavior, > > I'm sure anyone else can. > > > > 2) Any divergence between RFC3471/3473 and RFC3474 is clearly the > > responsibility > > of the authors of RFC3474. > > > > 3) 'call' vs 'connection' is not cited as one of the reasons for this > > divergence. > > In fact, once again 'connection' is used in the text. (I'm > > not surprised, > > as the > > GENERALIZED_UNI object was defined in OIF UNI 1.0, which > > doesn't support > > calls.) > > > > 4) The diversity attribute is completely useless in the > > multi-domain case, > > since > > it is a list of connections within the context of a specific > > UNI. No border > > node > > is going to have any way to identify those connections or > > determine how they > > are > > routed. > > > > 5) I thought "the SPC services support for the ASON model uses the > > GENERALIZED_UNI > > object" was rather imperious. It's pretty clear that the > > GENERALIZED_UNI > > object > > is not required by the ASON model. > > > > Thanks, > > > > John > > > > John Drake > > Calient Networks > > 5853 Rue Ferrari > > San Jose, CA 95138 > > jdrake@calient.net > > 408 972-3720 > > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ --------------4F8211154EC0216A3B77CE97 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit John -

To paraphrase a previous message in this discussion:
  Do you keep repeating yourself with the idea that it will make it so?

Bringing this back to a technical discussion -- I don't believe
that we have agreement regarding 3473 and:
  - a concept of call with call attributes (3474 handles this
      using the Generalized_UNI object)
  - a concept of call addressing that allows service providers to
      keep network resource names (SNPP and SNP names) and their formats
      private (3474 handles this through TNA addresses, port identifier
      and egress label)
  - the handling of SPCs through the same Call process as UNI requests
      (which has implications for SPC/UNI interworking issues)

Emails on these issues have been sent to the without response.  Perhaps we should continue the technical discussion.

Jonathan Sadler

John Drake wrote:

To quote a former President, "There you go again".

We're done

Thanks,

John

> -----Original Message-----
> From: Ong, Lyndon [mailto:LyOng@Ciena.com]
> Sent: Thursday, November 20, 2003 11:18 PM
> To: John Drake; 'ccamp@ops.ietf.org'
> Subject: RE: SPCs
>
>
> Hi John,
>
> Thanks for reading RFC 3474 :o)  Note that it says "may provide
> a mechanism" as opposed to "already defines a mechanism". No
> one is arguing that explicit label control *cannot* be used
> (with "clarification" as the editor has already suggested),
> the argument is over whether it is already supported in 3473
> and whether this is the right mechanism compared to
> an SPC_Label subobject.
>
> Note also neither 3471 or 3473 contain the terms "soft permanent
> connection", "spc" or "egress label".
>
> Cheers,
>
> Lyndon
>
>
> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: Thursday, November 20, 2003 8:08 AM
> To: 'ccamp@ops.ietf.org'
> Subject: SPCs
>
>
> I thought it might be useful to see what RFC3474 actually
> says about SPCs:
>
> "The processing of the SPC_LABEL sub-object follows that of the
>    EGRESS_LABEL sub-object [OIF-UNI1].  Note that although
> the explicit
>    label control described in [RFC3471] and [RFC3473] may provide a
>    mechanism to support specifying the egress label in the context of
>    supporting the GMPLS application, the SPC services support for the
>    ASON model uses the GENERALIZED_UNI object for this
> extension to help
>    align the model for both switched connection and soft permanent
>    connection, as well as to use the service level and diversity
>    attributes of the GENERALIZED_UNI object."
>
> A few observations:
>
> 1)  I don't think any clarifications to RFC3471/3473 wrt egress node
> explicit label
> control are required.  If the authors of RFC3474 can figure
> out the correct
> behavior,
> I'm sure anyone else can.
>
> 2)  Any divergence between RFC3471/3473 and RFC3474 is clearly the
> responsibility
> of the authors of RFC3474.
>
> 3)  'call' vs 'connection' is not cited as one of the reasons for this
> divergence.
> In fact, once again 'connection' is used in the text.  (I'm
> not surprised,
> as the
> GENERALIZED_UNI object was defined in OIF UNI 1.0, which
> doesn't support
> calls.)
>
> 4)  The diversity attribute is completely useless in the
> multi-domain case,
> since
> it is a list of connections within the context of a specific
> UNI.  No border
> node
> is going to have any way to identify those connections or
> determine how they
> are
> routed.
>
> 5)  I thought "the SPC services support for the ASON model uses the
> GENERALIZED_UNI
> object" was rather imperious.  It's pretty clear that the
> GENERALIZED_UNI
> object
> is not required by the ASON model.
>
> Thanks,
>
> John
>
> John Drake
> Calient Networks
> 5853 Rue Ferrari
> San Jose, CA 95138
> jdrake@calient.net
> 408 972-3720
>

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

--------------4F8211154EC0216A3B77CE97-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Nov 2003 12:41:22 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048DD0@nimbus.chromisys.com> From: John Drake To: "'Ong, Lyndon'" , "'ccamp@ops.ietf.org'" Subject: RE: SPCs Date: Fri, 21 Nov 2003 04:39:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To quote a former President, "There you go again". We're done Thanks, John > -----Original Message----- > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > Sent: Thursday, November 20, 2003 11:18 PM > To: John Drake; 'ccamp@ops.ietf.org' > Subject: RE: SPCs > > > Hi John, > > Thanks for reading RFC 3474 :o) Note that it says "may provide > a mechanism" as opposed to "already defines a mechanism". No > one is arguing that explicit label control *cannot* be used > (with "clarification" as the editor has already suggested), > the argument is over whether it is already supported in 3473 > and whether this is the right mechanism compared to > an SPC_Label subobject. > > Note also neither 3471 or 3473 contain the terms "soft permanent > connection", "spc" or "egress label". > > Cheers, > > Lyndon > > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Thursday, November 20, 2003 8:08 AM > To: 'ccamp@ops.ietf.org' > Subject: SPCs > > > I thought it might be useful to see what RFC3474 actually > says about SPCs: > > "The processing of the SPC_LABEL sub-object follows that of the > EGRESS_LABEL sub-object [OIF-UNI1]. Note that although > the explicit > label control described in [RFC3471] and [RFC3473] may provide a > mechanism to support specifying the egress label in the context of > supporting the GMPLS application, the SPC services support for the > ASON model uses the GENERALIZED_UNI object for this > extension to help > align the model for both switched connection and soft permanent > connection, as well as to use the service level and diversity > attributes of the GENERALIZED_UNI object." > > A few observations: > > 1) I don't think any clarifications to RFC3471/3473 wrt egress node > explicit label > control are required. If the authors of RFC3474 can figure > out the correct > behavior, > I'm sure anyone else can. > > 2) Any divergence between RFC3471/3473 and RFC3474 is clearly the > responsibility > of the authors of RFC3474. > > 3) 'call' vs 'connection' is not cited as one of the reasons for this > divergence. > In fact, once again 'connection' is used in the text. (I'm > not surprised, > as the > GENERALIZED_UNI object was defined in OIF UNI 1.0, which > doesn't support > calls.) > > 4) The diversity attribute is completely useless in the > multi-domain case, > since > it is a list of connections within the context of a specific > UNI. No border > node > is going to have any way to identify those connections or > determine how they > are > routed. > > 5) I thought "the SPC services support for the ASON model uses the > GENERALIZED_UNI > object" was rather imperious. It's pretty clear that the > GENERALIZED_UNI > object > is not required by the ASON model. > > Thanks, > > John > > John Drake > Calient Networks > 5853 Rue Ferrari > San Jose, CA 95138 > jdrake@calient.net > 408 972-3720 > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Nov 2003 11:22:08 +0000 Subject: I-D ACTION:draft-caviglia-mp2cp-00.txt Sensitivity: To: ccamp@ops.ietf.org From: "Diego Caviglia" Date: Fri, 21 Nov 2003 12:13:54 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi all, I've posted a new ID. Here is the Abstract: This memo introduces a new object for carrying GRSVP-TE labels, namely Mp2Cp Label object. This new object SHOULD be used in order to move under the Control Plane (CP) domain LSPs that were created by the Management Plane (MP). The result of using Mp2Cp Label in GRSVP-TE is that, at the end of the signaling flow, an LSP that was created by Management Plane is moved under to Control Plane domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-caviglia-mp2cp-00.txt Comments are *very* welcome. Regards. Diego Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Nov 2003 11:21:03 +0000 Message-ID: <3FBDF498.7080605@alcatel.be> Date: Fri, 21 Nov 2003 12:18:48 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: "Ong, Lyndon" Cc: "'John Drake'" , "'ccamp@ops.ietf.org'" Subject: Re: SPCs Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed lyndon, Ong, Lyndon wrote: > Hi John, > > Thanks for reading RFC 3474 :o) Note that it says "may provide > a mechanism" as opposed to "already defines a mechanism". No > one is arguing that explicit label control *cannot* be used > (with "clarification" as the editor has already suggested), > the argument is over whether it is already supported in 3473 > and whether this is the right mechanism compared to > an SPC_Label subobject. SPC_Label doesn't come alone, it comes with the G_UNI object and as said below "the GENERALIZED_UNI object is not required by the ASON model" - something that is obviously the case, a functional model is not requiring a specific implementation - however, this paragraph is contradictory wrt to this since it requires the usage of this specific object: ditto: "the SPC services support for the ASON model uses the GENERALIZED_UNI object" thus what you say is that divergence from GMPLS is mandatory to implement SPC for the ASON model whilst it has been shown on this mailing list that this is *not* the case > Note also neither 3471 or 3473 contain the terms "soft permanent > connection", "spc" or "egress label". note also that it doesn't contain the words ASON, or SNP/P or connection, it doesn't mean at all that the the RFC 3471/73 mechanisms aren't applicable to realize this functional model > Cheers, > > Lyndon > > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Thursday, November 20, 2003 8:08 AM > To: 'ccamp@ops.ietf.org' > Subject: SPCs > > > I thought it might be useful to see what RFC3474 actually says about SPCs: > > "The processing of the SPC_LABEL sub-object follows that of the > EGRESS_LABEL sub-object [OIF-UNI1]. Note that although the explicit > label control described in [RFC3471] and [RFC3473] may provide a > mechanism to support specifying the egress label in the context of > supporting the GMPLS application, the SPC services support for the > ASON model uses the GENERALIZED_UNI object for this extension to help > align the model for both switched connection and soft permanent > connection, as well as to use the service level and diversity > attributes of the GENERALIZED_UNI object." > > A few observations: > > 1) I don't think any clarifications to RFC3471/3473 wrt egress node > explicit label > control are required. If the authors of RFC3474 can figure out the correct > behavior, > I'm sure anyone else can. > > 2) Any divergence between RFC3471/3473 and RFC3474 is clearly the > responsibility > of the authors of RFC3474. > > 3) 'call' vs 'connection' is not cited as one of the reasons for this > divergence. > In fact, once again 'connection' is used in the text. (I'm not surprised, > as the > GENERALIZED_UNI object was defined in OIF UNI 1.0, which doesn't support > calls.) > > 4) The diversity attribute is completely useless in the multi-domain case, > since > it is a list of connections within the context of a specific UNI. No border > node > is going to have any way to identify those connections or determine how they > are > routed. > > 5) I thought "the SPC services support for the ASON model uses the > GENERALIZED_UNI > object" was rather imperious. It's pretty clear that the GENERALIZED_UNI > object > is not required by the ASON model. > > Thanks, > > John > > John Drake > Calient Networks > 5853 Rue Ferrari > San Jose, CA 95138 > jdrake@calient.net > 408 972-3720 > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Nov 2003 07:23:22 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE6226@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'John Drake' , "'ccamp@ops.ietf.org'" Subject: RE: SPCs Date: Thu, 20 Nov 2003 23:17:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi John, Thanks for reading RFC 3474 :o) Note that it says "may provide a mechanism" as opposed to "already defines a mechanism". No one is arguing that explicit label control *cannot* be used (with "clarification" as the editor has already suggested), the argument is over whether it is already supported in 3473 and whether this is the right mechanism compared to an SPC_Label subobject. Note also neither 3471 or 3473 contain the terms "soft permanent connection", "spc" or "egress label". Cheers, Lyndon -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Thursday, November 20, 2003 8:08 AM To: 'ccamp@ops.ietf.org' Subject: SPCs I thought it might be useful to see what RFC3474 actually says about SPCs: "The processing of the SPC_LABEL sub-object follows that of the EGRESS_LABEL sub-object [OIF-UNI1]. Note that although the explicit label control described in [RFC3471] and [RFC3473] may provide a mechanism to support specifying the egress label in the context of supporting the GMPLS application, the SPC services support for the ASON model uses the GENERALIZED_UNI object for this extension to help align the model for both switched connection and soft permanent connection, as well as to use the service level and diversity attributes of the GENERALIZED_UNI object." A few observations: 1) I don't think any clarifications to RFC3471/3473 wrt egress node explicit label control are required. If the authors of RFC3474 can figure out the correct behavior, I'm sure anyone else can. 2) Any divergence between RFC3471/3473 and RFC3474 is clearly the responsibility of the authors of RFC3474. 3) 'call' vs 'connection' is not cited as one of the reasons for this divergence. In fact, once again 'connection' is used in the text. (I'm not surprised, as the GENERALIZED_UNI object was defined in OIF UNI 1.0, which doesn't support calls.) 4) The diversity attribute is completely useless in the multi-domain case, since it is a list of connections within the context of a specific UNI. No border node is going to have any way to identify those connections or determine how they are routed. 5) I thought "the SPC services support for the ASON model uses the GENERALIZED_UNI object" was rather imperious. It's pretty clear that the GENERALIZED_UNI object is not required by the ASON model. Thanks, John John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138 jdrake@calient.net 408 972-3720 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Nov 2003 20:29:07 +0000 Message-Id: <200311202026.PAA23720@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-03.txt Date: Thu, 20 Nov 2003 15:26:36 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau Filename : draft-ietf-ccamp-gmpls-te-mib-03.txt Pages : 8 Date : 2003-11-20 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-te-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-20154031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-20154031.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Nov 2003 20:28:51 +0000 Message-Id: <200311202026.PAA23656@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-03.txt Date: Thu, 20 Nov 2003 15:26:04 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switch Router Management Information Base Author(s) : T. Nadeau Filename : draft-ietf-ccamp-gmpls-lsr-mib-03.txt Pages : 34 Date : 2003-11-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSRs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-lsr-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-20154015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-20154015.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Nov 2003 20:28:39 +0000 Message-Id: <200311202025.PAA23568@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-03.txt Date: Thu, 20 Nov 2003 15:25:26 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Definitions of Textual Conventions for Generalized Multi-Protocol Label Switching (GMPLS) Management Author(s) : T. Nadeau Filename : draft-ietf-ccamp-gmpls-tc-mib-03.txt Pages : 8 Date : 2003-11-20 This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multi-Protocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-tc-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-20153943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-20153943.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Nov 2003 17:13:42 +0000 Message-ID: <3FBCF5A6.8060303@lucent.com> Date: Thu, 20 Nov 2003 10:11:02 -0700 From: Stephen J Trowbridge Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: v.sharma@ieee.org, Zafar Ali , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON Routing Requirements to WG doc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Deborah, Of course ITU-T SG15 also sent a copy of G.7715.1 via liaison statement to ccamp. See: http://www.ietf.org/IESG/LIAISON/itut-sg15-ls-ason-status.html This is also available on the ITU ftp site for non-members at: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/ccamp_0310_q14_ason_status.html The copy on the IESG site has icons for the attachments, but for some reason I cannot download them from there. But for those of you who are interested can obtain G.7715.1 from the ITU ftp site. In addition to the document itself, you will find the "living list", which outlines some areas where we envision additional work for a future revision of this document. Regards, Steve Trowbridge On 11/20/2003 9:26 AM, Brungard, Deborah A, ALABS wrote: > Zafar, Vishal, > > Much appreciate the feedback - and the early/early interest in the DT document. > > Regardless if the document is agreed to be a WG doc or not, I hope the interaction between ccamp and the DT continues. Send any comments/clarifications via CCAMP or to one of the DT members directly. This iterative dialogue is needed early in the development if we want to quickly progress. > > As noted on a previous email, G7715.1 on ASON link state routing requirements was just completed in October. The basis of the work was to be protocol agnostic (PNNI, OSPF, ISIS) and solution-independent, and as we all know that can be a very difficult goal. Much late night drafting in Geneva to complete ;-) For companies also ITU members, G7715.1 is available under the AAP process for comments until Dec 13. And via CCAMP's ASON routing work and the liaison process, CCAMP can cooperatively contribute to future improvements/versions of the document. > > Deborah > > -----Original Message----- > From: Vishal Sharma [mailto:v.sharma@ieee.org] > Sent: Monday, November 17, 2003 1:05 PM > To: Zafar Ali; Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: RE: ASON Routing Requirements to WG doc > > > Hi Kireeti, Zafar, et al, > > I think the idea of the DT working co-operatively with the ITU-T, and having some room for > the DT (and CCAMP) to iteratively work on the routing requirements is a very good idea. > > > In fact, this ties back to the comment I had first made when Deborah was drafting the liason > statement on behalf of the WG to send to the ITU-T a few weeks ago. Lyndon had clarified > then that some items in G.7715.1 were themselves "work in progress", so I think this is > the perfect time for CCAMP and IETF to : > (a) study the ASON docs. to determine what more is needed in the GMPLS suite of protocols, > (b) seek clarifications from the ITU-T, and > (c) provide inputs to the ITU-T. > > So, I would definitely support the idea of having the DT (and, in fact, the WG as a whole) > spending some time understanding the ASON routing requirements (instead of merely > adopting them), and, if necessary, providing inputs to the ITU-T SG15 relative to G.7715 > and G.7715.1. > > -Vishal > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Zafar Ali > Sent: Monday, November 17, 2003 7:03 AM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org > Subject: Re: ASON Routing Requirements to WG doc > > > Hi Kireeti, > > I understand that the requirements that fall out of the scope of ITU-T recommendations are NOT part of this document/ work. However, I would like to understand some of the requirements in the document a little better. Specifically, when the document mentions that "- support multiple hierarchical levels", my question how many level of hierarchy is implied here? Similarly, when a requirement like, "- support architectural evolution in terms of the number of levels of hierarchies, aggregation and segmentation of (control ?) domains" is stated, I would like to again understand the notion of "levels of hierarchies". > > In short, I think there are a lots of TBD's in the document that DT will be closing with ITU. I would like to see this as an "interactive" process, rather than something like "here are the requirements, period". I think for the sake of prioritization and for providing cross-organization feedback, it will be very important to have some "room" for DT and ccamp. > > Thanks > > Regards... Zafar > > ================================================================= > Zafar Ali, Ph. D. 100 South Main St. #200, > Technical Leader, Ann Arbor, MI 48104, USA. > Cisco Systems. (734) 276-2459. > ================================================================= > > > At 07:42 PM 11/16/2003 -0800, Kireeti Kompella wrote: > > > Hi Zafar, > > On Sun, 16 Nov 2003, Zafar Ali wrote: > > Thanks for your input! > > >>Deborah made a very good point about goals of the design team during the WG >>meeting. Specifically, she mentioned that the DT will work closely with ITU >>to understand the requirements. > > > Excellent. > > >>I would really like to make sure that the >>requirements are coming from the service providers > > > If you read the design team charter, you'll see that the requirements > come from the ITU, and that requirements *not* from the ITU have no > place, especially since the document is entitled "ASON Routing > Requirements". However, the assumption is that the ITU got their > input from service providers (or carriers). > > >>and not from specific >>implementations. So, I would like to see more activity from the DT in >>closing on the requirements in the light of the needs of service providers, >>before agreeing to the notion. > > > Requirements from specific implementations and requirements that the > DT 'closes on ... [from] service providers' are not relevant in this > particular document. If there is a 'further requirements for GMPLS > routing', your concerns would be very relevant and valuable. > > However, for this document, given the charter of the design team, I > would ask you to reconsider. > > Thanks, > Kireeti. > ------- > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Nov 2003 16:28:10 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON Routing Requirements to WG doc Date: Thu, 20 Nov 2003 10:26:37 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0497B9B7@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON Routing Requirements to WG doc Thread-Index: AcOtNtFhbXP0xPCySdyfumOxYipftwCQo0nw From: "Brungard, Deborah A, ALABS" To: , "Zafar Ali" , "Kireeti Kompella" Cc: Zafar, Vishal, =20 Much appreciate the feedback - and the early/early interest in the DT = document. =20 Regardless if the document is agreed to be a WG doc or not, I hope the = interaction between ccamp and the DT continues. Send any = comments/clarifications via CCAMP or to one of the DT members directly. = This iterative dialogue is needed early in the development if we want to = quickly progress. =20 As noted on a previous email, G7715.1 on ASON link state routing = requirements was just completed in October. The basis of the work was to = be protocol agnostic (PNNI, OSPF, ISIS) and solution-independent, and as = we all know that can be a very difficult goal. Much late night drafting = in Geneva to complete ;-) For companies also ITU members, G7715.1 is = available under the AAP process for comments until Dec 13. And via = CCAMP's ASON routing work and the liaison process, CCAMP can = cooperatively contribute to future improvements/versions of the = document. =20 Deborah -----Original Message----- From: Vishal Sharma [mailto:v.sharma@ieee.org] Sent: Monday, November 17, 2003 1:05 PM To: Zafar Ali; Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: ASON Routing Requirements to WG doc Hi Kireeti, Zafar, et al, =20 I think the idea of the DT working co-operatively with the ITU-T, and = having some room for the DT (and CCAMP) to iteratively work on the routing requirements is a = very good idea. =20 In fact, this ties back to the comment I had first made when Deborah was = drafting the liason statement on behalf of the WG to send to the ITU-T a few weeks ago. = Lyndon had clarified then that some items in G.7715.1 were themselves "work in progress", so = I think this is the perfect time for CCAMP and IETF to : (a) study the ASON docs. to determine what more is needed in the GMPLS = suite of protocols, =20 (b) seek clarifications from the ITU-T, and (c) provide inputs to the ITU-T. =20 So, I would definitely support the idea of having the DT (and, in fact, = the WG as a whole)=20 spending some time understanding the ASON routing requirements (instead = of merely=20 adopting them), and, if necessary, providing inputs to the ITU-T SG15 = relative to G.7715=20 and G.7715.1. =20 -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On = Behalf Of Zafar Ali Sent: Monday, November 17, 2003 7:03 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: ASON Routing Requirements to WG doc Hi Kireeti,=20 I understand that the requirements that fall out of the scope of ITU-T = recommendations are NOT part of this document/ work. However, I would = like to understand some of the requirements in the document a little = better. Specifically, when the document mentions that "- support = multiple hierarchical levels", my question how many level of hierarchy = is implied here? Similarly, when a requirement like, "- support = architectural evolution in terms of the number of levels of hierarchies, = aggregation and segmentation of (control ?) domains" is stated, I would = like to again understand the notion of "levels of hierarchies".=20 In short, I think there are a lots of TBD's in the document that DT will = be closing with ITU. I would like to see this as an "interactive" = process, rather than something like "here are the requirements, period". = I think for the sake of prioritization and for providing = cross-organization feedback, it will be very important to have some = "room" for DT and ccamp.=20 Thanks Regards... Zafar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zafar Ali, Ph. D. 100 South Main St. = #200, Technical Leader, Ann Arbor, MI 48104, = USA. Cisco Systems. (734) 276-2459. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 07:42 PM 11/16/2003 -0800, Kireeti Kompella wrote: Hi Zafar, On Sun, 16 Nov 2003, Zafar Ali wrote: Thanks for your input! > Deborah made a very good point about goals of the design team during = the WG > meeting. Specifically, she mentioned that the DT will work closely = with ITU > to understand the requirements. Excellent. > I would really like to make sure that the > requirements are coming from the service providers If you read the design team charter, you'll see that the requirements come from the ITU, and that requirements *not* from the ITU have no place, especially since the document is entitled "ASON Routing Requirements". However, the assumption is that the ITU got their input from service providers (or carriers). > and not from specific > implementations. So, I would like to see more activity from the DT in > closing on the requirements in the light of the needs of service = providers, > before agreeing to the notion. Requirements from specific implementations and requirements that the DT 'closes on ... [from] service providers' are not relevant in this particular document. If there is a 'further requirements for GMPLS routing', your concerns would be very relevant and valuable. However, for this document, given the charter of the design team, I would ask you to reconsider. Thanks, Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Nov 2003 16:12:43 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048DC3@nimbus.chromisys.com> From: John Drake To: "'ccamp@ops.ietf.org'" Subject: SPCs Date: Thu, 20 Nov 2003 08:08:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I thought it might be useful to see what RFC3474 actually says about SPCs: "The processing of the SPC_LABEL sub-object follows that of the EGRESS_LABEL sub-object [OIF-UNI1]. Note that although the explicit label control described in [RFC3471] and [RFC3473] may provide a mechanism to support specifying the egress label in the context of supporting the GMPLS application, the SPC services support for the ASON model uses the GENERALIZED_UNI object for this extension to help align the model for both switched connection and soft permanent connection, as well as to use the service level and diversity attributes of the GENERALIZED_UNI object." A few observations: 1) I don't think any clarifications to RFC3471/3473 wrt egress node explicit label control are required. If the authors of RFC3474 can figure out the correct behavior, I'm sure anyone else can. 2) Any divergence between RFC3471/3473 and RFC3474 is clearly the responsibility of the authors of RFC3474. 3) 'call' vs 'connection' is not cited as one of the reasons for this divergence. In fact, once again 'connection' is used in the text. (I'm not surprised, as the GENERALIZED_UNI object was defined in OIF UNI 1.0, which doesn't support calls.) 4) The diversity attribute is completely useless in the multi-domain case, since it is a list of connections within the context of a specific UNI. No border node is going to have any way to identify those connections or determine how they are routed. 5) I thought "the SPC services support for the ASON model uses the GENERALIZED_UNI object" was rather imperious. It's pretty clear that the GENERALIZED_UNI object is not required by the ASON model. Thanks, John John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138 jdrake@calient.net 408 972-3720 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Nov 2003 16:01:48 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502FB8068@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Tom Petch , "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org, Randy Presuhn Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Date: Wed, 19 Nov 2003 16:59:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I believe thatthe codepoints we are talking about are not under discussion. Add those are in a TC that is in a separate MIB module in that document and the intent is that IANA (see start of module on page 36) will maintain that module and keep it in sync with ITU-T (in fact values under 1024 are reserved for ITU-T). Hope this clarifies. Thanks, Bert > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: woensdag 19 november 2003 16:21 > To: Wijnen, Bert (Bert) > Cc: ccamp@ops.ietf.org; Randy Presuhn > Subject: Re: Taking to the > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > FYI > > > As a member of the disman WG, I have followed the development > of the alarm mib, > currently draft-ietf-disman-alarm-mib-15.txt, over some years > and this has > included formal liaison with SG4 and some contact with SG15 > over such issues as > who owns the code points and who can define them. SG4 have expressed > satisfaction with the way in which the liaison with disman WG > has worked (as on > the IETF web site). > > But > > 1) not knowing the working procedures of the ITU, I don't > know if the agreement > with disman extends to other IETF WG - the wording suggests not to me. > > 2) the alarm mib is currently under debate between authors > and WG chair with a > list of some 80 issues being resolved; the most difficult to > resolve appear IMO > to be the ones relating to the existence of the ITU alarm table as an > augmentation of the basic disman alarm table (and perhaps > IMHO the lack of > suitable features in SMIv2). The alarm mib is complex, not > one I would expect > people to be able to dip into and readily extract a part thereof. > > 3) I have lost track of the start of this thread and just > what it was that this, > ccamp, WG > wanted to include in what (and my Acrobat viewer renders the > text of the bullet > points in AlarmSpec as black blobs of varying size:-(! But > whatever it is, I > suggest you contact the > disman chair, randy presuhn, to clarify the niceties of any > interaction with the > output of disman, whatever form that finally takes. It may > be that M.3100 > related material should be in a common MIB module and not > included in the alarm > mib because of issues of future updates and cross references > from multiple WGs.. > > I think this is known as cross-functional review:-) > > Tom Petch > > > -----Original Message----- > From: Wijnen, Bert (Bert) > To: Brungard, Deborah A, ALABS ; Wijnen, > Bert (Bert) > ; Adrian Farrel ; Lou Berger > > Cc: ccamp@ops.ietf.org > Date: 18 November 2003 23:10 > Subject: RE: Taking to the > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > >the disman mib has enumerations I believe! > > > >Thanks, > >Bert > > > >> -----Original Message----- > >> From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > >> Sent: dinsdag 18 november 2003 23:06 > >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger > >> Cc: ccamp@ops.ietf.org > >> Subject: RE: Taking to the > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > >> > >> > >> Thanks Bert. > >> > >> M.3100 provides the generic information model, X.733 and > >> X.736 define OSI generics pointing to X.721, and X.721 > >> provides abstract syntax. We were looking for an enumeration > >> to use vs. needing to support abstract syntax strings in > >> signaling. Any suggestions are welcome. > >> Deborah > >> > >> -----Original Message----- > >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > >> Sent: Tuesday, November 11, 2003 11:46 AM > >> To: Adrian Farrel; Lou Berger > >> Cc: ccamp@ops.ietf.org > >> Subject: RE: Taking to the > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > >> > >> > >> Things to potentially look at: > >> > >> draft-ietf-disman-alarm-mib-15.txt > >> > >> [M.3100] ITU Recommendation M.3100, "Generic Network > Information > >> Model", 1995 > >> > >> [X.733] ITU Recommendation X.733, "Information > Technology - Open > >> Systems Interconnection - System Management: Alarm > >> Reporting Function", 1992 > >> > >> [X.736] ITU Recommendation X.736, "Information > Technology - Open > >> Systems Interconnection - System Management: Security > >> Alarm Reporting Function", 1992 > >> > >> Thanks, > >> Bert > >> > >> > -----Original Message----- > >> > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> > Sent: dinsdag 11 november 2003 17:28 > >> > To: Lou Berger > >> > Cc: ccamp@ops.ietf.org > >> > Subject: Re: Taking to the > >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > >> > > >> > > >> > Lou, > >> > > >> > I believe the alarm reference was M.3100. > >> > > >> > Can someone confirm? > >> > > >> > Adrian > >> > > >> > > >> > > In the morning's meeting the AD's asked to bring the > >> proposed Alarm > >> > > communication extension to "the list". For today's > >> > presentation see: > >> > > http://www.labn.net/docs/AlarmSpec00.pdf > >> > > > >> > > I believe the issues to be discussed are: > >> > > 1) Is there general interest in this work? > >> > > 2) Should the usage of new TLVs in Error_Spec be permitted? > >> > > (We think there's some value, particularly with string > >> > > and timestamp) > >> > > 3) Are there good references for alarm code points? > >> > > > >> > > Thank, > >> > > Lou (and co-authors) > >> > > >> > > >> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Nov 2003 15:38:48 +0000 Message-ID: <002801c3aeb2$64db2100$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Wijnen, Bert (Bert)" Cc: , "Randy Presuhn" Subject: Re: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Date: Wed, 19 Nov 2003 15:20:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI As a member of the disman WG, I have followed the development of the alarm mib, currently draft-ietf-disman-alarm-mib-15.txt, over some years and this has included formal liaison with SG4 and some contact with SG15 over such issues as who owns the code points and who can define them. SG4 have expressed satisfaction with the way in which the liaison with disman WG has worked (as on the IETF web site). But 1) not knowing the working procedures of the ITU, I don't know if the agreement with disman extends to other IETF WG - the wording suggests not to me. 2) the alarm mib is currently under debate between authors and WG chair with a list of some 80 issues being resolved; the most difficult to resolve appear IMO to be the ones relating to the existence of the ITU alarm table as an augmentation of the basic disman alarm table (and perhaps IMHO the lack of suitable features in SMIv2). The alarm mib is complex, not one I would expect people to be able to dip into and readily extract a part thereof. 3) I have lost track of the start of this thread and just what it was that this, ccamp, WG wanted to include in what (and my Acrobat viewer renders the text of the bullet points in AlarmSpec as black blobs of varying size:-(! But whatever it is, I suggest you contact the disman chair, randy presuhn, to clarify the niceties of any interaction with the output of disman, whatever form that finally takes. It may be that M.3100 related material should be in a common MIB module and not included in the alarm mib because of issues of future updates and cross references from multiple WGs.. I think this is known as cross-functional review:-) Tom Petch -----Original Message----- From: Wijnen, Bert (Bert) To: Brungard, Deborah A, ALABS ; Wijnen, Bert (Bert) ; Adrian Farrel ; Lou Berger Cc: ccamp@ops.ietf.org Date: 18 November 2003 23:10 Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt >the disman mib has enumerations I believe! > >Thanks, >Bert > >> -----Original Message----- >> From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] >> Sent: dinsdag 18 november 2003 23:06 >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger >> Cc: ccamp@ops.ietf.org >> Subject: RE: Taking to the >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt >> >> >> Thanks Bert. >> >> M.3100 provides the generic information model, X.733 and >> X.736 define OSI generics pointing to X.721, and X.721 >> provides abstract syntax. We were looking for an enumeration >> to use vs. needing to support abstract syntax strings in >> signaling. Any suggestions are welcome. >> Deborah >> >> -----Original Message----- >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >> Sent: Tuesday, November 11, 2003 11:46 AM >> To: Adrian Farrel; Lou Berger >> Cc: ccamp@ops.ietf.org >> Subject: RE: Taking to the >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt >> >> >> Things to potentially look at: >> >> draft-ietf-disman-alarm-mib-15.txt >> >> [M.3100] ITU Recommendation M.3100, "Generic Network Information >> Model", 1995 >> >> [X.733] ITU Recommendation X.733, "Information Technology - Open >> Systems Interconnection - System Management: Alarm >> Reporting Function", 1992 >> >> [X.736] ITU Recommendation X.736, "Information Technology - Open >> Systems Interconnection - System Management: Security >> Alarm Reporting Function", 1992 >> >> Thanks, >> Bert >> >> > -----Original Message----- >> > From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> > Sent: dinsdag 11 november 2003 17:28 >> > To: Lou Berger >> > Cc: ccamp@ops.ietf.org >> > Subject: Re: Taking to the >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt >> > >> > >> > Lou, >> > >> > I believe the alarm reference was M.3100. >> > >> > Can someone confirm? >> > >> > Adrian >> > >> > >> > > In the morning's meeting the AD's asked to bring the >> proposed Alarm >> > > communication extension to "the list". For today's >> > presentation see: >> > > http://www.labn.net/docs/AlarmSpec00.pdf >> > > >> > > I believe the issues to be discussed are: >> > > 1) Is there general interest in this work? >> > > 2) Should the usage of new TLVs in Error_Spec be permitted? >> > > (We think there's some value, particularly with string >> > > and timestamp) >> > > 3) Are there good references for alarm code points? >> > > >> > > Thank, >> > > Lou (and co-authors) >> > >> > >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Nov 2003 01:18:56 +0000 Message-ID: <3FBAC46C.6000607@alcatel.be> Date: Wed, 19 Nov 2003 02:16:28 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: "Ash, Gerald R (Jerry), ALABS" Cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON Routing Requirements to WG doc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi jerry, > a. the list of requirements in Section 4 repeats the list in Section 3. agreed, we'll cap the Section 4 list and keep a single version of it w/i Section 3. > b. need to list all the authors in Section 9. ok, thanks, - dimitri. > Thanks, > Jerry > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 23:43:58 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048DB4@nimbus.chromisys.com> From: John Drake To: "'Lazer, Monica A, ALABS'" , Ben Mack-Crane , Yakov Rekhter Cc: "Ong, Lyndon" , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: spc connections Date: Tue, 18 Nov 2003 15:42:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Monica, Regardless of whether you're dealing with one or multiple domains, you will need a directory function that provides a mapping between AID and IP address. Have you studied RFC2858 and 'draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-04.txt'? Thanks, John > -----Original Message----- > From: Lazer, Monica A, ALABS [mailto:mlazer@att.com] > Sent: Tuesday, November 18, 2003 2:50 PM > To: Ben Mack-Crane; Yakov Rekhter > Cc: Ong, Lyndon; Kireeti Kompella; ccamp@ops.ietf.org > Subject: RE: spc connections > > > All, > I would like to bring in an operations perspective. > The request coming from the management plane, in TMN > architecture, will > start as an A-Z provisioning request from the NMS to an EMS > (the EMS of > the NEs including the ingress node), which in turn passes the > request to > the ingress NE. The A and Z points in NMS are known by their > AID, which > is a naming scheme based on physical location. If both ingress and > egress are not within the same domain, the EMS of the ingress > NE may not > have the ability to translate the Z point AID to an IP address. > > So would anyone take a stab at going through some > inter-domain examples > for this situation? > > Thank you, > > Monica > > -----Original Message----- > From: Ben Mack-Crane [mailto:ben.mack-crane@tellabs.com] > Sent: Tuesday, November 18, 2003 12:24 PM > To: Yakov Rekhter > Cc: Ong, Lyndon; 'John Drake'; 'Kireeti Kompella'; ccamp@ops.ietf.org > Subject: Re: spc connections > > So far, I see the following flaws in the proposed text: > > 1) No provision has been made to handle endpoint identifiers > that are not internal network addresses. > > 2) The text does not address inter domain cases; those in which > the ingress and egress endpoints are in different domains which > do not publish their internal addresses to each other. > > 3) Kireeti's proposed text unnecessarily overrides a processing > rule in rfc3473. > > 4) Lou's text still refers to creation of a new LabelSet object. > > 5) The procedures for handling the case in which a core network > does not (by policy) accept route information from the ingress > edge but must accept endpoint identification in an ERO must be > elaborated, both for the case of an endpoint in that core network > and the case of an endpoint in another domain that does not > publish internal addressing. > > Regards, > Ben > > Yakov Rekhter wrote: > > >Lyndon, > > > > > > > >>-----Original Message----- > >>From: John Drake [mailto:jdrake@calient.net] > >>Sent: Monday, November 17, 2003 1:06 PM > >>To: Ong, Lyndon; 'Kireeti Kompella' > >>Cc: ccamp@ops.ietf.org > >>Subject: RE: spc connections > >> > >> > >>>I understand that you have many aspects to weigh, and 7713.2 is > >>>only one of them. However, the SPC Label procedure is one where > >>>there have been no technical issues, and it has been implemented > >>>and tested. Other people on the list have concluded that there > >>>is a reasonable case for separating this from the ERO, and it is > >>>not in fact supported by the current procedures in 3473. > >>> > >>> > >>JD: Do you think that if you continue saying this that it will > somehow > >>become true? > >> > >>LYO: Yes, I believe that discussing issues on the mailing list may > actually > >>lead to some better understanding and common agreement :o) > >> > >> > > > >It certainly lead to better understanding - Lou's proposed text is > >the proof of this. Ditto for Kireeti's proposed text. > > > >And now, since we do have the text, unless the text has *technical* > >flaws I would suggest to close the discussion. > > > >Yakov. > > > > > > > > > > ----------------------------------------- > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 23:34:16 +0000 Message-Id: <4.3.2.7.2.20031118183052.049f9d00@mo-ex1> Date: Tue, 18 Nov 2003 18:33:19 -0500 To: "Ong, Lyndon" From: Lou Berger Subject: RE: spc connections Cc: "Brungard, Deborah A, ALABS" , "Kireeti Kompella" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Lyndon, As previously mentioned, the authors of RFC3471/3 firmly believed that edge control *is* included in those documents. Lou At 04:43 PM 11/18/2003, Ong, Lyndon wrote: >Hi Deborah, > >I was hoping to avoid interworking for SPC service, esp. >as 3473 does not explicitly support carrying an SPC Label >so there would be no conflict if we used a new object. > >It seems to be turning out that people have gone ahead >with something based on an extension/clarification >to 3473 that still needs to be documented (is there at least >running code somewhere?). Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 23:28:58 +0000 Message-Id: <4.3.2.7.2.20031118182644.05007ee8@mo-ex1> Date: Tue, 18 Nov 2003 18:27:43 -0500 To: "Wijnen, Bert (Bert)" From: Lou Berger Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Cc: "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , "Adrian Farrel" , "Berger, Lou" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Just looked at page 37. looks like a great list! Much thanks, Lou At 06:05 PM 11/18/2003, Wijnen, Bert (Bert) wrote: >the disman mib has enumerations I believe! > >Thanks, >Bert > > > -----Original Message----- > > From: Brungard, Deborah A, ALABS > [mailto:dbrungard@att.com] > > Sent: dinsdag 18 november 2003 23:06 > > To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger > > Cc: ccamp@ops.ietf.org > > Subject: RE: Taking to the > > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > > > > Thanks Bert. > > > > M.3100 provides the generic information model, X.733 and > > X.736 define OSI generics pointing to X.721, and X.721 > > provides abstract syntax. We were looking for an enumeration > > to use vs. needing to support abstract syntax strings in > > signaling. Any suggestions are welcome. > > Deborah > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) > [mailto:bwijnen@lucent.com] > > Sent: Tuesday, November 11, 2003 11:46 AM > > To: Adrian Farrel; Lou Berger > > Cc: ccamp@ops.ietf.org > > Subject: RE: Taking to the > > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > > > > Things to potentially look at: > > > > draft-ietf-disman-alarm-mib-15.txt > > > > [M.3100] ITU Recommendation M.3100, "Generic Network Information > > Model", 1995 > > > > [X.733] ITU Recommendation X.733, "Information Technology - Open > > Systems Interconnection - System Management: Alarm > > Reporting Function", 1992 > > > > [X.736] ITU Recommendation X.736, "Information Technology - Open > > Systems Interconnection - System Management: Security > > Alarm Reporting Function", 1992 > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Adrian Farrel > [mailto:adrian@olddog.co.uk] > > > Sent: dinsdag 11 november 2003 17:28 > > > To: Lou Berger > > > Cc: ccamp@ops.ietf.org > > > Subject: Re: Taking to the > > > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > > > > > > > Lou, > > > > > > I believe the alarm reference was M.3100. > > > > > > Can someone confirm? > > > > > > Adrian > > > > > > > > > > In the morning's meeting the AD's asked to bring the > > proposed Alarm > > > > communication extension to "the list". For today's > > > presentation see: > > > > > http://www.labn.net/docs/AlarmSpec00.pdf > > > > > > > > > I believe the issues to be discussed are: > > > > 1) Is there general interest in this work? > > > > 2) Should the usage of new TLVs in Error_Spec be permitted? > > > > (We think there's some value, particularly with string > > > > and timestamp) > > > > 3) Are there good references for alarm code points? > > > > > > > > Thank, > > > > Lou (and co-authors) > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 23:07:06 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502FB7E26@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , Adrian Farrel , Lou Berger Cc: ccamp@ops.ietf.org Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Date: Wed, 19 Nov 2003 00:05:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" the disman mib has enumerations I believe! Thanks, Bert > -----Original Message----- > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > Sent: dinsdag 18 november 2003 23:06 > To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger > Cc: ccamp@ops.ietf.org > Subject: RE: Taking to the > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > Thanks Bert. > > M.3100 provides the generic information model, X.733 and > X.736 define OSI generics pointing to X.721, and X.721 > provides abstract syntax. We were looking for an enumeration > to use vs. needing to support abstract syntax strings in > signaling. Any suggestions are welcome. > Deborah > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, November 11, 2003 11:46 AM > To: Adrian Farrel; Lou Berger > Cc: ccamp@ops.ietf.org > Subject: RE: Taking to the > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > Things to potentially look at: > > draft-ietf-disman-alarm-mib-15.txt > > [M.3100] ITU Recommendation M.3100, "Generic Network Information > Model", 1995 > > [X.733] ITU Recommendation X.733, "Information Technology - Open > Systems Interconnection - System Management: Alarm > Reporting Function", 1992 > > [X.736] ITU Recommendation X.736, "Information Technology - Open > Systems Interconnection - System Management: Security > Alarm Reporting Function", 1992 > > Thanks, > Bert > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: dinsdag 11 november 2003 17:28 > > To: Lou Berger > > Cc: ccamp@ops.ietf.org > > Subject: Re: Taking to the > > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > > > > Lou, > > > > I believe the alarm reference was M.3100. > > > > Can someone confirm? > > > > Adrian > > > > > > > In the morning's meeting the AD's asked to bring the > proposed Alarm > > > communication extension to "the list". For today's > > presentation see: > > > http://www.labn.net/docs/AlarmSpec00.pdf > > > > > > I believe the issues to be discussed are: > > > 1) Is there general interest in this work? > > > 2) Should the usage of new TLVs in Error_Spec be permitted? > > > (We think there's some value, particularly with string > > > and timestamp) > > > 3) Are there good references for alarm code points? > > > > > > Thank, > > > Lou (and co-authors) > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 22:51:58 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: spc connections Date: Tue, 18 Nov 2003 17:50:20 -0500 Message-ID: <7843C5FB69F36B43BC99B7C6379B460504394644@ACCLUST04EVS1.ugd.att.com> Thread-Topic: spc connections Thread-Index: AcOt+d/AzN3+J4R8TfCm0EoUs18gDAAHPU4Q From: "Lazer, Monica A, ALABS" To: "Ben Mack-Crane" , "Yakov Rekhter" Cc: "Ong, Lyndon" , "Kireeti Kompella" , All, I would like to bring in an operations perspective. The request coming from the management plane, in TMN architecture, will start as an A-Z provisioning request from the NMS to an EMS (the EMS of the NEs including the ingress node), which in turn passes the request to the ingress NE. The A and Z points in NMS are known by their AID, which is a naming scheme based on physical location. If both ingress and egress are not within the same domain, the EMS of the ingress NE may not have the ability to translate the Z point AID to an IP address.=20 So would anyone take a stab at going through some inter-domain examples for this situation? Thank you, Monica=20 -----Original Message----- From: Ben Mack-Crane [mailto:ben.mack-crane@tellabs.com] Sent: Tuesday, November 18, 2003 12:24 PM To: Yakov Rekhter Cc: Ong, Lyndon; 'John Drake'; 'Kireeti Kompella'; ccamp@ops.ietf.org Subject: Re: spc connections So far, I see the following flaws in the proposed text: 1) No provision has been made to handle endpoint identifiers that are not internal network addresses. 2) The text does not address inter domain cases; those in which the ingress and egress endpoints are in different domains which do not publish their internal addresses to each other. 3) Kireeti's proposed text unnecessarily overrides a processing rule in rfc3473. 4) Lou's text still refers to creation of a new LabelSet object. 5) The procedures for handling the case in which a core network does not (by policy) accept route information from the ingress edge but must accept endpoint identification in an ERO must be elaborated, both for the case of an endpoint in that core network and the case of an endpoint in another domain that does not publish internal addressing. Regards, Ben Yakov Rekhter wrote: >Lyndon, > >=20 > >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Monday, November 17, 2003 1:06 PM >>To: Ong, Lyndon; 'Kireeti Kompella' >>Cc: ccamp@ops.ietf.org >>Subject: RE: spc connections >> =20 >> >>>I understand that you have many aspects to weigh, and 7713.2 is >>>only one of them. However, the SPC Label procedure is one where >>>there have been no technical issues, and it has been implemented >>>and tested. Other people on the list have concluded that there >>>is a reasonable case for separating this from the ERO, and it is >>>not in fact supported by the current procedures in 3473. >>> =20 >>> >>JD: Do you think that if you continue saying this that it will somehow >>become true? >> >>LYO: Yes, I believe that discussing issues on the mailing list may actually >>lead to some better understanding and common agreement :o)=20 >> =20 >> > >It certainly lead to better understanding - Lou's proposed text is >the proof of this. Ditto for Kireeti's proposed text. > >And now, since we do have the text, unless the text has *technical* >flaws I would suggest to close the discussion. > >Yakov. > >=20 > ----------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 22:15:07 +0000 Message-ID: <3FBA9995.357AD550@tellabs.com> Date: Tue, 18 Nov 2003 16:13:41 -0600 From: Jonathan Sadler MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: Kireeti Kompella , "Ong, Lyndon" , ccamp@ops.ietf.org Subject: Re: spc connections Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi Deborah - "Brungard, Deborah A, ALABS" wrote: > It's been a long thread and I am not sure anymore what we are discussing: > > - use of the ERO for SPC? Can you be more specific on your concerns as this is where OIF/ITU chose for a different implementation. We need to understand if it resulted from an unclear description or technical concern (as both Yakov and Kireeti requested). As pointed out in previous emails, the ERO is a Connection object (corresponding with G.7713's Explicit Resource List), while the identification of the link connection to be used at the far end of an SPC is a Call parameter. This identification has no relevance to any of the connections used to deliver the SPC, making it reasonable to put it in the Call object (aka. Generalized UNI object). As also pointed out in previous emails, neighboring domains may enforce a high trust boundary, resuting in EROs being ignored since they prescribe the resources to be used in the neighboring domain when routing a connection. Finally, two neighboring domains involved in routing a call are allowed in G.8080 to use private name spaces for their SNPs. This privicy may be used to facilitate information hiding, or to eliminate the need for internal name coordination. The ERO causes problems with this as it requires SNP names to be exposed, removing the ability keep such naming private. These are some of the reasons that the OIF/ITU chose a different implementation than what has been discussed recently on the list. > - use of G7713.2 (3474) as a solution? This is also a needed discussion item to progress the ASON signaling work. > > On the use of G7713.2: we all agree it provides a *solution*. The question is - is a G7713.2 network overlay (not to be confused with the GMPLS overlay model) the only solution needed? Or do we need a 3473 solution? As stated in the 3473/3474 draft, the solution in G.7713.2 is not incompatible with nodes only implementing 3473. These nodes may sit between two G.7713.2 speakers with no problems. > Your 3473/3474 interworking draft and the new appendix added to the draft on GMPLS signalling for ASON both describe the 3473/3474 differences. The key driver for defining new 3474 objects was the implementation decision to support multiple addresses (IPv4, IPv6, NSAP) in the protocol objects (vs. address mapping at ingress/egress (e.g. G7713.1 ASON PNNI's implementation)). Actually, the key driver for new objects was the introduction of calls. The fact that endpoint addresses used for calls may take format other than IPv4 was in response to carrier's requests. Placing these addresses into the call object is appropriate as they are not necessarily the endpoints of individual connections. As for your characterization of G.7713.1 as "simpler", there are a number of reasons that G.7713.1 didn't need to make a large number of changes. Specifically: o G.7713.1 did not need to introduce IEs to handle the call/connection separation already in PNNI. o G.7713.1 utilizes NSAP addresses for endpoint addressing for which IPv6 is a subspace (AFI=35, see ISO 8348/Amd.1:1998). IPv4 is a further subspace of IPv6. (See IPv4-mapped IPv6 addresses in RFC 3513) Consequently, no additional address formats needed to be introduced in G.7713.1. Please also note that G.7713.1 scope is limited to SPCs, not Switched Connections. (This is stated in the summary for the document.) It is interesting to note that the specification of SPC endpoints (ie. the Calling and Called Party Number IEs) is still done with Call information, and not SNP names. Further note that the egress link connection is not specified using the DTL (PNNI's equivalent of G.7713's Explict Resource List). I hope this brings some clarity to the discussion. Jonathan Sadler > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 22:07:20 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Date: Tue, 18 Nov 2003 16:06:11 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0497B9B1@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Thread-Index: AcOoc9Ppv8mnSg18Qd++PcPF8Gz/6AFnkQiw From: "Brungard, Deborah A, ALABS" To: "Wijnen, Bert (Bert)" , "Adrian Farrel" , "Lou Berger" Cc: Thanks Bert. M.3100 provides the generic information model, X.733 and X.736 define = OSI generics pointing to X.721, and X.721 provides abstract syntax. We = were looking for an enumeration to use vs. needing to support abstract = syntax strings in signaling. Any suggestions are welcome. Deborah -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, November 11, 2003 11:46 AM To: Adrian Farrel; Lou Berger Cc: ccamp@ops.ietf.org Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Things to potentially look at: draft-ietf-disman-alarm-mib-15.txt [M.3100] ITU Recommendation M.3100, "Generic Network Information Model", 1995 [X.733] ITU Recommendation X.733, "Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function", 1992 [X.736] ITU Recommendation X.736, "Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function", 1992 Thanks, Bert=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: dinsdag 11 november 2003 17:28 > To: Lou Berger > Cc: ccamp@ops.ietf.org > Subject: Re: Taking to the > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt >=20 >=20 > Lou, >=20 > I believe the alarm reference was M.3100. >=20 > Can someone confirm? >=20 > Adrian >=20 >=20 > > In the morning's meeting the AD's asked to bring the proposed Alarm=20 > > communication extension to "the list". For today's=20 > presentation see: > > http://www.labn.net/docs/AlarmSpec00.pdf > >=20 > > I believe the issues to be discussed are: > > 1) Is there general interest in this work? > > 2) Should the usage of new TLVs in Error_Spec be permitted? > > (We think there's some value, particularly with string > > and timestamp) > > 3) Are there good references for alarm code points? > >=20 > > Thank, > > Lou (and co-authors) >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 21:45:35 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE6202@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'Brungard, Deborah A, ALABS'" , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: spc connections Date: Tue, 18 Nov 2003 13:43:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Deborah, I was hoping to avoid interworking for SPC service, esp. as 3473 does not explicitly support carrying an SPC Label so there would be no conflict if we used a new object. It seems to be turning out that people have gone ahead with something based on an extension/clarification to 3473 that still needs to be documented (is there at least running code somewhere?). It then becomes an interworking issue for the 3473-3474 document. BTW, I think you're being too simplistic in your analysis of 7713.2, the main differences are architectural (multi- vs. single session) rather than implementation. Cheers, Lyndon -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Tuesday, November 18, 2003 8:26 AM To: Kireeti Kompella; Ong, Lyndon Cc: ccamp@ops.ietf.org Subject: RE: spc connections Lyndon, It's been a long thread and I am not sure anymore what we are discussing: - use of the ERO for SPC? Can you be more specific on your concerns as this is where OIF/ITU chose for a different implementation. We need to understand if it resulted from an unclear description or technical concern (as both Yakov and Kireeti requested). - use of G7713.2 (3474) as a solution? This is also a needed discussion item to progress the ASON signaling work. On the use of G7713.2: we all agree it provides a *solution*. The question is - is a G7713.2 network overlay (not to be confused with the GMPLS overlay model) the only solution needed? Or do we need a 3473 solution? Your 3473/3474 interworking draft and the new appendix added to the draft on GMPLS signalling for ASON both describe the 3473/3474 differences. The key driver for defining new 3474 objects was the implementation decision to support multiple addresses (IPv4, IPv6, NSAP) in the protocol objects (vs. address mapping at ingress/egress (e.g. G7713.1 ASON PNNI's implementation)). Multiple family address resolution/management and support of the new objects are part of 3474 node processing (regardless if one is tunneling a new transparent object as an overlay/terminating or if one is using IP-only addressing). Operators are well familiar with the tradeoffs of using interworking functions, address mapping, and the operations to support multiple address families. And the use of interworking/overlays vs. a GMPLS backward compatible solution have been viewed as two different solutions to very different applications (for both operators and vendors depending on their network evolution/product support). Are you saying (below) that you view G7713.2 overlays as *one solution* or you view it as the *only one* solution needed? Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 20:50:12 +0000 Message-ID: <3FBA85C2.2030002@alcatel.be> Date: Tue, 18 Nov 2003 21:49:06 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Sergio.Belotti@alcatel.it Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: ason-req and call segments Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi sergio, yes this sentence should probably looks like "The initiating caller interacts with the called party by means of one or more intermediate network call controllers located at administrative domain boundaries (i.e., inter-domain reference points)" ps: also i'd like also to mention that this text was already included in the version 04.txt and that we are just looking at clarifying it Sergio.Belotti@alcatel.it wrote: > Hi Dimitri, > just a doubt in the second section releate to caller interacion. I guess > the sentence should be : > ""The initiating caller interacts with the called party by means of > one or more intermediate network call controllers ... > > Sergio > > > > Dimitri > PAPADIMITRIOU/BE/ALCA To: ccamp@ops.ietf.org > TEL@ALCATEL cc: > Sent by: Subject: ason-req and call segments > owner-ccamp@ops.ietf. > org > > > 18/11/2003 17.50 > > > > > > > folks, during the ccamp wg meeting discussions on ason-req, > a remark has been made asking for clarifications on "call > segments", this is the proposed text: > > "4.3 Support for Call Segments > > As described in [ITU-T G.8080], call segmentation may be applied > when a call crosses several administrative domains. As such, an end- > to-end call may consist of multiple call segments, when the call > traverses multiple administrative domains. For a given end-to-end > call, each call segment can have one or more associated connections > and the number of connections associated with each call segment may > be different. > > The initiating caller interacts with the called party by means of > one or more intermediate call controllers located at administrative > domain boundaries (i.e., inter-domain reference points) and at the > user-network reference points. Call segment capabilities are defined > by the policies associated at these reference points. > > This capability allows for independent (policy based) choices of > signaling, concatenation, data plane protection and control plane > driven recovery paradigms in different administrative domains." > > hope it addresses everyone concerns; > thanks, > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > > > > > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 20:08:16 +0000 Message-Id: <4.3.2.7.2.20031118150027.04d63718@mo-ex1> Date: Tue, 18 Nov 2003 15:07:30 -0500 To: "Anca Zamfir" From: Lou Berger Subject: Re: Egress Control (was Re: spc connections) Cc: "Berger, Lou" , "Zafar Ali" , "Kireeti Kompella" , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Zamfir, Please see below. At 02:45 PM 11/18/2003, Anca Zamfir wrote: >[...] > >There is no issue as long as you don't use different components/interfaces > >in each direction. > >Agreed. > > > If memory serves, this isn't supported in any case. > >You mean not supported in the standard? I am wrong. It's always bad to go from memory. > > I'm not sure what's missing, can you elaborate? > >I was thinking that if LSP stitching is done at the egress node the two >directions could be on the same te link but different component links. >Egress node is a mid-LSR from the data plane perspective in this case. I >may be wrong so please correct. I think this is a valid case and agree that specifying different components in each direction is not covered. There we could do this by using an unnumbered ero with a label in each direction. While this is possible, it wasn't what was originally envisioned. > >> > I think identifying components on transit links might be useful > >> > (particularly for RRO). But this may be implementation depended, i.e., > >> > when a component link isn't also addressable as an unnumbered > >> > interface. Do you know of such a case? > >> >>when the Egress TE link is bundled. This is one of the > >> >>applications of ERO extensions specified in > >> >>< >> n > >> > trol-bundle-02.txt>http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-bundle-02.txt>http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-bundle-02.txt. > > > >> > >> > >> >> > >> >>In this respect, do we agree that ERO extensions in the above mentioned > >> >>draft adds to the Egress control application? > >> > > >> >Again, not to egress control, but to explicit label/resource control on > >> >transit links. > >> > >>IMO, we should try if possible to have the same objects used for > transit or > >>egress links. > > > >As I mentioned / asked before, is this a real case. Is there a case where > >component can't also be addressed as an unnumbered interface? > >I don't know of a real case. A bundle by definition can have numbered, >unnumbered or a combination of component links. But I think that the >proposal you have works fine for all cases as long as same comp. link is >selected for both directions. agreed. (I think!) Thanks again for the comments. Lou Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 20:07:01 +0000 Message-Id: <200311182003.PAA10391@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-03.txt Date: Tue, 18 Nov 2003 15:03:22 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau Filename : draft-ietf-ccamp-gmpls-te-mib-03.txt Pages : 8 Date : 2003-11-18 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-te-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-18123831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-18123831.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 19:47:13 +0000 Message-Id: <4.3.2.7.2.20031118142940.06966ef0@toque.cisco.com> Date: Tue, 18 Nov 2003 14:45:30 -0500 To: Lou Berger From: Anca Zamfir Subject: Re: Egress Control (was Re: spc connections) Cc: "Berger, Lou" , "Zafar Ali" , "Kireeti Kompella" , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:54 PM 11/18/2003 -0500, Lou Berger wrote: >Zamfir, > See below. > >At 10:02 AM 11/18/2003, Anca Zamfir wrote: > >>Hi Lou, >>Please see inline. >> >>At 10:40 PM 11/17/2003 -0500, Lou Berger wrote: >> >Zafar, >> > Good comment. see below for responses. >> >At 08:26 PM 11/17/2003, Zafar Ali wrote: >> > >> >>Hi Lou, et all, >> >> >> >>One of the aspects of Egress control that is not covered either in the >> >>[RFC3473] or in your email discussion is the ability to specify Egress >> >>component link, >> > >> >agreed. Now that you mention it, I believe some of use did discuss this >> >case and agreed that this case is no different than an unnumbered >> >interface, so that we'd use the Unnumbered Interface ID Subobject >> >(RFC3477) to solve component identification. I don't think there's a real >> >issue here for Egress control. >> >>There is the case of bidirectional LSPs where the direction needs to be >>specified together with the interface ID. In the ERO proposal you have >>below (Section 2.1) if the egress link is bundled, there may be a need to >>have an interface ID object with directions information included (U bit), >>in order to make sure that the upstream/ downstream labels are created on >>the desired interfaces. > >There is no issue as long as you don't use different components/interfaces >in each direction. Agreed. > If memory serves, this isn't supported in any case. You mean not supported in the standard? > I'm not sure what's missing, can you elaborate? I was thinking that if LSP stitching is done at the egress node the two directions could be on the same te link but different component links. Egress node is a mid-LSR from the data plane perspective in this case. I may be wrong so please correct. >> > I think identifying components on transit links might be useful >> > (particularly for RRO). But this may be implementation depended, i.e., >> > when a component link isn't also addressable as an unnumbered >> > interface. Do you know of such a case? >> >>when the Egress TE link is bundled. This is one of the >> >>applications of ERO extensions specified in >> >><> n >> trol-bundle-02.txt>http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-bundle-02.txt>http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-bundle-02.txt. >> >> >> >> >> >>In this respect, do we agree that ERO extensions in the above mentioned >> >>draft adds to the Egress control application? >> > >> >Again, not to egress control, but to explicit label/resource control on >> >transit links. >> >>IMO, we should try if possible to have the same objects used for transit or >>egress links. > >As I mentioned / asked before, is this a real case. Is there a case where >component can't also be addressed as an unnumbered interface? I don't know of a real case. A bundle by definition can have numbered, unnumbered or a combination of component links. But I think that the proposal you have works fine for all cases as long as same comp. link is selected for both directions. Thanks, Anca >Lou > >>thanks, >>/anca >> >> >Thanks, >> >Lou >> > >> > >> >>Thanks >> >> >> >>Regards... Zafar >> >> >> >>At 03:35 PM 11/17/2003 -0500, Lou Berger wrote: >> >> >At 03:51 PM 11/15/2003, Kireeti Kompella wrote: >> >> > >> >> >>Hi Lou, >> >> >> >> >> >>On Sat, 15 Nov 2003, Lou Berger wrote: >> >> >> >> >> >> > As I mentioned in that mail, I agree that explicitly >> >> documenting >> >> >> > egress label control seems like the thing to do now. I suggest >> >> that this >> >> >> > be done in a standalone document as it has application outside of >> >> >> > overlay/UNI. The text below is overly specific. >> >> >> >> >> >>First, let's make the text (procedures) more general. Then we can >> >> >>figure out where it goes. My preference is to keep it in this doc. >> >> >> >> >> >>Kireeti. >> >> >>------- >> >> > >> >> > >> >> >See below for the my proposal on the clarification. I'll submit >> >> >this as a draft once folks have a chance to comment. Assuming the >> >> >draft goes forward, I think it should be on the Informational track. >> >> > >> >> >Also, Having some text in the overlay document would be fine as well. >> >> > >> >> >Lou >> >> >--------------------------------------------------------------------- >> - --- >> >> > >> >> >GMPLS Signaling Procedure For Egress Control >> >> > >> >> >Abstract >> >> > >> >> >This note clarifies the procedures for the control of a label used on an >> >> >egress output/downstream interface. Such control is also know and >> >> >"Egress Control". Support for Egress Control is implicit in Generalized >> >> >Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471] and >> >> >[RFC3473]. This note does not modify GMPLS signaling mechanisms and >> >> >procedures and should be viewed as an informative clarification of >> >> >[RFC3473]. >> >> > >> >> > >> >> >1. Background >> >> > >> >> > The ability to control a label used on an egress output/downstream >> >> > interface was one of the early requirements for GMPLS. In the >> >> > initial GMPLS drafts, this was called "Egress Control". As the >> GMPLS >> >> > drafts progressed, the ability to control a label on an egress >> >> > interface was generalized to support control of a label on any >> >> > interface. This generalization is seen in Section 6 of >> [RFC3471] and >> >> > Section 5.1 of [RFC3473]. In generalizing this functionality, the >> >> > procedures to support control of a label at the egress were also >> >> > generalized. While the resulting was intended to cover egress >> >> > control, this intention is not clear to all. This note reiterates >> >> > the procedures to cover control of a label used on an egress >> >> > output/downstream interface. >> >> > >> >> > For context, the following is the text from the GMPLS signaling >> draft >> >> > dated June 2000: >> >> > >> >> > 6. Egress Control >> >> > >> >> > The LSR at the head-end of an LSP can control the termination >> of the >> >> > LSP by using the ERO. To terminate an LSP on a particular >> outgoing >> >> > interface of the egress LSR, the head-end may specify the IP >> address >> >> > of that interface as the last element in the ERO, provided >> that that >> >> > interface has an associated IP address. >> >> > >> >> > There are cases where the use of IP address doesn't provide >> enough >> >> > information to uniquely identify the egress termination. One >> >> case is >> >> > when the outgoing interface on the egress LSR is a component >> link of >> >> > a link bundle. Another case is when it is desirable to >> "splice" two >> >> > LSPs together, i.e., where the tail of the first LSP would be >> >> > "spliced" into the head of the second LSP. This last case is >> more >> >> > likely to be used in the non-PSC classes of links. >> >> > >> >> > and >> >> > >> >> > 6.2. Procedures >> >> > >> >> > The Egress Label subobject may appear only as the last >> subobject in >> >> > the ERO/ER. Appearance of this subobject anywhere else in the >> >> ERO/ER >> >> > is treated as a "Bad strict node" error. >> >> > >> >> > During an LSP setup, when a node processing the ERO/RR >> performs Next >> >> > Hop selection finds that the second subobject is an Egress Label >> >> > Subobject, the node uses the information carried in this >> >> subobject to >> >> > determine the handling of the data received over that LSP. >> >> > Specifically, if the Link ID field of the subobject is non zero, >> >> then >> >> > this field identifies a specific (outgoing) link of the node that >> >> > should be used for sending all the data received over the >> LSP. If >> >> > the Label field of the subobject is not Implicit NULL label, this >> >> > field specifies the label that should be used as an outgoing >> >> label on >> >> > the data received over the LSP. >> >> > >> >> > Procedures by which an LSR at the head-end of an LSP obtains the >> >> > information needed to construct the Egress Label subobject are >> >> > outside the scope of this document. >> >> > >> >> > >> >> >2. Egress Control Procedures >> >> > >> >> > This section is intended to compliment Section 5.1.1 and 5.2.1 of >> >> > [RFC3473]. The procedures described in that section are not >> >> > modified. This section clarifies procedures related to the label >> >> > used on an egress output/downstream interface. >> >> > >> >> > >> >> >2.1. ERO Procedures >> >> > >> >> > Egress Control occurs when the node processing an ERO is the egress >> >> > and the ERO contains one or more label subobjects. In this >> case, the >> >> > outgoing/downstream interface is indicated in the ERO as the last >> >> > listed local interface. Note that an interface may be numbered or >> >> > unnumbered, and bundled or unbundled. >> >> > >> >> > To support Egress Control, an egress checks to see if the received >> >> > ERO contains an outgoing/downstream interface. If it does, the type >> >> > of the subobject or subobjects following the interface are examined. >> >> > If the associated LSP is unicast, one subobject is examined. Two >> >> > subobjects are examined for bidirectional LSPs. If the U-bit of the >> >> > subobject being examined is clear (0), then the value of the >> label is >> >> > copied into a new Label_Set object. This Label_Set object indicates >> >> > the label value that MUST be used for transmitting traffic >> associated >> >> > with the LSP on the indicated outgoing/downstream interface. >> >> > >> >> > If the U-bit of the subobject being examined is set (1), then the >> >> > value of the label is used for upstream traffic associated with the >> >> > bidirectional LSP. Specifically, the label value will be used for >> >> > the traffic associated with the LSP that will be received on the >> >> > indicated outgoing/downstream interface. >> >> > >> >> > Per [RFC3473], any errors encountered while processing the ERO, >> >> > including if the listed label(s) are not acceptable or cannot be >> >> > supported in forwarding, SHOULD result in the generation of a >> message >> >> > containing a "Bad EXPLICIT_ROUTE object" error. >> >> > >> >> > >> >> >2.2. RRO Procedures >> >> > >> >> > In the case where an ERO is used to specify outgoing interface >> >> > information at the egress, the egress should include the specified >> >> > interface information and label or labels, if present, in the >> >> > corresponding RRO. >> >> > >> >> > >> > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 18:56:34 +0000 Message-Id: <4.3.2.7.2.20031118135055.025a0380@mo-ex1> Date: Tue, 18 Nov 2003 13:54:42 -0500 To: "Anca Zamfir" From: Lou Berger Subject: Re: Egress Control (was Re: spc connections) Cc: "Berger, Lou" , "Zafar Ali" , "Kireeti Kompella" , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Zamfir, See below. At 10:02 AM 11/18/2003, Anca Zamfir wrote: >Hi Lou, >Please see inline. > >At 10:40 PM 11/17/2003 -0500, Lou Berger wrote: > >Zafar, > > Good comment. see below for responses. > >At 08:26 PM 11/17/2003, Zafar Ali wrote: > > > >>Hi Lou, et all, > >> > >>One of the aspects of Egress control that is not covered either in the > >>[RFC3473] or in your email discussion is the ability to specify Egress > >>component link, > > > >agreed. Now that you mention it, I believe some of use did discuss this > >case and agreed that this case is no different than an unnumbered > >interface, so that we'd use the Unnumbered Interface ID Subobject > >(RFC3477) to solve component identification. I don't think there's a real > >issue here for Egress control. > >There is the case of bidirectional LSPs where the direction needs to be >specified together with the interface ID. In the ERO proposal you have >below (Section 2.1) if the egress link is bundled, there may be a need to >have an interface ID object with directions information included (U bit), >in order to make sure that the upstream/ downstream labels are created on >the desired interfaces. There is no issue as long as you don't use different components/interfaces in each direction. If memory serves, this isn't supported in any case. I'm not sure what's missing, can you elaborate? > > I think identifying components on transit links might be useful > > (particularly for RRO). But this may be implementation depended, i.e., > > when a component link isn't also addressable as an unnumbered > > interface. Do you know of such a case? > >>when the Egress TE link is bundled. This is one of the > >>applications of ERO extensions specified in > >>< trol-bundle-02.txt>http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-bundle-02.txt>http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-bundle-02.txt. > > > >> > >>In this respect, do we agree that ERO extensions in the above mentioned > >>draft adds to the Egress control application? > > > >Again, not to egress control, but to explicit label/resource control on > >transit links. > >IMO, we should try if possible to have the same objects used for transit or >egress links. As I mentioned / asked before, is this a real case. Is there a case where component can't also be addressed as an unnumbered interface? Lou >thanks, >/anca > > >Thanks, > >Lou > > > > > >>Thanks > >> > >>Regards... Zafar > >> > >>At 03:35 PM 11/17/2003 -0500, Lou Berger wrote: > >> >At 03:51 PM 11/15/2003, Kireeti Kompella wrote: > >> > > >> >>Hi Lou, > >> >> > >> >>On Sat, 15 Nov 2003, Lou Berger wrote: > >> >> > >> >> > As I mentioned in that mail, I agree that explicitly > >> documenting > >> >> > egress label control seems like the thing to do now. I suggest > >> that this > >> >> > be done in a standalone document as it has application outside of > >> >> > overlay/UNI. The text below is overly specific. > >> >> > >> >>First, let's make the text (procedures) more general. Then we can > >> >>figure out where it goes. My preference is to keep it in this doc. > >> >> > >> >>Kireeti. > >> >>------- > >> > > >> > > >> >See below for the my proposal on the clarification. I'll submit > >> >this as a draft once folks have a chance to comment. Assuming the > >> >draft goes forward, I think it should be on the Informational track. > >> > > >> >Also, Having some text in the overlay document would be fine as well. > >> > > >> >Lou > >> >---------------------------------------------------------------------- > --- > >> > > >> >GMPLS Signaling Procedure For Egress Control > >> > > >> >Abstract > >> > > >> >This note clarifies the procedures for the control of a label used on an > >> >egress output/downstream interface. Such control is also know and > >> >"Egress Control". Support for Egress Control is implicit in Generalized > >> >Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471] and > >> >[RFC3473]. This note does not modify GMPLS signaling mechanisms and > >> >procedures and should be viewed as an informative clarification of > >> >[RFC3473]. > >> > > >> > > >> >1. Background > >> > > >> > The ability to control a label used on an egress output/downstream > >> > interface was one of the early requirements for GMPLS. In the > >> > initial GMPLS drafts, this was called "Egress Control". As the > GMPLS > >> > drafts progressed, the ability to control a label on an egress > >> > interface was generalized to support control of a label on any > >> > interface. This generalization is seen in Section 6 of [RFC3471] > and > >> > Section 5.1 of [RFC3473]. In generalizing this functionality, the > >> > procedures to support control of a label at the egress were also > >> > generalized. While the resulting was intended to cover egress > >> > control, this intention is not clear to all. This note reiterates > >> > the procedures to cover control of a label used on an egress > >> > output/downstream interface. > >> > > >> > For context, the following is the text from the GMPLS signaling > draft > >> > dated June 2000: > >> > > >> > 6. Egress Control > >> > > >> > The LSR at the head-end of an LSP can control the termination > of the > >> > LSP by using the ERO. To terminate an LSP on a particular > outgoing > >> > interface of the egress LSR, the head-end may specify the IP > address > >> > of that interface as the last element in the ERO, provided > that that > >> > interface has an associated IP address. > >> > > >> > There are cases where the use of IP address doesn't provide > enough > >> > information to uniquely identify the egress termination. One > >> case is > >> > when the outgoing interface on the egress LSR is a component > link of > >> > a link bundle. Another case is when it is desirable to > "splice" two > >> > LSPs together, i.e., where the tail of the first LSP would be > >> > "spliced" into the head of the second LSP. This last case is > more > >> > likely to be used in the non-PSC classes of links. > >> > > >> > and > >> > > >> > 6.2. Procedures > >> > > >> > The Egress Label subobject may appear only as the last > subobject in > >> > the ERO/ER. Appearance of this subobject anywhere else in the > >> ERO/ER > >> > is treated as a "Bad strict node" error. > >> > > >> > During an LSP setup, when a node processing the ERO/RR > performs Next > >> > Hop selection finds that the second subobject is an Egress Label > >> > Subobject, the node uses the information carried in this > >> subobject to > >> > determine the handling of the data received over that LSP. > >> > Specifically, if the Link ID field of the subobject is non zero, > >> then > >> > this field identifies a specific (outgoing) link of the node that > >> > should be used for sending all the data received over the > LSP. If > >> > the Label field of the subobject is not Implicit NULL label, this > >> > field specifies the label that should be used as an outgoing > >> label on > >> > the data received over the LSP. > >> > > >> > Procedures by which an LSR at the head-end of an LSP obtains the > >> > information needed to construct the Egress Label subobject are > >> > outside the scope of this document. > >> > > >> > > >> >2. Egress Control Procedures > >> > > >> > This section is intended to compliment Section 5.1.1 and 5.2.1 of > >> > [RFC3473]. The procedures described in that section are not > >> > modified. This section clarifies procedures related to the label > >> > used on an egress output/downstream interface. > >> > > >> > > >> >2.1. ERO Procedures > >> > > >> > Egress Control occurs when the node processing an ERO is the egress > >> > and the ERO contains one or more label subobjects. In this case, > the > >> > outgoing/downstream interface is indicated in the ERO as the last > >> > listed local interface. Note that an interface may be numbered or > >> > unnumbered, and bundled or unbundled. > >> > > >> > To support Egress Control, an egress checks to see if the received > >> > ERO contains an outgoing/downstream interface. If it does, the type > >> > of the subobject or subobjects following the interface are examined. > >> > If the associated LSP is unicast, one subobject is examined. Two > >> > subobjects are examined for bidirectional LSPs. If the U-bit of the > >> > subobject being examined is clear (0), then the value of the > label is > >> > copied into a new Label_Set object. This Label_Set object indicates > >> > the label value that MUST be used for transmitting traffic > associated > >> > with the LSP on the indicated outgoing/downstream interface. > >> > > >> > If the U-bit of the subobject being examined is set (1), then the > >> > value of the label is used for upstream traffic associated with the > >> > bidirectional LSP. Specifically, the label value will be used for > >> > the traffic associated with the LSP that will be received on the > >> > indicated outgoing/downstream interface. > >> > > >> > Per [RFC3473], any errors encountered while processing the ERO, > >> > including if the listed label(s) are not acceptable or cannot be > >> > supported in forwarding, SHOULD result in the generation of a > message > >> > containing a "Bad EXPLICIT_ROUTE object" error. > >> > > >> > > >> >2.2. RRO Procedures > >> > > >> > In the case where an ERO is used to specify outgoing interface > >> > information at the egress, the egress should include the specified > >> > interface information and label or labels, if present, in the > >> > corresponding RRO. > >> > > >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 17:28:31 +0000 Subject: Re: ason-req and call segments To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Message-ID: From: Sergio.Belotti@alcatel.it Date: Tue, 18 Nov 2003 18:26:28 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Dimitri, just a doubt in the second section releate to caller interacion. I guess the sentence should be : ""The initiating caller interacts with the called party by means of one or more intermediate network call controllers ... Sergio Dimitri PAPADIMITRIOU/BE/ALCA To: ccamp@ops.ietf.org TEL@ALCATEL cc: Sent by: Subject: ason-req and call segments owner-ccamp@ops.ietf. org 18/11/2003 17.50 folks, during the ccamp wg meeting discussions on ason-req, a remark has been made asking for clarifications on "call segments", this is the proposed text: "4.3 Support for Call Segments As described in [ITU-T G.8080], call segmentation may be applied when a call crosses several administrative domains. As such, an end- to-end call may consist of multiple call segments, when the call traverses multiple administrative domains. For a given end-to-end call, each call segment can have one or more associated connections and the number of connections associated with each call segment may be different. The initiating caller interacts with the called party by means of one or more intermediate call controllers located at administrative domain boundaries (i.e., inter-domain reference points) and at the user-network reference points. Call segment capabilities are defined by the policies associated at these reference points. This capability allows for independent (policy based) choices of signaling, concatenation, data plane protection and control plane driven recovery paradigms in different administrative domains." hope it addresses everyone concerns; thanks, -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 17:28:17 +0000 Message-ID: <3FBA55A9.1020906@tellabs.com> Date: Tue, 18 Nov 2003 11:23:53 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Yakov Rekhter CC: "Ong, Lyndon" , "'John Drake'" , "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: spc connections Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" So far, I see the following flaws in the proposed text: 1) No provision has been made to handle endpoint identifiers that are not internal network addresses. 2) The text does not address inter domain cases; those in which the ingress and egress endpoints are in different domains which do not publish their internal addresses to each other. 3) Kireeti's proposed text unnecessarily overrides a processing rule in rfc3473. 4) Lou's text still refers to creation of a new LabelSet object. 5) The procedures for handling the case in which a core network does not (by policy) accept route information from the ingress edge but must accept endpoint identification in an ERO must be elaborated, both for the case of an endpoint in that core network and the case of an endpoint in another domain that does not publish internal addressing. Regards, Ben Yakov Rekhter wrote: >Lyndon, > > > >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Monday, November 17, 2003 1:06 PM >>To: Ong, Lyndon; 'Kireeti Kompella' >>Cc: ccamp@ops.ietf.org >>Subject: RE: spc connections >> >> >>>I understand that you have many aspects to weigh, and 7713.2 is >>>only one of them. However, the SPC Label procedure is one where >>>there have been no technical issues, and it has been implemented >>>and tested. Other people on the list have concluded that there >>>is a reasonable case for separating this from the ERO, and it is >>>not in fact supported by the current procedures in 3473. >>> >>> >>JD: Do you think that if you continue saying this that it will somehow >>become true? >> >>LYO: Yes, I believe that discussing issues on the mailing list may actually >>lead to some better understanding and common agreement :o) >> >> > >It certainly lead to better understanding - Lou's proposed text is >the proof of this. Ditto for Kireeti's proposed text. > >And now, since we do have the text, unless the text has *technical* >flaws I would suggest to close the discussion. > >Yakov. > > > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 16:51:26 +0000 Message-ID: <3FBA4DDF.60007@alcatel.be> Date: Tue, 18 Nov 2003 17:50:39 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: ason-req and call segments Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed folks, during the ccamp wg meeting discussions on ason-req, a remark has been made asking for clarifications on "call segments", this is the proposed text: "4.3 Support for Call Segments As described in [ITU-T G.8080], call segmentation may be applied when a call crosses several administrative domains. As such, an end- to-end call may consist of multiple call segments, when the call traverses multiple administrative domains. For a given end-to-end call, each call segment can have one or more associated connections and the number of connections associated with each call segment may be different. The initiating caller interacts with the called party by means of one or more intermediate call controllers located at administrative domain boundaries (i.e., inter-domain reference points) and at the user-network reference points. Call segment capabilities are defined by the policies associated at these reference points. This capability allows for independent (policy based) choices of signaling, concatenation, data plane protection and control plane driven recovery paradigms in different administrative domains." hope it addresses everyone concerns; thanks, -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 16:27:51 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: spc connections Date: Tue, 18 Nov 2003 10:26:14 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0497B9AD@OCCLUST04EVS1.ugd.att.com> Thread-Topic: spc connections Thread-Index: AcOtfrKtrvk3ci4/QLebYbf3R+f6GAAXrBFg From: "Brungard, Deborah A, ALABS" To: "Kireeti Kompella" , "Ong, Lyndon" Cc: Lyndon, It's been a long thread and I am not sure anymore what we are = discussing: - use of the ERO for SPC? Can you be more specific on your concerns as = this is where OIF/ITU chose for a different implementation. We need to = understand if it resulted from an unclear description or technical = concern (as both Yakov and Kireeti requested). - use of G7713.2 (3474) as a solution? This is also a needed discussion = item to progress the ASON signaling work. On the use of G7713.2: we all agree it provides a *solution*. The = question is - is a G7713.2 network overlay (not to be confused with the = GMPLS overlay model) the only solution needed? Or do we need a 3473 = solution? Your 3473/3474 interworking draft and the new appendix added to the = draft on GMPLS signalling for ASON both describe the 3473/3474 = differences. The key driver for defining new 3474 objects was the = implementation decision to support multiple addresses (IPv4, IPv6, NSAP) = in the protocol objects (vs. address mapping at ingress/egress (e.g. = G7713.1 ASON PNNI's implementation)). Multiple family address = resolution/management and support of the new objects are part of 3474 = node processing (regardless if one is tunneling a new transparent object = as an overlay/terminating or if one is using IP-only addressing).=20 Operators are well familiar with the tradeoffs of using interworking = functions, address mapping, and the operations to support multiple = address families. And the use of interworking/overlays vs. a GMPLS = backward compatible solution have been viewed as two different solutions = to very different applications (for both operators and vendors depending = on their network evolution/product support). Are you saying (below) that = you view G7713.2 overlays as *one solution* or you view it as the *only = one* solution needed? Deborah -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, November 17, 2003 9:48 PM To: Ong, Lyndon Cc: ccamp@ops.ietf.org Subject: RE: spc connections=20 On Mon, 17 Nov 2003, Ong, Lyndon wrote: > I respectfully disagree with the suggestion, as > 7713.2/3474 provides a valid solution that does not > require changes to the text to begin with. Here's how I look at it: explicit label control as described in 3473 appears not to be clearly understood. Therefore, a clearer explanation is needed in any case. Given that, the choice is between: 3473+explanation: works without a new object, has label control per hop, is trivially backward compatible and 7713.2: needs a new (to 3473) object, has only egress label control, needs interworking spec with interoperate with 3473 (assuming interworking issues are fixed) Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 15:06:44 +0000 Message-Id: <4.3.2.7.2.20031118093138.030f9e08@toque.cisco.com> Date: Tue, 18 Nov 2003 10:02:51 -0500 To: Lou Berger From: Anca Zamfir Subject: Re: Egress Control (was Re: spc connections) Cc: "Zafar Ali" , "Berger, Lou" , "Kireeti Kompella" , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Lou, Please see inline. At 10:40 PM 11/17/2003 -0500, Lou Berger wrote: >Zafar, > Good comment. see below for responses. >At 08:26 PM 11/17/2003, Zafar Ali wrote: > >>Hi Lou, et all, >> >>One of the aspects of Egress control that is not covered either in the >>[RFC3473] or in your email discussion is the ability to specify Egress >>component link, > >agreed. Now that you mention it, I believe some of use did discuss this >case and agreed that this case is no different than an unnumbered >interface, so that we'd use the Unnumbered Interface ID Subobject >(RFC3477) to solve component identification. I don't think there's a real >issue here for Egress control. There is the case of bidirectional LSPs where the direction needs to be specified together with the interface ID. In the ERO proposal you have below (Section 2.1) if the egress link is bundled, there may be a need to have an interface ID object with directions information included (U bit), in order to make sure that the upstream/ downstream labels are created on the desired interfaces. > I think identifying components on transit links might be useful > (particularly for RRO). But this may be implementation depended, i.e., > when a component link isn't also addressable as an unnumbered > interface. Do you know of such a case? >>when the Egress TE link is bundled. This is one of the >>applications of ERO extensions specified in >>http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-bundle-02.txt. >> >>In this respect, do we agree that ERO extensions in the above mentioned >>draft adds to the Egress control application? > >Again, not to egress control, but to explicit label/resource control on >transit links. IMO, we should try if possible to have the same objects used for transit or egress links. thanks, /anca >Thanks, >Lou > > >>Thanks >> >>Regards... Zafar >> >>At 03:35 PM 11/17/2003 -0500, Lou Berger wrote: >> >At 03:51 PM 11/15/2003, Kireeti Kompella wrote: >> > >> >>Hi Lou, >> >> >> >>On Sat, 15 Nov 2003, Lou Berger wrote: >> >> >> >> > As I mentioned in that mail, I agree that explicitly >> documenting >> >> > egress label control seems like the thing to do now. I suggest >> that this >> >> > be done in a standalone document as it has application outside of >> >> > overlay/UNI. The text below is overly specific. >> >> >> >>First, let's make the text (procedures) more general. Then we can >> >>figure out where it goes. My preference is to keep it in this doc. >> >> >> >>Kireeti. >> >>------- >> > >> > >> >See below for the my proposal on the clarification. I'll submit >> >this as a draft once folks have a chance to comment. Assuming the >> >draft goes forward, I think it should be on the Informational track. >> > >> >Also, Having some text in the overlay document would be fine as well. >> > >> >Lou >> >------------------------------------------------------------------------- >> > >> >GMPLS Signaling Procedure For Egress Control >> > >> >Abstract >> > >> >This note clarifies the procedures for the control of a label used on an >> >egress output/downstream interface. Such control is also know and >> >"Egress Control". Support for Egress Control is implicit in Generalized >> >Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471] and >> >[RFC3473]. This note does not modify GMPLS signaling mechanisms and >> >procedures and should be viewed as an informative clarification of >> >[RFC3473]. >> > >> > >> >1. Background >> > >> > The ability to control a label used on an egress output/downstream >> > interface was one of the early requirements for GMPLS. In the >> > initial GMPLS drafts, this was called "Egress Control". As the GMPLS >> > drafts progressed, the ability to control a label on an egress >> > interface was generalized to support control of a label on any >> > interface. This generalization is seen in Section 6 of [RFC3471] and >> > Section 5.1 of [RFC3473]. In generalizing this functionality, the >> > procedures to support control of a label at the egress were also >> > generalized. While the resulting was intended to cover egress >> > control, this intention is not clear to all. This note reiterates >> > the procedures to cover control of a label used on an egress >> > output/downstream interface. >> > >> > For context, the following is the text from the GMPLS signaling draft >> > dated June 2000: >> > >> > 6. Egress Control >> > >> > The LSR at the head-end of an LSP can control the termination of the >> > LSP by using the ERO. To terminate an LSP on a particular outgoing >> > interface of the egress LSR, the head-end may specify the IP address >> > of that interface as the last element in the ERO, provided that that >> > interface has an associated IP address. >> > >> > There are cases where the use of IP address doesn't provide enough >> > information to uniquely identify the egress termination. One >> case is >> > when the outgoing interface on the egress LSR is a component link of >> > a link bundle. Another case is when it is desirable to "splice" two >> > LSPs together, i.e., where the tail of the first LSP would be >> > "spliced" into the head of the second LSP. This last case is more >> > likely to be used in the non-PSC classes of links. >> > >> > and >> > >> > 6.2. Procedures >> > >> > The Egress Label subobject may appear only as the last subobject in >> > the ERO/ER. Appearance of this subobject anywhere else in the >> ERO/ER >> > is treated as a "Bad strict node" error. >> > >> > During an LSP setup, when a node processing the ERO/RR performs Next >> > Hop selection finds that the second subobject is an Egress Label >> > Subobject, the node uses the information carried in this >> subobject to >> > determine the handling of the data received over that LSP. >> > Specifically, if the Link ID field of the subobject is non zero, >> then >> > this field identifies a specific (outgoing) link of the node that >> > should be used for sending all the data received over the LSP. If >> > the Label field of the subobject is not Implicit NULL label, this >> > field specifies the label that should be used as an outgoing >> label on >> > the data received over the LSP. >> > >> > Procedures by which an LSR at the head-end of an LSP obtains the >> > information needed to construct the Egress Label subobject are >> > outside the scope of this document. >> > >> > >> >2. Egress Control Procedures >> > >> > This section is intended to compliment Section 5.1.1 and 5.2.1 of >> > [RFC3473]. The procedures described in that section are not >> > modified. This section clarifies procedures related to the label >> > used on an egress output/downstream interface. >> > >> > >> >2.1. ERO Procedures >> > >> > Egress Control occurs when the node processing an ERO is the egress >> > and the ERO contains one or more label subobjects. In this case, the >> > outgoing/downstream interface is indicated in the ERO as the last >> > listed local interface. Note that an interface may be numbered or >> > unnumbered, and bundled or unbundled. >> > >> > To support Egress Control, an egress checks to see if the received >> > ERO contains an outgoing/downstream interface. If it does, the type >> > of the subobject or subobjects following the interface are examined. >> > If the associated LSP is unicast, one subobject is examined. Two >> > subobjects are examined for bidirectional LSPs. If the U-bit of the >> > subobject being examined is clear (0), then the value of the label is >> > copied into a new Label_Set object. This Label_Set object indicates >> > the label value that MUST be used for transmitting traffic associated >> > with the LSP on the indicated outgoing/downstream interface. >> > >> > If the U-bit of the subobject being examined is set (1), then the >> > value of the label is used for upstream traffic associated with the >> > bidirectional LSP. Specifically, the label value will be used for >> > the traffic associated with the LSP that will be received on the >> > indicated outgoing/downstream interface. >> > >> > Per [RFC3473], any errors encountered while processing the ERO, >> > including if the listed label(s) are not acceptable or cannot be >> > supported in forwarding, SHOULD result in the generation of a message >> > containing a "Bad EXPLICIT_ROUTE object" error. >> > >> > >> >2.2. RRO Procedures >> > >> > In the case where an ERO is used to specify outgoing interface >> > information at the egress, the egress should include the specified >> > interface information and label or labels, if present, in the >> > corresponding RRO. >> > >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 03:42:00 +0000 Message-Id: <4.3.2.7.2.20031117220634.0270e1f8@mo-ex1> Date: Mon, 17 Nov 2003 22:40:31 -0500 To: "Zafar Ali" From: Lou Berger Subject: Re: Egress Control (was Re: spc connections) Cc: "Berger, Lou" , "Kireeti Kompella" , , "Anca Zamfir" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Zafar, Good comment. see below for responses. At 08:26 PM 11/17/2003, Zafar Ali wrote: >Hi Lou, et all, > >One of the aspects of Egress control that is not covered either in the >[RFC3473] or in your email discussion is the ability to specify Egress >component link, agreed. Now that you mention it, I believe some of use did discuss this case and agreed that this case is no different than an unnumbered interface, so that we'd use the Unnumbered Interface ID Subobject (RFC3477) to solve component identification. I don't think there's a real issue here for Egress control. I think identifying components on transit links might be useful (particularly for RRO). But this may be implementation depended, i.e., when a component link isn't also addressable as an unnumbered interface. Do you know of such a case? >when the Egress TE link is bundled. This is one of the >applications of ERO extensions specified in >http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-bundle-02.txt. > >In this respect, do we agree that ERO extensions in the above mentioned >draft adds to the Egress control application? Again, not to egress control, but to explicit label/resource control on transit links. Thanks, Lou >Thanks > >Regards... Zafar > >At 03:35 PM 11/17/2003 -0500, Lou Berger wrote: > >At 03:51 PM 11/15/2003, Kireeti Kompella wrote: > > > >>Hi Lou, > >> > >>On Sat, 15 Nov 2003, Lou Berger wrote: > >> > >> > As I mentioned in that mail, I agree that explicitly > documenting > >> > egress label control seems like the thing to do now. I suggest that > this > >> > be done in a standalone document as it has application outside of > >> > overlay/UNI. The text below is overly specific. > >> > >>First, let's make the text (procedures) more general. Then we can > >>figure out where it goes. My preference is to keep it in this doc. > >> > >>Kireeti. > >>------- > > > > > >See below for the my proposal on the clarification. I'll submit > >this as a draft once folks have a chance to comment. Assuming the > >draft goes forward, I think it should be on the Informational track. > > > >Also, Having some text in the overlay document would be fine as well. > > > >Lou > >------------------------------------------------------------------------- > > > >GMPLS Signaling Procedure For Egress Control > > > >Abstract > > > >This note clarifies the procedures for the control of a label used on an > >egress output/downstream interface. Such control is also know and > >"Egress Control". Support for Egress Control is implicit in Generalized > >Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471] and > >[RFC3473]. This note does not modify GMPLS signaling mechanisms and > >procedures and should be viewed as an informative clarification of > >[RFC3473]. > > > > > >1. Background > > > > The ability to control a label used on an egress output/downstream > > interface was one of the early requirements for GMPLS. In the > > initial GMPLS drafts, this was called "Egress Control". As the GMPLS > > drafts progressed, the ability to control a label on an egress > > interface was generalized to support control of a label on any > > interface. This generalization is seen in Section 6 of [RFC3471] and > > Section 5.1 of [RFC3473]. In generalizing this functionality, the > > procedures to support control of a label at the egress were also > > generalized. While the resulting was intended to cover egress > > control, this intention is not clear to all. This note reiterates > > the procedures to cover control of a label used on an egress > > output/downstream interface. > > > > For context, the following is the text from the GMPLS signaling draft > > dated June 2000: > > > > 6. Egress Control > > > > The LSR at the head-end of an LSP can control the termination of the > > LSP by using the ERO. To terminate an LSP on a particular outgoing > > interface of the egress LSR, the head-end may specify the IP address > > of that interface as the last element in the ERO, provided that that > > interface has an associated IP address. > > > > There are cases where the use of IP address doesn't provide enough > > information to uniquely identify the egress termination. One > case is > > when the outgoing interface on the egress LSR is a component link of > > a link bundle. Another case is when it is desirable to "splice" two > > LSPs together, i.e., where the tail of the first LSP would be > > "spliced" into the head of the second LSP. This last case is more > > likely to be used in the non-PSC classes of links. > > > > and > > > > 6.2. Procedures > > > > The Egress Label subobject may appear only as the last subobject in > > the ERO/ER. Appearance of this subobject anywhere else in the > ERO/ER > > is treated as a "Bad strict node" error. > > > > During an LSP setup, when a node processing the ERO/RR performs Next > > Hop selection finds that the second subobject is an Egress Label > > Subobject, the node uses the information carried in this > subobject to > > determine the handling of the data received over that LSP. > > Specifically, if the Link ID field of the subobject is non zero, > then > > this field identifies a specific (outgoing) link of the node that > > should be used for sending all the data received over the LSP. If > > the Label field of the subobject is not Implicit NULL label, this > > field specifies the label that should be used as an outgoing > label on > > the data received over the LSP. > > > > Procedures by which an LSR at the head-end of an LSP obtains the > > information needed to construct the Egress Label subobject are > > outside the scope of this document. > > > > > >2. Egress Control Procedures > > > > This section is intended to compliment Section 5.1.1 and 5.2.1 of > > [RFC3473]. The procedures described in that section are not > > modified. This section clarifies procedures related to the label > > used on an egress output/downstream interface. > > > > > >2.1. ERO Procedures > > > > Egress Control occurs when the node processing an ERO is the egress > > and the ERO contains one or more label subobjects. In this case, the > > outgoing/downstream interface is indicated in the ERO as the last > > listed local interface. Note that an interface may be numbered or > > unnumbered, and bundled or unbundled. > > > > To support Egress Control, an egress checks to see if the received > > ERO contains an outgoing/downstream interface. If it does, the type > > of the subobject or subobjects following the interface are examined. > > If the associated LSP is unicast, one subobject is examined. Two > > subobjects are examined for bidirectional LSPs. If the U-bit of the > > subobject being examined is clear (0), then the value of the label is > > copied into a new Label_Set object. This Label_Set object indicates > > the label value that MUST be used for transmitting traffic associated > > with the LSP on the indicated outgoing/downstream interface. > > > > If the U-bit of the subobject being examined is set (1), then the > > value of the label is used for upstream traffic associated with the > > bidirectional LSP. Specifically, the label value will be used for > > the traffic associated with the LSP that will be received on the > > indicated outgoing/downstream interface. > > > > Per [RFC3473], any errors encountered while processing the ERO, > > including if the listed label(s) are not acceptable or cannot be > > supported in forwarding, SHOULD result in the generation of a message > > containing a "Bad EXPLICIT_ROUTE object" error. > > > > > >2.2. RRO Procedures > > > > In the case where an ERO is used to specify outgoing interface > > information at the egress, the egress should include the specified > > interface information and label or labels, if present, in the > > corresponding RRO. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 02:49:39 +0000 Date: Mon, 17 Nov 2003 18:47:54 -0800 (PST) From: Kireeti Kompella To: "Ong, Lyndon" cc: ccamp@ops.ietf.org Subject: RE: spc connections Message-ID: <20031117183924.B67554@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 17 Nov 2003, Ong, Lyndon wrote: > I respectfully disagree with the suggestion, as > 7713.2/3474 provides a valid solution that does not > require changes to the text to begin with. Here's how I look at it: explicit label control as described in 3473 appears not to be clearly understood. Therefore, a clearer explanation is needed in any case. Given that, the choice is between: 3473+explanation: works without a new object, has label control per hop, is trivially backward compatible and 7713.2: needs a new (to 3473) object, has only egress label control, needs interworking spec with interoperate with 3473 (assuming interworking issues are fixed) Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 01:29:58 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61FF@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Yakov Rekhter' Cc: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: spc connections Date: Mon, 17 Nov 2003 17:29:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Yakov, I respectfully disagree with the suggestion, as 7713.2/3474 provides a valid solution that does not require changes to the text to begin with. Cheers, Lyndon -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Monday, November 17, 2003 2:15 PM To: Ong, Lyndon Cc: 'John Drake'; 'Kireeti Kompella'; ccamp@ops.ietf.org Subject: Re: spc connections Lyndon, > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Monday, November 17, 2003 1:06 PM > To: Ong, Lyndon; 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: RE: spc connections > > I understand that you have many aspects to weigh, and 7713.2 is > > only one of them. However, the SPC Label procedure is one where > > there have been no technical issues, and it has been implemented > > and tested. Other people on the list have concluded that there > > is a reasonable case for separating this from the ERO, and it is > > not in fact supported by the current procedures in 3473. > > > JD: Do you think that if you continue saying this that it will somehow > become true? > > LYO: Yes, I believe that discussing issues on the mailing list may actually > lead to some better understanding and common agreement :o) It certainly lead to better understanding - Lou's proposed text is the proof of this. Ditto for Kireeti's proposed text. And now, since we do have the text, unless the text has *technical* flaws I would suggest to close the discussion. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 01:29:33 +0000 Message-Id: <4.3.2.7.2.20031117194358.02fbc338@toque.cisco.com> Date: Mon, 17 Nov 2003 20:26:55 -0500 To: Lou Berger From: Zafar Ali Subject: Re: Egress Control (was Re: spc connections) Cc: "Kireeti Kompella" , "Berger, Lou" , , Anca Zamfir , dimitri.papadimitriou@alcatel.be Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Lou, et all, One of the aspects of Egress control that is not covered either in the [RFC3473] or in your email discussion is the ability to specify Egress component link, when the Egress TE link is bundled. This is one of the applications of ERO extensions specified in http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-control-bundle-02.txt. In this respect, do we agree that ERO extensions in the above mentioned draft adds to the Egress control application? Thanks Regards... Zafar At 03:35 PM 11/17/2003 -0500, Lou Berger wrote: >At 03:51 PM 11/15/2003, Kireeti Kompella wrote: > >>Hi Lou, >> >>On Sat, 15 Nov 2003, Lou Berger wrote: >> >> > As I mentioned in that mail, I agree that explicitly documenting >> > egress label control seems like the thing to do now. I suggest that this >> > be done in a standalone document as it has application outside of >> > overlay/UNI. The text below is overly specific. >> >>First, let's make the text (procedures) more general. Then we can >>figure out where it goes. My preference is to keep it in this doc. >> >>Kireeti. >>------- > > >See below for the my proposal on the clarification. I'll submit >this as a draft once folks have a chance to comment. Assuming the >draft goes forward, I think it should be on the Informational track. > >Also, Having some text in the overlay document would be fine as well. > >Lou >------------------------------------------------------------------------- > >GMPLS Signaling Procedure For Egress Control > >Abstract > >This note clarifies the procedures for the control of a label used on an >egress output/downstream interface. Such control is also know and >"Egress Control". Support for Egress Control is implicit in Generalized >Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471] and >[RFC3473]. This note does not modify GMPLS signaling mechanisms and >procedures and should be viewed as an informative clarification of >[RFC3473]. > > >1. Background > > The ability to control a label used on an egress output/downstream > interface was one of the early requirements for GMPLS. In the > initial GMPLS drafts, this was called "Egress Control". As the GMPLS > drafts progressed, the ability to control a label on an egress > interface was generalized to support control of a label on any > interface. This generalization is seen in Section 6 of [RFC3471] and > Section 5.1 of [RFC3473]. In generalizing this functionality, the > procedures to support control of a label at the egress were also > generalized. While the resulting was intended to cover egress > control, this intention is not clear to all. This note reiterates > the procedures to cover control of a label used on an egress > output/downstream interface. > > For context, the following is the text from the GMPLS signaling draft > dated June 2000: > > 6. Egress Control > > The LSR at the head-end of an LSP can control the termination of the > LSP by using the ERO. To terminate an LSP on a particular outgoing > interface of the egress LSR, the head-end may specify the IP address > of that interface as the last element in the ERO, provided that that > interface has an associated IP address. > > There are cases where the use of IP address doesn't provide enough > information to uniquely identify the egress termination. One case is > when the outgoing interface on the egress LSR is a component link of > a link bundle. Another case is when it is desirable to "splice" two > LSPs together, i.e., where the tail of the first LSP would be > "spliced" into the head of the second LSP. This last case is more > likely to be used in the non-PSC classes of links. > > and > > 6.2. Procedures > > The Egress Label subobject may appear only as the last subobject in > the ERO/ER. Appearance of this subobject anywhere else in the ERO/ER > is treated as a "Bad strict node" error. > > During an LSP setup, when a node processing the ERO/RR performs Next > Hop selection finds that the second subobject is an Egress Label > Subobject, the node uses the information carried in this subobject to > determine the handling of the data received over that LSP. > Specifically, if the Link ID field of the subobject is non zero, then > this field identifies a specific (outgoing) link of the node that > should be used for sending all the data received over the LSP. If > the Label field of the subobject is not Implicit NULL label, this > field specifies the label that should be used as an outgoing label on > the data received over the LSP. > > Procedures by which an LSR at the head-end of an LSP obtains the > information needed to construct the Egress Label subobject are > outside the scope of this document. > > >2. Egress Control Procedures > > This section is intended to compliment Section 5.1.1 and 5.2.1 of > [RFC3473]. The procedures described in that section are not > modified. This section clarifies procedures related to the label > used on an egress output/downstream interface. > > >2.1. ERO Procedures > > Egress Control occurs when the node processing an ERO is the egress > and the ERO contains one or more label subobjects. In this case, the > outgoing/downstream interface is indicated in the ERO as the last > listed local interface. Note that an interface may be numbered or > unnumbered, and bundled or unbundled. > > To support Egress Control, an egress checks to see if the received > ERO contains an outgoing/downstream interface. If it does, the type > of the subobject or subobjects following the interface are examined. > If the associated LSP is unicast, one subobject is examined. Two > subobjects are examined for bidirectional LSPs. If the U-bit of the > subobject being examined is clear (0), then the value of the label is > copied into a new Label_Set object. This Label_Set object indicates > the label value that MUST be used for transmitting traffic associated > with the LSP on the indicated outgoing/downstream interface. > > If the U-bit of the subobject being examined is set (1), then the > value of the label is used for upstream traffic associated with the > bidirectional LSP. Specifically, the label value will be used for > the traffic associated with the LSP that will be received on the > indicated outgoing/downstream interface. > > Per [RFC3473], any errors encountered while processing the ERO, > including if the listed label(s) are not acceptable or cannot be > supported in forwarding, SHOULD result in the generation of a message > containing a "Bad EXPLICIT_ROUTE object" error. > > >2.2. RRO Procedures > > In the case where an ERO is used to specify outgoing interface > information at the egress, the egress should include the specified > interface information and label or labels, if present, in the > corresponding RRO. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Nov 2003 00:09:50 +0000 Message-Id: <200311180007.hAI07it39833@merlot.juniper.net> To: Dimitri.Papadimitriou@alcatel.be cc: ccamp@ops.ietf.org Subject: Re: spc connections MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7540.1069114064.1@juniper.net> Date: Mon, 17 Nov 2003 16:07:44 -0800 From: Yakov Rekhter Dimitri, > hi yakov, i would also suggest we concentrate on the text > being proposed here (Lou and Kireeti's proposal) since what > had to be discussed has been discussed from this perspective > > unless additional technical points are brought up, the > proposed text(s) is imho clarifying enough and is in-line w/ > expectation(s) expressed during last week ie clarification, > thus i hope that it will be also soon included in the gmpls- > overlay i-d order to move forward as discussed during the > ccamp wg meeting > > note that linking with the message of lou, i don't see > any issue in also having an info document that would be > larger scoped - as long as consistence is maintained w/i > the working group output - Agreed. Yakov. > thanks, > - dimitri. > > Yakov Rekhter wrote: > > Lyndon, > > > > > >>-----Original Message----- > >>From: John Drake [mailto:jdrake@calient.net] > >>Sent: Monday, November 17, 2003 1:06 PM > >>To: Ong, Lyndon; 'Kireeti Kompella' > >>Cc: ccamp@ops.ietf.org > >>Subject: RE: spc connections > >> > >>>I understand that you have many aspects to weigh, and 7713.2 is > >>>only one of them. However, the SPC Label procedure is one where > >>>there have been no technical issues, and it has been implemented > >>>and tested. Other people on the list have concluded that there > >>>is a reasonable case for separating this from the ERO, and it is > >>>not in fact supported by the current procedures in 3473. > >> > >> > >>JD: Do you think that if you continue saying this that it will somehow > >>become true? > >> > >>LYO: Yes, I believe that discussing issues on the mailing list may actually > >>lead to some better understanding and common agreement :o) > > > > > > It certainly lead to better understanding - Lou's proposed text is > > the proof of this. Ditto for Kireeti's proposed text. > > > > And now, since we do have the text, unless the text has *technical* > > flaws I would suggest to close the discussion. > > > > Yakov. > > > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 22:34:59 +0000 Message-ID: <3FB94CBC.60401@alcatel.be> Date: Mon, 17 Nov 2003 23:33:32 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Yakov Rekhter Cc: "Ong, Lyndon" , "'John Drake'" , "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: spc connections Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi yakov, i would also suggest we concentrate on the text being proposed here (Lou and Kireeti's proposal) since what had to be discussed has been discussed from this perspective unless additional technical points are brought up, the proposed text(s) is imho clarifying enough and is in-line w/ expectation(s) expressed during last week ie clarification, thus i hope that it will be also soon included in the gmpls- overlay i-d order to move forward as discussed during the ccamp wg meeting note that linking with the message of lou, i don't see any issue in also having an info document that would be larger scoped - as long as consistence is maintained w/i the working group output - thanks, - dimitri. Yakov Rekhter wrote: > Lyndon, > > >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Monday, November 17, 2003 1:06 PM >>To: Ong, Lyndon; 'Kireeti Kompella' >>Cc: ccamp@ops.ietf.org >>Subject: RE: spc connections >> >>>I understand that you have many aspects to weigh, and 7713.2 is >>>only one of them. However, the SPC Label procedure is one where >>>there have been no technical issues, and it has been implemented >>>and tested. Other people on the list have concluded that there >>>is a reasonable case for separating this from the ERO, and it is >>>not in fact supported by the current procedures in 3473. >> >> >>JD: Do you think that if you continue saying this that it will somehow >>become true? >> >>LYO: Yes, I believe that discussing issues on the mailing list may actually >>lead to some better understanding and common agreement :o) > > > It certainly lead to better understanding - Lou's proposed text is > the proof of this. Ditto for Kireeti's proposed text. > > And now, since we do have the text, unless the text has *technical* > flaws I would suggest to close the discussion. > > Yakov. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 22:17:07 +0000 Message-Id: <200311172214.hAHMEjt22947@merlot.juniper.net> To: "Ong, Lyndon" cc: "'John Drake'" , "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: spc connections MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64716.1069107285.1@juniper.net> Date: Mon, 17 Nov 2003 14:14:45 -0800 From: Yakov Rekhter Lyndon, > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Monday, November 17, 2003 1:06 PM > To: Ong, Lyndon; 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: RE: spc connections > > I understand that you have many aspects to weigh, and 7713.2 is > > only one of them. However, the SPC Label procedure is one where > > there have been no technical issues, and it has been implemented > > and tested. Other people on the list have concluded that there > > is a reasonable case for separating this from the ERO, and it is > > not in fact supported by the current procedures in 3473. > > > JD: Do you think that if you continue saying this that it will somehow > become true? > > LYO: Yes, I believe that discussing issues on the mailing list may actually > lead to some better understanding and common agreement :o) It certainly lead to better understanding - Lou's proposed text is the proof of this. Ditto for Kireeti's proposed text. And now, since we do have the text, unless the text has *technical* flaws I would suggest to close the discussion. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 21:47:34 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61FB@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'John Drake' , 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: spc connections Date: Mon, 17 Nov 2003 13:46:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi John, -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Monday, November 17, 2003 1:06 PM To: Ong, Lyndon; 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: spc connections > I understand that you have many aspects to weigh, and 7713.2 is > only one of them. However, the SPC Label procedure is one where > there have been no technical issues, and it has been implemented > and tested. Other people on the list have concluded that there > is a reasonable case for separating this from the ERO, and it is > not in fact supported by the current procedures in 3473. JD: Do you think that if you continue saying this that it will somehow become true? LYO: Yes, I believe that discussing issues on the mailing list may actually lead to some better understanding and common agreement :o) BTW, I did not mean to imply that ALL other people on the list agreed, just that there were multiple (at least 4-5) views in support of this. > I'm > not sure, therefore, why this would create an inconsistency with 3473 > (I guess there is a case where the ERO contains the terminating > endpoint node ID and an explicit label, but if the connection is > SPC the procedures are not defined). JD: What makes you think that there are not SPC implementations that use RFC3473? LYO: There may be SPC implementations, but 3473 does not itself define how to convey an SPC label. > > It seems like people are bound and determined to go their own > way on this, although I'm not sure why. JD: I'm assuming that you're referring to youself? LYO: Actually, I apologize for that last remark, I was just concerned seeing people writing new procedures when we hadn't reached some kind of consensus on the list. > > > Cheers, > > Lyndon > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 21:33:03 +0000 Message-Id: <200311172130.hAHLUkt12753@merlot.juniper.net> To: "'Ong, Lyndon'" cc: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: spc connections MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50091.1069104646.1@juniper.net> Date: Mon, 17 Nov 2003 13:30:46 -0800 From: Yakov Rekhter Lyndon, > I understand that you have many aspects to weigh, and 7713.2 is > only one of them. However, the SPC Label procedure is one where > there have been no technical issues, and it has been implemented > and tested. Other people on the list have concluded that there > is a reasonable case for separating this from the ERO, and it is > not in fact supported by the current procedures in 3473. Other people on the list have concluded that there is *not* a reasonable case for separating this from the ERO, and that explaining the processing of the ERO is sufficient. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 21:07:03 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048DA9@nimbus.chromisys.com> From: John Drake To: "'Ong, Lyndon'" , 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: spc connections Date: Mon, 17 Nov 2003 13:05:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > Sent: Monday, November 17, 2003 12:53 PM > To: 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: RE: spc connections > > > Hi Kireeti, > > I'll be happy to provide feedback any time. > > > > Being consistent with G.7713.2 isn't at the top of my list until the > many issues with 7713.2 are cleared up. Being consistent with 3473 is > at the very top of my list. Reusing objects defined in 3473 (which is > an IETF Standards Track document), and more fully explaining their > processing where needed is exactly what CCAMP should be doing. > > Kireeti. > ------- > > I understand that you have many aspects to weigh, and 7713.2 is > only one of them. However, the SPC Label procedure is one where > there have been no technical issues, and it has been implemented > and tested. Other people on the list have concluded that there > is a reasonable case for separating this from the ERO, and it is > not in fact supported by the current procedures in 3473. JD: Do you think that if you continue saying this that it will somehow become true? > I'm > not sure, therefore, why this would create an inconsistency with 3473 > (I guess there is a case where the ERO contains the terminating > endpoint node ID and an explicit label, but if the connection is > SPC the procedures are not defined). JD: What makes you think that there are not SPC implementations that use RFC3473? > > It seems like people are bound and determined to go their own > way on this, although I'm not sure why. JD: I'm assuming that you're referring to youself? > > > Cheers, > > Lyndon > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 20:53:55 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61F9@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: spc connections Date: Mon, 17 Nov 2003 12:52:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Kireeti, I'll be happy to provide feedback any time. Being consistent with G.7713.2 isn't at the top of my list until the many issues with 7713.2 are cleared up. Being consistent with 3473 is at the very top of my list. Reusing objects defined in 3473 (which is an IETF Standards Track document), and more fully explaining their processing where needed is exactly what CCAMP should be doing. Kireeti. ------- I understand that you have many aspects to weigh, and 7713.2 is only one of them. However, the SPC Label procedure is one where there have been no technical issues, and it has been implemented and tested. Other people on the list have concluded that there is a reasonable case for separating this from the ERO, and it is not in fact supported by the current procedures in 3473. I'm not sure, therefore, why this would create an inconsistency with 3473 (I guess there is a case where the ERO contains the terminating endpoint node ID and an explicit label, but if the connection is SPC the procedures are not defined). It seems like people are bound and determined to go their own way on this, although I'm not sure why. Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 20:36:54 +0000 Message-Id: <4.3.2.7.2.20031117153132.04bde3d0@mo-ex1> Date: Mon, 17 Nov 2003 15:35:05 -0500 To: "Kireeti Kompella" From: Lou Berger Subject: Egress Control (was Re: spc connections) Cc: "Berger, Lou" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:51 PM 11/15/2003, Kireeti Kompella wrote: >Hi Lou, > >On Sat, 15 Nov 2003, Lou Berger wrote: > > > As I mentioned in that mail, I agree that explicitly documenting > > egress label control seems like the thing to do now. I suggest that this > > be done in a standalone document as it has application outside of > > overlay/UNI. The text below is overly specific. > >First, let's make the text (procedures) more general. Then we can >figure out where it goes. My preference is to keep it in this doc. > >Kireeti. >------- See below for the my proposal on the clarification. I'll submit this as a draft once folks have a chance to comment. Assuming the draft goes forward, I think it should be on the Informational track. Also, Having some text in the overlay document would be fine as well. Lou ------------------------------------------------------------------------- GMPLS Signaling Procedure For Egress Control Abstract This note clarifies the procedures for the control of a label used on an egress output/downstream interface. Such control is also know and "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471] and [RFC3473]. This note does not modify GMPLS signaling mechanisms and procedures and should be viewed as an informative clarification of [RFC3473]. 1. Background The ability to control a label used on an egress output/downstream interface was one of the early requirements for GMPLS. In the initial GMPLS drafts, this was called "Egress Control". As the GMPLS drafts progressed, the ability to control a label on an egress interface was generalized to support control of a label on any interface. This generalization is seen in Section 6 of [RFC3471] and Section 5.1 of [RFC3473]. In generalizing this functionality, the procedures to support control of a label at the egress were also generalized. While the resulting was intended to cover egress control, this intention is not clear to all. This note reiterates the procedures to cover control of a label used on an egress output/downstream interface. For context, the following is the text from the GMPLS signaling draft dated June 2000: 6. Egress Control The LSR at the head-end of an LSP can control the termination of the LSP by using the ERO. To terminate an LSP on a particular outgoing interface of the egress LSR, the head-end may specify the IP address of that interface as the last element in the ERO, provided that that interface has an associated IP address. There are cases where the use of IP address doesn't provide enough information to uniquely identify the egress termination. One case is when the outgoing interface on the egress LSR is a component link of a link bundle. Another case is when it is desirable to "splice" two LSPs together, i.e., where the tail of the first LSP would be "spliced" into the head of the second LSP. This last case is more likely to be used in the non-PSC classes of links. and 6.2. Procedures The Egress Label subobject may appear only as the last subobject in the ERO/ER. Appearance of this subobject anywhere else in the ERO/ER is treated as a "Bad strict node" error. During an LSP setup, when a node processing the ERO/RR performs Next Hop selection finds that the second subobject is an Egress Label Subobject, the node uses the information carried in this subobject to determine the handling of the data received over that LSP. Specifically, if the Link ID field of the subobject is non zero, then this field identifies a specific (outgoing) link of the node that should be used for sending all the data received over the LSP. If the Label field of the subobject is not Implicit NULL label, this field specifies the label that should be used as an outgoing label on the data received over the LSP. Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Egress Label subobject are outside the scope of this document. 2. Egress Control Procedures This section is intended to compliment Section 5.1.1 and 5.2.1 of [RFC3473]. The procedures described in that section are not modified. This section clarifies procedures related to the label used on an egress output/downstream interface. 2.1. ERO Procedures Egress Control occurs when the node processing an ERO is the egress and the ERO contains one or more label subobjects. In this case, the outgoing/downstream interface is indicated in the ERO as the last listed local interface. Note that an interface may be numbered or unnumbered, and bundled or unbundled. To support Egress Control, an egress checks to see if the received ERO contains an outgoing/downstream interface. If it does, the type of the subobject or subobjects following the interface are examined. If the associated LSP is unicast, one subobject is examined. Two subobjects are examined for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then the value of the label is copied into a new Label_Set object. This Label_Set object indicates the label value that MUST be used for transmitting traffic associated with the LSP on the indicated outgoing/downstream interface. If the U-bit of the subobject being examined is set (1), then the value of the label is used for upstream traffic associated with the bidirectional LSP. Specifically, the label value will be used for the traffic associated with the LSP that will be received on the indicated outgoing/downstream interface. Per [RFC3473], any errors encountered while processing the ERO, including if the listed label(s) are not acceptable or cannot be supported in forwarding, SHOULD result in the generation of a message containing a "Bad EXPLICIT_ROUTE object" error. 2.2. RRO Procedures In the case where an ERO is used to specify outgoing interface information at the egress, the egress should include the specified interface information and label or labels, if present, in the corresponding RRO. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 20:11:50 +0000 Message-ID: <3FB92B1D.5030905@alcatel.be> Date: Mon, 17 Nov 2003 21:10:05 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Ben Mack-Crane Cc: Dimitri Papadimitriou , Ong Lyndon , "'John Drake'" , "'yhwkim@etri.re.kr'" , Jonathan.Sadler@tellabs.com, adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: spc connections Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed ben, see in-line Ben Mack-Crane wrote: > Dimitri Papadimitriou wrote: > >> ben, >> >> your response is confusing what you say is that >> the operator at the as boundary can accept a call >> that specifies accessing a specific end-point but >> does not accept the connection request associated >> to this call - does this make any sense ? > > Yes, it does. For instance, an operator receiving a > request for an Ethernet P-P call (service) may decide > to deliver that service over a lambda network or over > a SONET/SDH network using virtual concatenation. this confirms that the delivery of the ethernet end- to-end "connection" may include a single object ERO being the last hop, now that this triggers internal SDH switched connections this is up to the internals of the network, but remark here that there is by no way a control plane driven "call establishment" except if you were referring to a client initiated switched connection which is not the case seeing the title of this thread - first clarification > Thus the connection(s) used to realize the service (call) > may be quite different. Separating call attributes > from connection attributes so that they can be easily > distinguished contributes to a simpler protocol > (and simpler implementation). i took a look back at G.7713 and it mentions, that "To support Soft Permanent Connection (SPC) service, the Call Process is handled by the management plane, with management requesting the CC to establish connections in support of the call." there is no mention about calls processed by the control plane for spc's - second clarification note: CC = Connection Controller >> more fundamentally, i don't see where the delivery >> of call functionality for spc's does have to imply some implementation >> specific restrictions to fulfil >> this functional requirement ? when you point out >> here that the "ERO may be disregarded" it becomes >> a protocol requirement not a functional requirement >> and afaik G.8080 does have nothing to do with any >> implementation specifics >> > As you say, while it is a requirement that call/connection > separation is provided for SPCs as well as SCs according to G.8080, > this does not create a protocol requirement per se. in particular for SPCs for which the call are processed by the management plane, the network switched connection being processed by the control plane > My observation is simply that the protocol design will > benefit from separating call and connection information > as this leads to a protocol that simply meets the requirement. > Other (more complex) protocol designs are possible, > though I would like to avoid them. since there is no "control plane driven call" in spc, such considerations boil down in delivering protocol design that supports SP *Connection* your proposal can also be put in the basket of "add more objects to make it less complex" however this is still to be demonstrated >> now concerning the source of information, you're >> mismatching what lyndon said "passing information >> from the management to the control plane" with the control plane >> exchange of information between call/connection controllers the whole discussion point has been raised because lyndon made a distinction in ways for setting up SPC's (from the source of the end-point information) not the one you're bringing up here > I'm not certain I understand your point here. > I think principles of good information structure apply in any case. that the process of establishing the SPC is independent of the way management process the associated call, yes this is certainly true, that you want to use the control plane for these calls this seems in contradiction with G.7713, also, i'd like also to mention that there is a difference in - the end-to-end association between the edge permanent connection and network switched connection (= spc) - from the establishment of the switched connection within the network itself >> the conclusion, as also drawn by several people on >> this list seem clear: >> >> "There is no change in protocol to enable this function, merely a >> description of how it all works." >> >> something that will be addressed in order to avoid >> spreading of misunderstanding note that this conclusion still holds and is in imho addressed by the text proposed by kireeti >> thanks, >> - dimitri. >> >> >>> Dimitri, >>> >>> The reason that the SPC Label (or Egress Label) should be in a >>> separate object from the ERO >>> is that the ERO may be ignored. >>> >>> This is not unrelated to the source of the information, in that the >>> ERO is provided by some >>> network control or administrative entity while the call endpoint >>> identificaiton is provided by the entity >>> requesting the service. In fulfilling a service request, a service >>> provider may disregard the ERO >>> but may not disregard the service request. Thus it makes perfect >>> sense to keep these pieces >>> of information in separate objects. >>> >>> Regards, >>> Ben >>> >>> Dimitri Papadimitriou wrote: >>> >>> >>> >>>> lyndon, the fact that you may receive the "information" from an >>>> nms/ems, manually configured, or any other means does not have to >>>> impact the external behaviour of the protocol - what you suggest is >>>> the use of a >>>> mechanism that would depend on the originator of the "information" - >>>> >>>> while rfc 3473 specifies in section 5.1.1: >>>> "Procedures by which an LSR at the head-end of an LSP obtains the >>>> information needed to construct the Label subobject are outside the >>>> scope of this document." >>>> >>>> the only thing that needs to be specified for this subobject is the >>>> placement and ordering in the ERO (as specified in the same section) >>>> >>>> in addition - and as far as my understanding goes - there are no >>>> functional requirements mandating - this should be somewhat obvious - >>>> the implementation specific mechanism you describe here below >>>> >>>> hope this will help you to understand what we're trying to explain >>>> you since last monday (john, adrian, etc. via private and public >>>> e-mails) >>>> >>>> thanks, >>>> - dimitri. >>>> >>>> >>>> >>>> > > > > ----------------------------------------- > ============================================================ > The information contained in this message may be privileged and > confidential and protected from disclosure. If the reader of this > message is not the intended recipient, or an employee or agent > responsible for delivering this message to the intended recipient, you > are hereby notified that any reproduction, dissemination or distribution > of this communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by replying to the > message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 19:20:20 +0000 Message-ID: <3FB91E7E.40101@tellabs.com> Date: Mon, 17 Nov 2003 13:16:15 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Adrian Farrel CC: Dimitri Papadimitriou , "Ong, Lyndon" , "'John Drake'" , yhwkim@etri.re.kr, Jonathan.Sadler@tellabs.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: spc connections Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" Adrian, Here is my attempt to make sense of things (and address your questions below). An ERO is a protocol specific instance of G.7713's Explicit Resource List, which specifies the route of a connection. Some services are realized by multiple connections, which may have different EROs. This detail may be a bit less clear for services that are implemented by just one connection, but certainly an ERO is associated with a connection. Under some circumstances a service request may contain constraints. Thus a list of resources to use to realize a service (like an ERO) may be included in a service request. However, service providers often want to maintain control of routing in their networks, and in fact hide internal network details (topology, addressing, etc.) from service requesters outside the network. Therefore, a reasonable policy would be to ignore EROs received from some service requesters. Clearly, it is up to the service requester to specify the endpoints for a service request. These endpoints are specified using identifiers for Access Group Containers (AGC) which are taken from a different space from that used for internal network addresses. Specifying the service endpoint in the ERO is possible; however, this leads to some problems: 1) The endpoint must be specified using an internal network address. This may be unacceptable for service providers involved in inter-domain SPC setup that do not want to publish internal addresses outside their domain. 2) To avoid publishing internal addresses, AGC IDs could be used instead; however this would require extending the ERO definition to carry AGC IDs. 3) ERO processing rules must be enhanced to include methods for determining, based on content, whether (or what parts of) an ERO should be honored for a given service requester. (A simple "ignore" policy is no longer adequate.) These problems are more easily addressed (or don't arise) if the endpoint identification is encoded in an object separate from the ERO. Regards, Ben Adrian Farrel wrote: >Just another 2 cents. > >Lyndon correctly says that 3473 does not make the use of egress label control properly >clear. >John and Lou are right that the intention of the authors was to embrace egress label >control. > >Two small points worry me. >Lyndon says > ...the ERO, which may typically be calculated by the > source endpoint rather than passed down from the management system. >and Ben says > > >>In fulfilling a service request, a service provider may disregard the ERO >>but may not disregard the service request. >> >> > >Why is the ERO not considered as part of the service request? >For example, the service requester may have some strong views about which nodes should be >included on the path. >The service provider may run path computation on the (partial) ERO supplied by the >requester. > >Even when the ERO from the requester is otherwise empty, it *could* contain the >destination node and egress label. > > >I think we are arguing about whether implementations can be produced for one solution or >the other. I'm sure they can. > >In the debate about whether we have or need to have more than one solution, we should look >at what has been implemented and deployed. We can then decide whether it is harmful to >have two solutions, and whether we need to deprecate one of them. > >Adrian > > > > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 18:33:43 +0000 Message-Id: <200311171832.hAHIWdt83387@merlot.juniper.net> To: Kireeti Kompella cc: ccamp@ops.ietf.org Subject: Re: spc connections MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94075.1069093959.1@juniper.net> Date: Mon, 17 Nov 2003 10:32:39 -0800 From: Yakov Rekhter Kireeti, > Hi Lyndon, > > On Fri, 14 Nov 2003, Ong, Lyndon wrote: > > > Actually the extensions in the GMPLS Overlay draft would not > > be sufficient. Overlay deals again with signaled interfaces > > rather than SPC. > > You make a good point. A minor inaccuracy is that the signaling can > be sent across the 'ingress UNI' without having signaling across the > 'egress UNI' (if you'll forgive my abuse of terminology). > > How about the following further clarification: > > REPLACE: > > 3.3. Explicit Label Control > > In order to support explicit label control and full identification of > the egress link, an ingress edge-node may include an ERO whose last > group of subobjects are set as follows: > > WITH: > > 3.3. Explicit Label Control > > Four signaling modes to establish a connection from the ingress > edge-node to the egress edge-node are described here. The first is > a Switched Connection (SC), where the ingress edge-node signals all > the way to the egress edge-node. The second is a Soft Permanent > Connection (SPC) where the ingress core-node signals to the egress > core-node. The third is a hybrid signaling mode where an ingress > edge-node signals to the egress core-node. The final mode is when > an ingress core-node signals to the egress edge-node; this uses the > same procedures as SCs, and will not be further elaborated. > > In order to support modes two and three, the ingress signaling node > (ingress core-node for mode 2 and ingress edge-node for mode 3) must > identify the egress link, i.e., the link between the egress core-node > and the egress edge-node. This is done using explicit label control. > An ingress signaling node may include an ERO whose last group of > subobjects are set as follows: > (etc.) > > END That would be fine. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 18:24:58 +0000 Message-ID: <3FB9118B.4030007@tellabs.com> Date: Mon, 17 Nov 2003 12:20:59 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Dimitri Papadimitriou CC: Ong Lyndon , "'John Drake'" , "'yhwkim@etri.re.kr'" , Jonathan.Sadler@tellabs.com, adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: spc connections Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" Dimitri, See comments in-line below. Regards, Ben Dimitri Papadimitriou wrote: >ben, > >your response is confusing what you say is that >the operator at the as boundary can accept a call >that specifies accessing a specific end-point but >does not accept the connection request associated >to this call - does this make any sense ? > Yes, it does. For instance, an operator receiving a request for an Ethernet P-P call (service) may decide to deliver that service over a lambda network or over a SONET/SDH network using virtual concatenation. Thus the connection(s) used to realize the service (call) may be quite different. Separating call attributes from connection attributes so that they can be easily distinguished contributes to a simpler protocol (and simpler implementation). >more fundamentally, i don't see where the delivery >of call functionality for spc's does have to imply >some implementation specific restrictions to fulfil >this functional requirement ? when you point out >here that the "ERO may be disregarded" it becomes >a protocol requirement not a functional requirement >and afaik G.8080 does have nothing to do with any >implementation specifics > As you say, while it is a requirement that call/connection separation is provided for SPCs as well as SCs according to G.8080, this does not create a protocol requirement per se. My observation is simply that the protocol design will benefit from separating call and connection information as this leads to a protocol that simply meets the requirement. Other (more complex) protocol designs are possible, though I would like to avoid them. >now concerning the source of information, you're >mismatching what lyndon said "passing information >from the management to the control plane" with >the control plane exchange of information between >call/connection controllers > I'm not certain I understand your point here. I think principles of good information structure apply in any case. >the conclusion, as also drawn by several people on >this list seem clear: > >"There is no change in protocol to enable this function, >merely a description of how it all works." > >something that will be addressed in order to avoid >spreading of misunderstanding > >thanks, >- dimitri. > > >>Dimitri, >> >>The reason that the SPC Label (or Egress Label) should be in a separate >>object from the ERO >>is that the ERO may be ignored. >> >>This is not unrelated to the source of the information, in that the ERO >>is provided by some >>network control or administrative entity while the call endpoint >>identificaiton is provided by the entity >>requesting the service. In fulfilling a service request, a service >>provider may disregard the ERO >>but may not disregard the service request. Thus it makes perfect sense >>to keep these pieces >>of information in separate objects. >> >>Regards, >>Ben >> >>Dimitri Papadimitriou wrote: >> >> >> >>>lyndon, the fact that you may receive the "information" from an nms/ems, >>>manually configured, or any other means does not have to impact the >>>external behaviour of the protocol - what you suggest is the use of a >>>mechanism that would depend on the originator of the "information" - >>> >>>while rfc 3473 specifies in section 5.1.1: >>>"Procedures by which an LSR at the head-end of an LSP obtains the >>>information needed to construct the Label subobject are outside the >>>scope of this document." >>> >>>the only thing that needs to be specified for this subobject is the >>>placement and ordering in the ERO (as specified in the same section) >>> >>>in addition - and as far as my understanding goes - there are no >>>functional requirements mandating - this should be somewhat obvious - >>>the implementation specific mechanism you describe here below >>> >>>hope this will help you to understand what we're trying to explain >>>you since last monday (john, adrian, etc. via private and public >>>e-mails) >>> >>>thanks, >>>- dimitri. >>> >>> >>> >>> ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 18:09:39 +0000 Reply-To: From: "Vishal Sharma" To: "Zafar Ali" , "Kireeti Kompella" Cc: Subject: RE: ASON Routing Requirements to WG doc Date: Mon, 17 Nov 2003 10:04:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C3ACF2.3DD1F960" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C3ACF2.3DD1F960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Kireeti, Zafar, et al, I think the idea of the DT working co-operatively with the ITU-T, and having some room for the DT (and CCAMP) to iteratively work on the routing requirements is a very good idea. In fact, this ties back to the comment I had first made when Deborah was drafting the liason statement on behalf of the WG to send to the ITU-T a few weeks ago. Lyndon had clarified then that some items in G.7715.1 were themselves "work in progress", so I think this is the perfect time for CCAMP and IETF to : (a) study the ASON docs. to determine what more is needed in the GMPLS suite of protocols, (b) seek clarifications from the ITU-T, and (c) provide inputs to the ITU-T. So, I would definitely support the idea of having the DT (and, in fact, the WG as a whole) spending some time understanding the ASON routing requirements (instead of merely adopting them), and, if necessary, providing inputs to the ITU-T SG15 relative to G.7715 and G.7715.1. -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Zafar Ali Sent: Monday, November 17, 2003 7:03 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: ASON Routing Requirements to WG doc Hi Kireeti, I understand that the requirements that fall out of the scope of ITU-T recommendations are NOT part of this document/ work. However, I would like to understand some of the requirements in the document a little better. Specifically, when the document mentions that “- support multiple hierarchical levels”, my question how many level of hierarchy is implied here? Similarly, when a requirement like, “- support architectural evolution in terms of the number of levels of hierarchies, aggregation and segmentation of (control ?) domains” is stated, I would like to again understand the notion of “levels of hierarchies”. In short, I think there are a lots of TBD’s in the document that DT will be closing with ITU. I would like to see this as an “interactive” process, rather than something like "here are the requirements, period". I think for the sake of prioritization and for providing cross-organization feedback, it will be very important to have some "room" for DT and ccamp. Thanks Regards… Zafar ================================================================= Zafar Ali, Ph. D. 100 South Main St. #200, Technical Leader, Ann Arbor, MI 48104, USA. Cisco Systems. (734) 276-2459. ================================================================= At 07:42 PM 11/16/2003 -0800, Kireeti Kompella wrote: Hi Zafar, On Sun, 16 Nov 2003, Zafar Ali wrote: Thanks for your input! > Deborah made a very good point about goals of the design team during the WG > meeting. Specifically, she mentioned that the DT will work closely with ITU > to understand the requirements. Excellent. > I would really like to make sure that the > requirements are coming from the service providers If you read the design team charter, you'll see that the requirements come from the ITU, and that requirements *not* from the ITU have no place, especially since the document is entitled "ASON Routing Requirements". However, the assumption is that the ITU got their input from service providers (or carriers). > and not from specific > implementations. So, I would like to see more activity from the DT in > closing on the requirements in the light of the needs of service providers, > before agreeing to the notion. Requirements from specific implementations and requirements that the DT 'closes on ... [from] service providers' are not relevant in this particular document. If there is a 'further requirements for GMPLS routing', your concerns would be very relevant and valuable. However, for this document, given the charter of the design team, I would ask you to reconsider. Thanks, Kireeti. ------- ------=_NextPart_000_000E_01C3ACF2.3DD1F960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Kireeti, Zafar, et al,
 
I=20 think the idea of the DT working co-operatively with the ITU-T, and = having some=20 room for
the DT=20 (and CCAMP) to iteratively work on the routing requirements is a very = good=20 idea.
 
In=20 fact, this ties back to the comment I had first made when Deborah was = drafting=20 the liason
statement on behalf of the WG to send to the ITU-T a few weeks = ago.=20 Lyndon had clarified
then that some items in G.7715.1 = were=20 themselves "work in progress", so I think this is
the perfect time for CCAMP and = IETF=20 to :
(a) study the ASON docs. to = determine what=20 more is needed in the GMPLS = suite of=20 protocols,  
(b) seek clarifications from the = ITU-T,=20 and
(c) provide inputs to the=20 ITU-T.
 
So, I=20 would definitely support the idea of having the DT (and, in = fact, the=20 WG as a whole)
spending some time understanding the ASON routing=20 requirements (instead of merely
adopting them), and, if necessary,=20 providing inputs to the ITU-T SG15 relative to=20 G.7715
and=20 G.7715.1.
 
-Vishal
-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Zafar = Ali
Sent:=20 Monday, November 17, 2003 7:03 AM
To: Kireeti = Kompella
Cc:=20 ccamp@ops.ietf.org
Subject: Re: ASON Routing Requirements to = WG=20 doc

Hi Kireeti,

I = understand that the=20 requirements that fall out of the scope of ITU-T recommendations are = NOT part=20 of this document/ work. However, I would like to understand some of = the=20 requirements in the document a little better. Specifically, when the = document=20 mentions that “- support multiple hierarchical levels”, my = question how many=20 level of hierarchy is implied here? Similarly, when a requirement = like, “-=20 support architectural evolution in terms of the number of levels of=20 hierarchies, aggregation and segmentation of (control ?) = domains” is stated, I=20 would like to again understand the notion of “levels of = hierarchies”.=20

In short, I think there are a lots of TBD’s in the = document that DT=20 will be closing with ITU. I would like to see this as an = “interactive”=20 process, rather than something like "here are the requirements, = period". I=20 think for the sake of prioritization and for providing = cross-organization=20 feedback, it will be very important to have some "room" for DT and = ccamp.=20

Thanks

Regards…=20 = Zafar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zafar=20 Ali, Ph. D.=20 =         &nb= sp;         &= nbsp;         = ;   =20 100 South Main St. #200,
Technical Leader,=20 =         &nb= sp;         &= nbsp;         = ;   =20 Ann Arbor, MI 48104, USA.
Cisco=20 = Systems.       &= nbsp;         = ;          =20 (734)=20 = 276-2459.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


A= t=20 07:42 PM 11/16/2003 -0800, Kireeti Kompella wrote:
Hi Zafar,

On Sun, 16 Nov 2003, = Zafar Ali=20 wrote:

Thanks for your input!

> Deborah made a very = good=20 point about goals of the design team during the WG
> meeting.=20 Specifically, she mentioned that the DT will work closely with = ITU
>=20 to understand the requirements.

Excellent.

> I = would really=20 like to make sure that the
> requirements are coming from the = service=20 providers

If you read the design team charter, you'll see = that the=20 requirements
come from the ITU, and that requirements *not* from = the ITU=20 have no
place, especially since the document is entitled "ASON=20 Routing
Requirements".  However, the assumption is that the = ITU got=20 their
input from service providers (or carriers).

> and = not=20 from specific
> implementations. So, I would like to see more = activity=20 from the DT in
> closing on the requirements in the light of = the needs=20 of service providers,
> before agreeing to the=20 notion.

Requirements from specific implementations and = requirements=20 that the
DT 'closes on ... [from] service providers' are not = relevant in=20 this
particular document.  If there is a 'further = requirements for=20 GMPLS
routing', your concerns would be very relevant and=20 valuable.

However, for this document, given the charter of = the design=20 team, I
would ask you to=20 = reconsider.

Thanks,
Kireeti.
-------
------=_NextPart_000_000E_01C3ACF2.3DD1F960-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 16:06:51 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AD24.8AA99686" Subject: RE: ASON Routing Requirements to WG doc Date: Mon, 17 Nov 2003 10:04:55 -0600 Message-ID: <6579C6377F475547985F0B3E426E1626049F94BB@OCCLUST01EVS1.ugd.att.com> Thread-Topic: ASON Routing Requirements to WG doc Thread-Index: AcOtHCtC5EneX8A+RI2a7vy8FPi7qAABiQmQ From: "Aguirre-Torres, Luis, ALABS" To: "Zafar Ali" , "Kireeti Kompella" Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AD24.8AA99686 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Zafar, =20 I agree with you. I think this has to be an iterative process and I would expect the DT to make sure the requirements from ITU are considered and fully understood. Echoing Wesam's and Steve's comments, G.7715 as well as G.7715.1 were co-edited by major carriers with strong involvement from a number of experts representing equipment vendors at ITU-T, some of which will also be part of the Design Team. I believe there is room for the DT and CCAMP to work with ITU to further clarify, if required, any of the ASON routing requirements. =20 Luis =20 -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com]=20 Sent: Monday, November 17, 2003 10:03 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: ASON Routing Requirements to WG doc =20 Hi Kireeti,=20 I understand that the requirements that fall out of the scope of ITU-T recommendations are NOT part of this document/ work. However, I would like to understand some of the requirements in the document a little better. Specifically, when the document mentions that "- support multiple hierarchical levels", my question how many level of hierarchy is implied here? Similarly, when a requirement like, "- support architectural evolution in terms of the number of levels of hierarchies, aggregation and segmentation of (control ?) domains" is stated, I would like to again understand the notion of "levels of hierarchies".=20 In short, I think there are a lots of TBD's in the document that DT will be closing with ITU. I would like to see this as an "interactive" process, rather than something like "here are the requirements, period". I think for the sake of prioritization and for providing cross-organization feedback, it will be very important to have some "room" for DT and ccamp.=20 Thanks Regards... Zafar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zafar Ali, Ph. D. 100 South Main St. #200, Technical Leader, Ann Arbor, MI 48104, USA. Cisco Systems. (734) 276-2459. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 07:42 PM 11/16/2003 -0800, Kireeti Kompella wrote: Hi Zafar, On Sun, 16 Nov 2003, Zafar Ali wrote: Thanks for your input! > Deborah made a very good point about goals of the design team during the WG > meeting. Specifically, she mentioned that the DT will work closely with ITU > to understand the requirements. Excellent. > I would really like to make sure that the > requirements are coming from the service providers If you read the design team charter, you'll see that the requirements come from the ITU, and that requirements *not* from the ITU have no place, especially since the document is entitled "ASON Routing Requirements". However, the assumption is that the ITU got their input from service providers (or carriers). > and not from specific > implementations. So, I would like to see more activity from the DT in > closing on the requirements in the light of the needs of service providers, > before agreeing to the notion. Requirements from specific implementations and requirements that the DT 'closes on ... [from] service providers' are not relevant in this particular document. If there is a 'further requirements for GMPLS routing', your concerns would be very relevant and valuable. However, for this document, given the charter of the design team, I would ask you to reconsider. Thanks, Kireeti. ------- ------_=_NextPart_001_01C3AD24.8AA99686 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Zafar,

 

I agree with you. I think this has = to be an iterative process and I would expect the DT to make sure the = requirements from ITU are considered and fully understood.

Echoing Wesam’s and Steve’s comments, G.7715 as well as G.7715.1 were co-edited by = major carriers with strong involvement from a number of experts representing equipment vendors at ITU-T, some of which will also be part of the = Design Team. I believe there is room for the DT and CCAMP to work with ITU to further clarify, if required, any of the ASON routing = requirements.

 

Luis

 

-----Original = Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Monday, November = 17, 2003 10:03 AM
To: Kireeti Kompella
Cc: = ccamp@ops.ietf.org
Subject: Re: ASON Routing Requirements to WG doc

 

Hi Kireeti,

I understand that the requirements that fall out of the scope of ITU-T recommendations are NOT part of this document/ work. However, I would = like to understand some of the requirements in the document a little better. = Specifically, when the document mentions that “- support multiple hierarchical levels”, my question how many level of hierarchy is implied here? Similarly, when a requirement like, “- support architectural = evolution in terms of the number of levels of hierarchies, aggregation and = segmentation of (control ?) domains” is stated, I would like to again understand = the notion of “levels of hierarchies”.

In short, I think there are a lots of TBD’s in the document that = DT will be closing with ITU. I would like to see this as an = “interactive” process, rather than something like "here are the requirements, period". I think for the sake of prioritization and for providing cross-organization feedback, it will be very important to have some = "room" for DT and ccamp.

Thanks

Regards… Zafar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zafar Ali, Ph. D. =         &nb= sp;         &= nbsp;         = ;    100 South Main St. #200,
Technical Leader, =         &nb= sp;         &= nbsp;         = ;    Ann Arbor, MI 48104, USA.
Cisco = Systems.       &= nbsp;         = ;           (734) 276-2459.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


At 07:42 PM 11/16/2003 -0800, Kireeti Kompella wrote:

Hi Zafar,

On Sun, 16 Nov 2003, Zafar Ali wrote:

Thanks for your input!

> Deborah made a very good point about goals of the design team = during the WG
> meeting. Specifically, she mentioned that the DT will work closely = with ITU
> to understand the requirements.

Excellent.

> I would really like to make sure that the
> requirements are coming from the service providers

If you read the design team charter, you'll see that the = requirements
come from the ITU, and that requirements *not* from the ITU have no
place, especially since the document is entitled "ASON Routing
Requirements".  However, the assumption is that the ITU got = their
input from service providers (or carriers).

> and not from specific
> implementations. So, I would like to see more activity from the DT = in
> closing on the requirements in the light of the needs of service providers,
> before agreeing to the notion.

Requirements from specific implementations and requirements that the
DT 'closes on ... [from] service providers' are not relevant in this
particular document.  If there is a 'further requirements for = GMPLS
routing', your concerns would be very relevant and valuable.

However, for this document, given the charter of the design team, I
would ask you to reconsider.

Thanks,
Kireeti.
-------

=00 ------_=_NextPart_001_01C3AD24.8AA99686-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 15:04:16 +0000 Message-Id: <4.3.2.7.2.20031117092251.00b97cd0@toque.cisco.com> Date: Mon, 17 Nov 2003 10:02:47 -0500 To: Kireeti Kompella From: Zafar Ali Subject: Re: ASON Routing Requirements to WG doc Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4181482==_.ALT" --=====================_4181482==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Kireeti, I understand that the requirements that fall out of the scope of ITU-T=20 recommendations are NOT part of this document/ work. However, I would like= =20 to understand some of the requirements in the document a little better.=20 Specifically, when the document mentions that =93- support multiple=20 hierarchical levels=94, my question how many level of hierarchy is implied= =20 here? Similarly, when a requirement like, =93- support architectural=20 evolution in terms of the number of levels of hierarchies, aggregation and= =20 segmentation of (control ?) domains=94 is stated, I would like to again=20 understand the notion of =93levels of hierarchies=94. In short, I think there are a lots of TBD=92s in the document that DT will= be=20 closing with ITU. I would like to see this as an =93interactive=94 process,= =20 rather than something like "here are the requirements, period". I think for= =20 the sake of prioritization and for providing cross-organization feedback,=20 it will be very important to have some "room" for DT and ccamp. Thanks Regards=85 Zafar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zafar Ali, Ph. D. 100 South Main St. #200, Technical Leader, Ann Arbor, MI 48104, USA. Cisco Systems. (734) 276-2459. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 07:42 PM 11/16/2003 -0800, Kireeti Kompella wrote: >Hi Zafar, > >On Sun, 16 Nov 2003, Zafar Ali wrote: > >Thanks for your input! > > > Deborah made a very good point about goals of the design team during the= WG > > meeting. Specifically, she mentioned that the DT will work closely with= ITU > > to understand the requirements. > >Excellent. > > > I would really like to make sure that the > > requirements are coming from the service providers > >If you read the design team charter, you'll see that the requirements >come from the ITU, and that requirements *not* from the ITU have no >place, especially since the document is entitled "ASON Routing >Requirements". However, the assumption is that the ITU got their >input from service providers (or carriers). > > > and not from specific > > implementations. So, I would like to see more activity from the DT in > > closing on the requirements in the light of the needs of service= providers, > > before agreeing to the notion. > >Requirements from specific implementations and requirements that the >DT 'closes on ... [from] service providers' are not relevant in this >particular document. If there is a 'further requirements for GMPLS >routing', your concerns would be very relevant and valuable. > >However, for this document, given the charter of the design team, I >would ask you to reconsider. > >Thanks, >Kireeti. >------- --=====================_4181482==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kireeti,

I understand that the requirements that fall out of the scope of ITU-T recommendations are NOT part of this document/ work. However, I would like to understand some of the requirements in the document a little better. Specifically, when the document mentions that =93- support multiple hierarchical levels=94, my question how many level of hierarchy is implied here? Similarly, when a requirement like, =93- support architectural evolution in terms of the number of levels of hierarchies, aggregation and segmentation of (control ?) domains=94 is stated, I would like to again understand the notion of =93levels of hierarchies=94.

In short, I think there are a lots of TBD=92s in the document that DT will be closing with ITU. I would like to see this as an =93interactive=94 process, rather than something like "here are the requirements, period". I think for the sake of prioritization and for providing cross-organization feedback, it will be very important to have some "room" for DT and ccamp.

Thanks

Regards=85 Zafar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zafar Ali, Ph. D.          =           &= nbsp;         &n= bsp;  100 South Main St. #200,
Technical Leader,          =           &= nbsp;         &n= bsp;  Ann Arbor, MI 48104, USA.
Cisco Systems.       &nbs= p;          = ;        &nbs= p; (734) 276-2459.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


At 07:42 PM 11/16/2003 -0800, Kireeti Kompella wrote:
Hi Zafar,

On Sun, 16 Nov 2003, Zafar Ali wrote:

Thanks for your input!

> Deborah made a very good point about goals of the design team during the WG
> meeting. Specifically, she mentioned that the DT will work closely with ITU
> to understand the requirements.

Excellent.

> I would really like to make sure that the
> requirements are coming from the service providers

If you read the design team charter, you'll see that the requirements
come from the ITU, and that requirements *not* from the ITU have no
place, especially since the document is entitled "ASON Routing
Requirements".  However, the assumption is that the ITU got their
input from service providers (or carriers).

> and not from specific
> implementations. So, I would like to see more activity from the DT in
> closing on the requirements in the light of the needs of service providers,
> before agreeing to the notion.

Requirements from specific implementations and requirements that=20 the
DT 'closes on ... [from] service providers' are not relevant in=20 this
particular document.  If there is a 'further requirements for GMPLS
routing', your concerns would be very relevant and valuable.

However, for this document, given the charter of the design team, I
would ask you to reconsider.

Thanks,
Kireeti.
-------
--=====================_4181482==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 14:56:33 +0000 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60434416B@zcard0ke.ca.nortel.com> From: "Stephen Shew" To: "'Zafar Ali'" , Kireeti Kompella , dbrungard@att.com Cc: ccamp@ops.ietf.org Subject: RE: ASON Routing Requirements to WG doc Date: Mon, 17 Nov 2003 09:54:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AD1A.A659D188" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AD1A.A659D188 Content-Type: text/plain Zafar, the routing requirements (G.7715 and G.7715.1) developed within SG15 of the ITU-T have their basis in ASON architecture (G.8080). G.8080 in turn has constructs (esp. routing areas) based on transport plane architecture (G.805). Other recommendations within the ITU-T as well as outside the ITU-T (notably the TMF814 specification) have G.805 as their basis. Both G.8080 and G.805, as well as other work based on G.805 have had significant carrier participation. Also, the editor of Rec. G.7715 was from UUNET. -----Original Message----- From: Zafar Ali [mailto:zali@cisco.com] Sent: Sunday, November 16, 2003 14:16 To: Kireeti Kompella; dbrungard@att.com Cc: ccamp@ops.ietf.org Subject: Re: ASON Routing Requirements to WG doc Hi Kireeti, Deborah made a very good point about goals of the design team during the WG meeting. Specifically, she mentioned that the DT will work closely with ITU to "understand" the requirements. I would really like to make sure that the requirements are coming from the service providers and not from specific implementations. So, I would like to see more activity from the DT in closing on the requirements in the light of the needs of service providers, before agreeing to the notion. ------_=_NextPart_001_01C3AD1A.A659D188 Content-Type: text/html Message
Zafar, the routing requirements (G.7715 and G.7715.1) developed within SG15 of the ITU-T have their basis in ASON architecture (G.8080).  G.8080 in turn has constructs (esp. routing areas) based on transport plane architecture (G.805).  Other recommendations within the ITU-T as well as outside the ITU-T (notably the TMF814 specification) have G.805 as their basis.  Both G.8080 and G.805, as well as other work based on G.805 have had significant carrier participation.  Also, the editor of Rec. G.7715 was from UUNET.
-----Original Message-----
From: Zafar Ali [mailto:zali@cisco.com]
Sent: Sunday, November 16, 2003 14:16
To: Kireeti Kompella; dbrungard@att.com
Cc: ccamp@ops.ietf.org
Subject: Re: ASON Routing Requirements to WG doc

Hi Kireeti,

Deborah made a very good point about goals of the design team during the WG meeting. Specifically, she mentioned that the DT will work closely with ITU to "understand" the requirements. I would really like to make sure that the requirements are coming from the service providers and not from specific implementations. So, I would like to see more activity from the DT in closing on the requirements in the light of the needs of service providers, before agreeing to the notion.   
------_=_NextPart_001_01C3AD1A.A659D188-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 14:56:14 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON Routing Requirements to WG doc Date: Mon, 17 Nov 2003 08:54:39 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA3645@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON Routing Requirements to WG doc Thread-Index: AcOrvKQUj/5/3Zr3Q9efcy8V/qw2rwBVElSA From: "Ash, Gerald R (Jerry), ALABS" To: "Kireeti Kompella" , Cc: "Ash, Gerald R (Jerry), ALABS" Kireeti, > This is clearly a work in progress, but I would like to=20 > know if you think that this work is going in the right=20 > direction and should be made a WG document Yes, should be a WG document. =20 A couple of minor editorial comments: a. the list of requirements in Section 4 repeats the list in Section 3. b. need to list all the authors in Section 9. Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 14:24:49 +0000 Message-Id: <4.3.2.7.2.20031117091358.00b6aeb8@toque.cisco.com> Date: Mon, 17 Nov 2003 09:21:44 -0500 To: "Alanqar, Wesam I [NTWK SVCS]" From: Zafar Ali Subject: RE: ASON Routing Requirements to WG doc Cc: , "Kireeti Kompella" , Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1717589==_.ALT" --=====================_1717589==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Wasam, I understand your point, but all I am asking that will DT (or CCAMP) have some influence on these requirements, or we are expected to take them "as is"? Thanks Regards... Zafar ============================================================= Zafar Ali, Ph. D. 100 South Main St. #200, Technical Leader, Ann Arbor, MI 48104, USA. Cisco Systems. (734) 276-2459. ============================================================= At 02:11 PM 11/16/2003 -0600, Alanqar, Wesam I [NTWK SVCS] wrote: >ITU G.7715.1 will be a major input to the DT effort. G.7715.1 was >co-edited by two carriers with strong involvements from different vendors. >As a result, the DT output will be mainly driven by carrier requirements. > > > >Thanks, > >-Wesam Alanqar > >Sprint- Technology Research and Development > >ITU SG15 rep to IETF CCAMP > >Co-editor of G.7715.1 > > > >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf >Of Zafar Ali >Sent: Sunday, November 16, 2003 1:16 PM >To: Kireeti Kompella; dbrungard@att.com >Cc: ccamp@ops.ietf.org >Subject: Re: ASON Routing Requirements to WG doc > > > >Hi Kireeti, > >Deborah made a very good point about goals of the design team during the >WG meeting. Specifically, she mentioned that the DT will work closely with >ITU to understand the requirements. I would really like to make sure that >the requirements are coming from the service providers and not from >specific implementations. So, I would like to see more activity from the >DT in closing on the requirements in the light of the needs of service >providers, before agreeing to the notion. > >Thanks > >Regards& Zafar > >=================================================================== >Zafar Ali, Ph. D. 100 South Main St. #200, >Technical Leader, Ann Arbor, MI 48104, USA. >Cisco Systems. (734) 276-2459. >=================================================================== >At 01:06 PM 11/15/2003 -0800, Kireeti Kompella wrote: > >Hi, > >This is a call for consensus to make the document "Requirements for >Generalized MPLS (GMPLS) Routing for Automatically Switched Optical >Network (ASON)" draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt >a CCAMP WG document. > >This is clearly a work in progress, but I would like to know if you >think that this work is going in the right direction and should be >made a WG document, or you think that we should hold off. > >Please reply by midnight PST Nov 23, 2003. > >Thanks, >Kireeti. >------- --=====================_1717589==_.ALT Content-Type: text/html; charset="us-ascii" Hi Wasam,

I understand your point, but all I am asking that will DT (or CCAMP) have some influence on these requirements, or we are expected to take them "as is"?

Thanks

Regards... Zafar

=============================================================
Zafar Ali, Ph. D.                                 100 South Main St. #200,
Technical Leader,                                 Ann Arbor, MI 48104, USA.
Cisco Systems.                                    (734) 276-2459.
=============================================================

At 02:11 PM 11/16/2003 -0600, Alanqar, Wesam I [NTWK SVCS] wrote:

ITU G.7715.1 will be a major input to the DT effort. G.7715.1 was co-edited by two carriers with strong involvements from different vendors. As a result, the DT output will be mainly driven by carrier requirements.

 

Thanks,

-Wesam Alanqar

Sprint- Technology Research and Development

ITU SG15 rep to IETF CCAMP

Co-editor of G.7715.1

 

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali
Sent: Sunday, November 16, 2003 1:16 PM
To: Kireeti Kompella; dbrungard@att.com
Cc: ccamp@ops.ietf.org
Subject: Re: ASON Routing Requirements to WG doc

 

Hi Kireeti,

Deborah made a very good point about goals of the design team during the WG meeting. Specifically, she mentioned that the DT will work closely with ITU to understand the requirements. I would really like to make sure that the requirements are coming from the service providers and not from specific implementations. So, I would like to see more activity from the DT in closing on the requirements in the light of the needs of service providers, before agreeing to the notion.   

Thanks

Regards& Zafar 

===================================================================
Zafar Ali, Ph. D.                                 100 South Main St. #200,
Technical Leader,                                 Ann Arbor, MI 48104, USA.
Cisco Systems.                                    (734) 276-2459.
===================================================================
At 01:06 PM 11/15/2003 -0800, Kireeti Kompella wrote:

Hi,

This is a call for consensus to make the document "Requirements for
Generalized MPLS (GMPLS) Routing for Automatically Switched Optical
Network (ASON)" draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt
a CCAMP WG document.

This is clearly a work in progress, but I would like to know if you
think that this work is going in the right direction and should be
made a WG document, or you think that we should hold off.

Please reply by midnight PST Nov 23, 2003.

Thanks,
Kireeti.
-------
--=====================_1717589==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 03:49:21 +0000 Date: Sun, 16 Nov 2003 19:47:04 -0800 (PST) From: Kireeti Kompella To: Adrian Farrel cc: ccamp@ops.ietf.org Subject: Re: spc connections Message-ID: <20031116194311.U55840@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 16 Nov 2003, Adrian Farrel wrote: > Just another 2 cents. Pennies? > and Ben says > > In fulfilling a service request, a service provider may disregard the ERO > > but may not disregard the service request. Perhaps Ben is referring to section 3 of the overlay doc. However, in the case of SPC, this section doesn't apply, as the initiator of the request is not the ingress edge-node, but rather the ingress core-node, so 'normal' GMPLS rules apply. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 03:46:48 +0000 Date: Sun, 16 Nov 2003 19:42:05 -0800 (PST) From: Kireeti Kompella To: Zafar Ali cc: ccamp@ops.ietf.org Subject: Re: ASON Routing Requirements to WG doc Message-ID: <20031116192500.Y55840@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Zafar, On Sun, 16 Nov 2003, Zafar Ali wrote: Thanks for your input! > Deborah made a very good point about goals of the design team during the WG > meeting. Specifically, she mentioned that the DT will work closely with ITU > to understand the requirements. Excellent. > I would really like to make sure that the > requirements are coming from the service providers If you read the design team charter, you'll see that the requirements come from the ITU, and that requirements *not* from the ITU have no place, especially since the document is entitled "ASON Routing Requirements". However, the assumption is that the ITU got their input from service providers (or carriers). > and not from specific > implementations. So, I would like to see more activity from the DT in > closing on the requirements in the light of the needs of service providers, > before agreeing to the notion. Requirements from specific implementations and requirements that the DT 'closes on ... [from] service providers' are not relevant in this particular document. If there is a 'further requirements for GMPLS routing', your concerns would be very relevant and valuable. However, for this document, given the charter of the design team, I would ask you to reconsider. Thanks, Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Nov 2003 00:23:18 +0000 Message-ID: <034e01c3ac9c$13a34a50$db818182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ben Mack-Crane" , "Dimitri Papadimitriou" Cc: "Ong, Lyndon" , "'John Drake'" , , , , Subject: Re: spc connections Date: Sun, 16 Nov 2003 23:47:38 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just another 2 cents. Lyndon correctly says that 3473 does not make the use of egress label control properly clear. John and Lou are right that the intention of the authors was to embrace egress label control. Two small points worry me. Lyndon says ...the ERO, which may typically be calculated by the source endpoint rather than passed down from the management system. and Ben says > In fulfilling a service request, a service provider may disregard the ERO > but may not disregard the service request. Why is the ERO not considered as part of the service request? For example, the service requester may have some strong views about which nodes should be included on the path. The service provider may run path computation on the (partial) ERO supplied by the requester. Even when the ERO from the requester is otherwise empty, it *could* contain the destination node and egress label. I think we are arguing about whether implementations can be produced for one solution or the other. I'm sure they can. In the debate about whether we have or need to have more than one solution, we should look at what has been implemented and deployed. We can then decide whether it is harmful to have two solutions, and whether we need to deprecate one of them. Adrian ----- Original Message ----- From: "Ben Mack-Crane" To: "Dimitri Papadimitriou" Cc: "Ong, Lyndon" ; "'John Drake'" ; ; ; ; ; Sent: Friday, November 14, 2003 10:31 PM Subject: Re: spc connections > Dimitri, > > The reason that the SPC Label (or Egress Label) should be in a separate > object from the ERO > is that the ERO may be ignored. > > This is not unrelated to the source of the information, in that the ERO > is provided by some > network control or administrative entity while the call endpoint > identificaiton is provided by the entity > requesting the service. In fulfilling a service request, a service > provider may disregard the ERO > but may not disregard the service request. Thus it makes perfect sense > to keep these pieces > of information in separate objects. > > Regards, > Ben > > Dimitri Papadimitriou wrote: > > >lyndon, the fact that you may receive the "information" from an nms/ems, > >manually configured, or any other means does not have to impact the > >external behaviour of the protocol - what you suggest is the use of a > >mechanism that would depend on the originator of the "information" - > > > >while rfc 3473 specifies in section 5.1.1: > >"Procedures by which an LSR at the head-end of an LSP obtains the > > information needed to construct the Label subobject are outside the > > scope of this document." > > > >the only thing that needs to be specified for this subobject is the > >placement and ordering in the ERO (as specified in the same section) > > > >in addition - and as far as my understanding goes - there are no > >functional requirements mandating - this should be somewhat obvious - > >the implementation specific mechanism you describe here below > > > >hope this will help you to understand what we're trying to explain > >you since last monday (john, adrian, etc. via private and public > >e-mails) > > > >thanks, > >- dimitri. > > > > > > > >>This message is in MIME format. Since your mail reader does not understand > >>this format, some or all of this message may not be legible. > >> > >>------_=_NextPart_001_01C3AAF3.F61BAE90 > >>Content-Type: text/plain; > >> charset="ks_c_5601-1987" > >> > >>Hi John, > >> > >>I apologize for being an uninformed reader :o) As such I can only rely on the text in > >>3473, which is very specific and does not discuss SPC labels. > >> > >>It probably seems intuitively very obvious to you because you have had this in mind > >>for a while. It is not necessarily obvious from all points of view. I see a reasonable > >>case to be made that an SPC label, being passed down from the management system, > >>should be in a separate object from the ERO, which may typically be calculated by the > >>source endpoint rather than passed down from the management system. > >> > >>Cheers, > >> > >>Lyndon > >> > >>-----Original Message----- > >>From: John Drake [mailto:jdrake@calient.net] > >>Sent: Friday, November 14, 2003 12:48 PM > >>To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com > >>Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org > >>Subject: RE: spc connections > >> > >> > >>Lyndon, > >> > >>This will be my last post on this topic. > >> > >>I helped write RFC3471 and RFC3473, and SPC support was always an integral part of them, as Adrian's note informed you. > >> > >>If you are referring to your original question on this topic, I think the proper response is that it should be blindingly obvious to the informed reader that the egress node doesn't have to put the explicit label for the next hop into a Label Set in the outgoing Path message, because there is no outgoing Path message. > >> > >>Thanks, > >> > >>John > >> > >> > >>------_=_NextPart_001_01C3AAF3.F61BAE90 > >>Content-Type: text/html; > >> charset="ks_c_5601-1987" > >>Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> >>charset=3Dks_c_5601-1987"> > >>[=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = > >>connections > >> > >> > >> > >>
>>color=3D#0000ff size=3D2>Hi=20 > >>John,
> >>
>>color=3D#0000ff=20 > >>size=3D2> 
> >>
>>color=3D#0000ff size=3D2>I=20 > >>apologize for being an uninformed reader :o)  As such I = > >>can only=20 > >>rely on the text in
> >>
>>color=3D#0000ff size=3D2>3473,=20 > >>which is very specific and does not discuss SPC = > >>labels.
> >>
>>color=3D#0000ff=20 > >>size=3D2> 
> >>
>>color=3D#0000ff size=3D2>It=20 > >>probably seems intuitively very obvious to you because you have had = > >>this in=20 > >>mind
> >>
>>color=3D#0000ff size=3D2>for a=20 > >>while.  It is not necessarily obvious from all points of = > >>view.  I see=20 > >>a reasonable
> >>
>>color=3D#0000ff size=3D2>case=20 > >>to be made that an SPC label, being passed down from the management=20 > >>system,
> >>
>>color=3D#0000ff size=3D2>should=20 > >>be in a separate object from the ERO, which may typically be calculated = > >>by=20 > >>the
> >>
>>color=3D#0000ff size=3D2>source=20 > >>endpoint rather than passed down from the management = > >>system.
> >>
>>color=3D#0000ff=20 > >>size=3D2> 
> >>
>>color=3D#0000ff=20 > >>size=3D2>Cheers,
> >>
>>color=3D#0000ff=20 > >>size=3D2> 
> >>
>>color=3D#0000ff=20 > >>size=3D2>Lyndon
> >>
> >>
>>face=3DTahoma=20 > >> size=3D2>-----Original Message-----
From: John Drake=20 > >> [mailto:jdrake@calient.net]
Sent: Friday, November 14, 2003 = > >>12:48=20 > >> PM
To: Ong, Lyndon; 'yhwkim@etri.re.kr';=20 > >> jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 > >> kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 > >> connections

> >>
>>color=3D#0000ff=20 > >> size=3D2>Lyndon,
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff size=3D2>This=20 > >> will be my last post on this topic.
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff size=3D2>I=20 > >> helped write RFC3471 and RFC3473, and SPC support was always an = > >>integral part=20 > >> of them, as Adrian's note informed  you.
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff size=3D2>If=20 > >> you are referring to your original question on this topic, I think = > >>the proper=20 > >> response is that it should be blindingly obvious to the informed = > >>reader=20 > >> that the egress node doesn't have to put the explicit label for the = > >>next hop=20 > >> into a Label Set in the outgoing Path message, because there is no = > >>outgoing=20 > >> Path message. 
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff=20 > >> size=3D2>Thanks,
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff=20 > >> size=3D2>John
> >> > >>------_=_NextPart_001_01C3AAF3.F61BAE90-- > >> > >> > >> > >> > > > > > > > > > > > > ----------------------------------------- > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Nov 2003 20:16:13 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AC7D.D5D484ED" Subject: RE: ASON Routing Requirements to WG doc Date: Sun, 16 Nov 2003 14:11:35 -0600 Message-ID: Thread-Topic: ASON Routing Requirements to WG doc Thread-Index: AcOsdvxRMWEza8ujTl672ZFD6CzvugABiV5g From: "Alanqar, Wesam I [NTWK SVCS]" To: "Zafar Ali" Cc: , "Kireeti Kompella" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AC7D.D5D484ED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ITU G.7715.1 will be a major input to the DT effort. G.7715.1 was co-edited by two carriers with strong involvements from different vendors. As a result, the DT output will be mainly driven by carrier requirements. =20 Thanks, -Wesam Alanqar Sprint- Technology Research and Development ITU SG15 rep to IETF CCAMP Co-editor of G.7715.1 =20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali Sent: Sunday, November 16, 2003 1:16 PM To: Kireeti Kompella; dbrungard@att.com Cc: ccamp@ops.ietf.org Subject: Re: ASON Routing Requirements to WG doc =20 Hi Kireeti,=20 Deborah made a very good point about goals of the design team during the WG meeting. Specifically, she mentioned that the DT will work closely with ITU to "understand" the requirements. I would really like to make sure that the requirements are coming from the service providers and not from specific implementations. So, I would like to see more activity from the DT in closing on the requirements in the light of the needs of service providers, before agreeing to the notion. =20 Thanks Regards... Zafar =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zafar Ali, Ph. D. 100 South Main St. #200, Technical Leader, Ann Arbor, MI 48104, USA. Cisco Systems. (734) 276-2459. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 01:06 PM 11/15/2003 -0800, Kireeti Kompella wrote: Hi, This is a call for consensus to make the document "Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON)" draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt a CCAMP WG document. This is clearly a work in progress, but I would like to know if you think that this work is going in the right direction and should be made a WG document, or you think that we should hold off. Please reply by midnight PST Nov 23, 2003. Thanks, Kireeti. ------- ------_=_NextPart_001_01C3AC7D.D5D484ED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ITU G.7715.1 will be a major input = to the DT effort. G.7715.1 was co-edited by two carriers with strong = involvements from different vendors. As a result, the DT output will be mainly driven by = carrier requirements.

 

Thanks,

=

-Wesam = Alanqar

Sprint- Technology Research and Development

ITU SG15 rep to IETF = CCAMP

Co-editor of = G.7715.1

 

-----Original = Message-----
From: = owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Zafar Ali
Sent: = Sunday, November 16, = 2003 1:16 PM
To: Kireeti Kompella; dbrungard@att.com
Cc: = ccamp@ops.ietf.org
Subject: Re: ASON Routing Requirements to WG doc

 

Hi Kireeti,

Deborah made a very good point about goals of the design team during the = WG meeting. Specifically, she mentioned that the DT will work closely with = ITU to “understand” the requirements. I would really like to make = sure that the requirements are coming from the service providers and not from specific implementations. So, I would like to see more activity from the = DT in closing on the requirements in the light of the needs of service = providers, before agreeing to the notion.   

Thanks

Regards… Zafar 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zafar Ali, Ph. D. =         &nb= sp;         &= nbsp;         = ;    100 South Main St. = #200,
Technical Leader, =         &nb= sp;         &= nbsp;         = ;    Ann Arbor, MI = 48104, USA.
Cisco = Systems.       &= nbsp;         = ;                  = ; (734) 276-2459.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
At 01:06 PM 11/15/2003 = -0800, Kireeti Kompella wrote:

Hi,

This is a call for consensus to make the document "Requirements = for
Generalized MPLS (GMPLS) Routing for Automatically Switched Optical
Network (ASON)" = draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt
a CCAMP WG document.

This is clearly a work in progress, but I would like to know if you
think that this work is going in the right direction and should be
made a WG document, or you think that we should hold off.

Please reply by midnight PST Nov 23, = 2003.

Thanks,
Kireeti.
-------

=00 ------_=_NextPart_001_01C3AC7D.D5D484ED-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Nov 2003 19:20:55 +0000 Message-Id: <4.3.2.7.2.20031116140905.00b78f00@toque.cisco.com> Date: Sun, 16 Nov 2003 14:16:16 -0500 To: Kireeti Kompella , dbrungard@att.com From: Zafar Ali Subject: Re: ASON Routing Requirements to WG doc Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9704534==_.ALT" --=====================_9704534==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Kireeti, Deborah made a very good point about goals of the design team during the WG= =20 meeting. Specifically, she mentioned that the DT will work closely with ITU= =20 to =93understand=94 the requirements. I would really like to make sure that= the=20 requirements are coming from the service providers and not from specific=20 implementations. So, I would like to see more activity from the DT in=20 closing on the requirements in the light of the needs of service providers,= =20 before agreeing to the notion. Thanks Regards=85 Zafar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zafar Ali, Ph. D. 100 South Main St. #200, Technical Leader, Ann Arbor, MI 48104, USA. Cisco Systems. (734) 276-2459. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 01:06 PM 11/15/2003 -0800, Kireeti Kompella wrote: >Hi, > >This is a call for consensus to make the document "Requirements for >Generalized MPLS (GMPLS) Routing for Automatically Switched Optical >Network (ASON)" draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt >a CCAMP WG document. > >This is clearly a work in progress, but I would like to know if you >think that this work is going in the right direction and should be >made a WG document, or you think that we should hold off. > >Please reply by midnight PST Nov 23, 2003. > >Thanks, >Kireeti. >------- --=====================_9704534==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kireeti,

Deborah made a very good point about goals of the design team during the WG meeting. Specifically, she mentioned that the DT will work closely with ITU to =93understand=94 the requirements. I would really like to make sure that the requirements are coming from the service providers and not from specific implementations. So, I would like to see more activity from the DT in closing on the requirements in the light of the needs of service providers, before agreeing to the notion.   =20

Thanks

Regards=85 Zafar 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zafar Ali, Ph. D.          =           &= nbsp;         &n= bsp;  100 South Main St. #200,
Technical Leader,          =           &= nbsp;         &n= bsp;  Ann Arbor, MI 48104, USA.
Cisco Systems.       &nbs= p;          = ;                  (734) 276-2459.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
At 01:06 PM 11/15/2003 -0800, Kireeti Kompella wrote:
Hi,

This is a call for consensus to make the document "Requirements for
Generalized MPLS (GMPLS) Routing for Automatically Switched Optical
Network (ASON)" draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt
a CCAMP WG document.

This is clearly a work in progress, but I would like to know if you
think that this work is going in the right direction and should be
made a WG document, or you think that we should hold off.

Please reply by midnight PST Nov 23, 2003.

Thanks,
Kireeti.
-------
--=====================_9704534==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 21:08:07 +0000 Date: Sat, 15 Nov 2003 13:06:55 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: ASON Routing Requirements to WG doc Message-ID: <20031115130202.X52083@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, This is a call for consensus to make the document "Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON)" draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt a CCAMP WG document. This is clearly a work in progress, but I would like to know if you think that this work is going in the right direction and should be made a WG document, or you think that we should hold off. Please reply by midnight PST Nov 23, 2003. Thanks, Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 21:03:41 +0000 Date: Sat, 15 Nov 2003 13:01:47 -0800 (PST) From: Kireeti Kompella To: betts01@nortelnetworks.com, hklam@lucent.com cc: Scott Bradner , Alex Zinin , Bill Fenner , ccamp@ops.ietf.org Subject: ITU Liaison regarding ASON Requirements Design Team Message-ID: <20031115125508.X52083@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Mr. Lam and Mr. Betts, We would like to inform Q12/15 and Q14/15 that IETF CCAMP WG has initiated a Design Team on GMPLS ASON Routing Requirements. The GMPLS ASON Routing Requirements Design Team's Charter is as follows: "To understand the requirements for ASON routing so as to capture what's missing from current CCAMP work in a "GMPLS ASON Routing Requirements" document. The ground rules are the same as for ASON signaling requirements: no requirement will be considered in this document that is not an ASON routing requirement (as decided by those working on Questions 12 and 14 of Study Group 15). Requirements should be justified briefly and prioritized. If needed, a section on terminology should be included. No attempt should be made in this document to do protocol design or suggest protocol extensions." We expect to liaison to you a draft of the above WG document during Dec. 2003. We wish to work with you cooperatively on this document and we would appreciate your assistance in reviewing this draft. Thank you, Kireeti Kompella & Adrian Farrel CCAMP WG chairs, IETF Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 20:52:54 +0000 Date: Sat, 15 Nov 2003 12:51:07 -0800 (PST) From: Kireeti Kompella To: Lou Berger cc: ccamp@ops.ietf.org Subject: Re: spc connections Message-ID: <20031115124649.V52083@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Lou, On Sat, 15 Nov 2003, Lou Berger wrote: > As I mentioned in that mail, I agree that explicitly documenting > egress label control seems like the thing to do now. I suggest that this > be done in a standalone document as it has application outside of > overlay/UNI. The text below is overly specific. First, let's make the text (procedures) more general. Then we can figure out where it goes. My preference is to keep it in this doc. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 19:37:32 +0000 Message-Id: <4.3.2.7.2.20031115143112.02289d60@mo-ex1> Date: Sat, 15 Nov 2003 14:36:04 -0500 To: "Kireeti Kompella" From: Lou Berger Subject: Re: spc connections Cc: "Ong, Lyndon" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Woops, I guess I should have read your message before sending my previous mail. Kireeti, As I mentioned in that mail, I agree that explicitly documenting egress label control seems like the thing to do now. I suggest that this be done in a standalone document as it has application outside of overlay/UNI. The text below is overly specific. Lou At 10:31 PM 11/14/2003, Kireeti Kompella wrote: >Hi Lyndon, > >On Wed, 12 Nov 2003, Ong, Lyndon wrote: > > > A couple of times now it's been suggested that Explicit Label Control > is a way to > > do SPC connections instead of the SPC_Label sub-object. I'm wondering if > > people have a different model of SPC connections in mind. The > procedures in > > RFC 3473 for Explicit Label Control are as follows: > > > > [when a label sub-object is present] If the U-bit of the > > subobject being examined is clear (0), then value of the label is > > copied into a new Label_Set object. This Label_Set object MUST be > > included on the corresponding outgoing Path message. > >Should probably have added at the end 'if any'. > >What wasn't clearly specified is the cross-connections. Here's a picture: > > U1/D1 explicit labels > .... Y ----- Z ----- associated with Z: U2/D2 > >Z is the egress; Y the egress's upstream node. Y advertises U1 to Z >in its Path, Z advertises D1 to Y in its Resv. Z also notes that the >explicit labels associated with Z in the ERO are U2 (upstream) and D2. > >Z cross-connects D1 with D2; and also cross-connects U2 with U1. It >would have been nice to be more, um, explicit about this, but we can >fix this in the overlay doc. > > > Explicit Label Control seems like it would help you control the label > assignment > > within the signaled portion of a connection. > >Not having a Path message beyond the egress core-node only means >that the signaling stops at the core-node. However, the correct >cross-connections can still be made. > >Suggested change of text for the Overlay draft: > >REPLACE: > >3.3. Explicit Label Control > > In order to support explicit label control and full identification of > the egress link an ingress edge-node may include an ERO that consists > of only the last hop. This is signaled by setting the first > subobject of the ERO to the node-ID of the egress core-node with the > L-bit set. Following this subobject are all other subobjects > necessary to identify the link and labels as they would normally > appear. > >WITH: > >3.3. Explicit Label Control > > In order to support explicit label control and full identification of > the egress link, an ingress edge-node may include an ERO whose last > group of subobjects are set as follows: > subobject identifying the egress core-node (CN3); > subobject identifying the link I downstream of CN3 (if needed); > subobject identifying the label(s) L1 and L2 on link I (if needed) > > U1/D1 I:U2/D2 > EN1 ------- CN1 ------- CN2 ------- CN3 ------- EN2 > > These may be the only subobjects in the ERO, or there may be others > preceding them. > > The subobject identifying the egress core-node MAY have the L-bit > set. If so, the egress core-node SHOULD NOT send a PathErr, despite > section 5.1.1 of RFC 3473. > > On receiving such an ERO, the egress core-node CN3 MUST cross-connect > the downstream label D1 that it sends to its upstream node CN2 with > the downstream explicit label D2 associated with CN3 in the ERO. If > the LSP is bidirectional, CN3 MUST also cross-connect the upstream > label U2 in the ERO with the upstream label U1 it received from CN2. > > If either of these cross-connections fails, the egress core-node > SHOULD send a PathErr with . > >END > >Kireeti. >------- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 19:33:15 +0000 Message-Id: <4.3.2.7.2.20031115141823.03f79678@mo-ex1> Date: Sat, 15 Nov 2003 14:29:56 -0500 To: "Ong, Lyndon" From: Lou Berger Subject: RE: spc connections Cc: "Dimitri Papadimitriou" , , , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Lyndon, See below: At 08:06 PM 11/14/2003, Ong, Lyndon wrote: >Hi Dimitri, > >"There is no change in protocol to enable this function, >merely a description of how it all works." >Hmm, well I did not see anywhere in the protocol spec >something that states how this works at the present time. >If you are saying the ERO processing can be extended to do this, >yes, but from the previous messages a separate object >seems like a good approach, plus it would be consistent >with G.7713.2. > >Sorry if we're monopolizing the list on this issue... > >Cheers, > >Lyndon The intent is clear in 3471: >Berger Standards Track [Page 20] > >RFC 3471 GMPLS Signaling Functional Description > > > label used on a link. Specifically, the problem is that ERO and ER- > Hop do not support explicit label sub-objects. An example case where > such a mechanism is desirable is where there are two LSPs to be > "spliced" together, i.e., where the tail of the first LSP would be > "spliced" into the head of the second LSP. This last case is more > likely to be used in the non-PSC classes of links. We, the authors of 3471, and 3473 thought there was enough in the text to understand how to make "SPC" work. I accept that some have trouble accepting the intent and need the procedures for support spelled out. I have no issue with writing an informational draft that explicitly states the RSVP-TE procedure for using ERO to provide SPC support. The procedure should be less than one page and have zero (0) protocol changes. I think this should cover the issue. Lou Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 04:27:56 +0000 Date: Fri, 14 Nov 2003 20:27:00 -0800 (PST) From: Kireeti Kompella To: "Ong, Lyndon" cc: ccamp@ops.ietf.org Subject: RE: spc connections Message-ID: <20031114200414.H46555@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Lyndon, On Fri, 14 Nov 2003, Ong, Lyndon wrote: > Actually the extensions in the GMPLS Overlay draft would not > be sufficient. Overlay deals again with signaled interfaces > rather than SPC. You make a good point. A minor inaccuracy is that the signaling can be sent across the 'ingress UNI' without having signaling across the 'egress UNI' (if you'll forgive my abuse of terminology). How about the following further clarification: REPLACE: 3.3. Explicit Label Control In order to support explicit label control and full identification of the egress link, an ingress edge-node may include an ERO whose last group of subobjects are set as follows: WITH: 3.3. Explicit Label Control Four signaling modes to establish a connection from the ingress edge-node to the egress edge-node are described here. The first is a Switched Connection (SC), where the ingress edge-node signals all the way to the egress edge-node. The second is a Soft Permanent Connection (SPC) where the ingress core-node signals to the egress core-node. The third is a hybrid signaling mode where an ingress edge-node signals to the egress core-node. The final mode is when an ingress core-node signals to the egress edge-node; this uses the same procedures as SCs, and will not be further elaborated. In order to support modes two and three, the ingress signaling node (ingress core-node for mode 2 and ingress edge-node for mode 3) must identify the egress link, i.e., the link between the egress core-node and the egress edge-node. This is done using explicit label control. An ingress signaling node may include an ERO whose last group of subobjects are set as follows: (etc.) END Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 04:02:59 +0000 Date: Fri, 14 Nov 2003 20:02:29 -0800 (PST) From: Kireeti Kompella To: "Ong, Lyndon" cc: ccamp@ops.ietf.org Subject: Re: spc connections Message-ID: <20031114195620.A46555@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Lyndon, On Fri, 14 Nov 2003, Ong, Lyndon wrote: > I support your conclusion. With this approach it is also unnecessary to modify the > procedures defined in RFC 3473 for Explicit Label Control, which make sense in their > original use. It is important to update the processing of Explicit Label Control, either to say that a label subobject in the ERO MUST NOT be added to the egress node, or to say how it's processed in that case. Also, while not strictly necessary, it is useful to say how cross-connections are made with ERO labels, as there seems to be confusion here. The GMPLS Overlay doc seems a good vehicle for this. I would strongly recommend the authors to note in the header that this document updates RFC 3473. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 03:53:40 +0000 Date: Fri, 14 Nov 2003 19:53:06 -0800 (PST) From: Kireeti Kompella To: yhwkim@etri.re.kr cc: ccamp@ops.ietf.org Subject: Re: spc connections Message-ID: <20031114194720.D46555@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Young-Hwa, On Thu, 13 Nov 2003 yhwkim@etri.re.kr wrote: > In my understanding, for the support of SPC connection, SPC_LABEL (Type=4, > Sub-type=2) > subobject seems to be included in GENERALIZED_UNI object. > If my understanding is correct, I think there is a big ifference between > concept of SPC connection and GENERALIZED_UNI object. SPC connection is NNI > portion, not UNI. Agreed. > As it is, GENERALIZED_UNI object describes originating and terminating UNI > aspects between client and network nodes. > From logical view-point, in addition, the difference between switched > connection (SC) and soft permanent connection (SPC) is where call and > connection initiation is. In case of SC the initiation is of client node, > but in case of SPC the initiation is of network node (of course, triggered > by NMS). That's my understanding. > As a result, I think that GENERALIZED_UNI object and SPC > connection could not be indicated by using the object, called > GENERALIZED_UNI object because these are completely different by nature. > What do you think of my opinion? Again, I agree with you. The answer has been given that the perhaps poorly named GENERALIZED_UNI object was being reused. However, I would rather reuse the Explicit Label Control defined in 3473 than an object defined in an Informational RFC. Kireeti. ------- PS: Sorry for answering questions in this thread in a rather random order. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 03:45:56 +0000 Date: Fri, 14 Nov 2003 19:45:21 -0800 (PST) From: Kireeti Kompella To: "Ong, Lyndon" cc: ccamp@ops.ietf.org Subject: RE: spc connections Message-ID: <20031114193352.O46555@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Lyndon, On Fri, 14 Nov 2003, Ong, Lyndon wrote: > "There is no change in protocol to enable this function, > merely a description of how it all works." > > > Hmm, well I did not see anywhere in the protocol spec > something that states how this works at the present time. > If you are saying the ERO processing can be extended to do this, > yes, You are right insofar as 3473 is concerned; however, see my previous mail. It would be great to get your feedback on issues you find. > but from the previous messages a separate object > seems like a good approach, plus it would be consistent > with G.7713.2. Being consistent with G.7713.2 isn't at the top of my list until the many issues with 7713.2 are cleared up. Being consistent with 3473 is at the very top of my list. Reusing objects defined in 3473 (which is an IETF Standards Track document), and more fully explaining their processing where needed is exactly what CCAMP should be doing. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 03:33:52 +0000 Date: Fri, 14 Nov 2003 19:31:49 -0800 (PST) From: Kireeti Kompella To: "Ong, Lyndon" cc: ccamp@ops.ietf.org Subject: Re: spc connections Message-ID: <20031114180421.F46555@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Lyndon, On Wed, 12 Nov 2003, Ong, Lyndon wrote: > A couple of times now it's been suggested that Explicit Label Control is a way to > do SPC connections instead of the SPC_Label sub-object. I'm wondering if > people have a different model of SPC connections in mind. The procedures in > RFC 3473 for Explicit Label Control are as follows: > > [when a label sub-object is present] If the U-bit of the > subobject being examined is clear (0), then value of the label is > copied into a new Label_Set object. This Label_Set object MUST be > included on the corresponding outgoing Path message. Should probably have added at the end 'if any'. What wasn't clearly specified is the cross-connections. Here's a picture: U1/D1 explicit labels .... Y ----- Z ----- associated with Z: U2/D2 Z is the egress; Y the egress's upstream node. Y advertises U1 to Z in its Path, Z advertises D1 to Y in its Resv. Z also notes that the explicit labels associated with Z in the ERO are U2 (upstream) and D2. Z cross-connects D1 with D2; and also cross-connects U2 with U1. It would have been nice to be more, um, explicit about this, but we can fix this in the overlay doc. > Explicit Label Control seems like it would help you control the label assignment > within the signaled portion of a connection. Not having a Path message beyond the egress core-node only means that the signaling stops at the core-node. However, the correct cross-connections can still be made. Suggested change of text for the Overlay draft: REPLACE: 3.3. Explicit Label Control In order to support explicit label control and full identification of the egress link an ingress edge-node may include an ERO that consists of only the last hop. This is signaled by setting the first subobject of the ERO to the node-ID of the egress core-node with the L-bit set. Following this subobject are all other subobjects necessary to identify the link and labels as they would normally appear. WITH: 3.3. Explicit Label Control In order to support explicit label control and full identification of the egress link, an ingress edge-node may include an ERO whose last group of subobjects are set as follows: subobject identifying the egress core-node (CN3); subobject identifying the link I downstream of CN3 (if needed); subobject identifying the label(s) L1 and L2 on link I (if needed) U1/D1 I:U2/D2 EN1 ------- CN1 ------- CN2 ------- CN3 ------- EN2 These may be the only subobjects in the ERO, or there may be others preceding them. The subobject identifying the egress core-node MAY have the L-bit set. If so, the egress core-node SHOULD NOT send a PathErr, despite section 5.1.1 of RFC 3473. On receiving such an ERO, the egress core-node CN3 MUST cross-connect the downstream label D1 that it sends to its upstream node CN2 with the downstream explicit label D2 associated with CN3 in the ERO. If the LSP is bidirectional, CN3 MUST also cross-connect the upstream label U2 in the ERO with the upstream label U1 it received from CN2. If either of these cross-connections fails, the egress core-node SHOULD send a PathErr with . END Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Nov 2003 01:08:43 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61F4@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Dimitri Papadimitriou' , ben.mack-crane@tellabs.com Cc: jdrake@calient.net, yhwkim@etri.re.kr, Jonathan.Sadler@tellabs.com, adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: spc connections Date: Fri, 14 Nov 2003 17:06:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Dimitri, "There is no change in protocol to enable this function, merely a description of how it all works." Hmm, well I did not see anywhere in the protocol spec something that states how this works at the present time. If you are saying the ERO processing can be extended to do this, yes, but from the previous messages a separate object seems like a good approach, plus it would be consistent with G.7713.2. Sorry if we're monopolizing the list on this issue... Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 23:24:41 +0000 Subject: Re: spc connections To: ben.mack-crane@tellabs.com (Ben Mack-Crane) Date: Fri, 14 Nov 2003 23:23:03 +0000 (GMT) Cc: LyOng@Ciena.com (Ong Lyndon), jdrake@calient.net ('John Drake'), yhwkim@etri.re.kr ('yhwkim@etri.re.kr'), Jonathan.Sadler@tellabs.com, adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou ben, your response is confusing what you say is that the operator at the as boundary can accept a call that specifies accessing a specific end-point but does not accept the connection request associated to this call - does this make any sense ? more fundamentally, i don't see where the delivery of call functionality for spc's does have to imply some implementation specific restrictions to fulfil this functional requirement ? when you point out here that the "ERO may be disregarded" it becomes a protocol requirement not a functional requirement and afaik G.8080 does have nothing to do with any implementation specifics now concerning the source of information, you're mismatching what lyndon said "passing information from the management to the control plane" with the control plane exchange of information between call/connection controllers the conclusion, as also drawn by several people on this list seem clear: "There is no change in protocol to enable this function, merely a description of how it all works." something that will be addressed in order to avoid spreading of misunderstanding thanks, - dimitri. > Dimitri, > > The reason that the SPC Label (or Egress Label) should be in a separate > object from the ERO > is that the ERO may be ignored. > > This is not unrelated to the source of the information, in that the ERO > is provided by some > network control or administrative entity while the call endpoint > identificaiton is provided by the entity > requesting the service. In fulfilling a service request, a service > provider may disregard the ERO > but may not disregard the service request. Thus it makes perfect sense > to keep these pieces > of information in separate objects. > > Regards, > Ben > > Dimitri Papadimitriou wrote: > > >lyndon, the fact that you may receive the "information" from an nms/ems, > >manually configured, or any other means does not have to impact the > >external behaviour of the protocol - what you suggest is the use of a > >mechanism that would depend on the originator of the "information" - > > > >while rfc 3473 specifies in section 5.1.1: > >"Procedures by which an LSR at the head-end of an LSP obtains the > > information needed to construct the Label subobject are outside the > > scope of this document." > > > >the only thing that needs to be specified for this subobject is the > >placement and ordering in the ERO (as specified in the same section) > > > >in addition - and as far as my understanding goes - there are no > >functional requirements mandating - this should be somewhat obvious - > >the implementation specific mechanism you describe here below > > > >hope this will help you to understand what we're trying to explain > >you since last monday (john, adrian, etc. via private and public > >e-mails) > > > >thanks, > >- dimitri. > > > > > > > >>This message is in MIME format. Since your mail reader does not understand > >>this format, some or all of this message may not be legible. > >> > >>------_=_NextPart_001_01C3AAF3.F61BAE90 > >>Content-Type: text/plain; > >> charset="ks_c_5601-1987" > >> > >>Hi John, > >> > >>I apologize for being an uninformed reader :o) As such I can only rely on the text in > >>3473, which is very specific and does not discuss SPC labels. > >> > >>It probably seems intuitively very obvious to you because you have had this in mind > >>for a while. It is not necessarily obvious from all points of view. I see a reasonable > >>case to be made that an SPC label, being passed down from the management system, > >>should be in a separate object from the ERO, which may typically be calculated by the > >>source endpoint rather than passed down from the management system. > >> > >>Cheers, > >> > >>Lyndon > >> > >>-----Original Message----- > >>From: John Drake [mailto:jdrake@calient.net] > >>Sent: Friday, November 14, 2003 12:48 PM > >>To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com > >>Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org > >>Subject: RE: spc connections > >> > >> > >>Lyndon, > >> > >>This will be my last post on this topic. > >> > >>I helped write RFC3471 and RFC3473, and SPC support was always an integral part of them, as Adrian's note informed you. > >> > >>If you are referring to your original question on this topic, I think the proper response is that it should be blindingly obvious to the informed reader that the egress node doesn't have to put the explicit label for the next hop into a Label Set in the outgoing Path message, because there is no outgoing Path message. > >> > >>Thanks, > >> > >>John > >> > >> > >>------_=_NextPart_001_01C3AAF3.F61BAE90 > >>Content-Type: text/html; > >> charset="ks_c_5601-1987" > >>Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >> >>charset=3Dks_c_5601-1987"> > >>[=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = > >>connections > >> > >> > >> > >>
>>color=3D#0000ff size=3D2>Hi=20 > >>John,
> >>
>>color=3D#0000ff=20 > >>size=3D2> 
> >>
>>color=3D#0000ff size=3D2>I=20 > >>apologize for being an uninformed reader :o)  As such I = > >>can only=20 > >>rely on the text in
> >>
>>color=3D#0000ff size=3D2>3473,=20 > >>which is very specific and does not discuss SPC = > >>labels.
> >>
>>color=3D#0000ff=20 > >>size=3D2> 
> >>
>>color=3D#0000ff size=3D2>It=20 > >>probably seems intuitively very obvious to you because you have had = > >>this in=20 > >>mind
> >>
>>color=3D#0000ff size=3D2>for a=20 > >>while.  It is not necessarily obvious from all points of = > >>view.  I see=20 > >>a reasonable
> >>
>>color=3D#0000ff size=3D2>case=20 > >>to be made that an SPC label, being passed down from the management=20 > >>system,
> >>
>>color=3D#0000ff size=3D2>should=20 > >>be in a separate object from the ERO, which may typically be calculated = > >>by=20 > >>the
> >>
>>color=3D#0000ff size=3D2>source=20 > >>endpoint rather than passed down from the management = > >>system.
> >>
>>color=3D#0000ff=20 > >>size=3D2> 
> >>
>>color=3D#0000ff=20 > >>size=3D2>Cheers,
> >>
>>color=3D#0000ff=20 > >>size=3D2> 
> >>
>>color=3D#0000ff=20 > >>size=3D2>Lyndon
> >>
> >>
>>face=3DTahoma=20 > >> size=3D2>-----Original Message-----
From: John Drake=20 > >> [mailto:jdrake@calient.net]
Sent: Friday, November 14, 2003 = > >>12:48=20 > >> PM
To: Ong, Lyndon; 'yhwkim@etri.re.kr';=20 > >> jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 > >> kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 > >> connections

> >>
>>color=3D#0000ff=20 > >> size=3D2>Lyndon,
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff size=3D2>This=20 > >> will be my last post on this topic.
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff size=3D2>I=20 > >> helped write RFC3471 and RFC3473, and SPC support was always an = > >>integral part=20 > >> of them, as Adrian's note informed  you.
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff size=3D2>If=20 > >> you are referring to your original question on this topic, I think = > >>the proper=20 > >> response is that it should be blindingly obvious to the informed = > >>reader=20 > >> that the egress node doesn't have to put the explicit label for the = > >>next hop=20 > >> into a Label Set in the outgoing Path message, because there is no = > >>outgoing=20 > >> Path message. 
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff=20 > >> size=3D2>Thanks,
> >>
>>color=3D#0000ff=20 > >> size=3D2> 
> >>
>>color=3D#0000ff=20 > >> size=3D2>John
> >> > >>------_=_NextPart_001_01C3AAF3.F61BAE90-- > >> > >> > >> > >> > > > > > > > > > > > > ----------------------------------------- > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 22:34:59 +0000 Message-ID: <3FB557CC.9000404@tellabs.com> Date: Fri, 14 Nov 2003 16:31:40 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Dimitri Papadimitriou CC: "Ong, Lyndon" , "'John Drake'" , "'yhwkim@etri.re.kr'" , Jonathan.Sadler@tellabs.com, adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: spc connections Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" Dimitri, The reason that the SPC Label (or Egress Label) should be in a separate object from the ERO is that the ERO may be ignored. This is not unrelated to the source of the information, in that the ERO is provided by some network control or administrative entity while the call endpoint identificaiton is provided by the entity requesting the service. In fulfilling a service request, a service provider may disregard the ERO but may not disregard the service request. Thus it makes perfect sense to keep these pieces of information in separate objects. Regards, Ben Dimitri Papadimitriou wrote: >lyndon, the fact that you may receive the "information" from an nms/ems, >manually configured, or any other means does not have to impact the >external behaviour of the protocol - what you suggest is the use of a >mechanism that would depend on the originator of the "information" - > >while rfc 3473 specifies in section 5.1.1: >"Procedures by which an LSR at the head-end of an LSP obtains the > information needed to construct the Label subobject are outside the > scope of this document." > >the only thing that needs to be specified for this subobject is the >placement and ordering in the ERO (as specified in the same section) > >in addition - and as far as my understanding goes - there are no >functional requirements mandating - this should be somewhat obvious - >the implementation specific mechanism you describe here below > >hope this will help you to understand what we're trying to explain >you since last monday (john, adrian, etc. via private and public >e-mails) > >thanks, >- dimitri. > > > >>This message is in MIME format. Since your mail reader does not understand >>this format, some or all of this message may not be legible. >> >>------_=_NextPart_001_01C3AAF3.F61BAE90 >>Content-Type: text/plain; >> charset="ks_c_5601-1987" >> >>Hi John, >> >>I apologize for being an uninformed reader :o) As such I can only rely on the text in >>3473, which is very specific and does not discuss SPC labels. >> >>It probably seems intuitively very obvious to you because you have had this in mind >>for a while. It is not necessarily obvious from all points of view. I see a reasonable >>case to be made that an SPC label, being passed down from the management system, >>should be in a separate object from the ERO, which may typically be calculated by the >>source endpoint rather than passed down from the management system. >> >>Cheers, >> >>Lyndon >> >>-----Original Message----- >>From: John Drake [mailto:jdrake@calient.net] >>Sent: Friday, November 14, 2003 12:48 PM >>To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com >>Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org >>Subject: RE: spc connections >> >> >>Lyndon, >> >>This will be my last post on this topic. >> >>I helped write RFC3471 and RFC3473, and SPC support was always an integral part of them, as Adrian's note informed you. >> >>If you are referring to your original question on this topic, I think the proper response is that it should be blindingly obvious to the informed reader that the egress node doesn't have to put the explicit label for the next hop into a Label Set in the outgoing Path message, because there is no outgoing Path message. >> >>Thanks, >> >>John >> >> >>------_=_NextPart_001_01C3AAF3.F61BAE90 >>Content-Type: text/html; >> charset="ks_c_5601-1987" >>Content-Transfer-Encoding: quoted-printable >> >> >> >>>charset=3Dks_c_5601-1987"> >>[=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = >>connections >> >> >> >>
>color=3D#0000ff size=3D2>Hi=20 >>John,
>>
>color=3D#0000ff=20 >>size=3D2> 
>>
>color=3D#0000ff size=3D2>I=20 >>apologize for being an uninformed reader :o)  As such I = >>can only=20 >>rely on the text in
>>
>color=3D#0000ff size=3D2>3473,=20 >>which is very specific and does not discuss SPC = >>labels.
>>
>color=3D#0000ff=20 >>size=3D2> 
>>
>color=3D#0000ff size=3D2>It=20 >>probably seems intuitively very obvious to you because you have had = >>this in=20 >>mind
>>
>color=3D#0000ff size=3D2>for a=20 >>while.  It is not necessarily obvious from all points of = >>view.  I see=20 >>a reasonable
>>
>color=3D#0000ff size=3D2>case=20 >>to be made that an SPC label, being passed down from the management=20 >>system,
>>
>color=3D#0000ff size=3D2>should=20 >>be in a separate object from the ERO, which may typically be calculated = >>by=20 >>the
>>
>color=3D#0000ff size=3D2>source=20 >>endpoint rather than passed down from the management = >>system.
>>
>color=3D#0000ff=20 >>size=3D2> 
>>
>color=3D#0000ff=20 >>size=3D2>Cheers,
>>
>color=3D#0000ff=20 >>size=3D2> 
>>
>color=3D#0000ff=20 >>size=3D2>Lyndon
>>
>>
>face=3DTahoma=20 >> size=3D2>-----Original Message-----
From: John Drake=20 >> [mailto:jdrake@calient.net]
Sent: Friday, November 14, 2003 = >>12:48=20 >> PM
To: Ong, Lyndon; 'yhwkim@etri.re.kr';=20 >> jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 >> kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 >> connections

>>
>color=3D#0000ff=20 >> size=3D2>Lyndon,
>>
>color=3D#0000ff=20 >> size=3D2> 
>>
>color=3D#0000ff size=3D2>This=20 >> will be my last post on this topic.
>>
>color=3D#0000ff=20 >> size=3D2> 
>>
>color=3D#0000ff size=3D2>I=20 >> helped write RFC3471 and RFC3473, and SPC support was always an = >>integral part=20 >> of them, as Adrian's note informed  you.
>>
>color=3D#0000ff=20 >> size=3D2> 
>>
>color=3D#0000ff size=3D2>If=20 >> you are referring to your original question on this topic, I think = >>the proper=20 >> response is that it should be blindingly obvious to the informed = >>reader=20 >> that the egress node doesn't have to put the explicit label for the = >>next hop=20 >> into a Label Set in the outgoing Path message, because there is no = >>outgoing=20 >> Path message. 
>>
>color=3D#0000ff=20 >> size=3D2> 
>>
>color=3D#0000ff=20 >> size=3D2>Thanks,
>>
>color=3D#0000ff=20 >> size=3D2> 
>>
>color=3D#0000ff=20 >> size=3D2>John
>> >>------_=_NextPart_001_01C3AAF3.F61BAE90-- >> >> >> >> > > > > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 21:50:41 +0000 Subject: Re: spc connections To: LyOng@Ciena.com (Ong, Lyndon) Date: Fri, 14 Nov 2003 21:49:26 +0000 (GMT) Cc: jdrake@calient.net ('John Drake'), yhwkim@etri.re.kr ('yhwkim@etri.re.kr'), jonathan.sadler@tellabs.com, adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou lyndon, the fact that you may receive the "information" from an nms/ems, manually configured, or any other means does not have to impact the external behaviour of the protocol - what you suggest is the use of a mechanism that would depend on the originator of the "information" - while rfc 3473 specifies in section 5.1.1: "Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label subobject are outside the scope of this document." the only thing that needs to be specified for this subobject is the placement and ordering in the ERO (as specified in the same section) in addition - and as far as my understanding goes - there are no functional requirements mandating - this should be somewhat obvious - the implementation specific mechanism you describe here below hope this will help you to understand what we're trying to explain you since last monday (john, adrian, etc. via private and public e-mails) thanks, - dimitri. > > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C3AAF3.F61BAE90 > Content-Type: text/plain; > charset="ks_c_5601-1987" > > Hi John, > > I apologize for being an uninformed reader :o) As such I can only rely on the text in > 3473, which is very specific and does not discuss SPC labels. > > It probably seems intuitively very obvious to you because you have had this in mind > for a while. It is not necessarily obvious from all points of view. I see a reasonable > case to be made that an SPC label, being passed down from the management system, > should be in a separate object from the ERO, which may typically be calculated by the > source endpoint rather than passed down from the management system. > > Cheers, > > Lyndon > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Friday, November 14, 2003 12:48 PM > To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com > Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org > Subject: RE: spc connections > > > Lyndon, > > This will be my last post on this topic. > > I helped write RFC3471 and RFC3473, and SPC support was always an integral part of them, as Adrian's note informed you. > > If you are referring to your original question on this topic, I think the proper response is that it should be blindingly obvious to the informed reader that the egress node doesn't have to put the explicit label for the next hop into a Label Set in the outgoing Path message, because there is no outgoing Path message. > > Thanks, > > John > > > ------_=_NextPart_001_01C3AAF3.F61BAE90 > Content-Type: text/html; > charset="ks_c_5601-1987" > Content-Transfer-Encoding: quoted-printable > > > > charset=3Dks_c_5601-1987"> > [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = > connections > > > >
color=3D#0000ff size=3D2>Hi=20 > John,
>
color=3D#0000ff=20 > size=3D2> 
>
color=3D#0000ff size=3D2>I=20 > apologize for being an uninformed reader :o)  As such I = > can only=20 > rely on the text in
>
color=3D#0000ff size=3D2>3473,=20 > which is very specific and does not discuss SPC = > labels.
>
color=3D#0000ff=20 > size=3D2> 
>
color=3D#0000ff size=3D2>It=20 > probably seems intuitively very obvious to you because you have had = > this in=20 > mind
>
color=3D#0000ff size=3D2>for a=20 > while.  It is not necessarily obvious from all points of = > view.  I see=20 > a reasonable
>
color=3D#0000ff size=3D2>case=20 > to be made that an SPC label, being passed down from the management=20 > system,
>
color=3D#0000ff size=3D2>should=20 > be in a separate object from the ERO, which may typically be calculated = > by=20 > the
>
color=3D#0000ff size=3D2>source=20 > endpoint rather than passed down from the management = > system.
>
color=3D#0000ff=20 > size=3D2> 
>
color=3D#0000ff=20 > size=3D2>Cheers,
>
color=3D#0000ff=20 > size=3D2> 
>
color=3D#0000ff=20 > size=3D2>Lyndon
>
>
face=3DTahoma=20 > size=3D2>-----Original Message-----
From: John Drake=20 > [mailto:jdrake@calient.net]
Sent: Friday, November 14, 2003 = > 12:48=20 > PM
To: Ong, Lyndon; 'yhwkim@etri.re.kr';=20 > jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 > kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 > connections

>
color=3D#0000ff=20 > size=3D2>Lyndon,
>
color=3D#0000ff=20 > size=3D2> 
>
color=3D#0000ff size=3D2>This=20 > will be my last post on this topic.
>
color=3D#0000ff=20 > size=3D2> 
>
color=3D#0000ff size=3D2>I=20 > helped write RFC3471 and RFC3473, and SPC support was always an = > integral part=20 > of them, as Adrian's note informed  you.
>
color=3D#0000ff=20 > size=3D2> 
>
color=3D#0000ff size=3D2>If=20 > you are referring to your original question on this topic, I think = > the proper=20 > response is that it should be blindingly obvious to the informed = > reader=20 > that the egress node doesn't have to put the explicit label for the = > next hop=20 > into a Label Set in the outgoing Path message, because there is no = > outgoing=20 > Path message. 
>
color=3D#0000ff=20 > size=3D2> 
>
color=3D#0000ff=20 > size=3D2>Thanks,
>
color=3D#0000ff=20 > size=3D2> 
>
color=3D#0000ff=20 > size=3D2>John
> > ------_=_NextPart_001_01C3AAF3.F61BAE90-- > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 21:12:48 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61EB@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'John Drake' , "'yhwkim@etri.re.kr'" , jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: spc connections Date: Fri, 14 Nov 2003 13:12:07 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AAF3.F61BAE90" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AAF3.F61BAE90 Content-Type: text/plain; charset="ks_c_5601-1987" Hi John, I apologize for being an uninformed reader :o) As such I can only rely on the text in 3473, which is very specific and does not discuss SPC labels. It probably seems intuitively very obvious to you because you have had this in mind for a while. It is not necessarily obvious from all points of view. I see a reasonable case to be made that an SPC label, being passed down from the management system, should be in a separate object from the ERO, which may typically be calculated by the source endpoint rather than passed down from the management system. Cheers, Lyndon -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Friday, November 14, 2003 12:48 PM To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: RE: spc connections Lyndon, This will be my last post on this topic. I helped write RFC3471 and RFC3473, and SPC support was always an integral part of them, as Adrian's note informed you. If you are referring to your original question on this topic, I think the proper response is that it should be blindingly obvious to the informed reader that the egress node doesn't have to put the explicit label for the next hop into a Label Set in the outgoing Path message, because there is no outgoing Path message. Thanks, John ------_=_NextPart_001_01C3AAF3.F61BAE90 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections
Hi=20 John,
 
I=20 apologize for being an uninformed reader :o)  As such I = can only=20 rely on the text in
3473,=20 which is very specific and does not discuss SPC = labels.
 
It=20 probably seems intuitively very obvious to you because you have had = this in=20 mind
for a=20 while.  It is not necessarily obvious from all points of = view.  I see=20 a reasonable
case=20 to be made that an SPC label, being passed down from the management=20 system,
should=20 be in a separate object from the ERO, which may typically be calculated = by=20 the
source=20 endpoint rather than passed down from the management = system.
 
Cheers,
 
Lyndon
-----Original Message-----
From: John Drake=20 [mailto:jdrake@calient.net]
Sent: Friday, November 14, 2003 = 12:48=20 PM
To: Ong, Lyndon; 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 connections

Lyndon,
 
This=20 will be my last post on this topic.
 
I=20 helped write RFC3471 and RFC3473, and SPC support was always an = integral part=20 of them, as Adrian's note informed  you.
 
If=20 you are referring to your original question on this topic, I think = the proper=20 response is that it should be blindingly obvious to the informed = reader=20 that the egress node doesn't have to put the explicit label for the = next hop=20 into a Label Set in the outgoing Path message, because there is no = outgoing=20 Path message. 
 
Thanks,
 
John
------_=_NextPart_001_01C3AAF3.F61BAE90-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 20:49:14 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048D8E@nimbus.chromisys.com> From: John Drake To: "'Ong, Lyndon'" , "'yhwkim@etri.re.kr'" , jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: spc connections Date: Fri, 14 Nov 2003 12:47:50 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AAF0.91352CC0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AAF0.91352CC0 Content-Type: text/plain; charset="KS_C_5601-1987" Lyndon, This will be my last post on this topic. I helped write RFC3471 and RFC3473, and SPC support was always an integral part of them, as Adrian's note informed you. If you are referring to your original question on this topic, I think the proper response is that it should be blindingly obvious to the informed reader that the egress node doesn't have to put the explicit label for the next hop into a Label Set in the outgoing Path message, because there is no outgoing Path message. Thanks, John -----Original Message----- From: Ong, Lyndon [mailto:LyOng@Ciena.com] Sent: Friday, November 14, 2003 12:01 PM To: John Drake; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: RE: spc connections -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Friday, November 14, 2003 11:45 AM To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: RE: spc connections Overlay deals again with signaled interfaces rather than SPC. JD: What possible difference does that make? Read the procedures in 3473... ------_=_NextPart_001_01C3AAF0.91352CC0 Content-Type: text/html; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections
Lyndon,
 
This=20 will be my last post on this topic.
 
I=20 helped write RFC3471 and RFC3473, and SPC support was always an = integral part of=20 them, as Adrian's note informed  you.
 
If you=20 are referring to your original question on this topic, I think the = proper=20 response is that it should be blindingly obvious to the informed = reader=20 that the egress node doesn't have to put the explicit label for the = next hop=20 into a Label Set in the outgoing Path message, because there is no = outgoing Path=20 message. 
 
Thanks,
 
John
-----Original Message-----
From: Ong, Lyndon=20 [mailto:LyOng@Ciena.com]
Sent: Friday, November 14, 2003 = 12:01=20 PM
To: John Drake; 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 connections

 
-----Original Message-----
From: John Drake=20 [mailto:jdrake@calient.net]
Sent: Friday, November 14, = 2003 11:45=20 AM
To: Ong, Lyndon; 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 connections
 
Overlay deals again with signaled = interfaces
rather than SPC. 
 
JD:  What=20 possible difference does that=20 = make? 
 
Read the=20 procedures in = 3473...
------_=_NextPart_001_01C3AAF0.91352CC0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 20:01:51 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61E8@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'John Drake' , "'yhwkim@etri.re.kr'" , jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: spc connections Date: Fri, 14 Nov 2003 12:00:53 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AAEA.029D7A90" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AAEA.029D7A90 Content-Type: text/plain; charset="ks_c_5601-1987" -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Friday, November 14, 2003 11:45 AM To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: RE: spc connections Overlay deals again with signaled interfaces rather than SPC. JD: What possible difference does that make? Read the procedures in 3473... ------_=_NextPart_001_01C3AAEA.029D7A90 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections
 
-----Original Message-----
From: John Drake=20 [mailto:jdrake@calient.net]
Sent: Friday, November 14, 2003 = 11:45=20 AM
To: Ong, Lyndon; 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 connections
 
Overlay deals again with signaled = interfaces
rather than SPC. 
 
JD:  What=20 possible difference does that=20 = make? 
 
Read the=20 procedures in 3473...
------_=_NextPart_001_01C3AAEA.029D7A90-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 19:47:18 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048D8D@nimbus.chromisys.com> From: John Drake To: "'Ong, Lyndon'" , "'yhwkim@etri.re.kr'" , jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: spc connections Date: Fri, 14 Nov 2003 11:45:03 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AAE7.CBE62210" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AAE7.CBE62210 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Ong, Lyndon [mailto:LyOng@Ciena.com] Sent: Friday, November 14, 2003 10:42 AM To: John Drake; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: RE: spc connections Hi John, =20 Actually the extensions in the GMPLS Overlay draft would not be sufficient.=20 =20 JD: Per Adrian's note, there are no extensions. =20 Overlay deals again with signaled interfaces rather than SPC.=20 =20 JD: What possible difference does that make?=20 =20 Cheers, =20 Lyndon -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Friday, November 14, 2003 10:36 AM To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: RE: spc connections Lyndon, =20 You weren't paying attention to Adrian's e-mail, below: =20 Lyndon, Thank you for raising this. There is certainly a lack of clarity in = 3473 in this regard, which is perhaps unfortunate. In the earlier versions of the GMPLS work, this was made very explicit (sic) because egress label control was invented before it was generalized to explicit label. There is some reference to this in RFC3471 (of course, the function was originally independent of signaling protocol), but no explicit procedures. This descriptive deficiency has been addressed in draft-ccamp-gmpls- overlay. There is no change in protocol to enable this function, merely a description of how = it all works. Hope this helps. Cheers, Adrian -----Original Message----- From: Ong, Lyndon [mailto:LyOng@Ciena.com] Sent: Friday, November 14, 2003 10:16 AM To: 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: Re: spc connections Hi Young, =20 I support your conclusion. With this approach it is also unnecessary = to modify the procedures defined in RFC 3473 for Explicit Label Control, which make = sense in their original use. =20 Regarding RFC 3476, this was submitted by Bala Rajagopalan, who chairs = the Signaling Working Group of OIF, and was needed for agreement with IETF/IANA on codepoint assignments in RSVP and LDP for the OIF UNI interface. The signaling defined in = the OIF UNI is basically a subset of G.7713.2 and G.7713.3 for the UNI, although the = ITU-T specifications were completed later. =20 Cheers, =20 Lyndon -----Original Message----- From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr] Sent: Friday, November 14, 2003 7:18 AM To: jonathan.sadler@tellabs.com; yhwkim@etri.re.kr Cc: adrian@olddog.co.uk; Ong, Lyndon; kireeti@juniper.net; ccamp@ops.ietf.org Subject: [????] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc connections Hi,=20 I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the definition of SPC_Label.=20 The following description shows the definition of the SPC_Label.=20 "This attribute represents the SNP used at the destination = network-to-user connection. The SPC SNP ID is locally unique to the destination end and provided to the control plane by an external agent (e.g., the = management system that initiated the SPC connection request). Note that in the = case of the SPC connection, both source and destination user-to-network = connections are provisioned. As such, when setting up a network switched connection = to support the SPC service, the destination SNP associated with the provisioned connection needs to be specified to allow the control plane = to connect the switched connection to the destination portion of the provisioned connection." After reading this clause, I bacame to understand the reason that "Generalized_UNI" object included the SPC_Label subobject. Like the definition above, SPC_Label shows the provisioned connection label over = UNI portion, not NNI portion. As such, I think it is right for "Generalized_UNI" object to include = the SPC_Label subobject. In addition, by using this subobject and other information(maybe, ERO etc), the destination egress network node could idntify itself to be the last network node and not to invoke connection establishment over UNI interface. I hope this email conclude the discussion of SPC connections.=20 And, I'd like to know which WG rfc3476 is an output from because I = think it is not a output of ccamp WG.=20 Thanks,=20 Young=20 ------_=_NextPart_001_01C3AAE7.CBE62210 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections
 
-----Original Message-----
From: Ong, Lyndon=20 [mailto:LyOng@Ciena.com]
Sent: Friday, November 14, 2003 = 10:42=20 AM
To: John Drake; 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 connections

Hi=20 John,
 
Actually the extensions in the GMPLS Overlay draft would=20 not
be=20 sufficient. 
 
JD:  Per Adrian's = note, there are=20 no extensions.
 
Overlay deals again with signaled = interfaces
rather than SPC. 
 
JD:  What possible = difference does=20 that make? 
 
Cheers,
 
Lyndon
-----Original Message-----
From: John Drake=20 [mailto:jdrake@calient.net]
Sent: Friday, November 14, = 2003 10:36=20 AM
To: Ong, Lyndon; 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 connections

Lyndon,
 
You weren't paying attention to Adrian's e-mail,=20 below:
 
Lyndon,

Thank you for = raising=20 this. There is certainly a lack of clarity in 3473 in this = regard,
which=20 is perhaps unfortunate.

In the earlier versions of the GMPLS = work,=20 this was made very explicit (sic) because
egress label control = was=20 invented before it was generalized to explicit label.

There = is some=20 reference to this in RFC3471 (of course, the function was=20 originally
independent of signaling protocol), but no explicit=20 procedures.

This descriptive deficiency has been addressed = in=20 draft-ccamp-gmpls-overlay. There is no
change in protocol to = enable this=20 function, merely a description of how it all works.

Hope = this=20 helps.

Cheers,
Adrian
-----Original Message-----
From: Ong, Lyndon=20 [mailto:LyOng@Ciena.com]
Sent: Friday, November 14, = 2003 10:16=20 AM
To: 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: Re: = spc=20 connections

Hi Young,
 
I support your conclusion.  With this approach it = is also=20 unnecessary to modify the
procedures defined in RFC 3473 for Explicit Label = Control, which=20 make sense in their
original use.
 
Regarding RFC 3476, this was submitted by Bala = Rajagopalan, who=20 chairs the Signaling
Working Group of OIF, and was needed for agreement with = IETF/IANA=20 on codepoint assignments
in RSVP and LDP for the OIF UNI interface.  The = signaling=20 defined in the OIF UNI is
basically a subset of G.7713.2 and G.7713.3 for the UNI, = although=20 the ITU-T specifications
were completed later.
 
Cheers,
 
Lyndon
-----Original Message-----
From: = yhwkim@etri.re.kr=20 [mailto:yhwkim@etri.re.kr]
Sent: Friday, November 14, = 2003=20 7:18 AM
To: jonathan.sadler@tellabs.com;=20 yhwkim@etri.re.kr
Cc: adrian@olddog.co.uk; Ong, = Lyndon;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: = [????] Re: [=20 AuA=A8=F9E=A2=AC=A8=F6A ] spc connections

Hi,

I reviewed OIF E-NNI 1.0 = document(oif2003.179.00) that=20 includes the definition of SPC_Label.
The=20 following description shows the definition of the = SPC_Label.

"This attribute represents the SNP used at = the=20 destination network-to-user connection. The SPC SNP ID is = locally unique=20 to the destination end and provided to the control plane by an = external=20 agent (e.g., the management system that initiated the SPC = connection=20 request). Note that in the case of the SPC connection, both = source and=20 destination user-to-network connections are provisioned. As = such, when=20 setting up a network switched connection to support the SPC = service, the=20 destination SNP associated with the provisioned connection = needs to be=20 specified to allow the control plane to connect the switched = connection=20 to the destination portion of the provisioned = connection."

After reading this clause, I bacame to = understand the=20 reason that "Generalized_UNI" object included the SPC_Label = subobject.=20 Like the definition above, SPC_Label shows the provisioned = connection=20 label over UNI portion, not NNI portion.

As such, I think it is right for = "Generalized_UNI"=20 object  to include the SPC_Label subobject. In addition, = by using=20 this subobject and other information(maybe, ERO etc), the = destination=20 egress network node could idntify itself to be the last network = node and=20 not to invoke connection establishment over UNI = interface.

I hope this email conclude the discussion of = SPC=20 connections.
And, I'd like to know = which WG=20 rfc3476 is an output from because I think it is not a output of = ccamp=20 WG.

Thanks,
Young=20 =

------_=_NextPart_001_01C3AAE7.CBE62210-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 18:43:02 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61E6@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'John Drake' , "'yhwkim@etri.re.kr'" , jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: spc connections Date: Fri, 14 Nov 2003 10:42:13 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AADF.04DB5DA0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AADF.04DB5DA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi John, =20 Actually the extensions in the GMPLS Overlay draft would not be sufficient. Overlay deals again with signaled interfaces rather than SPC. =20 Cheers, =20 Lyndon -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: Friday, November 14, 2003 10:36 AM To: Ong, Lyndon; 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: RE: spc connections Lyndon, =20 You weren't paying attention to Adrian's e-mail, below: =20 Lyndon, Thank you for raising this. There is certainly a lack of clarity in = 3473 in this regard, which is perhaps unfortunate. In the earlier versions of the GMPLS work, this was made very explicit = (sic) because egress label control was invented before it was generalized to explicit = label. There is some reference to this in RFC3471 (of course, the function was = originally independent of signaling protocol), but no explicit procedures. This descriptive deficiency has been addressed in = draft-ccamp-gmpls-overlay. There is no change in protocol to enable this function, merely a description of how = it all works. Hope this helps. Cheers, Adrian -----Original Message----- From: Ong, Lyndon [mailto:LyOng@Ciena.com] Sent: Friday, November 14, 2003 10:16 AM To: 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: Re: spc connections Hi Young, =20 I support your conclusion. With this approach it is also unnecessary = to modify the procedures defined in RFC 3473 for Explicit Label Control, which make = sense in their original use. =20 Regarding RFC 3476, this was submitted by Bala Rajagopalan, who chairs = the Signaling Working Group of OIF, and was needed for agreement with IETF/IANA on = codepoint assignments in RSVP and LDP for the OIF UNI interface. The signaling defined in = the OIF UNI is basically a subset of G.7713.2 and G.7713.3 for the UNI, although the = ITU-T specifications were completed later. =20 Cheers, =20 Lyndon -----Original Message----- From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr] Sent: Friday, November 14, 2003 7:18 AM To: jonathan.sadler@tellabs.com; yhwkim@etri.re.kr Cc: adrian@olddog.co.uk; Ong, Lyndon; kireeti@juniper.net; = ccamp@ops.ietf.org Subject: [????] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc connections Hi,=20 I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the = definition of SPC_Label.=20 The following description shows the definition of the SPC_Label.=20 "This attribute represents the SNP used at the destination = network-to-user connection. The SPC SNP ID is locally unique to the = destination end and provided to the control plane by an external agent = (e.g., the management system that initiated the SPC connection = request). Note that in the case of the SPC connection, both source and = destination user-to-network connections are provisioned. As such, when = setting up a network switched connection to support the SPC service, = the destination SNP associated with the provisioned connection needs to = be specified to allow the control plane to connect the switched = connection to the destination portion of the provisioned connection." After reading this clause, I bacame to understand the reason that = "Generalized_UNI" object included the SPC_Label subobject. Like the = definition above, SPC_Label shows the provisioned connection label over = UNI portion, not NNI portion. As such, I think it is right for "Generalized_UNI" object to include = the SPC_Label subobject. In addition, by using this subobject and other = information(maybe, ERO etc), the destination egress network node could = idntify itself to be the last network node and not to invoke connection = establishment over UNI interface. I hope this email conclude the discussion of SPC connections.=20 And, I'd like to know which WG rfc3476 is an output from because I = think it is not a output of ccamp WG.=20 Thanks,=20 Young=20 ------_=_NextPart_001_01C3AADF.04DB5DA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections
Hi=20 John,
 
Actually the extensions in the GMPLS Overlay draft would=20 not
be=20 sufficient.  Overlay deals again with signaled=20 interfaces
rather=20 than SPC.
 
Cheers,
 
Lyndon
-----Original Message-----
From: John Drake=20 [mailto:jdrake@calient.net]
Sent: Friday, November 14, 2003 = 10:36=20 AM
To: Ong, Lyndon; 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: RE: spc=20 connections

Lyndon,
 
You=20 weren't paying attention to Adrian's e-mail, = below:
 
Lyndon,

Thank you for = raising this.=20 There is certainly a lack of clarity in 3473 in this regard,
which = is=20 perhaps unfortunate.

In the earlier versions of the GMPLS = work, this=20 was made very explicit (sic) because
egress label control was = invented=20 before it was generalized to explicit label.

There is some = reference to=20 this in RFC3471 (of course, the function was = originally
independent of=20 signaling protocol), but no explicit procedures.

This = descriptive=20 deficiency has been addressed in draft-ccamp-gmpls-overlay. There is=20 no
change in protocol to enable this function, merely a = description of how=20 it all works.

Hope this=20 helps.

Cheers,
Adrian
-----Original Message-----
From: Ong, Lyndon=20 [mailto:LyOng@Ciena.com]
Sent: Friday, November 14, 2003 = 10:16=20 AM
To: 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: Re: spc=20 connections

Hi=20 Young,
 
I=20 support your conclusion.  With this approach it is also = unnecessary to=20 modify the
procedures defined in RFC 3473 for Explicit Label Control, = which make=20 sense in their
original use.
 
Regarding RFC 3476, this was submitted by Bala = Rajagopalan, who=20 chairs the Signaling
Working Group of OIF, and was needed for agreement with = IETF/IANA on=20 codepoint assignments
in=20 RSVP and LDP for the OIF UNI interface.  The signaling defined = in the=20 OIF UNI is
basically a subset of G.7713.2 and G.7713.3 for the UNI, = although the=20 ITU-T specifications
were completed later.
 
Cheers,
 
Lyndon
-----Original Message-----
From: = yhwkim@etri.re.kr=20 [mailto:yhwkim@etri.re.kr]
Sent: Friday, November 14, = 2003 7:18=20 AM
To: jonathan.sadler@tellabs.com;=20 yhwkim@etri.re.kr
Cc: adrian@olddog.co.uk; Ong, Lyndon; = kireeti@juniper.net; ccamp@ops.ietf.org
Subject: [????] = Re: [=20 AuA=A8=F9E=A2=AC=A8=F6A ] spc connections

Hi,

I reviewed OIF E-NNI 1.0 = document(oif2003.179.00) that=20 includes the definition of SPC_Label.
The=20 following description shows the definition of the = SPC_Label.

"This attribute represents the SNP used at the = destination=20 network-to-user connection. The SPC SNP ID is locally unique to = the=20 destination end and provided to the control plane by an external = agent=20 (e.g., the management system that initiated the SPC connection = request).=20 Note that in the case of the SPC connection, both source and = destination=20 user-to-network connections are provisioned. As such, when = setting up a=20 network switched connection to support the SPC service, the = destination=20 SNP associated with the provisioned connection needs to be = specified to=20 allow the control plane to connect the switched connection to the = destination portion of the provisioned connection."

After reading this clause, I bacame to = understand the=20 reason that "Generalized_UNI" object included the SPC_Label = subobject.=20 Like the definition above, SPC_Label shows the provisioned = connection=20 label over UNI portion, not NNI portion.

As such, I think it is right for = "Generalized_UNI"=20 object  to include the SPC_Label subobject. In addition, by = using=20 this subobject and other information(maybe, ERO etc), the = destination=20 egress network node could idntify itself to be the last network = node and=20 not to invoke connection establishment over UNI = interface.

I hope this email conclude the discussion of = SPC=20 connections.
And, I'd like to know = which WG=20 rfc3476 is an output from because I think it is not a output of = ccamp=20 WG.

Thanks,
Young=20

------_=_NextPart_001_01C3AADF.04DB5DA0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 18:37:10 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048D8C@nimbus.chromisys.com> From: John Drake To: "'Ong, Lyndon'" , "'yhwkim@etri.re.kr'" , jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: spc connections Date: Fri, 14 Nov 2003 10:36:11 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AADE.2D322AF0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AADE.2D322AF0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Lyndon, =20 You weren't paying attention to Adrian's e-mail, below: =20 Lyndon, Thank you for raising this. There is certainly a lack of clarity in = 3473 in this regard, which is perhaps unfortunate. In the earlier versions of the GMPLS work, this was made very explicit (sic) because egress label control was invented before it was generalized to explicit label. There is some reference to this in RFC3471 (of course, the function was originally independent of signaling protocol), but no explicit procedures. This descriptive deficiency has been addressed in draft-ccamp-gmpls- overlay. There is no change in protocol to enable this function, merely a description of how = it all works. Hope this helps. Cheers, Adrian -----Original Message----- From: Ong, Lyndon [mailto:LyOng@Ciena.com] Sent: Friday, November 14, 2003 10:16 AM To: 'yhwkim@etri.re.kr'; jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk; kireeti@juniper.net; ccamp@ops.ietf.org Subject: Re: spc connections Hi Young, =20 I support your conclusion. With this approach it is also unnecessary = to modify the procedures defined in RFC 3473 for Explicit Label Control, which make = sense in their original use. =20 Regarding RFC 3476, this was submitted by Bala Rajagopalan, who chairs = the Signaling Working Group of OIF, and was needed for agreement with IETF/IANA on codepoint assignments in RSVP and LDP for the OIF UNI interface. The signaling defined in = the OIF UNI is basically a subset of G.7713.2 and G.7713.3 for the UNI, although the = ITU-T specifications were completed later. =20 Cheers, =20 Lyndon -----Original Message----- From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr] Sent: Friday, November 14, 2003 7:18 AM To: jonathan.sadler@tellabs.com; yhwkim@etri.re.kr Cc: adrian@olddog.co.uk; Ong, Lyndon; kireeti@juniper.net; ccamp@ops.ietf.org Subject: [????] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc connections Hi,=20 I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the definition of SPC_Label.=20 The following description shows the definition of the SPC_Label.=20 "This attribute represents the SNP used at the destination = network-to-user connection. The SPC SNP ID is locally unique to the destination end and provided to the control plane by an external agent (e.g., the = management system that initiated the SPC connection request). Note that in the = case of the SPC connection, both source and destination user-to-network = connections are provisioned. As such, when setting up a network switched connection = to support the SPC service, the destination SNP associated with the provisioned connection needs to be specified to allow the control plane = to connect the switched connection to the destination portion of the provisioned connection." After reading this clause, I bacame to understand the reason that "Generalized_UNI" object included the SPC_Label subobject. Like the definition above, SPC_Label shows the provisioned connection label over = UNI portion, not NNI portion. As such, I think it is right for "Generalized_UNI" object to include = the SPC_Label subobject. In addition, by using this subobject and other information(maybe, ERO etc), the destination egress network node could idntify itself to be the last network node and not to invoke connection establishment over UNI interface. I hope this email conclude the discussion of SPC connections.=20 And, I'd like to know which WG rfc3476 is an output from because I = think it is not a output of ccamp WG.=20 Thanks,=20 Young=20 ------_=_NextPart_001_01C3AADE.2D322AF0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections
Lyndon,
 
You=20 weren't paying attention to Adrian's e-mail, below:
 
Lyndon,

Thank you for = raising this.=20 There is certainly a lack of clarity in 3473 in this regard,
which = is perhaps=20 unfortunate.

In the earlier versions of the GMPLS work, this was = made=20 very explicit (sic) because
egress label control was invented before = it was=20 generalized to explicit label.

There is some reference to this = in RFC3471=20 (of course, the function was originally
independent of signaling = protocol),=20 but no explicit procedures.

This descriptive deficiency has been = addressed in draft-ccamp-gmpls-overlay. There is no
change in = protocol to=20 enable this function, merely a description of how it all = works.

Hope this=20 helps.

Cheers,
Adrian
-----Original Message-----
From: Ong, Lyndon=20 [mailto:LyOng@Ciena.com]
Sent: Friday, November 14, 2003 = 10:16=20 AM
To: 'yhwkim@etri.re.kr';=20 jonathan.sadler@tellabs.com
Cc: adrian@olddog.co.uk;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: Re: spc=20 connections

Hi=20 Young,
 
I=20 support your conclusion.  With this approach it is also = unnecessary to=20 modify the
procedures defined in RFC 3473 for Explicit Label Control, = which make=20 sense in their
original use.
 
Regarding RFC 3476, this was submitted by Bala Rajagopalan, = who chairs=20 the Signaling
Working Group of OIF, and was needed for agreement with = IETF/IANA on=20 codepoint assignments
in=20 RSVP and LDP for the OIF UNI interface.  The signaling defined = in the OIF=20 UNI is
basically a subset of G.7713.2 and G.7713.3 for the UNI, = although the=20 ITU-T specifications
were=20 completed later.
 
Cheers,
 
Lyndon
-----Original Message-----
From: = yhwkim@etri.re.kr=20 [mailto:yhwkim@etri.re.kr]
Sent: Friday, November 14, = 2003 7:18=20 AM
To: jonathan.sadler@tellabs.com;=20 yhwkim@etri.re.kr
Cc: adrian@olddog.co.uk; Ong, Lyndon;=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: [????] = Re: [=20 AuA=A8=F9E=A2=AC=A8=F6A ] spc connections

Hi,

I reviewed OIF E-NNI 1.0 document(oif2003.179.00) = that=20 includes the definition of SPC_Label.
The = following=20 description shows the definition of the SPC_Label.

"This attribute represents the SNP used at the = destination=20 network-to-user connection. The SPC SNP ID is locally unique to the = destination end and provided to the control plane by an external = agent=20 (e.g., the management system that initiated the SPC connection = request).=20 Note that in the case of the SPC connection, both source and = destination=20 user-to-network connections are provisioned. As such, when setting = up a=20 network switched connection to support the SPC service, the = destination SNP=20 associated with the provisioned connection needs to be specified to = allow=20 the control plane to connect the switched connection to the = destination=20 portion of the provisioned connection."

After reading this clause, I bacame to understand = the reason=20 that "Generalized_UNI" object included the SPC_Label subobject. = Like the=20 definition above, SPC_Label shows the provisioned connection label = over UNI=20 portion, not NNI portion.

As such, I think it is right for = "Generalized_UNI"=20 object  to include the SPC_Label subobject. In addition, by = using this=20 subobject and other information(maybe, ERO etc), the destination = egress=20 network node could idntify itself to be the last network node and = not to=20 invoke connection establishment over UNI interface.

I hope this email conclude the discussion of SPC=20 connections.
And, I'd like to know which = WG rfc3476=20 is an output from because I think it is not a output of ccamp = WG.=20

Thanks,
Young=20

------_=_NextPart_001_01C3AADE.2D322AF0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 18:17:09 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61E5@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'yhwkim@etri.re.kr'" , jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: spc connections Date: Fri, 14 Nov 2003 10:15:57 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AADB.59923660" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AADB.59923660 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi Young, =20 I support your conclusion. With this approach it is also unnecessary = to modify the procedures defined in RFC 3473 for Explicit Label Control, which make = sense in their original use. =20 Regarding RFC 3476, this was submitted by Bala Rajagopalan, who chairs = the Signaling Working Group of OIF, and was needed for agreement with IETF/IANA on = codepoint assignments in RSVP and LDP for the OIF UNI interface. The signaling defined in = the OIF UNI is basically a subset of G.7713.2 and G.7713.3 for the UNI, although the = ITU-T specifications were completed later. =20 Cheers, =20 Lyndon -----Original Message----- From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr] Sent: Friday, November 14, 2003 7:18 AM To: jonathan.sadler@tellabs.com; yhwkim@etri.re.kr Cc: adrian@olddog.co.uk; Ong, Lyndon; kireeti@juniper.net; = ccamp@ops.ietf.org Subject: [????] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc connections Hi,=20 I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the = definition of SPC_Label.=20 The following description shows the definition of the SPC_Label.=20 "This attribute represents the SNP used at the destination = network-to-user connection. The SPC SNP ID is locally unique to the = destination end and provided to the control plane by an external agent = (e.g., the management system that initiated the SPC connection = request). Note that in the case of the SPC connection, both source and = destination user-to-network connections are provisioned. As such, when = setting up a network switched connection to support the SPC service, = the destination SNP associated with the provisioned connection needs to = be specified to allow the control plane to connect the switched = connection to the destination portion of the provisioned connection." After reading this clause, I bacame to understand the reason that = "Generalized_UNI" object included the SPC_Label subobject. Like the = definition above, SPC_Label shows the provisioned connection label over = UNI portion, not NNI portion. As such, I think it is right for "Generalized_UNI" object to include = the SPC_Label subobject. In addition, by using this subobject and other = information(maybe, ERO etc), the destination egress network node could = idntify itself to be the last network node and not to invoke connection = establishment over UNI interface. I hope this email conclude the discussion of SPC connections.=20 And, I'd like to know which WG rfc3476 is an output from because I = think it is not a output of ccamp WG.=20 Thanks,=20 Young=20 ------_=_NextPart_001_01C3AADB.59923660 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections
Hi=20 Young,
 
I=20 support your conclusion.  With this approach it is also = unnecessary to=20 modify the
procedures defined in RFC 3473 for Explicit Label Control, = which make=20 sense in their
original use.
 
Regarding RFC 3476, this was submitted by Bala Rajagopalan, = who chairs=20 the Signaling
Working Group of OIF, and was needed for agreement with = IETF/IANA on=20 codepoint assignments
in=20 RSVP and LDP for the OIF UNI interface.  The signaling defined in = the OIF=20 UNI is
basically a subset of G.7713.2 and G.7713.3 for the UNI, = although the=20 ITU-T specifications
were=20 completed later.
 
Cheers,
 
Lyndon
-----Original Message-----
From: yhwkim@etri.re.kr = [mailto:yhwkim@etri.re.kr]
Sent: Friday, November 14, 2003 = 7:18=20 AM
To: jonathan.sadler@tellabs.com; = yhwkim@etri.re.kr
Cc:=20 adrian@olddog.co.uk; Ong, Lyndon; kireeti@juniper.net;=20 ccamp@ops.ietf.org
Subject: [????] Re: [ = AuA=A8=F9E=A2=AC=A8=F6A ] spc=20 connections

Hi,

I reviewed OIF E-NNI 1.0 document(oif2003.179.00) = that=20 includes the definition of SPC_Label.
The = following=20 description shows the definition of the SPC_Label.

"This attribute represents the SNP used at the = destination=20 network-to-user connection. The SPC SNP ID is locally unique to the=20 destination end and provided to the control plane by an external = agent (e.g.,=20 the management system that initiated the SPC connection request). = Note that in=20 the case of the SPC connection, both source and destination = user-to-network=20 connections are provisioned. As such, when setting up a network = switched=20 connection to support the SPC service, the destination SNP associated = with the=20 provisioned connection needs to be specified to allow the control = plane to=20 connect the switched connection to the destination portion of the = provisioned=20 connection."

After reading this clause, I bacame to understand = the reason=20 that "Generalized_UNI" object included the SPC_Label subobject. Like = the=20 definition above, SPC_Label shows the provisioned connection label = over UNI=20 portion, not NNI portion.

As such, I think it is right for "Generalized_UNI"=20 object  to include the SPC_Label subobject. In addition, by = using this=20 subobject and other information(maybe, ERO etc), the destination = egress=20 network node could idntify itself to be the last network node and not = to=20 invoke connection establishment over UNI interface.

I hope this email conclude the discussion of SPC=20 connections.
And, I'd like to know which WG = rfc3476 is=20 an output from because I think it is not a output of ccamp WG. =

Thanks,
Young=20

------_=_NextPart_001_01C3AADB.59923660-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 17:08:20 +0000 Subject: Re: =?euc-kr?B?W8D8w7zIuL3FXSBSZTogWyBBdUGo+UWirKj2QSBdIHNwYyBjb25u?= To: yhwkim@etri.re.kr Date: Fri, 14 Nov 2003 17:07:20 +0000 (GMT) Cc: jonathan.sadler@tellabs.com, adrian@olddog.co.uk, LyOng@ciena.com, kireeti@juniper.net, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou hi, as said in the following mail the point you mention here below "[...] the destination egress network node could idntify itself to be the last network node and not to invoke connection establishment over UNI interface." has been addressed, however it has not been taken into account when info rfc3474 had been released hope this helps, - dimitri. > > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C3AAC2.7A757040 > Content-Type: text/plain; > charset="euc-kr" > Content-Transfer-Encoding: quoted-printable > > Hi, > > I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the > definition of SPC_Label. > The following description shows the definition of the SPC_Label. > > "This attribute represents the SNP used at the destination = > network-to-user > connection. The SPC SNP ID is locally unique to the destination end and > provided to the control plane by an external agent (e.g., the = > management > system that initiated the SPC connection request). Note that in the = > case of > the SPC connection, both source and destination user-to-network = > connections > are provisioned. As such, when setting up a network switched connection = > to > support the SPC service, the destination SNP associated with the > provisioned connection needs to be specified to allow the control plane = > to > connect the switched connection to the destination portion of the > provisioned connection." > > After reading this clause, I bacame to understand the reason that > "Generalized_UNI" object included the SPC_Label subobject. Like the > definition above, SPC_Label shows the provisioned connection label over = > UNI > portion, not NNI portion. > As such, I think it is right for "Generalized_UNI" object to include = > the > SPC_Label subobject. In addition, by using this subobject and other > information(maybe, ERO etc), the destination egress network node could > idntify itself to be the last network node and not to invoke connection > establishment over UNI interface. > > I hope this email conclude the discussion of SPC connections. > And, I'd like to know which WG rfc3476 is an output from because I = > think it > is not a output of ccamp WG. > > Thanks, > Young > > > > > =BF=F8=BA=BB =B3=BB=BF=EB: > > =BA=B8=B3=BD=BB=E7=B6=F7: Jonathan Sadler[jonathan.sadler@tellabs.com] > =B9=DE=B4=C2=BB=E7=B6=F7: yhwkim@etri.re.kr > =C2=FC=C1=B6:adrian@olddog.co.uk; LyOng@ciena.com; kireeti@juniper.net; > ccamp@ops.ietf.org > =C1=A6=B8=F1: Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc connections > =B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/14 =B1=DD 00:31 > > Hi Young - > While the name of the "GENERALIZED_UNI" object seems to refer to the = > UNI > reference point, the purpose of the object is to carry attributes of a > call. G.8080 states that SPCs still use Network Call Controllers = > (NCCs) in > the process of setting up the SPC. Consequently, a call exists even = > for > SPCs. Therefore, carrying attributes of a call is independent of = > whether > the call was requested across a UNI or from a management system (ie. an > SPC). I agree that the name of the object is somewhat misleading, but = > it > comes from the fact that G.7713.2 attempted to reuse existing RSVP > extensions as much as possible. (The name of this Call object came = > from > the OIF UNI 1.0 IA) > The identification of the egress point in a carriers network to which = > an > SPC is to be delivered is also a Call attribute, not a connection = > attribute > -- it is independent of how a customer's service request is realized > acrossed a service provider's network. However, the ERO is an attribute = > of > a connection, not a call, and may not necessarily be passed over the = > E-NNI > reference point. Consequently, the use of explicit label control in an = > ERO > is not a possible way to handle SPCs that traverse an E-NNI. This is = > why > the egress point identification appears in the call object in G.7713.2. > I hope this helps clarify SPC operations in G.7713.2/RFC 3474. > Jonathan Sadler > yhwkim@etri.re.kr wrote: > Hi, > In my understanding, for the support of SPC connection, SPC_LABEL = > (Type=3D4, > Sub-type=3D2)=20 > subobject seems to be included in GENERALIZED_UNI object.=20 > If my understanding is correct, I think there is a big ifference = > between > concept of SPC connection and GENERALIZED_UNI object. SPC connection is = > NNI > portion, not UNI. > As it is, GENERALIZED_UNI object describes originating and terminating = > UNI > aspects between client and network nodes.=20 > >From logical view-point, in addition, the difference between switched > connection (SC) and soft permanent connection (SPC) is where call and > connection initiation is. In case of SC the initiation is of client = > node, > but in case of SPC the initiation is of network node (of course, = > triggered > by NMS). As a result, I think that GENERALIZED_UNI object and SPC > connection could not be indicated by using the object, called > GENERALIZED_UNI object because these are completely different by = > nature. > What do you think of my opinion? > Thanks,=20 > Young > ¿øº» ³»¿ë: > º¸³½»ç¶÷: Adrian > Farrel[adrian@olddog.co.uk]=20 > ¹Þ´Â»ç¶÷: Ong, Lyndon=20 > ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org=20 > Á¦¸ñ: spc connections=20 > ¹ÞÀº³¯Â¥: 2003/11/13 > ¸ñ 06:57=20 > =20 > Lyndon,=20 > Thank you for raising this. There is certainly a lack of clarity in = > 3473 in > this regard,=20 > which is perhaps unfortunate.=20 > In the earlier versions of the GMPLS work, this was made very explicit > (sic) because=20 > egress label control was invented before it was generalized to explicit > label.=20 > There is some reference to this in RFC3471 (of course, the function was > originally=20 > independent of signaling protocol), but no explicit procedures.=20 > This descriptive deficiency has been addressed in draft-ccamp-gmpls- > overlay. There is no=20 > change in protocol to enable this function, merely a description of how = > it > all works.=20 > Hope this helps.=20 > Cheers,=20 > Adrian=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Hi Adrian,=20 > A couple of times now it's been suggested that Explicit Label Control = > is a > way to=20 > do SPC connections instead of the SPC_Label sub-object. I'm wondering = > if=20 > people have a different model of SPC connections in mind. The = > procedures > in=20 > RFC 3473 for Explicit Label Control are as follows:=20 > [when a label sub-object is present] If the U-bit of the=20 > subobject being examined is clear (0), then value of the label is=20 > copied into a new Label_Set object. This Label_Set object MUST be=20 > included on the corresponding outgoing Path message.=20 > If the U-bit of the subobject being examined is set (1), then value=20 > of the label is label to be used for upstream traffic associated = > with=20 > the bidirectional LSP.=20 > Neither of these would seem to help you for SPC, since there is no = > outgoing > PATH=20 > message at the network endpoint, the endpoint call control is handled = > by=20 > the management system and not using a UNI or overlay interface (at = > least=20 > as defined in G.8080).=20 > Explicit Label Control seems like it would help you control the label > assignment=20 > within the signaled portion of a connection. > Cheers,=20 > Lyndon > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The information contained in this message may be privileged=20 > and confidential and protected from disclosure. If the=20 > reader of this message is not the intended recipient, or an=20 > employee or agent responsible for delivering this message to=20 > the intended recipient, you are hereby notified that any=20 > reproduction, dissemination or distribution of this=20 > communication is strictly prohibited. If you have received=20 > this communication in error, please notify us immediately by=20 > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ------_=_NextPart_001_01C3AAC2.7A757040 > Content-Type: text/html; > charset="euc-kr" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Deuc-kr"> > 5.5.2653.12"> > [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = > connections > > > >

Hi, >

> >

I reviewed OIF E-NNI 1.0 document(oif2003.179.00) = > that includes the definition of SPC_Label. >
The following description shows the definition of = > the SPC_Label. >

> >

"This attribute represents the SNP used at the = > destination network-to-user connection. The SPC SNP ID is locally = > unique to the destination end and provided to the control plane by an = > external agent (e.g., the management system that initiated the SPC = > connection request). Note that in the case of the SPC connection, both = > source and destination user-to-network connections are provisioned. As = > such, when setting up a network switched connection to support the SPC = > service, the destination SNP associated with the provisioned connection = > needs to be specified to allow the control plane to connect the = > switched connection to the destination portion of the provisioned = > connection."

> >

After reading this clause, I bacame to understand the = > reason that "Generalized_UNI" object included the SPC_Label = > subobject. Like the definition above, SPC_Label shows the provisioned = > connection label over UNI portion, not NNI portion.

> >

As such, I think it is right for = > "Generalized_UNI" object  to include the SPC_Label = > subobject. In addition, by using this subobject and other = > information(maybe, ERO etc), the destination egress network node could = > idntify itself to be the last network node and not to invoke connection = > establishment over UNI interface.

> >

I hope this email conclude the discussion of SPC = > connections. >
And, I'd like to know which WG rfc3476 is an output = > from because I think it is not a output of ccamp WG. >

> >

Thanks, >
Young >

>
>
>
> >

=BF=F8=BA=BB =B3=BB=BF=EB: >

> >

=BA=B8=B3=BD=BB=E7=B6=F7: Jonathan = > Sadler[jonathan.sadler@tellabs.com] >
=B9=DE=B4=C2=BB=E7=B6=F7: yhwkim@etri.re.kr >
=C2=FC=C1=B6:adrian@olddog.co.uk; LyOng@ciena.com; = > kireeti@juniper.net; ccamp@ops.ietf.org >
=C1=A6=B8=F1: Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = > connections >
=B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/14 =B1=DD = > 00:31 >

> >

Hi Young - >
While the name of the "GENERALIZED_UNI" = > object seems to refer to the UNI reference point, the purpose of the = > object is to carry attributes of a call.  G.8080 states that SPCs = > still use Network Call Controllers (NCCs) in the process of setting up = > the SPC.  Consequently, a call exists even for SPCs.  = > Therefore, carrying attributes of a call is independent of whether the = > call was requested across a UNI or from a management system (ie. an = > SPC). I agree that the name of the object is somewhat misleading, but = > it comes from the fact that G.7713.2 attempted to reuse existing RSVP = > extensions as much as possible.  (The name of this Call object = > came from the OIF UNI 1.0 IA)

> >

The identification of the egress point in a carriers = > network to which an SPC is to be delivered is also a Call attribute, = > not a connection attribute -- it is independent of how a customer's = > service request is realized acrossed a service provider's network. = > However, the ERO is an attribute of a connection, not a call, and may = > not necessarily be passed over the E-NNI reference point.  = > Consequently, the use of explicit label control in an ERO is not a = > possible way to handle SPCs that traverse an E-NNI.  This is why = > the egress point identification appears in the call object in = > G.7713.2.

> >

I hope this helps clarify SPC operations in = > G.7713.2/RFC 3474. >
Jonathan Sadler >
yhwkim@etri.re.kr wrote: >
Hi, >
In my understanding, for the support of SPC = > connection, SPC_LABEL (Type=3D4, Sub-type=3D2) >
subobject seems to be included in GENERALIZED_UNI = > object. >
If my understanding is correct, I think there is a = > big ifference between concept of SPC connection and GENERALIZED_UNI = > object. SPC connection is NNI portion, not UNI.

> >

As it is, GENERALIZED_UNI object describes = > originating and terminating UNI aspects between client and network = > nodes. >
From logical view-point, in addition, the difference = > between switched connection (SC) and soft permanent connection (SPC) is = > where call and connection initiation is. In case of SC the initiation = > is of client node, but in case of SPC the initiation is of network node = > (of course, triggered by NMS). As a result, I think that = > GENERALIZED_UNI object and SPC connection could not be indicated by = > using the object, called GENERALIZED_UNI object because these are = > completely different by nature.

> >

What do you think of my opinion? >
Thanks, >
Young >
&iquest;&oslash;&ordm;&raquo; = > &sup3;&raquo;&iquest;&euml;: >
SIZE=3D2>&ordm;&cedil;&sup3;&frac12;&raquo;&cced= > il;&para;&divide;: Adrian Farrel[adrian@olddog.co.uk] >
SIZE=3D2>&sup1;&THORN;&acute;&Acirc;&raquo;&cced= > il;&para;&divide;: Ong, Lyndon >
&Acirc;&uuml;&Aacute;&para;:'Kireeti = > Kompella'; ccamp@ops.ietf.org >
&Aacute;&brvbar;&cedil;&ntilde;: spc = > connections >
SIZE=3D2>&sup1;&THORN;&Agrave;&ordm;&sup3;&macr;= > &Acirc;&yen;: 2003/11/13 &cedil;&ntilde; 06:57 >
  >
Lyndon, >
Thank you for raising this. There is certainly a = > lack of clarity in 3473 in this regard, >
which is perhaps unfortunate. >
In the earlier versions of the GMPLS work, this was = > made very explicit (sic) because >
egress label control was invented before it was = > generalized to explicit label. >
There is some reference to this in RFC3471 (of = > course, the function was originally >
independent of signaling protocol), but no explicit = > procedures. >
This descriptive deficiency has been addressed in = > draft-ccamp-gmpls-overlay. There is no >
change in protocol to enable this function, merely a = > description of how it all works. >
Hope this helps. >
Cheers, >
Adrian >
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > >
Hi Adrian, >
A couple of times now it's been suggested that = > Explicit Label Control is a way to >
do SPC connections instead of the SPC_Label = > sub-object.  I'm wondering if >
people have a different model of SPC connections in = > mind.  The procedures in >
RFC 3473 for Explicit Label Control are as follows: = > >
   [when a label sub-object is = > present]  If the U-bit of the >
   subobject being examined is clear (0), = > then value of the label is >
   copied into a new Label_Set = > object.  This Label_Set object MUST be >
   included on the corresponding outgoing = > Path message. >
   If the U-bit of the subobject being = > examined is set (1), then value >
   of the label is label to be used for = > upstream traffic associated with >
   the bidirectional LSP. >
Neither of these would seem to help you for SPC, = > since there is no outgoing PATH >
message at the network endpoint, the endpoint call = > control is handled by >
the management system and not using a UNI or overlay = > interface (at least >
as defined in G.8080). >
Explicit Label Control seems like it would help you = > control the label assignment >
within the signaled portion of a connection. >
Cheers, >
Lyndon >

> >

SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >
The information contained in this message may be = > privileged >
and confidential and protected from disclosure. If = > the >
reader of this message is not the intended = > recipient, or an >
employee or agent responsible for delivering this = > message to >
the intended recipient, you are hereby notified that = > any >
reproduction, dissemination or distribution of this = > >
communication is strictly prohibited. If you have = > received >
this communication in error, please notify us = > immediately by >
replying to the message and deleting it from your = > computer. >

> >

Thank you. >
Tellabs >
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >

> > > > ------_=_NextPart_001_01C3AAC2.7A757040-- > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 16:35:46 +0000 Message-ID: <3FB503F8.64EE6BA4@tellabs.com> Date: Fri, 14 Nov 2003 10:34:01 -0600 From: Jonathan Sadler MIME-Version: 1.0 To: John Drake CC: "'yhwkim@etri.re.kr'" , adrian@olddog.co.uk, LyOng@ciena.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: [????] Re: [ AuA =?iso-8859-1?Q?=A8=F9?= E =?iso-8859-1?Q?=A2=AC=A8=F6?= A ] spc connections Content-Type: multipart/alternative; boundary="------------21E6EC8BCFCD0C004AC0AD29" --------------21E6EC8BCFCD0C004AC0AD29 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit John Drake wrote: > -----Original Message----- > From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr] > Sent: Friday, November 14, 2003 7:18 AM > To: jonathan.sadler@tellabs.com; yhwkim@etri.re.kr > Cc: adrian@olddog.co.uk; LyOng@ciena.com; > kireeti@juniper.net; ccamp@ops.ietf.org > Subject: [????] Re: [ AuA¨ùE¢¬¨öA ] spc connections > Hi, > > I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that > includes the definition of SPC_Label. > The following description shows the definition of the > SPC_Label. > > "This attribute represents the SNP used at the destination > network-to-user connection. The SPC SNP ID is locally unique > to the destination end and provided to the control plane by > an external agent (e.g., the management system that > initiated the SPC connection request). Note that in the case > of the SPC connection, both source and destination > user-to-network connections are provisioned. As such, when > setting up a network switched connection to support the SPC > service, the destination SNP associated with the provisioned > connection needs to be specified to allow the control plane > to connect the switched connection to the destination > portion of the provisioned connection." > > JD: Interestingly enough, I don't see the word 'call' once > in the above quote. I do see the word 'connection' quite a > few times, though. > --->8 snip 8<--- Which proves that the IETF isn't the only body guilty of using imprecise language in its DRAFT documents. I'm certain the editor of the OIF's E-NNI signalling spec appreciates your comment and will fix this nit in the next release of this DRAFT document. Jonathan Sadler ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ --------------21E6EC8BCFCD0C004AC0AD29 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit  

John Drake wrote:

-----Original Message-----
From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr]
Sent: Friday, November 14, 2003 7:18 AM
To: jonathan.sadler@tellabs.com; yhwkim@etri.re.kr
Cc: adrian@olddog.co.uk; LyOng@ciena.com; kireeti@juniper.net; ccamp@ops.ietf.org
Subject: [????] Re: [ AuA¨ùE¢¬¨öA ] spc connections
Hi,

I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the definition of SPC_Label.
The following description shows the definition of the SPC_Label.

"This attribute represents the SNP used at the destination network-to-user connection. The SPC SNP ID is locally unique to the destination end and provided to the control plane by an external agent (e.g., the management system that initiated the SPC connection request). Note that in the case of the SPC connection, both source and destination user-to-network connections are provisioned. As such, when setting up a network switched connection to support the SPC service, the destination SNP associated with the provisioned connection needs to be specified to allow the control plane to connect the switched connection to the destination portion of the provisioned connection."

JD:  Interestingly enough, I don't see the word 'call' once in the above quote.  I do see the word 'connection' quite a few times, though.

--->8 snip 8<---

Which proves that the IETF isn't the only body guilty of using imprecise language in its DRAFT documents.  I'm certain the editor of the OIF's E-NNI signalling spec appreciates your comment and will fix this nit in the next release of this DRAFT document.

Jonathan Sadler

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

--------------21E6EC8BCFCD0C004AC0AD29-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 15:47:56 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048D87@nimbus.chromisys.com> From: John Drake To: "'yhwkim@etri.re.kr'" , jonathan.sadler@tellabs.com Cc: adrian@olddog.co.uk, LyOng@ciena.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: =?euc-kr?B?UkU6IFs/Pz8/XSBSZTogWyBBdUGo+UWirKj2QSBdIHNwYyBjb25u?= =?euc-kr?B?ZWN0aW9ucw==?= Date: Fri, 14 Nov 2003 07:47:01 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AAC6.8B5B0330" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AAC6.8B5B0330 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr] Sent: Friday, November 14, 2003 7:18 AM To: jonathan.sadler@tellabs.com; yhwkim@etri.re.kr Cc: adrian@olddog.co.uk; LyOng@ciena.com; kireeti@juniper.net; ccamp@ops.ietf.org Subject: [????] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc connections Hi,=20 I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the definition of SPC_Label.=20 The following description shows the definition of the SPC_Label.=20 "This attribute represents the SNP used at the destination = network-to-user connection. The SPC SNP ID is locally unique to the destination end and provided to the control plane by an external agent (e.g., the = management system that initiated the SPC connection request). Note that in the = case of the SPC connection, both source and destination user-to-network = connections are provisioned. As such, when setting up a network switched connection = to support the SPC service, the destination SNP associated with the provisioned connection needs to be specified to allow the control plane = to connect the switched connection to the destination portion of the provisioned connection."=20 =20 JD: Interestingly enough, I don't see the word 'call' once in the = above quote. I do see the word 'connection' quite a few times, though. =20 After reading this clause, I bacame to understand the reason that "Generalized_UNI" object included the SPC_Label subobject. Like the definition above, SPC_Label shows the provisioned connection label over = UNI portion, not NNI portion. As such, I think it is right for "Generalized_UNI" object to include = the SPC_Label subobject. In addition, by using this subobject and other information(maybe, ERO etc), the destination egress network node could idntify itself to be the last network node and not to invoke connection establishment over UNI interface. I hope this email conclude the discussion of SPC connections.=20 And, I'd like to know which WG rfc3476 is an output from because I = think it is not a output of ccamp WG.=20 Thanks,=20 Young=20 =BF=F8=BA=BB =B3=BB=BF=EB:=20 =BA=B8=B3=BD=BB=E7=B6=F7: Jonathan Sadler[jonathan.sadler@tellabs.com]=20 =B9=DE=B4=C2=BB=E7=B6=F7: yhwkim@etri.re.kr=20 =C2=FC=C1=B6:adrian@olddog.co.uk; LyOng@ciena.com; kireeti@juniper.net; ccamp@ops.ietf.org=20 =C1=A6=B8=F1: Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc connections=20 =B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/14 =B1=DD 00:31=20 Hi Young -=20 While the name of the "GENERALIZED_UNI" object seems to refer to the = UNI reference point, the purpose of the object is to carry attributes of a call. G.8080 states that SPCs still use Network Call Controllers = (NCCs) in the process of setting up the SPC. Consequently, a call exists even = for SPCs. Therefore, carrying attributes of a call is independent of = whether the call was requested across a UNI or from a management system (ie. an SPC). I agree that the name of the object is somewhat misleading, but = it comes from the fact that G.7713.2 attempted to reuse existing RSVP extensions as much as possible. (The name of this Call object came = from the OIF UNI 1.0 IA) The identification of the egress point in a carriers network to which = an SPC is to be delivered is also a Call attribute, not a connection = attribute -- it is independent of how a customer's service request is realized acrossed a service provider's network. However, the ERO is an attribute = of a connection, not a call, and may not necessarily be passed over the = E-NNI reference point. Consequently, the use of explicit label control in an = ERO is not a possible way to handle SPCs that traverse an E-NNI. This is = why the egress point identification appears in the call object in G.7713.2. I hope this helps clarify SPC operations in G.7713.2/RFC 3474.=20 Jonathan Sadler=20 yhwkim@etri.re.kr wrote:=20 Hi,=20 In my understanding, for the support of SPC connection, SPC_LABEL = (Type=3D4, Sub-type=3D2)=20 subobject seems to be included in GENERALIZED_UNI object.=20 If my understanding is correct, I think there is a big ifference = between concept of SPC connection and GENERALIZED_UNI object. SPC connection is = NNI portion, not UNI. As it is, GENERALIZED_UNI object describes originating and terminating = UNI aspects between client and network nodes.=20 >From logical view-point, in addition, the difference between switched connection (SC) and soft permanent connection (SPC) is where call and connection initiation is. In case of SC the initiation is of client = node, but in case of SPC the initiation is of network node (of course, = triggered by NMS). As a result, I think that GENERALIZED_UNI object and SPC connection could not be indicated by using the object, called GENERALIZED_UNI object because these are completely different by = nature. What do you think of my opinion?=20 Thanks,=20 Young=20 ¿øº» ³»¿ë:=20 º¸³½»ç¶÷: Adrian Farrel[adrian@olddog.co.uk]=20 ¹Þ´Â»ç¶÷: Ong, Lyndon=20 ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org=20 Á¦¸ñ: spc connections=20 ¹ÞÀº³¯Â¥: 2003/11/13 ¸ñ 06:57=20 =20 Lyndon,=20 Thank you for raising this. There is certainly a lack of clarity in = 3473 in this regard,=20 which is perhaps unfortunate.=20 In the earlier versions of the GMPLS work, this was made very explicit (sic) because=20 egress label control was invented before it was generalized to explicit label.=20 There is some reference to this in RFC3471 (of course, the function was originally=20 independent of signaling protocol), but no explicit procedures.=20 This descriptive deficiency has been addressed in draft-ccamp-gmpls- overlay. There is no=20 change in protocol to enable this function, merely a description of how = it all works.=20 Hope this helps.=20 Cheers,=20 Adrian=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Hi Adrian,=20 A couple of times now it's been suggested that Explicit Label Control = is a way to=20 do SPC connections instead of the SPC_Label sub-object. I'm wondering = if=20 people have a different model of SPC connections in mind. The = procedures in=20 RFC 3473 for Explicit Label Control are as follows:=20 [when a label sub-object is present] If the U-bit of the=20 subobject being examined is clear (0), then value of the label is=20 copied into a new Label_Set object. This Label_Set object MUST be=20 included on the corresponding outgoing Path message.=20 If the U-bit of the subobject being examined is set (1), then value=20 of the label is label to be used for upstream traffic associated = with=20 the bidirectional LSP.=20 Neither of these would seem to help you for SPC, since there is no = outgoing PATH=20 message at the network endpoint, the endpoint call control is handled = by=20 the management system and not using a UNI or overlay interface (at = least=20 as defined in G.8080).=20 Explicit Label Control seems like it would help you control the label assignment=20 within the signaled portion of a connection.=20 Cheers,=20 Lyndon=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The information contained in this message may be privileged=20 and confidential and protected from disclosure. If the=20 reader of this message is not the intended recipient, or an=20 employee or agent responsible for delivering this message to=20 the intended recipient, you are hereby notified that any=20 reproduction, dissemination or distribution of this=20 communication is strictly prohibited. If you have received=20 this communication in error, please notify us immediately by=20 replying to the message and deleting it from your computer.=20 Thank you.=20 Tellabs=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 ------_=_NextPart_001_01C3AAC6.8B5B0330 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections
 
-----Original Message-----
From: yhwkim@etri.re.kr = [mailto:yhwkim@etri.re.kr]
Sent: Friday, November 14, 2003 = 7:18=20 AM
To: jonathan.sadler@tellabs.com; = yhwkim@etri.re.kr
Cc:=20 adrian@olddog.co.uk; LyOng@ciena.com; kireeti@juniper.net;=20 ccamp@ops.ietf.org
Subject: [????] Re: [ = AuA=A8=F9E=A2=AC=A8=F6A ] spc=20 connections

Hi,

I reviewed OIF E-NNI 1.0 document(oif2003.179.00) = that=20 includes the definition of SPC_Label.
The = following=20 description shows the definition of the SPC_Label.

"This attribute represents the SNP used at the = destination=20 network-to-user connection. The SPC SNP ID is locally unique to the=20 destination end and provided to the control plane by an external = agent (e.g.,=20 the management system that initiated the SPC connection request). = Note that in=20 the case of the SPC connection, both source and destination = user-to-network=20 connections are provisioned. As such, when setting up a network = switched=20 connection to support the SPC service, the destination SNP associated = with the=20 provisioned connection needs to be specified to allow the control = plane to=20 connect the switched connection to the destination portion of the = provisioned=20 connection." 

 

JD:  = Interestingly enough,=20 I don't see the word 'call' once in the above quote.  I do see = the word=20 'connection' quite a few times, though.

 

After reading this clause, I bacame to understand = the reason=20 that "Generalized_UNI" object included the SPC_Label subobject. Like = the=20 definition above, SPC_Label shows the provisioned connection label = over UNI=20 portion, not NNI portion.

As such, I think it is right for "Generalized_UNI"=20 object  to include the SPC_Label subobject. In addition, by = using this=20 subobject and other information(maybe, ERO etc), the destination = egress=20 network node could idntify itself to be the last network node and not = to=20 invoke connection establishment over UNI interface.

I hope this email conclude the discussion of SPC=20 connections.
And, I'd like to know which WG = rfc3476 is=20 an output from because I think it is not a output of ccamp WG. =

Thanks,
Young =




=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: Jonathan = Sadler[jonathan.sadler@tellabs.com]=20
=B9=DE=B4=C2=BB=E7=B6=F7: yhwkim@etri.re.kr =
=C2=FC=C1=B6:adrian@olddog.co.uk; LyOng@ciena.com; = kireeti@juniper.net;=20 ccamp@ops.ietf.org
=C1=A6=B8=F1: Re: [ = AuA=A8=F9E=A2=AC=A8=F6A ] spc=20 connections
=B9=DE=C0=BA=B3=AF=C2=A5: = 2003/11/14 =B1=DD 00:31

Hi Young -
While the name = of the=20 "GENERALIZED_UNI" object seems to refer to the UNI reference point, = the=20 purpose of the object is to carry attributes of a call.  G.8080 = states=20 that SPCs still use Network Call Controllers (NCCs) in the process of = setting=20 up the SPC.  Consequently, a call exists even for SPCs.  = Therefore,=20 carrying attributes of a call is independent of whether the call was = requested=20 across a UNI or from a management system (ie. an SPC). I agree that = the name=20 of the object is somewhat misleading, but it comes from the fact that = G.7713.2=20 attempted to reuse existing RSVP extensions as much as = possible.  (The=20 name of this Call object came from the OIF UNI 1.0 IA)

The identification of the egress point in a = carriers network=20 to which an SPC is to be delivered is also a Call attribute, not a = connection=20 attribute -- it is independent of how a customer's service request is = realized=20 acrossed a service provider's network. However, the ERO is an = attribute of a=20 connection, not a call, and may not necessarily be passed over the = E-NNI=20 reference point.  Consequently, the use of explicit label = control in an=20 ERO is not a possible way to handle SPCs that traverse an = E-NNI.  This is=20 why the egress point identification appears in the call object in=20 G.7713.2.

I hope this helps clarify SPC operations in = G.7713.2/RFC=20 3474.
Jonathan Sadler
yhwkim@etri.re.kr wrote:
Hi,
In my understanding, for the support of SPC connection, = SPC_LABEL=20 (Type=3D4, Sub-type=3D2)
subobject seems to = be included in=20 GENERALIZED_UNI object.
If my understanding = is=20 correct, I think there is a big ifference between concept of SPC = connection=20 and GENERALIZED_UNI object. SPC connection is NNI portion, not = UNI.

As it is, GENERALIZED_UNI object describes = originating and=20 terminating UNI aspects between client and network nodes. =
From logical view-point, in addition, the difference between = switched=20 connection (SC) and soft permanent connection (SPC) is where call and = connection initiation is. In case of SC the initiation is of client = node, but=20 in case of SPC the initiation is of network node (of course, = triggered by=20 NMS). As a result, I think that GENERALIZED_UNI object and SPC = connection=20 could not be indicated by using the object, called GENERALIZED_UNI = object=20 because these are completely different by nature.

What do you think of my opinion?
Thanks,
Young
&iquest;&oslash;&ordm;&raquo;=20 &sup3;&raquo;&iquest;&euml;:
&ordm;&cedil;&sup3;&frac12;&raquo;&cced= il;&para;&divide;:=20 Adrian Farrel[adrian@olddog.co.uk]
&sup1;&THORN;&acute;&Acirc;&raquo;&cced= il;&para;&divide;:=20 Ong, Lyndon
&Acirc;&uuml;&Aacute;&para;:'Kireeti = Kompella';=20 ccamp@ops.ietf.org
&Aacute;&brvbar;&cedil;&ntilde;: spc = connections=20
&sup1;&THORN;&Agrave;&ordm;&sup3;&macr;= &Acirc;&yen;:=20 2003/11/13 &cedil;&ntilde; 06:57
 =20
Lyndon,
Thank you for = raising this.=20 There is certainly a lack of clarity in 3473 in this regard, =
which is perhaps unfortunate.
In = the earlier=20 versions of the GMPLS work, this was made very explicit (sic) because =
egress label control was invented before it = was=20 generalized to explicit label.
There is = some reference=20 to this in RFC3471 (of course, the function was originally =
independent of signaling protocol), but no explicit = procedures.=20
This descriptive deficiency has been = addressed in=20 draft-ccamp-gmpls-overlay. There is no
change in=20 protocol to enable this function, merely a description of how it all = works.=20
Hope this helps.
Cheers,=20
Adrian
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Hi Adrian,=20
A couple of times now it's been suggested = that=20 Explicit Label Control is a way to
do SPC = connections=20 instead of the SPC_Label sub-object.  I'm wondering if =
people have a different model of SPC connections in = mind.  The=20 procedures in
RFC 3473 for Explicit Label = Control are=20 as follows:
   [when a label = sub-object is=20 present]  If the U-bit of the
  =20 subobject being examined is clear (0), then value of the label is=20
   copied into a new Label_Set = object. =20 This Label_Set object MUST be
   = included on=20 the corresponding outgoing Path message.
  =20 If the U-bit of the subobject being examined is set (1), then value=20
   of the label is label to be = used for=20 upstream traffic associated with
   the=20 bidirectional LSP.
Neither of these would = seem to help=20 you for SPC, since there is no outgoing PATH
message=20 at the network endpoint, the endpoint call control is handled by=20
the management system and not using a UNI = or overlay=20 interface (at least
as defined in G.8080).=20
Explicit Label Control seems like it would = help you=20 control the label assignment
within the = signaled=20 portion of a connection.
Cheers, =
Lyndon

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
The information contained in this message may be = privileged=20
and confidential and protected from = disclosure. If the=20
reader of this message is not the intended = recipient,=20 or an
employee or agent responsible for = delivering=20 this message to
the intended recipient, you = are hereby=20 notified that any
reproduction, = dissemination or=20 distribution of this
communication is = strictly=20 prohibited. If you have received
this = communication in=20 error, please notify us immediately by
replying to the=20 message and deleting it from your computer.

Thank you.
Tellabs =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

------_=_NextPart_001_01C3AAC6.8B5B0330-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Nov 2003 15:23:14 +0000 Message-ID: <4A0AE1E5A1AAD711AC1B00D0B7C2D4A2447E55@cms1> From: yhwkim@etri.re.kr To: jonathan.sadler@tellabs.com, yhwkim@etri.re.kr Cc: adrian@olddog.co.uk, LyOng@ciena.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: =?euc-kr?B?W8D8w7zIuL3FXSBSZTogWyBBdUGo+UWirKj2QSBdIHNwYyBjb25u?= =?euc-kr?B?ZWN0aW9ucw==?= Date: Sat, 15 Nov 2003 00:17:55 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AAC2.7A757040" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AAC2.7A757040 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Hi, I reviewed OIF E-NNI 1.0 document(oif2003.179.00) that includes the definition of SPC_Label. The following description shows the definition of the SPC_Label. "This attribute represents the SNP used at the destination = network-to-user connection. The SPC SNP ID is locally unique to the destination end and provided to the control plane by an external agent (e.g., the = management system that initiated the SPC connection request). Note that in the = case of the SPC connection, both source and destination user-to-network = connections are provisioned. As such, when setting up a network switched connection = to support the SPC service, the destination SNP associated with the provisioned connection needs to be specified to allow the control plane = to connect the switched connection to the destination portion of the provisioned connection." After reading this clause, I bacame to understand the reason that "Generalized_UNI" object included the SPC_Label subobject. Like the definition above, SPC_Label shows the provisioned connection label over = UNI portion, not NNI portion. As such, I think it is right for "Generalized_UNI" object to include = the SPC_Label subobject. In addition, by using this subobject and other information(maybe, ERO etc), the destination egress network node could idntify itself to be the last network node and not to invoke connection establishment over UNI interface. I hope this email conclude the discussion of SPC connections. And, I'd like to know which WG rfc3476 is an output from because I = think it is not a output of ccamp WG. Thanks, Young =BF=F8=BA=BB =B3=BB=BF=EB: =BA=B8=B3=BD=BB=E7=B6=F7: Jonathan Sadler[jonathan.sadler@tellabs.com] =B9=DE=B4=C2=BB=E7=B6=F7: yhwkim@etri.re.kr =C2=FC=C1=B6:adrian@olddog.co.uk; LyOng@ciena.com; kireeti@juniper.net; ccamp@ops.ietf.org =C1=A6=B8=F1: Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc connections =B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/14 =B1=DD 00:31 Hi Young - While the name of the "GENERALIZED_UNI" object seems to refer to the = UNI reference point, the purpose of the object is to carry attributes of a call. G.8080 states that SPCs still use Network Call Controllers = (NCCs) in the process of setting up the SPC. Consequently, a call exists even = for SPCs. Therefore, carrying attributes of a call is independent of = whether the call was requested across a UNI or from a management system (ie. an SPC). I agree that the name of the object is somewhat misleading, but = it comes from the fact that G.7713.2 attempted to reuse existing RSVP extensions as much as possible. (The name of this Call object came = from the OIF UNI 1.0 IA) The identification of the egress point in a carriers network to which = an SPC is to be delivered is also a Call attribute, not a connection = attribute -- it is independent of how a customer's service request is realized acrossed a service provider's network. However, the ERO is an attribute = of a connection, not a call, and may not necessarily be passed over the = E-NNI reference point. Consequently, the use of explicit label control in an = ERO is not a possible way to handle SPCs that traverse an E-NNI. This is = why the egress point identification appears in the call object in G.7713.2. I hope this helps clarify SPC operations in G.7713.2/RFC 3474. Jonathan Sadler yhwkim@etri.re.kr wrote: Hi, In my understanding, for the support of SPC connection, SPC_LABEL = (Type=3D4, Sub-type=3D2)=20 subobject seems to be included in GENERALIZED_UNI object.=20 If my understanding is correct, I think there is a big ifference = between concept of SPC connection and GENERALIZED_UNI object. SPC connection is = NNI portion, not UNI. As it is, GENERALIZED_UNI object describes originating and terminating = UNI aspects between client and network nodes.=20 >From logical view-point, in addition, the difference between switched connection (SC) and soft permanent connection (SPC) is where call and connection initiation is. In case of SC the initiation is of client = node, but in case of SPC the initiation is of network node (of course, = triggered by NMS). As a result, I think that GENERALIZED_UNI object and SPC connection could not be indicated by using the object, called GENERALIZED_UNI object because these are completely different by = nature. What do you think of my opinion? Thanks,=20 Young ¿øº» ³»¿ë: º¸³½»ç¶÷: Adrian Farrel[adrian@olddog.co.uk]=20 ¹Þ´Â»ç¶÷: Ong, Lyndon=20 ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org=20 Á¦¸ñ: spc connections=20 ¹ÞÀº³¯Â¥: 2003/11/13 ¸ñ 06:57=20 =20 Lyndon,=20 Thank you for raising this. There is certainly a lack of clarity in = 3473 in this regard,=20 which is perhaps unfortunate.=20 In the earlier versions of the GMPLS work, this was made very explicit (sic) because=20 egress label control was invented before it was generalized to explicit label.=20 There is some reference to this in RFC3471 (of course, the function was originally=20 independent of signaling protocol), but no explicit procedures.=20 This descriptive deficiency has been addressed in draft-ccamp-gmpls- overlay. There is no=20 change in protocol to enable this function, merely a description of how = it all works.=20 Hope this helps.=20 Cheers,=20 Adrian=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Hi Adrian,=20 A couple of times now it's been suggested that Explicit Label Control = is a way to=20 do SPC connections instead of the SPC_Label sub-object. I'm wondering = if=20 people have a different model of SPC connections in mind. The = procedures in=20 RFC 3473 for Explicit Label Control are as follows:=20 [when a label sub-object is present] If the U-bit of the=20 subobject being examined is clear (0), then value of the label is=20 copied into a new Label_Set object. This Label_Set object MUST be=20 included on the corresponding outgoing Path message.=20 If the U-bit of the subobject being examined is set (1), then value=20 of the label is label to be used for upstream traffic associated = with=20 the bidirectional LSP.=20 Neither of these would seem to help you for SPC, since there is no = outgoing PATH=20 message at the network endpoint, the endpoint call control is handled = by=20 the management system and not using a UNI or overlay interface (at = least=20 as defined in G.8080).=20 Explicit Label Control seems like it would help you control the label assignment=20 within the signaled portion of a connection. Cheers,=20 Lyndon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged=20 and confidential and protected from disclosure. If the=20 reader of this message is not the intended recipient, or an=20 employee or agent responsible for delivering this message to=20 the intended recipient, you are hereby notified that any=20 reproduction, dissemination or distribution of this=20 communication is strictly prohibited. If you have received=20 this communication in error, please notify us immediately by=20 replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C3AAC2.7A757040 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections

Hi,

I reviewed OIF E-NNI 1.0 document(oif2003.179.00) = that includes the definition of SPC_Label.
The following description shows the definition of = the SPC_Label.

"This attribute represents the SNP used at the = destination network-to-user connection. The SPC SNP ID is locally = unique to the destination end and provided to the control plane by an = external agent (e.g., the management system that initiated the SPC = connection request). Note that in the case of the SPC connection, both = source and destination user-to-network connections are provisioned. As = such, when setting up a network switched connection to support the SPC = service, the destination SNP associated with the provisioned connection = needs to be specified to allow the control plane to connect the = switched connection to the destination portion of the provisioned = connection."

After reading this clause, I bacame to understand the = reason that "Generalized_UNI" object included the SPC_Label = subobject. Like the definition above, SPC_Label shows the provisioned = connection label over UNI portion, not NNI portion.

As such, I think it is right for = "Generalized_UNI" object  to include the SPC_Label = subobject. In addition, by using this subobject and other = information(maybe, ERO etc), the destination egress network node could = idntify itself to be the last network node and not to invoke connection = establishment over UNI interface.

I hope this email conclude the discussion of SPC = connections.
And, I'd like to know which WG rfc3476 is an output = from because I think it is not a output of ccamp WG.

Thanks,
Young




=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: Jonathan = Sadler[jonathan.sadler@tellabs.com]
=B9=DE=B4=C2=BB=E7=B6=F7: yhwkim@etri.re.kr
=C2=FC=C1=B6:adrian@olddog.co.uk; LyOng@ciena.com; = kireeti@juniper.net; ccamp@ops.ietf.org
=C1=A6=B8=F1: Re: [ AuA=A8=F9E=A2=AC=A8=F6A ] spc = connections
=B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/14 =B1=DD = 00:31

Hi Young -
While the name of the "GENERALIZED_UNI" = object seems to refer to the UNI reference point, the purpose of the = object is to carry attributes of a call.  G.8080 states that SPCs = still use Network Call Controllers (NCCs) in the process of setting up = the SPC.  Consequently, a call exists even for SPCs.  = Therefore, carrying attributes of a call is independent of whether the = call was requested across a UNI or from a management system (ie. an = SPC). I agree that the name of the object is somewhat misleading, but = it comes from the fact that G.7713.2 attempted to reuse existing RSVP = extensions as much as possible.  (The name of this Call object = came from the OIF UNI 1.0 IA)

The identification of the egress point in a carriers = network to which an SPC is to be delivered is also a Call attribute, = not a connection attribute -- it is independent of how a customer's = service request is realized acrossed a service provider's network. = However, the ERO is an attribute of a connection, not a call, and may = not necessarily be passed over the E-NNI reference point.  = Consequently, the use of explicit label control in an ERO is not a = possible way to handle SPCs that traverse an E-NNI.  This is why = the egress point identification appears in the call object in = G.7713.2.

I hope this helps clarify SPC operations in = G.7713.2/RFC 3474.
Jonathan Sadler
yhwkim@etri.re.kr wrote:
Hi,
In my understanding, for the support of SPC = connection, SPC_LABEL (Type=3D4, Sub-type=3D2)
subobject seems to be included in GENERALIZED_UNI = object.
If my understanding is correct, I think there is a = big ifference between concept of SPC connection and GENERALIZED_UNI = object. SPC connection is NNI portion, not UNI.

As it is, GENERALIZED_UNI object describes = originating and terminating UNI aspects between client and network = nodes.
From logical view-point, in addition, the difference = between switched connection (SC) and soft permanent connection (SPC) is = where call and connection initiation is. In case of SC the initiation = is of client node, but in case of SPC the initiation is of network node = (of course, triggered by NMS). As a result, I think that = GENERALIZED_UNI object and SPC connection could not be indicated by = using the object, called GENERALIZED_UNI object because these are = completely different by nature.

What do you think of my opinion?
Thanks,
Young
&iquest;&oslash;&ordm;&raquo; = &sup3;&raquo;&iquest;&euml;:
&ordm;&cedil;&sup3;&frac12;&raquo;&cced= il;&para;&divide;: Adrian Farrel[adrian@olddog.co.uk]
&sup1;&THORN;&acute;&Acirc;&raquo;&cced= il;&para;&divide;: Ong, Lyndon
&Acirc;&uuml;&Aacute;&para;:'Kireeti = Kompella'; ccamp@ops.ietf.org
&Aacute;&brvbar;&cedil;&ntilde;: spc = connections
&sup1;&THORN;&Agrave;&ordm;&sup3;&macr;= &Acirc;&yen;: 2003/11/13 &cedil;&ntilde; 06:57
 
Lyndon,
Thank you for raising this. There is certainly a = lack of clarity in 3473 in this regard,
which is perhaps unfortunate.
In the earlier versions of the GMPLS work, this was = made very explicit (sic) because
egress label control was invented before it was = generalized to explicit label.
There is some reference to this in RFC3471 (of = course, the function was originally
independent of signaling protocol), but no explicit = procedures.
This descriptive deficiency has been addressed in = draft-ccamp-gmpls-overlay. There is no
change in protocol to enable this function, merely a = description of how it all works.
Hope this helps.
Cheers,
Adrian
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Hi Adrian,
A couple of times now it's been suggested that = Explicit Label Control is a way to
do SPC connections instead of the SPC_Label = sub-object.  I'm wondering if
people have a different model of SPC connections in = mind.  The procedures in
RFC 3473 for Explicit Label Control are as follows: =
   [when a label sub-object is = present]  If the U-bit of the
   subobject being examined is clear (0), = then value of the label is
   copied into a new Label_Set = object.  This Label_Set object MUST be
   included on the corresponding outgoing = Path message.
   If the U-bit of the subobject being = examined is set (1), then value
   of the label is label to be used for = upstream traffic associated with
   the bidirectional LSP.
Neither of these would seem to help you for SPC, = since there is no outgoing PATH
message at the network endpoint, the endpoint call = control is handled by
the management system and not using a UNI or overlay = interface (at least
as defined in G.8080).
Explicit Label Control seems like it would help you = control the label assignment
within the signaled portion of a connection.
Cheers,
Lyndon

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be = privileged
and confidential and protected from disclosure. If = the
reader of this message is not the intended = recipient, or an
employee or agent responsible for delivering this = message to
the intended recipient, you are hereby notified that = any
reproduction, dissemination or distribution of this =
communication is strictly prohibited. If you have = received
this communication in error, please notify us = immediately by
replying to the message and deleting it from your = computer.

Thank you.
Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C3AAC2.7A757040-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Nov 2003 20:02:39 +0000 Subject: Re: [ =?iso-8859-1?Q?=C0=FC=C3=BC=C8=B8=BD=C5?= ] spc connections To: jonathan.sadler@tellabs.com (Jonathan Sadler) Date: Thu, 13 Nov 2003 20:01:54 +0000 (GMT) Cc: yhwkim@etri.re.kr, adrian@olddog.co.uk, LyOng@ciena.com, kireeti@juniper.net, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=DISPLAY Content-Transfer-Encoding: 8bit Message-Id: From: Dimitri Papadimitriou jonathan, clarification inline... > Dimitri - > > Response inline... > > Jonathan Sadler > > Dimitri Papadimitriou wrote: > > > reading your mail, the following came to my mind: > > > > - does it mean that G.7713.2/RFC 3474 requires to setup > > a call when (or before) establishing an SPC ? > > G.8080 requires that a call be established for SPCs (soft permanent connections) as well as SC (switched connections). G.7713 and G.7713.2 follow this requirement. i'll clarify, i was referring to supporting simply being able to set up a spc without a call and the capability to support a call with no connections for which one or more spc and/or sc's are associated subsequently > > - G.7713.2/RFC 3474 can not support inter-as *te* ? > > I'm not certain how to parse your question -- could you please clarify? adrian's mail clarifies this, thanks, - dimitri. > > thanks, > > - dimitri. > > > > > --------------1FF6DF901322C8C0DC51EC75 > > > Content-Type: text/plain; > > > charset="iso-8859-1" > > > Content-Transfer-Encoding: 8bit > > > > > > Hi Young - > > > > > > While the name of the "GENERALIZED_UNI" object seems to refer to the UNI > > > reference point, the purpose of the object is to carry attributes of a > > > call. G.8080 states that SPCs still use Network Call Controllers (NCCs) > > > in the process of setting up the SPC. Consequently, a call exists even > > > for SPCs. Therefore, carrying attributes of a call is independent of > > > whether the call was requested across a UNI or from a management system > > > (ie. an SPC). I agree that the name of the object is somewhat > > > misleading, but it comes from the fact that G.7713.2 attempted to reuse > > > existing RSVP extensions as much as possible. (The name of this Call > > > object came from the OIF UNI 1.0 IA) > > > > > > The identification of the egress point in a carriers network to which an > > > SPC is to be delivered is also a Call attribute, not a connection > > > attribute -- it is independent of how a customer's service request is > > > realized acrossed a service provider's network. However, the ERO is an > > > attribute of a connection, not a call, and may not necessarily be passed > > > over the E-NNI reference point. Consequently, the use of explicit label > > > control in an ERO is not a possible way to handle SPCs that traverse an > > > E-NNI. This is why the egress point identification appears in the call > > > object in G.7713.2. > > > > > > I hope this helps clarify SPC operations in G.7713.2/RFC 3474. > > > > > > Jonathan Sadler > > > > > > yhwkim@etri.re.kr wrote: > > > > > > > Hi, > > > > > > > > In my understanding, for the support of SPC connection, SPC_LABEL > > > > (Type=4, Sub-type=2) > > > > subobject seems to be included in GENERALIZED_UNI object. > > > > If my understanding is correct, I think there is a big ifference > > > > between concept of SPC connection and GENERALIZED_UNI object. SPC > > > > connection is NNI portion, not UNI. > > > > > > > > As it is, GENERALIZED_UNI object describes originating and terminating > > > > UNI aspects between client and network nodes. > > > > From logical view-point, in addition, the difference between switched > > > > connection (SC) and soft permanent connection (SPC) is where call and > > > > connection initiation is. In case of SC the initiation is of client > > > > node, but in case of SPC the initiation is of network node (of course, > > > > triggered by NMS). As a result, I think that GENERALIZED_UNI object > > > > and SPC connection could not be indicated by using the object, called > > > > GENERALIZED_UNI object because these are completely different by > > > > nature. > > > > > > > > What do you think of my opinion? > > > > > > > > Thanks, > > > > Young > > > > > > > > ¿øº» ³»¿ë: > > > > > > > > º¸³½»ç¶÷: Adrian Farrel[adrian@olddog.co.uk] > > > > ¹Þ´Â»ç¶÷: Ong, Lyndon > > > > ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org > > > > Á¦¸ñ: spc connections > > > > ¹ÞÀº³¯Â¥: 2003/11/13 ¸ñ 06:57 > > > > > > > > > > > > Lyndon, > > > > Thank you for raising this. There is certainly a lack of clarity in > > > > 3473 in this regard, > > > > which is perhaps unfortunate. > > > > In the earlier versions of the GMPLS work, this was made very explicit > > > > (sic) because > > > > egress label control was invented before it was generalized to > > > > explicit label. > > > > There is some reference to this in RFC3471 (of course, the function > > > > was originally > > > > independent of signaling protocol), but no explicit procedures. > > > > This descriptive deficiency has been addressed in > > > > draft-ccamp-gmpls-overlay. There is no > > > > change in protocol to enable this function, merely a description of > > > > how it all works. > > > > Hope this helps. > > > > Cheers, > > > > Adrian > > > > ===================== > > > > > > > > Hi Adrian, > > > > A couple of times now it's been suggested that Explicit Label Control > > > > is a way to > > > > do SPC connections instead of the SPC_Label sub-object. I'm wondering > > > > if > > > > people have a different model of SPC connections in mind. The > > > > procedures in > > > > RFC 3473 for Explicit Label Control are as follows: > > > > [when a label sub-object is present] If the U-bit of the > > > > subobject being examined is clear (0), then value of the label is > > > > copied into a new Label_Set object. This Label_Set object MUST be > > > > included on the corresponding outgoing Path message. > > > > If the U-bit of the subobject being examined is set (1), then value > > > > > > > > of the label is label to be used for upstream traffic associated > > > > with > > > > the bidirectional LSP. > > > > Neither of these would seem to help you for SPC, since there is no > > > > outgoing PATH > > > > message at the network endpoint, the endpoint call control is handled > > > > by > > > > the management system and not using a UNI or overlay interface (at > > > > least > > > > as defined in G.8080). > > > > Explicit Label Control seems like it would help you control the label > > > > assignment > > > > within the signaled portion of a connection. > > > > > > > > Cheers, > > > > Lyndon > > > > > > > > > > > > ----------------------------------------- > > > ============================================================ > > > The information contained in this message may be privileged > > > and confidential and protected from disclosure. If the > > > reader of this message is not the intended recipient, or an > > > employee or agent responsible for delivering this message to > > > the intended recipient, you are hereby notified that any > > > reproduction, dissemination or distribution of this > > > communication is strictly prohibited. If you have received > > > this communication in error, please notify us immediately by > > > replying to the message and deleting it from your computer. > > > > > > Thank you. > > > Tellabs > > > ============================================================ > > > --------------1FF6DF901322C8C0DC51EC75 > > > Content-Type: text/html; > > > charset="us-ascii" > > > Content-Transfer-Encoding: 7bit > > > > > > > > > > > > Hi Young - > > >

While the name of the "GENERALIZED_UNI" object seems to refer to the > > > UNI reference point, the purpose of the object is to carry attributes of > > > a call.  G.8080 states that SPCs still use Network Call Controllers > > > (NCCs) in the process of setting up the SPC.  Consequently, a call > > > exists even for SPCs.  Therefore, carrying attributes of a call is > > > independent of whether the call was requested across a UNI or from a management > > > system (ie. an SPC). I agree that the name of the object is somewhat misleading, > > > but it comes from the fact that G.7713.2 attempted to reuse existing RSVP > > > extensions as much as possible.  (The name of this Call object came > > > from the OIF UNI 1.0 IA) > > >

The identification of the egress point in a carriers network to which > > > an SPC is to be delivered is also a Call attribute, not a connection attribute > > > -- it is independent of how a customer's service request is realized acrossed > > > a service provider's network. However, the ERO is an attribute of a connection, > > > not a call, and may not necessarily be passed over the E-NNI reference > > > point.  Consequently, the use of explicit label control in an ERO > > > is not a possible way to handle SPCs that traverse an E-NNI.  This > > > is why the egress point identification appears in the call object in G.7713.2. > > >

I hope this helps clarify SPC operations in G.7713.2/RFC 3474. > > >

Jonathan Sadler > > >

yhwkim@etri.re.kr wrote: > > >

Hi, > > >

In my understanding, for the support of SPC connection, > > > SPC_LABEL (Type=4, Sub-type=2) > > >
subobject seems to be included in GENERALIZED_UNI object. > > >
If my understanding is correct, I think there is a big > > > ifference between concept of SPC connection and GENERALIZED_UNI object. > > > SPC connection is NNI portion, not UNI. > > >

As it is, GENERALIZED_UNI object describes originating > > > and terminating UNI aspects between client and network nodes. > > >
From logical view-point, in addition, the difference > > > between switched connection (SC) and soft permanent connection (SPC) is > > > where call and connection initiation is. In case of SC the initiation is > > > of client node, but in case of SPC the initiation is of network node (of > > > course, triggered by NMS). As a result, I think that GENERALIZED_UNI object > > > and SPC connection could not be indicated by using the object, called GENERALIZED_UNI > > > object because these are completely different by nature. > > >

What do you think of my opinion? > > >

Thanks, > > >
Young > > >

¿øº» ³»¿ë: > > >

º¸³½»ç¶÷: > > > Adrian Farrel[adrian@olddog.co.uk] > > >
¹Þ´Â»ç¶÷: > > > Ong, Lyndon > > >
ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org > > >
Á¦¸ñ: spc connections > > >
¹ÞÀº³¯Â¥: > > > 2003/11/13 ¸ñ 06:57 > > >
  > > >

Lyndon, > > >
Thank you for raising this. There is certainly a lack > > > of clarity in 3473 in this regard, > > >
which is perhaps unfortunate. > > >
In the earlier versions of the GMPLS work, this was made > > > very explicit (sic) because > > >
egress label control was invented before it was generalized > > > to explicit label. > > >
There is some reference to this in RFC3471 (of course, > > > the function was originally > > >
independent of signaling protocol), but no explicit procedures. > > >
This descriptive deficiency has been addressed in draft-ccamp-gmpls-overlay. > > > There is no > > >
change in protocol to enable this function, merely a > > > description of how it all works. > > >
Hope this helps. > > >
Cheers, > > >
Adrian > > >
===================== > > >

Hi Adrian, > > >
A couple of times now it's been suggested that Explicit > > > Label Control is a way to > > >
do SPC connections instead of the SPC_Label sub-object.  > > > I'm wondering if > > >
people have a different model of SPC connections in mind.  > > > The procedures in > > >
RFC 3473 for Explicit Label Control are as follows: > > >
   [when a label sub-object is present]  > > > If the U-bit of the > > >
   subobject being examined is clear (0), then > > > value of the label is > > >
   copied into a new Label_Set object.  > > > This Label_Set object MUST be > > >
   included on the corresponding outgoing Path > > > message. > > >
   If the U-bit of the subobject being examined > > > is set (1), then value > > >
   of the label is label to be used for upstream > > > traffic associated with > > >
   the bidirectional LSP. > > >
Neither of these would seem to help you for SPC, since > > > there is no outgoing PATH > > >
message at the network endpoint, the endpoint call control > > > is handled by > > >
the management system and not using a UNI or overlay > > > interface (at least > > >
as defined in G.8080). > > >
Explicit Label Control seems like it would help you control > > > the label assignment > > >
within the signaled portion of a connection. > > >

Cheers, > > >
Lyndon

> > > > > > > > >

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

> > > --------------1FF6DF901322C8C0DC51EC75-- > > > > > > > > > > > > ----------------------------------------- > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Nov 2003 19:45:54 +0000 Message-ID: <001601c3aa1e$a215bbe0$db818182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Jonathan Sadler" Cc: , "Dimitri Papadimitriou" Subject: =?iso-8859-1?B?UmU6IFsgwPzDvMi4vcUgXSBzcGMgY29ubmVjdGlvbnM=?= Date: Thu, 13 Nov 2003 19:44:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jonathan, Thanks for helping to nail down these requirement issues. > > - G.7713.2/RFC 3474 can not support inter-as *te* ? > I'm not certain how to parse your question -- could you please clarify? On the subject of inter-AS TE, I think Dimitri is thinking as follows... You said: > > > realized acrossed a service provider's network. However, the ERO is an > > > attribute of a connection, not a call, and may not necessarily be passed > > > over the E-NNI reference point. Consequently, the use of explicit label > > > control in an ERO is not a possible way to handle SPCs that traverse an > > > E-NNI. This is why the egress point identification appears in the call > > > object in G.7713.2. Inter-AS, head-end-controlled TE requires that the ERO may include some information to help control the path on the other side of the E-NNI (if we assume that the E-NNI lies on an AS boundary). Your statement that the ERO "may not necessarily be passed over the E-NNI" suggests that this form of TE cannot be applied. I wonder if you could clarify "may not necessarily". What are the constraints? Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Nov 2003 19:29:54 +0000 Message-ID: <3FB3DAA2.37173A71@tellabs.com> Date: Thu, 13 Nov 2003 13:25:22 -0600 From: Jonathan Sadler MIME-Version: 1.0 To: Dimitri Papadimitriou CC: yhwkim@etri.re.kr, adrian@olddog.co.uk, LyOng@ciena.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: [ =?iso-8859-1?Q?=C0=FC=C3=BC=C8=B8=BD=C5?= ] spc connections Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Dimitri - Response inline... Jonathan Sadler Dimitri Papadimitriou wrote: > reading your mail, the following came to my mind: > > - does it mean that G.7713.2/RFC 3474 requires to setup > a call when (or before) establishing an SPC ? G.8080 requires that a call be established for SPCs (soft permanent connections) as well as SC (switched connections). G.7713 and G.7713.2 follow this requirement. > - G.7713.2/RFC 3474 can not support inter-as *te* ? I'm not certain how to parse your question -- could you please clarify? > thanks, > - dimitri. > > > --------------1FF6DF901322C8C0DC51EC75 > > Content-Type: text/plain; > > charset="iso-8859-1" > > Content-Transfer-Encoding: 8bit > > > > Hi Young - > > > > While the name of the "GENERALIZED_UNI" object seems to refer to the UNI > > reference point, the purpose of the object is to carry attributes of a > > call. G.8080 states that SPCs still use Network Call Controllers (NCCs) > > in the process of setting up the SPC. Consequently, a call exists even > > for SPCs. Therefore, carrying attributes of a call is independent of > > whether the call was requested across a UNI or from a management system > > (ie. an SPC). I agree that the name of the object is somewhat > > misleading, but it comes from the fact that G.7713.2 attempted to reuse > > existing RSVP extensions as much as possible. (The name of this Call > > object came from the OIF UNI 1.0 IA) > > > > The identification of the egress point in a carriers network to which an > > SPC is to be delivered is also a Call attribute, not a connection > > attribute -- it is independent of how a customer's service request is > > realized acrossed a service provider's network. However, the ERO is an > > attribute of a connection, not a call, and may not necessarily be passed > > over the E-NNI reference point. Consequently, the use of explicit label > > control in an ERO is not a possible way to handle SPCs that traverse an > > E-NNI. This is why the egress point identification appears in the call > > object in G.7713.2. > > > > I hope this helps clarify SPC operations in G.7713.2/RFC 3474. > > > > Jonathan Sadler > > > > yhwkim@etri.re.kr wrote: > > > > > Hi, > > > > > > In my understanding, for the support of SPC connection, SPC_LABEL > > > (Type=4, Sub-type=2) > > > subobject seems to be included in GENERALIZED_UNI object. > > > If my understanding is correct, I think there is a big ifference > > > between concept of SPC connection and GENERALIZED_UNI object. SPC > > > connection is NNI portion, not UNI. > > > > > > As it is, GENERALIZED_UNI object describes originating and terminating > > > UNI aspects between client and network nodes. > > > From logical view-point, in addition, the difference between switched > > > connection (SC) and soft permanent connection (SPC) is where call and > > > connection initiation is. In case of SC the initiation is of client > > > node, but in case of SPC the initiation is of network node (of course, > > > triggered by NMS). As a result, I think that GENERALIZED_UNI object > > > and SPC connection could not be indicated by using the object, called > > > GENERALIZED_UNI object because these are completely different by > > > nature. > > > > > > What do you think of my opinion? > > > > > > Thanks, > > > Young > > > > > > ¿øº» ³»¿ë: > > > > > > º¸³½»ç¶÷: Adrian Farrel[adrian@olddog.co.uk] > > > ¹Þ´Â»ç¶÷: Ong, Lyndon > > > ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org > > > Á¦¸ñ: spc connections > > > ¹ÞÀº³¯Â¥: 2003/11/13 ¸ñ 06:57 > > > > > > > > > Lyndon, > > > Thank you for raising this. There is certainly a lack of clarity in > > > 3473 in this regard, > > > which is perhaps unfortunate. > > > In the earlier versions of the GMPLS work, this was made very explicit > > > (sic) because > > > egress label control was invented before it was generalized to > > > explicit label. > > > There is some reference to this in RFC3471 (of course, the function > > > was originally > > > independent of signaling protocol), but no explicit procedures. > > > This descriptive deficiency has been addressed in > > > draft-ccamp-gmpls-overlay. There is no > > > change in protocol to enable this function, merely a description of > > > how it all works. > > > Hope this helps. > > > Cheers, > > > Adrian > > > ===================== > > > > > > Hi Adrian, > > > A couple of times now it's been suggested that Explicit Label Control > > > is a way to > > > do SPC connections instead of the SPC_Label sub-object. I'm wondering > > > if > > > people have a different model of SPC connections in mind. The > > > procedures in > > > RFC 3473 for Explicit Label Control are as follows: > > > [when a label sub-object is present] If the U-bit of the > > > subobject being examined is clear (0), then value of the label is > > > copied into a new Label_Set object. This Label_Set object MUST be > > > included on the corresponding outgoing Path message. > > > If the U-bit of the subobject being examined is set (1), then value > > > > > > of the label is label to be used for upstream traffic associated > > > with > > > the bidirectional LSP. > > > Neither of these would seem to help you for SPC, since there is no > > > outgoing PATH > > > message at the network endpoint, the endpoint call control is handled > > > by > > > the management system and not using a UNI or overlay interface (at > > > least > > > as defined in G.8080). > > > Explicit Label Control seems like it would help you control the label > > > assignment > > > within the signaled portion of a connection. > > > > > > Cheers, > > > Lyndon > > > > > > > > ----------------------------------------- > > ============================================================ > > The information contained in this message may be privileged > > and confidential and protected from disclosure. If the > > reader of this message is not the intended recipient, or an > > employee or agent responsible for delivering this message to > > the intended recipient, you are hereby notified that any > > reproduction, dissemination or distribution of this > > communication is strictly prohibited. If you have received > > this communication in error, please notify us immediately by > > replying to the message and deleting it from your computer. > > > > Thank you. > > Tellabs > > ============================================================ > > --------------1FF6DF901322C8C0DC51EC75 > > Content-Type: text/html; > > charset="us-ascii" > > Content-Transfer-Encoding: 7bit > > > > > > > > Hi Young - > >

While the name of the "GENERALIZED_UNI" object seems to refer to the > > UNI reference point, the purpose of the object is to carry attributes of > > a call.  G.8080 states that SPCs still use Network Call Controllers > > (NCCs) in the process of setting up the SPC.  Consequently, a call > > exists even for SPCs.  Therefore, carrying attributes of a call is > > independent of whether the call was requested across a UNI or from a management > > system (ie. an SPC). I agree that the name of the object is somewhat misleading, > > but it comes from the fact that G.7713.2 attempted to reuse existing RSVP > > extensions as much as possible.  (The name of this Call object came > > from the OIF UNI 1.0 IA) > >

The identification of the egress point in a carriers network to which > > an SPC is to be delivered is also a Call attribute, not a connection attribute > > -- it is independent of how a customer's service request is realized acrossed > > a service provider's network. However, the ERO is an attribute of a connection, > > not a call, and may not necessarily be passed over the E-NNI reference > > point.  Consequently, the use of explicit label control in an ERO > > is not a possible way to handle SPCs that traverse an E-NNI.  This > > is why the egress point identification appears in the call object in G.7713.2. > >

I hope this helps clarify SPC operations in G.7713.2/RFC 3474. > >

Jonathan Sadler > >

yhwkim@etri.re.kr wrote: > >

Hi, > >

In my understanding, for the support of SPC connection, > > SPC_LABEL (Type=4, Sub-type=2) > >
subobject seems to be included in GENERALIZED_UNI object. > >
If my understanding is correct, I think there is a big > > ifference between concept of SPC connection and GENERALIZED_UNI object. > > SPC connection is NNI portion, not UNI. > >

As it is, GENERALIZED_UNI object describes originating > > and terminating UNI aspects between client and network nodes. > >
From logical view-point, in addition, the difference > > between switched connection (SC) and soft permanent connection (SPC) is > > where call and connection initiation is. In case of SC the initiation is > > of client node, but in case of SPC the initiation is of network node (of > > course, triggered by NMS). As a result, I think that GENERALIZED_UNI object > > and SPC connection could not be indicated by using the object, called GENERALIZED_UNI > > object because these are completely different by nature. > >

What do you think of my opinion? > >

Thanks, > >
Young > >

¿øº» ³»¿ë: > >

º¸³½»ç¶÷: > > Adrian Farrel[adrian@olddog.co.uk] > >
¹Þ´Â»ç¶÷: > > Ong, Lyndon > >
ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org > >
Á¦¸ñ: spc connections > >
¹ÞÀº³¯Â¥: > > 2003/11/13 ¸ñ 06:57 > >
  > >

Lyndon, > >
Thank you for raising this. There is certainly a lack > > of clarity in 3473 in this regard, > >
which is perhaps unfortunate. > >
In the earlier versions of the GMPLS work, this was made > > very explicit (sic) because > >
egress label control was invented before it was generalized > > to explicit label. > >
There is some reference to this in RFC3471 (of course, > > the function was originally > >
independent of signaling protocol), but no explicit procedures. > >
This descriptive deficiency has been addressed in draft-ccamp-gmpls-overlay. > > There is no > >
change in protocol to enable this function, merely a > > description of how it all works. > >
Hope this helps. > >
Cheers, > >
Adrian > >
===================== > >

Hi Adrian, > >
A couple of times now it's been suggested that Explicit > > Label Control is a way to > >
do SPC connections instead of the SPC_Label sub-object.  > > I'm wondering if > >
people have a different model of SPC connections in mind.  > > The procedures in > >
RFC 3473 for Explicit Label Control are as follows: > >
   [when a label sub-object is present]  > > If the U-bit of the > >
   subobject being examined is clear (0), then > > value of the label is > >
   copied into a new Label_Set object.  > > This Label_Set object MUST be > >
   included on the corresponding outgoing Path > > message. > >
   If the U-bit of the subobject being examined > > is set (1), then value > >
   of the label is label to be used for upstream > > traffic associated with > >
   the bidirectional LSP. > >
Neither of these would seem to help you for SPC, since > > there is no outgoing PATH > >
message at the network endpoint, the endpoint call control > > is handled by > >
the management system and not using a UNI or overlay > > interface (at least > >
as defined in G.8080). > >
Explicit Label Control seems like it would help you control > > the label assignment > >
within the signaled portion of a connection. > >

Cheers, > >
Lyndon

> > > > > >

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

> > --------------1FF6DF901322C8C0DC51EC75-- > > > > > > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Nov 2003 18:17:44 +0000 Subject: Re: [ =?iso-8859-1?Q?=C0=FC=C3=BC=C8=B8=BD=C5?= ] spc connections To: jonathan.sadler@tellabs.com (Jonathan Sadler) Date: Thu, 13 Nov 2003 18:16:17 +0000 (GMT) Cc: yhwkim@etri.re.kr, adrian@olddog.co.uk, LyOng@ciena.com, kireeti@juniper.net, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=DISPLAY Content-Transfer-Encoding: 8bit Message-Id: From: Dimitri Papadimitriou jonathan, reading your mail, the following came to my mind: - does it mean that G.7713.2/RFC 3474 requires to setup a call when (or before) establishing an SPC ? - G.7713.2/RFC 3474 can not support inter-as *te* ? thanks, - dimitri. > --------------1FF6DF901322C8C0DC51EC75 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 8bit > > Hi Young - > > While the name of the "GENERALIZED_UNI" object seems to refer to the UNI > reference point, the purpose of the object is to carry attributes of a > call. G.8080 states that SPCs still use Network Call Controllers (NCCs) > in the process of setting up the SPC. Consequently, a call exists even > for SPCs. Therefore, carrying attributes of a call is independent of > whether the call was requested across a UNI or from a management system > (ie. an SPC). I agree that the name of the object is somewhat > misleading, but it comes from the fact that G.7713.2 attempted to reuse > existing RSVP extensions as much as possible. (The name of this Call > object came from the OIF UNI 1.0 IA) > > The identification of the egress point in a carriers network to which an > SPC is to be delivered is also a Call attribute, not a connection > attribute -- it is independent of how a customer's service request is > realized acrossed a service provider's network. However, the ERO is an > attribute of a connection, not a call, and may not necessarily be passed > over the E-NNI reference point. Consequently, the use of explicit label > control in an ERO is not a possible way to handle SPCs that traverse an > E-NNI. This is why the egress point identification appears in the call > object in G.7713.2. > > I hope this helps clarify SPC operations in G.7713.2/RFC 3474. > > Jonathan Sadler > > yhwkim@etri.re.kr wrote: > > > Hi, > > > > In my understanding, for the support of SPC connection, SPC_LABEL > > (Type=4, Sub-type=2) > > subobject seems to be included in GENERALIZED_UNI object. > > If my understanding is correct, I think there is a big ifference > > between concept of SPC connection and GENERALIZED_UNI object. SPC > > connection is NNI portion, not UNI. > > > > As it is, GENERALIZED_UNI object describes originating and terminating > > UNI aspects between client and network nodes. > > From logical view-point, in addition, the difference between switched > > connection (SC) and soft permanent connection (SPC) is where call and > > connection initiation is. In case of SC the initiation is of client > > node, but in case of SPC the initiation is of network node (of course, > > triggered by NMS). As a result, I think that GENERALIZED_UNI object > > and SPC connection could not be indicated by using the object, called > > GENERALIZED_UNI object because these are completely different by > > nature. > > > > What do you think of my opinion? > > > > Thanks, > > Young > > > > ¿øº» ³»¿ë: > > > > º¸³½»ç¶÷: Adrian Farrel[adrian@olddog.co.uk] > > ¹Þ´Â»ç¶÷: Ong, Lyndon > > ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org > > Á¦¸ñ: spc connections > > ¹ÞÀº³¯Â¥: 2003/11/13 ¸ñ 06:57 > > > > > > Lyndon, > > Thank you for raising this. There is certainly a lack of clarity in > > 3473 in this regard, > > which is perhaps unfortunate. > > In the earlier versions of the GMPLS work, this was made very explicit > > (sic) because > > egress label control was invented before it was generalized to > > explicit label. > > There is some reference to this in RFC3471 (of course, the function > > was originally > > independent of signaling protocol), but no explicit procedures. > > This descriptive deficiency has been addressed in > > draft-ccamp-gmpls-overlay. There is no > > change in protocol to enable this function, merely a description of > > how it all works. > > Hope this helps. > > Cheers, > > Adrian > > ===================== > > > > Hi Adrian, > > A couple of times now it's been suggested that Explicit Label Control > > is a way to > > do SPC connections instead of the SPC_Label sub-object. I'm wondering > > if > > people have a different model of SPC connections in mind. The > > procedures in > > RFC 3473 for Explicit Label Control are as follows: > > [when a label sub-object is present] If the U-bit of the > > subobject being examined is clear (0), then value of the label is > > copied into a new Label_Set object. This Label_Set object MUST be > > included on the corresponding outgoing Path message. > > If the U-bit of the subobject being examined is set (1), then value > > > > of the label is label to be used for upstream traffic associated > > with > > the bidirectional LSP. > > Neither of these would seem to help you for SPC, since there is no > > outgoing PATH > > message at the network endpoint, the endpoint call control is handled > > by > > the management system and not using a UNI or overlay interface (at > > least > > as defined in G.8080). > > Explicit Label Control seems like it would help you control the label > > assignment > > within the signaled portion of a connection. > > > > Cheers, > > Lyndon > > > > ----------------------------------------- > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > --------------1FF6DF901322C8C0DC51EC75 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > > Hi Young - >

While the name of the "GENERALIZED_UNI" object seems to refer to the > UNI reference point, the purpose of the object is to carry attributes of > a call.  G.8080 states that SPCs still use Network Call Controllers > (NCCs) in the process of setting up the SPC.  Consequently, a call > exists even for SPCs.  Therefore, carrying attributes of a call is > independent of whether the call was requested across a UNI or from a management > system (ie. an SPC). I agree that the name of the object is somewhat misleading, > but it comes from the fact that G.7713.2 attempted to reuse existing RSVP > extensions as much as possible.  (The name of this Call object came > from the OIF UNI 1.0 IA) >

The identification of the egress point in a carriers network to which > an SPC is to be delivered is also a Call attribute, not a connection attribute > -- it is independent of how a customer's service request is realized acrossed > a service provider's network. However, the ERO is an attribute of a connection, > not a call, and may not necessarily be passed over the E-NNI reference > point.  Consequently, the use of explicit label control in an ERO > is not a possible way to handle SPCs that traverse an E-NNI.  This > is why the egress point identification appears in the call object in G.7713.2. >

I hope this helps clarify SPC operations in G.7713.2/RFC 3474. >

Jonathan Sadler >

yhwkim@etri.re.kr wrote: >

Hi, >

In my understanding, for the support of SPC connection, > SPC_LABEL (Type=4, Sub-type=2) >
subobject seems to be included in GENERALIZED_UNI object. >
If my understanding is correct, I think there is a big > ifference between concept of SPC connection and GENERALIZED_UNI object. > SPC connection is NNI portion, not UNI. >

As it is, GENERALIZED_UNI object describes originating > and terminating UNI aspects between client and network nodes. >
From logical view-point, in addition, the difference > between switched connection (SC) and soft permanent connection (SPC) is > where call and connection initiation is. In case of SC the initiation is > of client node, but in case of SPC the initiation is of network node (of > course, triggered by NMS). As a result, I think that GENERALIZED_UNI object > and SPC connection could not be indicated by using the object, called GENERALIZED_UNI > object because these are completely different by nature. >

What do you think of my opinion? >

Thanks, >
Young >

¿øº» ³»¿ë: >

º¸³½»ç¶÷: > Adrian Farrel[adrian@olddog.co.uk] >
¹Þ´Â»ç¶÷: > Ong, Lyndon >
ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org >
Á¦¸ñ: spc connections >
¹ÞÀº³¯Â¥: > 2003/11/13 ¸ñ 06:57 >
  >

Lyndon, >
Thank you for raising this. There is certainly a lack > of clarity in 3473 in this regard, >
which is perhaps unfortunate. >
In the earlier versions of the GMPLS work, this was made > very explicit (sic) because >
egress label control was invented before it was generalized > to explicit label. >
There is some reference to this in RFC3471 (of course, > the function was originally >
independent of signaling protocol), but no explicit procedures. >
This descriptive deficiency has been addressed in draft-ccamp-gmpls-overlay. > There is no >
change in protocol to enable this function, merely a > description of how it all works. >
Hope this helps. >
Cheers, >
Adrian >
===================== >

Hi Adrian, >
A couple of times now it's been suggested that Explicit > Label Control is a way to >
do SPC connections instead of the SPC_Label sub-object.  > I'm wondering if >
people have a different model of SPC connections in mind.  > The procedures in >
RFC 3473 for Explicit Label Control are as follows: >
   [when a label sub-object is present]  > If the U-bit of the >
   subobject being examined is clear (0), then > value of the label is >
   copied into a new Label_Set object.  > This Label_Set object MUST be >
   included on the corresponding outgoing Path > message. >
   If the U-bit of the subobject being examined > is set (1), then value >
   of the label is label to be used for upstream > traffic associated with >
   the bidirectional LSP. >
Neither of these would seem to help you for SPC, since > there is no outgoing PATH >
message at the network endpoint, the endpoint call control > is handled by >
the management system and not using a UNI or overlay > interface (at least >
as defined in G.8080). >
Explicit Label Control seems like it would help you control > the label assignment >
within the signaled portion of a connection. >

Cheers, >
Lyndon

> > >

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

> --------------1FF6DF901322C8C0DC51EC75-- > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Nov 2003 15:34:34 +0000 Message-ID: <3FB3A3DD.FD52CEF7@tellabs.com> Date: Thu, 13 Nov 2003 09:31:41 -0600 From: Jonathan Sadler MIME-Version: 1.0 To: yhwkim@etri.re.kr CC: adrian@olddog.co.uk, LyOng@ciena.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: [ =?iso-8859-1?Q?=C0=FC=C3=BC=C8=B8=BD=C5?= ] spc connections Content-Type: multipart/alternative; boundary="------------1FF6DF901322C8C0DC51EC75" --------------1FF6DF901322C8C0DC51EC75 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Young - While the name of the "GENERALIZED_UNI" object seems to refer to the UNI reference point, the purpose of the object is to carry attributes of a call. G.8080 states that SPCs still use Network Call Controllers (NCCs) in the process of setting up the SPC. Consequently, a call exists even for SPCs. Therefore, carrying attributes of a call is independent of whether the call was requested across a UNI or from a management system (ie. an SPC). I agree that the name of the object is somewhat misleading, but it comes from the fact that G.7713.2 attempted to reuse existing RSVP extensions as much as possible. (The name of this Call object came from the OIF UNI 1.0 IA) The identification of the egress point in a carriers network to which an SPC is to be delivered is also a Call attribute, not a connection attribute -- it is independent of how a customer's service request is realized acrossed a service provider's network. However, the ERO is an attribute of a connection, not a call, and may not necessarily be passed over the E-NNI reference point. Consequently, the use of explicit label control in an ERO is not a possible way to handle SPCs that traverse an E-NNI. This is why the egress point identification appears in the call object in G.7713.2. I hope this helps clarify SPC operations in G.7713.2/RFC 3474. Jonathan Sadler yhwkim@etri.re.kr wrote: > Hi, > > In my understanding, for the support of SPC connection, SPC_LABEL > (Type=4, Sub-type=2) > subobject seems to be included in GENERALIZED_UNI object. > If my understanding is correct, I think there is a big ifference > between concept of SPC connection and GENERALIZED_UNI object. SPC > connection is NNI portion, not UNI. > > As it is, GENERALIZED_UNI object describes originating and terminating > UNI aspects between client and network nodes. > From logical view-point, in addition, the difference between switched > connection (SC) and soft permanent connection (SPC) is where call and > connection initiation is. In case of SC the initiation is of client > node, but in case of SPC the initiation is of network node (of course, > triggered by NMS). As a result, I think that GENERALIZED_UNI object > and SPC connection could not be indicated by using the object, called > GENERALIZED_UNI object because these are completely different by > nature. > > What do you think of my opinion? > > Thanks, > Young > > ¿øº» ³»¿ë: > > º¸³½»ç¶÷: Adrian Farrel[adrian@olddog.co.uk] > ¹Þ´Â»ç¶÷: Ong, Lyndon > ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org > Á¦¸ñ: spc connections > ¹ÞÀº³¯Â¥: 2003/11/13 ¸ñ 06:57 > > > Lyndon, > Thank you for raising this. There is certainly a lack of clarity in > 3473 in this regard, > which is perhaps unfortunate. > In the earlier versions of the GMPLS work, this was made very explicit > (sic) because > egress label control was invented before it was generalized to > explicit label. > There is some reference to this in RFC3471 (of course, the function > was originally > independent of signaling protocol), but no explicit procedures. > This descriptive deficiency has been addressed in > draft-ccamp-gmpls-overlay. There is no > change in protocol to enable this function, merely a description of > how it all works. > Hope this helps. > Cheers, > Adrian > ===================== > > Hi Adrian, > A couple of times now it's been suggested that Explicit Label Control > is a way to > do SPC connections instead of the SPC_Label sub-object. I'm wondering > if > people have a different model of SPC connections in mind. The > procedures in > RFC 3473 for Explicit Label Control are as follows: > [when a label sub-object is present] If the U-bit of the > subobject being examined is clear (0), then value of the label is > copied into a new Label_Set object. This Label_Set object MUST be > included on the corresponding outgoing Path message. > If the U-bit of the subobject being examined is set (1), then value > > of the label is label to be used for upstream traffic associated > with > the bidirectional LSP. > Neither of these would seem to help you for SPC, since there is no > outgoing PATH > message at the network endpoint, the endpoint call control is handled > by > the management system and not using a UNI or overlay interface (at > least > as defined in G.8080). > Explicit Label Control seems like it would help you control the label > assignment > within the signaled portion of a connection. > > Cheers, > Lyndon ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ --------------1FF6DF901322C8C0DC51EC75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Young -

While the name of the "GENERALIZED_UNI" object seems to refer to the UNI reference point, the purpose of the object is to carry attributes of a call.  G.8080 states that SPCs still use Network Call Controllers (NCCs) in the process of setting up the SPC.  Consequently, a call exists even for SPCs.  Therefore, carrying attributes of a call is independent of whether the call was requested across a UNI or from a management system (ie. an SPC). I agree that the name of the object is somewhat misleading, but it comes from the fact that G.7713.2 attempted to reuse existing RSVP extensions as much as possible.  (The name of this Call object came from the OIF UNI 1.0 IA)

The identification of the egress point in a carriers network to which an SPC is to be delivered is also a Call attribute, not a connection attribute -- it is independent of how a customer's service request is realized acrossed a service provider's network. However, the ERO is an attribute of a connection, not a call, and may not necessarily be passed over the E-NNI reference point.  Consequently, the use of explicit label control in an ERO is not a possible way to handle SPCs that traverse an E-NNI.  This is why the egress point identification appears in the call object in G.7713.2.

I hope this helps clarify SPC operations in G.7713.2/RFC 3474.

Jonathan Sadler

yhwkim@etri.re.kr wrote:

Hi,

In my understanding, for the support of SPC connection, SPC_LABEL (Type=4, Sub-type=2)
subobject seems to be included in GENERALIZED_UNI object.
If my understanding is correct, I think there is a big ifference between concept of SPC connection and GENERALIZED_UNI object. SPC connection is NNI portion, not UNI.

As it is, GENERALIZED_UNI object describes originating and terminating UNI aspects between client and network nodes.
From logical view-point, in addition, the difference between switched connection (SC) and soft permanent connection (SPC) is where call and connection initiation is. In case of SC the initiation is of client node, but in case of SPC the initiation is of network node (of course, triggered by NMS). As a result, I think that GENERALIZED_UNI object and SPC connection could not be indicated by using the object, called GENERALIZED_UNI object because these are completely different by nature.

What do you think of my opinion?

Thanks,
Young

¿øº» ³»¿ë:

º¸³½»ç¶÷: Adrian Farrel[adrian@olddog.co.uk]
¹Þ´Â»ç¶÷: Ong, Lyndon
ÂüÁ¶:'Kireeti Kompella'; ccamp@ops.ietf.org
Á¦¸ñ: spc connections
¹ÞÀº³¯Â¥: 2003/11/13 ¸ñ 06:57
 

Lyndon,
Thank you for raising this. There is certainly a lack of clarity in 3473 in this regard,
which is perhaps unfortunate.
In the earlier versions of the GMPLS work, this was made very explicit (sic) because
egress label control was invented before it was generalized to explicit label.
There is some reference to this in RFC3471 (of course, the function was originally
independent of signaling protocol), but no explicit procedures.
This descriptive deficiency has been addressed in draft-ccamp-gmpls-overlay. There is no
change in protocol to enable this function, merely a description of how it all works.
Hope this helps.
Cheers,
Adrian
=====================

Hi Adrian,
A couple of times now it's been suggested that Explicit Label Control is a way to
do SPC connections instead of the SPC_Label sub-object.  I'm wondering if
people have a different model of SPC connections in mind.  The procedures in
RFC 3473 for Explicit Label Control are as follows:
   [when a label sub-object is present]  If the U-bit of the
   subobject being examined is clear (0), then value of the label is
   copied into a new Label_Set object.  This Label_Set object MUST be
   included on the corresponding outgoing Path message.
   If the U-bit of the subobject being examined is set (1), then value
   of the label is label to be used for upstream traffic associated with
   the bidirectional LSP.
Neither of these would seem to help you for SPC, since there is no outgoing PATH
message at the network endpoint, the endpoint call control is handled by
the management system and not using a UNI or overlay interface (at least
as defined in G.8080).
Explicit Label Control seems like it would help you control the label assignment
within the signaled portion of a connection.

Cheers,
Lyndon

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

--------------1FF6DF901322C8C0DC51EC75-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Nov 2003 01:00:46 +0000 Subject: Re: [????] spc connections To: jdrake@calient.net (John Drake) Date: Thu, 13 Nov 2003 00:59:17 +0000 (GMT) Cc: yhwkim@etri.re.kr, adrian@olddog.co.uk, LyOng@ciena.com, kireeti@juniper.net, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou hi, your understanding is correct, the SPC_LABEL is included in the GENERALIZED_UNI object also your suggestion is in-line with: thanks, - dimitri. > > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C3A979.9A4B50F0 > Content-Type: text/plain; > charset="KS_C_5601-1987" > Content-Transfer-Encoding: quoted-printable > > Good analysis. > > -----Original Message----- > From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr] > Sent: Wednesday, November 12, 2003 3:48 PM > To: adrian@olddog.co.uk; LyOng@ciena.com > Cc: kireeti@juniper.net; ccamp@ops.ietf.org > Subject: [????] spc connections > > > > Hi,=20 > > In my understanding, for the support of SPC connection, SPC_LABEL = > (Type=3D4, > Sub-type=3D2)=20 > subobject seems to be included in GENERALIZED_UNI object.=20 > If my understanding is correct, I think there is a big ifference = > between > concept of SPC connection and GENERALIZED_UNI object. SPC connection is = > NNI > portion, not UNI. > > As it is, GENERALIZED_UNI object describes originating and terminating = > UNI > aspects between client and network nodes.=20 > >From logical view-point, in addition, the difference between switched > connection (SC) and soft permanent connection (SPC) is where call and > connection initiation is. In case of SC the initiation is of client = > node, > but in case of SPC the initiation is of network node (of course, = > triggered > by NMS). As a result, I think that GENERALIZED_UNI object and SPC > connection could not be indicated by using the object, called > GENERALIZED_UNI object because these are completely different by = > nature. > > What do you think of my opinion?=20 > > Thanks,=20 > Young=20 > > > =BF=F8=BA=BB =B3=BB=BF=EB:=20 > > =BA=B8=B3=BD=BB=E7=B6=F7: Adrian Farrel[adrian@olddog.co.uk]=20 > =B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon=20 > =C2=FC=C1=B6:'Kireeti Kompella'; ccamp@ops.ietf.org=20 > =C1=A6=B8=F1: spc connections=20 > =B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/13 =B8=F1 06:57=20 > > > > Lyndon,=20 > Thank you for raising this. There is certainly a lack of clarity in = > 3473 in > this regard,=20 > which is perhaps unfortunate.=20 > In the earlier versions of the GMPLS work, this was made very explicit > (sic) because=20 > egress label control was invented before it was generalized to explicit > label.=20 > There is some reference to this in RFC3471 (of course, the function was > originally=20 > independent of signaling protocol), but no explicit procedures.=20 > This descriptive deficiency has been addressed in draft-ccamp-gmpls- > overlay. There is no=20 > change in protocol to enable this function, merely a description of how = > it > all works.=20 > Hope this helps.=20 > Cheers,=20 > Adrian=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > > Hi Adrian,=20 > A couple of times now it's been suggested that Explicit Label Control = > is a > way to=20 > do SPC connections instead of the SPC_Label sub-object. I'm wondering = > if=20 > people have a different model of SPC connections in mind. The = > procedures > in=20 > RFC 3473 for Explicit Label Control are as follows:=20 > [when a label sub-object is present] If the U-bit of the=20 > subobject being examined is clear (0), then value of the label is=20 > copied into a new Label_Set object. This Label_Set object MUST be=20 > included on the corresponding outgoing Path message.=20 > If the U-bit of the subobject being examined is set (1), then value=20 > of the label is label to be used for upstream traffic associated = > with=20 > the bidirectional LSP.=20 > Neither of these would seem to help you for SPC, since there is no = > outgoing > PATH=20 > message at the network endpoint, the endpoint call control is handled = > by=20 > the management system and not using a UNI or overlay interface (at = > least=20 > as defined in G.8080).=20 > Explicit Label Control seems like it would help you control the label > assignment=20 > within the signaled portion of a connection.=20 > > Cheers,=20 > Lyndon=20 > > > ------_=_NextPart_001_01C3A979.9A4B50F0 > Content-Type: text/html; > charset="KS_C_5601-1987" > Content-Transfer-Encoding: quoted-printable > > > > charset=3DKS_C_5601-1987"> > [=C0=FC=C3=BC=C8=B8=BD=C5] spc connections > > > >
color=3D#0000ff size=3D2>Good=20 > analysis.
>
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = > solid; MARGIN-RIGHT: 0px"> >
face=3DTahoma=20 > size=3D2>-----Original Message-----
From: yhwkim@etri.re.kr = > > [mailto:yhwkim@etri.re.kr]
Sent: Wednesday, November 12, = > 2003 3:48=20 > PM
To: adrian@olddog.co.uk; LyOng@ciena.com
Cc:=20 > kireeti@juniper.net; ccamp@ops.ietf.org
Subject: [????] spc = > > connections

>

Hi,

>

In my understanding, for the support of SPC = > connection,=20 > SPC_LABEL (Type=3D4, Sub-type=3D2)
size=3D2>subobject seems to be=20 > included in GENERALIZED_UNI object.
If my=20 > understanding is correct, I think there is a big ifference between = > concept of=20 > SPC connection and GENERALIZED_UNI object. SPC connection is NNI = > portion, not=20 > UNI.

>

As it is, GENERALIZED_UNI object describes = > originating and=20 > terminating UNI aspects between client and network nodes. = >
size=3D2>From logical view-point, in addition, the difference between = > switched=20 > connection (SC) and soft permanent connection (SPC) is where call and = > > connection initiation is. In case of SC the initiation is of client = > node, but=20 > in case of SPC the initiation is of network node (of course, = > triggered by=20 > NMS). As a result, I think that GENERALIZED_UNI object and SPC = > connection=20 > could not be indicated by using the object, called GENERALIZED_UNI = > object=20 > because these are completely different by nature.

>

What do you think of my opinion?

>

Thanks,
Young = >


>

=BF=F8=BA=BB =B3=BB=BF=EB:

>

=BA=B8=B3=BD=BB=E7=B6=F7: Adrian = > Farrel[adrian@olddog.co.uk]
size=3D2>=B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon
size=3D2>=C2=FC=C1=B6:'Kireeti Kompella';=20 > ccamp@ops.ietf.org
=C1=A6=B8=F1: spc = > connections=20 >
=B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/13 =B8=F1 = > 06:57



>

Lyndon,
Thank you for = > raising this.=20 > There is certainly a lack of clarity in 3473 in this regard, = >
size=3D2>which is perhaps unfortunate.
In = > the earlier=20 > versions of the GMPLS work, this was made very explicit (sic) because = > >
egress label control was invented before it = > was=20 > generalized to explicit label.
There is = > some reference=20 > to this in RFC3471 (of course, the function was originally = >
size=3D2>independent of signaling protocol), but no explicit = > procedures.=20 >
This descriptive deficiency has been addressed in=20 > draft-ccamp-gmpls-overlay. There is no
size=3D2>change in=20 > protocol to enable this function, merely a description of how it all=20 > works.
Hope this helps.
size=3D2>Cheers,
Adrian
= > size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >

>

Hi Adrian,
A couple of = > times now it's=20 > been suggested that Explicit Label Control is a way to = >
size=3D2>do SPC connections instead of the SPC_Label = > sub-object.  I'm=20 > wondering if
people have a different model = > of SPC=20 > connections in mind.  The procedures in
size=3D2>RFC 3473=20 > for Explicit Label Control are as follows:
size=3D2>   [when a label sub-object is present]  If = > the U-bit of=20 > the
   subobject being examined = > is clear=20 > (0), then value of the label is
size=3D2>   copied=20 > into a new Label_Set object.  This Label_Set object MUST be=20 >
   included on the corresponding = > outgoing=20 > Path message.
   If the U-bit of = > the=20 > subobject being examined is set (1), then value
size=3D2>   of the label is label to be used for upstream = > traffic=20 > associated with
   the = > bidirectional=20 > LSP.
Neither of these would seem to help = > you for SPC,=20 > since there is no outgoing PATH
message at = > the network=20 > endpoint, the endpoint call control is handled by
size=3D2>the=20 > management system and not using a UNI or overlay interface (at least=20 >
as defined in G.8080).
size=3D2>Explicit Label Control seems like it would help you control = > the label=20 > assignment
within the signaled portion of a = > > connection.

>

Cheers,
Lyndon=20 >

> > ------_=_NextPart_001_01C3A979.9A4B50F0-- > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Nov 2003 00:05:27 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFCBBF27C@nimbus.chromisys.com> From: John Drake To: yhwkim@etri.re.kr, adrian@olddog.co.uk, LyOng@ciena.com Cc: kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: [????] spc connections Date: Wed, 12 Nov 2003 16:03:44 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A979.9A4B50F0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A979.9A4B50F0 Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable Good analysis. -----Original Message----- From: yhwkim@etri.re.kr [mailto:yhwkim@etri.re.kr] Sent: Wednesday, November 12, 2003 3:48 PM To: adrian@olddog.co.uk; LyOng@ciena.com Cc: kireeti@juniper.net; ccamp@ops.ietf.org Subject: [????] spc connections Hi,=20 In my understanding, for the support of SPC connection, SPC_LABEL = (Type=3D4, Sub-type=3D2)=20 subobject seems to be included in GENERALIZED_UNI object.=20 If my understanding is correct, I think there is a big ifference = between concept of SPC connection and GENERALIZED_UNI object. SPC connection is = NNI portion, not UNI. As it is, GENERALIZED_UNI object describes originating and terminating = UNI aspects between client and network nodes.=20 >From logical view-point, in addition, the difference between switched connection (SC) and soft permanent connection (SPC) is where call and connection initiation is. In case of SC the initiation is of client = node, but in case of SPC the initiation is of network node (of course, = triggered by NMS). As a result, I think that GENERALIZED_UNI object and SPC connection could not be indicated by using the object, called GENERALIZED_UNI object because these are completely different by = nature. What do you think of my opinion?=20 Thanks,=20 Young=20 =BF=F8=BA=BB =B3=BB=BF=EB:=20 =BA=B8=B3=BD=BB=E7=B6=F7: Adrian Farrel[adrian@olddog.co.uk]=20 =B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon=20 =C2=FC=C1=B6:'Kireeti Kompella'; ccamp@ops.ietf.org=20 =C1=A6=B8=F1: spc connections=20 =B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/13 =B8=F1 06:57=20 Lyndon,=20 Thank you for raising this. There is certainly a lack of clarity in = 3473 in this regard,=20 which is perhaps unfortunate.=20 In the earlier versions of the GMPLS work, this was made very explicit (sic) because=20 egress label control was invented before it was generalized to explicit label.=20 There is some reference to this in RFC3471 (of course, the function was originally=20 independent of signaling protocol), but no explicit procedures.=20 This descriptive deficiency has been addressed in draft-ccamp-gmpls- overlay. There is no=20 change in protocol to enable this function, merely a description of how = it all works.=20 Hope this helps.=20 Cheers,=20 Adrian=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Hi Adrian,=20 A couple of times now it's been suggested that Explicit Label Control = is a way to=20 do SPC connections instead of the SPC_Label sub-object. I'm wondering = if=20 people have a different model of SPC connections in mind. The = procedures in=20 RFC 3473 for Explicit Label Control are as follows:=20 [when a label sub-object is present] If the U-bit of the=20 subobject being examined is clear (0), then value of the label is=20 copied into a new Label_Set object. This Label_Set object MUST be=20 included on the corresponding outgoing Path message.=20 If the U-bit of the subobject being examined is set (1), then value=20 of the label is label to be used for upstream traffic associated = with=20 the bidirectional LSP.=20 Neither of these would seem to help you for SPC, since there is no = outgoing PATH=20 message at the network endpoint, the endpoint call control is handled = by=20 the management system and not using a UNI or overlay interface (at = least=20 as defined in G.8080).=20 Explicit Label Control seems like it would help you control the label assignment=20 within the signaled portion of a connection.=20 Cheers,=20 Lyndon=20 ------_=_NextPart_001_01C3A979.9A4B50F0 Content-Type: text/html; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] spc connections
Good=20 analysis.
-----Original Message-----
From: yhwkim@etri.re.kr = [mailto:yhwkim@etri.re.kr]
Sent: Wednesday, November 12, = 2003 3:48=20 PM
To: adrian@olddog.co.uk; LyOng@ciena.com
Cc:=20 kireeti@juniper.net; ccamp@ops.ietf.org
Subject: [????] spc = connections

Hi,

In my understanding, for the support of SPC = connection,=20 SPC_LABEL (Type=3D4, Sub-type=3D2)
subobject seems to be=20 included in GENERALIZED_UNI object.
If my=20 understanding is correct, I think there is a big ifference between = concept of=20 SPC connection and GENERALIZED_UNI object. SPC connection is NNI = portion, not=20 UNI.

As it is, GENERALIZED_UNI object describes = originating and=20 terminating UNI aspects between client and network nodes. =
From logical view-point, in addition, the difference between = switched=20 connection (SC) and soft permanent connection (SPC) is where call and = connection initiation is. In case of SC the initiation is of client = node, but=20 in case of SPC the initiation is of network node (of course, = triggered by=20 NMS). As a result, I think that GENERALIZED_UNI object and SPC = connection=20 could not be indicated by using the object, called GENERALIZED_UNI = object=20 because these are completely different by nature.

What do you think of my opinion?

Thanks,
Young =


=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: Adrian = Farrel[adrian@olddog.co.uk]
=B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon
=C2=FC=C1=B6:'Kireeti Kompella';=20 ccamp@ops.ietf.org
=C1=A6=B8=F1: spc = connections=20
=B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/13 =B8=F1 = 06:57



Lyndon,
Thank you for = raising this.=20 There is certainly a lack of clarity in 3473 in this regard, =
which is perhaps unfortunate.
In = the earlier=20 versions of the GMPLS work, this was made very explicit (sic) because =
egress label control was invented before it = was=20 generalized to explicit label.
There is = some reference=20 to this in RFC3471 (of course, the function was originally =
independent of signaling protocol), but no explicit = procedures.=20
This descriptive deficiency has been addressed in=20 draft-ccamp-gmpls-overlay. There is no
change in=20 protocol to enable this function, merely a description of how it all=20 works.
Hope this helps.
Cheers,
Adrian
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Hi Adrian,
A couple of = times now it's=20 been suggested that Explicit Label Control is a way to =
do SPC connections instead of the SPC_Label = sub-object.  I'm=20 wondering if
people have a different model = of SPC=20 connections in mind.  The procedures in
RFC 3473=20 for Explicit Label Control are as follows:
   [when a label sub-object is present]  If = the U-bit of=20 the
   subobject being examined = is clear=20 (0), then value of the label is
   copied=20 into a new Label_Set object.  This Label_Set object MUST be=20
   included on the corresponding = outgoing=20 Path message.
   If the U-bit of = the=20 subobject being examined is set (1), then value
   of the label is label to be used for upstream = traffic=20 associated with
   the = bidirectional=20 LSP.
Neither of these would seem to help = you for SPC,=20 since there is no outgoing PATH
message at = the network=20 endpoint, the endpoint call control is handled by
the=20 management system and not using a UNI or overlay interface (at least=20
as defined in G.8080).
Explicit Label Control seems like it would help you control = the label=20 assignment
within the signaled portion of a = connection.

Cheers,
Lyndon=20

------_=_NextPart_001_01C3A979.9A4B50F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 23:50:48 +0000 Message-ID: <4A0AE1E5A1AAD711AC1B00D0B7C2D4A2447E50@cms1> From: yhwkim@etri.re.kr To: adrian@olddog.co.uk, LyOng@ciena.com Cc: kireeti@juniper.net, ccamp@ops.ietf.org Subject: =?euc-kr?B?W8D8w7zIuL3FXSBzcGMgY29ubmVjdGlvbnM=?= Date: Thu, 13 Nov 2003 08:47:34 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A977.5871C800" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A977.5871C800 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Hi, In my understanding, for the support of SPC connection, SPC_LABEL = (Type=3D4, Sub-type=3D2) subobject seems to be included in GENERALIZED_UNI object. If my understanding is correct, I think there is a big ifference = between concept of SPC connection and GENERALIZED_UNI object. SPC connection is = NNI portion, not UNI. As it is, GENERALIZED_UNI object describes originating and terminating = UNI aspects between client and network nodes. >From logical view-point, in addition, the difference between switched connection (SC) and soft permanent connection (SPC) is where call and connection initiation is. In case of SC the initiation is of client = node, but in case of SPC the initiation is of network node (of course, = triggered by NMS). As a result, I think that GENERALIZED_UNI object and SPC connection could not be indicated by using the object, called GENERALIZED_UNI object because these are completely different by = nature. What do you think of my opinion? Thanks, Young =BF=F8=BA=BB =B3=BB=BF=EB: =BA=B8=B3=BD=BB=E7=B6=F7: Adrian Farrel[adrian@olddog.co.uk] =B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon =C2=FC=C1=B6:'Kireeti Kompella'; ccamp@ops.ietf.org =C1=A6=B8=F1: spc connections=20 =B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/13 =B8=F1 06:57 Lyndon, Thank you for raising this. There is certainly a lack of clarity in = 3473 in this regard,=20 which is perhaps unfortunate. In the earlier versions of the GMPLS work, this was made very explicit (sic) because=20 egress label control was invented before it was generalized to explicit label. There is some reference to this in RFC3471 (of course, the function was originally=20 independent of signaling protocol), but no explicit procedures. This descriptive deficiency has been addressed in draft-ccamp-gmpls- overlay. There is no=20 change in protocol to enable this function, merely a description of how = it all works. Hope this helps. Cheers,=20 Adrian=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Hi Adrian, A couple of times now it's been suggested that Explicit Label Control = is a way to=20 do SPC connections instead of the SPC_Label sub-object. I'm wondering = if=20 people have a different model of SPC connections in mind. The = procedures in=20 RFC 3473 for Explicit Label Control are as follows: [when a label sub-object is present] If the U-bit of the=20 subobject being examined is clear (0), then value of the label is=20 copied into a new Label_Set object. This Label_Set object MUST be=20 included on the corresponding outgoing Path message. If the U-bit of the subobject being examined is set (1), then value=20 of the label is label to be used for upstream traffic associated = with=20 the bidirectional LSP. Neither of these would seem to help you for SPC, since there is no = outgoing PATH=20 message at the network endpoint, the endpoint call control is handled = by=20 the management system and not using a UNI or overlay interface (at = least=20 as defined in G.8080). Explicit Label Control seems like it would help you control the label assignment=20 within the signaled portion of a connection. Cheers, Lyndon ------_=_NextPart_001_01C3A977.5871C800 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] spc connections

Hi,

In my understanding, for the support of SPC = connection, SPC_LABEL (Type=3D4, Sub-type=3D2)
subobject seems to be included in GENERALIZED_UNI = object.
If my understanding is correct, I think there is a = big ifference between concept of SPC connection and GENERALIZED_UNI = object. SPC connection is NNI portion, not UNI.

As it is, GENERALIZED_UNI object describes = originating and terminating UNI aspects between client and network = nodes.
From logical view-point, in addition, the difference = between switched connection (SC) and soft permanent connection (SPC) is = where call and connection initiation is. In case of SC the initiation = is of client node, but in case of SPC the initiation is of network node = (of course, triggered by NMS). As a result, I think that = GENERALIZED_UNI object and SPC connection could not be indicated by = using the object, called GENERALIZED_UNI object because these are = completely different by nature.

What do you think of my opinion?

Thanks,
Young


=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: Adrian = Farrel[adrian@olddog.co.uk]
=B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon
=C2=FC=C1=B6:'Kireeti Kompella'; = ccamp@ops.ietf.org
=C1=A6=B8=F1: spc connections
=B9=DE=C0=BA=B3=AF=C2=A5: 2003/11/13 =B8=F1 = 06:57



Lyndon,
Thank you for raising this. There is certainly a = lack of clarity in 3473 in this regard,
which is perhaps unfortunate.
In the earlier versions of the GMPLS work, this was = made very explicit (sic) because
egress label control was invented before it was = generalized to explicit label.
There is some reference to this in RFC3471 (of = course, the function was originally
independent of signaling protocol), but no explicit = procedures.
This descriptive deficiency has been addressed in = draft-ccamp-gmpls-overlay. There is no
change in protocol to enable this function, merely a = description of how it all works.
Hope this helps.
Cheers,
Adrian
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Hi Adrian,
A couple of times now it's been suggested that = Explicit Label Control is a way to
do SPC connections instead of the SPC_Label = sub-object.  I'm wondering if
people have a different model of SPC connections in = mind.  The procedures in
RFC 3473 for Explicit Label Control are as = follows:
   [when a label sub-object is = present]  If the U-bit of the
   subobject being examined is clear (0), = then value of the label is
   copied into a new Label_Set = object.  This Label_Set object MUST be
   included on the corresponding outgoing = Path message.
   If the U-bit of the subobject being = examined is set (1), then value
   of the label is label to be used for = upstream traffic associated with
   the bidirectional LSP.
Neither of these would seem to help you for SPC, = since there is no outgoing PATH
message at the network endpoint, the endpoint call = control is handled by
the management system and not using a UNI or overlay = interface (at least
as defined in G.8080).
Explicit Label Control seems like it would help you = control the label assignment
within the signaled portion of a connection.

Cheers,
Lyndon

------_=_NextPart_001_01C3A977.5871C800-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 23:43:59 +0000 Message-ID: From: Nurit Sprecher To: "'tnadeau@cisco.com'" , 'Adrian Farrel' , Nurit Sprecher , jcucchiara@mindspring.com, cheenu@bloomberg.net, arunv@force10networks.com Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: MPLS Tunnel Maximum Hops Date: Thu, 13 Nov 2003 01:43:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Well, meanwhile I have talked to Adrian and explained to him why it is required. I definitely think that this should be configurable per tunnel. For different tunnels I would like to limit the number of hops it may flow through (from many reasons that I'll specify in a detailed mail next week) and I would like to find the best route (using the CSPF) that can be committed to this restriction. I believe that this limitation relates not only to the LSR capability but also to the network topology and to the tunnels constraints (for example the required latency, etc.). Please note that even if it relates to the LSR capability, other LSRs that have LSPs that flow via this LSR should be aware of this limitation, otherwise we can meet many error conditions. This can be solved by configuration. I believe that in the multi area case, where loose nodes are involved, we should signal this value as well, otherwise this value will not sustain any more. Anyway, I understand that I came with this late, and I'll have to push it in the regular procedure. Nurit. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thursday, November 13, 2003 01:12 To: 'Adrian Farrel'; 'Nurit Sprecher'; jcucchiara@mindspring.com; cheenu@bloomberg.net; arunv@force10networks.com Cc: mpls@UU.NET; ccamp@ops.ietf.org Subject: RE: MPLS Tunnel Maximum Hops >I am unclear why this object should be writeable. I agree. >As you imply, it is either something that you wish to control >for each individual CSPF >calculation (in which case it is a per tunnel instance >configuration parameter) or it is a >quality of the entire LSR and is applied to all LSPs. > >The current object was intended to reflect the capabilities of >the LSR, not an operational >requirement. Thus it cannot be changed by the operator. > >It would be a different thing if you want to change the LSR's >CSPF behavior (compared with >stating the LSR's capabilities). > >So *if* this was to advance I would say that it should either be: >- a per tunnel instance object >- a configuration parameter for CSPF. >Personally, I do not see the requirement for the former, and >the latter is clearly out of >scope of the MPLS MIB modules. > >Note that there is an edge condition where you need to limit >the size of ERO on some >interfaces but not on others. In my view, this is a property >of the interface which should >be reported to CSPF direct, and not configured through the MPLS MIBs. I agree. The only possible option would be to add another object to reflect the configured value. --Tom > >Cheers, >Adrian > >----- Original Message ----- >From: "Nurit Sprecher" >To: ; "Nurit Sprecher" >; >; ; > >Cc: ; >Sent: Wednesday, November 12, 2003 7:52 PM >Subject: RE: MPLS Tunnel Maximum Hops > > >> Hi Joan, >> Thanks for the response. >> 1. What is the procedure to push it to the standard right >now when the draft >> is in a last call? >> 2. Do you agree that this should be configurable? Otherwise >how can you >> determine on the value? >> 3. Do you agree that it may be required also to configure it >per tunnel (but >> have a default value)? >> Until now I have just got e-mails on the procedure but not >on the idea >> itself. >> I'll appreciate your response, Nurit. >> >> >> -----Original Message----- >> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] >> Sent: Wednesday, November 12, 2003 19:32 >> To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher; >> cheenu@bloomberg.net; arunv@force10networks.com >> Cc: mpls@UU.NET; ccamp@ops.ietf.org >> Subject: RE: MPLS Tunnel Maximum Hops >> >> >> Hi Nurit, >> >> I can understand you wanting this change, but that is why >> we had working group last calls in June and an IETF last >> call in Aug/Sep. That is the opportunity for >> folks to give their comments, knowing that the MIB can only >> have minor edits after that. >> >> The most minimal way I see to make this change (and this is >> just my opinion) is: >> >> * change the mplsTunnelMaxHops object to read-write >> * agree upon a DEFVAL (default value upon startup, which can >> be set to a different value by an operator) >> * add to the conformance statement that this may be supported >> as a read-only >> >> So, in addition to making the object read-write, think it needs a >> DEFVAL, and this would need to be discussed and agreed upon by >> the working group. This is more than minor editing in my opinion. >> I am in agreement with Loa and Tom and would like to see >> the MIBs move forward. >> >> -Thanks, >> -Joan >> >> -----Original Message----- >> From: Nurit Sprecher >> Sent: Nov 12, 2003 11:25 AM >> To: "'tnadeau@cisco.com'" , >> Nurit Sprecher , >> cheenu@bloomberg.net, arunv@force10networks.com >> Cc: mpls@UU.NET, ccamp@ops.ietf.org >> Subject: RE: MPLS Tunnel Maximum Hops >> >> Thanks Tom for responding me. >> I understand that this is in a last call state, but this >issue should be >> addressed somehow? >> I am surprised that such an attribute that is provided to >the CSPF algorithm >> is not configurable. How can you determine its value? >Hard-coded? Doesn't it >> have to do with network topology? >> I think it should be configurable and we should see how we >could add it to >> the draft. >> Nurit. >> >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: Wednesday, November 12, 2003 18:14 >> To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com >> Cc: mpls@uu.net; ccamp@ops.ietf.org >> Subject: RE: MPLS Tunnel Maximum Hops >> >> >> >Any response to the bellow? >> >> The MIB is well past IETF last call, so >> I don't believe we can make any further changes >> at this time. >> >> --Tom >> >> >> >> >Hi, >> >I have a question regarding the mplsTunnelMaxHops scalar that >> >indicates the >> >maximum number of hops that can be specified on each tunnel >> >supported by the >> >LSR. >> >This scalar is a read only attribute but I can find it very >> >useful to let >> >configure it as well. >> >One of the CSPF constraints is the maximum number of hops the >> >LSP may follow >> >through. The limitation on the maximum number for example can >> >result from >> >the maximum packet size when fragmentation is not supported. >> >In such a case >> >the maximum number of hops can depend on the network nature >> >(numbered/unnumbered). Instead of hard coding it with the >> >worst case number, >> >let the network administrator, that is aware of the network nature, >> >configure it. >> >Moreover, I think that the maximum hops should be configurable >> >per tunnel. >> >Thanks, Nurit. >> > >> > >> >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 23:38:01 +0000 Reply-To: From: "Thomas D. Nadeau" To: Cc: "'Nurit Sprecher'" , , , , Subject: RE: MPLS Tunnel Maximum Hops Date: Wed, 12 Nov 2003 18:36:34 -0500 Organization: Cisco Systems, inc. Message-ID: <009c01c3a975$cf92d480$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >Tom, > >while I agree that we don't want any changes just now. >It would also be good to understand if this is a good idea >or not. If not we could discard it now, if it is would could >make a log for future updates. Any opinion? That is a good idea. I will keep a list of things that didn't get into the current version. --Tom > >/Loa > >Thomas D. Nadeau wrote: > >> >> >>>Any response to the bellow? >>> >>> >> >> The MIB is well past IETF last call, so >>I don't believe we can make any further changes >>at this time. >> >> --Tom >> >> >> >> >> >>>Hi, >>>I have a question regarding the mplsTunnelMaxHops scalar that >>>indicates the >>>maximum number of hops that can be specified on each tunnel >>>supported by the >>>LSR. >>>This scalar is a read only attribute but I can find it very >>>useful to let >>>configure it as well. >>>One of the CSPF constraints is the maximum number of hops the >>>LSP may follow >>>through. The limitation on the maximum number for example can >>>result from >>>the maximum packet size when fragmentation is not supported. >>>In such a case >>>the maximum number of hops can depend on the network nature >>>(numbered/unnumbered). Instead of hard coding it with the >>>worst case number, >>>let the network administrator, that is aware of the network nature, >>>configure it. >>>Moreover, I think that the maximum hops should be configurable >>>per tunnel. >>>Thanks, Nurit. >>> >>> >>> >>> >> >> >> >> >> >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 23:33:37 +0000 Reply-To: From: "Thomas D. Nadeau" To: "'Don Fedyk'" , Cc: "'Nurit Sprecher'" , , , , Subject: RE: MPLS Tunnel Maximum Hops Date: Wed, 12 Nov 2003 17:32:02 -0600 Organization: Cisco Systems, inc. Message-ID: <009901c3a975$30c069d0$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would like to hear from operators who have deployed the existing MPLS TE MIB on this issue before we rush to make any changes. The other question is whether this is something that matters to those deploying MPLS or GMPLS or both. --Tom >Limiting hops is a good idea IMHO and probably should be in >the MIB down the >road. > >Don > > >> -----Original Message----- >> From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net] >> Sent: Wednesday, November 12, 2003 11:34 AM >> To: tnadeau@cisco.com >> Cc: 'Nurit Sprecher'; cheenu@bloomberg.net; >> arunv@force10networks.com; mpls@UU.NET; ccamp@ops.ietf.org >> Subject: Re: MPLS Tunnel Maximum Hops >> >> >> Tom, >> >> while I agree that we don't want any changes just now. >> It would also be good to understand if this is a good idea >> or not. If not we could discard it now, if it is would could >> make a log for future updates. Any opinion? >> >> /Loa > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 23:14:45 +0000 Reply-To: From: "Thomas D. Nadeau" To: "'Adrian Farrel'" , "'Nurit Sprecher'" , , , Cc: , Subject: RE: MPLS Tunnel Maximum Hops Date: Wed, 12 Nov 2003 17:11:31 -0600 Organization: Cisco Systems, inc. Message-ID: <008e01c3a972$557988e0$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >I am unclear why this object should be writeable. I agree. >As you imply, it is either something that you wish to control >for each individual CSPF >calculation (in which case it is a per tunnel instance >configuration parameter) or it is a >quality of the entire LSR and is applied to all LSPs. > >The current object was intended to reflect the capabilities of >the LSR, not an operational >requirement. Thus it cannot be changed by the operator. > >It would be a different thing if you want to change the LSR's >CSPF behavior (compared with >stating the LSR's capabilities). > >So *if* this was to advance I would say that it should either be: >- a per tunnel instance object >- a configuration parameter for CSPF. >Personally, I do not see the requirement for the former, and >the latter is clearly out of >scope of the MPLS MIB modules. > >Note that there is an edge condition where you need to limit >the size of ERO on some >interfaces but not on others. In my view, this is a property >of the interface which should >be reported to CSPF direct, and not configured through the MPLS MIBs. I agree. The only possible option would be to add another object to reflect the configured value. --Tom > >Cheers, >Adrian > >----- Original Message ----- >From: "Nurit Sprecher" >To: ; "Nurit Sprecher" >; >; ; > >Cc: ; >Sent: Wednesday, November 12, 2003 7:52 PM >Subject: RE: MPLS Tunnel Maximum Hops > > >> Hi Joan, >> Thanks for the response. >> 1. What is the procedure to push it to the standard right >now when the draft >> is in a last call? >> 2. Do you agree that this should be configurable? Otherwise >how can you >> determine on the value? >> 3. Do you agree that it may be required also to configure it >per tunnel (but >> have a default value)? >> Until now I have just got e-mails on the procedure but not >on the idea >> itself. >> I'll appreciate your response, Nurit. >> >> >> -----Original Message----- >> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] >> Sent: Wednesday, November 12, 2003 19:32 >> To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher; >> cheenu@bloomberg.net; arunv@force10networks.com >> Cc: mpls@UU.NET; ccamp@ops.ietf.org >> Subject: RE: MPLS Tunnel Maximum Hops >> >> >> Hi Nurit, >> >> I can understand you wanting this change, but that is why >> we had working group last calls in June and an IETF last >> call in Aug/Sep. That is the opportunity for >> folks to give their comments, knowing that the MIB can only >> have minor edits after that. >> >> The most minimal way I see to make this change (and this is >> just my opinion) is: >> >> * change the mplsTunnelMaxHops object to read-write >> * agree upon a DEFVAL (default value upon startup, which can >> be set to a different value by an operator) >> * add to the conformance statement that this may be supported >> as a read-only >> >> So, in addition to making the object read-write, think it needs a >> DEFVAL, and this would need to be discussed and agreed upon by >> the working group. This is more than minor editing in my opinion. >> I am in agreement with Loa and Tom and would like to see >> the MIBs move forward. >> >> -Thanks, >> -Joan >> >> -----Original Message----- >> From: Nurit Sprecher >> Sent: Nov 12, 2003 11:25 AM >> To: "'tnadeau@cisco.com'" , >> Nurit Sprecher , >> cheenu@bloomberg.net, arunv@force10networks.com >> Cc: mpls@UU.NET, ccamp@ops.ietf.org >> Subject: RE: MPLS Tunnel Maximum Hops >> >> Thanks Tom for responding me. >> I understand that this is in a last call state, but this >issue should be >> addressed somehow? >> I am surprised that such an attribute that is provided to >the CSPF algorithm >> is not configurable. How can you determine its value? >Hard-coded? Doesn't it >> have to do with network topology? >> I think it should be configurable and we should see how we >could add it to >> the draft. >> Nurit. >> >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: Wednesday, November 12, 2003 18:14 >> To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com >> Cc: mpls@uu.net; ccamp@ops.ietf.org >> Subject: RE: MPLS Tunnel Maximum Hops >> >> >> >Any response to the bellow? >> >> The MIB is well past IETF last call, so >> I don't believe we can make any further changes >> at this time. >> >> --Tom >> >> >> >> >Hi, >> >I have a question regarding the mplsTunnelMaxHops scalar that >> >indicates the >> >maximum number of hops that can be specified on each tunnel >> >supported by the >> >LSR. >> >This scalar is a read only attribute but I can find it very >> >useful to let >> >configure it as well. >> >One of the CSPF constraints is the maximum number of hops the >> >LSP may follow >> >through. The limitation on the maximum number for example can >> >result from >> >the maximum packet size when fragmentation is not supported. >> >In such a case >> >the maximum number of hops can depend on the network nature >> >(numbered/unnumbered). Instead of hard coding it with the >> >worst case number, >> >let the network administrator, that is aware of the network nature, >> >configure it. >> >Moreover, I think that the maximum hops should be configurable >> >per tunnel. >> >Thanks, Nurit. >> > >> > >> >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 21:58:54 +0000 Message-ID: <00ea01c3a967$fbd96580$d3848182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ong, Lyndon" Cc: "'Kireeti Kompella'" , Subject: spc connections Date: Wed, 12 Nov 2003 21:57:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Lyndon, Thank you for raising this. There is certainly a lack of clarity in 3473 in this regard, which is perhaps unfortunate. In the earlier versions of the GMPLS work, this was made very explicit (sic) because egress label control was invented before it was generalized to explicit label. There is some reference to this in RFC3471 (of course, the function was originally independent of signaling protocol), but no explicit procedures. This descriptive deficiency has been addressed in draft-ccamp-gmpls-overlay. There is no change in protocol to enable this function, merely a description of how it all works. Hope this helps. Cheers, Adrian ===================== Hi Adrian, A couple of times now it's been suggested that Explicit Label Control is a way to do SPC connections instead of the SPC_Label sub-object. I'm wondering if people have a different model of SPC connections in mind. The procedures in RFC 3473 for Explicit Label Control are as follows: [when a label sub-object is present] If the U-bit of the subobject being examined is clear (0), then value of the label is copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message. If the U-bit of the subobject being examined is set (1), then value of the label is label to be used for upstream traffic associated with the bidirectional LSP. Neither of these would seem to help you for SPC, since there is no outgoing PATH message at the network endpoint, the endpoint call control is handled by the management system and not using a UNI or overlay interface (at least as defined in G.8080). Explicit Label Control seems like it would help you control the label assignment within the signaled portion of a connection. Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 21:54:30 +0000 Message-ID: <00e201c3a967$5413b850$d3848182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Nurit Sprecher" , , , , Cc: , Subject: Re: MPLS Tunnel Maximum Hops Date: Wed, 12 Nov 2003 21:51:55 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am unclear why this object should be writeable. As you imply, it is either something that you wish to control for each individual CSPF calculation (in which case it is a per tunnel instance configuration parameter) or it is a quality of the entire LSR and is applied to all LSPs. The current object was intended to reflect the capabilities of the LSR, not an operational requirement. Thus it cannot be changed by the operator. It would be a different thing if you want to change the LSR's CSPF behavior (compared with stating the LSR's capabilities). So *if* this was to advance I would say that it should either be: - a per tunnel instance object - a configuration parameter for CSPF. Personally, I do not see the requirement for the former, and the latter is clearly out of scope of the MPLS MIB modules. Note that there is an edge condition where you need to limit the size of ERO on some interfaces but not on others. In my view, this is a property of the interface which should be reported to CSPF direct, and not configured through the MPLS MIBs. Cheers, Adrian ----- Original Message ----- From: "Nurit Sprecher" To: ; "Nurit Sprecher" ; ; ; Cc: ; Sent: Wednesday, November 12, 2003 7:52 PM Subject: RE: MPLS Tunnel Maximum Hops > Hi Joan, > Thanks for the response. > 1. What is the procedure to push it to the standard right now when the draft > is in a last call? > 2. Do you agree that this should be configurable? Otherwise how can you > determine on the value? > 3. Do you agree that it may be required also to configure it per tunnel (but > have a default value)? > Until now I have just got e-mails on the procedure but not on the idea > itself. > I'll appreciate your response, Nurit. > > > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Wednesday, November 12, 2003 19:32 > To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher; > cheenu@bloomberg.net; arunv@force10networks.com > Cc: mpls@UU.NET; ccamp@ops.ietf.org > Subject: RE: MPLS Tunnel Maximum Hops > > > Hi Nurit, > > I can understand you wanting this change, but that is why > we had working group last calls in June and an IETF last > call in Aug/Sep. That is the opportunity for > folks to give their comments, knowing that the MIB can only > have minor edits after that. > > The most minimal way I see to make this change (and this is > just my opinion) is: > > * change the mplsTunnelMaxHops object to read-write > * agree upon a DEFVAL (default value upon startup, which can > be set to a different value by an operator) > * add to the conformance statement that this may be supported > as a read-only > > So, in addition to making the object read-write, think it needs a > DEFVAL, and this would need to be discussed and agreed upon by > the working group. This is more than minor editing in my opinion. > I am in agreement with Loa and Tom and would like to see > the MIBs move forward. > > -Thanks, > -Joan > > -----Original Message----- > From: Nurit Sprecher > Sent: Nov 12, 2003 11:25 AM > To: "'tnadeau@cisco.com'" , > Nurit Sprecher , > cheenu@bloomberg.net, arunv@force10networks.com > Cc: mpls@UU.NET, ccamp@ops.ietf.org > Subject: RE: MPLS Tunnel Maximum Hops > > Thanks Tom for responding me. > I understand that this is in a last call state, but this issue should be > addressed somehow? > I am surprised that such an attribute that is provided to the CSPF algorithm > is not configurable. How can you determine its value? Hard-coded? Doesn't it > have to do with network topology? > I think it should be configurable and we should see how we could add it to > the draft. > Nurit. > > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, November 12, 2003 18:14 > To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com > Cc: mpls@uu.net; ccamp@ops.ietf.org > Subject: RE: MPLS Tunnel Maximum Hops > > > >Any response to the bellow? > > The MIB is well past IETF last call, so > I don't believe we can make any further changes > at this time. > > --Tom > > > > >Hi, > >I have a question regarding the mplsTunnelMaxHops scalar that > >indicates the > >maximum number of hops that can be specified on each tunnel > >supported by the > >LSR. > >This scalar is a read only attribute but I can find it very > >useful to let > >configure it as well. > >One of the CSPF constraints is the maximum number of hops the > >LSP may follow > >through. The limitation on the maximum number for example can > >result from > >the maximum packet size when fragmentation is not supported. > >In such a case > >the maximum number of hops can depend on the network nature > >(numbered/unnumbered). Instead of hard coding it with the > >worst case number, > >let the network administrator, that is aware of the network nature, > >configure it. > >Moreover, I think that the maximum hops should be configurable > >per tunnel. > >Thanks, Nurit. > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 20:14:17 +0000 Message-ID: <3FB29419.3050305@netscape.net> Date: Wed, 12 Nov 2003 21:12:09 +0100 From: Loa Andersson Reply-To: loa@pi.se User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Nurit Sprecher CC: "'jcucchiara@mindspring.com'" , "'tnadeau@cisco.com'" , cheenu@bloomberg.net, arunv@force10networks.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: MPLS Tunnel Maximum Hops Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nurit, with my wg chair hat on :) - the way to push things to standard now is to write down the proposal in an ID and have the wg to discuss it. "Now" is a point in time when the other option - commenting on a draft and have editors/authors change the ID, because we have a set of mib modules in review and we don't want to delay this review longer than necessary. To have the documents out represents much more "good", than an update that would respin the doc back into wg last call, especially since the documents in review is heavily dependent on each other. /Loa Nurit Sprecher wrote: >Hi Joan, >Thanks for the response. >1. What is the procedure to push it to the standard right now when the draft >is in a last call? >2. Do you agree that this should be configurable? Otherwise how can you >determine on the value? >3. Do you agree that it may be required also to configure it per tunnel (but >have a default value)? >Until now I have just got e-mails on the procedure but not on the idea >itself. >I'll appreciate your response, Nurit. > > >-----Original Message----- >From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] >Sent: Wednesday, November 12, 2003 19:32 >To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher; >cheenu@bloomberg.net; arunv@force10networks.com >Cc: mpls@UU.NET; ccamp@ops.ietf.org >Subject: RE: MPLS Tunnel Maximum Hops > > >Hi Nurit, > >I can understand you wanting this change, but that is why >we had working group last calls in June and an IETF last >call in Aug/Sep. That is the opportunity for >folks to give their comments, knowing that the MIB can only >have minor edits after that. > >The most minimal way I see to make this change (and this is >just my opinion) is: > >* change the mplsTunnelMaxHops object to read-write >* agree upon a DEFVAL (default value upon startup, which can > be set to a different value by an operator) >* add to the conformance statement that this may be supported > as a read-only > >So, in addition to making the object read-write, think it needs a >DEFVAL, and this would need to be discussed and agreed upon by >the working group. This is more than minor editing in my opinion. >I am in agreement with Loa and Tom and would like to see >the MIBs move forward. > > -Thanks, > -Joan > >-----Original Message----- >From: Nurit Sprecher >Sent: Nov 12, 2003 11:25 AM >To: "'tnadeau@cisco.com'" , > Nurit Sprecher , > cheenu@bloomberg.net, arunv@force10networks.com >Cc: mpls@UU.NET, ccamp@ops.ietf.org >Subject: RE: MPLS Tunnel Maximum Hops > >Thanks Tom for responding me. >I understand that this is in a last call state, but this issue should be >addressed somehow? >I am surprised that such an attribute that is provided to the CSPF algorithm >is not configurable. How can you determine its value? Hard-coded? Doesn't it >have to do with network topology? >I think it should be configurable and we should see how we could add it to >the draft. >Nurit. > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Wednesday, November 12, 2003 18:14 >To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com >Cc: mpls@uu.net; ccamp@ops.ietf.org >Subject: RE: MPLS Tunnel Maximum Hops > > > > >>Any response to the bellow? >> >> > > The MIB is well past IETF last call, so >I don't believe we can make any further changes >at this time. > > --Tom > > > > > >>Hi, >>I have a question regarding the mplsTunnelMaxHops scalar that >>indicates the >>maximum number of hops that can be specified on each tunnel >>supported by the >>LSR. >>This scalar is a read only attribute but I can find it very >>useful to let >>configure it as well. >>One of the CSPF constraints is the maximum number of hops the >>LSP may follow >>through. The limitation on the maximum number for example can >>result from >>the maximum packet size when fragmentation is not supported. >>In such a case >>the maximum number of hops can depend on the network nature >>(numbered/unnumbered). Instead of hard coding it with the >>worst case number, >>let the network administrator, that is aware of the network nature, >>configure it. >>Moreover, I think that the maximum hops should be configurable >>per tunnel. >>Thanks, Nurit. >> >> >> >> > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 20:05:00 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61DB@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Lou Berger' Cc: "Wijnen, Bert (Bert)" , "Ccamp-wg (E-mail)" Subject: RE: fatal flaw and RFC3474 Date: Wed, 12 Nov 2003 12:03:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sounds like we're all in agreement! I talked with one of the editors of 3474 at lunch and it sounds like it started out as a simple document with codepoint assignments but grew as different reviewers suggested adding more information for explanation of how the codepoints would be used... Cheers, Lyndon -----Original Message----- From: Lou Berger [mailto:lberger@movaz.com] Sent: Wednesday, November 12, 2003 9:50 AM To: Ong, Lyndon Cc: 'Lou Berger'; Wijnen, Bert (Bert); Ccamp-wg (E-mail); Ong, Lyndon Subject: RE: fatal flaw and RFC3474 Lyndon, It sounds like you're agreeing with Bert, that we (the WG) needs to follow the formal liaison process. This sounds reasonable to me. Lou PS I think the liaison process is independent of the proposed 3474 update. While you say 3474 represents an agreement with the IETF, the only thing that that was agreed to was code point assignment for an ITU recommendation. Furthermore, 3474 is an informational document and cannot take precedence over documents approved by standard organizations. The changes needed to G.7713.2 can be addressed via the liaison process that you and Bert mention. This leaves the 3474 in it's current state where it doesn't match G.7713.2. The proposed 3474 revision would correct this. At 12:29 PM 11/12/2003, Ong, Lyndon wrote: >Hi Lou, > >It sounds to me as if the reverse is the case, RFC 3474 represents the >agreement between ITU and IETF on the assignment of codepoints but >G.7713.2 is now slightly out of phase because the issue was not >identified back to SG 15. > >I think Kireeti did in fact bring up the issue of ResvErr treatment >at the ITU Rapporteur's meeting in Chicago, but at the time it was >not clear that this was related to the "flaw". If the >people that brought up this issue can contribute details it can be >addressed through ITU, maybe through an amendment. > >BTW, 3474 already references G.7713.2. > >Cheers, > >Lyndon > > > >-----Original Message----- >From: Lou Berger [mailto:lberger@movaz.com] >Sent: Wednesday, November 12, 2003 9:05 AM >To: Wijnen, Bert (Bert) >Cc: Ccamp-wg (E-mail) >Subject: Re: fatal flaw and RFC3474 > > >Bert, > I think you make a good point. While RFC3474 was positioned as >"Documentation of IANA assignments" it is clearly more than that. This >leads to our current confusing state of affairs where we have to worry >about standard GMPLS interworking with recommendation G.7713.2 as well as >GMPLS interworking with the informational RFC 3474. Others have made the >point that 3474 = G.7713.2, but as you point out, this isn't the case. > >Given that the only ASON signaling documents that have standards >organization standing is G.7713.x, what do you think about working on an >RFC update that lists assignments and ether (a) references G7713.2 and >omits any technical discussion or (b) incorporates G7713.2 verbatim? > >This will make it clear that we're focusing on G7713.2 support/interworking >rather than on RFC3474. Furthermore it'll clear up what document should be >reference by the ongoing ASON support documents, i.e., G.7713.2. > >Lou > >At 11:35 AM 11/12/2003, Wijnen, Bert (Bert) wrote: > > >I hear that I may have caused confusion with my statement > >in the ccamp session earlier this week. > > > >The "fatal flaw" was in this text in the I-D that became RFC3474 > > Note that from the perspective of the ASON model ResvErr and ResvTear > > messages are not used. For backwards compatibility, when an ASON- > > compliant GMPLS node receives either a ResvErr or ResvTear as a > > response during the setup phase of message exchange, the GMPLS-ASON > > node should instead issue a PathTear message downstream and a PathErr > > (with Path_State_Removed flag set) message upstream. This is so that > > RSVP states are immediately removed upon error during the setup > > process. > >That text has been removed after lots of discussions. So that "fatal flaw" > >is not in RFC3464 itself. But it still exists in the ITU-T spec that this > >RFC refers to. This RFC3474 is just the "supportive document for the > >RSVP-TE assignments made by IANA". The base protocol spec is an ITU-T > >doc (G7713.2) and that was not modified (and still has not been modified > >as far as I know). > > > >My understanding was that CCAMP had send a liaison about this to ITU-RT SG15 > >but I cannot find it on our ietf web page with liaison statements. > > > >So Kireeti... was it send as liaison statement or was it communicated > >otherwise. If the former, we must get it added to web pages at IETF, > >if the latter, then I wonder if it should not become a formal communication. > > > >Appology if I was not clear at the meeting. > >Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 19:54:11 +0000 Message-ID: From: Nurit Sprecher To: "'jcucchiara@mindspring.com'" , Nurit Sprecher , "'tnadeau@cisco.com'" , cheenu@bloomberg.net, arunv@force10networks.com Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: MPLS Tunnel Maximum Hops Date: Wed, 12 Nov 2003 21:52:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Joan, Thanks for the response. 1. What is the procedure to push it to the standard right now when the draft is in a last call? 2. Do you agree that this should be configurable? Otherwise how can you determine on the value? 3. Do you agree that it may be required also to configure it per tunnel (but have a default value)? Until now I have just got e-mails on the procedure but not on the idea itself. I'll appreciate your response, Nurit. -----Original Message----- From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] Sent: Wednesday, November 12, 2003 19:32 To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher; cheenu@bloomberg.net; arunv@force10networks.com Cc: mpls@UU.NET; ccamp@ops.ietf.org Subject: RE: MPLS Tunnel Maximum Hops Hi Nurit, I can understand you wanting this change, but that is why we had working group last calls in June and an IETF last call in Aug/Sep. That is the opportunity for folks to give their comments, knowing that the MIB can only have minor edits after that. The most minimal way I see to make this change (and this is just my opinion) is: * change the mplsTunnelMaxHops object to read-write * agree upon a DEFVAL (default value upon startup, which can be set to a different value by an operator) * add to the conformance statement that this may be supported as a read-only So, in addition to making the object read-write, think it needs a DEFVAL, and this would need to be discussed and agreed upon by the working group. This is more than minor editing in my opinion. I am in agreement with Loa and Tom and would like to see the MIBs move forward. -Thanks, -Joan -----Original Message----- From: Nurit Sprecher Sent: Nov 12, 2003 11:25 AM To: "'tnadeau@cisco.com'" , Nurit Sprecher , cheenu@bloomberg.net, arunv@force10networks.com Cc: mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: MPLS Tunnel Maximum Hops Thanks Tom for responding me. I understand that this is in a last call state, but this issue should be addressed somehow? I am surprised that such an attribute that is provided to the CSPF algorithm is not configurable. How can you determine its value? Hard-coded? Doesn't it have to do with network topology? I think it should be configurable and we should see how we could add it to the draft. Nurit. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, November 12, 2003 18:14 To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com Cc: mpls@uu.net; ccamp@ops.ietf.org Subject: RE: MPLS Tunnel Maximum Hops >Any response to the bellow? The MIB is well past IETF last call, so I don't believe we can make any further changes at this time. --Tom >Hi, >I have a question regarding the mplsTunnelMaxHops scalar that >indicates the >maximum number of hops that can be specified on each tunnel >supported by the >LSR. >This scalar is a read only attribute but I can find it very >useful to let >configure it as well. >One of the CSPF constraints is the maximum number of hops the >LSP may follow >through. The limitation on the maximum number for example can >result from >the maximum packet size when fragmentation is not supported. >In such a case >the maximum number of hops can depend on the network nature >(numbered/unnumbered). Instead of hard coding it with the >worst case number, >let the network administrator, that is aware of the network nature, >configure it. >Moreover, I think that the maximum hops should be configurable >per tunnel. >Thanks, Nurit. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 18:24:15 +0000 Message-ID: <61B49BC6DA0DDE40957FB499E1835E370A9630A1@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Ong, Lyndon'" , "'Lou Berger'" , "Wijnen, Bert (Bert)" Cc: "Ccamp-wg (E-mail)" Subject: RE: fatal flaw and RFC3474 Date: Wed, 12 Nov 2003 13:17:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Hi all, I also recall Kireeti mentioning the ResvErr treatment at the interim Q14/15 meeting in Chicago. I'm wondering if what's really needed is more of a clarification. I.e., the procedure was applied only during the setup phase. During setup, the GMPLS node behavior/state machine is not modified by the procedure. It is still free to send out ResvErr or ResvTear. Similarly, the ASON node is still free to receive ResvErr and ResvTear. However, it has the option to continue the ResvErr or ResvTear message, or terminate this message and instead send out PathTear and PathErr. This does not break GMPLS as the new behavior is applicable to the ASON node not the GMPLS node. The GMPLS nodes will then receive the PathErr or PathTear message. The GMPLS node will then respond to these message based on GMPLS state machine behavior. Does this help? Best regards, Eve -----Original Message----- From: Ong, Lyndon [mailto:LyOng@Ciena.com] Sent: Wednesday, November 12, 2003 12:30 PM To: 'Lou Berger'; Wijnen, Bert (Bert) Cc: Ccamp-wg (E-mail); Ong, Lyndon Subject: RE: fatal flaw and RFC3474 Hi Lou, It sounds to me as if the reverse is the case, RFC 3474 represents the agreement between ITU and IETF on the assignment of codepoints but G.7713.2 is now slightly out of phase because the issue was not identified back to SG 15. I think Kireeti did in fact bring up the issue of ResvErr treatment at the ITU Rapporteur's meeting in Chicago, but at the time it was not clear that this was related to the "flaw". If the people that brought up this issue can contribute details it can be addressed through ITU, maybe through an amendment. BTW, 3474 already references G.7713.2. Cheers, Lyndon -----Original Message----- From: Lou Berger [mailto:lberger@movaz.com] Sent: Wednesday, November 12, 2003 9:05 AM To: Wijnen, Bert (Bert) Cc: Ccamp-wg (E-mail) Subject: Re: fatal flaw and RFC3474 Bert, I think you make a good point. While RFC3474 was positioned as "Documentation of IANA assignments" it is clearly more than that. This leads to our current confusing state of affairs where we have to worry about standard GMPLS interworking with recommendation G.7713.2 as well as GMPLS interworking with the informational RFC 3474. Others have made the point that 3474 = G.7713.2, but as you point out, this isn't the case. Given that the only ASON signaling documents that have standards organization standing is G.7713.x, what do you think about working on an RFC update that lists assignments and ether (a) references G7713.2 and omits any technical discussion or (b) incorporates G7713.2 verbatim? This will make it clear that we're focusing on G7713.2 support/interworking rather than on RFC3474. Furthermore it'll clear up what document should be reference by the ongoing ASON support documents, i.e., G.7713.2. Lou At 11:35 AM 11/12/2003, Wijnen, Bert (Bert) wrote: >I hear that I may have caused confusion with my statement >in the ccamp session earlier this week. > >The "fatal flaw" was in this text in the I-D that became RFC3474 > Note that from the perspective of the ASON model ResvErr and ResvTear > messages are not used. For backwards compatibility, when an ASON- > compliant GMPLS node receives either a ResvErr or ResvTear as a > response during the setup phase of message exchange, the GMPLS-ASON > node should instead issue a PathTear message downstream and a PathErr > (with Path_State_Removed flag set) message upstream. This is so that > RSVP states are immediately removed upon error during the setup > process. >That text has been removed after lots of discussions. So that "fatal flaw" >is not in RFC3464 itself. But it still exists in the ITU-T spec that this >RFC refers to. This RFC3474 is just the "supportive document for the >RSVP-TE assignments made by IANA". The base protocol spec is an ITU-T >doc (G7713.2) and that was not modified (and still has not been modified >as far as I know). > >My understanding was that CCAMP had send a liaison about this to ITU-RT SG15 >but I cannot find it on our ietf web page with liaison statements. > >So Kireeti... was it send as liaison statement or was it communicated >otherwise. If the former, we must get it added to web pages at IETF, >if the latter, then I wonder if it should not become a formal communication. > >Appology if I was not clear at the meeting. >Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 17:52:32 +0000 Message-Id: <4.3.2.7.2.20031112123750.02590e68@mo-ex1> Date: Wed, 12 Nov 2003 12:49:30 -0500 To: "Ong, Lyndon" From: Lou Berger Subject: RE: fatal flaw and RFC3474 Cc: 'Lou Berger' , "Wijnen, Bert (Bert)" , "Ccamp-wg (E-mail)" , "Ong, Lyndon" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Lyndon, It sounds like you're agreeing with Bert, that we (the WG) needs to follow the formal liaison process. This sounds reasonable to me. Lou PS I think the liaison process is independent of the proposed 3474 update. While you say 3474 represents an agreement with the IETF, the only thing that that was agreed to was code point assignment for an ITU recommendation. Furthermore, 3474 is an informational document and cannot take precedence over documents approved by standard organizations. The changes needed to G.7713.2 can be addressed via the liaison process that you and Bert mention. This leaves the 3474 in it's current state where it doesn't match G.7713.2. The proposed 3474 revision would correct this. At 12:29 PM 11/12/2003, Ong, Lyndon wrote: >Hi Lou, > >It sounds to me as if the reverse is the case, RFC 3474 represents the >agreement between ITU and IETF on the assignment of codepoints but >G.7713.2 is now slightly out of phase because the issue was not >identified back to SG 15. > >I think Kireeti did in fact bring up the issue of ResvErr treatment >at the ITU Rapporteur's meeting in Chicago, but at the time it was >not clear that this was related to the "flaw". If the >people that brought up this issue can contribute details it can be >addressed through ITU, maybe through an amendment. > >BTW, 3474 already references G.7713.2. > >Cheers, > >Lyndon > > > >-----Original Message----- >From: Lou Berger [mailto:lberger@movaz.com] >Sent: Wednesday, November 12, 2003 9:05 AM >To: Wijnen, Bert (Bert) >Cc: Ccamp-wg (E-mail) >Subject: Re: fatal flaw and RFC3474 > > >Bert, > I think you make a good point. While RFC3474 was positioned as >"Documentation of IANA assignments" it is clearly more than that. This >leads to our current confusing state of affairs where we have to worry >about standard GMPLS interworking with recommendation G.7713.2 as well as >GMPLS interworking with the informational RFC 3474. Others have made the >point that 3474 = G.7713.2, but as you point out, this isn't the case. > >Given that the only ASON signaling documents that have standards >organization standing is G.7713.x, what do you think about working on an >RFC update that lists assignments and ether (a) references G7713.2 and >omits any technical discussion or (b) incorporates G7713.2 verbatim? > >This will make it clear that we're focusing on G7713.2 support/interworking >rather than on RFC3474. Furthermore it'll clear up what document should be >reference by the ongoing ASON support documents, i.e., G.7713.2. > >Lou > >At 11:35 AM 11/12/2003, Wijnen, Bert (Bert) wrote: > > >I hear that I may have caused confusion with my statement > >in the ccamp session earlier this week. > > > >The "fatal flaw" was in this text in the I-D that became RFC3474 > > Note that from the perspective of the ASON model ResvErr and ResvTear > > messages are not used. For backwards compatibility, when an ASON- > > compliant GMPLS node receives either a ResvErr or ResvTear as a > > response during the setup phase of message exchange, the GMPLS-ASON > > node should instead issue a PathTear message downstream and a PathErr > > (with Path_State_Removed flag set) message upstream. This is so that > > RSVP states are immediately removed upon error during the setup > > process. > >That text has been removed after lots of discussions. So that "fatal flaw" > >is not in RFC3464 itself. But it still exists in the ITU-T spec that this > >RFC refers to. This RFC3474 is just the "supportive document for the > >RSVP-TE assignments made by IANA". The base protocol spec is an ITU-T > >doc (G7713.2) and that was not modified (and still has not been modified > >as far as I know). > > > >My understanding was that CCAMP had send a liaison about this to ITU-RT SG15 > >but I cannot find it on our ietf web page with liaison statements. > > > >So Kireeti... was it send as liaison statement or was it communicated > >otherwise. If the former, we must get it added to web pages at IETF, > >if the latter, then I wonder if it should not become a formal communication. > > > >Appology if I was not clear at the meeting. > >Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 17:30:27 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61D8@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Lou Berger' , "Wijnen, Bert (Bert)" Cc: "Ccamp-wg (E-mail)" , "Ong, Lyndon" Subject: RE: fatal flaw and RFC3474 Date: Wed, 12 Nov 2003 09:29:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Lou, It sounds to me as if the reverse is the case, RFC 3474 represents the agreement between ITU and IETF on the assignment of codepoints but G.7713.2 is now slightly out of phase because the issue was not identified back to SG 15. I think Kireeti did in fact bring up the issue of ResvErr treatment at the ITU Rapporteur's meeting in Chicago, but at the time it was not clear that this was related to the "flaw". If the people that brought up this issue can contribute details it can be addressed through ITU, maybe through an amendment. BTW, 3474 already references G.7713.2. Cheers, Lyndon -----Original Message----- From: Lou Berger [mailto:lberger@movaz.com] Sent: Wednesday, November 12, 2003 9:05 AM To: Wijnen, Bert (Bert) Cc: Ccamp-wg (E-mail) Subject: Re: fatal flaw and RFC3474 Bert, I think you make a good point. While RFC3474 was positioned as "Documentation of IANA assignments" it is clearly more than that. This leads to our current confusing state of affairs where we have to worry about standard GMPLS interworking with recommendation G.7713.2 as well as GMPLS interworking with the informational RFC 3474. Others have made the point that 3474 = G.7713.2, but as you point out, this isn't the case. Given that the only ASON signaling documents that have standards organization standing is G.7713.x, what do you think about working on an RFC update that lists assignments and ether (a) references G7713.2 and omits any technical discussion or (b) incorporates G7713.2 verbatim? This will make it clear that we're focusing on G7713.2 support/interworking rather than on RFC3474. Furthermore it'll clear up what document should be reference by the ongoing ASON support documents, i.e., G.7713.2. Lou At 11:35 AM 11/12/2003, Wijnen, Bert (Bert) wrote: >I hear that I may have caused confusion with my statement >in the ccamp session earlier this week. > >The "fatal flaw" was in this text in the I-D that became RFC3474 > Note that from the perspective of the ASON model ResvErr and ResvTear > messages are not used. For backwards compatibility, when an ASON- > compliant GMPLS node receives either a ResvErr or ResvTear as a > response during the setup phase of message exchange, the GMPLS-ASON > node should instead issue a PathTear message downstream and a PathErr > (with Path_State_Removed flag set) message upstream. This is so that > RSVP states are immediately removed upon error during the setup > process. >That text has been removed after lots of discussions. So that "fatal flaw" >is not in RFC3464 itself. But it still exists in the ITU-T spec that this >RFC refers to. This RFC3474 is just the "supportive document for the >RSVP-TE assignments made by IANA". The base protocol spec is an ITU-T >doc (G7713.2) and that was not modified (and still has not been modified >as far as I know). > >My understanding was that CCAMP had send a liaison about this to ITU-RT SG15 >but I cannot find it on our ietf web page with liaison statements. > >So Kireeti... was it send as liaison statement or was it communicated >otherwise. If the former, we must get it added to web pages at IETF, >if the latter, then I wonder if it should not become a formal communication. > >Appology if I was not clear at the meeting. >Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 17:28:36 +0000 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E608408596@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: loa@pi.se, tnadeau@cisco.com Cc: "'Nurit Sprecher'" , cheenu@bloomberg.net, arunv@force10networks.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: MPLS Tunnel Maximum Hops Date: Wed, 12 Nov 2003 12:26:34 -0500 Loa Limiting hops is a good idea IMHO and probably should be in the MIB down the road. Don > -----Original Message----- > From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net] > Sent: Wednesday, November 12, 2003 11:34 AM > To: tnadeau@cisco.com > Cc: 'Nurit Sprecher'; cheenu@bloomberg.net; > arunv@force10networks.com; mpls@UU.NET; ccamp@ops.ietf.org > Subject: Re: MPLS Tunnel Maximum Hops > > > Tom, > > while I agree that we don't want any changes just now. > It would also be good to understand if this is a good idea > or not. If not we could discard it now, if it is would could > make a log for future updates. Any opinion? > > /Loa Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 17:08:56 +0000 Message-Id: <4.3.2.7.2.20031112114838.02eda228@mo-ex1> Date: Wed, 12 Nov 2003 12:05:27 -0500 To: "Wijnen, Bert (Bert)" From: Lou Berger Subject: Re: fatal flaw and RFC3474 Cc: "Ccamp-wg (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Bert, I think you make a good point. While RFC3474 was positioned as "Documentation of IANA assignments" it is clearly more than that. This leads to our current confusing state of affairs where we have to worry about standard GMPLS interworking with recommendation G.7713.2 as well as GMPLS interworking with the informational RFC 3474. Others have made the point that 3474 = G.7713.2, but as you point out, this isn't the case. Given that the only ASON signaling documents that have standards organization standing is G.7713.x, what do you think about working on an RFC update that lists assignments and ether (a) references G7713.2 and omits any technical discussion or (b) incorporates G7713.2 verbatim? This will make it clear that we're focusing on G7713.2 support/interworking rather than on RFC3474. Furthermore it'll clear up what document should be reference by the ongoing ASON support documents, i.e., G.7713.2. Lou At 11:35 AM 11/12/2003, Wijnen, Bert (Bert) wrote: >I hear that I may have caused confusion with my statement >in the ccamp session earlier this week. > >The "fatal flaw" was in this text in the I-D that became RFC3474 > Note that from the perspective of the ASON model ResvErr and ResvTear > messages are not used. For backwards compatibility, when an ASON- > compliant GMPLS node receives either a ResvErr or ResvTear as a > response during the setup phase of message exchange, the GMPLS-ASON > node should instead issue a PathTear message downstream and a PathErr > (with Path_State_Removed flag set) message upstream. This is so that > RSVP states are immediately removed upon error during the setup > process. >That text has been removed after lots of discussions. So that "fatal flaw" >is not in RFC3464 itself. But it still exists in the ITU-T spec that this >RFC refers to. This RFC3474 is just the "supportive document for the >RSVP-TE assignments made by IANA". The base protocol spec is an ITU-T >doc (G7713.2) and that was not modified (and still has not been modified >as far as I know). > >My understanding was that CCAMP had send a liaison about this to ITU-RT SG15 >but I cannot find it on our ietf web page with liaison statements. > >So Kireeti... was it send as liaison statement or was it communicated >otherwise. If the former, we must get it added to web pages at IETF, >if the latter, then I wonder if it should not become a formal communication. > >Appology if I was not clear at the meeting. >Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 16:55:26 +0000 Message-ID: From: Nurit Sprecher To: "'tnadeau@cisco.com'" , Nurit Sprecher , cheenu@bloomberg.net, arunv@force10networks.com Cc: mpls@uu.net, ccamp@ops.ietf.org Subject: RE: MPLS Tunnel Maximum Hops Date: Wed, 12 Nov 2003 18:25:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks Tom for responding me. I understand that this is in a last call state, but this issue should be addressed somehow? I am surprised that such an attribute that is provided to the CSPF algorithm is not configurable. How can you determine its value? Hard-coded? Doesn't it have to do with network topology? I think it should be configurable and we should see how we could add it to the draft. Nurit. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, November 12, 2003 18:14 To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com Cc: mpls@uu.net; ccamp@ops.ietf.org Subject: RE: MPLS Tunnel Maximum Hops >Any response to the bellow? The MIB is well past IETF last call, so I don't believe we can make any further changes at this time. --Tom >Hi, >I have a question regarding the mplsTunnelMaxHops scalar that >indicates the >maximum number of hops that can be specified on each tunnel >supported by the >LSR. >This scalar is a read only attribute but I can find it very >useful to let >configure it as well. >One of the CSPF constraints is the maximum number of hops the >LSP may follow >through. The limitation on the maximum number for example can >result from >the maximum packet size when fragmentation is not supported. >In such a case >the maximum number of hops can depend on the network nature >(numbered/unnumbered). Instead of hard coding it with the >worst case number, >let the network administrator, that is aware of the network nature, >configure it. >Moreover, I think that the maximum hops should be configurable >per tunnel. >Thanks, Nurit. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 16:39:40 +0000 Message-ID: <3FB26113.80103@netscape.net> Date: Wed, 12 Nov 2003 17:34:27 +0100 From: Loa Andersson Reply-To: loa@pi.se User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: tnadeau@cisco.com CC: 'Nurit Sprecher' , cheenu@bloomberg.net, arunv@force10networks.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: MPLS Tunnel Maximum Hops Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tom, while I agree that we don't want any changes just now. It would also be good to understand if this is a good idea or not. If not we could discard it now, if it is would could make a log for future updates. Any opinion? /Loa Thomas D. Nadeau wrote: > > >>Any response to the bellow? >> >> > > The MIB is well past IETF last call, so >I don't believe we can make any further changes >at this time. > > --Tom > > > > > >>Hi, >>I have a question regarding the mplsTunnelMaxHops scalar that >>indicates the >>maximum number of hops that can be specified on each tunnel >>supported by the >>LSR. >>This scalar is a read only attribute but I can find it very >>useful to let >>configure it as well. >>One of the CSPF constraints is the maximum number of hops the >>LSP may follow >>through. The limitation on the maximum number for example can >>result from >>the maximum packet size when fragmentation is not supported. >>In such a case >>the maximum number of hops can depend on the network nature >>(numbered/unnumbered). Instead of hard coding it with the >>worst case number, >>let the network administrator, that is aware of the network nature, >>configure it. >>Moreover, I think that the maximum hops should be configurable >>per tunnel. >>Thanks, Nurit. >> >> >> >> > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 16:39:06 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502EAFA4B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: fatal flaw and RFC3474 Date: Wed, 12 Nov 2003 17:35:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I hear that I may have caused confusion with my statement in the ccamp session earlier this week. The "fatal flaw" was in this text in the I-D that became RFC3474 Note that from the perspective of the ASON model ResvErr and ResvTear messages are not used. For backwards compatibility, when an ASON- compliant GMPLS node receives either a ResvErr or ResvTear as a response during the setup phase of message exchange, the GMPLS-ASON node should instead issue a PathTear message downstream and a PathErr (with Path_State_Removed flag set) message upstream. This is so that RSVP states are immediately removed upon error during the setup process. That text has been removed after lots of discussions. So that "fatal flaw" is not in RFC3464 itself. But it still exists in the ITU-T spec that this RFC refers to. This RFC3474 is just the "supportive document for the RSVP-TE assignments made by IANA". The base protocol spec is an ITU-T doc (G7713.2) and that was not modified (and still has not been modified as far as I know). My understanding was that CCAMP had send a liaison about this to ITU-RT SG15 but I cannot find it on our ietf web page with liaison statements. So Kireeti... was it send as liaison statement or was it communicated otherwise. If the former, we must get it added to web pages at IETF, if the latter, then I wonder if it should not become a formal communication. Appology if I was not clear at the meeting. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 16:18:42 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61D5@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Adrian Farrel' , 'Kireeti Kompella' Cc: "'ccamp@ops.ietf.org'" Subject: notify message for call without connection Date: Wed, 12 Nov 2003 08:17:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Adrian, Kireeti, It's also been suggested that the Notify message can be used as an alternative to Path to initiate a call without connection. However, there has always been an issue with Notify that sections of RFC 3473 suggest that you can only send it after receiving a Notify Request object. Esp. in RFC 3473 section 4.3.2 it states that: Note that a Notify message MUST NOT be generated unless an appropriate Notify Request object has been received. This could really use some clarification. Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 16:15:06 +0000 Reply-To: From: "Thomas D. Nadeau" To: "'Nurit Sprecher'" , , Cc: , Subject: RE: MPLS Tunnel Maximum Hops Date: Wed, 12 Nov 2003 10:13:44 -0600 Organization: Cisco Systems, inc. Message-ID: <014b01c3a937$f5c4d9c0$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >Any response to the bellow? The MIB is well past IETF last call, so I don't believe we can make any further changes at this time. --Tom >Hi, >I have a question regarding the mplsTunnelMaxHops scalar that >indicates the >maximum number of hops that can be specified on each tunnel >supported by the >LSR. >This scalar is a read only attribute but I can find it very >useful to let >configure it as well. >One of the CSPF constraints is the maximum number of hops the >LSP may follow >through. The limitation on the maximum number for example can >result from >the maximum packet size when fragmentation is not supported. >In such a case >the maximum number of hops can depend on the network nature >(numbered/unnumbered). Instead of hard coding it with the >worst case number, >let the network administrator, that is aware of the network nature, >configure it. >Moreover, I think that the maximum hops should be configurable >per tunnel. >Thanks, Nurit. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Nov 2003 16:08:52 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61D4@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Adrian Farrel' , 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: spc connections Date: Wed, 12 Nov 2003 08:06:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Adrian, A couple of times now it's been suggested that Explicit Label Control is a way to do SPC connections instead of the SPC_Label sub-object. I'm wondering if people have a different model of SPC connections in mind. The procedures in RFC 3473 for Explicit Label Control are as follows: [when a label sub-object is present] If the U-bit of the subobject being examined is clear (0), then value of the label is copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message. If the U-bit of the subobject being examined is set (1), then value of the label is label to be used for upstream traffic associated with the bidirectional LSP. Neither of these would seem to help you for SPC, since there is no outgoing PATH message at the network endpoint, the endpoint call control is handled by the management system and not using a UNI or overlay interface (at least as defined in G.8080). Explicit Label Control seems like it would help you control the label assignment within the signaled portion of a connection. Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Nov 2003 22:17:01 +0000 Message-ID: From: Nurit Sprecher To: "'cheenu@bloomberg.net'" , "'arunv@force10networks.com'" , "'tnadeau@cisco.com'" Cc: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: MPLS Tunnel Maximum Hops Date: Wed, 12 Nov 2003 00:14:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Any response to the bellow? Hi, I have a question regarding the mplsTunnelMaxHops scalar that indicates the maximum number of hops that can be specified on each tunnel supported by the LSR. This scalar is a read only attribute but I can find it very useful to let configure it as well. One of the CSPF constraints is the maximum number of hops the LSP may follow through. The limitation on the maximum number for example can result from the maximum packet size when fragmentation is not supported. In such a case the maximum number of hops can depend on the network nature (numbered/unnumbered). Instead of hard coding it with the worst case number, let the network administrator, that is aware of the network nature, configure it. Moreover, I think that the maximum hops should be configurable per tunnel. Thanks, Nurit. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Nov 2003 16:49:09 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502EAF7A0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Adrian Farrel , Lou Berger Cc: ccamp@ops.ietf.org Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Date: Tue, 11 Nov 2003 17:46:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Things to potentially look at: draft-ietf-disman-alarm-mib-15.txt [M.3100] ITU Recommendation M.3100, "Generic Network Information Model", 1995 [X.733] ITU Recommendation X.733, "Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function", 1992 [X.736] ITU Recommendation X.736, "Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function", 1992 Thanks, Bert > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: dinsdag 11 november 2003 17:28 > To: Lou Berger > Cc: ccamp@ops.ietf.org > Subject: Re: Taking to the > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > Lou, > > I believe the alarm reference was M.3100. > > Can someone confirm? > > Adrian > > > > In the morning's meeting the AD's asked to bring the proposed Alarm > > communication extension to "the list". For today's > presentation see: > > http://www.labn.net/docs/AlarmSpec00.pdf > > > > I believe the issues to be discussed are: > > 1) Is there general interest in this work? > > 2) Should the usage of new TLVs in Error_Spec be permitted? > > (We think there's some value, particularly with string > > and timestamp) > > 3) Are there good references for alarm code points? > > > > Thank, > > Lou (and co-authors) > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Nov 2003 16:28:38 +0000 Message-ID: <017501c3a870$b9b20100$db818182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" Cc: Subject: Re: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Date: Tue, 11 Nov 2003 16:27:35 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Lou, I believe the alarm reference was M.3100. Can someone confirm? Adrian > In the morning's meeting the AD's asked to bring the proposed Alarm > communication extension to "the list". For today's presentation see: > http://www.labn.net/docs/AlarmSpec00.pdf > > I believe the issues to be discussed are: > 1) Is there general interest in this work? > 2) Should the usage of new TLVs in Error_Spec be permitted? > (We think there's some value, particularly with string > and timestamp) > 3) Are there good references for alarm code points? > > Thank, > Lou (and co-authors) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Nov 2003 15:44:01 +0000 Message-ID: <00fb01c3a869$0a925320$db818182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Soft/hard pre-emption Date: Tue, 11 Nov 2003 15:32:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit WG, Please be aware that I am starting a discussion on the correct behavior during pre-emption on the MPLS WG list. Depending on the outcome, this will impact GMPLS implementations. AS/when there is knock-on effect to GMPLS I will keep the list informed. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Nov 2003 08:33:36 +0000 Sensitivity: Subject: RE: Source routed Notify message To: Cc: " From: "Diego Caviglia" Date: Tue, 11 Nov 2003 09:02:03 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi Vishal, thanks for your reply; I'll try to explain myself a little better. Let me quote the draft-ietf-ccamp-gmpls-recovery-functional-01. " o Switchover: The action when an end node detects a failure in the working path is as follows: Start receiving from the protection path. At the same time, send a switchover request message to the other end node to enable switching at the other end. [...] GMPLS signaling mechanisms may be used to (reliably) signal the switchover request. *This message may be forwarded along the protection path if no other routing intelligence is available in the network.* " It seems to me that it is foreseen that, in protection/restoration scenario, tail end nodes exchange messages in order to share information. Now this is a scenario very similar to the one I depicted in my e-mail. >From my understanding the sentence "This message may be forwarded along the protection path if no other routing intelligence is available in the network." means that mechanism other that "normal" Ip routing should be used in order to inform efficently the other tail end about something that happens in the network. Again it seems to me that the more efficent way to do that is use a concept that is widley used and developed in GMPLS namely the ERO. I'm not saying that ERO obj should be mandatory in Notify messages but it seems to me that usage of ERO in notify should be allowed. Other answers in line. Regards, Diego "Vishal Sharma" on 10/11/2003 21.50.41 Please respond to To: "Diego Caviglia" , cc: Subject: RE: Source routed Notify message Diego, I think the problem you're looking at is still a bit ill-defined. (BTW, you have two nodes labeled H in the fig. below, which one is A trying to inform?) [dc] My fault. Assuming that the lower rightmost node is H, here are a few questions... [dc] Absolutely yes. Are you assuming, for example, that the DCN used for the SDH/SONET network uses an associated control plane (with the same topology as the data plane)? [dc] Yes. AFAIK the most likely transport DCN scenario uses embedded control channel. That control channel can be easily implemented using DCC. If not, then the IP message from A should be able to find its way easily enough to H, via the DCN. [dc] It depends on how the external part of the DCN interconnects the TNE. In general if a failure affecting the DCN (here I'm supposing that the data link failed was carrying also control channels) occurs the sender of the packet can not be sure about the delivery of the packet or at least can not be sure that the packet will be delivered following the best route. Further, if "lower layer" data plane mechanisms are at work, then the same mechanisms would have informed H as well, so why does A need to do anything special to inform H? [dc] This is not necessary true. In fact in my previous mail I specified that the failure was unidirectional that means that node H is not able to see the alarm. In any case, since the Notify message is an IP packet, it could always be IP source-routed (if A so desired), with some attendant limitations on size of course. [dc] Yes and in fact I'm worried about the limitation. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Diego Caviglia > Sent: Monday, November 10, 2003 8:17 AM > To: ccamp@ops.ietf.org > Subject: Source routed Notify message > > > Hi all, > is there anyone interested in having source routed, may by > means of standard ERO obj, Notify [RFC3473] message? > > The motivation to use a source routing mechanism for Notify is avoiding > OSPF convergence time during a network failure. > > The scenario I've in mind is the following: > > A---------------B---------------C > | | | > | | | > | | | > D---------------E---------------F > | | | > | | | > | | | > G---------------H---------------H > > Suppose there is a LSP (SDN/SONET) from H (Ingress) to A (Egress) and an > unidirectional failure occours between C and F in the H-->A direction. > Low layer mechanism (e.g AIS), informs A that a failure has > occourred. TNE > A wants to notify H about the failure but OSPF tables have not > been updated > thus TNA A knows that "normal routing" will have some problem in > delivering > the Notify to TNE H. > > A source routed path calculated using Link diversity with respect to the > failed LSP can avoid OSPF convergence time and inform efficently TNE H > about the failure of the LSP. > > That can be done either using the source route of the Ip header or using > the ERO object. The former has some limitation while the latter is > larghely used in GMPLS. > > Ragrds > > Diego > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Nov 2003 00:55:57 +0000 Message-ID: From: Nurit Sprecher To: "'cheenu@bloomberg.net'" , "'arunv@force10networks.com'" , "'tnadeau@cisco.com'" Cc: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: MPLS Tunnel Maximum Hops Date: Tue, 11 Nov 2003 02:54:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Hi, I have a comment regarding the mplsTunnelMaxHops scalar that indicates the maximum number of hops that can be specified on each tunnel supported by the LSR. This scalar is a read only attribute but I can find it very useful to let configure it as well. One of the CSPF constraints is the maximum number of hops the LSP may follow through. The limitation on the maximum number for example can result from the maximum packet size when fragmentation is not supported. In such a case the maximum number of hops can depend on the network nature (numbered/unnumbered). Instead of hard coding it with the worst case number, let the network administrator, that is aware of the network nature, configure it. Thanks, Nurit. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Nov 2003 21:35:01 +0000 Message-Id: <4.3.2.7.2.20031110161118.02e8fee8@mo-ex1> Date: Mon, 10 Nov 2003 16:32:31 -0500 To: ccamp@ops.ietf.org From: Lou Berger Subject: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_46891556==_" --=====================_46891556==_ Content-Type: text/plain; charset="us-ascii"; format=flowed In the morning's meeting the AD's asked to bring the proposed Alarm communication extension to "the list". For today's presentation see: http://www.labn.net/docs/AlarmSpec00.pdf I believe the issues to be discussed are: 1) Is there general interest in this work? 2) Should the usage of new TLVs in Error_Spec be permitted? (We think there's some value, particularly with string and timestamp) 3) Are there good references for alarm code points? Thank, Lou (and co-authors) >Subject: I-D ACTION:draft-berger-ccamp-gmpls-alarm-spec-00.txt >Date: Mon, 20 Oct 2003 15:40:44 -0400 >From: >Reply-To: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : GMPLS - Communication of Alarm Information > Author(s) : L. Berger > Filename : draft-berger-ccamp-gmpls-alarm-spec-00.txt > Pages : 13 > Date : 2003-10-20 > >This document describes an extension to Generalized MPLS (Multi- >Protocol Label Switching) signaling to support communication of alarm >information. GMPLS signaling already supports the control of alarm >reporting, but not the communication of alarm information. This >document presents both a functional description and GMPLS-RSVP >specifics of such an extension. This document also proposes >modification of the RSVP ERROR_SPEC object. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-berger-ccamp-gmpls-alarm-spec-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > --=====================_46891556==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ATT05498.TXT" Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-20144612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-00.txt --=====================_46891556==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-berger-ccamp-gmpls-alarm-spec-00.URL" [InternetShortcut] URL=ftp://ftp.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-00.txt --=====================_46891556==_-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Nov 2003 20:54:56 +0000 Reply-To: From: "Vishal Sharma" To: "Diego Caviglia" , Subject: RE: Source routed Notify message Date: Mon, 10 Nov 2003 12:50:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Diego, I think the problem you're looking at is still a bit ill-defined. (BTW, you have two nodes labeled H in the fig. below, which one is A trying to inform?) Assuming that the lower rightmost node is H, here are a few questions... Are you assuming, for example, that the DCN used for the SDH/SONET network uses an associated control plane (with the same topology as the data plane)? If not, then the IP message from A should be able to find its way easily enough to H, via the DCN. Further, if "lower layer" data plane mechanisms are at work, then the same mechanisms would have informed H as well, so why does A need to do anything special to inform H? In any case, since the Notify message is an IP packet, it could always be IP source-routed (if A so desired), with some attendant limitations on size of course. -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Diego Caviglia > Sent: Monday, November 10, 2003 8:17 AM > To: ccamp@ops.ietf.org > Subject: Source routed Notify message > > > Hi all, > is there anyone interested in having source routed, may by > means of standard ERO obj, Notify [RFC3473] message? > > The motivation to use a source routing mechanism for Notify is avoiding > OSPF convergence time during a network failure. > > The scenario I've in mind is the following: > > A---------------B---------------C > | | | > | | | > | | | > D---------------E---------------F > | | | > | | | > | | | > G---------------H---------------H > > Suppose there is a LSP (SDN/SONET) from H (Ingress) to A (Egress) and an > unidirectional failure occours between C and F in the H-->A direction. > Low layer mechanism (e.g AIS), informs A that a failure has > occourred. TNE > A wants to notify H about the failure but OSPF tables have not > been updated > thus TNA A knows that "normal routing" will have some problem in > delivering > the Notify to TNE H. > > A source routed path calculated using Link diversity with respect to the > failed LSP can avoid OSPF convergence time and inform efficently TNE H > about the failure of the LSP. > > That can be done either using the source route of the Ip header or using > the ERO object. The former has some limitation while the latter is > larghely used in GMPLS. > > Ragrds > > Diego > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Nov 2003 16:20:11 +0000 Sensitivity: Subject: Source routed Notify message To: ccamp@ops.ietf.org From: "Diego Caviglia" Date: Mon, 10 Nov 2003 17:16:49 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi all, is there anyone interested in having source routed, may by means of standard ERO obj, Notify [RFC3473] message? The motivation to use a source routing mechanism for Notify is avoiding OSPF convergence time during a network failure. The scenario I've in mind is the following: A---------------B---------------C | | | | | | | | | D---------------E---------------F | | | | | | | | | G---------------H---------------H Suppose there is a LSP (SDN/SONET) from H (Ingress) to A (Egress) and an unidirectional failure occours between C and F in the H-->A direction. Low layer mechanism (e.g AIS), informs A that a failure has occourred. TNE A wants to notify H about the failure but OSPF tables have not been updated thus TNA A knows that "normal routing" will have some problem in delivering the Notify to TNE H. A source routed path calculated using Link diversity with respect to the failed LSP can avoid OSPF convergence time and inform efficently TNE H about the failure of the LSP. That can be done either using the source route of the Ip header or using the ERO object. The former has some limitation while the latter is larghely used in GMPLS. Ragrds Diego Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Nov 2003 15:20:45 +0000 Reply-To: From: "Thomas D. Nadeau" To: "'Adrian Farrel'" , Subject: RE: Latest versions of GMPLS MIBs Date: Mon, 10 Nov 2003 10:16:57 -0500 Organization: Cisco Systems, inc. Message-ID: <000901c3a79d$d53525c0$688b8182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Do you have time Monday after CCAMP and lunch to go over the outstanding MIB issues? --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Nov 2003 21:18:15 +0000 Message-ID: <4A0AE1E5A1AAD711AC1B00D0B7C2D4A2447E4A@cms1> From: yhwkim@etri.re.kr To: ccamp@ops.ietf.org Subject: Discussion for interaction bet'n GMPLS RSVP-TE and LCAS Date: Mon, 10 Nov 2003 06:10:42 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A705.EF5D73A0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A705.EF5D73A0 Content-Type: text/plain; charset="euc-kr" Hi, I've posted my draft with the title, "Interaction between GMPLS RSVP-TE and LCAS (draft-kim-ccamp-interaction-grsvpte-lcas-00.txt)" to the internet-draft site. And, I received an e-mail from Adrian Farrel that if I want disccusion on the mailing list about the draft. Although I do not get a chance to present the draft, of cource, I want to handle interaction issues between GMPLS RSVP-TE and LCAS on the mailing list. I think that the first issues to be handled is whether ccampers have a need for this function and whether ccampers support my approach. I'm looking forward to your interests. Thanks, Young ------_=_NextPart_001_01C3A705.EF5D73A0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Discussion for interaction bet'n GMPLS RSVP-TE and LCAS

Hi,

I've posted my draft with the title, = "Interaction between GMPLS RSVP-TE and LCAS
(draft-kim-ccamp-interaction-grsvpte-lcas-00.txt)" to the = internet-draft site.
And, I received an e-mail from Adrian Farrel that if = I want disccusion on the mailing list about the draft.
Although I do not get a chance to present the draft, = of cource, I want to handle interaction issues between GMPLS RSVP-TE = and LCAS on the mailing list.

I think that the first issues to be handled is = whether ccampers have a need for this function and
whether ccampers support my approach.

I'm looking forward to your interests.

Thanks,
Young


 

------_=_NextPart_001_01C3A705.EF5D73A0-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Nov 2003 14:46:53 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048D77@nimbus.chromisys.com> From: John Drake To: "'Ong, Lyndon'" , 'Adrian Farrel' , Jonathan Sadler , "Varma, Eve L (Eve)" , dimitris@us.ibm.com Cc: ccamp@ops.ietf.org Subject: RE: draft-ong-ccamp-3473-3474-iw-00.txt Date: Sun, 9 Nov 2003 06:42:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Comments inline > -----Original Message----- > From: Ong, Lyndon [mailto:LyOng@Ciena.com] > Sent: Friday, November 07, 2003 2:41 PM > To: 'Adrian Farrel'; Jonathan Sadler; Varma, Eve L (Eve); > dimitris@us.ibm.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-ong-ccamp-3473-3474-iw-00.txt > > > Hi Adrian, John, > > Thank you for the comments. The document is a work in progress > and could certainly use input. I decided to put some initial > responses to > your comments into a single email rather than parcel things out. > > > First Adrian's issues: > > a) SPC services - while 3473 provides some functionality > associated with SPC such as egress label specification, there > is no explicit definition of SPC service (esp. ASON SPC > service) in either 3471 or 3473. In fact, > you point out that there are several possible techniques > that could be applied. > > 3474 defines a specific mechanism for ASON SPC service > using an SPC_Label sub-object. It has one benefit of marking > connections explicitly as SPC connections, while explicit label > control does not. It has the drawback that both ends need to > understand the sub-object, but, then, it's a new service, > so that shouldn't be surprising. > > b) Restart - I'll defer to restart experts here. If there are > issues it would be good to find these out! I would hope, though, > that GMPLS restart procedures are robust enough that you can add > persistent storage to a system without interfering with the > restart procedure. > > BTW, it should be clear to people that 3474 defines an interface > between two nodes, it does not define a nodal characteristic. It > would be very natural to have a border node with both 3474 and 3473 > interfaces. > > c) Call_ID and Call_OPS - I think you're right, if a 3473 node > sends PathErr, you would need to regenerate Call_ID and Call_OPS > at the interworking point. More on calls/connections later... > > > John's issues: > > d) client address space - as I understand it, Hamid's GVPN draft > calls for the PE to support some mapping of the identifiers at the > CE-PE boundary, allowing the CE to use a separate identifier space. JD: You misunderstood. You made an assertion about a separate address object, 'It also allows full overlap of the client address range with the address range used in the network, since separate objects are used for each.', that I questioned. I then offered a counter example, Hamid's I-D, to show that this functionality does NOT require a separate address object. > 3474 uses a different mechanism, with its own characteristics: > the TNA is allowed to take on formats other than IP address, it > is carried transparently across the intervening subnetworks, and > it is intended to be unique within a carrier domain, more like a > telephone number (whereas the GVPN identifier is local to the > particular GVPN). Both mechanisms can work, they are aimed at > different applications. JD: As described in my previous comment, addresses carried in RSVP messages in the normal way, e.g., RFC3473 compliant networks, would have the same characteristics you describe. (Non IP address support in a GMPLS ASON network is not required but could be supported in a variety of ways based upon the techniques described in Hamid's I-D.) > > It sounds like some of the mapping functions might be similar, > though. > > e) call without connection - this is frankly an area where there > has not been much implementation as yet and does need more work. JD: I would agree with this statement wrt to RFC 3474/G.7713.2. > > On your specific comment I would expect that a PATH for call without > connection would be addressed at the IP level to a destination that > is 3474-capable and bypass intermediate nodes that are not > 3474-capable. > That could avoid the problem of intermediate GMPLS nodes > actually allocating > resources. Also, the specific encoding of Label_Request, Sender_TSpec > and Upstream_Label objects for call without connection is not defined > in 3474 or G.7713.2 so it's not clear what resources if any would end > up being reserved. One way to approach this might be to identify > suggested encodings that would cause no resources to be reserved. JD: This wouldn't work, since you're still instantiating state in all of the intermediate nodes. I would agree with your comment that many things are not defined in RFC 3474/G.7713.2. > > > > Cheers, > > Lyndon > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Nov 2003 17:19:56 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502D95759@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Martin Dubuc , Adrian Farrel , jplang@ieee.org Cc: ccamp@ops.ietf.org, "Wijnen, Bert (Bert)" Subject: RE: LMP MIB revision 7 Date: Sat, 8 Nov 2003 18:17:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thanks. Before you submit, pls wait for me to completely review the document. It may have to wait till after IETF cause I am pretty busy this week (as I am sure you undestand). Thanks, Bert > -----Original Message----- > From: Martin Dubuc [mailto:dubuc.consulting@rogers.com] > Sent: zaterdag 8 november 2003 16:59 > To: Adrian Farrel; jplang@ieee.org > Cc: ccamp@ops.ietf.org; Wijnen, Bert (Bert) > Subject: Re: LMP MIB revision 7 > > > Adrian, > > Your interpretation of lmpCcUnderlyingIfIndex and lmpCcIsIf > is correct and I > like the clarifications that you are recommending. I can add > these to the > upcoming version of the MIB (which I should release shortly). > > Martin > > ----- Original Message ----- > From: "Adrian Farrel" > To: ; > Cc: ; "Wijnen, Bert (Bert)" > Sent: Friday, November 07, 2003 7:08 AM > Subject: LMP MIB revision 7 > > > > Hi, > > > > We're trying to wrap our brains around a couple of objects > in the LMP MIB. > They are > > lmpCcUnderlyingIfIndex and lmpCcIsIf. > > > > On the face of it, they seem to overlap because a zero value of > lmpCcUnderlyingIfIndex > > surely shows that the control channel is not associated > with an interface. > > > > However, I think you are trying to convey two separate concepts: > > - control channel is modelled as an interface or not > > - control channel is modelled as an interface *and* > > control channel is associated with an interface or not > > > > Is this correct? > > > > This would give rise to three possible outcomes > > - not modelled as interface > > lmpCcIsIf == false > > lmpCcUnderlyingIfIndex == 0 > > - modelled as interface but no interface associated > > lmpCcIsIf == true > > lmpCcUnderlyingIfIndex == 0 > > - modelled as interface and interface associated > > lmpCcIsIf == true > > lmpCcUnderlyingIfIndex != 0 > > > > OK so far? > > > > So now I have some questions with putative answers. Perhaps > you could > confirm? > > > > - Under what circumstances can you model the cc as an > > interface but not have one assigned? > > Answer: > > When one has not yet been configured or discovered (or > > assigned by the software - small window?) > > - Can LMP operate when the cc is modelled as an interface > > but one is not assigned? > > Answer: > > No. Under these circumstances, no LMP messages can > > be sent on the control channel. > > - What does it mean to say that the control channel is not > > modelled as an interface? > > Answer: > > This simply means that the control channel does not appear > > in the ifTable. It has no other meaning with respect to the > > operation of LMP. > > - Do we care to distinguish the case of {modelled but not assigned} > > from {not modelled}? > > Answer: > > Yes. With {not modelled} LMP can continue to operate as > > usual. With {modelled but not assigned} LMP must wait until > > an ifIndex is assigned before it can operate. > > > > In view of this, (and if I am right in all of the above) I > wonder if we > can clean up the > > description of lmpCcUnderlyingIfIndex > > From > > "This value represents the underlying interface index, i.e. > > the interface index of the interface over which the LMP > > interface will transmit its traffic. If set to 0, then the > > control channel is not associated with any underlying > > interface. If the control channel is not associated with an > > underlying interface, the control channel's operational > > status must not be up(1), nor should the control channel > > forward or receive traffic." > > To > > "If lmpCcIsIf is set to true(1), this object carries > the index > > into the ifTable of the entry that represents the LMP > > interface over which LMP will transmit its traffic. > > If this object is set to zero, but lmpCcIsIf is set > to true(1), > > the control channel is not currently associated with any > > underlying interface and the control channel's operational > > status must not be up(1), nor should the control channel > > forward or receive traffic. > > If lmpCcIsIf is set to false(2), this object should be set > > to zero and should be ignored." > > > > Similarly, can we change the description of lmpCcIsIf > > From > > "In implementations where the control channels are modeled > > as interfaces, the value of this object is true(1) and > > this control channel is represented by an interface in > > the interfaces group table. If control channels are not > > modeled as interfaces, the value of this object is > > false(2) and there are no corresponding interface for > > this control channel in the interfaces group table." > > To > > "In implementations where the control channels are modeled > > as interfaces, the value of this object is true(1) and > > this control channel is represented by an interface in > > the interfaces group table as indicated by the value of > > lmpCcUnderlyingIfIndex. If control channels are not > > modeled as interfaces, the value of this object is > > false(2), there is no corresponding interface for > > this control channel in the interfaces group table, > > and the value of lmpCcUnderlyingIfIndex should be > > ignored." > > > > We could also usefully add text to section 8 (Application of the > Interfaces Group to LMP) > > to say (right at the end of the section) ... > > > > "Note that it is not a requirement that LMP control > channels be modeled as > interfaces. It > > is acceptable that control channels simply exist as logical > connections > between adjacent > > LMP-capable nodes. In this case, lmpCcIsIf is set to false(2) and no > corresponding entry > > is made in the ifTable." > > > > Thanks a lot, > > Adrian > > > > ----- Original Message ----- > > From: "Wijnen, Bert (Bert)" > > To: "Adrian Farrel" > > Cc: "'Kireeti Kompella'" ; > ; "Wijnen, > Bert (Bert)" > > > > Sent: Thursday, November 06, 2003 3:12 PM > > Subject: RE: LMP MIB revision 6/7 > > > > > > > Mmmm... it helps somewhat... Maybe I get confused by: > > > > > lmpCcUnderlyingIfIndex OBJECT-TYPE > > > > > SYNTAX InterfaceIndexOrZero > > > > > MAX-ACCESS read-create > > > > > STATUS current > > > > > DESCRIPTION > > > > > "This value represents the underlying > interface index, i.e. > > > > > the interface index of the interface over > which the LMP > > > > > interface will transmit its traffic. If set > to 0, then the > > > s/interface/control channel/ ??? if so then it starts to be > understandbale > > > the way you described it. > > > > > > > > control channel is not associated with any underlying > > > > > interface. > > > > > > But even so: > > > > > interface. If the control channel is not > associated with an > > > > > underlying interface, the control channel's > operational > > > > > status must not be up(1), nor should the > control channel > > > > > forward or receive traffic." > > > > > > So what does that mean? that there can be no trafiic over > the control > > > channel if the cc is not associated with a underlying iface?? > > > > > > Maybe you can bring up the discussion on the WG mailing list. > > > I tried a few times and got nowhere. Maybe with your > questioning and > > > your proposed inetrpretation below, thing will become clearer and > > > will hopefully result in descriptions that are understandable for > > > mere mortals like myself? > > > > > > Thanks, > > > Bert > > > > > > > -----Original Message----- > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > Sent: woensdag 5 november 2003 18:01 > > > > To: Wijnen, Bert (Bert) > > > > Cc: 'Kireeti Kompella'; zinin@psg.com; Wijnen, Bert (Bert) > > > > Subject: Re: LMP MIB revision 6/7 > > > > > > > > > > > > My understanding here is (probably wrong as well)-: > > > > > > > > They are trying to handle two distinct things: > > > > - control channel is modelled as an interface or not > > > > - control channel is modelled as an interface *and* > > > > control channel is associated with an interface or not > > > > > > > > Thus there are three possible outcomes > > > > - not modelled as interface > > > > lmpCcIsIf == false > > > > lmpCcUnderlyingIfIndex == 0 > > > > - modelled as interface but no interface associated > > > > lmpCcIsIf == true > > > > lmpCcUnderlyingIfIndex == 0 > > > > - modelled as interface and interface associated > > > > lmpCcIsIf == true > > > > lmpCcUnderlyingIfIndex != 0 > > > > > > > > The reasonable questions are > > > > - Under what circumstances can you model the cc as an > > > > interface but not have one assigned? > > > > Answer: When one has not yet been configured or discovered > > > > (or assigned by the software - small window?) > > > > - Do we care to distinguish the case of {modelled but > not assigned} > > > > from {not modelled}? > > > > Answer: This is unclear to me, but it might be that an > > > > implementation > > > > needs a trigger to perform discovery. This trigger would be > > > > provided by {lmpCcIsIf == true, lmpCcUnderlyingIfIndex == 0} > > > > where the single field would not provide enough information. > > > > Similarly, if there is a need for gating user > configuration of a cc > > > > interface, then this would be achieved by the > lmpCcIsIf object, but > > > > I consider this more spurious. > > > > > > > > Does this help? > > > > > > > > Adrian > > > > > lmpCcUnderlyingIfIndex OBJECT-TYPE > > > > > SYNTAX InterfaceIndexOrZero > > > > > MAX-ACCESS read-create > > > > > STATUS current > > > > > DESCRIPTION > > > > > "This value represents the underlying > interface index, i.e. > > > > > the interface index of the interface over > which the LMP > > > > > interface will transmit its traffic. If set > to 0, then the > > > > > control channel is not associated with any underlying > > > > > interface. If the control channel is not > associated with an > > > > > underlying interface, the control channel's > operational > > > > > status must not be up(1), nor should the > control channel > > > > > forward or receive traffic." > > > > > ::= { lmpControlChannelEntry 2 } > > > > > > > > > > lmpCcIsIf OBJECT-TYPE > > > > > SYNTAX TruthValue > > > > > MAX-ACCESS read-create > > > > > STATUS current > > > > > DESCRIPTION > > > > > "In implementations where the control channels > are modeled > > > > > as interfaces, the value of this object is true(1) and > > > > > this control channel is represented by an interface in > > > > > the interfaces group table. If control > channels are not > > > > > modeled as interfaces, the value of this object is > > > > > false(2) and there are no corresponding interface for > > > > > this control channel in the interfaces group table." > > > > > ::= { lmpControlChannelEntry 3 } > > > > > > > > > > Do you understand that and does it make sense to you. > > > > > To me it seems the two are either overlapping, or conflicting, > > > > > or I just do not understand. I suspect it is the latter. > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Nov 2003 16:05:00 +0000 Message-ID: <004301c3a611$3cefa8e0$2202a8c0@flfrd.phub.net.cable.rogers.com> From: "Martin Dubuc" To: "Adrian Farrel" , Cc: , "Wijnen, Bert \(Bert\)" Subject: Re: LMP MIB revision 7 Date: Sat, 8 Nov 2003 10:59:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian, Your interpretation of lmpCcUnderlyingIfIndex and lmpCcIsIf is correct and I like the clarifications that you are recommending. I can add these to the upcoming version of the MIB (which I should release shortly). Martin ----- Original Message ----- From: "Adrian Farrel" To: ; Cc: ; "Wijnen, Bert (Bert)" Sent: Friday, November 07, 2003 7:08 AM Subject: LMP MIB revision 7 > Hi, > > We're trying to wrap our brains around a couple of objects in the LMP MIB. They are > lmpCcUnderlyingIfIndex and lmpCcIsIf. > > On the face of it, they seem to overlap because a zero value of lmpCcUnderlyingIfIndex > surely shows that the control channel is not associated with an interface. > > However, I think you are trying to convey two separate concepts: > - control channel is modelled as an interface or not > - control channel is modelled as an interface *and* > control channel is associated with an interface or not > > Is this correct? > > This would give rise to three possible outcomes > - not modelled as interface > lmpCcIsIf == false > lmpCcUnderlyingIfIndex == 0 > - modelled as interface but no interface associated > lmpCcIsIf == true > lmpCcUnderlyingIfIndex == 0 > - modelled as interface and interface associated > lmpCcIsIf == true > lmpCcUnderlyingIfIndex != 0 > > OK so far? > > So now I have some questions with putative answers. Perhaps you could confirm? > > - Under what circumstances can you model the cc as an > interface but not have one assigned? > Answer: > When one has not yet been configured or discovered (or > assigned by the software - small window?) > - Can LMP operate when the cc is modelled as an interface > but one is not assigned? > Answer: > No. Under these circumstances, no LMP messages can > be sent on the control channel. > - What does it mean to say that the control channel is not > modelled as an interface? > Answer: > This simply means that the control channel does not appear > in the ifTable. It has no other meaning with respect to the > operation of LMP. > - Do we care to distinguish the case of {modelled but not assigned} > from {not modelled}? > Answer: > Yes. With {not modelled} LMP can continue to operate as > usual. With {modelled but not assigned} LMP must wait until > an ifIndex is assigned before it can operate. > > In view of this, (and if I am right in all of the above) I wonder if we can clean up the > description of lmpCcUnderlyingIfIndex > From > "This value represents the underlying interface index, i.e. > the interface index of the interface over which the LMP > interface will transmit its traffic. If set to 0, then the > control channel is not associated with any underlying > interface. If the control channel is not associated with an > underlying interface, the control channel's operational > status must not be up(1), nor should the control channel > forward or receive traffic." > To > "If lmpCcIsIf is set to true(1), this object carries the index > into the ifTable of the entry that represents the LMP > interface over which LMP will transmit its traffic. > If this object is set to zero, but lmpCcIsIf is set to true(1), > the control channel is not currently associated with any > underlying interface and the control channel's operational > status must not be up(1), nor should the control channel > forward or receive traffic. > If lmpCcIsIf is set to false(2), this object should be set > to zero and should be ignored." > > Similarly, can we change the description of lmpCcIsIf > From > "In implementations where the control channels are modeled > as interfaces, the value of this object is true(1) and > this control channel is represented by an interface in > the interfaces group table. If control channels are not > modeled as interfaces, the value of this object is > false(2) and there are no corresponding interface for > this control channel in the interfaces group table." > To > "In implementations where the control channels are modeled > as interfaces, the value of this object is true(1) and > this control channel is represented by an interface in > the interfaces group table as indicated by the value of > lmpCcUnderlyingIfIndex. If control channels are not > modeled as interfaces, the value of this object is > false(2), there is no corresponding interface for > this control channel in the interfaces group table, > and the value of lmpCcUnderlyingIfIndex should be > ignored." > > We could also usefully add text to section 8 (Application of the Interfaces Group to LMP) > to say (right at the end of the section) ... > > "Note that it is not a requirement that LMP control channels be modeled as interfaces. It > is acceptable that control channels simply exist as logical connections between adjacent > LMP-capable nodes. In this case, lmpCcIsIf is set to false(2) and no corresponding entry > is made in the ifTable." > > Thanks a lot, > Adrian > > ----- Original Message ----- > From: "Wijnen, Bert (Bert)" > To: "Adrian Farrel" > Cc: "'Kireeti Kompella'" ; ; "Wijnen, Bert (Bert)" > > Sent: Thursday, November 06, 2003 3:12 PM > Subject: RE: LMP MIB revision 6/7 > > > > Mmmm... it helps somewhat... Maybe I get confused by: > > > > lmpCcUnderlyingIfIndex OBJECT-TYPE > > > > SYNTAX InterfaceIndexOrZero > > > > MAX-ACCESS read-create > > > > STATUS current > > > > DESCRIPTION > > > > "This value represents the underlying interface index, i.e. > > > > the interface index of the interface over which the LMP > > > > interface will transmit its traffic. If set to 0, then the > > s/interface/control channel/ ??? if so then it starts to be understandbale > > the way you described it. > > > > > > control channel is not associated with any underlying > > > > interface. > > > > But even so: > > > > interface. If the control channel is not associated with an > > > > underlying interface, the control channel's operational > > > > status must not be up(1), nor should the control channel > > > > forward or receive traffic." > > > > So what does that mean? that there can be no trafiic over the control > > channel if the cc is not associated with a underlying iface?? > > > > Maybe you can bring up the discussion on the WG mailing list. > > I tried a few times and got nowhere. Maybe with your questioning and > > your proposed inetrpretation below, thing will become clearer and > > will hopefully result in descriptions that are understandable for > > mere mortals like myself? > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: woensdag 5 november 2003 18:01 > > > To: Wijnen, Bert (Bert) > > > Cc: 'Kireeti Kompella'; zinin@psg.com; Wijnen, Bert (Bert) > > > Subject: Re: LMP MIB revision 6/7 > > > > > > > > > My understanding here is (probably wrong as well)-: > > > > > > They are trying to handle two distinct things: > > > - control channel is modelled as an interface or not > > > - control channel is modelled as an interface *and* > > > control channel is associated with an interface or not > > > > > > Thus there are three possible outcomes > > > - not modelled as interface > > > lmpCcIsIf == false > > > lmpCcUnderlyingIfIndex == 0 > > > - modelled as interface but no interface associated > > > lmpCcIsIf == true > > > lmpCcUnderlyingIfIndex == 0 > > > - modelled as interface and interface associated > > > lmpCcIsIf == true > > > lmpCcUnderlyingIfIndex != 0 > > > > > > The reasonable questions are > > > - Under what circumstances can you model the cc as an > > > interface but not have one assigned? > > > Answer: When one has not yet been configured or discovered > > > (or assigned by the software - small window?) > > > - Do we care to distinguish the case of {modelled but not assigned} > > > from {not modelled}? > > > Answer: This is unclear to me, but it might be that an > > > implementation > > > needs a trigger to perform discovery. This trigger would be > > > provided by {lmpCcIsIf == true, lmpCcUnderlyingIfIndex == 0} > > > where the single field would not provide enough information. > > > Similarly, if there is a need for gating user configuration of a cc > > > interface, then this would be achieved by the lmpCcIsIf object, but > > > I consider this more spurious. > > > > > > Does this help? > > > > > > Adrian > > > > lmpCcUnderlyingIfIndex OBJECT-TYPE > > > > SYNTAX InterfaceIndexOrZero > > > > MAX-ACCESS read-create > > > > STATUS current > > > > DESCRIPTION > > > > "This value represents the underlying interface index, i.e. > > > > the interface index of the interface over which the LMP > > > > interface will transmit its traffic. If set to 0, then the > > > > control channel is not associated with any underlying > > > > interface. If the control channel is not associated with an > > > > underlying interface, the control channel's operational > > > > status must not be up(1), nor should the control channel > > > > forward or receive traffic." > > > > ::= { lmpControlChannelEntry 2 } > > > > > > > > lmpCcIsIf OBJECT-TYPE > > > > SYNTAX TruthValue > > > > MAX-ACCESS read-create > > > > STATUS current > > > > DESCRIPTION > > > > "In implementations where the control channels are modeled > > > > as interfaces, the value of this object is true(1) and > > > > this control channel is represented by an interface in > > > > the interfaces group table. If control channels are not > > > > modeled as interfaces, the value of this object is > > > > false(2) and there are no corresponding interface for > > > > this control channel in the interfaces group table." > > > > ::= { lmpControlChannelEntry 3 } > > > > > > > > Do you understand that and does it make sense to you. > > > > To me it seems the two are either overlapping, or conflicting, > > > > or I just do not understand. I suspect it is the latter. > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Nov 2003 07:13:45 +0000 Subject: Re: draft-ong-ccamp-3473-3474-iw-00.txt To: LyOng@Ciena.com (Ong, Lyndon) Date: Sat, 8 Nov 2003 07:12:01 +0000 (GMT) Cc: adrian@olddog.co.uk ('Adrian Farrel'), jonathan.sadler@tellabs.com (Jonathan Sadler), evarma@lucent.com ("Varma, Eve L (Eve)"), dimitris@us.ibm.com, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou hi lyndon, see in-line for some additional comments: Ong, Lyndon wrote: > Hi Adrian, John, > > Thank you for the comments. The document is a work in progress > and could certainly use input. I decided to put some initial responses to > your comments into a single email rather than parcel things out. > > First Adrian's issues: > > a) SPC services - while 3473 provides some functionality > associated with SPC such as egress label specification, there > is no explicit definition of SPC service (esp. ASON SPC > service) in either 3471 or 3473. In fact, > you point out that there are several possible techniques > that could be applied. > > 3474 defines a specific mechanism for ASON SPC service > using an SPC_Label sub-object. It has one benefit of marking > connections explicitly as SPC connections, while explicit label > control does not. It has the drawback that both ends need to > understand the sub-object, but, then, it's a new service, > so that shouldn't be surprising. it has the drawback of imposing the support of G_UNI processing (containing the SPC_label) where SPC will start/end and thus break one of the paradigms being the independence of UNI and NNI implementation - also the interworking function should allow for asymmetric environment (and not only symmetric as presented), therefore the SPC_label which is in fact a sub-object including two fields an interface_id and a label, the question becomes what happens when the ERO includes only an interface_id (note that the same issue arise with the RFC3474 egress label for switched connections) note that "marking" services is not "advantageous" for intermediate subnetworks/domains while 3473 end-points can deduce this very easily without requiring any explicit marking > b) Restart - I'll defer to restart experts here. If there are > issues it would be good to find these out! I would hope, though, > that GMPLS restart procedures are robust enough that you can add > persistent storage to a system without interfering with the > restart procedure. > > BTW, it should be clear to people that 3474 defines an interface > between two nodes, it does not define a nodal characteristic. It > would be very natural to have a border node with both 3474 and 3473 > interfaces. you may want also to take a look at the appendix of > c) Call_ID and Call_OPS - I think you're right, if a 3473 node > sends PathErr, you would need to regenerate Call_ID and Call_OPS > at the interworking point. More on calls/connections later... additionally there is no "notify" message interworking possible except if it is explicitly asked to change the ip address within the notify request object to be the interworking point > John's issues: > > d) client address space - as I understand it, Hamid's GVPN draft > calls for the PE to support some mapping of the identifiers at the > CE-PE boundary, allowing the CE to use a separate identifier space. > 3474 uses a different mechanism, with its own characteristics: > the TNA is allowed to take on formats other than IP address, it > is carried transparently across the intervening subnetworks, and > it is intended to be unique within a carrier domain, more like a > telephone number (whereas the GVPN identifier is local to the > particular GVPN). Both mechanisms can work, they are aimed at > different applications. this "transparency" is limited due to two major issues: 1. interworking is not necessarily symmetric (there is no reason why the other end-point can process the RFC3474 information) so each ingress must be aware of the capabilities of the end- point in terms of RFC3474 support 2. whenever applying the IWF, a "TNA lookup" is needed obliging any intermediate node that performs such operations to support all the addressing schemes 3. it is also interesting to know how the ingress core-node will be made aware of the reachable TNA's ? note also that the topological examples given in the iw i-d are rather simplistic and one can be sure that at the end the control plane will end up by performing iw'ing at each node > It sounds like some of the mapping functions might be similar, > though. the main issue comparing to the gmpls vpn approach is that the latter refers to "identifiers" while TNA refers to "Addresses" allowing the transport of the latter as explained here above is more complex than the approach proposed in gmpls-vpn which performs the translation at the edges of the provider network - the section 2.2 of the gmpls vpn i-d explains this - > e) call without connection - this is frankly an area where there > has not been much implementation as yet and does need more work. then please indicate this more clearly in the introductory sections - also section 3.3 gives the impression that 3474 does meet the identified requirements while in fact (if i well understand your statement) it does not > On your specific comment I would expect that a PATH for call without > connection would be addressed at the IP level to a destination that > is 3474-capable and bypass intermediate nodes that are not 3474-capable. > That could avoid the problem of intermediate GMPLS nodes actually allocating > resources. Also, the specific encoding of Label_Request, Sender_TSpec > and Upstream_Label objects for call without connection is not defined > in 3474 or G.7713.2 so it's not clear what resources if any would end > up being reserved. One way to approach this might be to identify > suggested encodings that would cause no resources to be reserved. here the problem is that the for call w/o connection the use of the RFC3474 technique is simply not appropriated, the method proposed here above does not solve the problem in the sense that these specific values (and corr. processing) aren't supported by the standard RFC 3473 nodes anyway ps: i don't see described also the iw for the extended_tunnel id of the uni/e_nni session objects (C-Type 11/12 and 15/16) that rfc 3474 requires when crossing these ref points. thanks, - dimitri. > Cheers, > > Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Nov 2003 22:42:21 +0000 Message-ID: <829F074A10F98943A218DC363D09C92AAE61BF@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Adrian Farrel' , Jonathan Sadler , "Varma, Eve L (Eve)" , dimitris@us.ibm.com Cc: ccamp@ops.ietf.org Subject: RE: draft-ong-ccamp-3473-3474-iw-00.txt Date: Fri, 7 Nov 2003 14:40:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Adrian, John, Thank you for the comments. The document is a work in progress and could certainly use input. I decided to put some initial responses to your comments into a single email rather than parcel things out. First Adrian's issues: a) SPC services - while 3473 provides some functionality associated with SPC such as egress label specification, there is no explicit definition of SPC service (esp. ASON SPC service) in either 3471 or 3473. In fact, you point out that there are several possible techniques that could be applied. 3474 defines a specific mechanism for ASON SPC service using an SPC_Label sub-object. It has one benefit of marking connections explicitly as SPC connections, while explicit label control does not. It has the drawback that both ends need to understand the sub-object, but, then, it's a new service, so that shouldn't be surprising. b) Restart - I'll defer to restart experts here. If there are issues it would be good to find these out! I would hope, though, that GMPLS restart procedures are robust enough that you can add persistent storage to a system without interfering with the restart procedure. BTW, it should be clear to people that 3474 defines an interface between two nodes, it does not define a nodal characteristic. It would be very natural to have a border node with both 3474 and 3473 interfaces. c) Call_ID and Call_OPS - I think you're right, if a 3473 node sends PathErr, you would need to regenerate Call_ID and Call_OPS at the interworking point. More on calls/connections later... John's issues: d) client address space - as I understand it, Hamid's GVPN draft calls for the PE to support some mapping of the identifiers at the CE-PE boundary, allowing the CE to use a separate identifier space. 3474 uses a different mechanism, with its own characteristics: the TNA is allowed to take on formats other than IP address, it is carried transparently across the intervening subnetworks, and it is intended to be unique within a carrier domain, more like a telephone number (whereas the GVPN identifier is local to the particular GVPN). Both mechanisms can work, they are aimed at different applications. It sounds like some of the mapping functions might be similar, though. e) call without connection - this is frankly an area where there has not been much implementation as yet and does need more work. On your specific comment I would expect that a PATH for call without connection would be addressed at the IP level to a destination that is 3474-capable and bypass intermediate nodes that are not 3474-capable. That could avoid the problem of intermediate GMPLS nodes actually allocating resources. Also, the specific encoding of Label_Request, Sender_TSpec and Upstream_Label objects for call without connection is not defined in 3474 or G.7713.2 so it's not clear what resources if any would end up being reserved. One way to approach this might be to identify suggested encodings that would cause no resources to be reserved. Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Nov 2003 15:47:22 +0000 Message-ID: <010901c3a545$f77e6c90$0901010a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: , "Wijnen, Bert \(Bert\)" Subject: LMP MIB revision 7 Date: Fri, 7 Nov 2003 12:08:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We're trying to wrap our brains around a couple of objects in the LMP MIB. They are lmpCcUnderlyingIfIndex and lmpCcIsIf. On the face of it, they seem to overlap because a zero value of lmpCcUnderlyingIfIndex surely shows that the control channel is not associated with an interface. However, I think you are trying to convey two separate concepts: - control channel is modelled as an interface or not - control channel is modelled as an interface *and* control channel is associated with an interface or not Is this correct? This would give rise to three possible outcomes - not modelled as interface lmpCcIsIf == false lmpCcUnderlyingIfIndex == 0 - modelled as interface but no interface associated lmpCcIsIf == true lmpCcUnderlyingIfIndex == 0 - modelled as interface and interface associated lmpCcIsIf == true lmpCcUnderlyingIfIndex != 0 OK so far? So now I have some questions with putative answers. Perhaps you could confirm? - Under what circumstances can you model the cc as an interface but not have one assigned? Answer: When one has not yet been configured or discovered (or assigned by the software - small window?) - Can LMP operate when the cc is modelled as an interface but one is not assigned? Answer: No. Under these circumstances, no LMP messages can be sent on the control channel. - What does it mean to say that the control channel is not modelled as an interface? Answer: This simply means that the control channel does not appear in the ifTable. It has no other meaning with respect to the operation of LMP. - Do we care to distinguish the case of {modelled but not assigned} from {not modelled}? Answer: Yes. With {not modelled} LMP can continue to operate as usual. With {modelled but not assigned} LMP must wait until an ifIndex is assigned before it can operate. In view of this, (and if I am right in all of the above) I wonder if we can clean up the description of lmpCcUnderlyingIfIndex From "This value represents the underlying interface index, i.e. the interface index of the interface over which the LMP interface will transmit its traffic. If set to 0, then the control channel is not associated with any underlying interface. If the control channel is not associated with an underlying interface, the control channel's operational status must not be up(1), nor should the control channel forward or receive traffic." To "If lmpCcIsIf is set to true(1), this object carries the index into the ifTable of the entry that represents the LMP interface over which LMP will transmit its traffic. If this object is set to zero, but lmpCcIsIf is set to true(1), the control channel is not currently associated with any underlying interface and the control channel's operational status must not be up(1), nor should the control channel forward or receive traffic. If lmpCcIsIf is set to false(2), this object should be set to zero and should be ignored." Similarly, can we change the description of lmpCcIsIf From "In implementations where the control channels are modeled as interfaces, the value of this object is true(1) and this control channel is represented by an interface in the interfaces group table. If control channels are not modeled as interfaces, the value of this object is false(2) and there are no corresponding interface for this control channel in the interfaces group table." To "In implementations where the control channels are modeled as interfaces, the value of this object is true(1) and this control channel is represented by an interface in the interfaces group table as indicated by the value of lmpCcUnderlyingIfIndex. If control channels are not modeled as interfaces, the value of this object is false(2), there is no corresponding interface for this control channel in the interfaces group table, and the value of lmpCcUnderlyingIfIndex should be ignored." We could also usefully add text to section 8 (Application of the Interfaces Group to LMP) to say (right at the end of the section) ... "Note that it is not a requirement that LMP control channels be modeled as interfaces. It is acceptable that control channels simply exist as logical connections between adjacent LMP-capable nodes. In this case, lmpCcIsIf is set to false(2) and no corresponding entry is made in the ifTable." Thanks a lot, Adrian ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "Adrian Farrel" Cc: "'Kireeti Kompella'" ; ; "Wijnen, Bert (Bert)" Sent: Thursday, November 06, 2003 3:12 PM Subject: RE: LMP MIB revision 6/7 > Mmmm... it helps somewhat... Maybe I get confused by: > > > lmpCcUnderlyingIfIndex OBJECT-TYPE > > > SYNTAX InterfaceIndexOrZero > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "This value represents the underlying interface index, i.e. > > > the interface index of the interface over which the LMP > > > interface will transmit its traffic. If set to 0, then the > s/interface/control channel/ ??? if so then it starts to be understandbale > the way you described it. > > > > control channel is not associated with any underlying > > > interface. > > But even so: > > > interface. If the control channel is not associated with an > > > underlying interface, the control channel's operational > > > status must not be up(1), nor should the control channel > > > forward or receive traffic." > > So what does that mean? that there can be no trafiic over the control > channel if the cc is not associated with a underlying iface?? > > Maybe you can bring up the discussion on the WG mailing list. > I tried a few times and got nowhere. Maybe with your questioning and > your proposed inetrpretation below, thing will become clearer and > will hopefully result in descriptions that are understandable for > mere mortals like myself? > > Thanks, > Bert > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: woensdag 5 november 2003 18:01 > > To: Wijnen, Bert (Bert) > > Cc: 'Kireeti Kompella'; zinin@psg.com; Wijnen, Bert (Bert) > > Subject: Re: LMP MIB revision 6/7 > > > > > > My understanding here is (probably wrong as well)-: > > > > They are trying to handle two distinct things: > > - control channel is modelled as an interface or not > > - control channel is modelled as an interface *and* > > control channel is associated with an interface or not > > > > Thus there are three possible outcomes > > - not modelled as interface > > lmpCcIsIf == false > > lmpCcUnderlyingIfIndex == 0 > > - modelled as interface but no interface associated > > lmpCcIsIf == true > > lmpCcUnderlyingIfIndex == 0 > > - modelled as interface and interface associated > > lmpCcIsIf == true > > lmpCcUnderlyingIfIndex != 0 > > > > The reasonable questions are > > - Under what circumstances can you model the cc as an > > interface but not have one assigned? > > Answer: When one has not yet been configured or discovered > > (or assigned by the software - small window?) > > - Do we care to distinguish the case of {modelled but not assigned} > > from {not modelled}? > > Answer: This is unclear to me, but it might be that an > > implementation > > needs a trigger to perform discovery. This trigger would be > > provided by {lmpCcIsIf == true, lmpCcUnderlyingIfIndex == 0} > > where the single field would not provide enough information. > > Similarly, if there is a need for gating user configuration of a cc > > interface, then this would be achieved by the lmpCcIsIf object, but > > I consider this more spurious. > > > > Does this help? > > > > Adrian > > > lmpCcUnderlyingIfIndex OBJECT-TYPE > > > SYNTAX InterfaceIndexOrZero > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "This value represents the underlying interface index, i.e. > > > the interface index of the interface over which the LMP > > > interface will transmit its traffic. If set to 0, then the > > > control channel is not associated with any underlying > > > interface. If the control channel is not associated with an > > > underlying interface, the control channel's operational > > > status must not be up(1), nor should the control channel > > > forward or receive traffic." > > > ::= { lmpControlChannelEntry 2 } > > > > > > lmpCcIsIf OBJECT-TYPE > > > SYNTAX TruthValue > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "In implementations where the control channels are modeled > > > as interfaces, the value of this object is true(1) and > > > this control channel is represented by an interface in > > > the interfaces group table. If control channels are not > > > modeled as interfaces, the value of this object is > > > false(2) and there are no corresponding interface for > > > this control channel in the interfaces group table." > > > ::= { lmpControlChannelEntry 3 } > > > > > > Do you understand that and does it make sense to you. > > > To me it seems the two are either overlapping, or conflicting, > > > or I just do not understand. I suspect it is the latter. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Nov 2003 02:29:32 +0000 Reply-To: From: "Vishal Sharma" To: "Diego Caviglia" , Subject: RE: Notify message with ERO Date: Thu, 6 Nov 2003 18:23:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Diego, Can you elaborate a bit on how you think this would be used? That is, some of the application(s) and benefits of having this. Thanks, -Vishal > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Diego Caviglia > Sent: Thursday, November 06, 2003 5:01 AM > To: ccamp@ops.ietf.org > Subject: Notify message with ERO > > > Hi all, > is there anyone interested in having source routed, by means > of standard ERO obj, Notify [RFC3473] message? > > > Thanks. > > Diego > > > > > ------------------------------------------ > Diego Caviglia > Marconi - Optical Networks > ASTN/GMPLS - System Design Manager > Via A. Negrone 1/A > 16153 Genoa - Italy > Phone: +390106003736 > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Nov 2003 13:05:20 +0000 Sensitivity: Subject: Notify message with ERO To: ccamp@ops.ietf.org From: "Diego Caviglia" Date: Thu, 6 Nov 2003 14:00:47 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi all, is there anyone interested in having source routed, by means of standard ERO obj, Notify [RFC3473] message? Thanks. Diego ------------------------------------------ Diego Caviglia Marconi - Optical Networks ASTN/GMPLS - System Design Manager Via A. Negrone 1/A 16153 Genoa - Italy Phone: +390106003736 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Nov 2003 23:58:46 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048D52@nimbus.chromisys.com> From: John Drake To: John Drake , 'Adrian Farrel' , "'Ong, Lyndon'" , 'Jonathan Sadler' , "'Varma, Eve L (Eve)'" , "'dimitris@us.ibm.com'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: draft-ong-ccamp-3473-3474-iw-00.txt Date: Wed, 5 Nov 2003 15:56:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Lyndon, Something else occured to me. One of the issues associated with RFC3474 is that in a network with RFC3473 compliant nodes, a call w/o connection will be treated by those nodes as a connection setup request and they will allocate resources to it. How does your interworking draft address this issue? Thanks, John P.S. Did you have any thoughts on my other question (below)? > -----Original Message----- > From: John Drake > Sent: Monday, November 03, 2003 3:56 PM > To: 'Adrian Farrel'; Ong, Lyndon; Jonathan Sadler; Varma, Eve L (Eve); > dimitris@us.ibm.com > Cc: ccamp@ops.ietf.org > Subject: RE: draft-ong-ccamp-3473-3474-iw-00.txt > > > Lyndon, > > I also had a question about the folllowing from Section 3.2: > 'It also allows full overlap of > the client address range with the address range used in the > network, since separate objects are > used for each.' Why do you think separate object are > required to support this? > > Are you familiar, for example, with > draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-04.txt? > > Thanks, > > John > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Saturday, November 01, 2003 6:12 PM > > To: Ong, Lyndon; Jonathan Sadler; Varma, Eve L (Eve); > > dimitris@us.ibm.com > > Cc: ccamp@ops.ietf.org > > Subject: draft-ong-ccamp-3473-3474-iw-00.txt > > > > > > Hi, > > > > A couple of quick questions... > > > > Section 3.3 says > > As RFC 3473 does not support call and connection separation > > or soft permanent connection > > > > But surely RFC 3473 does support soft permanent connections? > > There are several techniques, > > but perhaps the most popular is explicit label control. In > > view of this, you need to > > describe how you map between the two techniques when > > transiting between 3473 and 3474 > > network types. (Not just how you carry one technique across > > the other type of network, but > > how you handle the case where the end points are in different > > types of network.) > > > > > > Section 3.3 also says > > c) support for extended restart capabilities > > and > > (c) is a local procedure and has no interworking implications > > > > Are you sure that the Hello interactions and state recovery > > between 3473 and 3474 LSRs has > > no interworking implications? > > > > > > > > Section 5.4 says > > Other objects may be received at the 3474/3473 interface, > > esp. the Call_ID and Call_OPS objects defined in RFC 3474. > > These are passed transparently across the 3473 domain. > > > > This may be true, but you need to cover the case where the > > 3473 domain generates an error > > (such as PathErr). Presumably the mandatory Call_IS and > > Call_OPS are added back in to the > > message when it reaches the 3474 domain? > > > > > > Cheers, > > Adrian > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Nov 2003 12:09:38 +0000 Message-ID: <088d01c3a395$6d518720$f9919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Martin Dubuc" , "Wijnen, Bert \(Bert\)" Cc: "Ccamp-wg \(E-mail\)" Subject: Re: SMICng compile error on LMP MIB 7 Date: Wed, 5 Nov 2003 12:05:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Martin, The alternative would be to introduce padding bits such as reservedOne(5), reservedTwo(6) etc. However, I agree there is no reason to keep the bits spaced as in the protocol. Thanks, Adrian ----- Original Message ----- From: "Martin Dubuc" To: "Wijnen, Bert (Bert)" ; "Ccamp-wg (E-mail)" Sent: Wednesday, November 05, 2003 2:45 AM Subject: Re: SMICng compile error on LMP MIB 7 > Bert, > > The definition of this bit field was based on the specification of the > Verify Transport Mechanism field in the LMP draft. This field is a 2 byte > bit field (16 bits). This field expresses the transport mechanisms supported > by an implementation (multiple bits could be set to indicate multiple > mechanisms supported). This field is technology dependent, but so far, only > SONET/SDH standards have defined values for this field (see [LMP-TEST]). In > the spec, there is a special value "payload" value defined as the most > significant bit value that is supposed to apply to all technologies. I > actually had misinterpreted the spec and coded the bit field as a 32 bit > field. This explains why I used bit 31 for this bit. In any case, I wanted > to use the same value as the spec in the bit field definition for the > "payload" value. However, I don't think it really makes a difference which > bit is used to represent the "payload" value. Bit 0 would be as good as bit > 15 (or 31) for this purpose and would allow all bits to be contiguous. I > have already digressed for the SONET/SDH test spec by keeping the currently > defined SONET/SDH bits contiguous. In [LMP-TEST], there are five values > specified over 8 bits (3 bits are reserved). I could have mapped the bits in > the bit field the same way (for instance DCC section overhead bytes on bit > 1), but I think it is better to have them all contiguous, the main reason > being that it is quite possible that other technologies will reuse the same > bits. This would prevent us from using the bit fields specified in the > standards because they are likely to be overloaded. In the end, the > implementor will have to perform some mapping. > > I can update the MIB to reflect this. > > Martin > > ----- Original Message ----- > From: "Wijnen, Bert (Bert)" > To: "Ccamp-wg (E-mail)" > Sent: Tuesday, November 04, 2003 2:22 PM > Subject: SMICng compile error on LMP MIB 7 > > > > The SMICng compile tells me: > > > > E: f(lmp.mi2), (1430,22) Named bits for BITS must be in contiguous > positions > > > > So why is there a gap ?? > > > > > > Thanks, > > Bert > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Nov 2003 02:49:46 +0000 Message-ID: <004601c3a346$e47029a0$2202a8c0@flfrd.phub.net.cable.rogers.com> From: "Martin Dubuc" To: "Wijnen, Bert \(Bert\)" , "Ccamp-wg \(E-mail\)" Subject: Re: SMICng compile error on LMP MIB 7 Date: Tue, 4 Nov 2003 21:45:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Bert, The definition of this bit field was based on the specification of the Verify Transport Mechanism field in the LMP draft. This field is a 2 byte bit field (16 bits). This field expresses the transport mechanisms supported by an implementation (multiple bits could be set to indicate multiple mechanisms supported). This field is technology dependent, but so far, only SONET/SDH standards have defined values for this field (see [LMP-TEST]). In the spec, there is a special value "payload" value defined as the most significant bit value that is supposed to apply to all technologies. I actually had misinterpreted the spec and coded the bit field as a 32 bit field. This explains why I used bit 31 for this bit. In any case, I wanted to use the same value as the spec in the bit field definition for the "payload" value. However, I don't think it really makes a difference which bit is used to represent the "payload" value. Bit 0 would be as good as bit 15 (or 31) for this purpose and would allow all bits to be contiguous. I have already digressed for the SONET/SDH test spec by keeping the currently defined SONET/SDH bits contiguous. In [LMP-TEST], there are five values specified over 8 bits (3 bits are reserved). I could have mapped the bits in the bit field the same way (for instance DCC section overhead bytes on bit 1), but I think it is better to have them all contiguous, the main reason being that it is quite possible that other technologies will reuse the same bits. This would prevent us from using the bit fields specified in the standards because they are likely to be overloaded. In the end, the implementor will have to perform some mapping. I can update the MIB to reflect this. Martin ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Sent: Tuesday, November 04, 2003 2:22 PM Subject: SMICng compile error on LMP MIB 7 > The SMICng compile tells me: > > E: f(lmp.mi2), (1430,22) Named bits for BITS must be in contiguous positions > > So why is there a gap ?? > > > Thanks, > Bert > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Nov 2003 19:24:32 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502D9500D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: SMICng compile error on LMP MIB 7 Date: Tue, 4 Nov 2003 20:22:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The SMICng compile tells me: E: f(lmp.mi2), (1430,22) Named bits for BITS must be in contiguous positions So why is there a gap ?? Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Nov 2003 12:15:03 +0000 Message-ID: <3FA79861.9060003@alcatel.be> Date: Tue, 04 Nov 2003 13:15:29 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Heiles Juergen CC: ccamp@ops.ietf.org Subject: Re: GPID for Ethernet with GFP-F mapping in SDH Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi juergen, for Ethernet MAC over SDH using framed GFP, value 54 should be used - thanks, d. ps: the value is generic (applicable to one or more lsp encoding type) Heiles Juergen wrote: > GPID values are listed in RFC3471. For a Ethernet 802.3 payload over SDH, Lambda, Fiber the value 46 is defined. > draft-ietf-ccamp-gmpls-g709 lists in addition a GPID of 54 for Ethernet MAC (framed GFP) for G.709 (and SDH). > draft-ietf-ccamp-gmpls-sonet-sdh doesn't define a SDH specific GPID. > > So what is the correct GPID for a Ethernet MAC over SDH VCs using framed GFP 46 or 54. I assume the later. > > Regards > > Juergen > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Nov 2003 11:54:39 +0000 Message-ID: From: Heiles Juergen To: ccamp@ops.ietf.org Subject: GPID for Ethernet with GFP-F mapping in SDH Date: Tue, 4 Nov 2003 12:52:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" GPID values are listed in RFC3471. For a Ethernet 802.3 payload over SDH, Lambda, Fiber the value 46 is defined. draft-ietf-ccamp-gmpls-g709 lists in addition a GPID of 54 for Ethernet MAC (framed GFP) for G.709 (and SDH). draft-ietf-ccamp-gmpls-sonet-sdh doesn't define a SDH specific GPID. So what is the correct GPID for a Ethernet MAC over SDH VCs using framed GFP 46 or 54. I assume the later. Regards Juergen Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Nov 2003 23:58:30 +0000 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048D1B@nimbus.chromisys.com> From: John Drake To: 'Adrian Farrel' , "Ong, Lyndon" , Jonathan Sadler , "Varma, Eve L (Eve)" , dimitris@us.ibm.com Cc: ccamp@ops.ietf.org Subject: RE: draft-ong-ccamp-3473-3474-iw-00.txt Date: Mon, 3 Nov 2003 15:55:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Lyndon, I also had a question about the folllowing from Section 3.2: 'It also allows full overlap of the client address range with the address range used in the network, since separate objects are used for each.' Why do you think separate object are required to support this? Are you familiar, for example, with draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-04.txt? Thanks, John > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Saturday, November 01, 2003 6:12 PM > To: Ong, Lyndon; Jonathan Sadler; Varma, Eve L (Eve); > dimitris@us.ibm.com > Cc: ccamp@ops.ietf.org > Subject: draft-ong-ccamp-3473-3474-iw-00.txt > > > Hi, > > A couple of quick questions... > > Section 3.3 says > As RFC 3473 does not support call and connection separation > or soft permanent connection > > But surely RFC 3473 does support soft permanent connections? > There are several techniques, > but perhaps the most popular is explicit label control. In > view of this, you need to > describe how you map between the two techniques when > transiting between 3473 and 3474 > network types. (Not just how you carry one technique across > the other type of network, but > how you handle the case where the end points are in different > types of network.) > > > Section 3.3 also says > c) support for extended restart capabilities > and > (c) is a local procedure and has no interworking implications > > Are you sure that the Hello interactions and state recovery > between 3473 and 3474 LSRs has > no interworking implications? > > > > Section 5.4 says > Other objects may be received at the 3474/3473 interface, > esp. the Call_ID and Call_OPS objects defined in RFC 3474. > These are passed transparently across the 3473 domain. > > This may be true, but you need to cover the case where the > 3473 domain generates an error > (such as PathErr). Presumably the mandatory Call_IS and > Call_OPS are added back in to the > message when it reaches the 3474 domain? > > > Cheers, > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Nov 2003 07:49:12 +0000 Message-ID: From: Nurit Sprecher To: "'curtis@fictitious.org'" , Nurit Sprecher Cc: 'Adrian Farrel' , "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: RE: RSVP Graceful Restart Date: Sun, 2 Nov 2003 09:47:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, I fully agree that it is satisfactory that the Ingress LER send traps on protection status changes. But such a trap should be defined. Thanks, Nurit. -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] Sent: Thursday, October 30, 2003 3:40 PM To: Nurit Sprecher Cc: 'Adrian Farrel'; 'mpls@uu.net'; ccamp@ops.ietf.org Subject: Re: RSVP Graceful Restart In message , Nurit Sprecher writes: > > Hi, > I have a question on notifications when FRR is activated. > If an LSP has been established with the 'one-to-one local protection > desired' and a detour has been established at each PLR --> all hops along > the LSP are considered FRR protected. > Is for example, a problem occurs on one of these detours and the hop becomes > to be unprotected, the consequent Resv message will indicate that the > relevant node is not protected any more and the ARHop table will be updated > with the information. However, a management station has no idea of the > event, unless it keeps polling the ARHop table, which is not a reasonable > operation. I think that an appropriate notification/trap should be sent to > the management station indicating the protection status has been changed to > trigger the management station polling the ARHop table and verifying which > node is not protected any more, or which node that has not been protected is > now protected. > Is it possible to add such a kind of trap to the TE MIB? > Thanks in advance, Nurit. The local_protect_available bit should be set by each node and if the backup fails at a node the bit should be cleared. The ingress then knows the primary LSP is not fully protected and can then optionally set a timer and reroute the primary LSP if for some reason the backup LSP cannot be reestablished during that time. Since the TE MIB reports status of the ingress, it might be better for the ingress to send traps on protection status changes rather than each midpoint sending status (ie: {is|not} fully-protected, {is|not} protection-inuse). If the management station need to know which node transitioned to not protected or inuse then it can poll the midpoints. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Nov 2003 02:17:43 +0000 Message-ID: <05e401c3a0e6$ec4f7b60$f9919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ong, Lyndon" , "Jonathan Sadler" , "Varma, Eve L \(Eve\)" , Cc: Subject: draft-ong-ccamp-3473-3474-iw-00.txt Date: Sun, 2 Nov 2003 02:11:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, A couple of quick questions... Section 3.3 says As RFC 3473 does not support call and connection separation or soft permanent connection But surely RFC 3473 does support soft permanent connections? There are several techniques, but perhaps the most popular is explicit label control. In view of this, you need to describe how you map between the two techniques when transiting between 3473 and 3474 network types. (Not just how you carry one technique across the other type of network, but how you handle the case where the end points are in different types of network.) Section 3.3 also says c) support for extended restart capabilities and (c) is a local procedure and has no interworking implications Are you sure that the Hello interactions and state recovery between 3473 and 3474 LSRs has no interworking implications? Section 5.4 says Other objects may be received at the 3474/3473 interface, esp. the Call_ID and Call_OPS objects defined in RFC 3474. These are passed transparently across the 3473 domain. This may be true, but you need to cover the case where the 3473 domain generates an error (such as PathErr). Presumably the mandatory Call_IS and Call_OPS are added back in to the message when it reaches the 3474 domain? Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 01 Nov 2003 12:24:53 +0000 Message-ID: <04d401c3a072$cc5a4610$f9919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Tim Hall" , "Thomas D. Nadeau" , "Cheenu Srinivasan" , "Adrian Farrel" , "Edward Harrison" Subject: Latest versions of GMPLS MIBs Date: Sat, 1 Nov 2003 12:21:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit We have produced updated versions of the GMPLS MIBs. The chief changes are - Work on basic compilation and smilint issues. - Provide a next index object to supply the next available arbitrary index into the Label Table. - Update references. - Update examples. - Resolve defaults for objects with syntax BITS. - Clarify which objects can be modified when rowStatus and adminStatus are set to active. - Control and reporting of upstream and downstream Notify Recipients. - Add support for control and reporting of GMPLS Administrative Status object. The submission of new drafts is blockaded until after Minneapolis. Those of you who can't wait may find the drafts at http://www.olddog.co.uk/download Cheers, Adrian