Subject: F�rum Social Brasileiro: radiografia das esquerdas ref.: nzv

From: "Informe Exclusivo" <[email-masked]>
Date: Mon, 24 Nov 2003 18:25:16 -0500

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: [email-masked]
Delivery-date: Thu, 27 Nov 2003 00:35:40 +0000
Message-ID: <[email-masked]>
Date: Thu, 27 Nov 2003 01:32:28 +0100
From: [email-masked]
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 , [email-masked]
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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
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: [email-masked]
Delivery-date: Wed, 26 Nov 2003 19:30:25 +0000
Message-ID: <[email-masked]>
Date: Wed, 26 Nov 2003 13:27:34 -0600
From: Jonathan Sadler
MIME-Version: 1.0
To: Adrian Farrel
CC: [email-masked]
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: [email-masked]
Delivery-date: Wed, 26 Nov 2003 14:55:07 +0000
Message-Id: <[email-masked]>
Date: Wed, 26 Nov 2003 09:53:09 -0500
To: Kireeti Kompella , [email-masked]
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: [email-masked]
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: [email-masked]
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: [email-masked]
Delivery-date: Wed, 26 Nov 2003 11:28:08 +0000
Sensitivity:
Subject: Re: GRSVP-TE and MSSPRING
To: "Adrian Farrel"
Cc: [email-masked]
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: [email-masked]
Delivery-date: Wed, 26 Nov 2003 08:38:25 +0000
Subject: ASON RSVP-TE draft to WG doc - draft - dimitri
To: [email-masked]
Cc: [email-masked]
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: [email-masked]
25/11/03 10:43 cc: [email-masked]
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: [email-masked]
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: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, November 25, 2003 1:45 PM
> To: [email-masked]; 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: [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 23:26:53 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'Adrian Farrel' , Jonathan Sadler
Cc: [email-masked]
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:[email-masked]]
Sent: Tuesday, November 25, 2003 2:00 PM
To: Jonathan Sadler
Cc: [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 23:08:29 +0000
Message-ID: <[email-masked]>
Date: Wed, 26 Nov 2003 00:04:56 +0100
From: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Adrian Farrel
Cc: [email-masked], 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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
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: [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 20:13:14 +0000
From: [email-masked]
Sensitivity:
Subject: RE: ASON RSVP-TE draft to WG doc
To: [email-masked]
Cc: [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 19:06:55 +0000
Message-ID: <[email-masked]>
From: "Natale, Robert C (Bob)"
To: Kireeti Kompella
Cc: [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 19:05:07 +0000
Message-ID: <[email-masked]>
From: Yanhe Fan
To: Kireeti Kompella , [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 18:54:30 +0000
Message-ID: <[email-masked]>
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: [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 18:52:23 +0000
Message-ID: <[email-masked]>
Date: Tue, 25 Nov 2003 12:49:09 -0600
From: Jonathan Sadler
MIME-Version: 1.0
To: Kireeti Kompella
CC: [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 15:02:07 +0000
Sensitivity:
Subject: GRSVP-TE and MSSPRING
To: [email-masked]
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: [email-masked]
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: [email-masked]
Message-Id: <[email-masked]>
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 12:13:17 +0000
Message-ID: <[email-masked]>
Date: Tue, 25 Nov 2003 13:11:09 +0100
From: [email-masked]
Reply-To: [email-masked]
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: [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 12:13:07 +0000
Message-ID: <[email-masked]>
Date: Tue, 25 Nov 2003 13:11:22 +0100
From: [email-masked]
Reply-To: [email-masked]
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: [email-masked]
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: [email-masked]
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:[email-masked]]=20
Envoy=E9 : lundi 24 novembre 2003 00:38
=C0 : [email-masked]
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: [email-masked]
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:[email-masked]]=20
Envoy=E9 : lundi 24 novembre 2003 00:36
=C0 : [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 05:44:37 +0000
Message-ID: <[email-masked]>
From: "Varma, Eve L (Eve)"
To: [email-masked]
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: [email-masked]
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: [email-masked]
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: [email-masked]
Message-Id: <[email-masked]>
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 01:45:35 +0000
Message-ID: <[email-masked]>
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: [email-masked]
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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 01:44:29 +0000
Message-ID: <[email-masked]>
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: [email-masked]
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: [email-masked]
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: [email-masked]
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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Sent: Monday, November 24, 2003 8:36 AM
> To: [email-masked]
> 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: [email-masked]
Delivery-date: Tue, 25 Nov 2003 00:47:32 +0000
Message-ID: <[email-masked]>
From: "Razdan, Rajender"
To: [email-masked], [email-masked]
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:[email-masked]]
Sent: Sunday, November 23, 2003 3:36 PM
To: [email-masked]
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 23:41:55 +0000
Message-ID: <[email-masked]>
Date: Tue, 25 Nov 2003 00:39:17 +0100
From: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Kireeti Kompella
CC: [email-masked]
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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
Delivery-date: Mon, 24 Nov 2003 22:29:44 +0000
Message-ID: <[email-masked]>
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: [email-masked], [email-masked]
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:[email-masked]]
Sent: Sunday, November 23, 2003 3:36 PM
To: [email-masked]
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: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Sunday, November 23, 2003 3:38 PM
> To: [email-masked]
> 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: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Vishal Sharma
> Sent: Monday, November 24, 2003 10:55 AM
> To: Kireeti Kompella; [email-masked]
> Subject: RE: ASON RSVP-TE draft to WG doc
>
>
> Kireeti,
>
> Yes.
>
> -Vishal
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Kireeti Kompella
> > Sent: Sunday, November 23, 2003 3:36 PM
> > To: [email-masked]
> > 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: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Sunday, November 23, 2003 3:36 PM
> To: [email-masked]
> 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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Kireeti Kompella
> Sent: Sunday, November 23, 2003 6:38 PM
> To: [email-masked]
> 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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On =
Behalf
> Of Kireeti Kompella
> Sent: Sunday, November 23, 2003 3:38 PM
> To: [email-masked]
> 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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 17:44:18 +0000
Message-Id: <[email-masked]>
To: "Brungard, Deborah A, ALABS"
cc: "Kireeti Kompella" , [email-masked], [email-masked]
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 17:40:56 +0000
Message-ID: <[email-masked]>
From: Ayan Banerjee
To: [email-masked]
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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Kireeti Kompella
> Sent: Sunday, November 23, 2003 6:36 PM
> To: [email-masked]
> 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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 17:33:22 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'Kireeti Kompella' , [email-masked]
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:[email-masked]]
Sent: Sunday, November 23, 2003 3:38 PM
To: [email-masked]
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 17:33:01 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'Kireeti Kompella' , [email-masked]
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:[email-masked]]
Sent: Sunday, November 23, 2003 3:36 PM
To: [email-masked]
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: [email-masked]
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: [email-masked]
Subject: Re: ASON RSVP-TE draft to WG doc
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 16:47:55 +0000
Message-ID: <[email-masked]>
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: [email-masked]
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 16:15:58 +0000
Message-ID:
From: "Hamid Ould-Brahim"
To: Kireeti Kompella , [email-masked]
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: [email-masked]
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: [email-masked]
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: [email-masked]
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: [email-masked]
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: [email-masked]
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: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Yes!

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Kireeti Kompella
>Sent: Sunday, November 23, 2003 6:36 PM
>To: [email-masked]
>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: [email-masked]
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: <[email-masked]>
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: [email-masked]
>[mailto:[email-masked]] On Behalf Of Brungard,
>Deborah A, ALABS
>Sent: Thursday, November 20, 2003 11:27 AM
>To: [email-masked]; Zafar Ali; Kireeti Kompella
>Cc: [email-masked]
>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:[email-masked]]
>Sent: Monday, November 17, 2003 1:05 PM
>To: Zafar Ali; Kireeti Kompella
>Cc: [email-masked]
>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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Zafar Ali
>Sent: Monday, November 17, 2003 7:03 AM
>To: Kireeti Kompella
>Cc: [email-masked]
>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: [email-masked]
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: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Yes!

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Kireeti Kompella
>Sent: Sunday, November 23, 2003 6:38 PM
>To: [email-masked]
>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: [email-masked]
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: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Yes!

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Kireeti Kompella
>Sent: Sunday, November 23, 2003 6:38 PM
>To: [email-masked]
>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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 15:16:55 +0000
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Re: ASON RSVP-TE draft to WG doc
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 15:15:27 +0000
Message-Id: <[email-masked]>
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: [email-masked]
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 15:15:15 +0000
Message-Id: <[email-masked]>
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: [email-masked]
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: [email-masked]
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: <[email-masked]>
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:[email-masked]]
Sent: Sunday, November 23, 2003 6:38 PM
To: [email-masked]
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: [email-masked]
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: <[email-masked]>
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:[email-masked]]
Sent: Sunday, November 23, 2003 6:36 PM
To: [email-masked]
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 14:25:28 +0000
Message-ID:
From: "Xu, Yangguang"
To: 'Kireeti Kompella' , [email-masked]
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:[email-masked]]
Sent: Sunday, November 23, 2003 6:36 PM
To: [email-masked]
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 14:20:32 +0000
Message-ID: <[email-masked]>
From: John Drake
To: 'Kireeti Kompella' , [email-masked]
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:[email-masked]]
> Sent: Sunday, November 23, 2003 3:36 PM
> To: [email-masked]
> 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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 14:20:13 +0000
Message-ID: <[email-masked]>
From: John Drake
To: 'Kireeti Kompella' , [email-masked]
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:[email-masked]]
> Sent: Sunday, November 23, 2003 3:38 PM
> To: [email-masked]
> 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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 14:10:24 +0000
Message-ID: <[email-masked]>
Date: Mon, 24 Nov 2003 15:06:24 +0100
From: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Kireeti Kompella
CC: [email-masked]
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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
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: [email-masked]
------------------------------------

Envelope-to: [email-masked]
Delivery-date: Mon, 24 Nov 2003 10:43:19 +0000
From: [email-masked]
Sensitivity:
Subject: Re: Crank-back signaling to WG doc
To: Kireeti Kompella
Cc: [email-masked]
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: [email-masked]

To: [email-masked]
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: [email-masked]
Delivery-date: Mon, 24 Nov 2003 09:42:36 +0000
Message-ID: <[email-masked]>
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: [email-masked]
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:[email-masked]

Envelope-to: [email-masked]
Delivery-date: Mon, 24 Nov 2003 07:56:34 +0000
From: [email-masked]
Sensitivity:
Subject: Re: ASON RSVP-TE draft to WG doc
To: Kireeti Kompella
Cc: [email-masked]
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: [email-masked]

To: [email-masked]
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: [email-masked]
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: <[email-masked]>
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: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Sent: Sunday, November 23, 2003 3:36 PM
> To: [email-masked]
> 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: [email-masked]
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: <[email-masked]>
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: [email-masked]
Delivery-date: Sun, 23 Nov 2003 23:39:25 +0000
Date: Sun, 23 Nov 2003 15:38:27 -0800 (PST)
From: Kireeti Kompella
To: [email-masked]
Subject: Crank-back signaling to WG doc
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Sun, 23 Nov 2003 23:39:12 +0000
Date: Sun, 23 Nov 2003 15:35:36 -0800 (PST)
From: Kireeti Kompella
To: [email-masked]
Subject: ASON RSVP-TE draft to WG doc
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Sat, 22 Nov 2003 20:15:39 +0000
Message-ID:
From: "Lam, Hing-Kam (Kam)"
To: "'Kireeti Kompella'" , "[email-masked]'"
Cc: "'Scott Bradner'" , "'Alex Zinin'" , "'Bill Fenner'" , "[email-masked]'" , "[email-masked]'" , "[email-masked]'" , [email-masked]
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'; [email-masked]'
> Cc: 'Scott Bradner'; 'Alex Zinin'; 'Bill Fenner';
> [email-masked]'; [email-masked]'; [email-masked]'
> 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'; [email-masked]'
> > Cc: Scott Bradner; Alex Zinin; Bill Fenner;
> > [email-masked];
> > [email-masked]'; [email-masked]'
> > 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:[email-masked]/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:[email-masked]]
> > > Sent: Saturday, November 15, 2003 4:02 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: Scott Bradner; Alex Zinin; Bill Fenner; [email-masked]
> > > 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: [email-masked]
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:
> [email-masked].
> 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: <[email-masked]>

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: <[email-masked]>

------=_NextPart_000_0746_01C3B105.17243EB0--

Envelope-to: [email-masked]
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 [email-masked] 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: [email-masked]
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: [email-masked]
Delivery-date: Fri, 21 Nov 2003 20:51:35 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'John Drake' , "[email-masked]'"
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:[email-masked]]
Sent: Friday, November 21, 2003 4:39 AM
To: Ong, Lyndon; [email-masked]'
Subject: RE: SPCs

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

We're done

Thanks,

John

Envelope-to: [email-masked]
Delivery-date: Fri, 21 Nov 2003 20:50:21 +0000
Message-ID: <[email-masked]>
From: John Drake
To: 'Jonathan Sadler'
Cc: "'Ong, Lyndon'" , "[email-masked]'"
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:[email-masked]]
Sent: Friday, November 21, 2003 9:24 AM
To: John Drake
Cc: 'Ong, Lyndon'; [email-masked]'
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:[email-masked] ]
> Sent: Thursday, November 20, 2003 11:18 PM
> To: John Drake; [email-masked]'
> 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:[email-masked] ]

> Sent: Thursday, November 20, 2003 8:08 AM
> To: [email-masked]'
> 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
> [email-masked]
> 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:[email-masked]]
Sent: Friday, November =
21, 2003=20
9:24 AM
To: John Drake
Cc: 'Ong, Lyndon';=20
[email-masked]'
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:[email-masked]] =

> Sent:=20
Thursday, November 20, 2003 11:18 PM
> To: John Drake;=20
[email-masked]'
> 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:[email-masked]] =

>=20
Sent: Thursday, November 20, 2003 8:08 AM
> To: =
[email-masked]'=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
> [email-masked]
> 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: [email-masked]
Delivery-date: Fri, 21 Nov 2003 17:28:07 +0000
Message-ID: <[email-masked]>
Date: Fri, 21 Nov 2003 11:23:51 -0600
From: Jonathan Sadler
MIME-Version: 1.0
To: John Drake
CC: "'Ong, Lyndon'" , "[email-masked]'"
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:[email-masked]]
> > Sent: Thursday, November 20, 2003 11:18 PM
> > To: John Drake; [email-masked]'
> > 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:[email-masked]]
> > Sent: Thursday, November 20, 2003 8:08 AM
> > To: [email-masked]'
> > 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
> > [email-masked]
> > 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:[email-masked]]

> Sent: Thursday, November 20, 2003 11:18 PM

> To: John Drake; [email-masked]'

> 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:[email-masked]]

> Sent: Thursday, November 20, 2003 8:08 AM

> To: [email-masked]'

> 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

> [email-masked]

> 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: [email-masked]
Delivery-date: Fri, 21 Nov 2003 12:41:22 +0000
Message-ID: <[email-masked]>
From: John Drake
To: "'Ong, Lyndon'" , "[email-masked]'"
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:[email-masked]]
> Sent: Thursday, November 20, 2003 11:18 PM
> To: John Drake; [email-masked]'
> 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:[email-masked]]
> Sent: Thursday, November 20, 2003 8:08 AM
> To: [email-masked]'
> 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
> [email-masked]
> 408 972-3720
>

Envelope-to: [email-masked]
Delivery-date: Fri, 21 Nov 2003 11:22:08 +0000
Subject: I-D ACTION:draft-caviglia-mp2cp-00.txt
Sensitivity:
To: [email-masked]
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: [email-masked]
Delivery-date: Fri, 21 Nov 2003 11:21:03 +0000
Message-ID: <[email-masked]>
Date: Fri, 21 Nov 2003 12:18:48 +0100
From: [email-masked]
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'" , "[email-masked]'"
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:[email-masked]]
> Sent: Thursday, November 20, 2003 8:08 AM
> To: [email-masked]'
> 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
> [email-masked]
> 408 972-3720
>
>

--
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
Delivery-date: Fri, 21 Nov 2003 07:23:22 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'John Drake' , "[email-masked]'"
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:[email-masked]]
Sent: Thursday, November 20, 2003 8:08 AM
To: [email-masked]'
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
[email-masked]
408 972-3720

Envelope-to: [email-masked]
Delivery-date: Thu, 20 Nov 2003 20:29:07 +0000
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Thu, 20 Nov 2003 20:28:51 +0000
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Thu, 20 Nov 2003 20:28:39 +0000
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Thu, 20 Nov 2003 17:13:42 +0000
Message-ID: <[email-masked]>
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: [email-masked], Zafar Ali , Kireeti Kompella , [email-masked]
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:[email-masked]/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:[email-masked]]
> Sent: Monday, November 17, 2003 1:05 PM
> To: Zafar Ali; Kireeti Kompella
> Cc: [email-masked]
> 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: [email-masked] [mailto:[email-masked]]On Behalf Of Zafar Ali
> Sent: Monday, November 17, 2003 7:03 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> 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: [email-masked]
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: <[email-masked]>
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:[email-masked]]
Sent: Monday, November 17, 2003 1:05 PM
To: Zafar Ali; Kireeti Kompella
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]]On =
Behalf Of Zafar Ali
Sent: Monday, November 17, 2003 7:03 AM
To: Kireeti Kompella
Cc: [email-masked]
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: [email-masked]
Delivery-date: Thu, 20 Nov 2003 16:12:43 +0000
Message-ID: <[email-masked]>
From: John Drake
To: "[email-masked]'"
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
[email-masked]
408 972-3720

Envelope-to: [email-masked]
Delivery-date: Wed, 19 Nov 2003 16:01:48 +0000
Message-ID: <[email-masked]>
From: "Wijnen, Bert (Bert)"
To: Tom Petch , "Wijnen, Bert (Bert)"
Cc: [email-masked], 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:[email-masked]]
> Sent: woensdag 19 november 2003 16:21
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]; 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: [email-masked]
> 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:[email-masked]]
> >> Sent: dinsdag 18 november 2003 23:06
> >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
> >> Cc: [email-masked]
> >> 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:[email-masked]]
> >> Sent: Tuesday, November 11, 2003 11:46 AM
> >> To: Adrian Farrel; Lou Berger
> >> Cc: [email-masked]
> >> 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:[email-masked]]
> >> > Sent: dinsdag 11 november 2003 17:28
> >> > To: Lou Berger
> >> > Cc: [email-masked]
> >> > 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: [email-masked]
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: [email-masked]
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:[email-masked]]
>> Sent: dinsdag 18 november 2003 23:06
>> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
>> Cc: [email-masked]
>> 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:[email-masked]]
>> Sent: Tuesday, November 11, 2003 11:46 AM
>> To: Adrian Farrel; Lou Berger
>> Cc: [email-masked]
>> 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:[email-masked]]
>> > Sent: dinsdag 11 november 2003 17:28
>> > To: Lou Berger
>> > Cc: [email-masked]
>> > 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: [email-masked]
Delivery-date: Wed, 19 Nov 2003 01:18:56 +0000
Message-ID: <[email-masked]>
Date: Wed, 19 Nov 2003 02:16:28 +0100
From: [email-masked]
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 , [email-masked]
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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2003 23:43:58 +0000
Message-ID: <[email-masked]>
From: John Drake
To: "'Lazer, Monica A, ALABS'" , Ben Mack-Crane , Yakov Rekhter
Cc: "Ong, Lyndon" , Kireeti Kompella , [email-masked]
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:[email-masked]]
> Sent: Tuesday, November 18, 2003 2:50 PM
> To: Ben Mack-Crane; Yakov Rekhter
> Cc: Ong, Lyndon; Kireeti Kompella; [email-masked]
> 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:[email-masked]]
> Sent: Tuesday, November 18, 2003 12:24 PM
> To: Yakov Rekhter
> Cc: Ong, Lyndon; 'John Drake'; 'Kireeti Kompella'; [email-masked]
> 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:[email-masked]]
> >>Sent: Monday, November 17, 2003 1:06 PM
> >>To: Ong, Lyndon; 'Kireeti Kompella'
> >>Cc: [email-masked]
> >>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: [email-masked]
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: [email-masked]
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:[email-masked]]
> > Sent: dinsdag 18 november 2003 23:06
> > To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
> > Cc: [email-masked]
> > 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:[email-masked]]
> > Sent: Tuesday, November 11, 2003 11:46 AM
> > To: Adrian Farrel; Lou Berger
> > Cc: [email-masked]
> > 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:[email-masked]]
> > > Sent: dinsdag 11 november 2003 17:28
> > > To: Lou Berger
> > > Cc: [email-masked]
> > > 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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 23:07:06 +0000
Message-ID: <[email-masked]>
From: "Wijnen, Bert (Bert)"
To: "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , Adrian Farrel , Lou Berger
Cc: [email-masked]
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:[email-masked]]
> Sent: dinsdag 18 november 2003 23:06
> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Tuesday, November 11, 2003 11:46 AM
> To: Adrian Farrel; Lou Berger
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: dinsdag 11 november 2003 17:28
> > To: Lou Berger
> > Cc: [email-masked]
> > 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: [email-masked]
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: <[email-masked]>
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:[email-masked]]
Sent: Tuesday, November 18, 2003 12:24 PM
To: Yakov Rekhter
Cc: Ong, Lyndon; 'John Drake'; 'Kireeti Kompella'; [email-masked]
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:[email-masked]]
>>Sent: Monday, November 17, 2003 1:06 PM
>>To: Ong, Lyndon; 'Kireeti Kompella'
>>Cc: [email-masked]
>>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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 22:15:07 +0000
Message-ID: <[email-masked]>
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" , [email-masked]
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: [email-masked]
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: <[email-masked]>
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:[email-masked]]
Sent: Tuesday, November 11, 2003 11:46 AM
To: Adrian Farrel; Lou Berger
Cc: [email-masked]
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:[email-masked]]
> Sent: dinsdag 11 november 2003 17:28
> To: Lou Berger
> Cc: [email-masked]
> 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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 21:45:35 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: "'Brungard, Deborah A, ALABS'" , Kireeti Kompella
Cc: [email-masked]
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:[email-masked]]
Sent: Tuesday, November 18, 2003 8:26 AM
To: Kireeti Kompella; Ong, Lyndon
Cc: [email-masked]
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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 20:50:12 +0000
Message-ID: <[email-masked]>
Date: Tue, 18 Nov 2003 21:49:06 +0100
From: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: [email-masked]
Cc: [email-masked], [email-masked]
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

[email-masked] 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: [email-masked]
> TEL@ALCATEL cc:
> Sent by: Subject: ason-req and call segments
> [email-masked].
> 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 : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone : +32 3 240-8491
>
>
>
>
>
>
>

--
Papadimitriou Dimitri
E-mail : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 20:07:01 +0000
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2003 19:47:13 +0000
Message-Id: <[email-masked]>
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: [email-masked]
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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 17:28:31 +0000
Subject: Re: ason-req and call segments
To: [email-masked]
Cc: [email-masked], [email-masked]
Message-ID:
From: [email-masked]
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: [email-masked]
TEL@ALCATEL cc:
Sent by: Subject: ason-req and call segments
[email-masked].
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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Nov 2003 17:28:17 +0000
Message-ID: <[email-masked]>
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'" , [email-masked]
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:[email-masked]]
>>Sent: Monday, November 17, 2003 1:06 PM
>>To: Ong, Lyndon; 'Kireeti Kompella'
>>Cc: [email-masked]
>>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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 16:51:26 +0000
Message-ID: <[email-masked]>
Date: Tue, 18 Nov 2003 17:50:39 +0100
From: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: [email-masked]
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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
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: <[email-masked]>
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:[email-masked]]
Sent: Monday, November 17, 2003 9:48 PM
To: Ong, Lyndon
Cc: [email-masked]
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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 15:06:44 +0000
Message-Id: <[email-masked]>
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: [email-masked]
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: [email-masked]
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: [email-masked]
Subject: RE: spc connections
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 01:29:58 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'Yakov Rekhter'
Cc: 'Kireeti Kompella' , [email-masked]
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:[email-masked]]
Sent: Monday, November 17, 2003 2:15 PM
To: Ong, Lyndon
Cc: 'John Drake'; 'Kireeti Kompella'; [email-masked]
Subject: Re: spc connections

Lyndon,

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Monday, November 17, 2003 1:06 PM
> To: Ong, Lyndon; 'Kireeti Kompella'
> Cc: [email-masked]
> 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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 01:29:33 +0000
Message-Id: <[email-masked]>
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 , [email-masked]
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: [email-masked]
Delivery-date: Tue, 18 Nov 2003 00:09:50 +0000
Message-Id: <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: spc connections
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>
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:[email-masked]]
> >>Sent: Monday, November 17, 2003 1:06 PM
> >>To: Ong, Lyndon; 'Kireeti Kompella'
> >>Cc: [email-masked]
> >>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 : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone : +32 3 240-8491
>

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2003 22:34:59 +0000
Message-ID: <[email-masked]>
Date: Mon, 17 Nov 2003 23:33:32 +0100
From: [email-masked]
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'" , [email-masked]
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:[email-masked]]
>>Sent: Monday, November 17, 2003 1:06 PM
>>To: Ong, Lyndon; 'Kireeti Kompella'
>>Cc: [email-masked]
>>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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2003 22:17:07 +0000
Message-Id: <[email-masked]>
To: "Ong, Lyndon"
cc: "'John Drake'" , "'Kireeti Kompella'" , [email-masked]
Subject: Re: spc connections
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>
Date: Mon, 17 Nov 2003 14:14:45 -0800
From: Yakov Rekhter

Lyndon,

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Monday, November 17, 2003 1:06 PM
> To: Ong, Lyndon; 'Kireeti Kompella'
> Cc: [email-masked]
> 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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 21:47:34 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'John Drake' , 'Kireeti Kompella'
Cc: [email-masked]
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:[email-masked]]
Sent: Monday, November 17, 2003 1:06 PM
To: Ong, Lyndon; 'Kireeti Kompella'
Cc: [email-masked]
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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 21:33:03 +0000
Message-Id: <[email-masked]>
To: "'Ong, Lyndon'"
cc: "'Kireeti Kompella'" , [email-masked]
Subject: Re: spc connections
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 21:07:03 +0000
Message-ID: <[email-masked]>
From: John Drake
To: "'Ong, Lyndon'" , 'Kireeti Kompella'
Cc: [email-masked]
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:[email-masked]]
> Sent: Monday, November 17, 2003 12:53 PM
> To: 'Kireeti Kompella'
> Cc: [email-masked]
> 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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 20:53:55 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'Kireeti Kompella'
Cc: [email-masked]
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: [email-masked]
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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 20:11:50 +0000
Message-ID: <[email-masked]>
Date: Mon, 17 Nov 2003 21:10:05 +0100
From: [email-masked]
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'" , "[email-masked]'" , [email-masked], [email-masked], [email-masked], [email-masked]
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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
Delivery-date: Mon, 17 Nov 2003 19:20:20 +0000
Message-ID: <[email-masked]>
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'" , [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 18:33:43 +0000
Message-Id: <[email-masked]>
To: Kireeti Kompella
cc: [email-masked]
Subject: Re: spc connections
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 18:24:58 +0000
Message-ID: <[email-masked]>
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'" , "[email-masked]'" , [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked]
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: [email-masked] [mailto:[email-masked]]On Behalf
Of Zafar Ali
Sent: Monday, November 17, 2003 7:03 AM
To: Kireeti Kompella
Cc: [email-masked]
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: =
[email-masked]=20
[mailto:[email-masked]]On Behalf Of Zafar =
Ali
Sent:=20
Monday, November 17, 2003 7:03 AM
To: Kireeti =
Kompella
Cc:=20
[email-masked]
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: [email-masked]
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: <[email-masked]>
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:[email-masked]]=20
Sent: Monday, November 17, 2003 10:03 AM
To: Kireeti Kompella
Cc: [email-masked]
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:[email-masked]]

Sent: Monday, November =
17, 2003
10:03 AM

To: Kireeti Kompella

Cc: =
[email-masked]

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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 15:04:16 +0000
Message-Id: <[email-masked]>
Date: Mon, 17 Nov 2003 10:02:47 -0500
To: Kireeti Kompella
From: Zafar Ali
Subject: Re: ASON Routing Requirements to WG doc
Cc: [email-masked]
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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 14:56:33 +0000
Message-ID: <[email-masked]>
From: "Stephen Shew"
To: "'Zafar Ali'" , Kireeti Kompella , [email-masked]
Cc: [email-masked]
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:[email-masked]]
Sent: Sunday, November 16, 2003 14:16
To: Kireeti Kompella; [email-masked]
Cc: [email-masked]
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:[email-masked]]
Sent: Sunday, November 16, 2003
14:16
To: Kireeti Kompella; [email-masked]
Cc:
[email-masked]
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: [email-masked]
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: <[email-masked]>
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: [email-masked]
Delivery-date: Mon, 17 Nov 2003 14:24:49 +0000
Message-Id: <[email-masked]>
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: [email-masked] [mailto:[email-masked]] On Behalf
>Of Zafar Ali
>Sent: Sunday, November 16, 2003 1:16 PM
>To: Kireeti Kompella; [email-masked]
>Cc: [email-masked]
>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: [email-masked]
[mailto:[email-masked]]
On Behalf Of Zafar Ali

Sent: Sunday, November 16, 2003 1:16 PM

To: Kireeti Kompella; [email-masked]

Cc: [email-masked]

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: [email-masked]
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: [email-masked]
Subject: Re: spc connections
Message-ID: <[email-masked]>
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: [email-masked]
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: [email-masked]
Subject: Re: ASON Routing Requirements to WG doc
Message-ID: <[email-masked]>
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: [email-masked]
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:[email-masked]]
> >>Sent: Friday, November 14, 2003 12:48 PM
> >>To: Ong, Lyndon; [email-masked]'; [email-masked]
> >>Cc: [email-masked]; [email-masked]; [email-masked]
> >>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:[email-masked]]
Sent: Friday, November 14, 2003 =
> >>12:48=20
> >> PM
To: Ong, Lyndon; [email-masked]';=20
> >> [email-masked]
Cc: [email-masked];=20
> >> [email-masked]; [email-masked]
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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Zafar Ali
Sent: Sunday, November 16, 2003 1:16 PM
To: Kireeti Kompella; [email-masked]
Cc: [email-masked]
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: =
[email-masked]
[mailto:[email-masked]] On =
Behalf
Of Zafar Ali

Sent: =
Sunday, November 16, =
2003 1:16 PM

To: Kireeti Kompella;
[email-masked]

Cc: =
[email-masked]

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: [email-masked]
Delivery-date: Sun, 16 Nov 2003 19:20:55 +0000
Message-Id: <[email-masked]>
Date: Sun, 16 Nov 2003 14:16:16 -0500
To: Kireeti Kompella , [email-masked]
From: Zafar Ali
Subject: Re: ASON Routing Requirements to WG doc
Cc: [email-masked]
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: [email-masked]
Delivery-date: Sat, 15 Nov 2003 21:08:07 +0000
Date: Sat, 15 Nov 2003 13:06:55 -0800 (PST)
From: Kireeti Kompella
To: [email-masked]
Subject: ASON Routing Requirements to WG doc
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Sat, 15 Nov 2003 21:03:41 +0000
Date: Sat, 15 Nov 2003 13:01:47 -0800 (PST)
From: Kireeti Kompella
To: [email-masked], [email-masked]
cc: Scott Bradner , Alex Zinin , Bill Fenner , [email-masked]
Subject: ITU Liaison regarding ASON Requirements Design Team
Message-ID: <[email-masked]>
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: [email-masked]
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: [email-masked]
Subject: Re: spc connections
Message-ID: <[email-masked]>
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: [email-masked]
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: [email-masked]
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: [email-masked]
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: [email-masked]
Subject: RE: spc connections
Message-ID: <[email-masked]>
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: [email-masked]
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: [email-masked]
Subject: Re: spc connections
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Sat, 15 Nov 2003 03:53:40 +0000
Date: Fri, 14 Nov 2003 19:53:06 -0800 (PST)
From: Kireeti Kompella
To: [email-masked]
cc: [email-masked]
Subject: Re: spc connections
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Young-Hwa,

On Thu, 13 Nov 2003 [email-masked] 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: [email-masked]
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: [email-masked]
Subject: RE: spc connections
Message-ID: <[email-masked]>
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: [email-masked]
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: [email-masked]
Subject: Re: spc connections
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Sat, 15 Nov 2003 01:08:43 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'Dimitri Papadimitriou' , [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 23:24:41 +0000
Subject: Re: spc connections
To: [email-masked] (Ben Mack-Crane)
Date: Fri, 14 Nov 2003 23:23:03 +0000 (GMT)
Cc: [email-masked] (Ong Lyndon), [email-masked] ('John Drake'), [email-masked] ([email-masked]'), [email-masked], [email-masked], [email-masked], [email-masked]
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:[email-masked]]
> >>Sent: Friday, November 14, 2003 12:48 PM
> >>To: Ong, Lyndon; [email-masked]'; [email-masked]
> >>Cc: [email-masked]; [email-masked]; [email-masked]
> >>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:[email-masked]]
Sent: Friday, November 14, 2003 =
> >>12:48=20
> >> PM
To: Ong, Lyndon; [email-masked]';=20
> >> [email-masked]
Cc: [email-masked];=20
> >> [email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 22:34:59 +0000
Message-ID: <[email-masked]>
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'" , "[email-masked]'" , [email-masked], [email-masked], [email-masked], [email-masked]
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:[email-masked]]
>>Sent: Friday, November 14, 2003 12:48 PM
>>To: Ong, Lyndon; [email-masked]'; [email-masked]
>>Cc: [email-masked]; [email-masked]; [email-masked]
>>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:[email-masked]]
Sent: Friday, November 14, 2003 =
>>12:48=20
>> PM
To: Ong, Lyndon; [email-masked]';=20
>> [email-masked]
Cc: [email-masked];=20
>> [email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 21:50:41 +0000
Subject: Re: spc connections
To: [email-masked] (Ong, Lyndon)
Date: Fri, 14 Nov 2003 21:49:26 +0000 (GMT)
Cc: [email-masked] ('John Drake'), [email-masked] ([email-masked]'), [email-masked], [email-masked], [email-masked], [email-masked]
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:[email-masked]]
> Sent: Friday, November 14, 2003 12:48 PM
> To: Ong, Lyndon; [email-masked]'; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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:[email-masked]]
Sent: Friday, November 14, 2003 =
> 12:48=20
> PM
To: Ong, Lyndon; [email-masked]';=20
> [email-masked]
Cc: [email-masked];=20
> [email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 21:12:48 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'John Drake' , "[email-masked]'" , [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 12:48 PM
To: Ong, Lyndon; [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 =
12:48=20
PM
To: Ong, Lyndon; [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 20:49:14 +0000
Message-ID: <[email-masked]>
From: John Drake
To: "'Ong, Lyndon'" , "[email-masked]'" , [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 12:01 PM
To: John Drake; [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: spc connections

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Friday, November 14, 2003 11:45 AM
To: Ong, Lyndon; [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 =
12:01=20
PM
To: John Drake; [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
Subject: RE: spc=20
connections

-----Original Message-----
From: John Drake=20
[mailto:[email-masked]]
Sent: Friday, November 14, =
2003 11:45=20
AM
To: Ong, Lyndon; [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 20:01:51 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'John Drake' , "[email-masked]'" , [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 11:45 AM
To: Ong, Lyndon; [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 =
11:45=20
AM
To: Ong, Lyndon; [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 19:47:18 +0000
Message-ID: <[email-masked]>
From: John Drake
To: "'Ong, Lyndon'" , "[email-masked]'" , [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 10:42 AM
To: John Drake; [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 10:36 AM
To: Ong, Lyndon; [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 10:16 AM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 14, 2003 7:18 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Ong, Lyndon; [email-masked];
[email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 =
10:42=20
AM
To: John Drake; [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, November 14, =
2003 10:36=20
AM
To: Ong, Lyndon; [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, November 14, =
2003 10:16=20
AM
To: [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
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: =
[email-masked]=20
[mailto:[email-masked]]
Sent: Friday, November 14, =
2003=20
7:18 AM
To: [email-masked];=20
[email-masked]
Cc: [email-masked]; Ong, =
Lyndon;=20
[email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 18:43:02 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'John Drake' , "[email-masked]'" , [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 10:36 AM
To: Ong, Lyndon; [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 10:16 AM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 14, 2003 7:18 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Ong, Lyndon; [email-masked]; =
[email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 =
10:36=20
AM
To: Ong, Lyndon; [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 =
10:16=20
AM
To: [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
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: =
[email-masked]=20
[mailto:[email-masked]]
Sent: Friday, November 14, =
2003 7:18=20
AM
To: [email-masked];=20
[email-masked]
Cc: [email-masked]; Ong, Lyndon; =

[email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 18:37:10 +0000
Message-ID: <[email-masked]>
From: John Drake
To: "'Ong, Lyndon'" , "[email-masked]'" , [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 10:16 AM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 14, 2003 7:18 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Ong, Lyndon; [email-masked];
[email-masked]
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:[email-masked]]
Sent: Friday, November 14, 2003 =
10:16=20
AM
To: [email-masked]';=20
[email-masked]
Cc: [email-masked];=20
[email-masked]; [email-masked]
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: =
[email-masked]=20
[mailto:[email-masked]]
Sent: Friday, November 14, =
2003 7:18=20
AM
To: [email-masked];=20
[email-masked]
Cc: [email-masked]; Ong, Lyndon;=20
[email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 18:17:09 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: "[email-masked]'" , [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 14, 2003 7:18 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Ong, Lyndon; [email-masked]; =
[email-masked]
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: [email-masked] =

[mailto:[email-masked]]
Sent: Friday, November 14, 2003 =
7:18=20
AM
To: [email-masked]; =
[email-masked]
Cc:=20
[email-masked]; Ong, Lyndon; [email-masked];=20
[email-masked]
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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 17:08:20 +0000
Subject: Re: =?euc-kr?B?W8D8w7zIuL3FXSBSZTogWyBBdUGo+UWirKj2QSBdIHNwYyBjb25u?=
To: [email-masked]
Date: Fri, 14 Nov 2003 17:07:20 +0000 (GMT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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[[email-masked]]
> =B9=DE=B4=C2=BB=E7=B6=F7: [email-masked]
> =C2=FC=C1=B6:[email-masked]; [email-masked]; [email-masked];
> [email-masked]
> =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
> [email-masked] 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[[email-masked]]=20
> ¹Þ´Â»ç¶÷: Ong, Lyndon=20
> ÂüÁ¶:'Kireeti Kompella'; [email-masked]=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[[email-masked]]
>
=B9=DE=B4=C2=BB=E7=B6=F7: [email-masked]
=C2=FC=C1=B6:[email-masked]; [email-masked]; =
> [email-masked]; [email-masked]
>
=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
[email-masked] 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[[email-masked]]
>
SIZE=3D2>&sup1;&THORN;&acute;&Acirc;&raquo;&cced=
> il;&para;&divide;: Ong, Lyndon
>
&Acirc;&uuml;&Aacute;&para;:'Kireeti =
> Kompella'; [email-masked]
>
&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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 16:35:46 +0000
Message-ID: <[email-masked]>
Date: Fri, 14 Nov 2003 10:34:01 -0600
From: Jonathan Sadler
MIME-Version: 1.0
To: John Drake
CC: "[email-masked]'" , [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 14, 2003 7:18 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]

Sent: Friday, November 14,
2003 7:18 AM

To: [email-masked];
[email-masked]

Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]

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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 15:47:56 +0000
Message-ID: <[email-masked]>
From: John Drake
To: "[email-masked]'" , [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 14, 2003 7:18 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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[[email-masked]]=20
=B9=DE=B4=C2=BB=E7=B6=F7: [email-masked]=20
=C2=FC=C1=B6:[email-masked]; [email-masked]; [email-masked];
[email-masked]=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
[email-masked] 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[[email-masked]]=20
¹Þ´Â»ç¶÷: Ong, Lyndon=20
ÂüÁ¶:'Kireeti Kompella'; [email-masked]=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: [email-masked] =

[mailto:[email-masked]]
Sent: Friday, November 14, 2003 =
7:18=20
AM
To: [email-masked]; =
[email-masked]
Cc:=20
[email-masked]; [email-masked]; [email-masked];=20
[email-masked]
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[[email-masked]]=20

=B9=DE=B4=C2=BB=E7=B6=F7: [email-masked] =

=C2=FC=C1=B6:[email-masked]; [email-masked]; =
[email-masked];=20
[email-masked]
=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
[email-masked] 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[[email-masked]]
&sup1;&THORN;&acute;&Acirc;&raquo;&cced=
il;&para;&divide;:=20
Ong, Lyndon
&Acirc;&uuml;&Aacute;&para;:'Kireeti =
Kompella';=20
[email-masked]
&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: [email-masked]
Delivery-date: Fri, 14 Nov 2003 15:23:14 +0000
Message-ID: <4A0AE1E5A1AAD711AC1B00D0B7C2D4A2447E55@cms1>
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
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[[email-masked]]
=B9=DE=B4=C2=BB=E7=B6=F7: [email-masked]
=C2=FC=C1=B6:[email-masked]; [email-masked]; [email-masked];
[email-masked]
=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
[email-masked] 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[[email-masked]]=20
¹Þ´Â»ç¶÷: Ong, Lyndon=20
ÂüÁ¶:'Kireeti Kompella'; [email-masked]=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[[email-masked]]

=B9=DE=B4=C2=BB=E7=B6=F7: [email-masked]

=C2=FC=C1=B6:[email-masked]; [email-masked]; =
[email-masked]; [email-masked]

=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

[email-masked] 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[[email-masked]]

&sup1;&THORN;&acute;&Acirc;&raquo;&cced=
il;&para;&divide;: Ong, Lyndon

&Acirc;&uuml;&Aacute;&para;:'Kireeti =
Kompella'; [email-masked]

&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: [email-masked]
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: [email-masked] (Jonathan Sadler)
Date: Thu, 13 Nov 2003 20:01:54 +0000 (GMT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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
> > >
> > > [email-masked] 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[[email-masked]]
> > > > ¹Þ´Â»ç¶÷: Ong, Lyndon
> > > > ÂüÁ¶:'Kireeti Kompella'; [email-masked]
> > > > Á¦¸ñ: 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
[email-masked] 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[[email-masked]]
> > >
¹Þ´Â»ç¶÷:
> > > Ong, Lyndon
ÂüÁ¶:'Kireeti Kompella'; [email-masked]
Á¦¸ñ: 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: [email-masked]
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: [email-masked]
Delivery-date: Thu, 13 Nov 2003 19:29:54 +0000
Message-ID: <[email-masked]>
Date: Thu, 13 Nov 2003 13:25:22 -0600
From: Jonathan Sadler
MIME-Version: 1.0
To: Dimitri Papadimitriou
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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
> >
> > [email-masked] 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[[email-masked]]
> > > ¹Þ´Â»ç¶÷: Ong, Lyndon
> > > ÂüÁ¶:'Kireeti Kompella'; [email-masked]
> > > Á¦¸ñ: 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
[email-masked] 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[[email-masked]]
> >
¹Þ´Â»ç¶÷:
> > Ong, Lyndon
ÂüÁ¶:'Kireeti Kompella'; [email-masked]
Á¦¸ñ: 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: [email-masked]
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: [email-masked] (Jonathan Sadler)
Date: Thu, 13 Nov 2003 18:16:17 +0000 (GMT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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
>
> [email-masked] 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[[email-masked]]
> > ¹Þ´Â»ç¶÷: Ong, Lyndon
> > ÂüÁ¶:'Kireeti Kompella'; [email-masked]
> > Á¦¸ñ: 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
[email-masked] 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[[email-masked]]
>
¹Þ´Â»ç¶÷:
> Ong, Lyndon
ÂüÁ¶:'Kireeti Kompella'; [email-masked]
Á¦¸ñ: 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: [email-masked]
Delivery-date: Thu, 13 Nov 2003 15:34:34 +0000
Message-ID: <[email-masked]>
Date: Thu, 13 Nov 2003 09:31:41 -0600
From: Jonathan Sadler
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
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

[email-masked] 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[[email-masked]]
> ¹Þ´Â»ç¶÷: Ong, Lyndon
> ÂüÁ¶:'Kireeti Kompella'; [email-masked]
> Á¦¸ñ: 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

[email-masked] 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[[email-masked]]

¹Þ´Â»ç¶÷:
Ong, Lyndon

ÂüÁ¶:'Kireeti Kompella'; [email-masked]

Á¦¸ñ: 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: [email-masked]
Delivery-date: Thu, 13 Nov 2003 01:00:46 +0000
Subject: Re: [????] spc connections
To: [email-masked] (John Drake)
Date: Thu, 13 Nov 2003 00:59:17 +0000 (GMT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 12, 2003 3:48 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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[[email-masked]]=20
> =B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon=20
> =C2=FC=C1=B6:'Kireeti Kompella'; [email-masked]=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: [email-masked] =
>
> [mailto:[email-masked]]
Sent: Wednesday, November 12, =
> 2003 3:48=20
> PM
To: [email-masked]; [email-masked]
Cc:=20
> [email-masked]; [email-masked]
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[[email-masked]]
size=3D2>=B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon
size=3D2>=C2=FC=C1=B6:'Kireeti Kompella';=20
> [email-masked]
=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: [email-masked]
Delivery-date: Thu, 13 Nov 2003 00:05:27 +0000
Message-ID: <[email-masked]>
From: John Drake
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 12, 2003 3:48 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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[[email-masked]]=20
=B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon=20
=C2=FC=C1=B6:'Kireeti Kompella'; [email-masked]=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: [email-masked] =

[mailto:[email-masked]]
Sent: Wednesday, November 12, =
2003 3:48=20
PM
To: [email-masked]; [email-masked]
Cc:=20
[email-masked]; [email-masked]
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[[email-masked]]
=B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon
=C2=FC=C1=B6:'Kireeti Kompella';=20
[email-masked]
=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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 23:50:48 +0000
Message-ID: <4A0AE1E5A1AAD711AC1B00D0B7C2D4A2447E50@cms1>
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
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[[email-masked]]
=B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon
=C2=FC=C1=B6:'Kireeti Kompella'; [email-masked]
=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[[email-masked]]

=B9=DE=B4=C2=BB=E7=B6=F7: Ong, Lyndon

=C2=FC=C1=B6:'Kireeti Kompella'; =
[email-masked]

=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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 23:43:59 +0000
Message-ID:
From: Nurit Sprecher
To: "[email-masked]'" , 'Adrian Farrel' , Nurit Sprecher , [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
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:[email-masked]]
Sent: Thursday, November 13, 2003 01:12
To: 'Adrian Farrel'; 'Nurit Sprecher'; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]]
>> Sent: Wednesday, November 12, 2003 19:32
>> To: Nurit Sprecher; [email-masked]'; Nurit Sprecher;
>> [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> 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: "[email-masked]'" ,
>> Nurit Sprecher ,
>> [email-masked], [email-masked]
>> Cc: [email-masked], [email-masked]
>> 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:[email-masked]]
>> Sent: Wednesday, November 12, 2003 18:14
>> To: 'Nurit Sprecher'; [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> 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: [email-masked]
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: <[email-masked]>
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: [email-masked]
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: <[email-masked]>
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:[email-masked]]
>> Sent: Wednesday, November 12, 2003 11:34 AM
>> To: [email-masked]
>> Cc: 'Nurit Sprecher'; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> 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: [email-masked]
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: <[email-masked]>
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: [email-masked] [mailto:[email-masked]]
>> Sent: Wednesday, November 12, 2003 19:32
>> To: Nurit Sprecher; [email-masked]'; Nurit Sprecher;
>> [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> 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: "[email-masked]'" ,
>> Nurit Sprecher ,
>> [email-masked], [email-masked]
>> Cc: [email-masked], [email-masked]
>> 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:[email-masked]]
>> Sent: Wednesday, November 12, 2003 18:14
>> To: 'Nurit Sprecher'; [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> 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: [email-masked]
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: [email-masked]
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: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 12, 2003 19:32
> To: Nurit Sprecher; [email-masked]'; Nurit Sprecher;
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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: "[email-masked]'" ,
> Nurit Sprecher ,
> [email-masked], [email-masked]
> Cc: [email-masked], [email-masked]
> 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:[email-masked]]
> Sent: Wednesday, November 12, 2003 18:14
> To: 'Nurit Sprecher'; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 20:14:17 +0000
Message-ID: <[email-masked]>
Date: Wed, 12 Nov 2003 21:12:09 +0100
From: Loa Andersson
Reply-To: [email-masked]
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: "[email-masked]'" , "[email-masked]'" , [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, November 12, 2003 19:32
>To: Nurit Sprecher; [email-masked]'; Nurit Sprecher;
>[email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>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: "[email-masked]'" ,
> Nurit Sprecher ,
> [email-masked], [email-masked]
>Cc: [email-masked], [email-masked]
>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:[email-masked]]
>Sent: Wednesday, November 12, 2003 18:14
>To: 'Nurit Sprecher'; [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 20:05:00 +0000
Message-ID: <[email-masked]>
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:[email-masked]]
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:[email-masked]]
>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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 19:54:11 +0000
Message-ID:
From: Nurit Sprecher
To: "[email-masked]'" , Nurit Sprecher , "[email-masked]'" , [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 12, 2003 19:32
To: Nurit Sprecher; [email-masked]'; Nurit Sprecher;
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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: "[email-masked]'" ,
Nurit Sprecher ,
[email-masked], [email-masked]
Cc: [email-masked], [email-masked]
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:[email-masked]]
Sent: Wednesday, November 12, 2003 18:14
To: 'Nurit Sprecher'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 18:24:15 +0000
Message-ID: <[email-masked]>
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:[email-masked]]
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:[email-masked]]
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: [email-masked]
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:[email-masked]]
>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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 17:30:27 +0000
Message-ID: <[email-masked]>
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:[email-masked]]
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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 17:28:36 +0000
Message-ID: <[email-masked]>
From: "Don Fedyk"
To: [email-masked], [email-masked]
Cc: "'Nurit Sprecher'" , [email-masked], [email-masked], [email-masked], [email-masked]
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:[email-masked]]
> Sent: Wednesday, November 12, 2003 11:34 AM
> To: [email-masked]
> Cc: 'Nurit Sprecher'; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> 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: [email-masked]
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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 16:55:26 +0000
Message-ID:
From: Nurit Sprecher
To: "[email-masked]'" , Nurit Sprecher , [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
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:[email-masked]]
Sent: Wednesday, November 12, 2003 18:14
To: 'Nurit Sprecher'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 16:39:40 +0000
Message-ID: <[email-masked]>
Date: Wed, 12 Nov 2003 17:34:27 +0100
From: Loa Andersson
Reply-To: [email-masked]
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: [email-masked]
CC: 'Nurit Sprecher' , [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 16:39:06 +0000
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 16:18:42 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'Adrian Farrel' , 'Kireeti Kompella'
Cc: "[email-masked]'"
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: [email-masked]
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: <[email-masked]>
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: [email-masked]
Delivery-date: Wed, 12 Nov 2003 16:08:52 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'Adrian Farrel' , 'Kireeti Kompella'
Cc: [email-masked]
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: [email-masked]
Delivery-date: Tue, 11 Nov 2003 22:17:01 +0000
Message-ID:
From: Nurit Sprecher
To: "[email-masked]'" , "[email-masked]'" , "[email-masked]'"
Cc: "[email-masked]'" , "[email-masked]'"
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: [email-masked]
Delivery-date: Tue, 11 Nov 2003 16:49:09 +0000
Message-ID: <[email-masked]>
From: "Wijnen, Bert (Bert)"
To: Adrian Farrel , Lou Berger
Cc: [email-masked]
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:[email-masked]]
> Sent: dinsdag 11 november 2003 17:28
> To: Lou Berger
> Cc: [email-masked]
> 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: [email-masked]
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: [email-masked]
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: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Diego Caviglia
> Sent: Monday, November 10, 2003 8:17 AM
> To: [email-masked]
> 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: [email-masked]
Delivery-date: Tue, 11 Nov 2003 00:55:57 +0000
Message-ID:
From: Nurit Sprecher
To: "[email-masked]'" , "[email-masked]'" , "[email-masked]'"
Cc: "[email-masked]'" , "[email-masked]'"
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: [email-masked]
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: [email-masked]
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:
> [email-masked].
>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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Diego Caviglia
> Sent: Monday, November 10, 2003 8:17 AM
> To: [email-masked]
> 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: [email-masked]
Delivery-date: Mon, 10 Nov 2003 16:20:11 +0000
Sensitivity:
Subject: Source routed Notify message
To: [email-masked]
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: [email-masked]
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: <[email-masked]>
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: [email-masked]
Delivery-date: Sun, 09 Nov 2003 21:18:15 +0000
Message-ID: <4A0AE1E5A1AAD711AC1B00D0B7C2D4A2447E4A@cms1>
From: [email-masked]
To: [email-masked]
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: [email-masked]
Delivery-date: Sun, 09 Nov 2003 14:46:53 +0000
Message-ID: <[email-masked]>
From: John Drake
To: "'Ong, Lyndon'" , 'Adrian Farrel' , Jonathan Sadler , "Varma, Eve L (Eve)" , [email-masked]
Cc: [email-masked]
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:[email-masked]]
> Sent: Friday, November 07, 2003 2:41 PM
> To: 'Adrian Farrel'; Jonathan Sadler; Varma, Eve L (Eve);
> [email-masked]
> Cc: [email-masked]
> 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: [email-masked]
Delivery-date: Sat, 08 Nov 2003 17:19:56 +0000
Message-ID: <[email-masked]>
From: "Wijnen, Bert (Bert)"
To: Martin Dubuc , Adrian Farrel , [email-masked]
Cc: [email-masked], "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:[email-masked]]
> Sent: zaterdag 8 november 2003 16:59
> To: Adrian Farrel; [email-masked]
> Cc: [email-masked]; 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:[email-masked]]
> > > > Sent: woensdag 5 november 2003 18:01
> > > > To: Wijnen, Bert (Bert)
> > > > Cc: 'Kireeti Kompella'; [email-masked]; 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: [email-masked]
Delivery-date: Sat, 08 Nov 2003 16:05:00 +0000
Message-ID: <[email-masked]>
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:[email-masked]]
> > > Sent: woensdag 5 november 2003 18:01
> > > To: Wijnen, Bert (Bert)
> > > Cc: 'Kireeti Kompella'; [email-masked]; 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: [email-masked]
Delivery-date: Sat, 08 Nov 2003 07:13:45 +0000
Subject: Re: draft-ong-ccamp-3473-3474-iw-00.txt
To: [email-masked] (Ong, Lyndon)
Date: Sat, 8 Nov 2003 07:12:01 +0000 (GMT)
Cc: [email-masked] ('Adrian Farrel'), [email-masked] (Jonathan Sadler), [email-masked] ("Varma, Eve L (Eve)"), [email-masked], [email-masked]
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: [email-masked]
Delivery-date: Fri, 07 Nov 2003 22:42:21 +0000
Message-ID: <[email-masked]>
From: "Ong, Lyndon"
To: 'Adrian Farrel' , Jonathan Sadler , "Varma, Eve L (Eve)" , [email-masked]
Cc: [email-masked]
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: [email-masked]
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:[email-masked]]
> > Sent: woensdag 5 november 2003 18:01
> > To: Wijnen, Bert (Bert)
> > Cc: 'Kireeti Kompella'; [email-masked]; 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: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Diego Caviglia
> Sent: Thursday, November 06, 2003 5:01 AM
> To: [email-masked]
> 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: [email-masked]
Delivery-date: Thu, 06 Nov 2003 13:05:20 +0000
Sensitivity:
Subject: Notify message with ERO
To: [email-masked]
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: [email-masked]
Delivery-date: Wed, 05 Nov 2003 23:58:46 +0000
Message-ID: <[email-masked]>
From: John Drake
To: John Drake , 'Adrian Farrel' , "'Ong, Lyndon'" , 'Jonathan Sadler' , "'Varma, Eve L (Eve)'" , "[email-masked]'"
Cc: "[email-masked]'"
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);
> [email-masked]
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: Saturday, November 01, 2003 6:12 PM
> > To: Ong, Lyndon; Jonathan Sadler; Varma, Eve L (Eve);
> > [email-masked]
> > Cc: [email-masked]
> > 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: [email-masked]
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: [email-masked]
Delivery-date: Wed, 05 Nov 2003 02:49:46 +0000
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Tue, 04 Nov 2003 19:24:32 +0000
Message-ID: <[email-masked]>
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: [email-masked]
Delivery-date: Tue, 04 Nov 2003 12:15:03 +0000
Message-ID: <[email-masked]>
Date: Tue, 04 Nov 2003 13:15:29 +0100
From: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Heiles Juergen
CC: [email-masked]
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 : [email-masked]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491

Envelope-to: [email-masked]
Delivery-date: Tue, 04 Nov 2003 11:54:39 +0000
Message-ID:
From: Heiles Juergen
To: [email-masked]
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: [email-masked]
Delivery-date: Mon, 03 Nov 2003 23:58:30 +0000
Message-ID: <[email-masked]>
From: John Drake
To: 'Adrian Farrel' , "Ong, Lyndon" , Jonathan Sadler , "Varma, Eve L (Eve)" , [email-masked]
Cc: [email-masked]
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:[email-masked]]
> Sent: Saturday, November 01, 2003 6:12 PM
> To: Ong, Lyndon; Jonathan Sadler; Varma, Eve L (Eve);
> [email-masked]
> Cc: [email-masked]
> 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: [email-masked]
Delivery-date: Sun, 02 Nov 2003 07:49:12 +0000
Message-ID:
From: Nurit Sprecher
To: "[email-masked]'" , Nurit Sprecher
Cc: 'Adrian Farrel' , "[email-masked]'" , "[email-masked]'"
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:[email-masked]]
Sent: Thursday, October 30, 2003 3:40 PM
To: Nurit Sprecher
Cc: 'Adrian Farrel'; [email-masked]'; [email-masked]
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: [email-masked]
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: [email-masked]
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