Re: TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt

[[e-mail]]

hi jp,

see in-line:

> Thanks for your useful comments here. See below,
> 
> At 02:18 PM 3/30/2004 +0200, [e-mail] wrote:
> 
>> hi jl, here below several comments on this updated version of the 
>> document:
>>
>> 1) section 5.3.1 mentions:
>>
>> "The solution MUST entirely preserve the concept of IGP hierarchy. In
>>    other words, flooding of TE link information across areas MUST be
>>    precluded."
>>
>> section 5.3.2 mentions:
>>
>> "The solution MUST also not increase IGP load which could compromise
>>    IGP scalability. In particular, a solution satisfying those
>>    requirements MUST not require for the IGP to carry some unreasonable
>>    amount of extra information and MUST not unreasonably increase the
>>    IGP flooding frequency."
>>
>> but section 7.12 tells:
>>
>> "The discovery mechanism SHOULD
>>    be applicable across multiple IGP areas, and SHOULD not impact the
>>    IGP scalability, provided that IGP extensions are used for such a
>>    discovery mechanism."
>>
>> -> would it be possible to align these requirements, i get the 
>> impression (please confirm) that you preclude TE link information but 
>> you would allow for node information (auto-mesh) ? note also that the 
>> section 7.12 doesn't tell us a lot about the expected distribution of 
>> the mesh
> 
> 
> The solution MUST preclude to flood TE-related link information and MUST 
> not compromise the IGP scalability in any circumstances. That being 
> said, IGP based mechanisms can be used for the discovery which will 
> respect the requirement mentioned above,

i understand to what you're referring, but please make it clear
imho it would help if in section 7.12 the exact meaning of the
following "*some* discovery mechanisms" was detailed so that the
reader can more accurately assess the scope of the above

>> 2) section 7.3
>>
>> "   In the context of this requirement document, an optimal path is
>>    defined as the shortest path across multiple areas taking into
>>    account either the IGP or TE metric. "
>>
>> are you referring here to
>> <http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-02.txt> 
>>
>>
>> would you clarify ?
> 
> 
> Sure, we will add some text. The reason for this clarification is that 
> there are a multitude of definitions for an optimal path: paths that 
> minimize the max link utilization, call set up failure, ... here we just 
> refer to the ability to compute a shortest path (using either the IGP or 
> TE metric).

ok

>> 3) section 7.3
>>
>> it is not clear for me what is behind the last part of the following 
>> sentence
>>
>> "So a solution should support both mechanisms, and SHOULD allow
>>    the operator to select by configuration, and on a per-LSP basis, the
>>    required level of optimality. "
>>
>> what is meant by "level of optimality" ? is it simply "optimal - 
>> sub-optimal" or do you have something else in mind ?
> 
> 
> We will clarify. The idea is that the ability to compute an end to end 
> shortest path may not be required for all inter-area TE LSPs. Hence the 
> solution should allow the operator to select the appropriate path 
> computation method.

ok, would be interesting to see whether operators would like to have 
selection based on the computational method (allow for intermediate 
computation or any other option suitable in this context) or based on 
the optimality level (then the solution itself selects the appropriate 
computational method) or simply both

>> 4) section 7.4
>>
>> "Another example is the requirement to set up multiple TE LSPs between
>>    a pair of LSRs residing in different IGP areas in case a single TE
>>    LSP satisfying the set of requirements could not be found. "
>>
>> why in such a case diversity would be desirable ?
> 
> 
> for either path protection or load balancing while minimizing the impact 
> in case of failure.
> 
>> got the impression that if a single path would have been feasible it 
>> would have been selected in this case - isn't it ?
> 
> 
> That being said, we need to rephrase, I agree with you that this 
> paragraph is not clear. It should read:
> 
> "Another example is the requirement to set up multiple TE LSPs between a 
> pair of LSRs residing in different IGP areas. For instance, this would 
> occur if TE LSP satisfying for instance the bandwidth requirement could 
> be found, hence, requiring to set up multiple TE LSPs"

the former point(s) seem clearer, is it "could be found" or "could not 
be found" ?

>> 5) section 7.7
>>
>> "This may reduce the recovery delay, but with the risk of
>>    multiple crankbacks, and sub-optimality.  "
>>
>> i agree, but this is valid iff the head-end has initially computed an 
>> end-to-end optimal path,
> 
> 
> more exactly this applies to contiguous LSP. For sub-optimality this 
> applies to any kind of LSP.

well i think that a contiguous LSP can still be sub-optimal hence
i would suggest to not implicitly attach the crankback functionality
to the signaling method, but to make clear what are the potential
issues in terms of optimality as said "iff the path was initially
computed as an end-to-end optimal"

>> also unclear if you refer also here to the provisioning delay ?
>>
>> editorially speaking it is also a bit unclear why you've splitted 
>> section 7.7 and section 7.8 both refers to inter-area lsp recovery

i don't know if this could be taken into account, this would simplify
reading and subsequent utilisation of the document

>> 6) section 7.11
>>
>> would it be possible to mention what's expected (or not expected) in 
>> terms also of hard preemption ?
> 
> 
> ok

just a hint here, is my understanding correct that the following 
sentence "The lower priority LSP is not torn down and can continue to 
forward traffic on a best-effort basis." infers that you would have to 
priority high/low only so i'd would instead be more generic here in
terms of priorities

>> 7) section 8.2
>>
>> what's meant by stability ? ie stability of what ? (for instance, as i 
>> read the document, but please correct me, stability and 
>> re-optimization are imho two features that are going in somehow 
>> opposite directions so a trade-off has to be found here)
> 
> 
> We will clarify.

ok

> thanks for your comments !

hope to see the next version soon, would also be interesting to see 
other people commenting here

thanks,
- dimitri.

> JP.
> 
>> thanks in advance,
>> - dimitri.
>>
>> LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
>>
>>> Hi all,
>>> Thanks in advance for your comments on this new revision of inter-area
>>> TE requirements.
>>> Regards,
>>> JL
>>>
>>>> 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           : Requirements for Inter-area MPLS Traffic
>>>
>>> Engineering
>>>
>>>>        Author(s)       : J. Le Roux, et al.
>>>>        Filename        : draft-ietf-tewg-interarea-mpls-te-req-00.txt
>>>>        Pages           : 20
>>>>        Date            : 2004-3-26
>>>>
>>>> This document lists a detailed set of functional requirements for the
>>>> support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) 
>>>> which could serve as a guideline to develop the required set of 
>>>> protocol extensions.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-r
>>>
>>> eq-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-ietf-tewg-interarea-mpls-te-req-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
>>>
>>>
>>
>> -- 
>> Papadimitriou Dimitri
>> E-mail : [e-mail]
>> E-mail : [e-mail]
>> Webpage: http://psg.com/~dpapadimitriou/
>> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>> Phone  : [phone]
>>
>>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]





Envelope-to: [e-mail]
Delivery-date: Wed, 31 Mar 2004 17:52:48 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 2004 19:52:02 +0200
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Jean Philippe Vasseur <[e-mail]>
Cc: LE ROUX Jean-Louis FTRD/DAC/LAN <[e-mail]>, [e-mail], [e-mail]
Subject: Re: TR : I-D  ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi jp,

see in-line:

> Thanks for your useful comments here. See below,
> 
> At 02:18 PM 3/30/2004 +0200, [e-mail] wrote:
> 
>> hi jl, here below several comments on this updated version of the 
>> document:
>>
>> 1) section 5.3.1 mentions:
>>
>> "The solution MUST entirely preserve the concept of IGP hierarchy. In
>>    other words, flooding of TE link information across areas MUST be
>>    precluded."
>>
>> section 5.3.2 mentions:
>>
>> "The solution MUST also not increase IGP load which could compromise
>>    IGP scalability. In particular, a solution satisfying those
>>    requirements MUST not require for the IGP to carry some unreasonable
>>    amount of extra information and MUST not unreasonably increase the
>>    IGP flooding frequency."
>>
>> but section 7.12 tells:
>>
>> "The discovery mechanism SHOULD
>>    be applicable across multiple IGP areas, and SHOULD not impact the
>>    IGP scalability, provided that IGP extensions are used for such a
>>    discovery mechanism."
>>
>> -> would it be possible to align these requirements, i get the 
>> impression (please confirm) that you preclude TE link information but 
>> you would allow for node information (auto-mesh) ? note also that the 
>> section 7.12 doesn't tell us a lot about the expected distribution of 
>> the mesh
> 
> 
> The solution MUST preclude to flood TE-related link information and MUST 
> not compromise the IGP scalability in any circumstances. That being 
> said, IGP based mechanisms can be used for the discovery which will 
> respect the requirement mentioned above,

i understand to what you're referring, but please make it clear
imho it would help if in section 7.12 the exact meaning of the
following "*some* discovery mechanisms" was detailed so that the
reader can more accurately assess the scope of the above

>> 2) section 7.3
>>
>> "   In the context of this requirement document, an optimal path is
>>    defined as the shortest path across multiple areas taking into
>>    account either the IGP or TE metric. "
>>
>> are you referring here to
>> <http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-02.txt> 
>>
>>
>> would you clarify ?
> 
> 
> Sure, we will add some text. The reason for this clarification is that 
> there are a multitude of definitions for an optimal path: paths that 
> minimize the max link utilization, call set up failure, ... here we just 
> refer to the ability to compute a shortest path (using either the IGP or 
> TE metric).

ok

>> 3) section 7.3
>>
>> it is not clear for me what is behind the last part of the following 
>> sentence
>>
>> "So a solution should support both mechanisms, and SHOULD allow
>>    the operator to select by configuration, and on a per-LSP basis, the
>>    required level of optimality. "
>>
>> what is meant by "level of optimality" ? is it simply "optimal - 
>> sub-optimal" or do you have something else in mind ?
> 
> 
> We will clarify. The idea is that the ability to compute an end to end 
> shortest path may not be required for all inter-area TE LSPs. Hence the 
> solution should allow the operator to select the appropriate path 
> computation method.

ok, would be interesting to see whether operators would like to have 
selection based on the computational method (allow for intermediate 
computation or any other option suitable in this context) or based on 
the optimality level (then the solution itself selects the appropriate 
computational method) or simply both

>> 4) section 7.4
>>
>> "Another example is the requirement to set up multiple TE LSPs between
>>    a pair of LSRs residing in different IGP areas in case a single TE
>>    LSP satisfying the set of requirements could not be found. "
>>
>> why in such a case diversity would be desirable ?
> 
> 
> for either path protection or load balancing while minimizing the impact 
> in case of failure.
> 
>> got the impression that if a single path would have been feasible it 
>> would have been selected in this case - isn't it ?
> 
> 
> That being said, we need to rephrase, I agree with you that this 
> paragraph is not clear. It should read:
> 
> "Another example is the requirement to set up multiple TE LSPs between a 
> pair of LSRs residing in different IGP areas. For instance, this would 
> occur if TE LSP satisfying for instance the bandwidth requirement could 
> be found, hence, requiring to set up multiple TE LSPs"

the former point(s) seem clearer, is it "could be found" or "could not 
be found" ?

>> 5) section 7.7
>>
>> "This may reduce the recovery delay, but with the risk of
>>    multiple crankbacks, and sub-optimality.  "
>>
>> i agree, but this is valid iff the head-end has initially computed an 
>> end-to-end optimal path,
> 
> 
> more exactly this applies to contiguous LSP. For sub-optimality this 
> applies to any kind of LSP.

well i think that a contiguous LSP can still be sub-optimal hence
i would suggest to not implicitly attach the crankback functionality
to the signaling method, but to make clear what are the potential
issues in terms of optimality as said "iff the path was initially
computed as an end-to-end optimal"

>> also unclear if you refer also here to the provisioning delay ?
>>
>> editorially speaking it is also a bit unclear why you've splitted 
>> section 7.7 and section 7.8 both refers to inter-area lsp recovery

i don't know if this could be taken into account, this would simplify
reading and subsequent utilisation of the document

>> 6) section 7.11
>>
>> would it be possible to mention what's expected (or not expected) in 
>> terms also of hard preemption ?
> 
> 
> ok

just a hint here, is my understanding correct that the following 
sentence "The lower priority LSP is not torn down and can continue to 
forward traffic on a best-effort basis." infers that you would have to 
priority high/low only so i'd would instead be more generic here in
terms of priorities

>> 7) section 8.2
>>
>> what's meant by stability ? ie stability of what ? (for instance, as i 
>> read the document, but please correct me, stability and 
>> re-optimization are imho two features that are going in somehow 
>> opposite directions so a trade-off has to be found here)
> 
> 
> We will clarify.

ok

> thanks for your comments !

hope to see the next version soon, would also be interesting to see 
other people commenting here

thanks,
- dimitri.

> JP.
> 
>> thanks in advance,
>> - dimitri.
>>
>> LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
>>
>>> Hi all,
>>> Thanks in advance for your comments on this new revision of inter-area
>>> TE requirements.
>>> Regards,
>>> JL
>>>
>>>> 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           : Requirements for Inter-area MPLS Traffic
>>>
>>> Engineering
>>>
>>>>        Author(s)       : J. Le Roux, et al.
>>>>        Filename        : draft-ietf-tewg-interarea-mpls-te-req-00.txt
>>>>        Pages           : 20
>>>>        Date            : 2004-3-26
>>>>
>>>> This document lists a detailed set of functional requirements for the
>>>> support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) 
>>>> which could serve as a guideline to develop the required set of 
>>>> protocol extensions.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-r
>>>
>>> eq-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-ietf-tewg-interarea-mpls-te-req-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
>>>
>>>
>>
>> -- 
>> Papadimitriou Dimitri
>> E-mail : [e-mail]
>> E-mail : [e-mail]
>> Webpage: http://psg.com/~dpapadimitriou/
>> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>> Phone  : [phone]
>>
>>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Wed, 31 Mar 2004 07:07:50 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 2004 09:07:25 +0200
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Bhaskara Peela <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: status of draft
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi, it means that the document will be published as is (including
the suklm format) once the cross reference issue is solved

thanks,
- dimitri.

Bhaskara Peela wrote:

> Hi Dimitri,
> 
> This is my question regarding SUKLM format.  Are we going to foresee any
> changes to SUKLM format or is it going to be accepted as it is as a final
> RFC? 
> 
> Thank you
> bhaskara
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] 
> Sent: Tuesday, March 30, 2004 2:40 PM
> To: Bhaskara Peela
> Cc: Adrian Farrel; '[e-mail]'; [e-mail];
> [e-mail]
> Subject: Re: Layer One VPNs
> 
> hi, the document is in the RFC Editor queue, due to a cross-reference 
> issue (with the GMPLS-ARCH document) since mid of last year -
> 
> thanks,
> - dimitri.
> 
> Bhaskara Peela wrote:
> 
> 
>>Hi,
>>
>>We see draft,
>>
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
> 
>>titled, "Generalized Multi-Protocol Label Switching Extensions for SONET
> 
> and
> 
>>SDH Control" expired in August 2003.  Is there any update on this?  I am
> 
> not
> 
>>able to find any update on IETF.  
>>
>>Are there changes to the definition of SUKLM format from this draft? 
>>
>>Thank you
>>bhaskara
>>
>>
>> 
>>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 30 Mar 2004 23:13:32 +0000
Message-ID: <[e-mail]>
From: Bhaskara Peela <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Bhaskara Peela <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: status of draft
Date: Tue, 30 Mar 2004 15:12:41 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C416AC.80237590"

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_01C416AC.80237590
Content-Type: text/plain


Hi Dimitri,

This is my question regarding SUKLM format.  Are we going to foresee any
changes to SUKLM format or is it going to be accepted as it is as a final
RFC? 

Thank you
bhaskara
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Tuesday, March 30, 2004 2:40 PM
To: Bhaskara Peela
Cc: Adrian Farrel; '[e-mail]'; [e-mail];
[e-mail]
Subject: Re: Layer One VPNs

hi, the document is in the RFC Editor queue, due to a cross-reference 
issue (with the GMPLS-ARCH document) since mid of last year -

thanks,
- dimitri.

Bhaskara Peela wrote:

> Hi,
> 
> We see draft,
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
> titled, "Generalized Multi-Protocol Label Switching Extensions for SONET
and
> SDH Control" expired in August 2003.  Is there any update on this?  I am
not
> able to find any update on IETF.  
> 
> Are there changes to the definition of SUKLM format from this draft? 
> 
> Thank you
> bhaskara
> 
> 
>  
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]

------_=_NextPart_001_01C416AC.80237590
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: status of draft</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Hi Dimitri,</FONT>
</P>

<P><FONT SIZE=3D2>This is my question regarding SUKLM format.&nbsp; Are =
we going to foresee any changes to SUKLM format or is it going to be =
accepted as it is as a final RFC? </FONT></P>

<P><FONT SIZE=3D2>Thank you</FONT>
<BR><FONT SIZE=3D2>bhaskara</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:Dimitri.Papadimi=
[e-mail]</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 30, 2004 2:40 PM</FONT>
<BR><FONT SIZE=3D2>To: Bhaskara Peela</FONT>
<BR><FONT SIZE=3D2>Cc: Adrian Farrel; '[e-mail]'; =
[e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Layer One VPNs</FONT>
</P>

<P><FONT SIZE=3D2>hi, the document is in the RFC Editor queue, due to a =
cross-reference </FONT>
<BR><FONT SIZE=3D2>issue (with the GMPLS-ARCH document) since mid of =
last year -</FONT>
</P>

<P><FONT SIZE=3D2>thanks,</FONT>
<BR><FONT SIZE=3D2>- dimitri.</FONT>
</P>

<P><FONT SIZE=3D2>Bhaskara Peela wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We see draft,</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet=
-sdh-08.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-g=
mpls-sonet-sdh-08.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; titled, &quot;Generalized Multi-Protocol Label =
Switching Extensions for SONET and</FONT>
<BR><FONT SIZE=3D2>&gt; SDH Control&quot; expired in August 2003.&nbsp; =
Is there any update on this?&nbsp; I am not</FONT>
<BR><FONT SIZE=3D2>&gt; able to find any update on IETF.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Are there changes to the definition of SUKLM =
format from this draft? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thank you</FONT>
<BR><FONT SIZE=3D2>&gt; bhaskara</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Papadimitriou Dimitri</FONT>
<BR><FONT SIZE=3D2>E-mail : [e-mail]</FONT>
<BR><FONT SIZE=3D2>E-mail : [e-mail]</FONT>
<BR><FONT SIZE=3D2>Webpage: <A HREF=3D"http://psg.com/~dpapadimitriou/" =
TARGET=3D"_blank">http://psg.com/~dpapadimitriou/</A></FONT>
<BR><FONT SIZE=3D2>Address: Fr. Wellesplein 1, B-2018 Antwerpen, =
Belgium</FONT>
<BR><FONT SIZE=3D2>Phone&nbsp; : [phone]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C416AC.80237590--



Envelope-to: [e-mail]
Delivery-date: Tue, 30 Mar 2004 22:38:41 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 2004 00:39:49 +0200
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Bhaskara Peela <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Layer One VPNs
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi, the document is in the RFC Editor queue, due to a cross-reference 
issue (with the GMPLS-ARCH document) since mid of last year -

thanks,
- dimitri.

Bhaskara Peela wrote:

> Hi,
> 
> We see draft,
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
> titled, "Generalized Multi-Protocol Label Switching Extensions for SONET and
> SDH Control" expired in August 2003.  Is there any update on this?  I am not
> able to find any update on IETF.  
> 
> Are there changes to the definition of SUKLM format from this draft? 
> 
> Thank you
> bhaskara
> 
> 
>  
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 30 Mar 2004 22:27:06 +0000
Message-ID: <[e-mail]>
From: Bhaskara Peela <[e-mail]>
To: Bhaskara Peela <[e-mail]>, Adrian Farrel <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: Status of draft
Date: Tue, 30 Mar 2004 14:26:47 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C416A6.16B5EC60"

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_01C416A6.16B5EC60
Content-Type: text/plain

 

Hi, 

We see draft,
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
>  titled, "Generalized Multi-Protocol Label Switching Extensions for SONET
and SDH Control" expired in August 2003.  Is there any update on this?  I am
not able to find any update on IETF.  

Are there changes to the definition of SUKLM format from this draft? 

Thank you 
bhaskara 

 

  


------_=_NextPart_001_01C416A6.16B5EC60
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">
<title>RE: Layer One VPNs</title>

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&nbsp;</span></font></p>

<p style='margin-left:.5in'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>Hi,</span></font> </p>

<p style='margin-left:.5in'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>We see draft, <a
href="http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt"
target="_blank">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt</a>
titled, &quot;Generalized Multi-Protocol Label Switching Extensions for SONET
and SDH Control&quot; expired in August 2003.&nbsp; Is there any update on
this?&nbsp; I am not able to find any update on IETF.&nbsp; </span></font></p>

<p style='margin-left:.5in'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>Are there changes to the definition of SUKLM format
from this draft? </span></font></p>

<p style='margin-left:.5in'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>Thank you</span></font> <br>
<font size=2><span style='font-size:10.0pt'>bhaskara</span></font> </p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&nbsp;</span></font></p>

<p style='margin-left:.5in'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>&nbsp;</span></font> </p>

</div>

</body>

</html>

------_=_NextPart_001_01C416A6.16B5EC60--



Envelope-to: [e-mail]
Delivery-date: Tue, 30 Mar 2004 22:25:38 +0000
Message-ID: <[e-mail]>
From: Bhaskara Peela <[e-mail]>
To: Adrian Farrel <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Layer One VPNs
Date: Tue, 30 Mar 2004 14:24:25 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C416A5.C1DDF3E0"

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_01C416A5.C1DDF3E0
Content-Type: text/plain


Hi,

We see draft,
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
titled, "Generalized Multi-Protocol Label Switching Extensions for SONET and
SDH Control" expired in August 2003.  Is there any update on this?  I am not
able to find any update on IETF.  

Are there changes to the definition of SUKLM format from this draft? 

Thank you
bhaskara


 

------_=_NextPart_001_01C416A5.C1DDF3E0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Layer One VPNs</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>We see draft, <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet=
-sdh-08.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-g=
mpls-sonet-sdh-08.txt</A> titled, &quot;Generalized Multi-Protocol =
Label Switching Extensions for SONET and SDH Control&quot; expired in =
August 2003.&nbsp; Is there any update on this?&nbsp; I am not able to =
find any update on IETF.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Are there changes to the definition of SUKLM format =
from this draft? </FONT>
</P>

<P><FONT SIZE=3D2>Thank you</FONT>
<BR><FONT SIZE=3D2>bhaskara</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C416A5.C1DDF3E0--



Envelope-to: [e-mail]
Delivery-date: Tue, 30 Mar 2004 18:48:49 +0000
Message-ID: <[e-mail]>
From: "Hamid Ould-Brahim" <[e-mail]>
To: Yakov Rekhter <[e-mail]>, Adrian Farrel <[e-mail]>
Cc: [e-mail]
Subject: RE: Layer One VPNs
Date: Tue, 30 Mar 2004 13:46:37 -0500

Yakov,

> >
> > Although Layer One VPNs do not currently have a home in any IETF 
> > working group, we were the recipients of a liaison from ITU-T SG13 
> > informing us about the work they are doing on this topic 
> and pointing 
> > us at 
> > 
> http://www.ietf.org/internet-drafts/draft-> takeda-l1vpn-framework-00.tx
> > t
> >
> > If anyone has comments on this work they can send them to 
> this mailing 
> > list (until another home is found in the IETF) or to the authors 
> > direct.
> 
> I think that this is important work, and that the home for 
> this work in the IETF should be the CCAMP WG.
> 

Yes. I agree. (seems to me a logical step).

Hamid.



Envelope-to: [e-mail]
Delivery-date: Tue, 30 Mar 2004 12:37:04 +0000
Message-Id: <[e-mail]>
Date: Tue, 30 Mar 2004 07:36:28 -0500
To: [e-mail]
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt
Cc: LE ROUX Jean-Louis FTRD/DAC/LAN <[e-mail]>, [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Dimitri,

Thanks for your useful comments here. See below,

At 02:18 PM 3/30/2004 +0200, [e-mail] wrote:
>hi jl, here below several comments on this updated version of the document:
>
>1) section 5.3.1 mentions:
>
>"The solution MUST entirely preserve the concept of IGP hierarchy. In
>    other words, flooding of TE link information across areas MUST be
>    precluded."
>
>section 5.3.2 mentions:
>
>"The solution MUST also not increase IGP load which could compromise
>    IGP scalability. In particular, a solution satisfying those
>    requirements MUST not require for the IGP to carry some unreasonable
>    amount of extra information and MUST not unreasonably increase the
>    IGP flooding frequency."
>
>but section 7.12 tells:
>
>"The discovery mechanism SHOULD
>    be applicable across multiple IGP areas, and SHOULD not impact the
>    IGP scalability, provided that IGP extensions are used for such a
>    discovery mechanism."
>
>-> would it be possible to align these requirements, i get the impression 
>(please confirm) that you preclude TE link information but you would allow 
>for node information (auto-mesh) ? note also that the section 7.12 doesn't 
>tell us a lot about the expected distribution of the mesh

The solution MUST preclude to flood TE-related link information and MUST 
not compromise the IGP scalability in any circumstances. That being said, 
IGP based mechanisms can be used for the discovery which will respect the 
requirement mentioned above,

>2) section 7.3
>
>"   In the context of this requirement document, an optimal path is
>    defined as the shortest path across multiple areas taking into
>    account either the IGP or TE metric. "
>
>are you referring here to
><http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-02.txt>
>
>would you clarify ?

Sure, we will add some text. The reason for this clarification is that 
there are a multitude of definitions for an optimal path: paths that 
minimize the max link utilization, call set up failure, ... here we just 
refer to the ability to compute a shortest path (using either the IGP or TE 
metric).


>3) section 7.3
>
>it is not clear for me what is behind the last part of the following sentence
>
>"So a solution should support both mechanisms, and SHOULD allow
>    the operator to select by configuration, and on a per-LSP basis, the
>    required level of optimality. "
>
>what is meant by "level of optimality" ? is it simply "optimal - 
>sub-optimal" or do you have something else in mind ?

We will clarify. The idea is that the ability to compute an end to end 
shortest path may not be required for all inter-area TE LSPs. Hence the 
solution should allow the operator to select the appropriate path 
computation method.

>4) section 7.4
>
>"Another example is the requirement to set up multiple TE LSPs between
>    a pair of LSRs residing in different IGP areas in case a single TE
>    LSP satisfying the set of requirements could not be found. "
>
>why in such a case diversity would be desirable ?

for either path protection or load balancing while minimizing the impact in 
case of failure.

>got the impression that if a single path would have been feasible it would 
>have been selected in this case - isn't it ?

That being said, we need to rephrase, I agree with you that this paragraph 
is not clear. It should read:

"Another example is the requirement to set up multiple TE LSPs between a 
pair of LSRs residing in different IGP areas. For instance, this would 
occur if TE LSP satisfying for instance the bandwidth requirement could be 
found, hence, requiring to set up multiple TE LSPs"

>5) section 7.7
>
>"This may reduce the recovery delay, but with the risk of
>    multiple crankbacks, and sub-optimality.  "
>
>i agree, but this is valid iff the head-end has initially computed an 
>end-to-end optimal path,

more exactly this applies to contiguous LSP. For sub-optimality this 
applies to any kind of LSP.

>also unclear if you refer also here to the provisioning delay ?
>
>editorially speaking it is also a bit unclear why you've splitted section 
>7.7 and section 7.8 both refers to inter-area lsp recovery
>
>6) section 7.11
>
>would it be possible to mention what's expected (or not expected) in terms 
>also of hard preemption ?

ok


>7) section 8.2
>
>what's meant by stability ? ie stability of what ? (for instance, as i 
>read the document, but please correct me, stability and re-optimization 
>are imho two features that are going in somehow opposite directions so a 
>trade-off has to be found here)

We will clarify.

thanks for your comments !

JP.

>thanks in advance,
>- dimitri.
>
>LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
>
>>Hi all,
>>Thanks in advance for your comments on this new revision of inter-area
>>TE requirements.
>>Regards,
>>JL
>>
>>>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           : Requirements for Inter-area MPLS Traffic
>>Engineering
>>
>>>        Author(s)       : J. Le Roux, et al.
>>>        Filename        : draft-ietf-tewg-interarea-mpls-te-req-00.txt
>>>        Pages           : 20
>>>        Date            : 2004-3-26
>>>
>>>This document lists a detailed set of functional requirements for the
>>>support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) 
>>>which could serve as a guideline to develop the required set of protocol 
>>>extensions.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-r
>>eq-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-ietf-tewg-interarea-mpls-te-req-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
>>
>
>--
>Papadimitriou Dimitri
>E-mail : [e-mail]
>E-mail : [e-mail]
>Webpage: http://psg.com/~dpapadimitriou/
>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>Phone  : [phone]
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 30 Mar 2004 12:17:57 +0000
Message-ID: <[e-mail]>
Date: Tue, 30 Mar 2004 14:18:21 +0200
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: LE ROUX Jean-Louis FTRD/DAC/LAN <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi jl, here below several comments on this updated version of the document:

1) section 5.3.1 mentions:

"The solution MUST entirely preserve the concept of IGP hierarchy. In
    other words, flooding of TE link information across areas MUST be
    precluded."

section 5.3.2 mentions:

"The solution MUST also not increase IGP load which could compromise
    IGP scalability. In particular, a solution satisfying those
    requirements MUST not require for the IGP to carry some unreasonable
    amount of extra information and MUST not unreasonably increase the
    IGP flooding frequency."

but section 7.12 tells:

"The discovery mechanism SHOULD
    be applicable across multiple IGP areas, and SHOULD not impact the
    IGP scalability, provided that IGP extensions are used for such a
    discovery mechanism."

-> would it be possible to align these requirements, i get the 
impression (please confirm) that you preclude TE link information but 
you would allow for node information (auto-mesh) ? note also that the 
section 7.12 doesn't tell us a lot about the expected distribution of 
the mesh

2) section 7.3

"   In the context of this requirement document, an optimal path is
    defined as the shortest path across multiple areas taking into
    account either the IGP or TE metric. "

are you referring here to
<http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-02.txt>

would you clarify ?

3) section 7.3

it is not clear for me what is behind the last part of the following 
sentence

"So a solution should support both mechanisms, and SHOULD allow
    the operator to select by configuration, and on a per-LSP basis, the
    required level of optimality. "

what is meant by "level of optimality" ? is it simply "optimal - 
sub-optimal" or do you have something else in mind ?

4) section 7.4

"Another example is the requirement to set up multiple TE LSPs between
    a pair of LSRs residing in different IGP areas in case a single TE
    LSP satisfying the set of requirements could not be found. "

why in such a case diversity would be desirable ? got the impression 
that if a single path would have been feasible it would have been 
selected in this case - isn't it ?

5) section 7.7

"This may reduce the recovery delay, but with the risk of
    multiple crankbacks, and sub-optimality.  "

i agree, but this is valid iff the head-end has initially computed an 
end-to-end optimal path, also unclear if you refer also here to the 
provisioning delay ?

editorially speaking it is also a bit unclear why you've splitted 
section 7.7 and section 7.8 both refers to inter-area lsp recovery

6) section 7.11

would it be possible to mention what's expected (or not expected) in 
terms also of hard preemption ?

7) section 8.2

what's meant by stability ? ie stability of what ? (for instance, as i 
read the document, but please correct me, stability and re-optimization 
are imho two features that are going in somehow opposite directions so a 
trade-off has to be found here)

thanks in advance,
- dimitri.

LE ROUX Jean-Louis FTRD/DAC/LAN wrote:

> Hi all,
> 
> Thanks in advance for your comments on this new revision of inter-area
> TE requirements.
> 
> Regards,
> 
> JL
> 
> 
>>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           : Requirements for Inter-area MPLS Traffic
> 
> Engineering
> 
>>        Author(s)       : J. Le Roux, et al.
>>        Filename        : draft-ietf-tewg-interarea-mpls-te-req-00.txt
>>        Pages           : 20
>>        Date            : 2004-3-26
>>
>>This document lists a detailed set of functional requirements for the
>>support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) 
>>which could serve as a guideline to develop the required set of 
>>protocol extensions.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-r
> 
> eq-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-ietf-tewg-interarea-mpls-te-req-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
> 
>>

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 30 Mar 2004 01:26:16 +0000
Message-Id: <[e-mail]>
Date: Tue, 30 Mar 2004 10:25:46 +0900
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
From: Tomohiro Otani <[e-mail]>
Subject: Re: Layer One VPNs
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

Hi Aridian

I also agree to investigate this item as a WG document.
Is this related to a former WG document of 
"draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-xx.txt"

Regards,

tomo

At 11:28 04/03/13 +0000, Adrian Farrel wrote:
>Hi,
>
>Although Layer One VPNs do not currently have a home in any IETF working 
>group, we were
>the recipients of a liaison from ITU-T SG13 informing us about the work 
>they are doing on
>this topic and pointing us at
>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
>
>If anyone has comments on this work they can send them to this mailing list 
>(until another
>home is found in the IETF) or to the authors direct.
>
>Thanks,
>Adrian

------------------------------------
Tomohiro Otani
KDDI R&D Laboratories, Inc.
Optical network architecture lab.
2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan
TEL: [phone]
FAX: [phone]
E-mail: [e-mail]
------------------------------------





Envelope-to: [e-mail]
Delivery-date: Tue, 30 Mar 2004 00:51: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: Layer One VPNs
Date: Mon, 29 Mar 2004 18:51:09 -0600
Message-ID: <[e-mail]>
Thread-Topic: Layer One VPNs
Thread-Index: AcQV5QPEihiO6HLYSFGMCwXW5Ly1GgAC4t7A
From: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>, <[e-mail]>

Adrian> Although Layer One VPNs do not currently have a home in any IETF =
working
Adrian> group, we were the recipients of a liaison from ITU-T SG13 =
informing us
Adrian> about the work they are doing on this topic and pointing us at
Adrian> =
<http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt>=


Yakov> I think that this is important work, and that the home for this
Yakov> work in the IETF should be the CCAMP WG.

I agree also.

Jerry





Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 23:26:42 +0000
Message-ID: <196b01c415e5$467bf780$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Martin Dubuc" <[e-mail]>, "Wijnen, Bert \(Bert\)" <[e-mail]>
Subject: Further WG Last Call on LMP MIB
Date: Tue, 30 Mar 2004 00:25:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Martin has done a sterling job updating the LMP MIB after the usual thorough and careful
review by Bert.

In view of the number of changes (although none is very major) we are holding another
working group last call on this draft.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-08.txt

Please send your comments to the list.

The last call will end on Thursday 8th April at 12 noon GMT.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 23:24:11 +0000
Message-Id: <6.0.3.0.2.20040329175823.04971a48@mo-ex1>
Date: Mon, 29 Mar 2004 17:59:25 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Layer One VPNs
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I too agree.

At 10:35 AM 3/29/2004 -0500, Yakov Rekhter wrote:

>Adrian,
>
> > Hi,
> >
> > Although Layer One VPNs do not currently have a home in any IETF working
> > group, we were the recipients of a liaison from ITU-T SG13 informing us
> > about the work they are doing on this topic and pointing us at
> > 
> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt 
>
> >
> > If anyone has comments on this work they can send them to this mailing
> > list (until another home is found in the IETF) or to the authors direct.
>
>I think that this is important work, and that the home for this
>work in the IETF should be the CCAMP WG.
>
>Yakov.




Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 23:10:13 +0000
Message-Id: <6.0.3.0.2.20040329180856.04c79d08@mo-ex1>
Date: Mon, 29 Mar 2004 18:09:16 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: draft-berger-ccamp-gmpls-segment-recovery-00.txt
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

done.

Thanks,
Lou

At 02:17 PM 3/29/2004 -0500, Adrian Farrel wrote:

>OK authors, please resubmit this as a WG draft.
>
>Thanks.
>
>Adrian
>----- Original Message -----
>From: "Adrian Farrel" <[e-mail]>
>To: <[e-mail]>
>Sent: Saturday, March 13, 2004 11:40 AM
>Subject: draft-berger-ccamp-gmpls-segment-recovery-00.txt
>
> > All,
> >
> > I have heard rough consensus on this draft becoming a working group 
> draft, but in view
>of
> > a few people who have expressed concern, I would like to leave this 
> open for a few more
> > days.
> >
> > Please, if you have concrete issues with this draft, raise them on the 
> list as soon as
> > possible.
> >
> > Thanks,
> > Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 20:04:38 +0000
Date: Mon, 29 Mar 2004 12:04:02 -0800
From: David Meyer <[e-mail]>
To: "Alanqar, Wesam I [NTK]" <[e-mail]>
Cc: John Drake <[e-mail]>, Yakov Rekhter <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: Layer One VPNs
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

On Mon, Mar 29, 2004 at 01:52:30PM -0600, Alanqar, Wesam I [NTK] wrote:
>> I support this work to be developed in CCAMP.

	Ditto.

	Dave



Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 19:59:02 +0000
Message-ID: <[e-mail]>
From: "Cao, Yang" <[e-mail]>
To: "'Alanqar, Wesam I [NTK]'" <[e-mail]>, John Drake <[e-mail]>, Yakov Rekhter  <[e-mail]>, Adrian Farrel  <[e-mail]>
Cc: [e-mail]
Subject: RE: Layer One VPNs
Date: Mon, 29 Mar 2004 15:02:05 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

I also support this work to be developed in CCAMP.

-----Original Message-----
From: Alanqar, Wesam I [NTK] [mailto:[e-mail]]
Sent: Monday, March 29, 2004 2:53 PM
To: John Drake; Yakov Rekhter ; Adrian Farrel 
Cc: [e-mail]
Subject: RE: Layer One VPNs


I support this work to be developed in CCAMP.

Thanks,
-Wesam Alanqar                         
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of John Drake
Sent: Monday, March 29, 2004 10:18 AM
To: 'Yakov Rekhter '; 'Adrian Farrel '
Cc: '[e-mail] '
Subject: RE: Layer One VPNs


 Agreed

-----Original Message-----
From: Yakov Rekhter
To: Adrian Farrel
Cc: [e-mail]
Sent: 3/29/2004 7:35 AM
Subject: Layer One VPNs

Adrian,

> Hi,
>
> Although Layer One VPNs do not currently have a home in any IETF
working
> group, we were the recipients of a liaison from ITU-T SG13 informing
us 
> about the work they are doing on this topic and pointing us at
>
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
>
> If anyone has comments on this work they can send them to this mailing

> list (until another home is found in the IETF) or to the authors
direct.

I think that this is important work, and that the home for this work in
the IETF should be the CCAMP WG.

Yakov.




Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 19:53:08 +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: Layer One VPNs
Date: Mon, 29 Mar 2004 13:52:30 -0600
Message-ID: <[e-mail]>
Thread-Topic: Layer One VPNs
Thread-Index: AcQVqbaaSIebAQ2bR+yMU+K9u5DEygAHY5Kw
From: "Alanqar, Wesam I [NTK]" <[e-mail]>
To: "John Drake" <[e-mail]>, "Yakov Rekhter " <[e-mail]>, "Adrian Farrel " <[e-mail]>
Cc: <[e-mail]>

I support this work to be developed in CCAMP.

Thanks,
-Wesam Alanqar                        =20
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of John Drake
Sent: Monday, March 29, 2004 10:18 AM
To: 'Yakov Rekhter '; 'Adrian Farrel '
Cc: '[e-mail] '
Subject: RE: Layer One VPNs


 Agreed

-----Original Message-----
From: Yakov Rekhter
To: Adrian Farrel
Cc: [e-mail]
Sent: 3/29/2004 7:35 AM
Subject: Layer One VPNs

Adrian,

> Hi,
>
> Although Layer One VPNs do not currently have a home in any IETF
working
> group, we were the recipients of a liaison from ITU-T SG13 informing
us=20
> about the work they are doing on this topic and pointing us at
>
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
>
> If anyone has comments on this work they can send them to this mailing

> list (until another home is found in the IETF) or to the authors
direct.

I think that this is important work, and that the home for this work in
the IETF should be the CCAMP WG.

Yakov.




Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 19:19:06 +0000
Message-ID: <18db01c415c2$90277440$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: draft-berger-ccamp-gmpls-segment-recovery-00.txt
Date: Mon, 29 Mar 2004 20:17:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

OK authors, please resubmit this as a WG draft.

Thanks.

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, March 13, 2004 11:40 AM
Subject: draft-berger-ccamp-gmpls-segment-recovery-00.txt


> All,
>
> I have heard rough consensus on this draft becoming a working group draft, but in view
of
> a few people who have expressed concern, I would like to leave this open for a few more
> days.
>
> Please, if you have concrete issues with this draft, raise them on the list as soon as
> possible.
>
> Thanks,
> Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 16:18:28 +0000
Message-ID: <[e-mail]>
From: John Drake <[e-mail]>
To: 'Yakov Rekhter ' <[e-mail]>, 'Adrian Farrel ' <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: Layer One VPNs
Date: Mon, 29 Mar 2004 08:17:52 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

 Agreed

-----Original Message-----
From: Yakov Rekhter
To: Adrian Farrel
Cc: [e-mail]
Sent: 3/29/2004 7:35 AM
Subject: Layer One VPNs

Adrian,

> Hi,
>
> Although Layer One VPNs do not currently have a home in any IETF
working
> group, we were the recipients of a liaison from ITU-T SG13 informing
us 
> about the work they are doing on this topic and pointing us at
>
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
>
> If anyone has comments on this work they can send them to this mailing
> list (until another home is found in the IETF) or to the authors
direct.

I think that this is important work, and that the home for this
work in the IETF should be the CCAMP WG.

Yakov.



Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 15:37:12 +0000
Message-Id: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
cc: [e-mail]
Subject: Layer One VPNs
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 29 Mar 2004 07:35:10 -0800
From: Yakov Rekhter <[e-mail]>

Adrian,

> Hi,
>
> Although Layer One VPNs do not currently have a home in any IETF working
> group, we were the recipients of a liaison from ITU-T SG13 informing us 
> about the work they are doing on this topic and pointing us at
> http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
>
> If anyone has comments on this work they can send them to this mailing
> list (until another home is found in the IETF) or to the authors direct.

I think that this is important work, and that the home for this
work in the IETF should be the CCAMP WG.

Yakov.



Envelope-to: [e-mail]
Delivery-date: Mon, 29 Mar 2004 09:04:53 +0000
Message-ID: <002b01c4156d$2760cb50$524609d9@pma>
From: "Filippo Cugini" <[e-mail]>
To: <[e-mail]>
Subject: wavelength conversion  - gmpls-routing-09
Date: Mon, 29 Mar 2004 11:06:12 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dear all,
I have to manage transparent OXC with (internal or external) DWDM
As defined in draft-ietf-ccamp-gmpls-routing-09.txt, 
the interface switching capability descriptor is type LSC.
Link Bundling is applied.
If I understood correctly the node is assumed by the routing protocol 
with full wavelength conversion capability 
also if it has no lambda conversion at all
Is it true?

Thanks, 
Filippo Cugini
CNIT National Lab of Photonic Networks
via Cisanello 145, 56124 Pisa
ph. [phone]
fax [phone]





Envelope-to: [e-mail]
Delivery-date: Sun, 28 Mar 2004 19:45:07 +0000
Message-ID: <12ab01c414fd$02fca650$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: WG Last Call on draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
Date: Sun, 28 Mar 2004 20:42:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Editors,

Working Group last call has completed on this draft without further comments (that I saw).

I have a few nits that I would like you to fix and then we can pass the draft on to the
ADs.

Thanks,
Adrian
============

1. Table of Content
Please don't number the table of contents
(See below for why this is good news :-)

Section 2
   Conventions used in this document:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].

   Any other recovery-related terminology used in this document
   conforms to the one defined in [TERM]. The reader is also assumed to
   be familiar with the terminology developed in [GMPLS-ARCH], [RFC-
   3471], [RFC-3473], [GMPLS-RTG] and [LMP].
This material should be in its own section not lumped in with "Contributors"

Section 3.
   IETF CCAMP Working Group. Here, the focus will only be on transport
For "will only be" read "is only"

Section 3.
   In the present release, a detailed analysis is provided for each of
Strike "In the present release,"

Section 4.1
   the transport plane, the latter, upon failure condition, MUST
Read "upon a failure"

Section 4.1
     defect û excessive errors (EXC) or degraded signal (DEG) - is
Non-ASCII character

Section 4.2
   consuming failure isolation (see also Section 4.5). This is
There is no section 4.5

Section 5.4
   In both schemes, it results a "group" of sum{n=1}^N N{n} working
Read "results in a"

Section 5.4
   one working LSP to be denied automatic recovery. But if one consider
Read "considers"

Section 5.5.1
   LSPs/spans recovery time and ratio depend on the proper recovery LSP
   provisioning (meaning pre-provisioning when performed before failure
   occurrence) and the level of recovery resources overbooking (i.e.
   over-provisioning). A proper balance of these two operations will
Rephrase
   The recovery time and ratio of LSPs/spans depend on proper recovery LSP
   provisioning (meaning pre-provisioning when performed before failure
   occurrence) and the level of overbooking of recovery resources (i.e.
   over-provisioning). A proper balance of these two operations will

Section 5.5.1
   classified here below to structure the analysis of the different
Strike "here"

Section 5.5.1
   options can be classified (as shown in the below figure) as follows:
Read "in the figure below"

Section 5.5.1
   (3) when the recovery resources are pre-reserved, they can be either
       pre-selected or selected on-demand.
I think people may find it hard to understand how a resource can be pre-reserved when it
has not yet been selected.
Can you clarify this.
In fact, it might be helpful in this section to clarify the behavioral differences when
resources are overbookable (such as in PSC) and when resources are synonymous to labels.

6. Normalization
[TERM] uses the term "reversion" and only peripherally mentions "normalization"
And, indeed, you revert to the word "reversion" in section 6.2

Section 7
   desirable to avoid that similar layers with functional overlaps to
Strike "that"

Section 7.2
   - Potentially, recovery capabilities with different temporal
Read "Potential recovery"

Section 7.2
   Here below we briefly extend on (4), (2) being covered in [RFC
   3386]. On the other hand (1) is extensively covered at the MPLS
   Working Group, and (3) at the PWE3 Working Group.
Read
   Below we briefly expand on (4) only. (2) is covered in [RFC-
   3386]. (1) is extensively covered by the MPLS
   Working Group, and (3) by the PWE3 Working Group.

Section 7.2
   Note: Recovery Granularity
Read
7.2.1 Recovery Granularity

Section 7.4.1
   A Shared Risk Link Group (SRLG) is defined as the set of optical
   spans (or links or optical lines) sharing a common physical resource
   (for instance, fiber links, fiber trunks or cables) i.e. sharing a
   common risk.
Why do you limit this to optical spans in this way? Would it not be better to describe
this in terms of physical or logical networking resources?
But, in any case, shouldn't you really refer to the definition elsewhere? It is not in
[TERM] (perhaps it should be), but the definition in [CCAMP-SRLG] should be good enough.
You go on to describe a link belonging to an SRLG. Do you mean TE link?

Section 7.4.1
   (but not a sufficient) condition to ensure optical network
Again, not sure why you are limited to optical networks.

Section 8.4.1
   The knowledge of this information available per TE link can be
   exploited in order to optimize the usage of the resources allocated
   per TE link for shared recovery. If one refers to r[i] as the actual
   bandwidth per TE link i (in terms of discrete bandwidth units)
   committed for shared recovery, then the following quantity must be
   maximized over the potential TE link candidates: sum {i=1}^N [(R{i}
   - r{i})/(t{i} û b{i})] or equivalently: sum {i=1}^N [(R{i} -
   r{i})/r{i}] with R{i} >= 1 and r{i} >= 1 (in terms of per component
   bandwidth unit). In this formula, N is the total number of links
   traversed by a given LSP, t[i] the Maximum Link Bandwidth per TE
   link i and b[i] the sum per TE link i of the bandwidth committed for
   working LSPs and other recovery LSPs (thus except "shared bandwidth"
   LSPs). The quantity [(R{i} - r{i})/r{i}] is defined as the Shared
   (Recovery) Bandwidth Ratio per TE link i. In addition, TE links for
   which R[i] reaches max_R[i] or for which r[i] = 0 are pruned during
   shared recovery path computation as well as TE links for which
   max_R[i] = r[i] which can simply not be shared.
Could you check the formulae. Do you really mean square root b{i} ? Regardless, this is a
non-standard ASCII character.
Could you also break the text so each formula is presented whole on a separate line.

Section 9
It would be nice to give a one-line key for each of the three path setup mechanisms (1, 2
and 3) in the table.

10. Security Considerations
Do all of the protection and recovery mechanisms described have identical security
implications? If so, please add that statement.
If not (which I suspect) please add some text to compare and contrast the security of the
different techniques.

Please use new IPR boilerplate

References
Could you check that [IPO-IMP], [CCAMP-LI], [CCAMP-SRLG], [MPLS-OSU] and [TE-NS] have not
died?
The version numbers and dates of references are (of course) a little out of date.

14. Author's Addresses
Read "Editors' Addresses" ?

Please use new copyright boilerplate.

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 04, 2004 12:23 PM
Subject: Last call on Protection and Restoration Design Team drafts


> As discussed in the CCAMP meeting today, the Protection and Restoration Design Team
drafts
> have been around and stable for a long time.
>
> The terminology draft (draft-ietf-ccamp-gmpls-recovery-terminology-03.txt) is marked as
> standards track, but clearly does not require an implementation.
>
> The Functional Analysis draft (draft-ietf-ccamp-gmpls-recovery-functional-01.txt) is
> neither marked as informational nor standards track - perhaps the editors would like to
> fix this as a last call comment. Nevertheless, this is clearly not aimed at having an
> implementation.
>
> The Recovery Analysis draft (draft-ietf-ccamp-gmpls-recovery-analysis-02.txt) is
> informational and does not need an implementation.
>
>
> This email begins a working group last call on
> draft-ietf-ccamp-gmpls-recovery-terminology-03.txt,
> draft-ietf-ccamp-gmpls-recovery-functional-01.txt and
> draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>
> The last call will end on Friday 26th March at 12 noon GMT.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>
> Comments to the list or to the chairs direct.
> Thanks,
> Adrian
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Sun, 28 Mar 2004 17:13:57 +0000
Message-ID: <129d01c414e7$dc11ee20$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: WG Last Call Completed: draft-ietf-ccamp-gmpls-overlay-03.txt 
Date: Sun, 28 Mar 2004 15:33:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Oh, I should have said...

Please use the new IPR and copyright boilerplate.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Sunday, March 28, 2004 3:03 PM
Subject: WG Last Call Completed: draft-ietf-ccamp-gmpls-overlay-03.txt


> Authors,
>
> The WG last call for this draft has completed.
> No comments were made on the list, but a private comment was sent to the chairs as
below.
>
> I suggest you either:
> - make the change suggested by Kireeti *and* reference Lou's new egress control draft
> or
> - simply add a reference to Lou's new draft.
>
> When you have done this we can pass the draft to the ADs.
>
> Thanks,
> Adrian
>
> ======
>
> Hi Adrian and Kireeti,
>
> Would it be possible to include in the following the text for section 3.3 as proposed
> after the ietf58 meeting by Kireeti:
>
> <http://psg.com/lists/ccamp/ccamp.2003/msg01015.html>
>
> "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 <error code>."
>
> ==============
>
> > As discussed in the CCAMP meeting today,
> > draft-ietf-ccamp-gmpls-overlay-03.txt has been
> > updated with a few minor changes and is now ready for working group last
> > call.
> >
> > Several vendors have indicated that they support this function.
> >
> > This email begins a working group last call on
> > draft-ietf-ccamp-gmpls-overlay-03.txt
> > The last call will end on Friday 26th March at 12 noon GMT.
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt
> >
> > Comments to the list or to the chairs direct.
> > Thanks,
> > Adrian
>
>
>
>
>
> ----- Original Message ----- 
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, March 04, 2004 9:38 AM
> Subject: Last call on draft-ietf-ccamp-gmpls-overlay-03.txt
>
>
> > As discussed in the CCAMP meeting today, draft-ietf-ccamp-gmpls-overlay-03.txt has
been
> > updated with a few minor changes and is now ready for working group last call.
> >
> > Several vendors have indicated that they support this function.
> >
> > This email begins a working group last call on draft-ietf-ccamp-gmpls-overlay-03.txt
> > The last call will end on Friday 26th March at 12 noon GMT.
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt
> >
> > Comments to the list or to the chairs direct.
> > Thanks,
> > Adrian
> >
> >
> >
>




Envelope-to: [e-mail]
Delivery-date: Sun, 28 Mar 2004 17:13:50 +0000
Message-ID: <129e01c414e7$dd1a5d70$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: WG Last Call on draft-ietf-ccamp-gmpls-recovery-functional-01.txt
Date: Sun, 28 Mar 2004 17:48:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Editors,

Working group last call has completed on this draft without any further comments (that I
saw).

I have a few nits that I'd like you to fix and then we can pass the draft on to the ADs.

Thanks,
Adrian
============

Contributors
Please update contact details

Please add a list of Contents

Section 1 - non-ASCII characters
Unless otherwise stated, all references to ôlinkö in this draft

2. Span Protection
Please left justify heading

Section 2
   set of M protection links, usually cwith M <= N.
Read "with".

Section 2 - missing line break
   set of M protection links, usually cwith M <= N. A failure in any of    the N working
links results in traffic being switched to one of the

2.1 Unidirectional 1+1 dedicated protection
Please left justify heading

Section 2.1
        ôDedicated 1+1ö along with the bandwidth parameters for the
Non-ASCII characters

Section 2.1
        using the Link Management Protocol (LMP), or if LMP is not
Please add reference for LMP (and in other places in the draft).

Section 2.2
   Suppose an LSP is routed over link i between two nodes A and B.
Please state "a bi-directional LSP"

   2.3 Dedicated 1:1 protection with Extra Traffic
Please left justify heading

Section 2.3
   of the nodes, A or B. This node is referred to as the ômasterö. The    other node is
called the ôslaveö. The determination of the master    and the slave may be based on
configured information or protocol
Non-ASCII characters (two places)

Section 2.3 - missing line break
   of the nodes, A or B. This node is referred to as the ômasterö. The    other node is
called the ôslaveö. The determination of the master    and the slave may be based on
configured information or protocol

Section 2.3
            Traffic(i.e.,the traffic is dropped by the slave and not
Insert space "Traffic (i.e."

Section 2.3
Please add text to introduce the bullets beginning...
          o Pre-emption MUST be supported to accommodate Extra
             Traffic.

2.6 Messages
You say that these messages MUST be transmitted reliably.
You must, therefore, say what action is taken when such a
message fails to be delivered.

3.0 End-to-End (Path) Protection and Restoration
Read "3. End-to-End..."

Section 3.
   tend protection schemes and the functional steps needed to implement
Read "to-end"

Section 3.2
          o Switchover: The action when an end node detects a failure
See my comments on the terminology draft. This usage is consistent with what I would like
to see (namely "switchover"), but is inconsistent with the current terminology draft.

Section 3.2
                                  At the same time, send a switchover
             request message to the other end node to enable switching
             at the other end.
There is no subject of this sentence.
Ditto in the subsequent bullet.

3.1 Unidirectional 1+1 Protection
In the bi-directional case you point out that there are two distinct
failure detection cases. The case of detection by an intermediate
node gives rise to the requirement for signaling with an End-to-End
Failure Indication Message.
Why is this not a requirement in the unidirectional case?

Section 3.2.1
You don't say (but I know you have discovered in the solution draft)
that there is a correlation requirement between working and protection
LSP Identifiers. As you go on to place requirements on nodal information
in the next section, it would be worth clarifying the requirements on
LSP Identifiers.

Section 3.2.2
   Each node that is on the working or protection path of an LSP must
   have knowledge of the LSP identifier as well as the previous and
   next nodes in the LSP. This is so that restoration-related messages
   may be forwarded properly.
I don't see this requirement for end-to-end restoration.
It would appear only to be the case that *some* forwarding mechanism exists.

3.2.4  End-to-End Failure Acknowledge Message
   This message is sent by the source node in response to an End-to-End
   failure indication message. This message is sent to the originator
   of the failure indication message. The acknowledge message should be
   sent for each failure indication message received.  Each
   intermediate node receiving the acknowledge message must forward it
   towards the destination of the message.
It is not clear from this text what the purpose of this message is. If it is solely to
acknowledge the End-to-End Failure Indication Message, then you need to add a caveat that
this message need not be used when either
- some other means of reliable delivery of the Failure Message is used
or
- some other means of failure indication is used.

3.2.6  End-to-End Switchover Response Message
Please make it clear that this message may convey a positive or negative outcome.

Section 3.3
   signaling draft describes different type of switches [GMPLS_SIG]).
Read "[GMPLS-SIG]"

3.3.1  End-to-End Failure Indication and Acknowledgement
As per 3.2.3 and 3.2.4, you need to clarify that there is no requirement that these
messages flow along the path of the LSP.
As per my comment for 3.2.4, you need to clarify the purpose of the Acknowledgement
message.

Section 3.3
Nowhere in this section do you describe how the resources of the broken primary LSP may
become available for use by other LSPs (extra traffic or shared mesh protection) once the
traffic has been switched off the primary (but not necessarily before it has been switched
onto the protection LSP).

Section 4
   working path remains allocated to the LSP that was originally routed
   over it even after a failure. It is
   important to have mechanisms that allow reversion to be performed
   with minimal service disruption to the customer. This can be
   achieved using a ôbridge-and-switchö approach (often referred to as
make-before-break).

   The basic steps involved in bridge-and-switch are:

     1. The source node commences the process by ôbridgingö the signal         onto both
the working and the protection paths (or links in the
        case of span protection).
Line under-flow
Non-ASCII characters
Line over-flow
Line over-flow

Section 4
     5. Upon receipt of this message, the destination stops
        transmitting along the protection path and de-activates the LSP
        along this path. The de-activation procedure should remove the
        cross-LSPs along the protection path (and frees the resources
        to be used for restoring other failures.
For "cross-LSP" read "cross-connections"?

Section 4
   to force a switchover (from working to protect or vice versa), and
Read "protection"

Section 4
   working to protect administratively. These administrative conditions
Ditto

Security Considerations
It would be appropriate to write some material on the consequences to
security of protection schemes. For example, the consequences of badly
applied protection may increase the risk of misconnection. In particular
when extra traffic is involved, it is easily possible to deliver the
wrong traffic to the wrong place.
Similarly, an intrusion that sets up what appears to be a valid
protection LSP and then causes a fault may be able to divert traffic.
It is the place of this type of draft to guide the security behavior of
the solutions drafts that will follow.

6. Author's Addresses
Read "Authors' Addresses"
Update as required

7. Intellectual Property Considerations
Please use new boilerplate

Copyright
Please use the new boilerplate.






----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 04, 2004 12:23 PM
Subject: Last call on Protection and Restoration Design Team drafts


> As discussed in the CCAMP meeting today, the Protection and Restoration Design Team
drafts
> have been around and stable for a long time.
>
> The terminology draft (draft-ietf-ccamp-gmpls-recovery-terminology-03.txt) is marked as
> standards track, but clearly does not require an implementation.
>
> The Functional Analysis draft (draft-ietf-ccamp-gmpls-recovery-functional-01.txt) is
> neither marked as informational nor standards track - perhaps the editors would like to
> fix this as a last call comment. Nevertheless, this is clearly not aimed at having an
> implementation.
>
> The Recovery Analysis draft (draft-ietf-ccamp-gmpls-recovery-analysis-02.txt) is
> informational and does not need an implementation.
>
>
> This email begins a working group last call on
> draft-ietf-ccamp-gmpls-recovery-terminology-03.txt,
> draft-ietf-ccamp-gmpls-recovery-functional-01.txt and
> draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>
> The last call will end on Friday 26th March at 12 noon GMT.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>
> Comments to the list or to the chairs direct.
> Thanks,
> Adrian
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Sun, 28 Mar 2004 14:05:26 +0000
Message-ID: <128801c414cd$986d7d20$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: WG Last Call Completed: draft-ietf-ccamp-gmpls-overlay-03.txt 
Date: Sun, 28 Mar 2004 15:03:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Authors,

The WG last call for this draft has completed.
No comments were made on the list, but a private comment was sent to the chairs as below.

I suggest you either:
- make the change suggested by Kireeti *and* reference Lou's new egress control draft
or
- simply add a reference to Lou's new draft.

When you have done this we can pass the draft to the ADs.

Thanks,
Adrian

======

Hi Adrian and Kireeti,

Would it be possible to include in the following the text for section 3.3 as proposed
after the ietf58 meeting by Kireeti:

<http://psg.com/lists/ccamp/ccamp.2003/msg01015.html>

"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 <error code>."

==============

> As discussed in the CCAMP meeting today,
> draft-ietf-ccamp-gmpls-overlay-03.txt has been
> updated with a few minor changes and is now ready for working group last
> call.
>
> Several vendors have indicated that they support this function.
>
> This email begins a working group last call on
> draft-ietf-ccamp-gmpls-overlay-03.txt
> The last call will end on Friday 26th March at 12 noon GMT.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt
>
> Comments to the list or to the chairs direct.
> Thanks,
> Adrian





----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 04, 2004 9:38 AM
Subject: Last call on draft-ietf-ccamp-gmpls-overlay-03.txt


> As discussed in the CCAMP meeting today, draft-ietf-ccamp-gmpls-overlay-03.txt has been
> updated with a few minor changes and is now ready for working group last call.
>
> Several vendors have indicated that they support this function.
>
> This email begins a working group last call on draft-ietf-ccamp-gmpls-overlay-03.txt
> The last call will end on Friday 26th March at 12 noon GMT.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt
>
> Comments to the list or to the chairs direct.
> Thanks,
> Adrian
>
>
>




Envelope-to: [e-mail]
Delivery-date: Sun, 28 Mar 2004 14:05:18 +0000
Message-ID: <128501c414cd$57f1c490$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: WG Last Call Complete: draft-ietf-ccamp-gmpls-g709-06.txt
Date: Sun, 28 Mar 2004 14:47:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Authors,

WG last call has completed on this draft.
There were a few minor comments. Please incorporate these and issue a new version for me
to pass to the ADs.

Thanks,
Adrian


----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 04, 2004 9:39 AM
Subject: Last call on draft-ietf-ccamp-gmpls-g709-06.txt


> As discussed in the CCAMP meeting today, draft-ietf-ccamp-gmpls-g709-06.txt has been
> stable for a long time. We now have several vendors with implementations or plans to
> implement, and several providers asking for the function.
>
> This email begins a working group last call on draft-ietf-ccamp-gmpls-g709-06.txt
> The last call will end on Friday 26th March at 12 noon GMT.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-06.txt
>
> Comments to the list or to the chairs direct.
> Thanks,
> Adrian




Envelope-to: [e-mail]
Delivery-date: Sun, 28 Mar 2004 14:05:10 +0000
Message-ID: <128601c414cd$58a18c90$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: WG Last Call Completed draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
Date: Sun, 28 Mar 2004 14:50:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Editors,

WG last call has completed on this draft.

A few comments were received. Please address these in a new version and submit it so that
I can pass the draft on to the ADs.

Thanks,
Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 04, 2004 12:23 PM
Subject: Last call on Protection and Restoration Design Team drafts


> As discussed in the CCAMP meeting today, the Protection and Restoration Design Team
drafts
> have been around and stable for a long time.
>
> The terminology draft (draft-ietf-ccamp-gmpls-recovery-terminology-03.txt) is marked as
> standards track, but clearly does not require an implementation.
>
> The Functional Analysis draft (draft-ietf-ccamp-gmpls-recovery-functional-01.txt) is
> neither marked as informational nor standards track - perhaps the editors would like to
> fix this as a last call comment. Nevertheless, this is clearly not aimed at having an
> implementation.
>
> The Recovery Analysis draft (draft-ietf-ccamp-gmpls-recovery-analysis-02.txt) is
> informational and does not need an implementation.
>
>
> This email begins a working group last call on
> draft-ietf-ccamp-gmpls-recovery-terminology-03.txt,
> draft-ietf-ccamp-gmpls-recovery-functional-01.txt and
> draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>
> The last call will end on Friday 26th March at 12 noon GMT.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>
> Comments to the list or to the chairs direct.
> Thanks,
> Adrian
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Sat, 27 Mar 2004 12:30:45 +0000
Message-ID: <[e-mail]>
Date: Sat, 27 Mar 2004 13:30:52 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: "Ong, Lyndon" <[e-mail]>
Cc: "'Lou Berger'" <[e-mail]>, Kireeti Kompella <[e-mail]>, [e-mail]
Subject: Re: Label type to be used
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

the proposal that makes a fully transparent Sonet/SDH encoded capable 
link appearing as [X,LSC] or [LSC,X], or [LSC,LSC] w/ a label defined as 
a port and/or lambda is aligned with the evolution of the definition 
towards OTN (coming from the so-called pre-OTN) technology and thus 
probably better than trying to retain the TDM value for it (with several 
flavours)

so you would have something like this when trying to harmonize in 
between the several documents we have tnat deals with this specific 
representation issue, i also think it provides the distinction you're 
asking for b/w fiber and so-called clear channels:

2.4.4. Lambda-Switch Capable

   If an interface is of type LSC, it means that the node receiving data
   over this interface can recognize and switch individual lambdas
   within the interface.  An interface that allows only one lambda per
   interface, and switches just that lambda is of type LSC.
 > This includes interfaces that only support fully transparent SONET/SDH
 > signals, as defined in [GMPLS-SONET-SDH].

[...]

2.4.7. Interface Switching Capabilities and Labels

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
 >    [TDM, TDM] - label represents a timeslot ([GMPLS-SONET-SDH],
                      [GMPLS-G709])
 >    [LSC, LSC] - label represents a G.709 OCh/lambda/port
 >    [FSC, FSC] - label represents a fiber (i.e. physical port)
 >    [PSC, TDM] - label represents a timeslot ([GMPLS-SONET-SDH],
                      [GMPLS-G709])
 >    [PSC, LSC] - label represents a G.709 OCh/lambda/port
 >    [PSC, FSC] - label represents a fiber
 >    [TDM, LSC] - label represents a G.709 OCh/lambda/port
 >    [TDM, FSC] - label represents a fiber
 >    [LSC, FSC] - label represents a fiber

 > Note: except when explicitly indicated the label encoding MUST follow 
 > the rules defined in [RFC3471] Section 3.2.

ps: in fact one sees here that for the "timeslot" case, the switching 
type TDM value equates the encoding one


Ong, Lyndon wrote:
> Hi Lou,
> 
> Your proposed text looks pretty good to me.
>  
> Side note: is there a way that the
> existing text can be clarified to distinguish
> between the case of only one lambda allowed
> on an interface and the case of fiber switching?  
> 
> Currently the text seems to allow an overlap
> in the case of a non-channelized OC-12/48/etc. as in
> a sense there is only one "lambda" but you would
> typically request fiber switching.
> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Friday, March 26, 2004 11:17 AM
> To: Kireeti Kompella
> Cc: [e-mail]; John Drake
> Subject: RE: Label type to be used
> 
> 
> Kireeti,
>          I think John's points on (a) and (c) are reasonable.  I think the 
> only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make 
> this clear are:
> 
>     2.4.4. Lambda-Switch Capable
> 
>     If an interface is of type LSC, it means that the node receiving data
>     over this interface can recognize and switch individual lambdas
>     within the interface.  An interface that allows only one lambda per
>     interface, and switches just that lambda is of type LSC.
>  >  This includes interfaces that only support fully transparent SONET/SDH
>  >   signals, as defined in [GMPLS-SONET-SDH].
> 
> and
>         [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>         [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>  >      [LSC, LSC] - label represents a lambda/port
>         [FSC, FSC] - label represents a port on an OXC
>         [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>  >      [PSC, LSC] - label represents a lambda/port
>         [PSC, FSC] - label represents a port
>  >      [TDM, LSC] - label represents a lambda/port
>         [TDM, FSC] - label represents a port
>         [LSC, FSC] - label represents a port
> 
> Lou
> 
> PS This matches all but one implementation we've interoperated with.
> 
> At 01:49 PM 3/26/2004 -0500, John Drake wrote:
> 
> 
> 
>>>-----Original Message-----
>>>From: Kireeti Kompella 
>>
>>[<mailto:[e-mail]>mailto:[e-mail]]
>>
>>>Sent: Thursday, March 18, 2004 9:58 AM
>>>To: [e-mail]
>>>Subject: Label type to be used
>>>
>>>Hi,
>>>
>>>Arthi and Lou pointed out the following typos in the GMPLS routing doc
>>>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
>>>Editor's queue:
>>>
>>>In section 2.4.7 is the following table defining the type of label
>>>for various combinations of switching types:
>>>
>>>      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>>>      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>      [LSC, LSC] - label represents a lambda
>>>      [FSC, FSC] - label represents a port on an OXC
>>>      [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>      [PSC, LSC] - label represents a lambda
>>>      [PSC, FSC] - label represents a port
>>>      [TDM, LSC] - label represents a lambda
>>>      [TDM, FSC] - label represents a port
>>>      [LSC, FSC] - label represents a port
>>>
>>>The one at issue is [PSC, LSC]; above it says that the label
>>>represents a lambda; and in the case of [PSC, TDM] with a fully
>>>transparent signal, the above indicates the label represents a TDM
>>>time slot.  The proposal is to change this to:
>>>
>>>      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>>>      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>      [LSC, LSC] - label represents a lambda
>>>      [FSC, FSC] - label represents a port on an OXC
>>>      [PSC, TDM] - fully transparent signal: label represents a port
>>>                   ("transparency" is defined in [GMPLS-SONET-SDH])
>>>      [PSC, TDM] - non-transparent signal: label represents a TDM time
>>>                   slot [GMPLS-SONET-SDH]
>>>      [PSC, LSC] - label represents a port
>>>      [PSC, FSC] - label represents a port
>>>      [TDM, LSC] - label represents a lambda
>>>      [TDM, FSC] - label represents a port
>>>      [LSC, FSC] - label represents a port
>>>
>>>Please respond by Friday 3/26, 5pm PST with comments on:
>>>
>>>a) do you agree with the above change?
>>
>>[John Drake]
>>
>>I don't have a problem with the [PSC, LSC] change but I don't
>>understand the distinction between transparent and non-transparent
>>TDM as it pertains to GMPLS routing.  As I indicated in a previous
>>e-mail, I think the transparent TDM case should be handled with a
>>switching type of LSC and an encoding type of SDH/SONET, and I think
>>that this should be specified in the SDH/SONET I-D, where the distinction
>>between transparent and non-transparent TDM is defined, rather than in
>>this document.
>>
>>
>>>b) in your implementation today, what do expect the label to represent
>>>   i) in the case of [PSC, LSC]?
>>
>>[John Drake]
>>
>>Port/lambda
>>
>>
>>>   ii) in the case of [PSC, TDM] with a fully transparent signal?
>>>c) if you implement as the draft says, would it be a hardship to change
>>>   this?
>>
>>[John Drake]
>>
>>N/A.  Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty
>>clear about which types of labels are in the transparent and non-transparent
>>TDM cases.
>>
>>
>>>If we can get closure on this, I'll take up the task of modifying the
>>>pending RFC with the ADs.
>>>
>>>Kireeti.
>>>-------
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Fri, 26 Mar 2004 23:59:10 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Lou Berger' <[e-mail]>, Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Subject: RE: Label type to be used
Date: Fri, 26 Mar 2004 15:57:55 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Lou,

Your proposed text looks pretty good to me.
 
Side note: is there a way that the
existing text can be clarified to distinguish
between the case of only one lambda allowed
on an interface and the case of fiber switching?  

Currently the text seems to allow an overlap
in the case of a non-channelized OC-12/48/etc. as in
a sense there is only one "lambda" but you would
typically request fiber switching.

Cheers,

Lyndon

-----Original Message-----
From: Lou Berger [mailto:[e-mail]]
Sent: Friday, March 26, 2004 11:17 AM
To: Kireeti Kompella
Cc: [e-mail]; John Drake
Subject: RE: Label type to be used


Kireeti,
         I think John's points on (a) and (c) are reasonable.  I think the 
only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make 
this clear are:

    2.4.4. Lambda-Switch Capable

    If an interface is of type LSC, it means that the node receiving data
    over this interface can recognize and switch individual lambdas
    within the interface.  An interface that allows only one lambda per
    interface, and switches just that lambda is of type LSC.
 >  This includes interfaces that only support fully transparent SONET/SDH
 >   signals, as defined in [GMPLS-SONET-SDH].

and
        [PSC, PSC] - label is carried in the "shim" header [RFC3032]
        [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
 >      [LSC, LSC] - label represents a lambda/port
        [FSC, FSC] - label represents a port on an OXC
        [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
 >      [PSC, LSC] - label represents a lambda/port
        [PSC, FSC] - label represents a port
 >      [TDM, LSC] - label represents a lambda/port
        [TDM, FSC] - label represents a port
        [LSC, FSC] - label represents a port

Lou

PS This matches all but one implementation we've interoperated with.

At 01:49 PM 3/26/2004 -0500, John Drake wrote:


> > -----Original Message-----
> > From: Kireeti Kompella 
> [<mailto:[e-mail]>mailto:[e-mail]]
> > Sent: Thursday, March 18, 2004 9:58 AM
> > To: [e-mail]
> > Subject: Label type to be used
> >
> > Hi,
> >
> > Arthi and Lou pointed out the following typos in the GMPLS routing doc
> > (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
> > Editor's queue:
> >
> > In section 2.4.7 is the following table defining the type of label
> > for various combinations of switching types:
> >
> >       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >       [LSC, LSC] - label represents a lambda
> >       [FSC, FSC] - label represents a port on an OXC
> >       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >       [PSC, LSC] - label represents a lambda
> >       [PSC, FSC] - label represents a port
> >       [TDM, LSC] - label represents a lambda
> >       [TDM, FSC] - label represents a port
> >       [LSC, FSC] - label represents a port
> >
> > The one at issue is [PSC, LSC]; above it says that the label
> > represents a lambda; and in the case of [PSC, TDM] with a fully
> > transparent signal, the above indicates the label represents a TDM
> > time slot.  The proposal is to change this to:
> >
> >       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >       [LSC, LSC] - label represents a lambda
> >       [FSC, FSC] - label represents a port on an OXC
> >       [PSC, TDM] - fully transparent signal: label represents a port
> >                    ("transparency" is defined in [GMPLS-SONET-SDH])
> >       [PSC, TDM] - non-transparent signal: label represents a TDM time
> >                    slot [GMPLS-SONET-SDH]
> >       [PSC, LSC] - label represents a port
> >       [PSC, FSC] - label represents a port
> >       [TDM, LSC] - label represents a lambda
> >       [TDM, FSC] - label represents a port
> >       [LSC, FSC] - label represents a port
> >
> > Please respond by Friday 3/26, 5pm PST with comments on:
> >
> > a) do you agree with the above change?
>[John Drake]
>
>I don't have a problem with the [PSC, LSC] change but I don't
>understand the distinction between transparent and non-transparent
>TDM as it pertains to GMPLS routing.  As I indicated in a previous
>e-mail, I think the transparent TDM case should be handled with a
>switching type of LSC and an encoding type of SDH/SONET, and I think
>that this should be specified in the SDH/SONET I-D, where the distinction
>between transparent and non-transparent TDM is defined, rather than in
>this document.
>
> > b) in your implementation today, what do expect the label to represent
> >    i) in the case of [PSC, LSC]?
>[John Drake]
>
>Port/lambda
>
> >    ii) in the case of [PSC, TDM] with a fully transparent signal?
> > c) if you implement as the draft says, would it be a hardship to change
> >    this?
>[John Drake]
>
>N/A.  Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty
>clear about which types of labels are in the transparent and non-transparent
>TDM cases.
>
> >
> > If we can get closure on this, I'll take up the task of modifying the
> > pending RFC with the ADs.
> >
> > Kireeti.
> > -------




Envelope-to: [e-mail]
Delivery-date: Fri, 26 Mar 2004 19:18:05 +0000
Message-Id: <6.0.3.0.2.20040326135558.035aad58@mo-ex1>
Date: Fri, 26 Mar 2004 14:17:27 -0500
To: "Kireeti Kompella" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: RE: Label type to be used
Cc: <[e-mail]>, "John Drake" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Kireeti,
         I think John's points on (a) and (c) are reasonable.  I think the 
only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make 
this clear are:

    2.4.4. Lambda-Switch Capable

    If an interface is of type LSC, it means that the node receiving data
    over this interface can recognize and switch individual lambdas
    within the interface.  An interface that allows only one lambda per
    interface, and switches just that lambda is of type LSC.
 >  This includes interfaces that only support fully transparent SONET/SDH
 >   signals, as defined in [GMPLS-SONET-SDH].

and
        [PSC, PSC] - label is carried in the "shim" header [RFC3032]
        [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
 >      [LSC, LSC] - label represents a lambda/port
        [FSC, FSC] - label represents a port on an OXC
        [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
 >      [PSC, LSC] - label represents a lambda/port
        [PSC, FSC] - label represents a port
 >      [TDM, LSC] - label represents a lambda/port
        [TDM, FSC] - label represents a port
        [LSC, FSC] - label represents a port

Lou

PS This matches all but one implementation we've interoperated with.

At 01:49 PM 3/26/2004 -0500, John Drake wrote:


> > -----Original Message-----
> > From: Kireeti Kompella 
> [<mailto:[e-mail]>mailto:[e-mail]]
> > Sent: Thursday, March 18, 2004 9:58 AM
> > To: [e-mail]
> > Subject: Label type to be used
> >
> > Hi,
> >
> > Arthi and Lou pointed out the following typos in the GMPLS routing doc
> > (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
> > Editor's queue:
> >
> > In section 2.4.7 is the following table defining the type of label
> > for various combinations of switching types:
> >
> >       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >       [LSC, LSC] - label represents a lambda
> >       [FSC, FSC] - label represents a port on an OXC
> >       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >       [PSC, LSC] - label represents a lambda
> >       [PSC, FSC] - label represents a port
> >       [TDM, LSC] - label represents a lambda
> >       [TDM, FSC] - label represents a port
> >       [LSC, FSC] - label represents a port
> >
> > The one at issue is [PSC, LSC]; above it says that the label
> > represents a lambda; and in the case of [PSC, TDM] with a fully
> > transparent signal, the above indicates the label represents a TDM
> > time slot.  The proposal is to change this to:
> >
> >       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >       [LSC, LSC] - label represents a lambda
> >       [FSC, FSC] - label represents a port on an OXC
> >       [PSC, TDM] - fully transparent signal: label represents a port
> >                    ("transparency" is defined in [GMPLS-SONET-SDH])
> >       [PSC, TDM] - non-transparent signal: label represents a TDM time
> >                    slot [GMPLS-SONET-SDH]
> >       [PSC, LSC] - label represents a port
> >       [PSC, FSC] - label represents a port
> >       [TDM, LSC] - label represents a lambda
> >       [TDM, FSC] - label represents a port
> >       [LSC, FSC] - label represents a port
> >
> > Please respond by Friday 3/26, 5pm PST with comments on:
> >
> > a) do you agree with the above change?
>[John Drake]
>
>I don't have a problem with the [PSC, LSC] change but I don't
>understand the distinction between transparent and non-transparent
>TDM as it pertains to GMPLS routing.  As I indicated in a previous
>e-mail, I think the transparent TDM case should be handled with a
>switching type of LSC and an encoding type of SDH/SONET, and I think
>that this should be specified in the SDH/SONET I-D, where the distinction
>between transparent and non-transparent TDM is defined, rather than in
>this document.
>
> > b) in your implementation today, what do expect the label to represent
> >    i) in the case of [PSC, LSC]?
>[John Drake]
>
>Port/lambda
>
> >    ii) in the case of [PSC, TDM] with a fully transparent signal?
> > c) if you implement as the draft says, would it be a hardship to change
> >    this?
>[John Drake]
>
>N/A.  Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty
>clear about which types of labels are in the transparent and non-transparent
>TDM cases.
>
> >
> > If we can get closure on this, I'll take up the task of modifying the
> > pending RFC with the ADs.
> >
> > Kireeti.
> > -------




Envelope-to: [e-mail]
Delivery-date: Fri, 26 Mar 2004 18:50:29 +0000
Message-ID: <[e-mail]>
From: John Drake <[e-mail]>
To: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: RE: Label type to be used
Date: Fri, 26 Mar 2004 10:49:31 -0800
MIME-Version: 1.0
Content-Type: text/plain

> -----Original Message-----
> From: Kireeti Kompella [mailto:[e-mail]]
> Sent: Thursday, March 18, 2004 9:58 AM
> To: [e-mail]
> Subject: Label type to be used
> 
> Hi,
> 
> Arthi and Lou pointed out the following typos in the GMPLS routing doc
> (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
> Editor's queue:
> 
> In section 2.4.7 is the following table defining the type of label
> for various combinations of switching types:
> 
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a lambda
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
> 
> The one at issue is [PSC, LSC]; above it says that the label
> represents a lambda; and in the case of [PSC, TDM] with a fully
> transparent signal, the above indicates the label represents a TDM
> time slot.  The proposal is to change this to:
> 
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - fully transparent signal: label represents a port
>                    ("transparency" is defined in [GMPLS-SONET-SDH])
>       [PSC, TDM] - non-transparent signal: label represents a TDM time
>                    slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a port
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
> 
> Please respond by Friday 3/26, 5pm PST with comments on:
> 
> a) do you agree with the above change?
[John Drake] 

I don't have a problem with the [PSC, LSC] change but I don't
understand the distinction between transparent and non-transparent
TDM as it pertains to GMPLS routing.  As I indicated in a previous
e-mail, I think the transparent TDM case should be handled with a
switching type of LSC and an encoding type of SDH/SONET, and I think
that this should be specified in the SDH/SONET I-D, where the distinction
between transparent and non-transparent TDM is defined, rather than in
this document.


> b) in your implementation today, what do expect the label to represent
>    i) in the case of [PSC, LSC]?
[John Drake]

Port/lambda

>    ii) in the case of [PSC, TDM] with a fully transparent signal?
> c) if you implement as the draft says, would it be a hardship to change
>    this?
[John Drake] 

N/A.  Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty
clear about which types of labels are in the transparent and non-transparent
TDM cases.
  
> 
> If we can get closure on this, I'll take up the task of modifying the
> pending RFC with the ADs.
> 
> Kireeti.
> -------



Envelope-to: [e-mail]
Delivery-date: Fri, 26 Mar 2004 16:06:27 +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: [RE] Layer One VPNs - sorry for the previous email
Date: Fri, 26 Mar 2004 10:03:13 -0600
Message-ID: <[e-mail]>
Thread-Topic: [RE] Layer One VPNs - sorry for the previous email
Thread-Index: AcQMXWuOrr7p2ER1RPqdvvflBQHH2AG6a8ng
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>, "Tomonori TAKEDA" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Hi Tomonori, Adrian,

I noted the SG13 liaison has a response date of September 2004 (the =
l1vpn questionnaire responses are due June).  Will we wait until the =
August IETF meeting to respond? (hopefully there will have been a =
decision on the l1vpn work allocation)

I support Dimitri's comments below, it would be useful for the next =
version of the draft to compare ITU terminology and [TERM], and also =
provide an initial proposal of comparison/delta requirements to aid in =
ccamp's understanding of the work and for responding to SG13 e.g. =
comparison to ccamp's gmpls-overlay draft which includes GMPLS VPN =
support (L1 included) and the GVPN services draft which includes VPN =
service models and GMPLS toolkit to support.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of [e-mail]
Sent: Wednesday, March 17, 2004 3:11 PM
To: Tomonori TAKEDA
Cc: [e-mail]; [e-mail]
Subject: Re: [RE] Layer One VPNs - sorry for the previous email


hi tomonori,

Tomonori TAKEDA wrote:

> Hi, Dimitri
>=20
> Thank you for your comments. Please see my comments in line.
>=20
> At 18:39 04/03/15 +0100, [e-mail] wrote:
>=20
>> hi tomonori, young, all,
>>
>> the proposed framework document (part of this discussion)
>> deliversa good starting point in terms of functionality
>>
>> some more specific comment on this document:
>>
>> - it mentions an issue concerning the "shared control link" it
>> may be advisable to detail more accurately the expectation in
>> terms of functionality and then assess whether a shared control
>> link can be used in this context, the addition to which you're
>> referring seems to imply a mux/de-mux mechanism - it would be
>> of great interest to see how this compares with Section 4 of
>> the GVPN id
>=20
>=20
> Okay, let me try to answer your comments.
>=20
> For control link between the CE and the PE, I would say there are =
three=20
> categories.
>=20
> 1) Physically disjoint control link
> 2) IP-level disjoint control link (e.g., GRE tunnel)
> 3) IP-level shared control link
>=20
> Shared control link generally refers to category 3).
>=20
>  From here, I am describing more than what is described in the ID.
>=20
> Category 3) is typically the case that the same CE device belongs to=20
> multiple VPNs (or the CE device contains multiple VPN instances), as=20
> described in section 6.1 of the ID. In this case, to distinguish=20
> messages exchanged over the control channel, some mechanisms are =
needed,=20
> and addition of VPN ID seems one way to do.
>=20
> In GVPN ID, my understanding is that logical CE-PE links (or=20
> association) belong to each VPN. L1VPN framework ID is in line with =
this=20
> (as described in section 6.1), but this ID goes beyond and tackles the =

> case for shared control channel.

this was over time also my understanding of your intention and we may=20
point this as something to be further discussed from a solution=20
perspective in case of acceptance of this work item w/i ietf scope

>> - section 4.1, performance is included as service do you mean
>> this as a classification of the quality of the delivered service
>> or do you mean that it is a service to allow customer to monitor
>> performance of the delivered service ?
>=20
>=20
> I mean the former.
>=20
> To make sure, I mean that performance is one of the items that specify =

> the service. (or the service defines the level of performance.)

ok, this clarifies

>> - there is the issue of the "PE-PE virtual links" and in case of
>> "Per VPN Peer model" more details should be provided in order to
>> assess whether existing GMPLS mechanisms are sufficient (from
>> that perspective details about the following sentence might be
>> of interest because it seems you took this as initial working
>> assumption "there is currently no leakage of routing information
>> across the PE to CE boundary.")
>=20
>=20
> Agree. Providing more details about service requirements may be =
helpful=20
> ? Functional requirements are also important, but before going that in =

> details, more clear service level requirements may be useful.

do you plan to deliver those as part of the user community or do you=20
expect this input to come from SG13 - or both - ? just to know about the =

timeframe we may expect here since there are very interesting issues=20
you're introducing with the above approaches

> Concerning the initial working assumption you mentioned, we started =
from=20
> the most acknowledged model for the service interface, that is the =
UNI.=20
> That is why we put above text.

so you started with a signaling interface, and then try to build on top=20
of it the necessary pieces

>> - i would suggest to conclude the document with the expected
>> delta requirement from gmpls perspective (this would help in
>> assessing what's expected in terms of protocol for the next
>> step(s))
>=20
>=20
> Okay, if CCAMP is going to work on the L1 VPN, I agree delta =
requirement=20
> would be an important step.
>=20
> Do you have anything in your mind ?

try to collect all the sentences that are part of the present document=20
that either implicitly or explicitly determine a feature to be covered
list them in terms of signaling and routing, i think we would gain a lot =

of precious time in having such conclusion in case decision to work on=20
solution is accepted

>> - an edit concerning the section on terminology it would be
>> of great help for this community to point the differences (if
>> any) from the existing [TERM] document
>=20
>=20
> Thanks. I would take that into the next version.

thanks,
- dimitri.

> Best regards,
>=20
>> thanks,
>> - dimitri.
>=20
>=20
> -----
> Tomonori TAKEDA
> NTT Network Service Systems Lab.
> Phone: [phone]
>=20

--=20
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]





Envelope-to: [e-mail]
Delivery-date: Tue, 23 Mar 2004 20:35:42 +0000
Date: Tue, 23 Mar 2004 15:34:39 -0500
From: Ashok Narayanan <[e-mail]>
To: Ben Mack-Crane <[e-mail]>
Cc: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: Re: Label type to be used
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

On Tue, Mar 23, 2004 at 02:20:55PM -0600, Ben Mack-Crane wrote:
> Hi Kireeti,
> 
> See in-line.
> 
> Regards,
> Ben
> 
> Kireeti Kompella wrote:
> 
> >Hi Ben,
> >
> >On Tue, 23 Mar 2004, Ben Mack-Crane wrote:
> >
> > 
> >
> >>The original text seems to have a sensible pattern.
> >>The proposed changed text does not.
> >>   
> >>
> >
> >Your responses below don't bear out your comment above: your
> >implementation uses port labels for [PSC, TDM/transparent], but the
> >original text says to use SUKLM.
> >
> >The sensibility of the pattern is also questionable; an equally
> >sensible pattern is to use port labels for [x, TDM/transparent].
> >
> If an interface supports transparent switching, it would fit the
> type [x, FSC], and thus use a port label for transparent LSP requests.
> So both [x, TDM] and [x, FSC] would fit the advertisement provided by
> a TDM port that supports both TDM channelized switching and transparent
> switching.  One would use SUKLM label in the first case and a port label
> in the second (as indicated in the GMPLS-SONET-SDH draft, and in the
> current text in the routing draft).

My understanding of how transparent switching works on a TDM switch is
not where it really should be to jump into this discussion, but what
the heck....

If you request a fully transparent TDM signal, that still implies that
it is a TDM signal, right? Could you connect a GigE port to a TDM
switch and request a OC-48 worth of fully transparent signal to
another GigE port on the other side? I believe the answer is no; and
in that case the switch can't truly advertise this link as FSC.

-Ashok

> 
> At least this is the way I understand the current docs.
> 
> >
> > 
> >
> >>In reviewing the discussion so far, it seems to me the best solution
> >>is to leave the text as is, understanding that switches capable of
> >>handling both TDM channelized switching as well as fully transparent
> >>(port or lambda) switching advertise multiple switching types.
> >>   
> >>
> >
> >I'm not sure how you reached the conclusion that the best solution is
> >to leave the text as is.  So far, there's been uniform agreement to
> >change the text, with Ashok counted as an abstention ("I won't really
> >object").
> >
> >The main point, though, is to come to a meaningful position that also
> >jives with current implementations -- ultimately, standards are to
> >enable interoperable implementations.
> >
> I thought my interpretation did match current implementations (as far
> as I can tell from the discussion to date).
> 
> 
> >
> ><snipped>
> >
> > 
> >
> >>>Please respond by Friday 3/26, 5pm PST with comments on:
> >>>
> >>>a) do you agree with the above change?
> >>>
> >>>     
> >>>
> >>No.
> >>
> >>   
> >>
> >>>b) in your implementation today, what do expect the label to represent
> >>> i) in the case of [PSC, LSC]?
> >>>
> >>>     
> >>>
> >>Lambda.
> >>
> >>   
> >>
> >>> ii) in the case of [PSC, TDM] with a fully transparent signal?
> >>>
> >>>     
> >>>
> >>Port.
> >>
> >>   
> >>
> >>>c) if you implement as the draft says, would it be a hardship to change
> >>> this?
> >>>
> >>>     
> >>>
> >>Yes.
> >>   
> >>
> >
> >Noted.
> >
> >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
> ============================================================
> 

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)




Envelope-to: [e-mail]
Delivery-date: Tue, 23 Mar 2004 20:26:26 +0000
Message-ID: <[e-mail]>
Date: Tue, 23 Mar 2004 14:20:55 -0600
From: Ben Mack-Crane <[e-mail]>
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 <[e-mail]>
CC: [e-mail]
Subject: Re: Label type to be used
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; format="flowed"

Hi Kireeti,

See in-line.

Regards,
Ben

Kireeti Kompella wrote:

>Hi Ben,
>
>On Tue, 23 Mar 2004, Ben Mack-Crane wrote:
>
>  
>
>>The original text seems to have a sensible pattern.
>>The proposed changed text does not.
>>    
>>
>
>Your responses below don't bear out your comment above: your
>implementation uses port labels for [PSC, TDM/transparent], but the
>original text says to use SUKLM.
>
>The sensibility of the pattern is also questionable; an equally
>sensible pattern is to use port labels for [x, TDM/transparent].
>
If an interface supports transparent switching, it would fit the
type [x, FSC], and thus use a port label for transparent LSP requests.
So both [x, TDM] and [x, FSC] would fit the advertisement provided by
a TDM port that supports both TDM channelized switching and transparent
switching.  One would use SUKLM label in the first case and a port label
in the second (as indicated in the GMPLS-SONET-SDH draft, and in the
current text in the routing draft).

At least this is the way I understand the current docs.

>
>  
>
>>In reviewing the discussion so far, it seems to me the best solution
>>is to leave the text as is, understanding that switches capable of
>>handling both TDM channelized switching as well as fully transparent
>>(port or lambda) switching advertise multiple switching types.
>>    
>>
>
>I'm not sure how you reached the conclusion that the best solution is
>to leave the text as is.  So far, there's been uniform agreement to
>change the text, with Ashok counted as an abstention ("I won't really
>object").
>
>The main point, though, is to come to a meaningful position that also
>jives with current implementations -- ultimately, standards are to
>enable interoperable implementations.
>
I thought my interpretation did match current implementations (as far
as I can tell from the discussion to date).


>
><snipped>
>
>  
>
>>>Please respond by Friday 3/26, 5pm PST with comments on:
>>>
>>>a) do you agree with the above change?
>>>
>>>      
>>>
>>No.
>>
>>    
>>
>>>b) in your implementation today, what do expect the label to represent
>>>  i) in the case of [PSC, LSC]?
>>>
>>>      
>>>
>>Lambda.
>>
>>    
>>
>>>  ii) in the case of [PSC, TDM] with a fully transparent signal?
>>>
>>>      
>>>
>>Port.
>>
>>    
>>
>>>c) if you implement as the draft says, would it be a hardship to change
>>>  this?
>>>
>>>      
>>>
>>Yes.
>>    
>>
>
>Noted.
>
>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: [e-mail]
Delivery-date: Tue, 23 Mar 2004 20:08:01 +0000
Date: Tue, 23 Mar 2004 12:06:02 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: Kireeti Kompella <[e-mail]>
cc: [e-mail]
Subject: Re: Label type to be used
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Kireeti,

I have also included your original questions for [PSC,LSC] and [PSC,TDM]
in this mail. Please see my answers inline.

thanks,
-arthi

> > the proposal as it read is:
> >  >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >  >       [PSC, TDM] - fully transparent signal: label represents a port
> >  >                    ("transparency" is defined in [GMPLS-SONET-SDH])
> >  >       [PSC, TDM] - non-transparent signal: label represents a TDM time
> >  >                    slot [GMPLS-SONET-SDH]
> >
> > the suggestion is also indicate the distinction for [TDM,TDM]:
> >          [TDM, TDM] - fully transparent signal: label represents a port
> >                       ("transparency" is defined in [GMPLS-SONET-SDH])
> >          [TDM, TDM] - non-transparent signal: label represents a TDM time
> >                       slot [GMPLS-SONET-SDH]
> >  >       [PSC, TDM] - fully transparent signal: label represents a port
> >  >                    ("transparency" is defined in [GMPLS-SONET-SDH])
> >  >       [PSC, TDM] - non-transparent signal: label represents a TDM time
> >  >                    slot [GMPLS-SONET-SDH]

>
> Okay.  Makes sense.  Questions for all:
>
> 1) do you agree with this change?
--------> Yes for the above changes. Yes for the proposed changes to
[PSC, LSC] case as well.

> 2) if you implement GMPLS for [TDM, TDM] links, do you use port labels
>    or SUKLM labels for the fully transparent case?
>    - if SUKLM, would it be a hardship to change this?
------> N/A.

  3) in your implementation today, what do expect the label to represent
>    i) in the case of [PSC, LSC]?
-------> Port.

>    ii) in the case of [PSC, TDM] with a fully transparent signal?
-------> Port.

> 4) if you implement as the draft says, would it be a hardship to change
>    this?
-------> N/A.




Envelope-to: [e-mail]
Delivery-date: Tue, 23 Mar 2004 19:43:57 +0000
Date: Tue, 23 Mar 2004 11:42:22 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Ben Mack-Crane <[e-mail]>
cc: [e-mail]
Subject: Re: Label type to be used
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Ben,

On Tue, 23 Mar 2004, Ben Mack-Crane wrote:

> The original text seems to have a sensible pattern.
> The proposed changed text does not.

Your responses below don't bear out your comment above: your
implementation uses port labels for [PSC, TDM/transparent], but the
original text says to use SUKLM.

The sensibility of the pattern is also questionable; an equally
sensible pattern is to use port labels for [x, TDM/transparent].

> In reviewing the discussion so far, it seems to me the best solution
> is to leave the text as is, understanding that switches capable of
> handling both TDM channelized switching as well as fully transparent
> (port or lambda) switching advertise multiple switching types.

I'm not sure how you reached the conclusion that the best solution is
to leave the text as is.  So far, there's been uniform agreement to
change the text, with Ashok counted as an abstention ("I won't really
object").

The main point, though, is to come to a meaningful position that also
jives with current implementations -- ultimately, standards are to
enable interoperable implementations.

<snipped>

> >Please respond by Friday 3/26, 5pm PST with comments on:
> >
> >a) do you agree with the above change?
> >
> No.
>
> >b) in your implementation today, what do expect the label to represent
> >   i) in the case of [PSC, LSC]?
> >
> Lambda.
>
> >   ii) in the case of [PSC, TDM] with a fully transparent signal?
> >
> Port.
>
> >c) if you implement as the draft says, would it be a hardship to change
> >   this?
> >
> Yes.

Noted.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 23 Mar 2004 19:06:41 +0000
From: "Tamer Khattab" <[e-mail]>
To: [e-mail]
Bcc: 
Subject: GMPLS Architecture
Date: Tue, 23 Mar 2004 11:05:05 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>

Hi all,
I am newly subscribed to ccamp group and I am mainly interested in GMPLS 
architecutre.  I am doing some research as a Ph.D. student at University of 
BC in Vancouver, BC, Canada.

I would like to propose the addition of Optical Code Labelling method to the 
GMPLS architecture in order to have more label mapping layers and at the 
same time to increase the number of optical label mapping layers that are 
capable of working in an all optical manner (no need for O-E-O conversion).
Currently, this is only valid for FSC, and LSC.  If we add the Optical Code 
and call it Code Switch Capable (CSC) then we will make optical switches 
(specially the all-optical backbone ones) able to identify higher number of 
isolated flows, which will significantly increase the QoS, as well as 
Management and Contol abilities of all-optical networks.

Any comments/suggestions in this area?  I am open for any discussions.

Thank you and best regards,

Tamer Khattab
PhD. Canadidate
Lab for Advance Networking
Electrical and Computer Engineerign
The University of British Columbia
http://www.ece.ubc.ca/~tkhattab

_________________________________________________________________
MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE*   
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines




Envelope-to: [e-mail]
Delivery-date: Tue, 23 Mar 2004 16:47:14 +0000
Message-ID: <[e-mail]>
From: John Drake <[e-mail]>
To: 'Ben Mack-Crane' <[e-mail]>, Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Subject: RE: Label type to be used
Date: Tue, 23 Mar 2004 08:45:49 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C410F6.4BF652D0"

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_01C410F6.4BF652D0
Content-Type: text/plain;
	charset="iso-8859-1"

Very sensible

-----Original Message-----
From: Ben Mack-Crane [mailto:[e-mail]]
Sent: Tuesday, March 23, 2004 8:15 AM
To: Kireeti Kompella
Cc: [e-mail]
Subject: Re: Label type to be used


Hi,

The original text seems to have a sensible pattern.
The proposed changed text does not.

In reviewing the discussion so far, it seems to me the best solution
is to leave the text as is, understanding that switches capable of
handling both TDM channelized switching as well as fully transparent
(port or lambda) switching advertise multiple switching types.

The tuples shown in the text under discussion do not appear in routing,
and labels are not a concern of routing, so rather than confuse
things further, it is best to leave the text as is.

Answers to the specific questions are in-line below.

Regards,
Ben


Kireeti Kompella wrote:


Hi,



Arthi and Lou pointed out the following typos in the GMPLS routing doc

(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC

Editor's queue:



In section 2.4.7 is the following table defining the type of label

for various combinations of switching types:



      [PSC, PSC] - label is carried in the "shim" header [RFC3032]

      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]

      [LSC, LSC] - label represents a lambda

      [FSC, FSC] - label represents a port on an OXC

      [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]

      [PSC, LSC] - label represents a lambda

      [PSC, FSC] - label represents a port

      [TDM, LSC] - label represents a lambda

      [TDM, FSC] - label represents a port

      [LSC, FSC] - label represents a port



The one at issue is [PSC, LSC]; above it says that the label

represents a lambda; and in the case of [PSC, TDM] with a fully

transparent signal, the above indicates the label represents a TDM

time slot.  The proposal is to change this to:



      [PSC, PSC] - label is carried in the "shim" header [RFC3032]

      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]

      [LSC, LSC] - label represents a lambda

      [FSC, FSC] - label represents a port on an OXC

      [PSC, TDM] - fully transparent signal: label represents a port

                   ("transparency" is defined in [GMPLS-SONET-SDH])

      [PSC, TDM] - non-transparent signal: label represents a TDM time

                   slot [GMPLS-SONET-SDH]

      [PSC, LSC] - label represents a port

      [PSC, FSC] - label represents a port

      [TDM, LSC] - label represents a lambda

      [TDM, FSC] - label represents a port

      [LSC, FSC] - label represents a port



Please respond by Friday 3/26, 5pm PST with comments on:



a) do you agree with the above change?

No.


b) in your implementation today, what do expect the label to represent

   i) in the case of [PSC, LSC]?

Lambda.


   ii) in the case of [PSC, TDM] with a fully transparent signal?

Port.


c) if you implement as the draft says, would it be a hardship to change

   this?

Yes.




If we can get closure on this, I'll take up the task of modifying the

pending RFC with the ADs.



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
============================================================


------_=_NextPart_001_01C410F6.4BF652D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D187054616-23032004><FONT face=3DArial =
color=3D#0000ff size=3D2>Very=20
sensible</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ben Mack-Crane=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, March =
23, 2004=20
  8:15 AM<BR><B>To:</B> Kireeti Kompella<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> Re: Label type to be=20
  used<BR><BR></FONT></DIV><FONT=20
  face=3D"Courier New, Courier, monospace">Hi,<BR><BR>The original text =
seems to=20
  have a sensible pattern.<BR>The proposed changed text does =
not.<BR><BR>In=20
  reviewing the discussion so far, it seems to me the best =
solution<BR>is to=20
  leave the text as is, understanding that switches capable =
of<BR>handling both=20
  TDM channelized switching as well as fully transparent<BR>(port or =
lambda)=20
  switching advertise multiple switching types.<BR><BR>The tuples shown =
in the=20
  text under discussion do not appear in routing,<BR>and labels are not =
a=20
  concern of routing, so rather than confuse<BR>things further, it is =
best to=20
  leave the text as is.<BR><BR>Answers to the specific questions are =
in-line=20
  below.<BR><BR>Regards,<BR>Ben<BR><BR></FONT><BR>Kireeti Kompella =
wrote:<BR>
  <BLOCKQUOTE cite=[e-mail] =
type=3D"cite"><PRE wrap=3D"">Hi,

Arthi and Lou pointed out the following typos in the GMPLS routing doc
(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
Editor's queue:

In section 2.4.7 is the following table defining the type of label
for various combinations of switching types:

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [LSC, LSC] - label represents a lambda
      [FSC, FSC] - label represents a port on an OXC
      [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [PSC, LSC] - label represents a lambda
      [PSC, FSC] - label represents a port
      [TDM, LSC] - label represents a lambda
      [TDM, FSC] - label represents a port
      [LSC, FSC] - label represents a port

The one at issue is [PSC, LSC]; above it says that the label
represents a lambda; and in the case of [PSC, TDM] with a fully
transparent signal, the above indicates the label represents a TDM
time slot.  The proposal is to change this to:

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [LSC, LSC] - label represents a lambda
      [FSC, FSC] - label represents a port on an OXC
      [PSC, TDM] - fully transparent signal: label represents a port
                   ("transparency" is defined in [GMPLS-SONET-SDH])
      [PSC, TDM] - non-transparent signal: label represents a TDM time
                   slot [GMPLS-SONET-SDH]
      [PSC, LSC] - label represents a port
      [PSC, FSC] - label represents a port
      [TDM, LSC] - label represents a lambda
      [TDM, FSC] - label represents a port
      [LSC, FSC] - label represents a port

Please respond by Friday 3/26, 5pm PST with comments on:

a) do you agree with the above change?</PRE></BLOCKQUOTE>No.<BR>
  <BLOCKQUOTE cite=[e-mail] =
type=3D"cite"><PRE wrap=3D"">b) in your implementation today, what do =
expect the label to represent
   i) in the case of [PSC, LSC]?</PRE></BLOCKQUOTE>Lambda.<BR>
  <BLOCKQUOTE cite=[e-mail] =
type=3D"cite"><PRE wrap=3D"">   ii) in the case of [PSC, TDM] with a =
fully transparent signal?</PRE></BLOCKQUOTE>Port.<BR>
  <BLOCKQUOTE cite=[e-mail] =
type=3D"cite"><PRE wrap=3D"">c) if you implement as the draft says, =
would it be a hardship to change
   this?</PRE></BLOCKQUOTE>Yes.<BR>
  <BLOCKQUOTE cite=[e-mail] =
type=3D"cite"><PRE wrap=3D"">
If we can get closure on this, I'll take up the task of modifying the
pending RFC with the ADs.

Kireeti.
-------

  </PRE></BLOCKQUOTE><BR>
  <P>
  <HR SIZE=3D1>

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

------_=_NextPart_001_01C410F6.4BF652D0--



Envelope-to: [e-mail]
Delivery-date: Tue, 23 Mar 2004 16:22:46 +0000
Message-ID: <[e-mail]>
Date: Tue, 23 Mar 2004 10:14:50 -0600
From: Ben Mack-Crane <[e-mail]>
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 <[e-mail]>
CC: [e-mail]
Subject: Re: Label type to be used
Content-Type: multipart/alternative; boundary="------------090109040400040306000704"

--------------090109040400040306000704
Content-Type: text/plain;
	charset="us-ascii";
	format="flowed"
Content-Transfer-Encoding: 7bit

Hi,

The original text seems to have a sensible pattern.
The proposed changed text does not.

In reviewing the discussion so far, it seems to me the best solution
is to leave the text as is, understanding that switches capable of
handling both TDM channelized switching as well as fully transparent
(port or lambda) switching advertise multiple switching types.

The tuples shown in the text under discussion do not appear in routing,
and labels are not a concern of routing, so rather than confuse
things further, it is best to leave the text as is.

Answers to the specific questions are in-line below.

Regards,
Ben


Kireeti Kompella wrote:

>Hi,
>
>Arthi and Lou pointed out the following typos in the GMPLS routing doc
>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
>Editor's queue:
>
>In section 2.4.7 is the following table defining the type of label
>for various combinations of switching types:
>
>      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>      [LSC, LSC] - label represents a lambda
>      [FSC, FSC] - label represents a port on an OXC
>      [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>      [PSC, LSC] - label represents a lambda
>      [PSC, FSC] - label represents a port
>      [TDM, LSC] - label represents a lambda
>      [TDM, FSC] - label represents a port
>      [LSC, FSC] - label represents a port
>
>The one at issue is [PSC, LSC]; above it says that the label
>represents a lambda; and in the case of [PSC, TDM] with a fully
>transparent signal, the above indicates the label represents a TDM
>time slot.  The proposal is to change this to:
>
>      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>      [LSC, LSC] - label represents a lambda
>      [FSC, FSC] - label represents a port on an OXC
>      [PSC, TDM] - fully transparent signal: label represents a port
>                   ("transparency" is defined in [GMPLS-SONET-SDH])
>      [PSC, TDM] - non-transparent signal: label represents a TDM time
>                   slot [GMPLS-SONET-SDH]
>      [PSC, LSC] - label represents a port
>      [PSC, FSC] - label represents a port
>      [TDM, LSC] - label represents a lambda
>      [TDM, FSC] - label represents a port
>      [LSC, FSC] - label represents a port
>
>Please respond by Friday 3/26, 5pm PST with comments on:
>
>a) do you agree with the above change?
>
No.

>b) in your implementation today, what do expect the label to represent
>   i) in the case of [PSC, LSC]?
>
Lambda.

>   ii) in the case of [PSC, TDM] with a fully transparent signal?
>
Port.

>c) if you implement as the draft says, would it be a hardship to change
>   this?
>
Yes.

>
>If we can get closure on this, I'll take up the task of modifying the
>pending RFC with the ADs.
>
>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
============================================================
--------------090109040400040306000704
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

<HTML>
<BODY>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<font face="Courier New, Courier, monospace">Hi,<br>
<br>
The original text seems to have a sensible pattern.<br>
The proposed changed text does not.<br>
<br>
In reviewing the discussion so far, it seems to me the best solution<br>
is to leave the text as is, understanding that switches capable of<br>
handling both TDM channelized switching as well as fully transparent<br>
(port or lambda) switching advertise multiple switching types.<br>
<br>
The tuples shown in the text under discussion do not appear in routing,<br>
and labels are not a concern of routing, so rather than confuse<br>
things further, it is best to leave the text as is.<br>
<br>
Answers to the specific questions are in-line below.<br>
<br>
Regards,<br>
Ben<br>
<br>
</font><br>
Kireeti Kompella wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">Hi,

Arthi and Lou pointed out the following typos in the GMPLS routing doc
(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
Editor's queue:

In section 2.4.7 is the following table defining the type of label
for various combinations of switching types:

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [LSC, LSC] - label represents a lambda
      [FSC, FSC] - label represents a port on an OXC
      [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [PSC, LSC] - label represents a lambda
      [PSC, FSC] - label represents a port
      [TDM, LSC] - label represents a lambda
      [TDM, FSC] - label represents a port
      [LSC, FSC] - label represents a port

The one at issue is [PSC, LSC]; above it says that the label
represents a lambda; and in the case of [PSC, TDM] with a fully
transparent signal, the above indicates the label represents a TDM
time slot.  The proposal is to change this to:

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [LSC, LSC] - label represents a lambda
      [FSC, FSC] - label represents a port on an OXC
      [PSC, TDM] - fully transparent signal: label represents a port
                   ("transparency" is defined in [GMPLS-SONET-SDH])
      [PSC, TDM] - non-transparent signal: label represents a TDM time
                   slot [GMPLS-SONET-SDH]
      [PSC, LSC] - label represents a port
      [PSC, FSC] - label represents a port
      [TDM, LSC] - label represents a lambda
      [TDM, FSC] - label represents a port
      [LSC, FSC] - label represents a port

Please respond by Friday 3/26, 5pm PST with comments on:

a) do you agree with the above change?</pre>
</blockquote>
No.<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">
b) in your implementation today, what do expect the label to represent
   i) in the case of [PSC, LSC]?</pre>
</blockquote>
Lambda.<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">
   ii) in the case of [PSC, TDM] with a fully transparent signal?</pre>
</blockquote>
Port.<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">
c) if you implement as the draft says, would it be a hardship to change
   this?</pre>
</blockquote>
Yes.<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">

If we can get closure on this, I'll take up the task of modifying the
pending RFC with the ADs.

Kireeti.
-------

  </pre>
</blockquote>
<br>
</body>
</html>


<P><hr size=1></P>
<P><STRONG>============================================================<br>The information contained in this message may be privileged <br>and confidential and protected from disclosure.  If the <br>reader of this message is not the intended recipient, or an <br>employee or agent responsible for delivering this message to <br>the intended recipient, you are hereby notified that any <br>reproduction, dissemination or distribution of this <br>communication is strictly prohibited. If you have received <br>this communication in error, please notify us immediately by <br>replying to the message and deleting it from your computer.<br><br>Thank you.<br>Tellabs<br>============================================================</STRONG></P>
</BODY>
</HTML>
--------------090109040400040306000704--




Envelope-to: [e-mail]
Delivery-date: Tue, 23 Mar 2004 02:41:02 +0000
From: "zafar ali" <[e-mail]>
To: "'Vishal Sharma'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Node-id Hello -  standards track or BCP?
Date: Mon, 22 Mar 2004 21:40:49 -0500
Organization: Cisco Systems
Message-ID: <000a01c41080$40e40480$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: Vishal Sharma [mailto:[e-mail]] 
>Sent: Friday, March 19, 2004 2:28 PM
>To: Adrian Farrel; [e-mail]; [e-mail]; Zafar Ali
>Subject: RE: Node-id Hello - standards track or BCP?
>
>
>Adrian,
>
>I think this is appropriate for the BCP category.
>
>Also, I think Arun brings up a very good point about 
>consistency with addressing in Path/Resv. messages, and I 
>support the idea that it would be good to have clarification 
>to this effect in the draft.

Hi Vishal, 

Thanks for your feedback; much appreciated. As I mentioned in the reply
to Arun's email, we will put a clarification statement accordingly.

Thanks

Regards... Zafar 

>
>-Vishal
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]On
>> Behalf Of Adrian Farrel
>> Sent: Thursday, March 18, 2004 8:39 PM
>> To: [e-mail]
>> Subject: Node-id Hello - standards track or BCP?
>> 
>> 
>> (or informational?)
>> 
>> The question for you folks is:
>> 
>> does this change protocol behavior (standards track)
>> or narrow the choices for an implementation (BCP)
>> or describe what some implementations do (informational)
>> 
>> An essential difference between the first and the second might be
>> the behavior that one
>> LSR expects from its neighbor.
>> 
>> Opinions are cheap, but I want them anyway.
>> 
>> Thanks,
>> Adrian
>> 
>




Envelope-to: [e-mail]
Delivery-date: Tue, 23 Mar 2004 02:37:37 +0000
From: "zafar ali" <[e-mail]>
To: <[e-mail]>, "'Adrian Farrel'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Node-id Hello -  standards track or BCP?
Date: Mon, 22 Mar 2004 21:36:47 -0500
Organization: Cisco Systems
Message-ID: <000901c4107f$b0c22120$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Arun, 

Sorry for the delay; thanks for your feedback on the draft. 

Please my reply in-line. 

Thanks

Regards... Zafar

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Arun Satyanarayana
>Sent: Friday, March 19, 2004 1:49 PM
>To: Adrian Farrel
>Cc: [e-mail]; Arun Satyanarayan
>Subject: Re: Node-id Hello - standards track or BCP?
>
>
>
>BCP since it does narrow choice.
>
>However, I do have some comments:
>
>The following text in section 2 is not necessarily true:
>
>                                             Specifically, when all TE
>   links between neighbor nodes are unnumbered, it is implied that the
>   nodes will use node-id based Hellos for detection of signaling
>   adjacency failures.
>
>TE links may be unnumbered, but the corresponding control 
>channel(s) may be numbered. Implementations may choose to use 
>either the control channel interface addresses or node id's 
>(a.k.a loopback addresses) for RSVP messages.
>
>In general, it would suffice to say that the IP addressing 
>used in Hellos follows the addressing used in Path and Resv 
>messages. This includes any modified IP addressing behaviour 
>for Path and Resv messages, when the control channel is 
>out-of-band, as well as, when unnumbered data interfaces are 
>in use. Hence, if implementations do want to narrow Hellos to 
>node id's (a.k.a loopback addresses), they do so consistently 
>across all other RSVP messages as well. This means conditions 
>such as Hellos being up but Path and Resv refreshes being 
>lost, or vice versa do not occur. 

Yes, this is a good point; we will include the comment accordingly.

>It also means that, it is 
>not necessary to consult routing to correlate node id's to 
>corresponding control channel IP interface addresses to go 
>from Hellos to Path/Resv state for the sender node and vice versa.
>
>Thanks,
>_arun_ ============================================================
>On Fri, 19 Mar 2004, Adrian Farrel wrote:
>
>> (or informational?)
>>
>> The question for you folks is:
>>
>> does this change protocol behavior (standards track)
>> or narrow the choices for an implementation (BCP)
>> or describe what some implementations do (informational)
>>
>> An essential difference between the first and the second 
>might be the 
>> behavior that one LSR expects from its neighbor.
>>
>> Opinions are cheap, but I want them anyway.
>>
>> Thanks,
>> Adrian
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 23 Mar 2004 00:36:25 +0000
Message-ID: <[e-mail]>
From: John Drake <[e-mail]>
To: 'Lou Berger' <[e-mail]>, Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Subject: RE: Label type to be used
Date: Mon, 22 Mar 2004 16:34:52 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Snipped

-----Original Message-----
An alternative is to advertise such interfaces as LSC all the time.  I 
don't think such advertisements are implied today, but the text could be 
change.


JD:  This is my understanding of what should be advertised.  Whether
the wavelength is internally switched electrically or optically isn't
relevant.



Envelope-to: [e-mail]
Delivery-date: Mon, 22 Mar 2004 16:35:20 +0000
Message-ID: <[e-mail]>
From: "Pandian, Vijay" <[e-mail]>
To: 'Kireeti Kompella' <[e-mail]>, [e-mail]
Subject: RE: Label type to be used
Date: Mon, 22 Mar 2004 11:37:36 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Kireeti,

Comments inline...

Regards,

Vijay

> -----Original Message-----
> From: Kireeti Kompella [mailto:[e-mail]]
> Sent: Thursday, March 18, 2004 12:58 PM
> To: [e-mail]
> Subject: Label type to be used
> 
> 
> Hi,
> 
> Arthi and Lou pointed out the following typos in the GMPLS routing doc
> (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
> Editor's queue:
> 
> In section 2.4.7 is the following table defining the type of label
> for various combinations of switching types:
> 
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a lambda
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
> 
> The one at issue is [PSC, LSC]; above it says that the label
> represents a lambda; and in the case of [PSC, TDM] with a fully
> transparent signal, the above indicates the label represents a TDM
> time slot.  The proposal is to change this to:
> 
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - fully transparent signal: label represents a port
>                    ("transparency" is defined in [GMPLS-SONET-SDH])
>       [PSC, TDM] - non-transparent signal: label represents a TDM time
>                    slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a port
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
> 
> Please respond by Friday 3/26, 5pm PST with comments on:
> 
> a) do you agree with the above change?

Yes, but we need one more change.
Why is it for [TDM, LSC] the label is lambda? Shouldn't this be port as
well?

> b) in your implementation today, what do expect the label to represent
>    i) in the case of [PSC, LSC]?

Not applicable

>    ii) in the case of [PSC, TDM] with a fully transparent signal?

Port

> c) if you implement as the draft says, would it be a hardship 
> to change
>    this?

No

> 
> If we can get closure on this, I'll take up the task of modifying the
> pending RFC with the ADs.
> 
> Kireeti.
> -------
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 22 Mar 2004 14:40:56 +0000
Message-Id: <6.0.3.0.2.20040322091952.05e1cc18@mo-ex1>
Date: Mon, 22 Mar 2004 09:38:01 -0500
To: "Kireeti Kompella" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Label type to be used
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:16 PM 3/21/2004 -0500, Kireeti Kompella wrote:

>On Sun, 21 Mar 2004, dimitri papadimitriou wrote:
>
>Hi Dimitri,
>
> > the proposal as it read is:
> >  >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >  >       [PSC, TDM] - fully transparent signal: label represents a port
> >  >                    ("transparency" is defined in [GMPLS-SONET-SDH])
> >  >       [PSC, TDM] - non-transparent signal: label represents a TDM time
> >  >                    slot [GMPLS-SONET-SDH]
> >
> > the suggestion is also indicate the distinction for [TDM,TDM]:
> >          [TDM, TDM] - fully transparent signal: label represents a port
> >                       ("transparency" is defined in [GMPLS-SONET-SDH])
> >          [TDM, TDM] - non-transparent signal: label represents a TDM time
> >                       slot [GMPLS-SONET-SDH]
> >  >       [PSC, TDM] - fully transparent signal: label represents a port
> >  >                    ("transparency" is defined in [GMPLS-SONET-SDH])
> >  >       [PSC, TDM] - non-transparent signal: label represents a TDM time
> >  >                    slot [GMPLS-SONET-SDH]
>
>Okay.  Makes sense.  Questions for all:
>
>1) do you agree with this change?
>2) if you implement GMPLS for [TDM, TDM] links, do you use port labels
>    or SUKLM labels for the fully transparent case?
>    - if SUKLM, would it be a hardship to change this?
>
>Please respond by Sun Mar 28th, 5pm PST.
>
>Thanks!
>Kireeti.
>-------

Kireeti,
         I think Dimitri's clarification reflects the current state of the 
documents.  So is *not* a change, but makes more explicit what is already 
in the documents.  There are implementations that do exactly this today.

Changing to SUKLM, per your item 2, implies an update to 
[GMPLS-SONET-SDH].  Also, more importantly, (at least to me) is it implies 
that a link's switching type or label type may need change based on a 
neighbor's switching type!  Consider transport equipment that support 
SONET/SDH framing, but not sub-channel switching.  Item 2 implies that a 
SUKLM label would be used when the neighbor is a TDM switch, and a port 
label is used when a neighbor is a router.  This seems wrong to me.

An alternative is to advertise such interfaces as LSC all the time.  I 
don't think such advertisements are implied today, but the text could be 
change.  An even better alternative is to introduce a new switching 
capability between TDM and LSC that is used for interfaces that only 
support a single transparent service on the interface.  I like this 
alternative, but it is a bit late to make such a change...

Lou




Envelope-to: [e-mail]
Delivery-date: Sun, 21 Mar 2004 19:20:13 +0000
Message-ID: <[e-mail]>
Date: Sun, 21 Mar 2004 14:18:53 -0500 (EST)
Subject: Questions
From: <[e-mail]>
To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi all,
I’am studying GMPLS and I have a couple of questions, don’t you mind to
answer me?.

The first question is about routing in GMPLS. It is clear that GMPLS uses
OSPF-TE or IS-IS-TE, in these protocols, the information about max
bandwidth available on each network interface is advertised. However, in
the case of lambda-switched network without wavelength converter, the
wavelength continuity is one constraint. How this constraint is taken into
account in a LSP request?. The routing protocol of GMPLS calculates and
provides single wavelength routes or the wavelength is selected hop by hop
along with signaling process?
The second question is about the current utilization state of GMPLS. Is
there any implementation and utilization of GMPLS a real network as
control plan?

Those are my two questions, thank you for every answer.

Linh






Envelope-to: [e-mail]
Delivery-date: Sun, 21 Mar 2004 18:17:14 +0000
Date: Sun, 21 Mar 2004 10:16:13 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: Re: Label type to be used
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 21 Mar 2004, dimitri papadimitriou wrote:

Hi Dimitri,

> the proposal as it read is:
>  >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>  >       [PSC, TDM] - fully transparent signal: label represents a port
>  >                    ("transparency" is defined in [GMPLS-SONET-SDH])
>  >       [PSC, TDM] - non-transparent signal: label represents a TDM time
>  >                    slot [GMPLS-SONET-SDH]
>
> the suggestion is also indicate the distinction for [TDM,TDM]:
>          [TDM, TDM] - fully transparent signal: label represents a port
>                       ("transparency" is defined in [GMPLS-SONET-SDH])
>          [TDM, TDM] - non-transparent signal: label represents a TDM time
>                       slot [GMPLS-SONET-SDH]
>  >       [PSC, TDM] - fully transparent signal: label represents a port
>  >                    ("transparency" is defined in [GMPLS-SONET-SDH])
>  >       [PSC, TDM] - non-transparent signal: label represents a TDM time
>  >                    slot [GMPLS-SONET-SDH]

Okay.  Makes sense.  Questions for all:

1) do you agree with this change?
2) if you implement GMPLS for [TDM, TDM] links, do you use port labels
   or SUKLM labels for the fully transparent case?
   - if SUKLM, would it be a hardship to change this?

Please respond by Sun Mar 28th, 5pm PST.

Thanks!
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Sun, 21 Mar 2004 13:22:32 +0000
Message-ID: <[e-mail]>
Date: Sun, 21 Mar 2004 14:21:13 +0100
From: dimitri papadimitriou <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail]
Subject: Re: Label type to be used
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi kireeti

Kireeti Kompella wrote:

> Hi Dimitri,
> 
> 
>>>a) do you agree with the above change?
>>
>>yes, wouldn't be also wise to include the distinction for the
>>[TDM,TDM] case ?
> 
> 
> Could you clarify?

the proposal as it read is:
 >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
 >       [PSC, TDM] - fully transparent signal: label represents a port
 >                    ("transparency" is defined in [GMPLS-SONET-SDH])
 >       [PSC, TDM] - non-transparent signal: label represents a TDM time
 >                    slot [GMPLS-SONET-SDH]

the suggestion is also indicate the distinction for [TDM,TDM]:
         [TDM, TDM] - fully transparent signal: label represents a port
                      ("transparency" is defined in [GMPLS-SONET-SDH])
         [TDM, TDM] - non-transparent signal: label represents a TDM time
                      slot [GMPLS-SONET-SDH]
 >       [PSC, TDM] - fully transparent signal: label represents a port
 >                    ("transparency" is defined in [GMPLS-SONET-SDH])
 >       [PSC, TDM] - non-transparent signal: label represents a TDM time
 >                    slot [GMPLS-SONET-SDH]

thanks,
- dimitri.

>>>b) in your implementation today, what do expect the label to represent
>>>   i) in the case of [PSC, LSC]?
>>
>>port
>>
>>
>>>   ii) in the case of [PSC, TDM] with a fully transparent signal?
>>
>>port
> 
> 
> Thanks for your responses.
> 
> Kireeti.
> -------
> 
> 
> .
> 




Envelope-to: [e-mail]
Delivery-date: Sun, 21 Mar 2004 02:05:16 +0000
Date: Sat, 20 Mar 2004 18:03:51 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: dimitri papadimitriou <[e-mail]>
cc: [e-mail]
Subject: Re: Label type to be used
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Dimitri,

> > a) do you agree with the above change?
>
> yes, wouldn't be also wise to include the distinction for the
> [TDM,TDM] case ?

Could you clarify?

> > b) in your implementation today, what do expect the label to represent
> >    i) in the case of [PSC, LSC]?
>
> port
>
> >    ii) in the case of [PSC, TDM] with a fully transparent signal?
>
> port

Thanks for your responses.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Sat, 20 Mar 2004 12:53:46 +0000
Message-ID: <[e-mail]>
Date: Sat, 20 Mar 2004 13:54:11 +0100
From: dimitri papadimitriou <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail]
Subject: Re: Label type to be used
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi kireeti

see in-line:

Kireeti Kompella wrote:

> Hi,
> 
> Arthi and Lou pointed out the following typos in the GMPLS routing doc
> (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
> Editor's queue:
> 
> In section 2.4.7 is the following table defining the type of label
> for various combinations of switching types:
> 
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a lambda
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
> 
> The one at issue is [PSC, LSC]; above it says that the label
> represents a lambda; and in the case of [PSC, TDM] with a fully
> transparent signal, the above indicates the label represents a TDM
> time slot.  The proposal is to change this to:
> 
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - fully transparent signal: label represents a port
>                    ("transparency" is defined in [GMPLS-SONET-SDH])
>       [PSC, TDM] - non-transparent signal: label represents a TDM time
>                    slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a port
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
> 
> Please respond by Friday 3/26, 5pm PST with comments on:
> 
> a) do you agree with the above change?

yes, wouldn't be also wise to include the distinction for the
[TDM,TDM] case ?

> b) in your implementation today, what do expect the label to represent
>    i) in the case of [PSC, LSC]?

port

>    ii) in the case of [PSC, TDM] with a fully transparent signal?

port

> c) if you implement as the draft says, would it be a hardship to change
>    this?
> 
> If we can get closure on this, I'll take up the task of modifying the
> pending RFC with the ADs.
> 
> Kireeti.
> -------
> 
> 
> .
> 




Envelope-to: [e-mail]
Delivery-date: Sat, 20 Mar 2004 03:21:46 +0000
Message-Id: <[e-mail]>
Date: Fri, 19 Mar 2004 22:19:09 -0500
To: "Adrian Farrel" <[e-mail]>
From: Anca Zamfir <[e-mail]>
Subject: Re: Node-id Hello -  standards track or BCP?
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

BCP in my opinion.

/anca
At 04:38 AM 3/19/2004 +0000, Adrian Farrel wrote:
>(or informational?)
>
>The question for you folks is:
>
>does this change protocol behavior (standards track)
>or narrow the choices for an implementation (BCP)
>or describe what some implementations do (informational)
>
>An essential difference between the first and the second might be the 
>behavior that one
>LSR expects from its neighbor.
>
>Opinions are cheap, but I want them anyway.
>
>Thanks,
>Adrian





Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2004 20:11:42 +0000
Date: Fri, 19 Mar 2004 12:09:55 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail], Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>, Adrian Farrel <[e-mail]>, Kireeti Kompella <[e-mail]>, [e-mail], [e-mail]
Subject: Communication respone re: Intra-Carrier E-NNI Routing Using OSPF
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1057782165-1079726995=:13502"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [e-mail] for more info.

--0-1057782165-1079726995=:13502
Content-Type: TEXT/PLAIN; charset=US-ASCII

 From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs
 To: Mr. Steve Joiner, OIF Technical Committee Chair
 Cc: Jim Jones,        OIF Architecture/Signaling Working Group Chair
 Cc: John McDonough,   OIF Liaison to ITU-T SG15
 Cc: Alex Zinin,       IETF Routing Area Director
 Cc: Bill Fenner,      IETF Routing Area Director
 Regarding: OIF intra-carrier E-NNI routing work
 Date:     March 19, 2004
 Reply by: April 30, 2004

Dear Steve,

Thank you for your communication regarding the current status of OIF
signaling and routing work, and the associated documentation.  This
communication is in response.  As there is no formal liaison
relationship yet between the IETF and the OIF, this communication is
not treated as a liaison; hopefully, this situation will be rectified
soon.

Thank you too for allowing Mr. Lyndon Ong to present a synopsis of
the work going on at the OIF with regard to Intra-carrier E-NNI
routing.  It was both useful and enlightening.

However, both of these gave us cause for alarm, on two fronts:
a) The development of new or modified code points and procedures
   in OSPF without expert review from the OSPF WG in the IETF
   contravenes IETF procedure, especially as the IETF pays special
   attention to changes in protocols in the Routing Area, such as
   OSPF.
b) The development of routing for optical networks without expert
   review from the CCAMP WG is also a source of concern, especially
   in the light of an on-going cooperative effort between the ITU-T
   and the IETF.  This effort has identified several gaps between
   GMPLS routing extensions and ASON routing requirements; once this
   task is complete, further routing extensions will be defined to
   fill these gaps.  Experimental extensions from the OIF in the
   context of an interoperability demo will only serve to confuse
   the industry and hinder the progress of standards.

Mr. Ong's emphasis that this work was experimental and purely for the
purpose of testing alleviated some of our concerns.  It would be very
helpful to hear this officially from the OIF; furthermore, in the
interests of openness and full disclosure, we would strongly urge the
modification of a paragraph in the Introduction of the draft routing
document OIF2003.259 as follows:

   "The base protocol as defined by this document is OSPF with
    extensions for Traffic Engineering and GMPLS.  This document
    proposes to use GMPLS-OSPF to operate at each hierarchical
    level, with multiple such levels stacking up to form the
    routing hierarchy.  Extensions have been defined in the forms
    of (sub-) TLVs to accommodate the requirements as defined in the
    G.8080, G.7715, and G.7715.1.  Note that these extensions as
    currently specified are purely for the purpose of experimentation
    and testing; in particular, they have not yet been reviewed by
    the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
    use experimental codepoints, and as such must not be used in
    production deployments."

Mr. Ong also brought to our attention that the OIF will be holding
an interoperability demonstration of this specification at the
SuperComm in June 2004.  Due to the preliminary nature of this
specification, the IETF would strongly recommend that the words
OSPF, OSPF-TE and GMPLS not be used in the context of this
demonstration, nor that there be any implication that this work
has been reviewed or sanctioned by the IETF.

It would be helpful in determining the future relationship between
the IETF and the OIF to understand how the OIF intends to progress
this document.

 o Is this intended to become an Implementation Agreement in
   something close to its current form?

 o Does the OIF intend to submit this as a submission in the ITU-T
   SG15 to become a Recommendation?

 o Does the OIF intend to submit this document as an Internet Draft
   to become an IETF RFC?

Thank you for your attention in this matter, and for initiating this
dialogue.  We hope that this develops into a fruitful relationship.
To that end, we enclose a product of the joint work between the
ITU-T and the IETF on Routing Requirements for ASON.  This is a
work in progress, and we solicit your comments:
 - to identify any requirements that the OIF has over and above those
    requirements established by the ITU-T ASON model
 - to ensure that the solution developed within the IETF addresses
    the requirements of both the ITU-T and OIF.

We hope that your feedback will signal the beginning of an active
cooperation between the IETF and the OIF.

Sincerely,
Kireeti Kompella
Adrian Farrel

<attachment: current version of GMPLS ASON Routing Requirements doc>

Kireeti.
-------
--0-1057782165-1079726995=:13502
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gmpls-ason-routing-reqts
Content-Transfer-Encoding: BASE64
Content-ID: <[e-mail]>
Content-Description: Reqts for GMPLS routing for ASON
Content-Disposition: attachment; filename=gmpls-ason-routing-reqts

Q0NBTVAgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgV2VzYW0gQWxhbnFhciAoU3ByaW50KQ0KSW50ZXJuZXQgRHJhZnQgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVib3JhaCBCcnVuZ2Fy
ZCAoQVRUKQ0KQ2F0ZWdvcnk6IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAg
ICAgICAgICBEYXZlIE1leWVyIChDaXNjbyBTeXN0ZW1zKQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEx5
bmRvbiBPbmcgKENpZW5hKQ0KRXhwaXJhdGlvbiBEYXRlOiBKdWx5IDIwMDQg
ICAgICAgICAgICAgRGltaXRyaSBQYXBhZGltaXRyaW91IChBbGNhdGVsKQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Sm9uYXRoYW4gU2FkbGVyIChUZWxsYWJzKQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0ZXBoZW4gU2hldyAo
Tm9ydGVsKQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDA0DQoNCg0KDQog
ICAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBHZW5lcmFsaXplZCBNUExT
IChHTVBMUykgUm91dGluZw0KICAgICAgICAgICAgIGZvciBBdXRvbWF0aWNh
bGx5IFN3aXRjaGVkIE9wdGljYWwgTmV0d29yayAoQVNPTikNCg0KICAgICAg
ICAgICAgIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJl
cXRzLTAyLnR4dA0KDQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBU
aGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBm
dWxsIGNvbmZvcm1hbmNlIHdpdGgNCiAgIGFsbCBwcm92aXNpb25zIG9mIFNl
Y3Rpb24gMTAgb2YgUkZDLTIwMjYuDQoNCiAgIEludGVybmV0LURyYWZ0cyBh
cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy
aW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRz
IHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBt
YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVy
bmV0LQ0KICAgRHJhZnRzLiBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv
Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mDQogICBzaXggbW9udGhz
IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBi
eSBvdGhlcg0KICAgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFw
cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC0gRHJhZnRzDQogICBhcyByZWZl
cmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMg
IndvcmsgaW4NCiAgIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3Vy
cmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBo
dHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQNCg0K
ICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9y
aWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9y
Zy9zaGFkb3cuaHRtbC4NCg0KDQpBYnN0cmFjdA0KDQogICBUaGUgR2VuZXJh
bGl6ZWQgTVBMUyAoR01QTFMpIHN1aXRlIG9mIHByb3RvY29scyBoYXMgYmVl
biBkZWZpbmVkIHRvDQogICBjb250cm9sIGRpZmZlcmVudCBzd2l0Y2hpbmcg
dGVjaG5vbG9naWVzIGFzIHdlbGwgYXMgZGlmZmVyZW50DQogICBhcHBsaWNh
dGlvbnMuIFRoZXNlIGluY2x1ZGUgc3VwcG9ydCBmb3IgcmVxdWVzdGluZyBU
RE0gY29ubmVjdGlvbnMNCiAgIGluY2x1ZGluZyBTT05FVC9TREggYW5kIE9w
dGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzIChPVE5zKS4NCg0KICAgVGhpcyBk
b2N1bWVudCBjb25jZW50cmF0ZXMgb24gdGhlIHJvdXRpbmcgcmVxdWlyZW1l
bnRzIG9uIHRoZSBHTVBMUw0KICAgc3VpdGUgb2YgcHJvdG9jb2xzIHRvIHN1
cHBvcnQgdGhlIGNhcGFiaWxpdGllcyBhbmQgZnVuY3Rpb25hbGl0aWVzDQog
ICBmb3IgYW4gQXV0b21hdGljYWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdv
cmsgKEFTT04pIGFzIGRlZmluZWQgYnkNCiAgIElUVS1ULg0KDQoNCg0KDQpX
LkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBKdWx5IDIwMDQgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAxDQoMDQpkcmFmdC1pZXRmLWNjYW1w
LWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMi50eHQgICAgICAgICBGZWJy
dWFyeSAyMDA0DQoNCg0KMS4gQ29udHJpYnV0b3JzDQoNCiAgIFRoaXMgZG9j
dW1lbnQgaXMgdGhlIHJlc3VsdCBvZiB0aGUgQ0NBTVAgV29ya2luZyBHcm91
cCBBU09OIFJvdXRpbmcNCiAgIFJlcXVpcmVtZW50cyBkZXNpZ24gdGVhbSBq
b2ludCBlZmZvcnQuDQoNCjIuIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBk
b2N1bWVudA0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U
IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hP
VUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFu
ZCAiT1BUSU9OQUwiIGluDQogICB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBp
bnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDLTIxMTkuDQoNCjMuIElu
dHJvZHVjdGlvbg0KDQogICBUaGUgR01QTFMgc3VpdGUgb2YgcHJvdG9jb2xz
IHByb3ZpZGVzIGFtb25nIG90aGVyIGNhcGFiaWxpdHkgc3VwcG9ydA0KICAg
Zm9yIGNvbnRyb2xsaW5nIGRpZmZlcmVudCBzd2l0Y2hpbmcgdGVjaG5vbG9n
aWVzLiBUaGVzZSBpbmNsdWRlDQogICBzdXBwb3J0IGZvciByZXF1ZXN0aW5n
IFRETSBjb25uZWN0aW9ucyB1dGlsaXppbmcgU09ORVQvU0RIIChzZWUgQU5T
SQ0KICAgVDEuMTA1L0lUVS1UIEcuNzA3KSBhcyB3ZWxsIGFzIE9wdGljYWwg
VHJhbnNwb3J0IE5ldHdvcmtzIChzZWUgSVRVLVQNCiAgIEcuNzA5KS4gSG93
ZXZlciwgdGhlcmUgYXJlIGNlcnRhaW4gY2FwYWJpbGl0aWVzIHRoYXQgYXJl
IG5lZWRlZCB0bw0KICAgc3VwcG9ydCB0aGUgSVRVLVQgRy44MDgwIGNvbnRy
b2wgcGxhbmUgYXJjaGl0ZWN0dXJlIGZvciB0aGUNCiAgIEF1dG9tYXRpY2Fs
bHkgU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrIChBU09OKS4gVGhlcmVmb3Jl
LCBpdCBpcw0KICAgZGVzaXJhYmxlIHRvIHVuZGVyc3RhbmQgdGhlIGNvcnJl
c3BvbmRpbmcgcmVxdWlyZW1lbnRzIGZvciB0aGUgR01QTFMNCiAgIHByb3Rv
Y29sIHN1aXRlLiBUaGUgQVNPTiBjb250cm9sIHBsYW5lIGFyY2hpdGVjdHVy
ZSBpcyBkZWZpbmVkIGluDQogICBbRy44MDgwXSBhbmQgQVNPTiByb3V0aW5n
IHJlcXVpcmVtZW50cyBhcmUgaWRlbnRpZmllZCBpbiBbRy43NzE1XQ0KICAg
YW5kIHJlZmluZWQgaW4gW0cuNzcxNS4xXSBmb3IgbGluayBzdGF0ZSBhcmNo
aXRlY3R1cmVzLiBUaGVzZQ0KICAgcmVjb21tZW5kYXRpb25zIHByb3ZpZGUg
ZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgYW5kIGFyY2hpdGVjdHVyZSwNCiAg
IHRoZXkgcHJvdmlkZSBhIHByb3RvY29sIG5ldXRyYWwgYXBwcm9hY2guDQoN
CiAgIFRoaXMgZG9jdW1lbnQgZm9jdXNlcyBvbiB0aGUgcm91dGluZyByZXF1
aXJlbWVudHMgZm9yIHRoZSBHTVBMUw0KICAgc3VpdGUgb2YgcHJvdG9jb2xz
IHRvIHN1cHBvcnQgdGhlIGNhcGFiaWxpdGllcyBhbmQgZnVuY3Rpb25hbGl0
eSBvZg0KICAgQVNPTiBjb250cm9sIHBsYW5lcy4gSXQgZGlzY3Vzc2VzIHRo
ZSByZXF1aXJlbWVudHMgZm9yIEdNUExTIHJvdXRpbmcNCiAgIHRoYXQgTUFZ
IHN1YnNlcXVlbnRseSBsZWFkIHRvIGFkZGl0aW9uYWwgYmFja3dhcmQgY29t
cGF0aWJsZQ0KICAgZXh0ZW5zaW9ucyB0byBzdXBwb3J0IHRoZSBjYXBhYmls
aXRpZXMgc3BlY2lmaWVkIGluIHRoZSBhYm92ZQ0KICAgcmVmZXJlbmNlZCBk
b2N1bWVudHMuIEEgZGVzY3JpcHRpb24gb2YgYmFja3dhcmQgY29tcGF0aWJp
bGl0eQ0KICAgY29uc2lkZXJhdGlvbnMgaXMgcHJvdmlkZWQgaW4gU2VjdGlv
biA1LiBOb25ldGhlbGVzcywgYW55IHByb3RvY29sDQogICAoaW4gcGFydGlj
dWxhciwgcm91dGluZykgZGVzaWduIG9yIHN1Z2dlc3RlZCBwcm90b2NvbCBl
eHRlbnNpb25zIGlzDQogICBzdHJpY3RseSBvdXRzaWRlIHRoZSBzY29wZSBv
ZiB0aGlzIGRvY3VtZW50LiBBbiBBU09OIChSb3V0aW5nKQ0KICAgdGVybWlu
b2xvZ3kgc2VjdGlvbiBpcyBwcm92aWRlZCBpbiBBcHBlbmRpeCAxIGFuZCBB
cHBlbmRpeCAyLg0KDQogICBUaGUgQVNPTiBtb2RlbCBkaXN0aW5ndWlzaGVz
IHJlZmVyZW5jZSBwb2ludHMgKHJlcHJlc2VudGluZyBwb2ludHMNCiAgIG9m
IGluZm9ybWF0aW9uIGV4Y2hhbmdlKSBkZWZpbmVkICgxKSBiZXR3ZWVuIGFu
IGFkbWluaXN0cmF0aXZlDQogICBkb21haW4gYW5kIGEgdXNlciAodXNlci1u
ZXR3b3JrIGludGVyZmFjZSBvciBVTkkpLCAoMikgYmV0d2Vlbg0KICAgYWRt
aW5pc3RyYXRpdmUgZG9tYWlucyBvciB3aXRoaW4gYW4gYWRtaW5pc3RyYXRp
dmUgZG9tYWluIGJldHdlZW4NCiAgIGRpZmZlcmVudCBjb250cm9sIGRvbWFp
bnMgKGV4dGVybmFsIG5ldHdvcmstbmV0d29yayBpbnRlcmZhY2Ugb3IgRS0N
CiAgIE5OSSkgYW5kLCAoMykgd2l0aGluIHRoZSBzYW1lIGFkbWluaXN0cmF0
aXZlIGRvbWFpbiBiZXR3ZWVuIGNvbnRyb2wNCiAgIGNvbXBvbmVudHMgKG9y
IHNpbXBseSBjb250cm9sbGVycykgb2YgdGhlIHNhbWUgY29udHJvbCBkb21h
aW4NCiAgIChpbnRlcm5hbCBuZXR3b3JrLW5ldHdvcmsgaW50ZXJmYWNlIG9y
IEktTk5JKS4gVGhlIEFTT04gbW9kZWwgYWxsb3dzDQogICBmb3IgdGhlIHBy
b3RvY29scyB1c2VkIHdpdGhpbiBkaWZmZXJlbnQgY29udHJvbCBkb21haW5z
IHRvIGJlDQogICBkaWZmZXJlbnQ7IGFuZCBmb3IgdGhlIHByb3RvY29sIHVz
ZWQgYmV0d2VlbiBjb250cm9sIGRvbWFpbnMgdG8gYmUNCiAgIGRpZmZlcmVu
dCB0aGFuIHRoZSBwcm90b2NvbHMgdXNlZCB3aXRoaW4gY29udHJvbCBkb21h
aW5zLiBJLU5OSQ0KICAgY29udHJvbCBpbnRlcmZhY2VzIGFyZSBsb2NhdGVk
IGJldHdlZW4gcHJvdG9jb2wgY29udHJvbGxlcnMgd2l0aGluIGENCiAgIGNv
bnRyb2wgZG9tYWluLiBFLU5OSSBjb250cm9sIGludGVyZmFjZXMgYXJlIGxv
Y2F0ZWQgb24gcHJvdG9jb2wNCiAgIGNvbnRyb2xsZXJzIGJldHdlZW4gY29u
dHJvbCBkb21haW5zLg0KDQoNClcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVz
IEp1bHkgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIN
CgwNCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRz
LTAyLnR4dCAgICAgICAgIEZlYnJ1YXJ5IDIwMDQNCg0KDQogICBUaGUgdGVy
bSByb3V0aW5nIGluZm9ybWF0aW9uIHJlZmVycyB0byB0aGUgYWJzdHJhY3Qg
cmVwcmVzZW50YXRpb24NCiAgIG9mIG5ldHdvcmsgcm91dGluZyByZWxhdGVk
IGluZm9ybWF0aW9uIHN1Y2ggYXMgbm9kZSBhbmQgbGluaw0KICAgYXR0cmli
dXRlcyAoc2VlIFNlY3Rpb24gNC41KS4gTm8gcm91dGluZyBpbmZvcm1hdGlv
biBpcyBwYXNzZWQgb3Zlcg0KICAgdGhlIFVOSS4gUm91dGluZyBpbmZvcm1h
dGlvbiBleGNoYW5nZWQgb3ZlciB0aGUgTk5JIGlzIHN1YmplY3QgdG8NCiAg
IHRoZSBwb2xpY3kgY29uc3RyYWludHMgYXQgaW5kaXZpZHVhbCBOTklzLiBU
aGUgcm91dGluZyBpbmZvcm1hdGlvbg0KICAgZXhjaGFuZ2VkIG92ZXIgdGhl
IEUtTk5JIGVuY2Fwc3VsYXRlcyB0aGUgY29tbW9uIHNlbWFudGljcyBvZiB0
aGUNCiAgIGluZGl2aWR1YWwgZG9tYWluIGluZm9ybWF0aW9uIHdoaWxlIGFs
bG93aW5nIGRpZmZlcmVudA0KICAgcmVwcmVzZW50YXRpb24gd2l0aGluIGVh
Y2ggZG9tYWluLg0KDQogICBUaGUgQVNPTiByb3V0aW5nIGFyY2hpdGVjdHVy
ZSBpcyBiYXNlZCBvbiB0aGUgZm9sbG93aW5nIGFzc3VtcHRpb25zOg0KICAg
LSBBIGNhcnJpZXIncyBuZXR3b3JrIGlzIHN1YmRpdmlkZWQgYXMgUm91dGlu
ZyBBcmVhcyAoUkFzKS4gRWFjaCBSQQ0KICAgICBzaGFsbCBiZSB1bmlxdWVs
eSBpZGVudGlmaWFibGUgd2l0aGluIGEgY2FycmllcidzIG5ldHdvcmsgKGku
ZS4NCiAgICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluKS4gUkFzIHBhcnRpdGlv
bmluZyBwcm92aWRlIGZvciByb3V0aW5nDQogICAgIGluZm9ybWF0aW9uIGFi
c3RyYWN0aW9uLCB0aGVyZWJ5IGVuYWJsaW5nIHNjYWxhYmxlIHJvdXRpbmcu
DQogICAtIFJvdXRpbmcgQ29udHJvbGxlcnMgKFJDKSBwcm92aWRlIGZvciB0
aGUgZXhjaGFuZ2Ugb2Ygcm91dGluZw0KICAgICBpbmZvcm1hdGlvbiBiZXR3
ZWVuIGFuZCB3aXRoaW4gYSBSQS4gVGhlIHJvdXRpbmcgaW5mb3JtYXRpb24N
CiAgICAgZXhjaGFuZ2VkIGJldHdlZW4gUkNzIGlzIHN1YmplY3QgdG8gcG9s
aWN5IGNvbnN0cmFpbnRzIGltcG9zZWQgYXQNCiAgICAgcmVmZXJlbmNlIHBv
aW50cyAoRS1OTkkgYW5kIEktTk5JKS4NCiAgIC0gRm9yIGEgUkEsIHRoZSBz
ZXQgb2YgUkNzIGlzIHJlZmVycmVkIHRvIGFzIGEgcm91dGluZyAoY29udHJv
bCkNCiAgICAgZG9tYWluLiBUaGUgUkMgTUFZIHN1cHBvcnQgbW9yZSB0aGFu
IG9uZSByb3V0aW5nIHByb3RvY29sIChpLmUuIGFuDQogICAgIFJDIE1BWSBz
dXBwb3J0IG11bHRpcGxlIFByb3RvY29sIENvbnRyb2xsZXIgKFBDcykpLiBU
aGVyZSBTSE9VTEQNCiAgICAgTk9UIGJlIGFueSBkZXBlbmRlbmNpZXMgb24g
dGhlIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scyB1c2VkLg0KICAgLSBU
aGUgcm91dGluZyBpbmZvcm1hdGlvbiBleGNoYW5nZWQgYmV0d2VlbiByb3V0
aW5nIGRvbWFpbnMgKGkuZS4NCiAgICAgaW50ZXItZG9tYWluKSBpcyBpbmRl
cGVuZGVudCBvZiBib3RoIHRoZSBpbnRyYS1kb21haW4gcm91dGluZw0KICAg
ICBwcm90b2NvbCBhbmQgdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGRpc3Ry
aWJ1dGlvbiBjaG9pY2UocyksIGUuZy4NCiAgICAgY2VudHJhbGl6ZWQsIGZ1
bGx5IGRpc3RyaWJ1dGVkLg0KICAgLSBUaGUgcm91dGluZyBhZGphY2VuY3kg
dG9wb2xvZ3kgKGkuZS4gdGhlIGFzc29jaWF0ZWQgUEMNCiAgICAgY29ubmVj
dGl2aXR5IHRvcG9sb2d5KSBhbmQgdGhlIHRyYW5zcG9ydCBuZXR3b3JrIHRv
cG9sb2d5IFNIQUxMDQogICAgIE5PVCBiZSBhc3N1bWVkIHRvIGJlIGNvbmdy
dWVudC4NCg0KICAgVGhlIGZvbGxvd2luZyBmdW5jdGlvbmFsaXR5IGlzIGV4
cGVjdGVkIGZyb20gR01QTFMgcm91dGluZyB0bw0KICAgaW5zdGFudGlhdGUg
QVNPTiByb3V0aW5nIHJlYWxpemF0aW9uIChzZWUgW0cuNzcxNV0gYW5kIFtH
Ljc3MTUuMV0pOg0KICAgLSBzdXBwb3J0IG11bHRpcGxlIGhpZXJhcmNoaWNh
bCBsZXZlbHMgb2YgUkFzOyB0aGUgbnVtYmVyIG9mDQogICAgIGhpZXJhcmNo
aWNhbCBsZXZlbHMgdG8gYmUgc3VwcG9ydGVkIGlzIHJvdXRpbmcgcHJvdG9j
b2wNCiAgICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQogICAtIHN1cHBv
cnQgaGllcmFyY2hpY2FsIHJvdXRpbmcgaW5mb3JtYXRpb24gZGlzc2VtaW5h
dGlvbiBpbmNsdWRpbmcNCiAgICAgc3VtbWFyaXplZCByb3V0aW5nIGluZm9y
bWF0aW9uDQogICAtIHN1cHBvcnQgZm9yIG11bHRpcGxlIGxpbmtzIGJldHdl
ZW4gbm9kZXMgKGFuZCBiZXR3ZWVuIFJBcykgYW5kIGZvcg0KICAgICBsaW5r
IGFuZCBub2RlIGRpdmVyc2l0eQ0KICAgLSBzdXBwb3J0IGFyY2hpdGVjdHVy
YWwgZXZvbHV0aW9uIGluIHRlcm1zIG9mIHRoZSBudW1iZXIgb2YgbGV2ZWxz
DQogICAgIG9mIGhpZXJhcmNoaWVzLCBhZ2dyZWdhdGlvbiBhbmQgc2VnbWVu
dGF0aW9uIG9mIFJBcw0KICAgLSBzdXBwb3J0IHJvdXRpbmcgaW5mb3JtYXRp
b24gYmFzZWQgb24gYSBjb21tb24gc2V0IG9mIGluZm9ybWF0aW9uDQogICAg
IGVsZW1lbnRzIGFzIGRlZmluZWQgaW4gW0cuNzcxNV0gYW5kIFtHLjc3MTUu
MV0sIGRpdmlkZWQgYmV0d2Vlbg0KICAgICBhdHRyaWJ1dGVzIHBlcnRhaW5p
bmcgdG8gbGlua3MgYW5kIGFic3RyYWN0IG5vZGVzIChlYWNoDQogICAgIHJl
cHJlc2VudGluZyBlaXRoZXIgYSBzdWItbmV0d29yayBvciBzaW1wbHkgYSBu
b2RlKS4gW0cuNzcxNV0NCiAgICAgcmVjb2duaXplcyB0aGF0IHRoZSBtYW5u
ZXIgaW4gd2hpY2ggdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gaXMNCiAgICAg
cmVwcmVzZW50ZWQgYW5kIGV4Y2hhbmdlZCB3aWxsIHZhcnkgd2l0aCB0aGUg
cm91dGluZyBwcm90b2NvbA0KICAgICB1c2VkLg0KDQogICBBbHNvLCB0aGUg
YmVoYXZpb3VyIG9mIEdNUExTIHJvdXRpbmcgaXMgZXhwZWN0ZWQgdG8gYmUg
c3VjaCB0aGF0Og0KICAgLSBpdCBpcyBzY2FsYWJsZSB3aXRoIHJlc3BlY3Qg
dG8gdGhlIG51bWJlciBvZiBsaW5rcywgbm9kZXMgYW5kIFJBcw0KICAgLSBp
biByZXNwb25zZSB0byBhIHJvdXRpbmcgZXZlbnQgKGUuZy4gdG9wb2xvZ3kg
dXBkYXRlLCByZWFjaGFiaWxpdHkNCg0KDQpXLkFsYW5xYXIgZXQgYWwuIC0g
RXhwaXJlcyBKdWx5IDIwMDQgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAzDQoMDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGlu
Zy1yZXF0cy0wMi50eHQgICAgICAgICBGZWJydWFyeSAyMDA0DQoNCg0KICAg
ICB1cGRhdGUpLCBpdCBkZWxpdmVycyBjb252ZXJnZW5jZSBhbmQgZGFtcGlu
ZyBhZ2FpbnN0IGZsYXBwaW5nDQogICAtIGl0IGZ1bGZpbHMgdGhlIG9wZXJh
dGlvbmFsIHNlY3VyaXR5IG9iamVjdGl2ZXMgd2hlcmUgcmVxdWlyZWQNCg0K
NC4gQVNPTiBSZXF1aXJlbWVudHMgZm9yIEdNUExTIFJvdXRpbmcNCg0KICAg
VGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBBU09OIHJvdXRpbmcgY29tcG9uZW50
cyAoc2VlIEFwcGVuZGl4IDIpIGlzDQogICBwcm92aWRlZCBpbiB0ZXJtcyBv
ZiByb3V0aW5nIGZ1bmN0aW9uYWxpdHkuIFRoaXMgZGVzY3JpcHRpb24gaXMg
b25seQ0KICAgY29uY2VwdHVhbDogbm8gcGh5c2ljYWwgcGFydGl0aW9uaW5n
IG9mIHRoZXNlIGZ1bmN0aW9ucyBpcyBpbXBsaWVkLg0KDQogICBUaGUgUm91
dGluZyBDb250cm9sbGVyIChSQykgY29tcG9uZW50cyByZWNlaXZlIHJvdXRp
bmcgaW5mb3JtYXRpb24NCiAgIGZyb20gdGhlaXIgYXNzb2NpYXRlZCBMaW5r
IFJlc291cmNlIE1hbmFnZXIocykgKExSTXMpIHJlZ2FyZGluZyBURQ0KICAg
bGlua3MgYW5kIHN0b3JlIHRoaXMgaW5mb3JtYXRpb24gaW4gdGhlIFJvdXRp
bmcgSW5mb3JtYXRpb24gRGF0YWJhc2UNCiAgIChSREIpLiBUaGUgUkRCIGlz
IHJlcGxpY2F0ZWQgYXQgZWFjaCBSQyB3aXRoaW4gdGhlIHNhbWUgUm91dGlu
ZyBBcmVhDQogICAoUkEpLCBhbmQgTUFZIGNvbnRhaW4gaW5mb3JtYXRpb24g
YWJvdXQgbXVsdGlwbGUgdHJhbnNwb3J0IHBsYW5lDQogICBuZXR3b3JrIGxh
eWVycy4gV2hlbmV2ZXIgdGhlIHN0YXRlIG9mIGEgVEUgbGluayAob3IgY29t
cG9uZW50IGxpbmspDQogICBjaGFuZ2VzLCB0aGUgTFJNIGluZm9ybXMgdGhl
IGNvcnJlc3BvbmRpbmcgUkMsIHdoaWNoIGluIHR1cm4gdXBkYXRlcw0KICAg
aXRzIGFzc29jaWF0ZWQgUkRCLiBJbiBvcmRlciB0byBhc3N1cmUgUkRCIHN5
bmNocm9uaXphdGlvbiwgdGhlIFJDcw0KICAgY28tb3BlcmF0ZSBhbmQgZXhj
aGFuZ2Ugcm91dGluZyBpbmZvcm1hdGlvbi4gSW4gdGhpcyBjb250ZXh0LA0K
ICAgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFJDcyBpcyByZWFsaXplZCB1c2lu
ZyBhIHBhcnRpY3VsYXIgcm91dGluZw0KICAgcHJvdG9jb2wgcmVwcmVzZW50
ZWQgYnkgdGhlIHByb3RvY29sIGNvbnRyb2xsZXIgKFBDKSBjb21wb25lbnQg
YW5kDQogICB0aGUgcHJvdG9jb2wgbWVzc2FnZXMgYXJlIGNvbnZleWVkIG92
ZXIgdGhlIFNpZ25hbGluZyBDb250cm9sDQogICBOZXR3b3JrIChTQ04pLiBU
aGUgUEMgTUFZIGNvbnZleSBpbmZvcm1hdGlvbiBmb3Igb25lIG9yIG1vcmUN
CiAgIHRyYW5zcG9ydCBuZXR3b3JrIGxheWVycy4gTW9yZW92ZXIsIGFzIFtH
NzcxNS4xXSBzdGF0ZXMgYW5kDQogICBpbGx1c3RyYXRlcyBpbiBpdHMgRmln
dXJlIDEsIEFTT04gcm91dGluZyBwcm90b2NvbCByZXF1aXJlbWVudHMNCiAg
IGRlYWxzIGV4Y2x1c2l2ZWx5IHdpdGggdGhlIFBDIHRvIFBDIGNvbW11bmlj
YXRpb24gb2YgdGhlIChSQykNCiAgIHJvdXRpbmcgaW5mb3JtYXRpb247IHRo
ZXJlZm9yZSBhbnkgb3RoZXIgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGFueQ0K
ICAgb3RoZXIgZnVuY3Rpb25hbCBjb21wb25lbnQocykgKGUuZy4gU0MsIExS
TSkgaXMgYWxzbyBvdXRzaWRlIHRoZQ0KICAgc2NvcGUgb2YgdGhpcyBkb2N1
bWVudC4NCg0KICAgTm90ZTogdGhlIFJDIGNhbiBiZSB0aG91Z2h0IG9mIGFz
IHRoZSBmdW5jdGlvbiBwcm9jZXNzaW5nIHRoZSBURQ0KICAgZGF0YWJhc2Ug
cG9wdWxhdGVkIGJ5IHRoZSBsaW5rIGxvY2FsL3JlbW90ZSBjb21wb25lbnQg
YW5kIFRFIGxpbmtzDQogICAoTFJNKSBhbmQgYnkgdGhlIG5ldHdvcmsgd2lk
ZSBURSBsaW5rcyB0aHJvdWdoIHRoZSBQQyB3aGljaA0KICAgcHJvY2Vzc2Vz
IHRoZSBwcm90b2NvbCBzcGVjaWZpYyByb3V0aW5nIGV4Y2hhbmdlcy4gVGhl
IFNDTg0KICAgY29ycmVzcG9uZHMgdG8gdGhlIElQIGNvbnRyb2wgcGxhbmUg
dG9wb2xvZ3kgZW5hYmxpbmcgcm91dGluZw0KICAgZXhjaGFuZ2VzIGJldHdl
ZW4gR01QTFMgY29udHJvbGxlcnMgKGkuZS4gdGhlIHJvdXRpbmcgYWRqYWNl
bmNpZXMpLg0KDQo0LjEgTXVsdGlwbGUgSGllcmFyY2hpY2FsIExldmVscw0K
DQogICBbRy44MDgwXSBpbnRyb2R1Y2VzIHRoZSBjb25jZXB0IG9mIFJvdXRp
bmcgQXJlYSAoUkEpLiBSQXMgcHJvdmlkZQ0KICAgZm9yIHJvdXRpbmcgaW5m
b3JtYXRpb24gYWJzdHJhY3Rpb24sIHRoZXJlYnkgZW5hYmxpbmcgc2NhbGFi
bGUNCiAgIHJvdXRpbmcgaW5mb3JtYXRpb24gcmVwcmVzZW50YXRpb24uIEV4
Y2VwdCBmb3IgdGhlIHNpbmdsZSBSQSBjYXNlLA0KICAgUkFzIGFyZSBoaWVy
YXJjaGljYWxseSBjb250YWluZWQ6IGEgaGlnaGVyIGxldmVsIChwYXJlbnQp
IFJBDQogICBjb250YWlucyBsb3dlciBsZXZlbCAoY2hpbGQpIFJBcyB0aGF0
IGluIHR1cm4gTUFZIGFsc28gY29udGFpbiBSQXMsDQogICBldGMuIFRodXMs
IFJBcyBjb250YWluIFJBcyB0aGF0IHJlY3Vyc2l2ZWx5IGRlZmluZSBzdWNj
ZXNzaXZlDQogICBoaWVyYXJjaGljYWwgcm91dGluZyBsZXZlbHMuDQoNCiAg
IEhvd2V2ZXIsIHRoZSBSQSBjb250YWlubWVudCByZWxhdGlvbnNoaXAgZGVz
Y3JpYmVzIG9ubHkgYW4NCiAgIGFyY2hpdGVjdHVyYWwgaGllcmFyY2hpY2Fs
IG9yZ2FuaXphdGlvbiBvZiBSQXMuIEl0IGRvZXMgbm90IHJlc3RyaWN0DQog
ICB0aGUgcm91dGluZyBwcm90b2NvbCByZWFsaXphdGlvbiAoZS5nLiBPU1BG
IG11bHRpLWFyZWFzLCBwYXRoDQogICBjb21wdXRhdGlvbiwgZXRjLikuIE1v
cmVvdmVyLCB0aGUgcmVhbGl6YXRpb24gb2YgdGhlIHJvdXRpbmcNCiAgIHBh
cmFkaWdtIHRvIHN1cHBvcnQgaGllcmFyY2hpY2FsIHJvdXRpbmcgYW5kIHRo
ZSBudW1iZXIgb2YNCg0KDQoNClcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVz
IEp1bHkgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDQN
CgwNCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRz
LTAyLnR4dCAgICAgICAgIEZlYnJ1YXJ5IDIwMDQNCg0KDQogICBoaWVyYXJj
aGljYWwgbGV2ZWxzIHRvIGJlIHN1cHBvcnRlZCBpcyByb3V0aW5nIHByb3Rv
Y29sIHNwZWNpZmljIGFuZA0KICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp
cyBkb2N1bWVudC4NCg0KICAgQVNPTiByb3V0aW5nIGNvbXBvbmVudHMgYXJl
IGlkZW50aWZpZWQgYnkgdmFsdWVzIHRoYXQgTUFZIGJlIGRyYXduDQogICBm
cm9tIHNldmVyYWwgaWRlbnRpZmllciBzcGFjZXMgKHNlZSBbRy43NzE1LjFd
KS4gVGhlIHVzZSBvZg0KICAgaWRlbnRpZmllcnMgaW4gYSByb3V0aW5nIHBy
b3RvY29sIHJlYWxpemF0aW9uIGlzIGltcGxlbWVudGF0aW9uDQogICBzcGVj
aWZpYyBhbmQgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4N
Cg0KICAgSW4gYSBtdWx0aS1sZXZlbCByb3V0aW5nIGhpZXJhcmNoeSwgaXQg
aXMgbmVjZXNzYXJ5IHRvIGRpc3Rpbmd1aXNoDQogICBhbW9uZyBSQ3Mgd2l0
aGluIGEgbGV2ZWwgYW5kIFJDcyBhdCBkaWZmZXJlbnQgbGV2ZWxzIG9mIHRo
ZSByb3V0aW5nDQogICBoaWVyYXJjaHkuIEJlZm9yZSBhbnkgcGFpciBvZiBS
Q3MgZXN0YWJsaXNoZXMgY29tbXVuaWNhdGlvbiwgdGhleQ0KICAgTVVTVCB2
ZXJpZnkgdGhleSBiZWxvbmcgdG8gdGhlIHNhbWUgUkEgKHNlZSBTZWN0aW9u
IDQuMikuIEEgUkENCiAgIGlkZW50aWZpZXIgKFJBIElEKSBpcyByZXF1aXJl
ZCB0byBwcm92aWRlIHRoZSBzY29wZSB3aXRoaW4gd2hpY2ggdGhlDQogICBS
Q3MgY2FuIGNvbW11bmljYXRlLiBUbyBkaXN0aW5ndWlzaCBiZXR3ZWVuIFJD
cyB3aXRoaW4gdGhlIHNhbWUgUkEsDQogICBhbiBSQyBpZGVudGlmaWVyIChS
QyBJRCkgaXMgcmVxdWlyZWQ7IHRoZSBSQyBJRCBtdXN0IGJlIHVuaXF1ZQ0K
ICAgd2l0aGluIGl0cyBjb250YWluaW5nIFJBLg0KDQogICBBIFJBIHJlcHJl
c2VudHMgYSBwYXJ0aXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgYW5kIGl0cyBp
ZGVudGlmaWVyDQogICAoaS5lLiBSQSBJRCkgaXMgdXNlZCB3aXRoaW4gdGhl
IGNvbnRyb2wgcGxhbmUgYXMgYSByZWZlcmVuY2UgdG8gdGhlDQogICBkYXRh
IHBsYW5lIHBhcnRpdGlvbi4gUkEgSURzIE1BWSBiZSBhc3NvY2lhdGVkIHdp
dGggYSB0cmFuc3BvcnQNCiAgIHBsYW5lIG5hbWUgc3BhY2Ugd2hlcmVhcyBS
QyBJRHMgYXJlIGFzc29jaWF0ZWQgd2l0aCBhIGNvbnRyb2wgcGxhbmUNCiAg
IG5hbWUgc3BhY2UuDQoNCjQuMiBIaWVyYXJjaGljYWwgUm91dGluZyBJbmZv
cm1hdGlvbiBEaXNzZW1pbmF0aW9uDQoNCiAgIFJvdXRpbmcgaW5mb3JtYXRp
b24gY2FuIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIGFkamFjZW50IGxldmVscyBv
ZiB0aGUNCiAgIHJvdXRpbmcgaGllcmFyY2h5IGkuZS4gTGV2ZWwgTisxIGFu
ZCBOLCB3aGVyZSBMZXZlbCBOIHJlcHJlc2VudHMgdGhlDQogICBSQXMgY29u
dGFpbmVkIGJ5IExldmVsIE4rMS4gVGhlIGxpbmtzIGNvbm5lY3RpbmcgUkFz
IE1BWSBiZSB2aWV3ZWQNCiAgIGFzIGV4dGVybmFsIGxpbmtzLCBhbmQgdGhl
IGxpbmtzIHJlcHJlc2VudGluZyBjb25uZWN0aXZpdHkgd2l0aGluIGFuDQog
ICBSQSBNQVkgYmUgdmlld2VkIGFzIGludGVybmFsIGxpbmtzLg0KDQogICBU
aGUgcGh5c2ljYWwgbG9jYXRpb24gb2YgUkNzIGF0IGFkamFjZW50IGxldmVs
cywgdGhlaXIgcmVsYXRpb25zaGlwDQogICBhbmQgdGhlaXIgY29tbXVuaWNh
dGlvbiBwcm90b2NvbCBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcw0K
ICAgZG9jdW1lbnQuIE5vIGFzc3VtcHRpb24gaXMgbWFkZSByZWdhcmRpbmcg
aG93IFJDcyBjb21tdW5pY2F0ZQ0KICAgYmV0d2VlbiBsZXZlbHMuIElmIHJv
dXRpbmcgaW5mb3JtYXRpb24gaXMgZXhjaGFuZ2VkIGJldHdlZW4gYSBSQywN
CiAgIGl0cyBwYXJlbnQsIGFuZCBpdHMgY2hpbGQgUkNzLCBpdCBTSE9VTEQg
aW5jbHVkZSByZWFjaGFiaWxpdHkgYW5kDQogICBNQVkgaW5jbHVkZSAodXBv
biBwb2xpY3kgZGVjaXNpb24pIG5vZGUgYW5kIGxpbmsgdG9wb2xvZ3kuDQoN
CiAgIE11bHRpcGxlIFJDcyB3aXRoaW4gYSBSQSBNQVkgdHJhbnNmb3JtIChm
aWx0ZXIsIHN1bW1hcml6ZSwgZXRjLikgYW5kDQogICB0aGVuIGZvcndhcmQg
aW5mb3JtYXRpb24gdG8gUkNzIGF0IGRpZmZlcmVudCBsZXZlbHMuIEhvd2V2
ZXIgaW4gdGhpcw0KICAgY2FzZSB0aGUgcmVzdWx0aW5nIGluZm9ybWF0aW9u
IGF0IHRoZSByZWNlaXZpbmcgbGV2ZWwgbXVzdCBiZSBzZWxmLQ0KICAgY29u
c2lzdGVudDsgdGhpcyBNQVkgYmUgYWNoaWV2ZWQgdXNpbmcgYSBudW1iZXIg
b2YgbWVjaGFuaXNtcy4NCg0KICAgTm90ZTogdGhlcmUgaXMgbm8gcmVsYXRp
b25zaGlwIGJldHdlZW4gbXVsdGktbGF5ZXIgYW5kIG11bHRpLWxldmVsDQog
ICByb3V0aW5nLiBUaGUgZm9ybWVyIGltcGxpZXMgYSBzaW5nbGUgcm91dGlu
ZyBwcm90b2NvbCBpbnN0YW5jZSBmb3INCiAgIG11bHRpcGxlIHRyYW5zcG9y
dCBzd2l0Y2hpbmcgbGF5ZXJzIHdoZXJlYXMgdGhlIGxhdHRlciBpbXBsaWVz
IGENCiAgIGhpZXJhcmNoaWNhbCByb3V0aW5nIHRvcG9sb2d5IGZvciBvbmUg
dHJhbnNwb3J0IHN3aXRjaGluZyBsYXllci4NCg0KNC4yLjEgQ29tbXVuaWNh
dGlvbiBiZXR3ZWVuIEFkamFjZW50IFJvdXRpbmcgTGV2ZWxzDQoNCiAgIDEu
IFR5cGUgb2YgSW5mb3JtYXRpb24gRXhjaGFuZ2VkDQoNCg0KDQpXLkFsYW5x
YXIgZXQgYWwuIC0gRXhwaXJlcyBKdWx5IDIwMDQgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA1DQoMDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxz
LWFzb24tcm91dGluZy1yZXF0cy0wMi50eHQgICAgICAgICBGZWJydWFyeSAy
MDA0DQoNCg0KICAgICAgVGhlIHR5cGUgb2YgaW5mb3JtYXRpb24gZmxvd2lu
ZyB1cHdhcmQgKGkuZS4gTGV2ZWwgTiB0byBMZXZlbA0KICAgICAgTisxKSBh
bmQgdGhlIGluZm9ybWF0aW9uIGZsb3dpbmcgZG93bndhcmQgKGkuZS4gTGV2
ZWwgTisxIHRvDQogICAgICBMZXZlbCBOKSBhcmUgdXNlZCBmb3Igc2ltaWxh
ciBwdXJwb3NlcywgbmFtZWx5LCB0aGUgZXhjaGFuZ2Ugb2YNCiAgICAgIHJl
YWNoYWJpbGl0eSBpbmZvcm1hdGlvbiBhbmQgc3VtbWFyaXplZCB0b3BvbG9n
eSBpbmZvcm1hdGlvbiB0bw0KICAgICAgYWxsb3cgcm91dGluZyBhY3Jvc3Mg
bXVsdGlwbGUgUkFzLiBUaGUgc3VtbWFyaXphdGlvbiBvZiB0b3BvbG9neQ0K
ICAgICAgaW5mb3JtYXRpb24gbWF5IGltcGFjdCB0aGUgYWNjdXJhY3kgb2Yg
cm91dGluZyBhbmQgTUFZIHJlcXVpcmUNCiAgICAgIGFkZGl0aW9uYWwgcGF0
aCBjYWxjdWxhdGlvbi4NCg0KICAgICAgVGhlIGZvbGxvd2luZyBpbmZvcm1h
dGlvbiBleGNoYW5nZSBhcmUgZXhwZWN0ZWQ6DQogICAgICAtIExldmVsIE4r
MSB2aXNpYmlsaXR5IHRvIExldmVsIE4gcmVhY2hhYmlsaXR5IGFuZCB0b3Bv
bG9neSAob3INCiAgICAgICAgdXB3YXJkIGluZm9ybWF0aW9uIGNvbW11bmlj
YXRpb24pIGFsbG93aW5nIFJDKHMpIGF0IGxldmVsIE4rMQ0KICAgICAgICB0
byBkZXRlcm1pbmUgdGhlIHJlYWNoYWJsZSBlbmRwb2ludHMgZnJvbSBMZXZl
bCBOLg0KICAgICAgLSBMZXZlbCBOIHZpc2liaWxpdHkgdG8gTGV2ZWwgTisx
IHJlYWNoYWJpbGl0eSBhbmQgdG9wb2xvZ3kgKG9yDQogICAgICAgIGRvd253
YXJkIGluZm9ybWF0aW9uIGNvbW11bmljYXRpb24pIGFsbG93aW5nIFJDKHMp
IGluIGFuIFJBIGF0DQogICAgICAgIExldmVsIE4gdG8gZGV2ZWxvcCBwYXRo
cyB0byByZWFjaGFibGUgZW5kcG9pbnRzIG91dHNpZGUgb2YgdGhlDQogICAg
ICAgIFJBLg0KDQogICAyLiBJbnRlcmFjdGlvbnMgYmV0d2VlbiBVcHdhcmQg
YW5kIERvd253YXJkIENvbW11bmljYXRpb24NCg0KICAgICAgV2hlbiBib3Ro
IHVwd2FyZCBhbmQgZG93bndhcmQgaW5mb3JtYXRpb24gZXhjaGFuZ2VzIGNv
bnRhaW4NCiAgICAgIGVuZHBvaW50IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlv
biwgYSBmZWVkYmFjayBsb29wIGNvdWxkDQogICAgICBwb3RlbnRpYWxseSBi
ZSBjcmVhdGVkLiBDb25zZXF1ZW50bHksIHRoZSByb3V0aW5nIHByb3RvY29s
IE1VU1QNCiAgICAgIGluY2x1ZGUgYSBtZXRob2QgdG86DQogICAgICAtIHBy
ZXZlbnQgaW5mb3JtYXRpb24gcHJvcGFnYXRlZCBmcm9tIGEgTGV2ZWwgTisx
IFJBIGludG8gdGhlDQogICAgICAgIExldmVsIE4gUkEgdG8gYmUgcmUtaW50
cm9kdWNlZCBpbnRvIHRoZSBMZXZlbCBOKzEgUkEsIGFuZA0KICAgICAgLSBw
cmV2ZW50IGluZm9ybWF0aW9uIHByb3BhZ2F0ZWQgZnJvbSBhIExldmVsIE4t
MSBSQSBpbnRvIHRoZQ0KICAgICAgICBMZXZlbCBOIFJBIHRvIGJlIHJlLWlu
dHJvZHVjZWQgaW50byB0aGUgTGV2ZWwgTi0xIFJBLg0KDQogICAgICBUaGUg
cm91dGluZyBwcm90b2NvbCBpcyByZXF1aXJlZCB0byBkaWZmZXJlbnRpYXRl
IHRoZSByb3V0aW5nDQogICAgICBpbmZvcm1hdGlvbiBvcmlnaW5hdGVkIGF0
IGEgZ2l2ZW4gbGV2ZWwgUkEgZnJvbSB0aGUgb25lIGRlcml2ZWQNCiAgICAg
IHVzaW5nIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIHJlY2VpdmVkIGZyb20g
aXRzIGV4dGVybmFsIFJBcw0KICAgICAgKHJlZ2FyZGxlc3Mgb2YgdGhlIGxl
dmVsIG9mIHRoZSBjb3JyZXNwb25kaW5nIFJDcykuIFRoaXMgaXMgYQ0KICAg
ICAgbmVjZXNzYXJ5IGNvbmRpdGlvbiB0byBiZSBmdWxmaWxsZWQgYnkgcm91
dGluZyBwcm90b2NvbHMgdG8gYmUNCiAgICAgIGxvb3AgZnJlZS4NCg0KICAg
ICAgQWxzbywgZm9yIEFTT04sIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGV4
Y2hhbmdlIG1heSBnZW5lcmF0ZQ0KICAgICAgdHJhbnNpZW50IGxvb3BzIGF0
IHRoZSBkYXRhIHBsYW5lIGlmIG5vIHJvdXRlIHJlY29yZGluZyBpcyB1c2Vk
DQogICAgICBkdXJpbmcgc2lnbmFsaW5nLiBTbywgYXQgdGhlIGRhdGEgcGxh
bmUsIGl0IGlzIG5vdCB0aGUgcm91dGluZw0KICAgICAgZXhjaGFuZ2UgdGhh
dCBndWFyYW50ZWVzICh0cmFuc2llbnQpIGxvb3AgYXZvaWRhbmNlIGJ1dCB0
aGUNCiAgICAgIHNpZ25hbGluZyBwcm90b2NvbCBieSByZWNvcmRpbmcgdGhl
IHJvdXRlIHVudGlsIHRoZSBub2RlIHdoZXJlDQogICAgICBjb21wdXRhdGlv
biBvY2N1cnMgKGJ5IGV4Y2x1ZGluZyBzZWdtZW50cyBhbHJlYWR5IHRyYXZl
cnNlZCkuDQoNCiAgIDMuIE1ldGhvZCBvZiBDb21tdW5pY2F0aW9uDQoNCiAg
ICAgIFR3byBhcHByb2FjaGVzIGV4aXN0IGZvciBjb21tdW5pY2F0aW9uIGJl
dHdlZW4gTGV2ZWwgTiBhbmQgTisxLg0KDQogICAgICAtIFRoZSBmaXJzdCBh
cHByb2FjaCBwbGFjZXMgYW4gaW5zdGFuY2Ugb2YgYSBMZXZlbCBOIHJvdXRp
bmcNCiAgICAgICAgZnVuY3Rpb24gYW5kIGFuIGluc3RhbmNlIG9mIGEgTGV2
ZWwgTisxIHJvdXRpbmcgZnVuY3Rpb24gaW4gdGhlDQogICAgICAgIHNhbWUg
c3lzdGVtLiBUaGUgY29tbXVuaWNhdGlvbnMgaW50ZXJmYWNlIGlzIHdpdGhp
biBhIHNpbmdsZQ0KICAgICAgICBzeXN0ZW0gYW5kIGlzIHRodXMgbm90IGFu
IG9wZW4gaW50ZXJmYWNlIHN1YmplY3QgdG8NCiAgICAgICAgc3RhbmRhcmRp
emF0aW9uLg0KDQoNCg0KVy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgSnVs
eSAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNg0KDA0K
ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDIu
dHh0ICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCiAgICAgIC0gVGhlIHNl
Y29uZCBhcHByb2FjaCBwbGFjZXMgdGhlIExldmVsIE4gcm91dGluZyBmdW5j
dGlvbiBvbiBhDQogICAgICAgIHNlcGFyYXRlIHN5c3RlbSBmcm9tIHRoZSBM
ZXZlbCBOKzEgcm91dGluZyBmdW5jdGlvbi4gSW4gdGhpcw0KICAgICAgICBj
YXNlLCBhIGNvbW11bmljYXRpb24gaW50ZXJmYWNlIG11c3QgYmUgdXNlZCBi
ZXR3ZWVuIHRoZQ0KICAgICAgICBzeXN0ZW1zIGNvbnRhaW5pbmcgdGhlIHJv
dXRpbmcgZnVuY3Rpb25zIGZvciBkaWZmZXJlbnQgbGV2ZWxzLg0KICAgICAg
ICBUaGlzIGNvbW11bmljYXRpb24gaW50ZXJmYWNlIGFuZCBtZWNoYW5pc21z
IGFyZSBvdXRzaWRlIHRoZQ0KICAgICAgICBzY29wZSBvZiB0aGlzIGRvY3Vt
ZW50Lg0KDQo0LjIuMiBDb25maWd1cmluZyB0aGUgUm91dGluZyBIaWVyYXJj
aHkNCg0KICAgVGhlIFJDIE1VU1Qgc3VwcG9ydCBzdGF0aWMgKGkuZS4gb3Bl
cmF0b3IgYXNzaXN0ZWQpIGFuZCBNQVkgc3VwcG9ydA0KICAgYXV0b21hdGVk
IGNvbmZpZ3VyYXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIGRlc2NyaWJpbmcg
aXRzDQogICByZWxhdGlvbnNoaXAgdG8gcGFyZW50IGFuZCBpdHMgY2hpbGQg
d2l0aGluIHRoZSBoaWVyYXJjaGljYWwgcm91dGluZw0KICAgc3RydWN0dXJl
IChpbmNsdWRpbmcgUkEgSUQgYW5kIFJDIElEKS4gV2hlbiBhcHBsaWVkIHJl
Y3Vyc2l2ZWx5LCB0aGUNCiAgIHdob2xlIGhpZXJhcmNoeSBpcyB0aHVzIGNv
bmZpZ3VyZWQuDQoNCjQuMi4zIENvbmZpZ3VyaW5nIFJDIEFkamFjZW5jaWVz
DQoNCiAgIFRoZSBSQyBNVVNUIHN1cHBvcnQgc3RhdGljIChpLmUuIG9wZXJh
dG9yIGFzc2lzdGVkKSBhbmQgTUFZIHN1cHBvcnQNCiAgIGF1dG9tYXRlZCBj
b25maWd1cmF0aW9uIG9mIHRoZSBpbmZvcm1hdGlvbiBkZXNjcmliaW5nIGl0
cyBjb250cm9sDQogICBhZGphY2VuY2llcyB0byBvdGhlciBSQ3Mgd2l0aGlu
IGEgUkEuIFRoZSByb3V0aW5nIHByb3RvY29sIFNIT1VMRA0KICAgc3VwcG9y
dCBhbGwgdGhlIHR5cGVzIG9mIFJDIGFkamFjZW5jaWVzIGRlc2NyaWJlZCBp
biBTZWN0aW9uIDkgb2YNCiAgIFtHLjc3MTVdLiBUaGUgbGF0dGVyIGluY2x1
ZGVzIGNvbmdydWVudCB0b3BvbG9neSAod2l0aCBkaXN0cmlidXRlZA0KICAg
UkMpIGFuZCBodWJiZWQgdG9wb2xvZ3kgKHdpdGggZGVzaWduYXRlZCBSQyku
DQoNCjQuMyBFdm9sdXRpb24NCg0KICAgVGhlIGNvbnRhaW5tZW50IHJlbGF0
aW9uc2hpcHMgb2YgUkFzIE1BWSBjaGFuZ2UsIG1vdGl2YXRlZCBieSBldmVu
dHMNCiAgIHN1Y2ggYXMgbWVyZ2VycywgYWNxdWlzaXRpb25zLCBhbmQgZGl2
ZXN0aXR1cmVzLg0KDQogICBUaGUgcm91dGluZyBwcm90b2NvbCBTSE9VTEQg
YmUgY2FwYWJsZSBvZiBzdXBwb3J0aW5nIGFyY2hpdGVjdHVyYWwNCiAgIGV2
b2x1dGlvbiBpbiB0ZXJtcyBvZiBudW1iZXIgb2YgaGllcmFyY2hpY2FsIGxl
dmVscywgYXMgd2VsbCBhcw0KICAgYWdncmVnYXRpb24gYW5kIHNlZ21lbnRh
dGlvbiBvZiBSQXMuIFJBIElEcyB1bmlxdWVuZXNzIHdpdGhpbiBhbg0KICAg
YWRtaW5pc3RyYXRpdmUgZG9tYWluIE1BWSBmYWNpbGl0YXRlIHRoZXNlIG9w
ZXJhdGlvbnMuIFRoZSByb3V0aW5nDQogICBwcm90b2NvbCBpcyBub3QgZXhw
ZWN0ZWQgdG8gYXV0b21hdGljYWxseSBpbml0aWF0ZSBhbmQvb3IgZXhlY3V0
ZQ0KICAgdGhlc2Ugb3BlcmF0aW9ucy4NCg0KNC40IE11bHRpcGxlIExpbmtz
IGJldHdlZW4gTm9kZXMgYW5kIFJBcw0KDQogICBTZWUgU2VjdGlvbiA0LjUu
MQ0KDQo0LjUgUm91dGluZyBBdHRyaWJ1dGVzDQoNCiAgIFJvdXRpbmcgZm9y
IHRyYW5zcG9ydCBuZXR3b3JrcyBpcyBwZXJmb3JtZWQgb24gYSBwZXIgbGF5
ZXIgYmFzaXMsDQogICB3aGVyZSB0aGUgcm91dGluZyBwYXJhZGlnbXMgTUFZ
IGRpZmZlciBhbW9uZyBsYXllcnMgYW5kIHdpdGhpbiBhDQogICBsYXllci4g
Tm90IGFsbCBlcXVpcG1lbnQgc3VwcG9ydCB0aGUgc2FtZSBzZXQgb2YgdHJh
bnNwb3J0IGxheWVycyBvcg0KICAgdGhlIHNhbWUgZGVncmVlIG9mIGNvbm5l
Y3Rpb24gZmxleGliaWxpdHkgYXQgYW55IGdpdmVuIGxheWVyLiBBDQogICBz
ZXJ2ZXIgbGF5ZXIgdHJhaWwgbWF5IHN1cHBvcnQgdmFyaW91cyBjbGllbnRz
LCBpbnZvbHZpbmcgZGlmZmVyZW50DQogICBhZGFwdGF0aW9uIGZ1bmN0aW9u
cy4gQWRkaXRpb25hbGx5LCBlcXVpcG1lbnQgbWF5IHN1cHBvcnQgdmFyaWFi
bGUNCiAgIGFkYXB0YXRpb24gZnVuY3Rpb25hbGl0eSwgd2hlcmVieSBhIHNp
bmdsZSBzZXJ2ZXIgbGF5ZXIgdHJhaWwNCiAgIGR5bmFtaWNhbGx5IHN1cHBv
cnRzIGRpZmZlcmVudCBtdWx0aXBsZXhpbmcgc3RydWN0dXJlcy4gQXMgYSBy
ZXN1bHQsDQogICByb3V0aW5nIGluZm9ybWF0aW9uIE1BWSBpbmNsdWRlIGxh
eWVyIHNwZWNpZmljLCBsYXllciBpbmRlcGVuZGVudCwNCiAgIGFuZCBjbGll
bnQvc2VydmVyIGFkYXB0YXRpb24gaW5mb3JtYXRpb24uDQoNCg0KVy5BbGFu
cWFyIGV0IGFsLiAtIEV4cGlyZXMgSnVseSAyMDA0ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgNw0KDA0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBs
cy1hc29uLXJvdXRpbmctcmVxdHMtMDIudHh0ICAgICAgICAgRmVicnVhcnkg
MjAwNA0KDQoNCjQuNS4xIFRheG9ub215IG9mIEF0dHJpYnV0ZXMNCg0KICAg
QXR0cmlidXRlcyBjYW4gYmUgb3JnYW5pemVkIGFjY29yZGluZyB0byB0aGUg
Zm9sbG93aW5nIGNhdGVnb3JpZXM6DQoNCiAgIC0gTm9kZSByZWxhdGVkIG9y
IGxpbmsgcmVsYXRlZA0KDQogICAtIFByb3Zpc2lvbmVkLCBuZWdvdGlhdGVk
IG9yIGF1dG9tYXRpY2FsbHkgY29uZmlndXJlZA0KDQogICAtIEluaGVyaXRl
ZCBvciBsYXllciBzcGVjaWZpYyAoY2xpZW50IGxheWVycyBjYW4gaW5oZXJp
dCBzb21lDQogICAgIGF0dHJpYnV0ZXMgZnJvbSB0aGUgc2VydmVyIGxheWVy
IHdoaWxlIG90aGVyIGF0dHJpYnV0ZXMgbGlrZQ0KICAgICBMaW5rIENhcGFj
aXR5IGFyZSBzcGVjaWZpZWQgYnkgbGF5ZXIpLg0KDQogICAoQ29tcG9uZW50
KSBsaW5rIGF0dHJpYnV0ZXMgY2FuIGJlIHN0YXRpY2FsbHkgb3IgYXV0b21h
dGljYWxseQ0KICAgY29uZmlndXJlZCBmb3IgZWFjaCB0cmFuc3BvcnQgbmV0
d29yayBsYXllci4gVGhpcyBtYXkgbGVhZCB0bw0KICAgdW5uZWNlc3Nhcnkg
cmVwZXRpdGlvbi4gSGVuY2UsIHRoZSBpbmhlcml0YW5jZSBwcm9wZXJ0eSBv
Zg0KICAgYXR0cmlidXRlcyBjYW4gYWxzbyBiZSB1c2VkIHRvIG9wdGltaXpl
IHRoZSBjb25maWd1cmF0aW9uIHByb2Nlc3MuDQoNCiAgIFRFIGxpbmtzIGFy
ZSBjb25maWd1cmVkIHRocm91Z2ggZ3JvdXBpbmcgb2YgY29tcG9uZW50IGxp
bmtzLg0KICAgR3JvdXBpbmcgTUFZIGJlIGJhc2VkIG9uIGRpZmZlcmVudCBs
aW5rIGF0dHJpYnV0ZXMgKGUuZy4sIFNSTEcNCiAgIGluZm9ybWF0aW9uLCBs
aW5rIHdlaWdodCwgZXRjKS4NCg0KICAgVHdvIFJBcyBtYXkgYmUgbGlua2Vk
IGJ5IG9uZSBvciBtb3JlIFRFIGxpbmtzLiBNdWx0aXBsZSBURSBsaW5rcyBt
YXkNCiAgIGJlIHJlcXVpcmVkIHdoZW4gY29tcG9uZW50IGxpbmtzIGFyZSBu
b3QgZXF1aXZhbGVudCBmb3Igcm91dGluZw0KICAgcHVycG9zZXMgd2l0aCBy
ZXNwZWN0IHRvIHRoZSBSQXMgdGhleSBhcmUgYXR0YWNoZWQgdG8sIG9yIHRv
IHRoZQ0KICAgY29udGFpbmluZyBSQSwgb3Igd2hlbiBzbWFsbGVyIGdyb3Vw
aW5ncyBhcmUgcmVxdWlyZWQuDQoNCjQuNS4yIENvbW1vbmx5IEFkdmVydGlz
ZWQgSW5mb3JtYXRpb24NCg0KICAgQWR2ZXJ0aXNlbWVudHMgTUFZIGNvbnRh
aW4gdGhlIGZvbGxvd2luZyBjb21tb24gc2V0IG9mIGluZm9ybWF0aW9uDQog
ICByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhleSBhcmUgbGluayBvciBub2Rl
IHJlbGF0ZWQ6DQogICAtIFJBIElEIG9mIHdoaWNoIHRoZSBhZHZlcnRpc2Vt
ZW50IGlzIGJvdW5kZWQNCiAgIC0gUkMgSUQgb2YgdGhlIGVudGl0eSBnZW5l
cmF0aW5nIHRoZSBhZHZlcnRpc2VtZW50DQogICAtIEluZm9ybWF0aW9uIHRv
IHVuaXF1ZWx5IGlkZW50aWZ5IGFkdmVydGlzZW1lbnRzDQogICAtIEluZm9y
bWF0aW9uIHRvIGRldGVybWluZSB3aGV0aGVyIGFuIGFkdmVydGlzZW1lbnQg
aGFzIGJlZW4gdXBkYXRlZA0KICAgLSBJbmZvcm1hdGlvbiB0byBpbmRpY2F0
ZSB3aGVuIGFuIGFkdmVydGlzZW1lbnQgaGFzIGJlZW4gZGVyaXZlZA0KICAg
ICBmcm9tIGEgc291cmNlIGV4dGVybmFsIHRvIHRoZSByb3V0aW5nIGFyZWEN
Cg0KNC41LjMgTm9kZSBBdHRyaWJ1dGVzDQoNCiAgIEFsbCBub2RlcyBiZWxv
bmcgdG8gYSBSQSwgaGVuY2UgdGhlIFJBIElEIGNhbiBiZSBjb25zaWRlcmVk
IGFuDQogICBhdHRyaWJ1dGUgb2YgYWxsIG5vZGVzLiBHaXZlbiB0aGF0IG5v
IGRpc3RpbmN0aW9uIGlzIG1hZGUgYmV0d2Vlbg0KICAgYWJzdHJhY3Qgbm9k
ZXMgYW5kIHRob3NlIHRoYXQgY2Fubm90IGJlIGRlY29tcG9zZWQgYW55IGZ1
cnRoZXIsIHRoZQ0KICAgc2FtZSBhdHRyaWJ1dGVzIE1BWSBiZSB1c2VkIGZv
ciB0aGVpciBhZHZlcnRpc2VtZW50Lg0KDQogICBUaGUgZm9sbG93aW5nIE5v
ZGUgQXR0cmlidXRlcyBhcmUgZGVmaW5lZDoNCg0KICAgICAgIEF0dHJpYnV0
ZSAgICAgICAgQ2FwYWJpbGl0eSAgICAgIFVzYWdlDQogICAgICAgLS0tLS0t
LS0tLS0gICAgICAtLS0tLS0tLS0tLSAgICAgLS0tLS0tLS0tDQogICAgICAg
Tm9kZSBJRCAgICAgICAgICBSRVFVSVJFRCAgICAgICAgUkVRVUlSRUQNCiAg
ICAgICBSZWFjaGFiaWxpdHkgICAgIFJFUVVJUkVEICAgICAgICBPUFRJT05B
TA0KDQogICAgICAgICAgICAgICAgVGFibGUgMS4gTm9kZSBBdHRyaWJ1dGVz
DQoNCg0KVy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgSnVseSAyMDA0ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOA0KDA0KZHJhZnQtaWV0
Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDIudHh0ICAgICAg
ICAgRmVicnVhcnkgMjAwNA0KDQoNCiAgIFJlYWNoYWJpbGl0eSBpbmZvcm1h
dGlvbiBkZXNjcmliZXMgdGhlIHNldCBvZiBlbmRwb2ludHMgdGhhdCBhcmUN
CiAgIHJlYWNoYWJsZSBieSB0aGUgYXNzb2NpYXRlZCBub2RlLiBJdCBNQVkg
YmUgYWR2ZXJ0aXNlZCBhcyBhIHNldCBvZg0KICAgYXNzb2NpYXRlZCBhZGRy
ZXNzIHByZWZpeGVzIG9yIGEgc2V0IG9mIGFzc29jaWF0ZWQgVEUgbGluayBJ
RHMsDQogICBjb25zaXN0ZW50bHkgYXNzaWduZWQgd2l0aGluIGFuIGFkbWlu
aXN0cmF0aXZlIGRvbWFpbi4NCg0KICAgTm90ZTogbm8gZGlzdGluY3Rpb24g
aXMgbWFkZSBiZXR3ZWVuIG5vZGVzIHRoYXQgbWF5IGhhdmUgZnVydGhlcg0K
ICAgaW50ZXJuYWwgZGV0YWlscyAoaS5lLiwgYWJzdHJhY3Qgbm9kZXMpIGFu
ZCB0aG9zZSB0aGF0IGNhbm5vdCBiZQ0KICAgZGVjb21wb3NlZCBhbnkgZnVy
dGhlci4NCg0KNC41LjQgTGluayBBdHRyaWJ1dGVzDQoNCiAgIFRoZSBmb2xs
b3dpbmcgTGluayBBdHRyaWJ1dGVzIGFyZSBkZWZpbmVkOg0KDQogICAgICAg
TGluayBBdHRyaWJ1dGUgICAgICAgICAgICAgICAgICAgQ2FwYWJpbGl0eSAg
ICAgIFVzYWdlDQogICAgICAgLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAg
ICAgICAgLS0tLS0tLS0tLS0gICAgIC0tLS0tLS0tLQ0KICAgICAgIExvY2Fs
IFRFIGxpbmsgSUQgICAgICAgICAgICAgICAgIFJFUVVJUkVEICAgICAgICBS
RVFVSVJFRA0KICAgICAgIFJlbW90ZSBURSBsaW5rIElEICAgICAgICAgICAg
ICAgIFJFUVVJUkVEICAgICAgICBSRVFVSVJFRA0KICAgICAgIFRFIExpbmsg
Q2hhcmFjdGVyaXN0aWNzICAgICAgICAgIFRhYmxlIDMNCg0KICAgICAgICAg
ICAgICAgIFRhYmxlIDIuIExpbmsgQXR0cmlidXRlcw0KDQogICBUaGUgVEUg
bGluayBJRCBtdXN0IGJlIHN1ZmZpY2llbnQgdG8gdW5pcXVlbHkgaWRlbnRp
ZnkgdGhlDQogICBjb3JyZXNwb25kaW5nIHRyYW5zcG9ydCBwbGFuZSByZXNv
dXJjZSB0YWtpbmcgaW50byBhY2NvdW50DQogICBzZXBhcmF0aW9uIG9mIGRh
dGEgYW5kIGNvbnRyb2wgcGxhbmVzLiBUaGUgVEUgbGluayBJRCBmb3JtYXQg
aXMNCiAgIHJvdXRpbmcgcHJvdG9jb2wgc3BlY2lmaWMuDQoNCiAgIE5vdGU6
IHdoZW4gdGhlIHJlbW90ZSBlbmQgb2YgYSBURSBsaW5rIGlzIGxvY2F0ZWQg
b3V0c2lkZSBvZiB0aGUgUkEsDQogICB0aGUgcmVtb3RlIFRFIGxpbmsgSUQg
aXMgT1BUSU9OQUwuDQoNCiAgIFRoZSBmb2xsb3dpbmcgVEUgbGluayBjaGFy
YWN0ZXJpc3RpYyBhdHRyaWJ1dGVzIGFyZSBkZWZpbmVkOg0KDQogICAtIFNp
Z25hbCBUeXBlOiBUaGlzIGlkZW50aWZpZXMgdGhlIGNoYXJhY3RlcmlzdGlj
IGluZm9ybWF0aW9uIG9mIHRoZQ0KICAgICBsYXllciBuZXR3b3JrLg0KDQog
ICAtIExpbmsgV2VpZ2h0OiBUaGUgbWV0cmljIGluZGljYXRpbmcgdGhlIHJl
bGF0aXZlIGRlc2lyYWJpbGl0eSBvZiBhDQogICAgIHBhcnRpY3VsYXIgbGlu
ayBvdmVyIGFub3RoZXIgZS5nLiBkdXJpbmcgcGF0aCBjb21wdXRhdGlvbi4N
Cg0KICAgLSBSZXNvdXJjZSBDbGFzczogVGhpcyBjb3JyZXNwb25kcyB0byB0
aGUgc2V0IG9mIGFkbWluaXN0cmF0aXZlDQogICAgIGdyb3VwcyBhc3NpZ25l
ZCBieSB0aGUgb3BlcmF0b3IgdG8gdGhpcyBsaW5rLiBBIGxpbmsgTUFZIGJl
bG9uZyB0bw0KICAgICB6ZXJvLCBvbmUgb3IgbW9yZSBhZG1pbmlzdHJhdGl2
ZSBncm91cHMuDQoNCiAgIC0gQ29ubmVjdGlvbiBUeXBlczogVGhpcyBhbGxv
d3MgaWRlbnRpZmljYXRpb24gb2Ygd2hldGhlciB0aGUgbG9jYWwNCiAgICAg
Y29tcG9uZW50IGxpbmsgaXMgYXQgYSBib3JkZXIgb3Igd2l0aGluIGFuIExT
UCByZWdpb24gKHNlZSBbSElFUl0pDQoNCiAgIC0gTGluayBDYXBhY2l0eTog
VGhpcyBwcm92aWRlcyB0aGUgc3VtIG9mIHRoZSBhdmFpbGFibGUgYW5kDQog
ICAgIHBvdGVudGlhbCBiYW5kd2lkdGggY2FwYWNpdHkgZm9yIGEgcGFydGlj
dWxhciBuZXR3b3JrIHRyYW5zcG9ydA0KICAgICBsYXllci4gT3RoZXIgY2Fw
YWNpdHkgbWVhc3VyZXMgTUFZIGJlIGZ1cnRoZXIgY29uc2lkZXJlZC4NCg0K
ICAgLSBMaW5rIEF2YWlsYWJpbGl0eTogVGhpcyByZXByZXNlbnRzIHRoZSBz
dXJ2aXZhYmlsaXR5IGNhcGFiaWxpdHkNCiAgICAgc3VjaCBhcyB0aGUgcHJv
dGVjdGlvbiB0eXBlIGFzc29jaWF0ZWQgd2l0aCB0aGUgbGluay4NCg0KICAg
LSBEaXZlcnNpdHkgU3VwcG9ydDogVGhpcyByZXByZXNlbnRzIGRpdmVyc2l0
eSBpbmZvcm1hdGlvbiBzdWNoIGFzDQoNCg0KVy5BbGFucWFyIGV0IGFsLiAt
IEV4cGlyZXMgSnVseSAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgOQ0KDA0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRp
bmctcmVxdHMtMDIudHh0ICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCiAg
ICAgdGhlIFNSTEcgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBs
aW5rLg0KDQogICAtIExvY2FsIEFkYXB0YXRpb24gU3VwcG9ydDogVGhpcyBp
bmRpY2F0ZXMgdGhlIHNldCBvZiBjbGllbnQgbGF5ZXINCiAgICAgYWRhcHRh
dGlvbnMgc3VwcG9ydGVkIGJ5IHRoZSBsb2NhbCBjb21wb25lbnQgbGluayBh
c3NvY2lhdGVkIHRvDQogICAgIHRoZSBsb2NhbCBURSBsaW5rLiBUaGlzIGNh
biBvbmx5IGV4aXN0IHdoZW4gdGhlICJMb2NhbCBDb25uZWN0aW9uDQogICAg
IFR5cGUiIGluZGljYXRlcyBjcm9zc2luZyBvZiBhbiBMU1AgUmVnaW9uIG9y
IGNhbiBiZSBmbGV4aWJseQ0KICAgICBhc3NpZ25lZCB0byBiZSBhdCBhIGJv
cmRlciBvciB3aXRoaW4gYW4gTFNQIHJlZ2lvbiAoc2VlIFtISUVSXSkuDQoN
CiAgICAgICAgVEUgbGluayBDaGFyYWN0ZXJpc3RpY3MgICAgICAgICBDYXBh
YmlsaXR5ICAgICAgVXNhZ2UNCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0gICAgICAgICAtLS0tLS0tLS0tICAgICAgLS0tLS0tLS0tDQogICAg
ICAgIFNpZ25hbCBUeXBlICAgICAgICAgICAgICAgICAgICAgUkVRVUlSRUQg
ICAgICAgIE9QVElPTkFMDQogICAgICAgIExpbmsgV2VpZ2h0ICAgICAgICAg
ICAgICAgICAgICAgUkVRVUlSRUQgICAgICAgIE9QVElPTkFMDQogICAgICAg
IFJlc291cmNlIENsYXNzICAgICAgICAgICAgICAgICAgUkVRVUlSRUQgICAg
ICAgIE9QVElPTkFMDQogICAgICAgIExvY2FsIENvbm5lY3Rpb24gVHlwZXMg
ICAgICAgICAgUkVRVUlSRUQgICAgICAgIE9QVElPTkFMDQogICAgICAgIExp
bmsgQ2FwYWNpdHkgICAgICAgICAgICAgICAgICAgUkVRVUlSRUQgICAgICAg
IE9QVElPTkFMDQogICAgICAgIExpbmsgQXZhaWxhYmlsaXR5ICAgICAgICAg
ICAgICAgT1BUSU9OQUwgICAgICAgIE9QVElPTkFMDQogICAgICAgIERpdmVy
c2l0eSBTdXBwb3J0ICAgICAgICAgICAgICAgT1BUSU9OQUwgICAgICAgIE9Q
VElPTkFMDQogICAgICAgIExvY2FsIEFkYXB0YXRpb24gc3VwcG9ydCAgICAg
ICAgT1BUSU9OQUwgICAgICAgIE9QVElPTkFMDQoNCiAgICAgICAgICAgICAg
IFRhYmxlIDMuIFRFIGxpbmsgQ2hhcmFjdGVyaXN0aWNzDQoNCiAgIE5vdGU6
IHNlcGFyYXRlIGFkdmVydGlzZW1lbnRzIG9mIGxheWVyIHNwZWNpZmljIGF0
dHJpYnV0ZXMgTUFZIGJlDQogICBjaG9zZW4uIEhvd2V2ZXIgdGhpcyBtYXkg
bGVhZCB0byB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlvbi4gVGhpcyBjYW4NCiAg
IGJlIGF2b2lkZWQgdXNpbmcgdGhlIGluaGVyaXRhbmNlIHByb3BlcnR5LCBz
byB0aGF0IGF0dHJpYnV0ZXMNCiAgIGRlcml2YWJsZSBmcm9tIHRoZSBsb2Nh
bCBhZGFwdGF0aW9uIGluZm9ybWF0aW9uIGRvIG5vdCBuZWVkIHRvIGJlDQog
ICBhZHZlcnRpc2VkLg0KDQo1LiBCYWNrd2FyZCBDb21wYXRpYmlsaXR5DQoN
CiAgIEFueSBwYXJ0aWN1bGFyIHJlYWxpemF0aW9uIG9mIHRoZSBBU09OIHJv
dXRpbmcgcmVxdWlyZW1lbnRzIE1VU1QgYmUNCiAgIGJhY2t3YXJkIGNvbXBh
dGlibGUgd2l0aCB0aGUgY29uc2lkZXJlZCByb3V0aW5nIHByb3RvY29sKHMp
Lg0KDQogICBCYWNrd2FyZCBjb21wYXRpYmlsaXR5IG1lYW5zIHRoYXQgYXQg
YW55IGxldmVsIG9mIHRoZSByb3V0aW5nDQogICBoaWVyYXJjaHksIG5vZGVz
LCBzb21lIG9mIHdoaWNoIHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50cyBkZXNj
cmliZWQNCiAgIGluIHRoaXMgZG9jdW1lbnQsIGFuZCBzb21lIG9mIHdoaWNo
IGRvIG5vdCwgTVVTVCBzdGlsbCBiZSBjYXBhYmxlIHRvDQogICBvcGVyYXRl
IGFzIG1hbmRhdGVkIGJ5IHRoZSBPU1BGLCBJUy1JUywgYW5kL29yIElEUiBJ
RVRGIFdHIGFuZCB0aGVpcg0KICAgY29ycmVzcG9uZGluZyBHTVBMUyBleHRl
bnNpb25zIChhcyBtYW5kYXRlZCBieSB0aGUgQ0NBTVAgSUVURiBXRykuDQoN
CiAgIEFkZGl0aW9uYWxseSwgbm9kZXMgKHRoYXQgZG8gbm90IHN1cHBvcnQg
dGhlc2UgcmVxdWlyZW1lbnRzIGFuZCkgYXJlDQogICBtYWRlIHBhcnQgb2Yg
YSBtdWx0aS1sZXZlbCByb3V0aW5nIGhpZXJhcmNoeSBmcm9tIHRoZWlyIGNv
bnRhaW5pbmcNCiAgIFJBKHMpLCBtdXN0IGJlIGNhcGFibGUgb2Y6DQogICAt
IHJlamVjdGluZyAob3IgaWdub3JpbmcpIGFueSBpbmNvbWluZyByb3V0aW5n
IGluZm9ybWF0aW9uIHRoYXQNCiAgICAgd291bGQgYmUgYWRkcmVzc2VkIHRv
IHRoZW0gaW4gYSB3YXkgdGhhdCBpcyBub3QgZGV0cmltZW50YWwgdG8gdGhl
DQogICAgIG5ldHdvcmsgYXMgYSB3aG9sZQ0KICAgLSBjb21tdW5pY2F0aW5n
IChhdCBhIGdpdmVuIGxldmVsKSB3aXRoIGFueSBvdGhlciBub2RlIGxvY2F0
ZWQNCiAgICAgYXQgdGhlIHNhbWUgbGV2ZWwgYW5kIHRoYXQgaW1wbGVtZW50
cyB0aGVzZSByZXF1aXJlbWVudHMNCiAgIFRoaXMgYXNzdW1lcyB0aGF0IHN1
Y2ggbm9kZXMgZG8gbm90IGNvbW11bmljYXRlIGRpcmVjdGx5IGVpdGhlciB3
aXRoDQogICBsb3dlciBvciB1cHBlciBsZXZlbCBub2Rlcy4NCg0KICAgTm90
ZTogYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIHJvdXRpbmcgcHJvdG9j
b2xzIGlzIGEgcHJvdG9jb2wNCiAgIHJlcXVpcmVtZW50IGRlZmluZWQgaW4g
dGhlIElFVEYgY29udGV4dC4NCg0KDQoNClcuQWxhbnFhciBldCBhbC4gLSBF
eHBpcmVzIEp1bHkgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMTANCgwNCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5n
LXJlcXRzLTAyLnR4dCAgICAgICAgIEZlYnJ1YXJ5IDIwMDQNCg0KDQo2LiBT
ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBBU09OIHJvdXRpbmcgcHJv
dG9jb2wgTVVTVCBkZWxpdmVyIHRoZSBvcGVyYXRpb25hbCBzZWN1cml0eQ0K
ICAgb2JqZWN0aXZlcyB3aGVyZSByZXF1aXJlZC4NCg0KNy4gQ29uY2x1c2lv
bnMNCg0KICAgVGhpcyBzZWN0aW9uIGNhcHR1cmVzIGZyb20gdGhlIGlkZW50
aWZpZWQgQVNPTiByb3V0aW5nIHJlcXVpcmVtZW50cw0KICAgdGhlIG1pc3Np
bmcgY2FwYWJpbGl0aWVzIGZyb20gdGhlIEdNUExTIHJvdXRpbmcgcHJvdG9j
b2xzIChlLmcuDQogICBPU1BGLCBJUy1JUykuDQoNCiAgIFRoZSBHTVBMUyBy
b3V0aW5nIHByb3RvY29sIGlzIHJlcXVpcmVkIHRvIHN1cHBvcnQgbXVsdGlw
bGUNCiAgIGhpZXJhcmNoaWNhbCBsZXZlbHMgb2YgUkFzIGFuZCBoaWVyYXJj
aGljYWwgcm91dGluZyBpbmZvcm1hdGlvbg0KICAgZGlzc2VtaW5hdGlvbiBp
bmNsdWRpbmcgc3VtbWFyaXplZCByb3V0aW5nIGluZm9ybWF0aW9uLiBIb3dl
dmVyLCB0aGUNCiAgIG51bWJlciBvZiBoaWVyYXJjaGljYWwgbGV2ZWxzIHRv
IGJlIHN1cHBvcnRlZCBpcyByb3V0aW5nIHByb3RvY29sDQogICBpbXBsZW1l
bnRhdGlvbiBzcGVjaWZpYy4gVGhpcyBpbXBsaWVzIHRoYXQgdGhlIEdNUExT
IHJvdXRpbmcNCiAgIHByb3RvY29sIG11c3QgZGVsaXZlcjoNCiAgIC0gcHJv
Y2Vzc2luZyBvZiByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBiZXR3
ZWVuIGFkamFjZW50DQogICAgIGxldmVscyBvZiB0aGUgcm91dGluZyBoaWVy
YXJjaHkgKGkuZS4gTGV2ZWwgTisxIGFuZCBOKSBpbmNsdWRpbmcNCiAgICAg
cmVhY2hhYmlsaXR5IGFuZCB1cG9uIHBvbGljeSBkZWNpc2lvbiBzdW1tYXJp
emVkIHRvcG9sb2d5DQogICAgIGluZm9ybWF0aW9uDQogICAtIHdoZW4gbXVs
dGlwbGUgUkNzIHdpdGhpbiBhIFJBIHRyYW5zZm9ybSAoZmlsdGVyLCBzdW1t
YXJpemUsIGV0Yy4pDQogICAgIGFuZCB0aGVuIGZvcndhcmQgaW5mb3JtYXRp
b24gdG8gUkMocykgYXQgZGlmZmVyZW50IGxldmVscyB0aGF0IHRoZQ0KICAg
ICByZXN1bHRpbmcgaW5mb3JtYXRpb24gYXQgdGhlIHJlY2VpdmluZyBsZXZl
bCBpcyBzZWxmLWNvbnNpc3RlbnQNCiAgIC0gYSBtZWNoYW5pc20gdG8gcHJl
dmVudCByZS1pbnRyb2R1Y3Rpb24gb2YgaW5mb3JtYXRpb24gcHJvcGFnYXRl
ZA0KICAgICBpbnRvIHRoZSBMZXZlbCBOIFJBIGJhY2sgdG8gdGhlIGV4dGVy
bmFsIGxldmVsIFJBIGZyb20gd2hpY2ggdGhpcw0KICAgICBpbmZvcm1hdGlv
biBoYXMgYmVlbiBpbml0aWFsbHkgcmVjZWl2ZWQuIEl0IGlzIHRodXMgZXhw
ZWN0ZWQgdGhhdA0KICAgICBhZHZlcnRpc2VtZW50cyB3aWxsIGluY2x1ZGUg
aW5mb3JtYXRpb24gd2hlbiB0aGV5IGhhdmUgYmVlbg0KICAgICBkZXJpdmVk
IGZyb20gYSBzb3VyY2UgZXh0ZXJuYWwgdG8gdGhlIFJBLiBOb3RlIHRoYXQg
ZXhpc3RpbmcNCiAgICAgcm91dGluZyBwcm90b2NvbHMgc3VwcG9ydCBtZWNo
YW5pc21zIHRvIGlkZW50aWZ5IGFkdmVydGlzZW1lbnRzIG9mDQogICAgIGV4
dGVybmFsbHkgZGVyaXZlZCBpbmZvcm1hdGlvbiBhbmQgdGhlcmVmb3JlIGFu
IGFuYWx5c2lzIG9mIHRoZWlyDQogICAgIGFwcGxpY2FiaWxpdHkgaGFzIHRv
IGJlIGNvbnNpZGVyZWQgb24gYSBwZXItcHJvdG9jb2wgYmFzaXMuDQoNCiAg
IEluIG9yZGVyIHRvIHN1cHBvcnQgb3BlcmF0b3IgYXNzaXN0ZWQgY2hhbmdl
cyBpbiB0aGUgY29udGFpbm1lbnQNCiAgIHJlbGF0aW9uc2hpcHMgb2YgUkFz
LCB0aGUgR01QTFMgcm91dGluZyBwcm90b2NvbCBpcyBleHBlY3RlZCB0bw0K
ICAgc3VwcG9ydCBldm9sdXRpb24gaW4gdGVybXMgb2YgbnVtYmVyIG9mIGhp
ZXJhcmNoaWNhbCBsZXZlbHMgb2YgUkFzDQogICAoYWRkaW5nIGFuZCByZW1v
dmluZyBSQXMgYXQgdGhlIHRvcC9ib3R0b20gb2YgdGhlIGhpZXJhcmNoeSks
IGFzDQogICB3ZWxsIGFzIGFnZ3JlZ2F0aW9uIGFuZCBzZWdtZW50YXRpb24g
b2YgUkFzLiBUaGVzZSBHTVBMUyByb3V0aW5nDQogICBjYXBhYmlsaXRpZXMg
YXJlIGNvbnNpZGVyZWQgb2YgbG93ZXIgcHJpb3JpdHkgYXMgdGhleSBhcmUN
CiAgIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCB0aGVpciBtZXRob2Qg
b2Ygc3VwcG9ydCBzaG91bGQgYmUNCiAgIGV2YWx1YXRlZCBvbiBwZXItcHJv
dG9jb2wgYmFzaXMgZS5nLiBPU1BGIHZzIElTLUlTLiBJbiBhZGRpdGlvbiwN
CiAgIHN1cHBvcnQgb2Ygbm9uLWRpc3J1cHRpdmUgb3BlcmF0aW9ucyBzdWNo
IGFzIGFkZGluZyBvciByZW1vdmluZyBhDQogICBoaWVyYXJjaGljYWwgbGV2
ZWwgb2YgUkFzIGluIG9yIGZyb20gdGhlIG1pZGRsZSBvZiB0aGUgcm91dGlu
Zw0KICAgaGllcmFyY2h5IGFyZSBjb25zaWRlcmVkIGFzIHRoZSBsb3dlc3Qg
cHJpb3JpdHkgcmVxdWlyZW1lbnRzLiBOb3RlDQogICBhbHNvIHRoYXQgdGhl
IG51bWJlciBvZiBoaWVyYXJjaGljYWwgbGV2ZWxzIHRvIGJlIHN1cHBvcnRl
ZCBpcw0KICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMsIGFuZCByZWZsZWN0
cyBhIGNvbnRhaW5tZW50IHJlbGF0aW9uc2hpcA0KICAgZS5nLiBhIFJBIGlu
c2VydGlvbiBpbnZvbHZlcyBzdXBwb3J0aW5nIGEgZGlmZmVyZW50IHJvdXRp
bmcgcHJvdG9jb2wNCiAgIGRvbWFpbiBpbiBhIHBvcnRpb24gb2YgdGhlIG5l
dHdvcmsuDQoNCiAgIE5vdGU6IHNvbWUgbWVtYmVycyBvZiB0aGUgRGVzaWdu
IFRlYW0gcXVlc3Rpb24gaWYgdGhlIEFTT04NCiAgIHJlcXVpcmVtZW50IGZv
ciBzdXBwb3J0aW5nIGFyY2hpdGVjdHVyZSBldm9sdXRpb24gaXMgYSByZXF1
aXJlbWVudA0KICAgb24gdGhlIHJvdXRpbmcgcHJvdG9jb2wgKHByb3RvY29s
LXNwZWNpZmljIGNhcGFiaWxpdHkpIHZzLiBhDQoNCg0KVy5BbGFucWFyIGV0
IGFsLiAtIEV4cGlyZXMgSnVseSAyMDA0ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAxMQ0KDA0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29u
LXJvdXRpbmctcmVxdHMtMDIudHh0ICAgICAgICAgRmVicnVhcnkgMjAwNA0K
DQoNCiAgIGNhcGFiaWxpdHkgdG8gYmUgcHJvdmlkZWQgYnkgdGhlIGFyY2hp
dGVjdHVyZS4gRm9yIGV4YW1wbGUsIEFTT04NCiAgIGFsbG93cyBmb3Igc3Vw
cG9ydGluZyBtdWx0aXBsZSBwcm90b2NvbHMgd2l0aGluIGVhY2ggUkEuIFRo
ZQ0KICAgbXVsdGlwbGUgcHJvdG9jb2xzIHNoYXJlIGEgY29tbW9uIHJvdXRp
bmcgaW5mb3JtYXRpb24gZGF0YWJhc2UNCiAgIChSREIpLCBhbmQgdGhlIFJE
QiBpcyB0aGUgY29tcG9uZW50LCB3aGljaCBuZWVkcyB0byBzdXBwb3J0DQog
ICBhcmNoaXRlY3R1cmUgZXZvbHV0aW9uLiBUaGUgRGVzaWduIFRlYW0gaW52
aXRlcyBDQ0FNUCBpbnB1dCB0bw0KICAgdW5kZXJzdGFuZCB0aGUgcHJvdG9j
b2wtc3BlY2lmaWMgaW1wYWN0cy4NCg0KICAgR01QTFMgcm91dGluZyBjdXJy
ZW50bHkgY292ZXJzIGFsbCBub2RlIGF0dHJpYnV0ZXMgY29uc2lkZXJlZCBp
bg0KICAgW0cuNzcxNS4xXS4gQXNzdW1pbmcgdGhhdCB0aGUgc2V0IG9mIFRF
IGxpbmsgSURzIGFyZSBudW1iZXJlZCBlaXRoZXINCiAgIGZyb20gdGhlaXIg
Y29tcG9uZW50L1RFIGxpbmtzIG9yIGZyb20gdGhlIG5vZGUgYWRkcmVzcyB0
aGF0IGhvc3RzDQogICB0aGVzZSBjb21wb25lbnRzL1RFIGxpbmtzLCBubyBh
ZGRpdGlvbmFsIGV4dGVuc2lvbnMgc2VlbSB0byBiZQ0KICAgcmVxdWlyZWQg
aW4gb3JkZXIgdG8gYWR2ZXJ0aXNlIHJlYWNoYWJsZSBlbmQtcG9pbnRzIHdp
dGhpbiBhbiBBU09ODQogICBjb250cm9sIHBsYW5lLiBBZHZlcnRpc2VtZW50
IG9mIGV4dGVybmFsbHkgcmVhY2hhYmxlIHByZWZpeGVzIGlzDQogICBidWls
dCBpbiB3aXRoaW4gYW55IHJvdXRpbmcgcHJvdG9jb2wgaW5kZXBlbmRlbnRs
eSBvZiBpdHMgdXNhZ2UNCiAgIGluL291dHNpZGUgR01QTFMuDQoNCiAgIE5v
dGU6IHNvbWUgbWVtYmVycyBvZiB0aGUgRGVzaWduIFRlYW0gbm90ZWQgdGhh
dCByZWFjaGFiaWxpdHkNCiAgIGluZm9ybWF0aW9uIChhcyBkZXNjcmliZWQg
aW4gU2VjdGlvbiA0LjUuMykgbWF5IGJlIGFkdmVydGlzZWQgYXMgYQ0KICAg
c2V0IG9mIFVOSSBUcmFuc3BvcnQgUmVzb3VyY2UgYWRkcmVzcyBwcmVmaXhl
cyAoYXNzaWduZWQgYW5kDQogICBzZWxlY3RlZCBjb25zaXN0ZW50bHkgaW4g
dGhlaXIgYXBwbGljYWJpbGl0eSBzY29wZSkuIFRoZXNlIG1lbWJlcnMNCiAg
IG9mIHRoZSBEZXNpZ24gVGVhbSByYWlzZWQgYSBjb25jZXJuIHRoYXQgZXhp
c3RpbmcgbWV0aG9kcyBvZg0KICAgYWR2ZXJ0aXNpbmcgcmVhY2hhYmlsaXR5
IG1heSBuZWVkIHRvIGJlIGV4YW1pbmVkIChvbiBhIHBlci1wcm90b2NvbA0K
ICAgYmFzaXMpIHRvIGRldGVybWluZSBpZiB0aGV5IGFyZSBhbHNvIGFwcGxp
Y2FibGUgZm9yIFVOSSBUcmFuc3BvcnQNCiAgIFJlc291cmNlIGFkZHJlc3Nl
cy4gVGhleSBpbnZpdGUgQ0NBTVAgZGlzY3Vzc2lvbiBvbiB0aGlzIGFzcGVj
dC4NCg0KICAgRnJvbSB0aGUgY29uc2lkZXJlZCBsaXN0IG9mIGxpbmsgYXR0
cmlidXRlcyBhbmQgY2hhcmFjdGVyaXN0aWNzLCB0aGUNCiAgIExvY2FsIEFk
YXB0YXRpb24gc3VwcG9ydCBpbmZvcm1hdGlvbiBpcyBtaXNzaW5nIGFzIFRF
IGxpbmsNCiAgIGF0dHJpYnV0ZS4gR01QTFMgcm91dGluZyBkb2VzIG5vdCBj
dXJyZW50bHkgY29uc2lkZXIgdGhlIHVzZSBvZg0KICAgZGVkaWNhdGVkIFRF
IGxpbmsgYXR0cmlidXRlKHMpIHRvIGRlc2NyaWJlIHRoZSBjcm9zcy9pbnRl
ci1sYXllcg0KICAgcmVsYXRpb25zaGlwcy4gQWxsIG90aGVyIFRFIGxpbmsg
YXR0cmlidXRlcyBhbmQgY2hhcmFjdGVyaXN0aWNzIGFyZQ0KICAgY3VycmVu
dGx5IGNvdmVyZWQuIFRoZSBuZWVkIGZvciBhICJURSBtZXRyaWMiIHBlciBj
b21wb25lbnQgbGluaw0KICAgbmVlZHMgdG8gYmUgZnVydGhlciBhc3Nlc3Nl
ZCwgaW4gdGhlIHNlbnNlIHRoYXQgaXQgY2FuIGJlIGN1cnJlbnRseQ0KICAg
aW1wbGVtZW50ZWQuIEZ1cnRoZXIgY29uc2lkZXJhdGlvbiBpcyBoZXJlIG5l
ZWRlZCByZWdhcmRpbmcgaW1wYWN0cw0KICAgb24gVEUgbGluayBidW5kbGlu
ZyBjYXBhYmlsaXRpZXMgYW5kIHRoZSBpbmNyZWFzZSBvZiB0aGUgcm91dGlu
Zw0KICAgYWR2ZXJ0aXNlbWVudCBvdmVyaGVhZCB3aXRoIHBvdGVudGlhbGx5
IGR1cGxpY2F0ZWQgaW5mb3JtYXRpb24uDQoNCiAgIE5vdGU6IEFTT04gZG9l
cyBub3QgcmVzdHJpY3QgdGhlIGFyY2hpdGVjdHVyZSBjaG9pY2VzIHVzZWQs
IGVpdGhlciBhDQogICBjby1sb2NhdGVkIGFyY2hpdGVjdHVyZSBvciBhIHBo
eXNpY2FsbHkgc2VwYXJhdGVkIGFyY2hpdGVjdHVyZSBtYXkNCiAgIGJlIHVz
ZWQuIFNvbWUgbWVtYmVycyBvZiB0aGUgRGVzaWduIFRlYW0gYXJlIGNvbmNl
cm5lZCB0aGF0IEdNUExTJ3MNCiAgIGNvbmNlcHQgb2YgdGhlIExTUiByZXF1
aXJlcyBhIDEtdG8tMSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUNCiAgIHRy
YW5zcG9ydCBwbGFuZSBlbnRpdHkgYW5kIHRoZSBjb250cm9sIHBsYW5lIGVu
dGl0eSAoUm91dGVyKS4gVGhleQ0KICAgaW52aXRlIENDQU1QIGlucHV0IG9u
IEdNUExTIGNhcGFiaWxpdGllcyB0byBzdXBwb3J0IG11bHRpcGxlDQogICBh
cmNoaXRlY3R1cmVzIGkuZS4gaG93IHJvdXRpbmcgcHJvdG9jb2xzIHdvdWxk
IGlkZW50aWZ5IHRoZQ0KICAgdHJhbnNwb3J0IG5vZGUgSUQgdnMuIHRoZSBy
b3V0ZXIgb3Igcm91dGluZyBjb250cm9sbGVyIElEIHdoZW4NCiAgIHNjb3Bp
bmcgTGluayBJRHMgaW4gYSBsaW5rIGFkdmVydGlzZW1lbnQuDQoNCiAgIFRo
ZSBpbmhlcml0YW5jZSBwcm9wZXJ0eSBvZiBsaW5rIGF0dHJpYnV0ZXMgdXNl
ZCB0byBvcHRpbWl6ZSB0aGUNCiAgIGNvbXBvbmVudC9URSBsaW5rIGNvbmZp
Z3VyYXRpb24gcHJvY2VzcyBpcyBidWlsdCBpbiB3aXRoaW4gR01QTFMuDQoN
Cg0KDQoNCg0KDQpXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBKdWx5IDIw
MDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEyDQoMDQpkcmFm
dC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMi50eHQg
ICAgICAgICBGZWJydWFyeSAyMDA0DQoNCg0KOC4gQWNrbm93bGVkZ2VtZW50
cw0KDQogICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIEtpcmVl
dGkgS29tcGVsbGEgZm9yIGhhdmluZw0KICAgaW5pdGlhdGVkIHRoZSBwcm9w
b3NhbCBvZiBhbiBBU09OIFJvdXRpbmcgUmVxdWlyZW1lbnQgRGVzaWduIFRl
YW0uDQoNCjkuIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBDb25zaWRlcmF0aW9u
cw0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcg
dGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgaW50ZWxsZWN0dWFs
IHByb3BlcnR5IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWlt
ZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVz
ZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9j
dW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRl
ciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWls
YWJsZTsgbmVpdGhlciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0DQogICBo
YXMgbWFkZSBhbnkgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0
cy4gIEluZm9ybWF0aW9uIG9uIHRoZQ0KICAgSUVURidzIHByb2NlZHVyZXMg
d2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBzdGFuZGFyZHMtdHJhY2sgYW5k
DQogICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBm
b3VuZCBpbiBCQ1AtMTEuICBDb3BpZXMgb2YNCiAgIGNsYWltcyBvZiByaWdo
dHMgbWFkZSBhdmFpbGFibGUgZm9yIHB1YmxpY2F0aW9uIGFuZCBhbnkgYXNz
dXJhbmNlcw0KICAgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUs
IG9yIHRoZSByZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlDQogICB0byBvYnRh
aW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVz
ZSBvZiBzdWNoDQogICBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50
b3JzIG9yIHVzZXJzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbg0KICAgY2FuIGJl
IG9idGFpbmVkIGZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCiAgIFRo
ZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcg
dG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMg
b3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkN
CiAgIHJpZ2h0cyB3aGljaCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1h
eSBiZSByZXF1aXJlZCB0byBwcmFjdGljZQ0KICAgdGhpcyBzdGFuZGFyZC4g
UGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIEV4
ZWN1dGl2ZQ0KICAgRGlyZWN0b3IuDQoNCjEwLiBSZWZlcmVuY2VzDQoNCjEw
LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQyAyMDI2XSAgIFMu
QnJhZG5lciwgIlRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgUHJvY2VzcyAtLQ0K
ICAgICAgICAgICAgICAgIFJldmlzaW9uIDMiLCBCQ1AgOSwgUkZDIDIwMjYs
IE9jdG9iZXIgMTk5Ni4NCg0KICAgW1JGQyAyMTE5XSAgIFMuQnJhZG5lciwg
IktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAg
ICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAy
MTE5LCBNYXJjaCAxOTk3Lg0KDQogICBbRy43NzE1XSAgICAgSVRVLVQgUmVj
LiBHLjc3MTUvWS4xMzA2LCAiQXJjaGl0ZWN0dXJlIGFuZA0KICAgICAgICAg
ICAgICAgIFJlcXVpcmVtZW50cyBmb3IgdGhlIEF1dG9tYXRpY2FsbHkgU3dp
dGNoZWQgT3B0aWNhbA0KICAgICAgICAgICAgICAgIE5ldHdvcmsgKEFTT04p
LCIgSnVuZSAyMDAyLg0KDQogICBbRy43NzE1LjFdICAgSVRVLVQgRHJhZnQg
UmVjLiBHLjc3MTUuMS9ZLjE3MDYuMSwgIkFTT04gUm91dGluZw0KICAgICAg
ICAgICAgICAgIEFyY2hpdGVjdHVyZSBhbmQgUmVxdWlyZW1lbnRzIGZvciBM
aW5rIFN0YXRlDQogICAgICAgICAgICAgICAgUHJvdG9jb2xzLCIgTm92ZW1i
ZXIgMjAwMy4NCg0KICAgW0cuODA4MF0gICAgIElUVS1UIFJlYy4gRy44MDgw
L1kuMTMwNCwgIkFyY2hpdGVjdHVyZSBmb3IgdGhlDQogICAgICAgICAgICAg
ICAgQXV0b21hdGljYWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmsgKEFT
T04pLCINCiAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDAxIChhbmQgUmV2
aXNpb24sIEphbnVhcnkgMjAwMykuDQoNCiAgIFtISUVSXSAgICAgICBLLktv
bXBlbGxhIGFuZCBZLlJla2h0ZXIsICJMU1AgSGllcmFyY2h5IHdpdGgNCiAg
ICAgICAgICAgICAgICBHZW5lcmFsaXplZCBNUExTIFRFLCIgSW50ZXJuZXQg
ZHJhZnQgKHdvcmsgaW4NCiAgICAgICAgICAgICAgICBwcm9ncmVzcyksIGRy
YWZ0LWlldGYtbXBscy1sc3AtaGllcmFyY2h5LCBTZXB0JzAyLg0KDQoNClcu
QWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIEp1bHkgMjAwNCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgMTMNCgwNCmRyYWZ0LWlldGYtY2NhbXAt
Z21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAyLnR4dCAgICAgICAgIEZlYnJ1
YXJ5IDIwMDQNCg0KDQoNCjExLiBBdXRob3IncyBBZGRyZXNzZXMNCg0KICAg
V2VzYW0gQWxhbnFhciAoU3ByaW50KSANCiAgIEVNYWlsOiB3ZXNhbS5hbGFu
cWFyQG1haWwuc3ByaW50LmNvbQ0KDQogICBEZWJvcmFoIEJydW5nYXJkIChB
VCZUKQ0KICAgUm0uIEQxLTNDMjIgLSAyMDAgUy4gTGF1cmVsIEF2ZS4NCiAg
IE1pZGRsZXRvd24sIE5KIDA3NzQ4LCBVU0ENCiAgIFBob25lOiArMSA3MzIg
NDIwMTU3Mw0KICAgRU1haWw6IGRicnVuZ2FyZEBhdHQuY29tDQoNCiAgIERh
dmlkIE1leWVyIChDaXNjbyBTeXN0ZW1zKQ0KICAgRU1haWw6IGRtbUAxLTQt
NS5uZXQNCg0KICAgTHluZG9uIE9uZyAoQ2llbmEgQ29ycG9yYXRpb24pDQog
ICA1OTY1IFNpbHZlciBDcmVlayBWYWxsZXkgUmQsDQogICBTYW4gSm9zZSwg
Q0EgOTUxMjgsIFVTQQ0KICAgUGhvbmU6ICsxIDQwOCA4MzQ3ODk0DQogICBF
TWFpbDogbHlvbmdAY2llbmEuY29tDQoNCiAgIERpbWl0cmkgUGFwYWRpbWl0
cmlvdSAoQWxjYXRlbCkNCiAgIEZyYW5jaXMgV2VsbGVuc3BsZWluIDEsDQog
ICBCLTIwMTggQW50d2VycGVuLCBCZWxnaXVtDQogICBQaG9uZTogKzMyIDMg
MjQwODQ5MQ0KICAgRU1haWw6IGRpbWl0cmkucGFwYWRpbWl0cmlvdUBhbGNh
dGVsLmJlDQoNCiAgIEpvbmF0aGFuIFNhZGxlcg0KICAgMTQxNSBXLiBEaWVo
bCBSZA0KICAgTmFwZXJ2aWxsZSwgSUwgNjA1NjMNCiAgIEVNYWlsOiBqb25h
dGhhbi5zYWRsZXJAdGVsbGFicy5jb20NCg0KICAgU3RlcGhlbiBTaGV3IChO
b3J0ZWwgTmV0d29ya3MpDQogICBQTyBCb3ggMzUxMSBTdGF0aW9uIEMNCiAg
IE90dGF3YSwgT250YXJpbywgQ0FOQURBIEsxWSA0SDcNCiAgIFBob25lOiAr
MSA2MTMgNzYzMjQ2Mg0KICAgRU1haWw6IHNkc2hld0Bub3J0ZWxuZXR3b3Jr
cy5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpXLkFs
YW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBKdWx5IDIwMDQgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDE0DQoMDQpkcmFmdC1pZXRmLWNjYW1wLWdt
cGxzLWFzb24tcm91dGluZy1yZXF0cy0wMi50eHQgICAgICAgICBGZWJydWFy
eSAyMDA0DQoNCg0KQXBwZW5kaXggMSAtIEFTT04gVGVybWlub2xvZ3kNCg0K
ICAgVGhpcyBkb2N1bWVudCBtYWtlcyB1c2Ugb2YgdGhlIGZvbGxvd2luZyB0
ZXJtczoNCg0KICAgQWRtaW5pc3RyYXRpdmUgZG9tYWluOiBTZWUgUmVjb21t
ZW5kYXRpb24gRy44MDUuDQoNCiAgIENvbnRyb2wgcGxhbmU6IHBlcmZvcm1z
IHRoZSBjYWxsIGNvbnRyb2wgYW5kIGNvbm5lY3Rpb24gY29udHJvbA0KICAg
ZnVuY3Rpb25zLiBUaHJvdWdoIHNpZ25hbGluZywgdGhlIGNvbnRyb2wgcGxh
bmUgc2V0cyB1cCBhbmQgcmVsZWFzZXMNCiAgIGNvbm5lY3Rpb25zLCBhbmQg
bWF5IHJlc3RvcmUgYSBjb25uZWN0aW9uIGluIGNhc2Ugb2YgYSBmYWlsdXJl
Lg0KDQogICAoQ29udHJvbCkgRG9tYWluOiByZXByZXNlbnRzIGEgY29sbGVj
dGlvbiBvZiBlbnRpdGllcyB0aGF0IGFyZQ0KICAgZ3JvdXBlZCBmb3IgYSBw
YXJ0aWN1bGFyIHB1cnBvc2UuIEcuODA4MCBhcHBsaWVzIHRoaXMgRy44MDUN
CiAgIHJlY29tbWVuZGF0aW9uIGNvbmNlcHQgKHRoYXQgZGVmaW5lcyB0d28g
cGFydGljdWxhciBmb3JtcywgdGhlDQogICBhZG1pbmlzdHJhdGl2ZSBkb21h
aW4gYW5kIHRoZSBtYW5hZ2VtZW50IGRvbWFpbikgdG8gdGhlIGNvbnRyb2wN
CiAgIHBsYW5lIGluIHRoZSBmb3JtIG9mIGEgY29udHJvbCBkb21haW4uIFRo
ZSBlbnRpdGllcyB0aGF0IGFyZSBncm91cGVkDQogICBpbiBhIGNvbnRyb2wg
ZG9tYWluIGFyZSBjb21wb25lbnRzIG9mIHRoZSBjb250cm9sIHBsYW5lLg0K
DQogICBFeHRlcm5hbCBOTkkgKEUtTk5JKTogaW50ZXJmYWNlcyBhcmUgbG9j
YXRlZCBiZXR3ZWVuIHByb3RvY29sDQogICBjb250cm9sbGVycyBiZXR3ZWVu
IGNvbnRyb2wgZG9tYWlucy4NCg0KICAgSW50ZXJuYWwgTk5JIChJLU5OSSk6
IGludGVyZmFjZXMgYXJlIGxvY2F0ZWQgYmV0d2VlbiBwcm90b2NvbA0KICAg
Y29udHJvbGxlcnMgd2l0aGluIGNvbnRyb2wgZG9tYWlucy4NCg0KICAgTGlu
azogU2VlIFJlY29tbWVuZGF0aW9uIEcuODA1Lg0KDQogICBNYW5hZ2VtZW50
IHBsYW5lOiBwZXJmb3JtcyBtYW5hZ2VtZW50IGZ1bmN0aW9ucyBmb3IgdGhl
IFRyYW5zcG9ydA0KICAgUGxhbmUsIHRoZSBjb250cm9sIHBsYW5lIGFuZCB0
aGUgc3lzdGVtIGFzIGEgd2hvbGUuIEl0IGFsc28gcHJvdmlkZXMNCiAgIGNv
b3JkaW5hdGlvbiBiZXR3ZWVuIGFsbCB0aGUgcGxhbmVzLiBUaGUgZm9sbG93
aW5nIG1hbmFnZW1lbnQNCiAgIGZ1bmN0aW9uYWwgYXJlYXMgYXJlIHBlcmZv
cm1lZCBpbiB0aGUgbWFuYWdlbWVudCBwbGFuZTogcGVyZm9ybWFuY2UsDQog
ICBmYXVsdCwgY29uZmlndXJhdGlvbiwgYWNjb3VudGluZyBhbmQgc2VjdXJp
dHkgbWFuYWdlbWVudA0KDQogICBNYW5hZ2VtZW50IGRvbWFpbjogU2VlIFJl
Y29tbWVuZGF0aW9uIEcuODA1Lg0KDQogICBUcmFuc3BvcnQgcGxhbmU6IHBy
b3ZpZGVzIGJpLWRpcmVjdGlvbmFsIG9yIHVuaWRpcmVjdGlvbmFsIHRyYW5z
ZmVyDQogICBvZiB1c2VyIGluZm9ybWF0aW9uLCBmcm9tIG9uZSBsb2NhdGlv
biB0byBhbm90aGVyLiBJdCBjYW4gYWxzbw0KICAgcHJvdmlkZSB0cmFuc2Zl
ciBvZiBzb21lIGNvbnRyb2wgYW5kIG5ldHdvcmsgbWFuYWdlbWVudCBpbmZv
cm1hdGlvbi4NCiAgIFRoZSBUcmFuc3BvcnQgUGxhbmUgaXMgbGF5ZXJlZDsg
aXQgaXMgZXF1aXZhbGVudCB0byB0aGUgVHJhbnNwb3J0DQogICBOZXR3b3Jr
IGRlZmluZWQgaW4gRy44MDUuDQoNCiAgIFVzZXIgTmV0d29yayBJbnRlcmZh
Y2UgKFVOSSk6IGludGVyZmFjZXMgYXJlIGxvY2F0ZWQgYmV0d2Vlbg0KICAg
cHJvdG9jb2wgY29udHJvbGxlcnMgYmV0d2VlbiBhIHVzZXIgYW5kIGEgY29u
dHJvbCBkb21haW4uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClcuQWxh
bnFhciBldCBhbC4gLSBFeHBpcmVzIEp1bHkgMjAwNCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgMTUNCgwNCmRyYWZ0LWlldGYtY2NhbXAtZ21w
bHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAyLnR4dCAgICAgICAgIEZlYnJ1YXJ5
IDIwMDQNCg0KDQpBcHBlbmRpeCAyIC0gQVNPTiBSb3V0aW5nIFRlcm1pbm9s
b2d5DQoNCiAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgdXNlIG9mIHRoZSBmb2xs
b3dpbmcgdGVybXM6DQoNCiAgIFJvdXRpbmcgQXJlYSAoUkEpOiBhIFJBIHJl
cHJlc2VudHMgYSBwYXJ0aXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgYW5kDQog
ICBpdHMgaWRlbnRpZmllciBpcyB1c2VkIHdpdGhpbiB0aGUgY29udHJvbCBw
bGFuZSBhcyB0aGUNCiAgIHJlcHJlc2VudGF0aW9uIG9mIHRoaXMgcGFydGl0
aW9uLiBQZXIgW0cuODA4MF0gYSBSQSBpcyBkZWZpbmVkIGJ5IGENCiAgIHNl
dCBvZiBzdWItbmV0d29ya3MsIHRoZSBURSBsaW5rcyB0aGF0IGludGVyY29u
bmVjdCB0aGVtLCBhbmQgdGhlDQogICBpbnRlcmZhY2VzIHJlcHJlc2VudGlu
ZyB0aGUgZW5kcyBvZiB0aGUgVEUgbGlua3MgZXhpdGluZyB0aGF0IFJBLiBB
DQogICBSQSBtYXkgY29udGFpbiBzbWFsbGVyIFJBcyBpbnRlci1jb25uZWN0
ZWQgYnkgVEUgbGlua3MuIFRoZSBsaW1pdCBvZg0KICAgc3ViZGl2aXNpb24g
cmVzdWx0cyBpbiBhIFJBIHRoYXQgY29udGFpbnMgdHdvIHN1Yi1uZXR3b3Jr
cyBhbmQgYSBURQ0KICAgbGluayB3aXRoIGEgc2luZ2xlIGNvbXBvbmVudCBs
aW5rLg0KDQogICBSb3V0aW5nIERhdGFiYXNlIChSREIpOiByZXBvc2l0b3J5
IGZvciB0aGUgbG9jYWwgdG9wb2xvZ3ksIG5ldHdvcmsNCiAgIHRvcG9sb2d5
LCByZWFjaGFiaWxpdHksIGFuZCBvdGhlciByb3V0aW5nIGluZm9ybWF0aW9u
IHRoYXQgaXMNCiAgIHVwZGF0ZWQgYXMgcGFydCBvZiB0aGUgcm91dGluZyBp
bmZvcm1hdGlvbiBleGNoYW5nZSBhbmQgbWF5DQogICBhZGRpdGlvbmFsbHkg
Y29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIGNvbmZpZ3VyZWQuIFRoZSBS
REIgbWF5DQogICBjb250YWluIHJvdXRpbmcgaW5mb3JtYXRpb24gZm9yIG1v
cmUgdGhhbiBvbmUgUm91dGluZyBBcmVhIChSQSkuDQoNCiAgIFJvdXRpbmcg
Q29tcG9uZW50czogQVNPTiByb3V0aW5nIGFyY2hpdGVjdHVyZSBmdW5jdGlv
bnMuIFRoZXNlDQogICBmdW5jdGlvbnMgY2FuIGJlIGNsYXNzaWZpZWQgYXMg
cHJvdG9jb2wgaW5kZXBlbmRlbnQgKExpbmsgUmVzb3VyY2UNCiAgIE1hbmFn
ZXIgb3IgTFJNLCBSb3V0aW5nIENvbnRyb2xsZXIgb3IgUkMpIGFuZCBwcm90
b2NvbCBzcGVjaWZpYw0KICAgKFByb3RvY29sIENvbnRyb2xsZXIgb3IgUEMp
Lg0KDQogICBSb3V0aW5nIENvbnRyb2xsZXIgKFJDKTogaGFuZGxlcyAoYWJz
dHJhY3QpIGluZm9ybWF0aW9uIG5lZWRlZCBmb3INCiAgIHJvdXRpbmcgYW5k
IHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlIHdpdGggcGVlcmlu
ZyBSQ3MgYnkNCiAgIG9wZXJhdGluZyBvbiB0aGUgUkRCLiBUaGUgUkMgaGFz
IGFjY2VzcyB0byBhIHZpZXcgb2YgdGhlIFJEQi4gVGhlIFJDDQogICBpcyBw
cm90b2NvbCBpbmRlcGVuZGVudC4NCg0KICAgTm90ZTogU2luY2UgdGhlIFJE
QiBtYXkgY29udGFpbiByb3V0aW5nIGluZm9ybWF0aW9uIHBlcnRhaW5pbmcg
dG8NCiAgIG11bHRpcGxlIFJBcyAoYW5kIGhlbmNlIHBvc3NpYmx5IG11bHRp
cGxlIGxheWVyIG5ldHdvcmtzKSwgdGhlIFJDcw0KICAgYWNjZXNzaW5nIHRo
ZSBSREIgbWF5IHNoYXJlIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uLg0KDQog
ICBMaW5rIFJlc291cmNlIE1hbmFnZXIgKExSTSk6IHN1cHBsaWVzIGFsbCB0
aGUgcmVsZXZhbnQgY29tcG9uZW50DQogICBhbmQgVEUgbGluayBpbmZvcm1h
dGlvbiB0byB0aGUgUkMuIEl0IGluZm9ybXMgdGhlIFJDIGFib3V0IGFueSBz
dGF0ZQ0KICAgY2hhbmdlcyBvZiB0aGUgbGluayByZXNvdXJjZXMgaXQgY29u
dHJvbHMuDQoNCiAgIFByb3RvY29sIENvbnRyb2xsZXIgKFBDKTogaGFuZGxl
cyBwcm90b2NvbCBzcGVjaWZpYyBtZXNzYWdlDQogICBleGNoYW5nZXMgYWNj
b3JkaW5nIHRvIHRoZSByZWZlcmVuY2UgcG9pbnQgb3ZlciB3aGljaCB0aGUN
CiAgIGluZm9ybWF0aW9uIGlzIGV4Y2hhbmdlZCAoZS5nLiBFLU5OSSwgSS1O
TkkpLCBhbmQgaW50ZXJuYWwgZXhjaGFuZ2VzDQogICB3aXRoIHRoZSBSQy4g
VGhlIFBDIGZ1bmN0aW9uIGlzIHByb3RvY29sIGRlcGVuZGVudC4NCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KVy5BbGFucWFyIGV0IGFsLiAtIEV4cGly
ZXMgSnVseSAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAx
Ng0KDA0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVx
dHMtMDIudHh0ICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCkZ1bGwgQ29w
eXJpZ2h0IFN0YXRlbWVudA0KDQogICAiQ29weXJpZ2h0IChDKSBUaGUgSW50
ZXJuZXQgU29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoN
CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkg
YmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgIG90aGVycywgYW5kIGRl
cml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBl
eHBsYWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9u
IG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQNCiAgIGFuZCBk
aXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0
cmljdGlvbiBvZiBhbnkNCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFi
b3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoDQogICBh
cmUgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZl
IHdvcmtzLiBIb3dldmVyLCB0aGlzDQogICBkb2N1bWVudCBpdHNlbGYgbWF5
IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92
aW5nDQogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRv
IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBv
cmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9z
ZSBvZg0KICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hp
Y2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAgIGNvcHlyaWdodHMgZGVm
aW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBi
ZQ0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBp
dCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQog
ICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBw
ZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQogICByZXZva2VkIGJ5IHRoZSBJ
bnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMu
DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250
YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJh
c2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVU
IEVOR0lORUVSSU5HDQogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FS
UkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcNCiAgIEJV
VCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9G
IFRIRSBJTkZPUk1BVElPTg0KICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdF
IEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRg0KICAg
TUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ
VVJQT1NFLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KVy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMg
SnVseSAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxNw0K

--0-1057782165-1079726995=:13502--



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2004 19:28:52 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Zafar Ali" <[e-mail]>
Subject: RE: Node-id Hello -  standards track or BCP?
Date: Fri, 19 Mar 2004 11:27:50 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian,

I think this is appropriate for the BCP category.

Also, I think Arun brings up a very good point about consistency
with addressing in Path/Resv. messages, and I support the idea that
it would be good to have clarification to this effect in the draft.

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, March 18, 2004 8:39 PM
> To: [e-mail]
> Subject: Node-id Hello - standards track or BCP?
> 
> 
> (or informational?)
> 
> The question for you folks is:
> 
> does this change protocol behavior (standards track)
> or narrow the choices for an implementation (BCP)
> or describe what some implementations do (informational)
> 
> An essential difference between the first and the second might be 
> the behavior that one
> LSR expects from its neighbor.
> 
> Opinions are cheap, but I want them anyway.
> 
> Thanks,
> Adrian
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2004 18:50:20 +0000
Date: Fri, 19 Mar 2004 13:48:42 -0500 (EST)
From: Arun Satyanarayana <[e-mail]>
Reply-To: <[e-mail]>
To: Adrian Farrel <[e-mail]>
Cc: <[e-mail]>, Arun Satyanarayan <[e-mail]>
Subject: Re: Node-id Hello -  standards track or BCP?
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

BCP since it does narrow choice.

However, I do have some comments:

The following text in section 2 is not necessarily true:

                                             Specifically, when all TE
   links between neighbor nodes are unnumbered, it is implied that the
   nodes will use node-id based Hellos for detection of signaling
   adjacency failures.

TE links may be unnumbered, but the corresponding control channel(s) may
be numbered. Implementations may choose to use either the control channel
interface addresses or node id's (a.k.a loopback addresses) for RSVP
messages.

In general, it would suffice to say that the IP addressing used in Hellos
follows the addressing used in Path and Resv messages. This includes any
modified IP addressing behaviour for Path and Resv messages, when the
control channel is out-of-band, as well as, when unnumbered data
interfaces are in use. Hence, if implementations do want to narrow Hellos
to node id's (a.k.a loopback addresses), they do so consistently across
all other RSVP messages as well. This means conditions such as Hellos
being up but Path and Resv refreshes being lost, or vice versa do not
occur. It also means that, it is not necessary to consult routing to
correlate node id's to corresponding control channel IP interface
addresses to go from Hellos to Path/Resv state for the sender node and
vice versa.

Thanks,
_arun_
============================================================
On Fri, 19 Mar 2004, Adrian Farrel wrote:

> (or informational?)
>
> The question for you folks is:
>
> does this change protocol behavior (standards track)
> or narrow the choices for an implementation (BCP)
> or describe what some implementations do (informational)
>
> An essential difference between the first and the second might be the behavior that one
> LSR expects from its neighbor.
>
> Opinions are cheap, but I want them anyway.
>
> Thanks,
> Adrian






Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2004 15:48:49 +0000
Message-Id: <[e-mail]>
Date: Fri, 19 Mar 2004 10:46:39 -0500
To: "zafar ali" <[e-mail]>
From: "Siva Sivabalan (msiva)" <[e-mail]>
Subject: RE: Node-id Hello -  standards track or BCP?
Cc: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

This belongs to BCP category.

Thanks,
Siva

At 01:11 AM 3/19/2004 -0500, zafar ali wrote:
>Dear Adrian and Ccampers:
>
>We have also updated the ID based on the comments received from the list
>and contribution from Dimitri. The updated version should appear at the
>list shortly, in the mean time mirror copy can be found at,
>
>http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp-node-i
>d-based-hello-01.txt
>
>Comments and suggestions will be appreciated.
>
>N.b. IMO this draft belongs to BCP category and does NOT change protocol
>behavior.
>
>Thanks
>
>Regards... Zafar
>
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Adrian Farrel
> >Sent: Thursday, March 18, 2004 11:39 PM
> >To: [e-mail]
> >Subject: Node-id Hello - standards track or BCP?
> >
> >
> >(or informational?)
> >
> >The question for you folks is:
> >
> >does this change protocol behavior (standards track)
> >or narrow the choices for an implementation (BCP)
> >or describe what some implementations do (informational)
> >
> >An essential difference between the first and the second might
> >be the behavior that one LSR expects from its neighbor.
> >
> >Opinions are cheap, but I want them anyway.
> >
> >Thanks,
> >Adrian
> >
> >




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2004 10:12:07 +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: Stepping back from the ASON Routing Discussion
Date: Fri, 19 Mar 2004 10:10:46 -0000
Message-ID: <[e-mail]>
Thread-Topic: Stepping back from the ASON Routing Discussion
Thread-Index: AcQNQneOhg9W47vnQsWhrprJCF6cBQAU0EcA
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

Hi Adrian....I have been biting my tongue and trying hard to stay out of =
this....I have failed, but I'll try and keep it short.

You (and Vishal) are right....we have been doing hierarchies for years.  =
And there are not just technical issues wrt client/server layer network =
relationships (which is what transport hierarchies create), there are =
also commercial issues, ie different parties can own the client and =
server layer networks involved.

The problems arise when folks think they can converge (somehow) the 3 =
native network modes of cl-ps, co-ps and co-cs.  Sure you can try, but =
its a big mistake.  All these modes can be derived from applying =
constraints to the most basic network mode, which is 'broadcast at =
source, filter at sink'.  This is how humans communicate in a mtg, and =
its how ethernet works.  However, it does not scale.  So we introduce =
constraints.....and we do so to get benefits in simpler =
design/operations/management/etc.

Addressing and routing are the 1st set of constraints.....these provide =
a 'where' (not 'who') semantic and a limited directivity behaviour.  =
This gets us to the cl-ps WAN mode best exemplified by IP.  Adding =
signalling (ie controlling the directivity further) gets us to the co-ps =
mode.....and it has implications on the nature of the forwarding traffic =
unit, ie this can be simplified to simply contain a link-connection ID =
(ie label) and not a full DA/SA pair (as required for the cl-ps =
mode).....the addresses are now only related to the trail access points. =
 If we add further constraints to the forwarding traffic unit we end up =
with the co-cs mode, ie now fixed BW, labels become some time/freq/space =
metric and (*very* significantly) there are no traffic/QoS classes.

However, all these modes have very different behaviours, eg the faults =
that can affect each mode are very different and the arch constructions =
that are allowed are different (I'll resist explaining why certain types =
on MPLS break the arch rules).  The simple fact is they all do different =
jobs optimally and we thus need them all.  The last thing one should be =
doing is trying to converge them all.....its simply wrong and folks who =
try this will continue to hit problems. (What we do want however is =
convergence *within* each mode, ie no point in having lots of co-ps =
technologies say.....just leads to stovepipe proliferation (ie =
technology=3Dservice) and downstream i/w problems).

We require our suppliers to understand/respect the func arch stuff of =
layered networks that is detailed in G.805/809...everything flows from =
these, esp the management information models.  And we were instrumental =
in doing the control-plane func arch of G.8080. =20

I'll stop at that point since I am sure you can fill-in where I am =
heading now ;-)

regards, Neil

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: 18 March 2004 23:19
> To: Vishal Sharma; [e-mail]; Don Fedyk
> Cc: [e-mail]
> Subject: Re: Stepping back from the ASON Routing Discussion
>=20
>=20
> Vishal,
>=20
> I think what you describe is business as usual for hierarchies.
> This is clearly a requirement that needs to be captured, but=20
> it is nothing startling or
> controversial (I believe).
>=20
> Thanks,
> Adrian
> ----- Original Message -----=20
> From: "Vishal Sharma" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>;=20
> <[e-mail]>; "Don Fedyk"
> <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, March 18, 2004 7:43 PM
> Subject: RE: Stepping back from the ASON Routing Discussion
>=20
>=20
> > Adrian, et al,
> >
> > You mention that there are two developments of the=20
> following requirement:
> >
> > ["It is a requirement of ASON routing to support networks=20
> that contain
> > devices
> > that do not contain the capabilities to participate fully=20
> (or at all) in the
> > routing protocols run within the network."]
> >
> > The second development listed below seems to assume that=20
> the islands within
> > the network will not be represented to the routing protocol=20
> only when they
> > contain devices that do not support routing.
> >
> > However, this is where I would appreciate some clarification to
> > help clear some of my understanding of this discussion.
> >
> > It seems to me that while one implication of the above requirement
> > is certainly this, it is also possible that islands are not=20
> represented
> > to the routing protocol, simply because the provider does=20
> not wish to
> > reveal the topology of its network beyond a certain level=20
> of granularity
> > (even if the devices do support routing protocols within=20
> those islands).
> >
> > This would be increasingly so when hierarchy is=20
> implemented. (The devices
> > could then support routing at a given level of the=20
> hierarchy, but may be
> > abstracted at the next (higher) level.)
> >
> > While I understand that the current discussion focuses=20
> initially on a given
> > level of the hierarchy, I think the second development you=20
> talk about
> > below is also a consequence of the need to support hierarchy.
> >
> > Or, did I not get it right?
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]On
> > > Behalf Of Adrian Farrel
> > > Sent: Thursday, March 18, 2004 3:43 AM
> > > To: [e-mail]; Don Fedyk
> > > Cc: [e-mail]
> > > Subject: Re: Stepping back from the ASON Routing Discussion
> > >
> > >
> > > Don,
> > >
> > > Just picking out one snippet...
> > >
> > > > >>Do we, or do we not need to support a physically separated
> > > > >>architecture with a 1-n relationship between control plane
> > > > >>and transport plane entities?
> > > > >
> > > > > I would say yes. The requirement I see here is=20
> devices not capable of
> > > > > participating fully in GMPLS routing.
> > >
> > > I had to read this several times before I got it. Sorry.
> > >
> > > You mean that...
> > > "It is a requirement of ASON routing to support networks that
> > > contain devices that do not
> > > contain the capabilities to participate fully (or at all) in the
> > > routing protocols run
> > > within the network."
> > >
> > > That sounds a reasonable requirement.
> > >
> > > There are two developments of this requirement.
> > >
> > > The first is where the routing responsiblity for the device is
> > > taken on "by proxy" by a
> > > control plane entity such as one that Lyndon, Jonathan and I have
> > > been drawing. In this
> > > case, although the device is not participating in the routing
> > > protocols within the
> > > network, it is fully represented and there are no issues
> > > (although we must ensure that
> > > this function is covered by the requirements).
> > >
> > > In the second case, ther are islands within the network which are
> > > simply not represented
> > > to the routing protocol. This gives me a greater problem. Clearly
> > > you cannot route through
> > > a part of the network unless it appears to be connected in the
> > > TEDB. In this case, I
> > > suggest that what is needed is to represent those (legacy?)
> > > devices/subnetworks as
> > > Forwarding Adjacencies or virtual TE links. This requires some
> > > advertisement by a control
> > > plane entity on behalf of the devices/subnetworks, but does not
> > > expose the details of the
> > > connectivity of the devices that do not support routing.
> > >
> > > Some of you may (from time to time) hear me burble on about the
> > > fact that soft permanent
> > > LSPs should not simply cover the case where the permanent part is
> > > at the edge of the
> > > network. When I ramble in this way, I am talking about the second
> > > case, above.
> > >
> > > Cheers,
> > > Adrian
> > >
> > >
> >
> >
> >
> >
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2004 08:17:54 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Kireeti Kompella' <[e-mail]>
Cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing
Date: Fri, 19 Mar 2004 00:17:10 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Kireeti,

Please see below.

Lyndon

-----Original Message-----
From: Kireeti Kompella [mailto:[e-mail]]
Sent: Thursday, March 18, 2004 11:47 AM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABSHi '; [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing


Hi Lyndon,

On Tue, 16 Mar 2004, Ong, Lyndon wrote:

> 1) the client system may not be an IP system, but another transport
> device with an IP control interface - for example, an ADM (add-drop
> multiplexer) acting as a client to an optical network.  Advertising
> reachability using normal means might imply that the system can be
> used for IP traffic routing.

There is a section in the GMPLS routing document titled:

1.2. Excluding data traffic from control channels

This section proposes one method for achieving this; and finishes by
saying:

   Other techniques for excluding data traffic from control channels may
   also be needed.

So, we all agree that this is a requirement.  I would not put this in
the ASON Routing Reqts doc, though, unless this is written in some
ITU-T Recommendation, given that the ASON Routing Reqts are *not* to
introduce new requirements, however useful or sane they may be for
ASON (or other) networks.

[LYO] OK, point taken.  This is already a GMPLS requirement.

> 2) the client system may use a different addressing space than the
> internal network addressing space.  Carriers may wish to use a
> different addressing space for administrative or policy reasons.
>
> (Note: one model for this is the VPN model, which would allow
> private networks to have their own address spaces.  Another model
> is a telephone number-like model, where clients obtain addresses
> from a space maintained by the carrier.)
>
> 3) the client system may use a non-IP address for compatibility
> reasons, for example, a client with an existing management plane
> address that the carrier wants to access without having to
> add a new address and translation mechanism.

Again, these are both good, but unless you can find text to this
effect in an ITU-T Recommendation on ASON routing requirements, we
cannot put this in the ASON Routing Requirements document.

If there is such text (for any of points 1, 2 or 3), it would be
useful in the context of this debate to post it to this list.

[LYO]  Well, I was not asking for this to be put into the 
requirements document, just trying to present some of the
concerns with the conclusions section.

For point 3, I view Recommendation 7713.1 which (in my faint
recollection) has only PNNI addressing, and in particular does not
have IP addressing, as suggesting that it is NOT a requirement that
a given solution cater to all possible address types.  So, while this
might a nice-to-have, it certainly doesn't seem to be an ASON
requirement.  If you think otherwise, please let me know --
Recommendation number & section.

[LYO] G.7713.1 is a signaling document (and as Jon points out does
have a mechanism for carrying IP addresses).  PNNI routing extensions
for ASON would need a mechanism for advertising UNI
reachability.

Thanks,
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2004 07:57:29 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Kireeti Kompella' <[e-mail]>
Cc: [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing
Date: Thu, 18 Mar 2004 23:56:01 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Kireeti,

I would like to put this discussion in some perspective:
we were discussing unsettled areas in the conclusions section, 
which currently states that "no additional 
extensions seem to be required in order to advertise reachable 
end-points within an ASON control plane."

I'm concerned that this can be read as a conclusion about the
routing protocols rather than routing requirements, and if
so seems premature and out of scope of the requirements document.

As Jon has pointed out, the specific requirement in ASON
is to advertise reachability in terms of a set of SNPP IDs
or UNI Transport Resource Addresses or associated prefixes.

ASON does not specify in detail how UNI Transport Resource
Addresses are formatted or allocated (apart from specifying 
that they are globally unique and network assigned).  If
GMPLS has restrictions that affect reachability advertisement
it would be helpful to understand this.

Cheers,

Lyndon


-----Original Message-----
From: Kireeti Kompella [mailto:[e-mail]]
Sent: Thursday, March 18, 2004 11:47 AM
To: Ong, Lyndon
Cc: [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing


Hi Lyndon,

On Tue, 16 Mar 2004, Ong, Lyndon wrote:

> Maybe the issue needs to be worded more clearly...
>
> Can existing address reachability mechanisms support
> (and if so, how)
>
> a) distinguishing between the control plane address
> for a client and the data plane address for a client
> which might be two different things?
>
> b) distinguishing between the internal network address
> space and an external client address space?
>
> c) advertising reachability to a client whose address
> space is non-IP?

All excellent questions.  Thanks for the summary.

I'll go back to my meta-question:

Are these ASON routing requirements?  If so, can you quote chapter and
verse?  The clear charter of the ASON Routing Reqts DT is to take
*existing* ASON routing requirements, evaluate them against what's in
GMPLS routing, and come up with a list of remaining requirements to
set the stage for an ASON Routing Extensions document.  Not to come up
with new requirements, however excellent they may be.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2004 06:12:48 +0000
From: "zafar ali" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Node-id Hello -  standards track or BCP?
Date: Fri, 19 Mar 2004 01:11:06 -0500
Organization: Cisco Systems
Message-ID: <000001c40d78$f85875c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Adrian and Ccampers:

We have also updated the ID based on the comments received from the list
and contribution from Dimitri. The updated version should appear at the
list shortly, in the mean time mirror copy can be found at, 

http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp-node-i
d-based-hello-01.txt

Comments and suggestions will be appreciated. 

N.b. IMO this draft belongs to BCP category and does NOT change protocol
behavior. 

Thanks

Regards... Zafar

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Adrian Farrel
>Sent: Thursday, March 18, 2004 11:39 PM
>To: [e-mail]
>Subject: Node-id Hello - standards track or BCP?
>
>
>(or informational?)
>
>The question for you folks is:
>
>does this change protocol behavior (standards track)
>or narrow the choices for an implementation (BCP)
>or describe what some implementations do (informational)
>
>An essential difference between the first and the second might 
>be the behavior that one LSR expects from its neighbor.
>
>Opinions are cheap, but I want them anyway.
>
>Thanks,
>Adrian
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2004 04:40:36 +0000
Message-ID: <100001c40d6c$155de2c0$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Node-id Hello -  standards track or BCP?
Date: Fri, 19 Mar 2004 04:38:44 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

(or informational?)

The question for you folks is:

does this change protocol behavior (standards track)
or narrow the choices for an implementation (BCP)
or describe what some implementations do (informational)

An essential difference between the first and the second might be the behavior that one
LSR expects from its neighbor.

Opinions are cheap, but I want them anyway.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 23:56:27 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Stepping back from the ASON Routing Discussion
Date: Thu, 18 Mar 2004 15:55:28 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian,

Great, thanks. I just wanted to make sure, since hierarchy was
point 3 of the requirements email you sent.

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, March 18, 2004 3:19 PM
> To: Vishal Sharma; [e-mail]; Don Fedyk
> Cc: [e-mail]
> Subject: Re: Stepping back from the ASON Routing Discussion
>
>
> Vishal,
>
> I think what you describe is business as usual for hierarchies.
> This is clearly a requirement that needs to be captured, but it
> is nothing startling or
> controversial (I believe).
>
> Thanks,
> Adrian
> ----- Original Message -----
> From: "Vishal Sharma" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>;
> <[e-mail]>; "Don Fedyk"
> <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, March 18, 2004 7:43 PM
> Subject: RE: Stepping back from the ASON Routing Discussion
>
>
> > Adrian, et al,
> >
> > You mention that there are two developments of the following
> requirement:
> >
> > ["It is a requirement of ASON routing to support networks that contain
> > devices
> > that do not contain the capabilities to participate fully (or
> at all) in the
> > routing protocols run within the network."]
> >
> > The second development listed below seems to assume that the
> islands within
> > the network will not be represented to the routing protocol
> only when they
> > contain devices that do not support routing.
> >
> > However, this is where I would appreciate some clarification to
> > help clear some of my understanding of this discussion.
> >
> > It seems to me that while one implication of the above requirement
> > is certainly this, it is also possible that islands are not represented
> > to the routing protocol, simply because the provider does not wish to
> > reveal the topology of its network beyond a certain level of granularity
> > (even if the devices do support routing protocols within those islands).
> >
> > This would be increasingly so when hierarchy is implemented.
> (The devices
> > could then support routing at a given level of the hierarchy, but may be
> > abstracted at the next (higher) level.)
> >
> > While I understand that the current discussion focuses
> initially on a given
> > level of the hierarchy, I think the second development you talk about
> > below is also a consequence of the need to support hierarchy.
> >
> > Or, did I not get it right?
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]On
> > > Behalf Of Adrian Farrel
> > > Sent: Thursday, March 18, 2004 3:43 AM
> > > To: [e-mail]; Don Fedyk
> > > Cc: [e-mail]
> > > Subject: Re: Stepping back from the ASON Routing Discussion
> > >
> > >
> > > Don,
> > >
> > > Just picking out one snippet...
> > >
> > > > >>Do we, or do we not need to support a physically separated
> > > > >>architecture with a 1-n relationship between control plane
> > > > >>and transport plane entities?
> > > > >
> > > > > I would say yes. The requirement I see here is devices
> not capable of
> > > > > participating fully in GMPLS routing.
> > >
> > > I had to read this several times before I got it. Sorry.
> > >
> > > You mean that...
> > > "It is a requirement of ASON routing to support networks that
> > > contain devices that do not
> > > contain the capabilities to participate fully (or at all) in the
> > > routing protocols run
> > > within the network."
> > >
> > > That sounds a reasonable requirement.
> > >
> > > There are two developments of this requirement.
> > >
> > > The first is where the routing responsiblity for the device is
> > > taken on "by proxy" by a
> > > control plane entity such as one that Lyndon, Jonathan and I have
> > > been drawing. In this
> > > case, although the device is not participating in the routing
> > > protocols within the
> > > network, it is fully represented and there are no issues
> > > (although we must ensure that
> > > this function is covered by the requirements).
> > >
> > > In the second case, ther are islands within the network which are
> > > simply not represented
> > > to the routing protocol. This gives me a greater problem. Clearly
> > > you cannot route through
> > > a part of the network unless it appears to be connected in the
> > > TEDB. In this case, I
> > > suggest that what is needed is to represent those (legacy?)
> > > devices/subnetworks as
> > > Forwarding Adjacencies or virtual TE links. This requires some
> > > advertisement by a control
> > > plane entity on behalf of the devices/subnetworks, but does not
> > > expose the details of the
> > > connectivity of the devices that do not support routing.
> > >
> > > Some of you may (from time to time) hear me burble on about the
> > > fact that soft permanent
> > > LSPs should not simply cover the case where the permanent part is
> > > at the edge of the
> > > network. When I ramble in this way, I am talking about the second
> > > case, above.
> > >
> > > Cheers,
> > > Adrian
> > >
> > >
> >
> >
> >
> >
>




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 23:48:23 +0000
Date: Thu, 18 Mar 2004 18:47:18 -0500
From: Ashok Narayanan <[e-mail]>
To: Lou Berger <[e-mail]>
Cc: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: Re: Label type to be used
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

I erroneously sent out some wrong text in my previous email which can
be ignored as noise:

> Plus TDM switches now
> have to handle both SUKLM and port labels, and both Intserv and
> SONET/SDH TSpecs when in fact there was really no need for it. 

Meanwhile I have another question. We changed the label type of 
[PSC, LSC] from "lambda" to "port"; and I guess the reason for that is
that a PSC device really isn't going to know about wavelengths. If my
understanding is correct, then [TDM, LSC] should also really be a port
label. Why isn't it?

-Ashok


> If the
> signal is truly transparent then a TSpec reflecting all the slots on
> the link, and a SUKLM label reflecting STS-1, is functionally
> identical to a port label and an Intserv tspec (probably the SONET
> TSpec is a more accurate description of the link). 
> 
> Anyway, I won't really object to the change if nobody else does.
> 
> -Ashok
> 
> > 
> > Lou
> > 
> > >On Thu, Mar 18, 2004 at 09:58:23AM -0800, Kireeti Kompella wrote:
> > >> Hi,
> > >>
> > >> Arthi and Lou pointed out the following typos in the GMPLS routing doc
> > >> (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
> > >> Editor's queue:
> > >>
> > >> In section 2.4.7 is the following table defining the type of label
> > >> for various combinations of switching types:
> > >>
> > >>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> > >>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> > >>       [LSC, LSC] - label represents a lambda
> > >>       [FSC, FSC] - label represents a port on an OXC
> > >>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> > >>       [PSC, LSC] - label represents a lambda
> > >>       [PSC, FSC] - label represents a port
> > >>       [TDM, LSC] - label represents a lambda
> > >>       [TDM, FSC] - label represents a port
> > >>       [LSC, FSC] - label represents a port
> > >>
> > >> The one at issue is [PSC, LSC]; above it says that the label
> > >> represents a lambda; and in the case of [PSC, TDM] with a fully
> > >> transparent signal, the above indicates the label represents a TDM
> > >> time slot.  The proposal is to change this to:
> > >>
> > >>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> > >>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> > >>       [LSC, LSC] - label represents a lambda
> > >>       [FSC, FSC] - label represents a port on an OXC
> > >>       [PSC, TDM] - fully transparent signal: label represents a port
> > >>                    ("transparency" is defined in [GMPLS-SONET-SDH])
> > >>       [PSC, TDM] - non-transparent signal: label represents a TDM time
> > >>                    slot [GMPLS-SONET-SDH]
> > >>       [PSC, LSC] - label represents a port
> > >>       [PSC, FSC] - label represents a port
> > >>       [TDM, LSC] - label represents a lambda
> > >>       [TDM, FSC] - label represents a port
> > >>       [LSC, FSC] - label represents a port
> > >>
> > >> Please respond by Friday 3/26, 5pm PST with comments on:
> > >>
> > >> a) do you agree with the above change?
> > >> b) in your implementation today, what do expect the label to represent
> > >>    i) in the case of [PSC, LSC]?
> > >>    ii) in the case of [PSC, TDM] with a fully transparent signal?
> > >> c) if you implement as the draft says, would it be a hardship to change
> > >>    this?
> > >>
> > >> If we can get closure on this, I'll take up the task of modifying the
> > >> pending RFC with the ADs.
> > >>
> > >> Kireeti.
> > >> -------
> > >
> > >--
> > >
> > >
> > >--- Asok the Intern ----------------------------------------
> > >Ashok Narayanan
> > >IOS Network Protocols, Cisco Systems
> > >1414 Mass Ave, Boxborough MA 01719
> > >Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)
> 
> -- 
> 
> 
> 
> --- Asok the Intern ----------------------------------------
> Ashok Narayanan
> IOS Network Protocols, Cisco Systems
> 1414 Mass Ave, Boxborough MA 01719
> Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)
> 

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 23:40:39 +0000
Message-ID: <0f2f01c40d42$546ba580$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Vishal Sharma" <[e-mail]>, <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Stepping back from the ASON Routing Discussion
Date: Thu, 18 Mar 2004 23:18:58 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Vishal,

I think what you describe is business as usual for hierarchies.
This is clearly a requirement that needs to be captured, but it is nothing startling or
controversial (I believe).

Thanks,
Adrian
----- Original Message ----- 
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>; "Don Fedyk"
<[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, March 18, 2004 7:43 PM
Subject: RE: Stepping back from the ASON Routing Discussion


> Adrian, et al,
>
> You mention that there are two developments of the following requirement:
>
> ["It is a requirement of ASON routing to support networks that contain
> devices
> that do not contain the capabilities to participate fully (or at all) in the
> routing protocols run within the network."]
>
> The second development listed below seems to assume that the islands within
> the network will not be represented to the routing protocol only when they
> contain devices that do not support routing.
>
> However, this is where I would appreciate some clarification to
> help clear some of my understanding of this discussion.
>
> It seems to me that while one implication of the above requirement
> is certainly this, it is also possible that islands are not represented
> to the routing protocol, simply because the provider does not wish to
> reveal the topology of its network beyond a certain level of granularity
> (even if the devices do support routing protocols within those islands).
>
> This would be increasingly so when hierarchy is implemented. (The devices
> could then support routing at a given level of the hierarchy, but may be
> abstracted at the next (higher) level.)
>
> While I understand that the current discussion focuses initially on a given
> level of the hierarchy, I think the second development you talk about
> below is also a consequence of the need to support hierarchy.
>
> Or, did I not get it right?
>
> -Vishal
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Adrian Farrel
> > Sent: Thursday, March 18, 2004 3:43 AM
> > To: [e-mail]; Don Fedyk
> > Cc: [e-mail]
> > Subject: Re: Stepping back from the ASON Routing Discussion
> >
> >
> > Don,
> >
> > Just picking out one snippet...
> >
> > > >>Do we, or do we not need to support a physically separated
> > > >>architecture with a 1-n relationship between control plane
> > > >>and transport plane entities?
> > > >
> > > > I would say yes. The requirement I see here is devices not capable of
> > > > participating fully in GMPLS routing.
> >
> > I had to read this several times before I got it. Sorry.
> >
> > You mean that...
> > "It is a requirement of ASON routing to support networks that
> > contain devices that do not
> > contain the capabilities to participate fully (or at all) in the
> > routing protocols run
> > within the network."
> >
> > That sounds a reasonable requirement.
> >
> > There are two developments of this requirement.
> >
> > The first is where the routing responsiblity for the device is
> > taken on "by proxy" by a
> > control plane entity such as one that Lyndon, Jonathan and I have
> > been drawing. In this
> > case, although the device is not participating in the routing
> > protocols within the
> > network, it is fully represented and there are no issues
> > (although we must ensure that
> > this function is covered by the requirements).
> >
> > In the second case, ther are islands within the network which are
> > simply not represented
> > to the routing protocol. This gives me a greater problem. Clearly
> > you cannot route through
> > a part of the network unless it appears to be connected in the
> > TEDB. In this case, I
> > suggest that what is needed is to represent those (legacy?)
> > devices/subnetworks as
> > Forwarding Adjacencies or virtual TE links. This requires some
> > advertisement by a control
> > plane entity on behalf of the devices/subnetworks, but does not
> > expose the details of the
> > connectivity of the devices that do not support routing.
> >
> > Some of you may (from time to time) hear me burble on about the
> > fact that soft permanent
> > LSPs should not simply cover the case where the permanent part is
> > at the edge of the
> > network. When I ramble in this way, I am talking about the second
> > case, above.
> >
> > Cheers,
> > Adrian
> >
> >
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 23:40:08 +0000
Date: Thu, 18 Mar 2004 18:38:53 -0500
From: Ashok Narayanan <[e-mail]>
To: Lou Berger <[e-mail]>
Cc: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: Re: Label type to be used
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

On Thu, Mar 18, 2004 at 04:43:11PM -0500, Lou Berger wrote:
> At 04:27 PM 3/18/2004 -0500, Ashok Narayanan wrote:
> 
> >Personally, I do not agree with this change. I would rather see the
> >other side of this discrepancy fixed i.e. GMPLS-SONET-SDH should
> >specify the use of SUKLM label and SONET TSpec for all [PSC, TDM]
> >links irrespective of transparency. This seems like a more natural
> >architecture to me. Why is this not preferred?
> >
> >-Ashok
> 
> Ashok,
> 
> Beyond the original rational for the current definition, this is not 
> consistent with GMPLS-SONET-SDH, which is in the RFC editor queue, 

Both drafts are in the queue; one is not consistent with the
other. Seem symmetric to me.

> and does 
> not match many implementations (at least all we've tested against.)
> 
> Kireeti's change is consistent with the other documents (and the reality of 
> many implementations).

That's not bad; I could say that especially at this late time we could
live with it. But it seems messy. It's a very nice hierarchical model
to say that label type and TSpec type is dictated by switching type (pair). 
But this exception makes things not so clean. Plus TDM switches now
have to handle both SUKLM and port labels, and both Intserv and
SONET/SDH TSpecs when in fact there was really no need for it. If the
signal is truly transparent then a TSpec reflecting all the slots on
the link, and a SUKLM label reflecting STS-1, is functionally
identical to a port label and an Intserv tspec (probably the SONET
TSpec is a more accurate description of the link). 

Anyway, I won't really object to the change if nobody else does.

-Ashok

> 
> Lou
> 
> >On Thu, Mar 18, 2004 at 09:58:23AM -0800, Kireeti Kompella wrote:
> >> Hi,
> >>
> >> Arthi and Lou pointed out the following typos in the GMPLS routing doc
> >> (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
> >> Editor's queue:
> >>
> >> In section 2.4.7 is the following table defining the type of label
> >> for various combinations of switching types:
> >>
> >>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> >>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >>       [LSC, LSC] - label represents a lambda
> >>       [FSC, FSC] - label represents a port on an OXC
> >>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >>       [PSC, LSC] - label represents a lambda
> >>       [PSC, FSC] - label represents a port
> >>       [TDM, LSC] - label represents a lambda
> >>       [TDM, FSC] - label represents a port
> >>       [LSC, FSC] - label represents a port
> >>
> >> The one at issue is [PSC, LSC]; above it says that the label
> >> represents a lambda; and in the case of [PSC, TDM] with a fully
> >> transparent signal, the above indicates the label represents a TDM
> >> time slot.  The proposal is to change this to:
> >>
> >>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> >>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >>       [LSC, LSC] - label represents a lambda
> >>       [FSC, FSC] - label represents a port on an OXC
> >>       [PSC, TDM] - fully transparent signal: label represents a port
> >>                    ("transparency" is defined in [GMPLS-SONET-SDH])
> >>       [PSC, TDM] - non-transparent signal: label represents a TDM time
> >>                    slot [GMPLS-SONET-SDH]
> >>       [PSC, LSC] - label represents a port
> >>       [PSC, FSC] - label represents a port
> >>       [TDM, LSC] - label represents a lambda
> >>       [TDM, FSC] - label represents a port
> >>       [LSC, FSC] - label represents a port
> >>
> >> Please respond by Friday 3/26, 5pm PST with comments on:
> >>
> >> a) do you agree with the above change?
> >> b) in your implementation today, what do expect the label to represent
> >>    i) in the case of [PSC, LSC]?
> >>    ii) in the case of [PSC, TDM] with a fully transparent signal?
> >> c) if you implement as the draft says, would it be a hardship to change
> >>    this?
> >>
> >> If we can get closure on this, I'll take up the task of modifying the
> >> pending RFC with the ADs.
> >>
> >> Kireeti.
> >> -------
> >
> >--
> >
> >
> >--- Asok the Intern ----------------------------------------
> >Ashok Narayanan
> >IOS Network Protocols, Cisco Systems
> >1414 Mass Ave, Boxborough MA 01719
> >Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 22:31:49 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: Kireeti Kompella <[e-mail]>, Jonathan Sadler <[e-mail]>
Cc: [e-mail]
Subject: RE: Stepping back from the ASON Routing Discussion
Date: Thu, 18 Mar 2004 17:30:16 -0500

Jonathan and Kireeti

A question

> -----Original Message-----
> From: Kireeti Kompella [mailto:[e-mail]] 
> Sent: Thursday, March 18, 2004 3:03 PM
> 
> 
> Hi Jonathan,
> 
> On Wed, 17 Mar 2004, Jonathan Sadler wrote:
> 
> > > The first sentence is about requirements.
> > > Do we, or do we not, need to support advertising UNI Transport 
> > > Resource address prefixes?
> >
> > There is a requirement to be able to advertise reachability (G.7715 
> > sec7.1.1, G.7715.1 sec 9.4).  G.7715.1 states:
> >   Reachability Information: Reachability information describes
> >   the set of endpoints that are reachable by the associated node.
> >   It may be advertised either as a set of UNI Transport Resource
> >   addresses/address prefixes, or a set of associated
> >   SNPP IDs/SNPP ID prefixes, the selection of which must be
> >   consistent within the applicable scope.
> > so technically, there isn't a requirement to advertise UNI 
> Transport 
> > Resource Addresses -- the requirement is to advertise 
> reachability in 
> > terms of SNPP IDs or UNI Transport Resources Addresses.
> 
> Thanks for the references!  This is exactly what I want to 
> see.  What I don't want is an ITU-T Liaison complaining that 
> we are re-doing their requirements :-)

Is it safe to say the primary requirement is not the advertisement itself
but the ability for a user/operator to be able to setup connections/calls
using either UNI Transport Resource addresses or SNPP IDs as the local and
remote endpoints identifiers?  I think this is the primary requirement and
it can be somewhat independent of the advertisement depending on scope.  I
hear the advertisement requirement as well, but I believe that by first
separating these requirements and scoping them we may be able to make some
progress. 

Thanks,
Don 




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 21:43:53 +0000
Message-Id: <6.0.3.0.2.20040318163938.0375eb28@mo-ex1>
Date: Thu, 18 Mar 2004 16:43:11 -0500
To: "Ashok Narayanan" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Label type to be used
Cc: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:27 PM 3/18/2004 -0500, Ashok Narayanan wrote:

>Personally, I do not agree with this change. I would rather see the
>other side of this discrepancy fixed i.e. GMPLS-SONET-SDH should
>specify the use of SUKLM label and SONET TSpec for all [PSC, TDM]
>links irrespective of transparency. This seems like a more natural
>architecture to me. Why is this not preferred?
>
>-Ashok

Ashok,

Beyond the original rational for the current definition, this is not 
consistent with GMPLS-SONET-SDH, which is in the RFC editor queue, and does 
not match many implementations (at least all we've tested against.)

Kireeti's change is consistent with the other documents (and the reality of 
many implementations).

Lou

>On Thu, Mar 18, 2004 at 09:58:23AM -0800, Kireeti Kompella wrote:
> > Hi,
> >
> > Arthi and Lou pointed out the following typos in the GMPLS routing doc
> > (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
> > Editor's queue:
> >
> > In section 2.4.7 is the following table defining the type of label
> > for various combinations of switching types:
> >
> >       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >       [LSC, LSC] - label represents a lambda
> >       [FSC, FSC] - label represents a port on an OXC
> >       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >       [PSC, LSC] - label represents a lambda
> >       [PSC, FSC] - label represents a port
> >       [TDM, LSC] - label represents a lambda
> >       [TDM, FSC] - label represents a port
> >       [LSC, FSC] - label represents a port
> >
> > The one at issue is [PSC, LSC]; above it says that the label
> > represents a lambda; and in the case of [PSC, TDM] with a fully
> > transparent signal, the above indicates the label represents a TDM
> > time slot.  The proposal is to change this to:
> >
> >       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
> >       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
> >       [LSC, LSC] - label represents a lambda
> >       [FSC, FSC] - label represents a port on an OXC
> >       [PSC, TDM] - fully transparent signal: label represents a port
> >                    ("transparency" is defined in [GMPLS-SONET-SDH])
> >       [PSC, TDM] - non-transparent signal: label represents a TDM time
> >                    slot [GMPLS-SONET-SDH]
> >       [PSC, LSC] - label represents a port
> >       [PSC, FSC] - label represents a port
> >       [TDM, LSC] - label represents a lambda
> >       [TDM, FSC] - label represents a port
> >       [LSC, FSC] - label represents a port
> >
> > Please respond by Friday 3/26, 5pm PST with comments on:
> >
> > a) do you agree with the above change?
> > b) in your implementation today, what do expect the label to represent
> >    i) in the case of [PSC, LSC]?
> >    ii) in the case of [PSC, TDM] with a fully transparent signal?
> > c) if you implement as the draft says, would it be a hardship to change
> >    this?
> >
> > If we can get closure on this, I'll take up the task of modifying the
> > pending RFC with the ADs.
> >
> > Kireeti.
> > -------
>
>--
>
>
>--- Asok the Intern ----------------------------------------
>Ashok Narayanan
>IOS Network Protocols, Cisco Systems
>1414 Mass Ave, Boxborough MA 01719
>Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 21:35:09 +0000
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 2004 15:33:41 -0600
From: Jonathan Sadler <[e-mail]>
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: "Ong, Lyndon" <[e-mail]>, "'Brungard, Deborah A, ALABS'" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 1 addressing
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Hi Kireeti -

Let me try and correct what may be a misperception...

Kireeti Kompella wrote:

> On Tue, 16 Mar 2004, Ong, Lyndon wrote:
> > 3) the client system may use a non-IP address for compatibility
> > reasons, for example, a client with an existing management plane
> > address that the carrier wants to access without having to
> > add a new address and translation mechanism.

<snip>

> For point 3, I view Recommendation 7713.1 which (in my faint
> recollection) has only PNNI addressing, and in particular does not
> have IP addressing, as suggesting that it is NOT a requirement that
> a given solution cater to all possible address types.  So, while this
> might a nice-to-have, it certainly doesn't seem to be an ASON
> requirement.  If you think otherwise, please let me know --
> Recommendation number & section.

G.7713.1 does not include any special procedures to handle IPv4 and IPv6
addressing because special procedures are unnecessary.   The NSAP addresses
used in G.7713.1 are meta-addresses that incorporate a number of addresses
formats, including IPv4 and IPv6.  This is accomplished through the Address
Format Identifier (AFI) octet that exists at the begining of the NSAP
address format.  AFIs have been defined by ISO/IEC for IPv4 and IPv6 --
therefore the procedures for handling IPv4 and IPv6 addresses in G.7713.1
already exist.

For more information on NSAPs, including all the AFIs allocated, please see
ISO/IEC 8348:1996 and ISO/IEC 8348:1996 Amd.1, available free of charge at:

http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/s027728_ISO_IEC_8348_1996(E).zip


http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c030507_ISO_IEC_8348_1996_Amd_1_1998(E).zip

It should be noted that this standards based approach is different than the
_experimental_ approach taken in RFC 1888.  Since NSAP addresses are
variable length, and allow for lengths longer than any of the address spaces
incorporated, there is no loss of information when using an NSAP version of
an IPv4 or IPv6 address.  Contrast this to RFC 1888, where new addresses are
defined in the IPv6 for each NSAP addressed endpoint, and a mapping function
must be used to do a translation.  This is necessary as IPv6 addresses are
too short to accommodate every NSAP.

Consequently, special procedures (ie. new objects) were necessary in
G.7713.2 and G.7713.3 to fully accommodate NSAP addresses.

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: [e-mail]
Delivery-date: Thu, 18 Mar 2004 21:28:26 +0000
Date: Thu, 18 Mar 2004 16:27:33 -0500
From: Ashok Narayanan <[e-mail]>
To: Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Subject: Re: Label type to be used
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i

Personally, I do not agree with this change. I would rather see the
other side of this discrepancy fixed i.e. GMPLS-SONET-SDH should
specify the use of SUKLM label and SONET TSpec for all [PSC, TDM]
links irrespective of transparency. This seems like a more natural
architecture to me. Why is this not preferred?

-Ashok

On Thu, Mar 18, 2004 at 09:58:23AM -0800, Kireeti Kompella wrote:
> Hi,
> 
> Arthi and Lou pointed out the following typos in the GMPLS routing doc
> (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
> Editor's queue:
> 
> In section 2.4.7 is the following table defining the type of label
> for various combinations of switching types:
> 
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a lambda
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
> 
> The one at issue is [PSC, LSC]; above it says that the label
> represents a lambda; and in the case of [PSC, TDM] with a fully
> transparent signal, the above indicates the label represents a TDM
> time slot.  The proposal is to change this to:
> 
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - fully transparent signal: label represents a port
>                    ("transparency" is defined in [GMPLS-SONET-SDH])
>       [PSC, TDM] - non-transparent signal: label represents a TDM time
>                    slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a port
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
> 
> Please respond by Friday 3/26, 5pm PST with comments on:
> 
> a) do you agree with the above change?
> b) in your implementation today, what do expect the label to represent
>    i) in the case of [PSC, LSC]?
>    ii) in the case of [PSC, TDM] with a fully transparent signal?
> c) if you implement as the draft says, would it be a hardship to change
>    this?
> 
> If we can get closure on this, I'll take up the task of modifying the
> pending RFC with the ADs.
> 
> Kireeti.
> -------

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: [phone] (Attn: Ashok Narayanan)




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 21:09:36 +0000
Message-Id: <[e-mail]>
Date: Thu, 18 Mar 2004 16:08:03 -0500
To: Kireeti Kompella <[e-mail]>, [e-mail]
From: Anca Zamfir <[e-mail]>
Subject: Re: Label type to be used
Cc: Anca Zamfir <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Dimitri, Kireeti,
Thanks for the clarifications. The changes proposed look ok.

>a) do you agree with the above change?

yes

>b) in your implementation today, what do expect the label to represent
>    i) in the case of [PSC, LSC]?

port

>    ii) in the case of [PSC, TDM] with a fully transparent signal?

port

>c) if you implement as the draft says, would it be a hardship to change
>    this?

n/a

thanks,
/anca

At 11:19 AM 3/18/2004 -0800, Kireeti Kompella wrote:
>Hi Anca,
>
>On Thu, 18 Mar 2004, Anca Zamfir wrote:
>
> > Does "label represents a port" means port label must be used in signaling?
> > Or a label (from the respective LSP domain) that takes the whole port
> > resource should be used? For example, in the [PSC, TDM] I think that
> > signaling should still use a TDM label. Is this interpretation correct?
>
>"represents a port" means port label should be used.
>
>If you look at GMPLS-SONET-SDH, last para of section 2:
>
>    The traffic parameters and label encoding defined in [RFC3471]
>    Section 3.2 MUST be used for fully transparent STS-1/STM-0/STS-
>                                 ^^^^^^^^^^^^^^^^^
>
>If you use traffic params from 3471/3473, you *cannot* use an SUKLM
>label.  However, section 3.2 of 3471 covers lots of label types (port,
>lambda, ATM/FR), so that reference is not very helpful, except to say
>that the label is not SUKLM.
>
>Kireeti.
>-------





Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 20:28:34 +0000
Message-ID: <[e-mail]>
From: "Varma, Eve L (Eve)" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, "Ong, Lyndon" <[e-mail]>
Cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing
Date: Thu, 18 Mar 2004 15:26:57 -0500
MIME-Version: 1.0
Content-Type: text/plain

Hi,

-----Original Message-----
From: Kireeti Kompella [mailto:[e-mail]]
Sent: Thursday, March 18, 2004 2:47 PM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABS'; [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing


Hi Lyndon,

On Tue, 16 Mar 2004, Ong, Lyndon wrote:

> Hi Folks,
>
> Let me kick off some discussion on issue 1 by noting some of the
> concerns with using existing methods of advertising reachability
> for this purpose:
>
> 1) the client system may not be an IP system, but another transport
> device with an IP control interface - for example, an ADM (add-drop
> multiplexer) acting as a client to an optical network.  Advertising
> reachability using normal means might imply that the system can be
> used for IP traffic routing.
xxxxxxxxxxxxxxxxxxxxxxxxxxx
[elv]

Just a quick side note - If one were dealing with routers as the clients, for example, I think there can still be an issue.

Each router has an IP address, which is routable in the IP layer space.  Of course, that's not the routable address in the optical space.  So if it is required that an optical routable address for the remote IP router be provided in the UNI message, the router will need to know:
+ the IP address of the IP router it wants to talk to for its IP layer operations, AND
+ the optical routable address that the router it wants to talk to is associated with.

Aside from making visible the edge optical NE routable addresses (security issue), the router will also need to track the equivalence between the two, as it will need to maintain the other router's IP routable address
in the forwarding table, as well as its optical layer routable address for UNI signaling purposes.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

There is a section in the GMPLS routing document titled:


1.2. Excluding data traffic from control channels

This section proposes one method for achieving this; and finishes by
saying:

   Other techniques for excluding data traffic from control channels may
   also be needed.

So, we all agree that this is a requirement.  I would not put this in
the ASON Routing Reqts doc, though, unless this is written in some
ITU-T Recommendation, given that the ASON Routing Reqts are *not* to
introduce new requirements, however useful or sane they may be for
ASON (or other) networks.

> 2) the client system may use a different addressing space than the
> internal network addressing space.  Carriers may wish to use a
> different addressing space for administrative or policy reasons.
>
> (Note: one model for this is the VPN model, which would allow
> private networks to have their own address spaces.  Another model
> is a telephone number-like model, where clients obtain addresses
> from a space maintained by the carrier.)
>
> 3) the client system may use a non-IP address for compatibility
> reasons, for example, a client with an existing management plane
> address that the carrier wants to access without having to
> add a new address and translation mechanism.

Again, these are both good, but unless you can find text to this
effect in an ITU-T Recommendation on ASON routing requirements, we
cannot put this in the ASON Routing Requirements document.

If there is such text (for any of points 1, 2 or 3), it would be
useful in the context of this debate to post it to this list.

For point 3, I view Recommendation 7713.1 which (in my faint
recollection) has only PNNI addressing, and in particular does not
have IP addressing, as suggesting that it is NOT a requirement that
a given solution cater to all possible address types.  So, while this
might a nice-to-have, it certainly doesn't seem to be an ASON
requirement.  If you think otherwise, please let me know --
Recommendation number & section.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[elv]  In Rec. G.807, Section 7.4 on naming and addressing, I've excerpted some points - hope this is helpful:

Separation of server layer name and client layer name, as well as user domain name and service provider domain name, provides an abstraction barrier between name processing and connection operations. Some properties of the naming and addressing in the switched network are:
.	Name independence: The client (user) name should not make assumptions on what capabilities are offered by the server (service provider) name, and thus the semantics of the two name spaces should be separate and distinct. This does not place any constraints on the syntax of client and server layer name spaces, or on the user and service provider name spaces.
.	Server layer name space: The server layer name space provides identification of the node and the resources available for connection operations at that layer. Server names are applicable at the server layer only, and should not be communicated to the client layer.
.	Service provider name space: The service provider name space provides identification of the node and the resources available for connection operations and is an NNI issue. Service provider names are applicable in the service provider domain, and should not be communicated to the user.
.    Name translation: This provides multiple purposes. The translation function may provide mapping of the client layer name to server layer name (used for routeing decision through the server layer), user domain name to service provider domain name, or provide mapping of connection identifier to a connection in the server layer. These translation functions will likely be performed via one or more directory services.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Thanks,
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 20:04:25 +0000
Date: Thu, 18 Mar 2004 12:03:09 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Jonathan Sadler <[e-mail]>
cc: [e-mail]
Subject: Re: Stepping back from the ASON Routing Discussion
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Jonathan,

On Wed, 17 Mar 2004, Jonathan Sadler wrote:

> > The first sentence is about requirements.
> > Do we, or do we not, need to support advertising UNI Transport Resource address prefixes?
>
> There is a requirement to be able to advertise reachability (G.7715
> sec7.1.1, G.7715.1 sec 9.4).  G.7715.1 states:
>   Reachability Information: Reachability information describes
>   the set of endpoints that are reachable by the associated node.
>   It may be advertised either as a set of UNI Transport Resource
>   addresses/address prefixes, or a set of associated
>   SNPP IDs/SNPP ID prefixes, the selection of which must be
>   consistent within the applicable scope.
> so technically, there isn't a requirement to advertise UNI Transport
> Resource Addresses -- the requirement is to advertise reachability
> in terms of SNPP IDs or UNI Transport Resources Addresses.

Thanks for the references!  This is exactly what I want to see.  What
I don't want is an ITU-T Liaison complaining that we are re-doing
their requirements :-)

> It should be noted that there is a unique attribute of SNPP Prefixes
> and UNI Transport Resource Addresses -- they exist independant of
> layer networks.  More specifically, UNI Transport Resource Addresses
> are used to name an Access Group Container, where the Access Groups
> within the Container can be in one or more layer networks.  So, it
> cannot be assumed that a specific UNI Transport Resource Address is
> in Layer Network A or B.

Okay, noted.

> > 2.
...
> > Do we, or do we not need to support a physically separated
> > architecture with a 1-n relationship between control plane and
> > transport plane entities?
>
> Yes.

If you have references, that would be great.  In my reading (I'll look
for the reference), I understood this to be: ASON doesn't restrict the
architecture to physically co-located or to physically separate, i.e.,
a particular solution may do either.  In that case, unless GMPLS
supports both, we should just state which approach GMPLS takes.

(As an aside, I'm not convinced that GMPLS is restricted to a single
box architecture.  The combination of GMPLS and GSMP should yield a
non-co-located architecture.  However, this may not be as well-fleshed
out as one wishes.  But this is orthogonal to the requirements.)

> > 3.
...
> > The requirements questions are:
> > A. What does ASON require in terms of evolution of hierarchies?
>
> The requirements stated in G.7715.1 are:
>   "...the routing protocol shall be capable of supporting
>   architectural evolution in terms of number of hierarchical
>   levels, as well as aggregation and segmentation of RAs."
>
> This is further illustrated as being:
>  - Segmentation of one Routing Area into two separate RAs
>  - Aggregation of two RAs into one RA
>  - Renaming of RAs
>  - Insertion of an RA into the hierarchy
>  - Deletion of an RA from the hierarchy
>
> Insertion and Deletion can be done at any point in the hierarchy --
> it is not limited to just the top or bottom of the hierarchy.

Perfect.

> > B. Are these requirements immediate and high priority?
>
> No statement of immediate/high priority exists in the ASON documents
> for any ASON requirement.

That's a good point.  When we liaize (forgive me!) this back to the
ITU-T SG14, we should mention that we have prioritized the
requirements, and ask if they have comments on that.

Thanks again for bringing us back to the DT charter!

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 19:47:37 +0000
Date: Thu, 18 Mar 2004 11:47:05 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>
cc: [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Lyndon,

On Tue, 16 Mar 2004, Ong, Lyndon wrote:

> Maybe the issue needs to be worded more clearly...
>
> Can existing address reachability mechanisms support
> (and if so, how)
>
> a) distinguishing between the control plane address
> for a client and the data plane address for a client
> which might be two different things?
>
> b) distinguishing between the internal network address
> space and an external client address space?
>
> c) advertising reachability to a client whose address
> space is non-IP?

All excellent questions.  Thanks for the summary.

I'll go back to my meta-question:

Are these ASON routing requirements?  If so, can you quote chapter and
verse?  The clear charter of the ASON Routing Reqts DT is to take
*existing* ASON routing requirements, evaluate them against what's in
GMPLS routing, and come up with a list of remaining requirements to
set the stage for an ASON Routing Extensions document.  Not to come up
with new requirements, however excellent they may be.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 19:47:22 +0000
Date: Thu, 18 Mar 2004 11:46:53 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>
cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Lyndon,

On Tue, 16 Mar 2004, Ong, Lyndon wrote:

> Hi Folks,
>
> Let me kick off some discussion on issue 1 by noting some of the
> concerns with using existing methods of advertising reachability
> for this purpose:
>
> 1) the client system may not be an IP system, but another transport
> device with an IP control interface - for example, an ADM (add-drop
> multiplexer) acting as a client to an optical network.  Advertising
> reachability using normal means might imply that the system can be
> used for IP traffic routing.

There is a section in the GMPLS routing document titled:

1.2. Excluding data traffic from control channels

This section proposes one method for achieving this; and finishes by
saying:

   Other techniques for excluding data traffic from control channels may
   also be needed.

So, we all agree that this is a requirement.  I would not put this in
the ASON Routing Reqts doc, though, unless this is written in some
ITU-T Recommendation, given that the ASON Routing Reqts are *not* to
introduce new requirements, however useful or sane they may be for
ASON (or other) networks.

> 2) the client system may use a different addressing space than the
> internal network addressing space.  Carriers may wish to use a
> different addressing space for administrative or policy reasons.
>
> (Note: one model for this is the VPN model, which would allow
> private networks to have their own address spaces.  Another model
> is a telephone number-like model, where clients obtain addresses
> from a space maintained by the carrier.)
>
> 3) the client system may use a non-IP address for compatibility
> reasons, for example, a client with an existing management plane
> address that the carrier wants to access without having to
> add a new address and translation mechanism.

Again, these are both good, but unless you can find text to this
effect in an ITU-T Recommendation on ASON routing requirements, we
cannot put this in the ASON Routing Requirements document.

If there is such text (for any of points 1, 2 or 3), it would be
useful in the context of this debate to post it to this list.

For point 3, I view Recommendation 7713.1 which (in my faint
recollection) has only PNNI addressing, and in particular does not
have IP addressing, as suggesting that it is NOT a requirement that
a given solution cater to all possible address types.  So, while this
might a nice-to-have, it certainly doesn't seem to be an ASON
requirement.  If you think otherwise, please let me know --
Recommendation number & section.

Thanks,
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 19:44:23 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Stepping back from the ASON Routing Discussion
Date: Thu, 18 Mar 2004 11:43:26 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian, et al,

You mention that there are two developments of the following requirement:

["It is a requirement of ASON routing to support networks that contain
devices
that do not contain the capabilities to participate fully (or at all) in the
routing protocols run within the network."]

The second development listed below seems to assume that the islands within
the network will not be represented to the routing protocol only when they
contain devices that do not support routing.

However, this is where I would appreciate some clarification to
help clear some of my understanding of this discussion.

It seems to me that while one implication of the above requirement
is certainly this, it is also possible that islands are not represented
to the routing protocol, simply because the provider does not wish to
reveal the topology of its network beyond a certain level of granularity
(even if the devices do support routing protocols within those islands).

This would be increasingly so when hierarchy is implemented. (The devices
could then support routing at a given level of the hierarchy, but may be
abstracted at the next (higher) level.)

While I understand that the current discussion focuses initially on a given
level of the hierarchy, I think the second development you talk about
below is also a consequence of the need to support hierarchy.

Or, did I not get it right?

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, March 18, 2004 3:43 AM
> To: [e-mail]; Don Fedyk
> Cc: [e-mail]
> Subject: Re: Stepping back from the ASON Routing Discussion
>
>
> Don,
>
> Just picking out one snippet...
>
> > >>Do we, or do we not need to support a physically separated
> > >>architecture with a 1-n relationship between control plane
> > >>and transport plane entities?
> > >
> > > I would say yes. The requirement I see here is devices not capable of
> > > participating fully in GMPLS routing.
>
> I had to read this several times before I got it. Sorry.
>
> You mean that...
> "It is a requirement of ASON routing to support networks that
> contain devices that do not
> contain the capabilities to participate fully (or at all) in the
> routing protocols run
> within the network."
>
> That sounds a reasonable requirement.
>
> There are two developments of this requirement.
>
> The first is where the routing responsiblity for the device is
> taken on "by proxy" by a
> control plane entity such as one that Lyndon, Jonathan and I have
> been drawing. In this
> case, although the device is not participating in the routing
> protocols within the
> network, it is fully represented and there are no issues
> (although we must ensure that
> this function is covered by the requirements).
>
> In the second case, ther are islands within the network which are
> simply not represented
> to the routing protocol. This gives me a greater problem. Clearly
> you cannot route through
> a part of the network unless it appears to be connected in the
> TEDB. In this case, I
> suggest that what is needed is to represent those (legacy?)
> devices/subnetworks as
> Forwarding Adjacencies or virtual TE links. This requires some
> advertisement by a control
> plane entity on behalf of the devices/subnetworks, but does not
> expose the details of the
> connectivity of the devices that do not support routing.
>
> Some of you may (from time to time) hear me burble on about the
> fact that soft permanent
> LSPs should not simply cover the case where the permanent part is
> at the edge of the
> network. When I ramble in this way, I am talking about the second
> case, above.
>
> Cheers,
> Adrian
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 19:20:27 +0000
Date: Thu, 18 Mar 2004 11:19:33 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Anca Zamfir <[e-mail]>
cc: [e-mail]
Subject: Re: Label type to be used
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Anca,

On Thu, 18 Mar 2004, Anca Zamfir wrote:

> Does "label represents a port" means port label must be used in signaling?
> Or a label (from the respective LSP domain) that takes the whole port
> resource should be used? For example, in the [PSC, TDM] I think that
> signaling should still use a TDM label. Is this interpretation correct?

"represents a port" means port label should be used.

If you look at GMPLS-SONET-SDH, last para of section 2:

   The traffic parameters and label encoding defined in [RFC3471]
   Section 3.2 MUST be used for fully transparent STS-1/STM-0/STS-
                                ^^^^^^^^^^^^^^^^^

If you use traffic params from 3471/3473, you *cannot* use an SUKLM
label.  However, section 3.2 of 3471 covers lots of label types (port,
lambda, ATM/FR), so that reference is not very helpful, except to say
that the label is not SUKLM.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 19:11:31 +0000
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 2004 20:12:19 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: [e-mail]
Cc: Anca Zamfir <[e-mail]>, Kireeti Kompella <[e-mail]>, [e-mail]
Subject: Re: Label type to be used
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

oops... pushed too fast

 > note: transparent =/= photonic (that LSC implies)

add: "Transparency is not applied at the interfaces with
the initiating and terminating LSRs, but is only applied
between intermediate LSRs."

 > so your second assumption seems to be the right one

[e-mail] wrote:
> anca,
> 
> VC/STS signal:
> - Label Request per GMPLS-SONET-SDH
> - Label per GMPLS-SONET-SDH
> 
> Section/RS or Line/MS transparent STS-1/STM-0/STS-
> 3*N/STM-N (N=1, 4, 16, 64, 256) signal:
> - Label Request per GMPLS-SONET-SDH
> - Label per RFC 3471 Section 3.2 => port (represents
>   the section/RS or line/MS)
> 
> Fully transparent signal:
> - Label Request per RFC 3471 Section 3.1
> - Label per RFC 3471 Section 3.2 => port (represents
>   whole signal)
> 
> note: transparent =/= photonic (that LSC implies)
> 
> so your second assumption seems to be the right one
> 
> ---
> 
> Anca Zamfir wrote:
> 
>> Hi,
>> Does "label represents a port" means port label must be used in 
>> signaling? Or a label (from the respective LSP domain) that takes the 
>> whole port resource should be used? For example, in the [PSC, TDM] I 
>> think that signaling should still use a TDM label. Is this 
>> interpretation correct?
>> Thanks,
>> /anca
>>
>> At 09:58 AM 3/18/2004 -0800, Kireeti Kompella wrote:
>>
>>> Hi,
>>>
>>> Arthi and Lou pointed out the following typos in the GMPLS routing doc
>>> (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
>>> Editor's queue:
>>>
>>> In section 2.4.7 is the following table defining the type of label
>>> for various combinations of switching types:
>>>
>>>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>>>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>       [LSC, LSC] - label represents a lambda
>>>       [FSC, FSC] - label represents a port on an OXC
>>>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>       [PSC, LSC] - label represents a lambda
>>>       [PSC, FSC] - label represents a port
>>>       [TDM, LSC] - label represents a lambda
>>>       [TDM, FSC] - label represents a port
>>>       [LSC, FSC] - label represents a port
>>>
>>> The one at issue is [PSC, LSC]; above it says that the label
>>> represents a lambda; and in the case of [PSC, TDM] with a fully
>>> transparent signal, the above indicates the label represents a TDM
>>> time slot.  The proposal is to change this to:
>>>
>>>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>>>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>>       [LSC, LSC] - label represents a lambda
>>>       [FSC, FSC] - label represents a port on an OXC
>>>       [PSC, TDM] - fully transparent signal: label represents a port
>>>                    ("transparency" is defined in [GMPLS-SONET-SDH])
>>>       [PSC, TDM] - non-transparent signal: label represents a TDM time
>>>                    slot [GMPLS-SONET-SDH]
>>>       [PSC, LSC] - label represents a port
>>>       [PSC, FSC] - label represents a port
>>>       [TDM, LSC] - label represents a lambda
>>>       [TDM, FSC] - label represents a port
>>>       [LSC, FSC] - label represents a port
>>>
>>> Please respond by Friday 3/26, 5pm PST with comments on:
>>>
>>> a) do you agree with the above change?
>>> b) in your implementation today, what do expect the label to represent
>>>    i) in the case of [PSC, LSC]?
>>>    ii) in the case of [PSC, TDM] with a fully transparent signal?
>>> c) if you implement as the draft says, would it be a hardship to change
>>>    this?
>>>
>>> If we can get closure on this, I'll take up the task of modifying the
>>> pending RFC with the ADs.
>>>
>>> Kireeti.
>>> -------
>>
>>
>>
>>
>>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 19:03:24 +0000
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 2004 20:03:27 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Anca Zamfir <[e-mail]>
Cc: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: Re: Label type to be used
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

anca,

VC/STS signal:
- Label Request per GMPLS-SONET-SDH
- Label per GMPLS-SONET-SDH

Section/RS or Line/MS transparent STS-1/STM-0/STS-
3*N/STM-N (N=1, 4, 16, 64, 256) signal:
- Label Request per GMPLS-SONET-SDH
- Label per RFC 3471 Section 3.2 => port (represents
   the section/RS or line/MS)

Fully transparent signal:
- Label Request per RFC 3471 Section 3.1
- Label per RFC 3471 Section 3.2 => port (represents
   whole signal)

note: transparent =/= photonic (that LSC implies)

so your second assumption seems to be the right one

---

Anca Zamfir wrote:

> Hi,
> Does "label represents a port" means port label must be used in 
> signaling? Or a label (from the respective LSP domain) that takes the 
> whole port resource should be used? For example, in the [PSC, TDM] I 
> think that signaling should still use a TDM label. Is this 
> interpretation correct?
> Thanks,
> /anca
> 
> At 09:58 AM 3/18/2004 -0800, Kireeti Kompella wrote:
> 
>> Hi,
>>
>> Arthi and Lou pointed out the following typos in the GMPLS routing doc
>> (draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
>> Editor's queue:
>>
>> In section 2.4.7 is the following table defining the type of label
>> for various combinations of switching types:
>>
>>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>       [LSC, LSC] - label represents a lambda
>>       [FSC, FSC] - label represents a port on an OXC
>>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>       [PSC, LSC] - label represents a lambda
>>       [PSC, FSC] - label represents a port
>>       [TDM, LSC] - label represents a lambda
>>       [TDM, FSC] - label represents a port
>>       [LSC, FSC] - label represents a port
>>
>> The one at issue is [PSC, LSC]; above it says that the label
>> represents a lambda; and in the case of [PSC, TDM] with a fully
>> transparent signal, the above indicates the label represents a TDM
>> time slot.  The proposal is to change this to:
>>
>>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>>       [LSC, LSC] - label represents a lambda
>>       [FSC, FSC] - label represents a port on an OXC
>>       [PSC, TDM] - fully transparent signal: label represents a port
>>                    ("transparency" is defined in [GMPLS-SONET-SDH])
>>       [PSC, TDM] - non-transparent signal: label represents a TDM time
>>                    slot [GMPLS-SONET-SDH]
>>       [PSC, LSC] - label represents a port
>>       [PSC, FSC] - label represents a port
>>       [TDM, LSC] - label represents a lambda
>>       [TDM, FSC] - label represents a port
>>       [LSC, FSC] - label represents a port
>>
>> Please respond by Friday 3/26, 5pm PST with comments on:
>>
>> a) do you agree with the above change?
>> b) in your implementation today, what do expect the label to represent
>>    i) in the case of [PSC, LSC]?
>>    ii) in the case of [PSC, TDM] with a fully transparent signal?
>> c) if you implement as the draft says, would it be a hardship to change
>>    this?
>>
>> If we can get closure on this, I'll take up the task of modifying the
>> pending RFC with the ADs.
>>
>> Kireeti.
>> -------
> 
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 18:30:55 +0000
Message-Id: <[e-mail]>
Date: Thu, 18 Mar 2004 13:30:05 -0500
To: Kireeti Kompella <[e-mail]>
From: Anca Zamfir <[e-mail]>
Subject: Re: Label type to be used
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,
Does "label represents a port" means port label must be used in signaling? 
Or a label (from the respective LSP domain) that takes the whole port 
resource should be used? For example, in the [PSC, TDM] I think that 
signaling should still use a TDM label. Is this interpretation correct?
Thanks,
/anca

At 09:58 AM 3/18/2004 -0800, Kireeti Kompella wrote:
>Hi,
>
>Arthi and Lou pointed out the following typos in the GMPLS routing doc
>(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
>Editor's queue:
>
>In section 2.4.7 is the following table defining the type of label
>for various combinations of switching types:
>
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a lambda
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
>
>The one at issue is [PSC, LSC]; above it says that the label
>represents a lambda; and in the case of [PSC, TDM] with a fully
>transparent signal, the above indicates the label represents a TDM
>time slot.  The proposal is to change this to:
>
>       [PSC, PSC] - label is carried in the "shim" header [RFC3032]
>       [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
>       [LSC, LSC] - label represents a lambda
>       [FSC, FSC] - label represents a port on an OXC
>       [PSC, TDM] - fully transparent signal: label represents a port
>                    ("transparency" is defined in [GMPLS-SONET-SDH])
>       [PSC, TDM] - non-transparent signal: label represents a TDM time
>                    slot [GMPLS-SONET-SDH]
>       [PSC, LSC] - label represents a port
>       [PSC, FSC] - label represents a port
>       [TDM, LSC] - label represents a lambda
>       [TDM, FSC] - label represents a port
>       [LSC, FSC] - label represents a port
>
>Please respond by Friday 3/26, 5pm PST with comments on:
>
>a) do you agree with the above change?
>b) in your implementation today, what do expect the label to represent
>    i) in the case of [PSC, LSC]?
>    ii) in the case of [PSC, TDM] with a fully transparent signal?
>c) if you implement as the draft says, would it be a hardship to change
>    this?
>
>If we can get closure on this, I'll take up the task of modifying the
>pending RFC with the ADs.
>
>Kireeti.
>-------





Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 18:01:12 +0000
Date: Thu, 18 Mar 2004 09:58:23 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: Label type to be used
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

Arthi and Lou pointed out the following typos in the GMPLS routing doc
(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
Editor's queue:

In section 2.4.7 is the following table defining the type of label
for various combinations of switching types:

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [LSC, LSC] - label represents a lambda
      [FSC, FSC] - label represents a port on an OXC
      [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [PSC, LSC] - label represents a lambda
      [PSC, FSC] - label represents a port
      [TDM, LSC] - label represents a lambda
      [TDM, FSC] - label represents a port
      [LSC, FSC] - label represents a port

The one at issue is [PSC, LSC]; above it says that the label
represents a lambda; and in the case of [PSC, TDM] with a fully
transparent signal, the above indicates the label represents a TDM
time slot.  The proposal is to change this to:

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [LSC, LSC] - label represents a lambda
      [FSC, FSC] - label represents a port on an OXC
      [PSC, TDM] - fully transparent signal: label represents a port
                   ("transparency" is defined in [GMPLS-SONET-SDH])
      [PSC, TDM] - non-transparent signal: label represents a TDM time
                   slot [GMPLS-SONET-SDH]
      [PSC, LSC] - label represents a port
      [PSC, FSC] - label represents a port
      [TDM, LSC] - label represents a lambda
      [TDM, FSC] - label represents a port
      [LSC, FSC] - label represents a port

Please respond by Friday 3/26, 5pm PST with comments on:

a) do you agree with the above change?
b) in your implementation today, what do expect the label to represent
   i) in the case of [PSC, LSC]?
   ii) in the case of [PSC, TDM] with a fully transparent signal?
c) if you implement as the draft says, would it be a hardship to change
   this?

If we can get closure on this, I'll take up the task of modifying the
pending RFC with the ADs.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 14:45:02 +0000
Message-ID: <0e8201c40cf7$79b05070$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Eric Mannie" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: <[e-mail]>
Subject: WG Chair review of draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
Date: Thu, 18 Mar 2004 14:41:32 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,
Please find attached my nits review of this draft in WG last call.

Thanks,
Adrian


Category: Standard Track
Can a terminology draft be standards track? I don't know.


1. Abstract
Please don't number the abstract.


1. Abstract
   This document defines a common terminology for Generalized Multi-
   Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
   protection and restoration) that are under consideration by the
   CCAMP Working Group. The proposed terminology is intended to be
   independent of the underlying transport technologies covered by
   GMPLS.
Please rephrase this to be more definitive. For example,
   This document defines a common terminology for Generalized Multi-
   Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
   protection and restoration). The terminology is independent of 
   the underlying transport technologies covered by GMPLS.


Need a table of contents please.


2. Contributors
I think some of the contact details are ood


3. Introduction
Please rephrase this to be more definitive as in the abstract.


4.2 Traffic Types
   B. Extra traffic:
   Extra traffic is not protected by definition, but may be
   restored.
I agree that this is normally the case, but is it necessarily
the case? I.e. is it "by definition" or "by convention"?
So, for example, extra traffic could be transmitted using 1+1
protection on recovery resources of two other LSPs such that
the pre-emption of traffic on one set of recovery resources 
would have minimal impact on the extra traffic.


4.2 Traffic Types
   B. Extra traffic:
Could you make it clear that the extra traffic does not need to
commence or be terminated at the ends of the LSPs/spans that it
uses.


4.3 LSP/Span Protection and Restoration
   LSP/span protection denotes the paradigm whereby one or more
   dedicated protection LSP(s)/span(s) is/are fully established to
   protect one ore more working LSP(s)/span(s).
For "ore" read "or"


4.5 Recovery Domain
   The recovery operation is contained within the recovery domain. A
   GMPLS recovery domain must be entirely contained within a GMPLS
   domain. A GMPLS domain may contain multiple recovery domains.
There is no definition of "GMPLS domain".
A reference would do (but I don't think I have seen the term defined
elsewhere, so you'll need to define it here).


4.10 Switching Mechanism
   A switch is an action that can be performed at both the bridge and
   the selector. This action is as follows:
Would it be possible to change this term to "switch-over"?
I am concerned that we already have a switching term (cf MPL*S*).
(Sorry, there are a few uses of this term throughout the three
documents.)


4.12 Failure Reporting
Not sure of the value or completeness of this section.


4.13 External commands
   B. Lockout of normal traffic:
   A configuration action initiated externally that results in the
   normal traffic being temporarily not allowed to be routed over its
   recovery LSP/span.
Please clarify that in this case extra traffic is still allowed on the
recovery LSP/span.


4.13 External commands
You seem to be missing "Forced switch for recovery LSP/span"


4.16 Recovery Schemes Related Time and Durations
This section seems to mix policy-controlled times (such as hold-off)
with times that are features of the data plane technology and times
that are features of the control plane technology (such as detection
time).
The second category is missing some values (such as fault 
localization/isolation).
Perhaps it would be best to make this section cover only policy timers,
and put the remaining information into section 5 that is a more complete
definition of the phases.
Note also that "F. Recovery time:" needs to include propagation time. It
is not clear whether you intended this to be included in the "reporting 
of the signal fail or degrade" mentioned in the "B. Correlation time:"
and "C. Hold-off time:", or included in the "E. Switching time:"


5. Recovery Phases
   - Phase 4: Recovery (Protection or Restoration)
   See above.
   - Phase 5: Reversion (Normalization)
   See above.
Please give section references.


Section 5.1
   C. Deciding Entity (part of the failure recovery decision process):
   An entity that makes the recovery decision or select the recovery
   resources.
Read "selects"


6.1 1+1 protection
Capital "P"


Section 6.3 Notes
1. Please put a space as in "Note 1:"
2. Are these notes intended to apply to the whole of
   section 6 or just to section 6.3? I think the whole
   of section 6.
   Perhaps introduce a new section 6.4 "Notes on Protection Schemes"


New IPR section please.


10.1 Normative References
I would prefer that the non-IETF references became Informational
References. I don't think we would lose anything by doing this.


10.2 Informative References
Perhaps "Informational" would be more accurate :-)


11. Acknowledgments
   Valuable comments and input were received from many people.
Personally, I find that a bit off target. But if you no longer have
a record, so be it.


12. Author's Addresses
Read "Editors' Addresses"


New copyright boiler plate please, and fill in the address.




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 14:44:47 +0000
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 2004 15:44:48 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: Don Fedyk <[e-mail]>, [e-mail]
Subject: Re: Stepping back from the ASON Routing Discussion
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

adrian, so let me try to recap here, what are the combination
using the terminology you were introducing that are w/i scope

1) R(i) 1:1 L(i) with every L(i) 1:1 P(i)
2) R(i) 1:n L(j) with every L(j) 1:1 P(j)
3) R(i) 1:1 L(i) with every L(i) 1:m P(j)
4) R(i) 1:1 L(i) with some  L(i) 1:0 P(j) and some L(i) 1:1 P(i)
5) R(i) 1:n L(j) with some  L(j) 1:0 P(k) and some L(j) 1:1 P(j)

if this is the case, are we missing something that needs to be
further covered ?

also there is no discussion here about DP<->CP realization and
or physical co-location issue(s), this is completely orthogonal
to the present discussion (some responses on the list show this
is still not clearly integrated)

Adrian Farrel wrote:
> Don,
> 
> Just picking out one snippet...
> 
> 
>>>>Do we, or do we not need to support a physically separated
>>>>architecture with a 1-n relationship between control plane
>>>>and transport plane entities?
>>>
>>>I would say yes. The requirement I see here is devices not capable of
>>>participating fully in GMPLS routing.
> 
> 
> I had to read this several times before I got it. Sorry.
> 
> You mean that...
> "It is a requirement of ASON routing to support networks that contain devices that do not
> contain the capabilities to participate fully (or at all) in the routing protocols run
> within the network."
> 
> That sounds a reasonable requirement.
> 
> There are two developments of this requirement.
> 
> The first is where the routing responsiblity for the device is taken on "by proxy" by a
> control plane entity such as one that Lyndon, Jonathan and I have been drawing. In this
> case, although the device is not participating in the routing protocols within the
> network, it is fully represented and there are no issues (although we must ensure that
> this function is covered by the requirements).
> 
> In the second case, ther are islands within the network which are simply not represented
> to the routing protocol. This gives me a greater problem. Clearly you cannot route through
> a part of the network unless it appears to be connected in the TEDB. In this case, I
> suggest that what is needed is to represent those (legacy?) devices/subnetworks as
> Forwarding Adjacencies or virtual TE links. This requires some advertisement by a control
> plane entity on behalf of the devices/subnetworks, but does not expose the details of the
> connectivity of the devices that do not support routing.
> 
> Some of you may (from time to time) hear me burble on about the fact that soft permanent
> LSPs should not simply cover the case where the permanent part is at the edge of the
> network. When I ramble in this way, I am talking about the second case, above.
> 
> Cheers,
> Adrian
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 13:10:10 +0000
Message-ID: <0e7101c40cea$1aef7dc0$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Subject: CCAMP WG Minutes - 59th IETF Seoul
Date: Thu, 18 Mar 2004 13:05:32 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E5E_01C40CE9.B22C2F90"

This is a multi-part message in MIME format.

------=_NextPart_000_0E5E_01C40CE9.B22C2F90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Common Control and Measurement Plane WG (ccamp)

THURSDAY, March 4 at 0900-1130
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

CHAIRS: Kireeti Kompella <[e-mail]>
        Adrian Farrel <[e-mail]>

=3D=3D=3D
Group Admin
---
Chairs
  Admin - Nothing much to say (in English anyway)
        - In Korean, however, the following was said:
          "Jigeumbuteo CCAMP meetingeul sijakhagesumnida".

  Agenda bash (5 mins) - No changes
  Status of WG drafts and milestones
    Adrian's slides showed that we do have some draft
    congestion in the WG.
    - RFC editor queue
    - status of IANA for SONET/SDH
      Kireeti talked about an issue with SONET/SDH IANA
      assignments
    - need a means to get early assignments.
      There is WIP to accomplish this, and it is moving
      ahead.
    - future allocation of "experimental" values

Liaisons
---
Marco Carugi talked about work in SG-13 (SG13 liaison).
  He covered topics, new study areas, timescales, objectives
  and status. They are also looking for people interested in
  doing work in these areas.

  An L1 VPN questionnaire and framework draft were attached
  to the liaison.

  Tomonori Takeda talked about the technical issues and
  details of the work.

  Monique Morrow had a couple of clarification for Marco -
  When will the consent portion of the work be done in the
  ITU?

    Marco said that the different pieces of work were
    progressing at different speeds. Some material is
    already embodied in recommendations. The next SG13
    meetings are in June and September.

  Dimitri Papadimitriou asked if the draft (l1vpn
  framework) provided in the liaison could include a
  summarization (as conclusion) on the expected GMPLS work
  for the CCAMP WG, this would clarify the intent of the
  liaison in term of expected effort for the CCAMP WG

    Kireeti answered. If CCAMP's rechartering this month
    results in the addition of L1VPNs to the charter, then
    a Liaison response from the IETF will include this
    information, plus a request for a cooperative effort,
    preferably along the lines of the ASON routing work,
    wherein the ITU-T defines the requirements and the IETF
    does the protocol extensions.

  Alex Zinin said that we will have to make a decision at
  some point as to whether or not we want to do this work
  here.

  Kohei Shiomoto said that the protocol for the L1VPN should
  be developed at the IETF as long as it uses IP protocol.
  There are already internet-drafts on GVPN and CCAMP is the
  best place to discuss it.

  Deborah Brungard said that there is work and some synergy
  and that we should continue to work on this.

    Monique Morrow agrees that we should work on that.

    Marco added some comments that were not captured in the
    minutes.

    Malcolm Betts said he also feels that we should do this.

  Adrian took a quick poll and it seems as if nobody is
  against doing this work.

  Kireeti reminded people to continue this discussion on
  the list.

---
Lyndon Ong talked about work in SG-15 (3 liaisons).

  Liaisons were on ASON routing requirements, response to
  comments on Q14 for G.7713.2 and comments on the CCAMP
  ASON signaling requirements draft.

  Lyndon spent much of the time on the details of response
  to comments on Q14. It seems that some of the differences
  in architectural models revolve around "end-to-end" and
  "call segment" operating models.

  Kireeti asked for the reply by date.

    Lyndon did not have that.

    Steve Trowbridge said that the meeting starts on April
    19th

  Dimitri had a question on the deadline. There is a
  deadline on G.7713 (April 2004), isn't there a similar
  deadline on G.7713.2 (since this is the document to which
  convergence is expected) ?

    Lyndon said that he had not gone into that. He gave a
    reason, but this was not captured in the minutes.

  Deborah said that the liaison for 7713.2 does not say any
  thing about convergence.

    Lyndon said that they are still looking for a "meeting
    of the minds".

  Deborah said that there is an issue with G.7713.2 because
  of compatibility.

    Lyndon said that yes there has been a lot of discussion
    of compatibility questions and requirements.

  Kireeti said that we should not discuss this here.

  Steve Trowbridge added some comments that were not
  captured in the minutes.

  Kireeti asked the WG to take this discussion to the list
  and try to keep that discussion on a productive basis.

  Adrian said that he wanted to recognize the efforts of
  the ITU folks in this work.

=3D=3D=3D
ASON Requirements and Solutions
---
Dimitri Papadimitriou presented status of ASON Signaling
Requirements (draft-ietf-ccamp-gmpls-ason-reqts-05.txt.

  The requirements were driven by last year's liaison from
  the ITU.

  The discussion slides proposed to defer to the GROW WG
  (cf. RIFT WG item) concerning the (external) non-IP
  reachability issue since much broader than just CCAMP
  GMPLS/ASON context

  After this meeting, Dimitri would like to re-spin the
  draft and have a two week last call.

  Lyndon said he want to capture the requirement on "non-IP
  reachability" - whether or not we will work on it here

  Kireeti said that we first need to understand importance
  of this and then we can look to the ADs for guidance on
  handling this.  He also said that we should take some time
  to work out what we want to say to the ITU when we include
  the current draft.

---
Dimitri Papadimitriou gave status ASON Signaling Solutions
(draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt) status.

  He would like feedback on whether or not the current draft
  deals correctly with the session attribute object that
  encodes the long call_id (alternatives were also proposed)

  His objective at this point is to try to have a document
  ready for last call for the next IETF 60 meeting in San
  Diego

  Lyndon suggested that we might remove the comparison with
  G.7713 from the draft.

    Adrian asked if this meant that the interworking draft
    for RFC3473/4 interworking was now obsolete.

      Lyndon said maybe, if interworking is removed as a
      requirement.

---
Lou Berger talked about Egress Control -
draft-berger-gmpls-egress-control-01.txt -

  Original egress label control became explicit label
  control. This draft attempts to capture the original
  intent.

  He wants to know if the WG feels that this is ready to
  be a BCP and what the chairs think the next steps should
  be.

  Lou re-iterated that the purpose and scope of the draft
  is for clarification. He does not see any value in adding
  to this intent or combining it with other work.

  Adrian then took a poll and nobody objected to take this
  on as a WG item (more than a third were in favor).

---
Lyndon Ong went over status on ASON Routing Requirements -
draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

  He includes in his presentation the Design Team's
  conclusions as to what there is agreement about what's
  missing from GMPLS (delta), and what are the areas on
  which there is no agreement about what's missing from
  GMPLS.

  Vishal Sharma asked if the three issues (slide 6) were
  already opened up for discussion on the list, or would
  they be formally opened up with the DT members initiating
  a discussion on these on the list?

    Lyndon Ong replied that a discussion had not been
    formally opened up yet (although people were free to
    discuss/comment).

      Kireeti asked Lyndon to more formally open this
      discussion on the mailing list.

  Vishal Sharma said that he supports this.

  Kireeti said he would like - after checking with the AD -
  that we should take this work to the IS-IS and OSPF WGs.

    Alex Zinin said this is a good idea.

=3D=3D=3D
Tunnel Trace
---
Ron Bonica presented status on draft-bonica-tunproto-05.txt

  The solution is very similar to Trace-Route but does not
  require that each node in a tunnel supports TTL decrement.

  He gave a few examples as to how the idea in the draft
  will work in a few scenarios.

  There are a couple of outstanding issues:
  - trace requires a route to tunnel head end
  - integration with LSP ping.

  He would like to get the draft accepted as a WG draft.

  Yakov asked what SPs use today for tunnel tracing.

    Ron said that in some case people can use ICMP for MPLS.

  Yakov then asked if we could get a BCP on what people are
  doing.

    Ron asked if he should resubmit his earlier draft on
    this.

      Kireeti said that we do not want to decide that now.

=3D=3D=3D
Protection and Restoration
---
Dimitri Papadimitriou presented status on the work of the
Protection and Restoration Team - specifically:
1) draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
2) draft-ietf-ccamp-gmpls-recovery-functional-01.txt
3) draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
4) draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt

  He gave estimates on the timing for each of the above
  drafts (estimated completion dates).

  He outlined the changes to the e2e signaling ID (draft 4,
  above).

  He encouraged the WG to really read the documents and
  comment.

  Kireeti polled for consensus on the following:

    a) Analysis - last call? Some support, no objection
    b) Functional - last call? Some support, no objection
    c) Terminology - last call? Some support, no objection
    d) e2e Signaling - WG document? Some support, no object

   Kohei Shiomoto said that the e2e Signaling draft does not
   address the misconnection issues raised in the mailing
   list.

     Dimitri answered that it is addressed in 8.3 of the
     draft.

       Kohei said that the misconnection issue does not
       happen only in the P&R context but also in more
       general context and therefore should be addressed
       in more general context as well.

         Kireeti said that the question should be continued
         to the mailing list.

  People at the microphone were asked to take their
  questions to the list.

---
Lou Berger presented an overview of work on Segment
Recovery - draft-berger-ccamp-gmpls-segment-recovery-00.txt

  He also talked about what still needs to be done (next
  steps), including more usage scenarios, more explanatory
  text and see if the WG will adopt this work.

  Arthi Ayyangar asked if the association object is required
  even if we are only doing segment recovery (as opposed to
  e2e).

  Arthi asked why couldn't we extend the Detour Object to
  achieve the same result. Kireeti asked her to take to the
  list.

  Richard Rabbat asked if this draft raised the same issues
  as the e2e signaling draft in terms of misconnection.

    Kireeti replied that they did not know if there were
    misconnection problems.

      Richard asked that the discussion about misconnections
      be moved to the mailing list in the interest of time.

  Adrian polled for support of accepting this as a WG draft.
  There was moderate support and no objection.

=3D=3D=3D
Inter-Area/AS
---
Arthi Ayyangar talked about the status of the merged draft
on Inter-area/AS signaling -
draft-vasseur-ccamp-inter-area-as-te-00.txt

  The draft currently represents a full merge - work is
  still required to strip out redundant and unneeded text.

  She said that the authors encourage people to come forward
  with their comments.  She would also like to see if there
  is interest in this work becoming a WG document.

  Vishal Sharma said that the work should apply to general
  path computation domains and GMPLS LSPs.
  In response to Arthi's question on Slide "Outstanding
  Issues" (about whether detailed description of various
  path computation algorithms should be part of this
  document or separate document(s)), he supported the
  document being split into a framework document, discussing
  signaling, and another document(s), discussing the path
  computation mechanisms, since the latter do not need to be
  standardized.
  In response to Slide "Outstanding Issues: Size of the
  document" and for clarity, he supported the splitting of
  the applicability statement into an independent document.

  Dimitri agreed on the subject of separating the document.
  In addition, he questioned about the relevance of using
  the LSP_Attributes to signal the signaling method for the
  intra-area/-AS provisioning of the LSP.
  In particular, he proposed to not include protocol
  procedures within examples/scenarios that makes the
  document difficult to read.

    Arthi asked that Dimitri take his specific comments to
    the list.

  Kireeti said that he agrees that the document needs to be
  split - one as a signaling and another (informational) to
  provide examples for path computation. He also said that
  we need a separate applicability document.

    Vishal Sharma then said that he would be happy to help
    with these tasks.

---
Vishal Sharma talked about work on Inter-area path
protection
draft-dachille-inter-area-path-protection-00.txt

  He provided a brief overview of how it works, and showed
  how it relates to other work in progress. He also listed
  the next steps.

  He emphasized that this is really a generic mechanism for
  diverse path computation, and protection is one
  application of it, so the authors would respin with a new
  name and emphasis to reflect this."

  Zafar Ali asked how this would work if there is a failure
  at the time during which the backup path is being setup.

    Vishal replied that the solutions to this were, so far,
    not discussed in the draft, but that there are several
    options.

    He then outlined some of the options. E.g. either
    default in such a case to a sequential computation, and
    use XRO to exclude the link/node where backup path setup
    failed, and retry the backup (and optimize both primary
    and secondary later using the techniques in the draft).
    Or, set up the primary and the backup again, using the
    techniques described in the draft.

    Vishal said they would be happy to add some discussion
    in the document, and welcomed feedback on the list.

  Zafar asked how this work relates to PCS/PCE work.

    Vishal replied that it could actually be made use of by
    the PCS/PCE approach, and could be viewed as
    complementary.

  Kireeti asked that further discussion be taken to the
  list.

  Vishal said he welcomed further feedback on the document.

  Dimitri asked why, knowing that the proposed approach
  works as expected in the intra-domain case when the
  number of ABRs (where computation can be executed at each
  stage) does not increase, this approach is so focused on
  optimization (since it can't be achieved if this
  condition is not met).

    Vishal clarified that the focus of the work is to
    propose a generic mechanism to facilitate diverse path
    setup by communicating alternate path info, with
    optimization a desired goal (for reasons explained in
    the document).

    Vishal added that given the network model (where border
    nodes are not assumed to have visibility in areas other
    than their own), the scheme was not trying to be
    globally optimal.

    Vishal explained that in such cases some selection needs
    to be performed at each stage.

  Kireeti asked that further discussion on this should be
  taken to the list.

  Also, he said that Dimitri had a good point - we need to
  define criteria on which any optimization is based.

  Kireeti concluded by saying that path protection and
  inter-area are both in the charter, but that this document
  could only be considered for a WG document after there was
  discussion about the document on the list.

=3D=3D=3D
Control Pane Resilience, Hello Protocol and Graceful Restart
---
Young Hwa Kim gave a presentation on Requirements for the
Resilience of Control Plane in GMPLS -
draft-kim-ccamp-cpr-reqts-00.txt

  He described the reasons why control plane resilience is
  needed.

  Zafar asked how control plane resilience is different from
  anything else in IP.

  Steve Trowbridge said that their is also some work in this
  area in the ITU and he would try to get this in as a
  liaison as soon as possible.

  Kireeti said that this is an important discussion and
  there are a lot of things to do. Specific topics should be
  raised on the list when appropriate.

---
Lou Berger went over Extensions to GMPLS RSVP Graceful
Restart
draft-aruns-ccamp-rsvp-restart-ext-00

  He emphasized that egress restart is already covered in
  RFC3473 and this work has no effect on that functionality.
  He gave a brief overview and listed open issues.

  Next steps include merging with other restart drafts and
  seeing if this work can become a WG draft.

  Arthi Ayyangar said that the text at the beginning of the
  draft seems to talk only about the recovery ERO, although
  using the RecoveryPath one can recover many objects
  besides the ERO. So the text should be clarified to this
  effect.

    Lou asked if she would like to contribute text.

  There was a discussion on adjacent node restart.

  Arthi asked why adjacent node restart was an issue being
  addressed in RSVP-TE. She pointed out that before this
  becomes an issue to be solved in RSVP-TE, we would first
  need to check if adjacent node restart even works for
  IGPs.

  The chairs then asked for other discussion to go to the
  list.

---
Zafar Ali talked about Extensions to GMPLS RSVP Graceful
Restart
draft-rahman-ccamp-rsvp-restart-extensions-00.txt

  Kireeti said that he appreciated the honesty of the
  authors in acknowledging other work.

  Nurit Sprecher asked about the relationship to FRR and
  similar issues.

    Adrian agreed that these were important issues and had
    been raised on the list in recent days. He asked the
    authors to make sure that they cover the points in the
    draft.

---
Zafar then covered modifications to Hello procedures
1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
2) draft-ali-ccamp-rsvp-hello-gr-admin-00.txt

  He wants to go forward with draft 1 above.

  Adrian polled and there was some interest and no strong
  objection.

  Kireeti said that this work cannot be informational if
  it has - or proposes - changes to a standard.

  Zafar also wants draft 2 to be a WG document.

  Kireeti said that we need to take this to the list, but
  Zafar also needs to socialize the work he is doing so that
  people may decide whether or not this is work we want to
  do.

=3D=3D=3D
Everything Else
---
Emmanuel Dotaro gave status of Multi-region protection -
draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt

  He briefly covered changes since previous versions.

  He proposes that we may need to make changes to the
  charter to include all of this work. In particular to
  include in the charter the complete set of GMPLS
  mechanisms for integrated control planes, and not only
  multi-layer recovery (as it stands today).

  Adrian suggested that the authors need to get more people
  involved in this important work and revisit this later.

---
Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs
draft-vasseur-ccamp-isis-te-caps-00.txt

  He would like to have this accepted as a WG document.

  Adrian asked to hold off on this until after the OSPF talk
  below.

---
Seisho Yasukawa
draft-vasseur-ccamp-ospf-te-caps-00.txt

  He would like to have this accepted as a WG document.

  Regarding both drafts, Kireeti is not sure that this work
  belongs in this WG. The decision is driven by the
  generality of its applicability. If we do take it on, their
  needs to be a functional specification (independent of IGP)
  as well.

  He asked that further discussion be taken to the list.

---
The Following presentations were postponed as we ran out
of time. Adrian made a couple of brief comments as follows:
  ---
  Zafar Ali - Explicit Resource Control and Tracking
  draft-zamfir-explicit-resource-control-bundle-03.txt

    This work concerns identification of component links in
    EROs and RROs.

    A small group is currently examining other issues
    concerning identification of component links in all
    aspects of GMPLS. A draft is expected soon. Please mail
    Adrian or the list, if you want to be involved in this
    work.

  ---
  Lou Berger - Alarm Reporting
  draft-berger-ccamp-gmpls-alarm-spec-01.txt

    This draft is stable and complete in the view of the
    authors.

    A quick poll showed some support for this being a WG
    document, and no opposition. This will be taken to the
    list.
------=_NextPart_000_0E5E_01C40CE9.B22C2F90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Common Control and Measurement Plane =
WG=20
(ccamp)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>THURSDAY, March 4 at=20
0900-1130<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>CHAIRS: Kireeti Kompella =
&lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Adrian =
Farrel=20
&lt;</FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>Group =
Admin<BR>---<BR>Chairs<BR>&nbsp;=20
Admin - Nothing much to say (in English=20
anyway)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - In Korean, =
however, the=20
following was =
said:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
"Jigeumbuteo CCAMP meetingeul sijakhagesumnida".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Agenda bash (5 mins) - No=20
changes<BR>&nbsp; Status of WG drafts and =
milestones<BR>&nbsp;&nbsp;&nbsp;=20
Adrian's slides showed that we do have some draft<BR>&nbsp;&nbsp;&nbsp;=20
congestion in the WG.<BR>&nbsp;&nbsp;&nbsp; - RFC editor=20
queue<BR>&nbsp;&nbsp;&nbsp; - status of IANA for=20
SONET/SDH<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Kireeti talked about an =
issue with=20
SONET/SDH IANA<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
assignments<BR>&nbsp;&nbsp;&nbsp; - need a means to get early=20
assignments.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There is WIP to =
accomplish this,=20
and it is moving<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ahead.<BR>&nbsp;&nbsp;&nbsp;=20
- future allocation of "experimental" values</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Liaisons<BR>---<BR>Marco Carugi =
talked about work=20
in SG-13 (SG13 liaison).<BR>&nbsp; He covered topics, new study areas,=20
timescales, objectives<BR>&nbsp; and status. They are also looking for =
people=20
interested in<BR>&nbsp; doing work in these areas.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; An L1 VPN questionnaire and =
framework=20
draft were attached<BR>&nbsp; to the liaison.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Tomonori Takeda talked about =
the technical=20
issues and<BR>&nbsp; details of the work.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Monique Morrow had a couple of =

clarification for Marco -<BR>&nbsp; When will the consent portion of the =
work be=20
done in the<BR>&nbsp; ITU?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Marco said that =
the different=20
pieces of work were<BR>&nbsp;&nbsp;&nbsp; progressing at different =
speeds. Some=20
material is<BR>&nbsp;&nbsp;&nbsp; already embodied in recommendations. =
The next=20
SG13<BR>&nbsp;&nbsp;&nbsp; meetings are in June and =
September.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Dimitri Papadimitriou asked if =
the draft=20
(l1vpn<BR>&nbsp; framework) provided in the liaison could include =
a<BR>&nbsp;=20
summarization (as conclusion) on the expected GMPLS work<BR>&nbsp; for =
the CCAMP=20
WG, this would clarify the intent of the<BR>&nbsp; liaison in term of =
expected=20
effort for the CCAMP WG</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Kireeti answered. =
If CCAMP's=20
rechartering this month<BR>&nbsp;&nbsp;&nbsp; results in the addition of =
L1VPNs=20
to the charter, then<BR>&nbsp;&nbsp;&nbsp; a Liaison response from the =
IETF will=20
include this<BR>&nbsp;&nbsp;&nbsp; information, plus a request for a =
cooperative=20
effort,<BR>&nbsp;&nbsp;&nbsp; preferably along the lines of the ASON =
routing=20
work,<BR>&nbsp;&nbsp;&nbsp; wherein the ITU-T defines the requirements =
and the=20
IETF<BR>&nbsp;&nbsp;&nbsp; does the protocol extensions.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Alex Zinin said that we will =
have to make=20
a decision at<BR>&nbsp; some point as to whether or not we want to do =
this=20
work<BR>&nbsp; here.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kohei Shiomoto said that the =
protocol for=20
the L1VPN should<BR>&nbsp; be developed at the IETF as long as it uses =
IP=20
protocol.<BR>&nbsp; There are already internet-drafts on GVPN and CCAMP =
is=20
the<BR>&nbsp; best place to discuss it.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Deborah Brungard said that =
there is work=20
and some synergy<BR>&nbsp; and that we should continue to work on=20
this.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Monique Morrow =
agrees that we=20
should work on that.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Marco added some =
comments that=20
were not captured in the<BR>&nbsp;&nbsp;&nbsp; minutes.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Malcolm Betts said =
he also=20
feels that we should do this.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Adrian took a quick poll and =
it seems as=20
if nobody is<BR>&nbsp; against doing this work.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti reminded people to =
continue this=20
discussion on<BR>&nbsp; the list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Lyndon Ong talked about work =
in SG-15 (3=20
liaisons).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Liaisons were on ASON routing=20
requirements, response to<BR>&nbsp; comments on Q14 for G.7713.2 and =
comments on=20
the CCAMP<BR>&nbsp; ASON signaling requirements draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Lyndon spent much of the time =
on the=20
details of response<BR>&nbsp; to comments on Q14. It seems that some of =
the=20
differences<BR>&nbsp; in architectural models revolve around =
"end-to-end"=20
and<BR>&nbsp; "call segment" operating models.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti asked for the reply by =

date.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Lyndon did not =
have=20
that.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Steve Trowbridge =
said that the=20
meeting starts on April<BR>&nbsp;&nbsp;&nbsp; 19th</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Dimitri had a question on the =
deadline.=20
There is a<BR>&nbsp; deadline on G.7713 (April 2004), isn't there a=20
similar<BR>&nbsp; deadline on G.7713.2 (since this is the document to=20
which<BR>&nbsp; convergence is expected) ?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Lyndon said that =
he had not=20
gone into that. He gave a<BR>&nbsp;&nbsp;&nbsp; reason, but this was not =

captured in the minutes.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Deborah said that the liaison =
for 7713.2=20
does not say any<BR>&nbsp; thing about convergence.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Lyndon said that =
they are=20
still looking for a "meeting<BR>&nbsp;&nbsp;&nbsp; of the =
minds".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Deborah said that there is an =
issue with=20
G.7713.2 because<BR>&nbsp; of compatibility.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Lyndon said that =
yes there has=20
been a lot of discussion<BR>&nbsp;&nbsp;&nbsp; of compatibility =
questions and=20
requirements.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti said that we should =
not discuss=20
this here.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Steve Trowbridge added some =
comments that=20
were not<BR>&nbsp; captured in the minutes.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti asked the WG to take =
this=20
discussion to the list<BR>&nbsp; and try to keep that discussion on a =
productive=20
basis.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Adrian said that he wanted to =
recognize=20
the efforts of<BR>&nbsp; the ITU folks in this work.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>ASON Requirements and=20
Solutions<BR>---<BR>Dimitri Papadimitriou presented status of ASON=20
Signaling<BR>Requirements=20
(draft-ietf-ccamp-gmpls-ason-reqts-05.txt.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; The requirements were driven =
by last=20
year's liaison from<BR>&nbsp; the ITU.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; The discussion slides proposed =
to defer to=20
the GROW WG<BR>&nbsp; (cf. RIFT WG item) concerning the (external)=20
non-IP<BR>&nbsp; reachability issue since much broader than just =
CCAMP<BR>&nbsp;=20
GMPLS/ASON context</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; After this meeting, Dimitri =
would like to=20
re-spin the<BR>&nbsp; draft and have a two week last call.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Lyndon said he want to capture =
the=20
requirement on "non-IP<BR>&nbsp; reachability" - whether or not we will =
work on=20
it here</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti said that we first =
need to=20
understand importance<BR>&nbsp; of this and then we can look to the ADs =
for=20
guidance on<BR>&nbsp; handling this.&nbsp; He also said that we should =
take some=20
time<BR>&nbsp; to work out what we want to say to the ITU when we=20
include<BR>&nbsp; the current draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Dimitri Papadimitriou gave =
status ASON=20
Signaling Solutions<BR>(draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt)=20
status.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He would like feedback on =
whether or not=20
the current draft<BR>&nbsp; deals correctly with the session attribute =
object=20
that<BR>&nbsp; encodes the long call_id (alternatives were also=20
proposed)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; His objective at this point is =
to try to=20
have a document<BR>&nbsp; ready for last call for the next IETF 60 =
meeting in=20
San<BR>&nbsp; Diego</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Lyndon suggested that we might =
remove the=20
comparison with<BR>&nbsp; G.7713 from the draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Adrian asked if =
this meant=20
that the interworking draft<BR>&nbsp;&nbsp;&nbsp; for RFC3473/4 =
interworking was=20
now obsolete.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lyndon =
said maybe,=20
if interworking is removed as a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
requirement.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Lou Berger talked about Egress =
Control=20
-<BR>draft-berger-gmpls-egress-control-01.txt -</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Original egress label control =
became=20
explicit label<BR>&nbsp; control. This draft attempts to capture the=20
original<BR>&nbsp; intent.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He wants to know if the WG =
feels that this=20
is ready to<BR>&nbsp; be a BCP and what the chairs think the next steps=20
should<BR>&nbsp; be.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Lou re-iterated that the =
purpose and scope=20
of the draft<BR>&nbsp; is for clarification. He does not see any value =
in=20
adding<BR>&nbsp; to this intent or combining it with other =
work.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Adrian then took a poll and =
nobody=20
objected to take this<BR>&nbsp; on as a WG item (more than a third were =
in=20
favor).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Lyndon Ong went over status on =
ASON=20
Routing Requirements=20
-<BR>draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He includes in his =
presentation the Design=20
Team's<BR>&nbsp; conclusions as to what there is agreement about=20
what's<BR>&nbsp; missing from GMPLS (delta), and what are the areas =
on<BR>&nbsp;=20
which there is no agreement about what's missing from<BR>&nbsp;=20
GMPLS.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Vishal Sharma asked if the =
three issues=20
(slide 6) were<BR>&nbsp; already opened up for discussion on the list, =
or=20
would<BR>&nbsp; they be formally opened up with the DT members=20
initiating<BR>&nbsp; a discussion on these on the list?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Lyndon Ong replied =
that a=20
discussion had not been<BR>&nbsp;&nbsp;&nbsp; formally opened up yet =
(although=20
people were free to<BR>&nbsp;&nbsp;&nbsp; discuss/comment).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Kireeti asked=20
Lyndon to more formally open this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
discussion=20
on the mailing list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Vishal Sharma said that he =
supports=20
this.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti said he would like - =
after=20
checking with the AD -<BR>&nbsp; that we should take this work to the =
IS-IS and=20
OSPF WGs.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Alex Zinin said =
this is a good=20
idea.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>Tunnel =
Trace<BR>---<BR>Ron Bonica=20
presented status on draft-bonica-tunproto-05.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; The solution is very similar =
to=20
Trace-Route but does not<BR>&nbsp; require that each node in a tunnel =
supports=20
TTL decrement.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He gave a few examples as to =
how the idea=20
in the draft<BR>&nbsp; will work in a few scenarios.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; There are a couple of =
outstanding=20
issues:<BR>&nbsp; - trace requires a route to tunnel head end<BR>&nbsp; =
-=20
integration with LSP ping.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He would like to get the draft =
accepted as=20
a WG draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Yakov asked what SPs use today =
for tunnel=20
tracing.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Ron said that in =
some case=20
people can use ICMP for MPLS.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Yakov then asked if we could =
get a BCP on=20
what people are<BR>&nbsp; doing.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Ron asked if he =
should=20
resubmit his earlier draft on<BR>&nbsp;&nbsp;&nbsp; this.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Kireeti said that=20
we do not want to decide that now.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>Protection and=20
Restoration<BR>---<BR>Dimitri Papadimitriou presented status on the work =
of=20
the<BR>Protection and Restoration Team - specifically:<BR>1)=20
draft-ietf-ccamp-gmpls-recovery-analysis-02.txt<BR>2)=20
draft-ietf-ccamp-gmpls-recovery-functional-01.txt<BR>3)=20
draft-ietf-ccamp-gmpls-recovery-terminology-03.txt<BR>4)=20
draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He gave estimates on the =
timing for each=20
of the above<BR>&nbsp; drafts (estimated completion dates).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He outlined the changes to the =
e2e=20
signaling ID (draft 4,<BR>&nbsp; above).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He encouraged the WG to really =
read the=20
documents and<BR>&nbsp; comment.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti polled for consensus =
on the=20
following:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; a) Analysis - last =
call? Some=20
support, no objection<BR>&nbsp;&nbsp;&nbsp; b) Functional - last call? =
Some=20
support, no objection<BR>&nbsp;&nbsp;&nbsp; c) Terminology - last call? =
Some=20
support, no objection<BR>&nbsp;&nbsp;&nbsp; d) e2e Signaling - WG =
document? Some=20
support, no object</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Kohei Shiomoto said that =
the e2e=20
Signaling draft does not<BR>&nbsp;&nbsp; address the misconnection =
issues raised=20
in the mailing<BR>&nbsp;&nbsp; list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; Dimitri =
answered that it=20
is addressed in 8.3 of the<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Kohei said=20
that the misconnection issue does =
not<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
happen only in the P&amp;R context but also in=20
more<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; general context and =
therefore=20
should be addressed<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in more =
general=20
context as well.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Kireeti said that the question should be=20
continued<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to the =
mailing=20
list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; People at the microphone were =
asked to=20
take their<BR>&nbsp; questions to the list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Lou Berger presented an =
overview of work=20
on Segment<BR>Recovery -=20
draft-berger-ccamp-gmpls-segment-recovery-00.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He also talked about what =
still needs to=20
be done (next<BR>&nbsp; steps), including more usage scenarios, more=20
explanatory<BR>&nbsp; text and see if the WG will adopt this =
work.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Arthi Ayyangar asked if the =
association=20
object is required<BR>&nbsp; even if we are only doing segment recovery =
(as=20
opposed to<BR>&nbsp; e2e).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Arthi asked why couldn't we =
extend the=20
Detour Object to<BR>&nbsp; achieve the same result. Kireeti asked her to =
take to=20
the<BR>&nbsp; list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Richard Rabbat asked if this =
draft raised=20
the same issues<BR>&nbsp; as the e2e signaling draft in terms of=20
misconnection.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Kireeti replied =
that they did=20
not know if there were<BR>&nbsp;&nbsp;&nbsp; misconnection=20
problems.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Richard asked that=20
the discussion about misconnections<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be =
moved=20
to the mailing list in the interest of time.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Adrian polled for support of =
accepting=20
this as a WG draft.<BR>&nbsp; There was moderate support and no=20
objection.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier =
size=3D2>=3D=3D=3D<BR>Inter-Area/AS<BR>---<BR>Arthi Ayyangar=20
talked about the status of the merged draft<BR>on Inter-area/AS =
signaling=20
-<BR>draft-vasseur-ccamp-inter-area-as-te-00.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; The draft currently represents =
a full=20
merge - work is<BR>&nbsp; still required to strip out redundant and =
unneeded=20
text.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; She said that the authors =
encourage people=20
to come forward<BR>&nbsp; with their comments.&nbsp; She would also like =
to see=20
if there<BR>&nbsp; is interest in this work becoming a WG =
document.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Vishal Sharma said that the =
work should=20
apply to general<BR>&nbsp; path computation domains and GMPLS =
LSPs.<BR>&nbsp; In=20
response to Arthi's question on Slide "Outstanding<BR>&nbsp; Issues" =
(about=20
whether detailed description of various<BR>&nbsp; path computation =
algorithms=20
should be part of this<BR>&nbsp; document or separate document(s)), he =
supported=20
the<BR>&nbsp; document being split into a framework document,=20
discussing<BR>&nbsp; signaling, and another document(s), discussing the=20
path<BR>&nbsp; computation mechanisms, since the latter do not need to=20
be<BR>&nbsp; standardized.<BR>&nbsp; In response to Slide "Outstanding =
Issues:=20
Size of the<BR>&nbsp; document" and for clarity, he supported the =
splitting=20
of<BR>&nbsp; the applicability statement into an independent=20
document.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Dimitri agreed on the subject =
of=20
separating the document.<BR>&nbsp; In addition, he questioned about the=20
relevance of using<BR>&nbsp; the LSP_Attributes to signal the signaling =
method=20
for the<BR>&nbsp; intra-area/-AS provisioning of the LSP.<BR>&nbsp; In=20
particular, he proposed to not include protocol<BR>&nbsp; procedures =
within=20
examples/scenarios that makes the<BR>&nbsp; document difficult to=20
read.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Arthi asked that =
Dimitri take=20
his specific comments to<BR>&nbsp;&nbsp;&nbsp; the list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti said that he agrees =
that the=20
document needs to be<BR>&nbsp; split - one as a signaling and another=20
(informational) to<BR>&nbsp; provide examples for path computation. He =
also said=20
that<BR>&nbsp; we need a separate applicability document.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Vishal Sharma then =
said that=20
he would be happy to help<BR>&nbsp;&nbsp;&nbsp; with these =
tasks.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Vishal Sharma talked about =
work on=20
Inter-area=20
path<BR>protection<BR>draft-dachille-inter-area-path-protection-00.txt</F=
ONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He provided a brief overview =
of how it=20
works, and showed<BR>&nbsp; how it relates to other work in progress. He =
also=20
listed<BR>&nbsp; the next steps.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He emphasized that this is =
really a=20
generic mechanism for<BR>&nbsp; diverse path computation, and protection =
is=20
one<BR>&nbsp; application of it, so the authors would respin with a=20
new<BR>&nbsp; name and emphasis to reflect this."</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Zafar Ali asked how this would =
work if=20
there is a failure<BR>&nbsp; at the time during which the backup path is =
being=20
setup.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Vishal replied =
that the=20
solutions to this were, so far,<BR>&nbsp;&nbsp;&nbsp; not discussed in =
the=20
draft, but that there are several<BR>&nbsp;&nbsp;&nbsp; =
options.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; He then outlined =
some of the=20
options. E.g. either<BR>&nbsp;&nbsp;&nbsp; default in such a case to a=20
sequential computation, and<BR>&nbsp;&nbsp;&nbsp; use XRO to exclude the =

link/node where backup path setup<BR>&nbsp;&nbsp;&nbsp; failed, and =
retry the=20
backup (and optimize both primary<BR>&nbsp;&nbsp;&nbsp; and secondary =
later=20
using the techniques in the draft).<BR>&nbsp;&nbsp;&nbsp; Or, set up the =
primary=20
and the backup again, using the<BR>&nbsp;&nbsp;&nbsp; techniques =
described in=20
the draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Vishal said they =
would be=20
happy to add some discussion<BR>&nbsp;&nbsp;&nbsp; in the document, and =
welcomed=20
feedback on the list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Zafar asked how this work =
relates to=20
PCS/PCE work.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Vishal replied =
that it could=20
actually be made use of by<BR>&nbsp;&nbsp;&nbsp; the PCS/PCE approach, =
and could=20
be viewed as<BR>&nbsp;&nbsp;&nbsp; complementary.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti asked that further =
discussion be=20
taken to the<BR>&nbsp; list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Vishal said he welcomed =
further feedback=20
on the document.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Dimitri asked why, knowing =
that the=20
proposed approach<BR>&nbsp; works as expected in the intra-domain case =
when=20
the<BR>&nbsp; number of ABRs (where computation can be executed at=20
each<BR>&nbsp; stage) does not increase, this approach is so focused=20
on<BR>&nbsp; optimization (since it can't be achieved if this<BR>&nbsp;=20
condition is not met).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Vishal clarified =
that the=20
focus of the work is to<BR>&nbsp;&nbsp;&nbsp; propose a generic =
mechanism to=20
facilitate diverse path<BR>&nbsp;&nbsp;&nbsp; setup by communicating =
alternate=20
path info, with<BR>&nbsp;&nbsp;&nbsp; optimization a desired goal (for =
reasons=20
explained in<BR>&nbsp;&nbsp;&nbsp; the document).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Vishal added that =
given the=20
network model (where border<BR>&nbsp;&nbsp;&nbsp; nodes are not assumed =
to have=20
visibility in areas other<BR>&nbsp;&nbsp;&nbsp; than their own), the =
scheme was=20
not trying to be<BR>&nbsp;&nbsp;&nbsp; globally optimal.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Vishal explained =
that in such=20
cases some selection needs<BR>&nbsp;&nbsp;&nbsp; to be performed at each =

stage.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti asked that further =
discussion on=20
this should be<BR>&nbsp; taken to the list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Also, he said that Dimitri had =
a good=20
point - we need to<BR>&nbsp; define criteria on which any optimization =
is=20
based.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti concluded by saying =
that path=20
protection and<BR>&nbsp; inter-area are both in the charter, but that =
this=20
document<BR>&nbsp; could only be considered for a WG document after =
there=20
was<BR>&nbsp; discussion about the document on the list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>Control Pane Resilience, =
Hello Protocol=20
and Graceful Restart<BR>---<BR>Young Hwa Kim gave a presentation on =
Requirements=20
for the<BR>Resilience of Control Plane in GMPLS=20
-<BR>draft-kim-ccamp-cpr-reqts-00.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He described the reasons why =
control plane=20
resilience is<BR>&nbsp; needed.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Zafar asked how control plane =
resilience=20
is different from<BR>&nbsp; anything else in IP.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Steve Trowbridge said that =
their is also=20
some work in this<BR>&nbsp; area in the ITU and he would try to get this =
in as=20
a<BR>&nbsp; liaison as soon as possible.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti said that this is an =
important=20
discussion and<BR>&nbsp; there are a lot of things to do. Specific =
topics should=20
be<BR>&nbsp; raised on the list when appropriate.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Lou Berger went over =
Extensions to GMPLS=20
RSVP =
Graceful<BR>Restart<BR>draft-aruns-ccamp-rsvp-restart-ext-00</FONT></DIV>=

<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He emphasized that egress =
restart is=20
already covered in<BR>&nbsp; RFC3473 and this work has no effect on that =

functionality.<BR>&nbsp; He gave a brief overview and listed open=20
issues.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Next steps include merging =
with other=20
restart drafts and<BR>&nbsp; seeing if this work can become a WG=20
draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Arthi Ayyangar said that the =
text at the=20
beginning of the<BR>&nbsp; draft seems to talk only about the recovery =
ERO,=20
although<BR>&nbsp; using the RecoveryPath one can recover many =
objects<BR>&nbsp;=20
besides the ERO. So the text should be clarified to this<BR>&nbsp;=20
effect.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Lou asked if she =
would like to=20
contribute text.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; There was a discussion on =
adjacent node=20
restart.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Arthi asked why adjacent node =
restart was=20
an issue being<BR>&nbsp; addressed in RSVP-TE. She pointed out that =
before=20
this<BR>&nbsp; becomes an issue to be solved in RSVP-TE, we would=20
first<BR>&nbsp; need to check if adjacent node restart even works =
for<BR>&nbsp;=20
IGPs.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; The chairs then asked for =
other discussion=20
to go to the<BR>&nbsp; list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Zafar Ali talked about =
Extensions to GMPLS=20
RSVP=20
Graceful<BR>Restart<BR>draft-rahman-ccamp-rsvp-restart-extensions-00.txt<=
/FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti said that he =
appreciated the=20
honesty of the<BR>&nbsp; authors in acknowledging other =
work.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Nurit Sprecher asked about the =

relationship to FRR and<BR>&nbsp; similar issues.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Adrian agreed that =
these were=20
important issues and had<BR>&nbsp;&nbsp;&nbsp; been raised on the list =
in recent=20
days. He asked the<BR>&nbsp;&nbsp;&nbsp; authors to make sure that they =
cover=20
the points in the<BR>&nbsp;&nbsp;&nbsp; draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Zafar then covered =
modifications to Hello=20
procedures<BR>1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt<BR>2)=20
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He wants to go forward with =
draft 1=20
above.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Adrian polled and there was =
some interest=20
and no strong<BR>&nbsp; objection.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti said that this work =
cannot be=20
informational if<BR>&nbsp; it has - or proposes - changes to a=20
standard.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Zafar also wants draft 2 to be =
a WG=20
document.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Kireeti said that we need to =
take this to=20
the list, but<BR>&nbsp; Zafar also needs to socialize the work he is =
doing so=20
that<BR>&nbsp; people may decide whether or not this is work we want=20
to<BR>&nbsp; do.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D<BR>Everything =
Else<BR>---<BR>Emmanuel Dotaro=20
gave status of Multi-region protection=20
-<BR>draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He briefly covered changes =
since previous=20
versions.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He proposes that we may need =
to make=20
changes to the<BR>&nbsp; charter to include all of this work. In =
particular=20
to<BR>&nbsp; include in the charter the complete set of GMPLS<BR>&nbsp;=20
mechanisms for integrated control planes, and not only<BR>&nbsp; =
multi-layer=20
recovery (as it stands today).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Adrian suggested that the =
authors need to=20
get more people<BR>&nbsp; involved in this important work and revisit =
this=20
later.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Jean-Louis Le Roux - =
Advertizing TE=20
Capabilities in =
IGPs<BR>draft-vasseur-ccamp-isis-te-caps-00.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He would like to have this =
accepted as a=20
WG document.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Adrian asked to hold off on =
this until=20
after the OSPF talk<BR>&nbsp; below.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>Seisho=20
Yasukawa<BR>draft-vasseur-ccamp-ospf-te-caps-00.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He would like to have this =
accepted as a=20
WG document.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Regarding both drafts, Kireeti =
is not sure=20
that this work<BR>&nbsp; belongs in this WG. The decision is driven by=20
the<BR>&nbsp; generality of its applicability. If we do take it on,=20
their<BR>&nbsp; needs to be a functional specification (independent of=20
IGP)<BR>&nbsp; as well.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; He asked that further =
discussion be taken=20
to the list.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>---<BR>The Following presentations =
were postponed=20
as we ran out<BR>of time. Adrian made a couple of brief comments as=20
follows:<BR>&nbsp; ---<BR>&nbsp; Zafar Ali - Explicit Resource Control =
and=20
Tracking<BR>&nbsp;=20
draft-zamfir-explicit-resource-control-bundle-03.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; This work concerns =

identification of component links in<BR>&nbsp;&nbsp;&nbsp; EROs and=20
RROs.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; A small group is =
currently=20
examining other issues<BR>&nbsp;&nbsp;&nbsp; concerning identification =
of=20
component links in all<BR>&nbsp;&nbsp;&nbsp; aspects of GMPLS. A draft =
is=20
expected soon. Please mail<BR>&nbsp;&nbsp;&nbsp; Adrian or the list, if =
you want=20
to be involved in this<BR>&nbsp;&nbsp;&nbsp; work.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; ---<BR>&nbsp; Lou Berger - =
Alarm=20
Reporting<BR>&nbsp; =
draft-berger-ccamp-gmpls-alarm-spec-01.txt</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; This draft is =
stable and=20
complete in the view of the<BR>&nbsp;&nbsp;&nbsp; authors.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; A quick poll =
showed some=20
support for this being a WG<BR>&nbsp;&nbsp;&nbsp; document, and no =
opposition.=20
This will be taken to the<BR>&nbsp;&nbsp;&nbsp; =
list.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0E5E_01C40CE9.B22C2F90--




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 11:51:16 +0000
Message-ID: <0e4201c40cde$e4841170$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, "Stephen Shew" <[e-mail]>, <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Subject: Re: ason-routing-reqts: issue 2 architecture
Date: Thu, 18 Mar 2004 11:32:00 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E28_01C40CDC.A11394D0"

This is a multi-part message in MIME format.

------=_NextPart_000_0E28_01C40CDC.A11394D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Lyndon,

> If you follow this through, is there a visible difference between
> the following cases:


Well, yes. I can see a difference.
But I suppose you are asking a deeper question.

Your B) shows only a decoupling of control plane and data plane such as =
one might achieve using GSMP (or TL1 or ...) in a standard =
configuration.

Your A) includes with this decoupling a centralization of control into a =
single controling entity. As Jonathan points out, this might be done in =
order to present the data plane resources (nodes and links) as a single =
entity, or might be done simply because there is a single centralized =
control plane node.

It was my intention to distinguish these cases using R1 and R2 on my =
figure.

NOTE WELL. None of these figures dwells on control plane connectivity. =
This is entirely a separate matter from TE connectivity.

Thanks,
Adrian

> =20
>         A)                       B)
>            ------------------       ------   ------   ------
>           |R1                |     |R1    | |R2    | |R3    |
>           |  --    --    --  |     |  --  | |  --  | |  --  |
>           | |L1|  |L2|  |L3| |     | |L1| | | |L2| | | |L3| |
>           |  --    --    --  |     |  --  | |  --  | |  --  |
>           |   :     :     :  |     |   :  | |   :  | |   :  |
> Control    ---+-----+-----+--       ---+--   ---+--   ---+--
> Plane         :     :     :            :        :        :
> --------------+-----+-----+----    ----+--------+--------+----
> Data          :     :     :            :        :        :
> Plane        --     :    --           --        :       --
>         ----|P1|--------|P3|---   ---|P1|--------------|P3|---
>              -- \   :  / --           --    \   :  /    --
>                  \ -- /                      \ -- /
>                   |P2|                        |P2|
>                    --                          --
>=20
> > >              ------------------     ------   =20
> > >             |R1                |   |R2    |  =20
> > >             |  --    --    --  |   |  --  |    ------
> > >             | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
> > >             |  --    --    --  |   |  --  |   |  --  |
> > >             |   :     :     :  |   |   :  |   | |L5| |
> > > Control      ---+-----+-----+--     ---+--    |  --  |
> > > Plane           :     :     :          :      |   :  |
> > > ----------------+-----+-----+----------+------+---+--+-
> > > Data            :     :     :          :      |   :  |
> > > Plane          --     :    --         --      |  --  |
> > >           ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
> > >                -- \   :  / --         --      |  --  |
> > >                    \ -- /                     |      |
> > >                     |P2|                       ------
> > >                      --
> > >=20
> > > Pn is a physical (bearer/data/transport plane) node.
> > > Rn is a control plane "router"
> > > Ln is a logical control plane entity that manages a single
> > >    physical node.
> > >=20
> > > Thus:
> > > R3 represents an LSR with all components collocated.
> > > R2 shows how the "router" component may be disjoint from
> > >    the switch
> > > R1 shows how a single "router" may manage multiple switches

------=_NextPart_000_0E28_01C40CDC.A11394D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Lyndon,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; If you follow this through, is =
there a=20
visible difference between</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;the following =
cases:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Well, yes. I can see a =
difference.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>But I suppose you are asking a deeper =

question.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Your B) shows only a decoupling of =
control plane=20
and data plane such as one might achieve using GSMP (or TL1 or ...) in a =

standard configuration.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Your A) includes with this decoupling =
a=20
centralization of control into a single controling entity. As Jonathan =
points=20
out, this might be done in order to present the data plane resources =
(nodes and=20
links) as a single entity, or might be done simply because there is a =
single=20
centralized control plane node.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It was my intention to distinguish =
these cases=20
using R1 and R2 on my figure.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>NOTE WELL. None of these figures =
dwells on=20
control plane connectivity. This is entirely a separate matter from TE=20
connectivity.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</DIV>
<DIV><BR>&gt; &nbsp;<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
A)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
B)<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
------------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
------&nbsp;&nbsp;=20
------&nbsp;&nbsp; ------<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp; |R1&nbsp;&nbsp;&nbsp; | |R2&nbsp;&nbsp;&nbsp; =
|=20
|R3&nbsp;&nbsp;&nbsp; |<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;=20
--&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp; --&nbsp; | |&nbsp; --&nbsp; | |&nbsp; --&nbsp; |<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |L1|&nbsp; =
|L2|&nbsp;=20
|L3| |&nbsp;&nbsp;&nbsp;&nbsp; | |L1| | | |L2| | | |L3| |<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;=20
--&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp; --&nbsp; | |&nbsp; --&nbsp; | |&nbsp; --&nbsp; |<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; | |&nbsp;&nbsp; :&nbsp; =
|=20
|&nbsp;&nbsp; :&nbsp; |<BR>&gt; Control&nbsp;&nbsp;&nbsp;=20
---+-----+-----+--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
---+--&nbsp;&nbsp;=20
---+--&nbsp;&nbsp; ---+--<BR>&gt;=20
Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<BR>&gt;=20
--------------+-----+-----+----&nbsp;&nbsp;&nbsp;=20
----+--------+--------+----<BR>&gt;=20
Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :<BR>&gt;=20
Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
----|P1|--------|P3|---&nbsp;&nbsp;=20
---|P1|--------------|P3|---<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--=20
\&nbsp;&nbsp; :&nbsp; /=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp; \&nbsp;&nbsp; :&nbsp; /&nbsp;&nbsp;&nbsp; =
--<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
\ --=20
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\ -- /<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|P2|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|P2|<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
--<BR></FONT><FONT face=3DCourier size=3D2>&gt; <BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
------------------&nbsp;&nbsp;&nbsp;&nbsp; ------&nbsp;&nbsp;&nbsp; =
<BR>&gt;=20
&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp; |R2&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; <BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
|&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; |&nbsp;&nbsp; =
|&nbsp;=20
--&nbsp; |&nbsp;&nbsp;&nbsp; ------<BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; |=20
|L1|&nbsp; |L2|&nbsp; |L3| |&nbsp;&nbsp; | |L4| |&nbsp;&nbsp;=20
|R3&nbsp;&nbsp;&nbsp; |<BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
|&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; |&nbsp;&nbsp; =
|&nbsp;=20
--&nbsp; |&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
|&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;=20
|&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |&nbsp;&nbsp; | |L5| |<BR>&gt; &gt; =
&gt;=20
Control&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
---+-----+-----+--&nbsp;&nbsp;&nbsp;&nbsp;=20
---+--&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt; &gt; &gt;=20
Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |<BR>&gt; &gt; =
&gt;=20
----------------+-----+-----+----------+------+---+--+-<BR>&gt; &gt; =
&gt;=20
Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |<BR>&gt; &gt; =
&gt;=20
Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
----|P1|--------|P3|-------|P4|-----+-|P5|-+-<BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
-- \&nbsp;&nbsp; :&nbsp; / =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\ --=20
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|P2|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
------<BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; Pn is a physical =
(bearer/data/transport=20
plane) node.<BR>&gt; &gt; &gt; Rn is a control plane "router"<BR>&gt; =
&gt; &gt;=20
Ln is a logical control plane entity that manages a single<BR>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp; physical node.<BR>&gt; &gt; &gt; <BR>&gt; &gt; =
&gt;=20
Thus:<BR>&gt; &gt; &gt; R3 represents an LSR with all components=20
collocated.<BR>&gt; &gt; &gt; R2 shows how the "router" component may be =

disjoint from<BR>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; the switch<BR>&gt; =
&gt; &gt;=20
R1 shows how a single "router" may manage multiple=20
switches<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0E28_01C40CDC.A11394D0--




Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2004 11:51:00 +0000
Message-ID: <0e4301c40cde$e5fbe460$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Don Fedyk" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Stepping back from the ASON Routing Discussion
Date: Thu, 18 Mar 2004 11:43:01 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Don,

Just picking out one snippet...

> >>Do we, or do we not need to support a physically separated
> >>architecture with a 1-n relationship between control plane
> >>and transport plane entities?
> >
> > I would say yes. The requirement I see here is devices not capable of
> > participating fully in GMPLS routing.

I had to read this several times before I got it. Sorry.

You mean that...
"It is a requirement of ASON routing to support networks that contain devices that do not
contain the capabilities to participate fully (or at all) in the routing protocols run
within the network."

That sounds a reasonable requirement.

There are two developments of this requirement.

The first is where the routing responsiblity for the device is taken on "by proxy" by a
control plane entity such as one that Lyndon, Jonathan and I have been drawing. In this
case, although the device is not participating in the routing protocols within the
network, it is fully represented and there are no issues (although we must ensure that
this function is covered by the requirements).

In the second case, ther are islands within the network which are simply not represented
to the routing protocol. This gives me a greater problem. Clearly you cannot route through
a part of the network unless it appears to be connected in the TEDB. In this case, I
suggest that what is needed is to represent those (legacy?) devices/subnetworks as
Forwarding Adjacencies or virtual TE links. This requires some advertisement by a control
plane entity on behalf of the devices/subnetworks, but does not expose the details of the
connectivity of the devices that do not support routing.

Some of you may (from time to time) hear me burble on about the fact that soft permanent
LSPs should not simply cover the case where the permanent part is at the edge of the
network. When I ramble in this way, I am talking about the second case, above.

Cheers,
Adrian





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 23:30:08 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: [e-mail]
Cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Stepping back from the ASON Routing Discussion
Date: Wed, 17 Mar 2004 18:26:52 -0500

Hi Dimitri

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 
> Sent: Wednesday, March 17, 2004 4:06 PM
> 
> don
> 
> Don Fedyk wrote:
> 
> > Hi Adrian
> > 
> > I had to step away from my computer for a snowstorm looks 
> like there 
> > was a bit of a flurry here too;-) I'll try to stick to the 
> questions 
> > and answers as I know them.
> > 
> > See inline
> > 
> > 
> >>-----Original Message-----
> >>From: Adrian Farrel [mailto:[e-mail]]
> >>Sent: Tuesday, March 16, 2004 5:44 PM
> >>To: [e-mail]
> >>Subject: Stepping back from the ASON Routing Discussion
> >>
> >>
> >>Just stepping back a moment...
> >>
> >>It feels to me that we are getting drawn into discussions of
> >>what can and cannot be achieved using existing protocols. 
> >>This is all very valid, but is clearly not part of the 
> >>requirements work.
> >>
> >>I understand that the DT wishes to analyse the changes to
> >>existing protocols to meet the requirements under the charter 
> >>phrase "to capture what's missing from current CCAMP work", 
> >>but I feel that this is clouding (and delaying) the 
> >>production of a clear requirements draft.
> >>
> >>So looking at the three topics that Deborah raised.
> >>
> >>1.
> >>Some members of the Design Team noted that reachability
> >>information (as described in Section 4.5.3) may be advertised 
> >>as a set of UNI Transport Resource address prefixes (assigned 
> >>and selected consistently in their applicability scope). 
> >>These members of the Design Team raised a concern that 
> >>existing methods of advertising reachability may need to be 
> >>examined (on a per-protocol basis) to determine if they are 
> >>also applicable for UNI Transport Resource addresses. They 
> >>invite CCAMP discussion on this aspect.
> >>
> >>The first sentence is about requirements.
> >>Do we, or do we not, need to support advertising UNI
> >>Transport Resource address prefixes?
> > 
> > My opinion is Yes there is a requirement in signaling protocols 
> > requirement to signal a name i.e. UNI TR address (complete).
> 
> i have some difficulties to map the above sentence with the 
> below, for me reading this it is yes and then no i've another 
> way so i don't need, and the below is the real problem of 
> course the name resolution into the address prefix and one 
> uses the address prefix not the name in the signaling, why 
> shall you assume that the names are distributed but not their 
> corresponding prefixes or the mechanism to resolve them?

Sorry I was trying to be consistent. I see the requirement of multiple
address types. What I don't see is a requirement that says to support
multiple addresses you have to have multiple addresses in every TLV in every
routing protocol. The relationship is like VoIP or even host names and IP
addresses. A user should be able to type in a destination UNI TR address and
without any other addressing a path/call/connection comes up. The fact that
internal translations were used is transparent to the user.  The other
requirement I see is that the systems not be tied solely to UNI TR address
forever. The fact that internal translations were used is a key for
evolution/flexibiity. 

As for address/name resolution it is very common to put the minimal
resolution information when you are distant from the address and refine it
as you get closer to the destination. I only see requirements for minimal
resolution of addresses/names outside the area. That is practical and
flexible.

> 
> > No in inter domain routing. Requirement addresses must be 
> able to be 
> > aggregated and names are not. The requirement is that a UNI 
> TR address 
> > must resolve to an Prefix address (For GMPLS routing IP 
> prefix fits). 
> > That leaves intra domain routing. The requirement is to have a 
> > destination address resolution. You are signaling with a UNI TR 
> > address (complete) and you have a IP address prefix or 
> nothing.  The 
> > problem is IP cannot take you all the way because resolving 
> completely 
> > outside of the area is not a requirement. But inside the area you 
> > should be able to resolve a UNI TR address to a IP address Control 
> > plane element.
> > 
> > 
> >>The second sentence is about solutions and is not relevant in
> >>this draft.
> >>
> >>2.
> >>ASON does not restrict the architecture choices used, either
> >>a co-located architecture or a physically separated 
> >>architecture may be used. Some members of the Design Team are 
> >>concerned that GMPLS's concept of the LSR requires a 1-to-1 
> >>relationship between the transport plane entity and the 
> >>control plane entity (Router). They invite CCAMP input on 
> >>GMPLS capabilities to support multiple architectures i.e. how 
> >>routing protocols would identify the transport node ID vs. 
> >>the router or routing controller ID when scoping Link IDs in 
> >>a link advertisement.
> >>
> >>The first sentence is about requirements.
> >>Do we, or do we not need to support a physically separated
> >>architecture with a 1-n relationship between control plane 
> >>and transport plane entities?
> > 
> > I would say yes. The requirement I see here is devices not 
> capable of 
> > participating fully in GMPLS routing.
> 
> but in 1-n, 1 controls n, and 1 participates to the routing, 
> the devices (part of the set n) are data plane entities that 
> are by definition not gmpls capable, so i don't understand 
> what you try to say here by the above justification
> 
The device/controller that speaks GMPLS may speak on behalf of devices that
don't. 

> >>The remaining text is about solutions and not relevant in 
> this draft.
> >>
> >>3.
> >>In order to support operator assisted changes in the
> >>containment relationships of RAs, the GMPLS routing protocol 
> >>is expected to support evolution in terms of number of 
> >>hierarchical levels of RAs (adding and removing RAs at the 
> >>top/bottom of the hierarchy), as well as aggregation and 
> >>segmentation of RAs. These GMPLS routing capabilities are 
> >>considered of lower priority as they are implementation 
> >>specific and their method of support should be evaluated on 
> >>per-protocol basis e.g. OSPF vs IS-IS. In addition, support 
> >>of non-disruptive operations such as adding or removing a 
> >>hierarchical level of RAs in or from the middle of the 
> >>routing hierarchy are considered as the lowest priority 
> >>requirements. Note also that the number of hierarchical 
> >>levels to be supported is implementation specific, and 
> >>reflects a containment relationship e.g. a RA insertion 
> >>involves supporting a different routing protocol domain in a 
> >>portion of the network.
> >>Note: some members of the Design Team question if the ASON 
> >>requirement for supporting architecture evolution is a 
> >>requirement on the routing protocol (protocol specific
> >>capability) vs. a capability to be provided by the 
> >>architecture. For example, ASON allows for supporting 
> >>multiple protocols within each RA. The multiple protocols 
> >>share a common routing information database (RDB), and the 
> >>RDB is the component, which needs to support architecture 
> >>evolution. The Design Team invites CCAMP input to understand 
> >>the protocol-specific impacts.
> >>
> >>This seems to mix up requirements and solutions.
> >>It is not relevant what OSPF and IS-IS can or cannot do.
> >>
> >>The requirements questions are:
> >>A. What does ASON require in terms of evolution of
> >>hierarchies? B. Are these requirements immediate and high priority?
> > 
> > No comment from me.
> > 
> > 
> >>
> >>Is it reasonable to make this separation between
> >>requirements, and consequent required changes to the 
> >>protocols? If so, can we focus on the requirements and make 
> >>some rapid progress?
> > 
> > 
> > Hope that helps,
> > Don
> > 
> >>Thanks,
> >>Adrian
> >>
> >>
> >>
> > 
> > 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : [e-mail]
> E-mail : [e-mail]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : [phone]
> 

Regards,
Don 
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 23:08:07 +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: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Wed, 17 Mar 2004 23:06:58 -0000
Message-ID: <[e-mail]>
Thread-Topic: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Thread-Index: AcQMYrpKMH9CZZ39RIeP39zZHgWS+AAC/QJQ
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

Yakov/Zafar,

<snipped?=20
> > Are you saying that just because RSVP control plan at the=20
> neighbor is up
> > means that it's in-sync, given that we don't use a reliable=20
> transport
> > mechanics? We still need to rely on RSVP refresh messages for
> > maintaining states; this is just "HOW" RSVP protocol is=20
> defined. And NOT
> > to mention about existing implementations and deployments.=20
>=20
> Wrt "we don't use a reliable transport mechanics", I assume that
> one uses rfc2961 (RSVP Refresh Overhead Reduction Extensions),
> which (among other things) supports reliable RSVP message delivery.
>=20
> Wrt maintaining/refreshing state, we could still rely on RSVP
> refresh messages.  But wrt detecting liveness of the neighbor's
> RSVP module, I think using RSVP Hellos is a better alternative than
> relying on on RSVP refresh messages.
>=20
> More generally, refreshing state and protocol liveness detection
> need not be coupled, and should not be coupled. For an example look
> at ISIS or OSPF - resending LSAs to refresh state, sending Hellos
> to provide protocol liveness detection.
>=20
> Yakov.
NH=3D> I have to say I tend to agree with Yakov's view here.  The =
'hello' function is a basic OAM connectivity verification of networking =
protocols.  It should not be proxied by other functions of those =
protocols.  It also reminds me of the case of trying to use a networking =
protocol's 'hello' OAM capability to proxy for the traffic's data =
data-plane OAM.  This is also wrong.  In some network modes there are =
logically (and in some cases physically) disjoint data-planes for =
customer traffic and control/management-plane traffic.  In summary:
-	each networking protocol needs its own OAM....and more generally needs =
its own exception-handling for the protocol (the 'hello' function is a =
basic connectivity verification exception handling capability)
-	network protocol OAM (eg in control/management-plane protocols) should =
in general not be used to proxy for traffic data-plane OAM

regards, Neil
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 22:03:53 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Wed, 17 Mar 2004 17:02:53 -0500
Organization: Cisco Systems
Message-ID: <000001c40c6b$9d41b6a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see my comments in-line. 

Thanks
 
Regards... Zafar

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf 
>Of Yakov Rekhter
>Sent: Wednesday, March 17, 2004 3:58 PM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>[clipped...]
>
>> >> >> >In principle one could use the refresh mechanism as a liveness
>> >> >> >detection of the RSVP module of the control plane. 
>However, the 
>> >> >> >overhead of the refresh mechanism is certainly higher than of 
>> >> >> >Hello. And that is why using RSVP Hellos for 
>detecting liveness of 
>> >> >> >RSVP module of the control plane seems to be the best 
>available 
>> >> >> >today (note that "best" does not imply "the only").
>> >> >> 
>> >> >> So we are in agreement :-)
>> >> >
>> >> >So you agree that (a) RSVP Hello should be used to 
>detect liveness 
>> >> >of RSVP module, and (b) any use of RSVP should include (among 
>> >> >other
>> >> >things) the ability to detect liveness of the RSVP module of a
>> >> >neighbor. Correct ?
>> >> >
>> >> 
>> >> No, unless you can please point me to a place where such use of 
>> >> RSVP
>> >> Hello is documented. What you wanted to do can ONLY be 
>achieved if 
>> >> RSVP Hello protocol is mandatory. The fact remains that 
>RSVP Hellos 
>> >> are "optional" and standard RSVP (RFC2205) "IS" required 
>to maintain 
>> >> state via the generation of RSVP refresh messages.
>> >
>> >And what is wrong with making RSVP Hellos mandatory, and use it as
>> >*the* mechanism to determing the state of the RSVP module on a
>> >neighbor ?
>> 
>> Are you saying that just because RSVP control plan at the 
>neighbor is 
>> up means that it's in-sync, given that we don't use a reliable 
>> transport mechanics? We still need to rely on RSVP refresh messages 
>> for maintaining states; this is just "HOW" RSVP protocol is defined. 
>> And NOT to mention about existing implementations and deployments.
>
>Wrt "we don't use a reliable transport mechanics", I assume 
>that one uses rfc2961 (RSVP Refresh Overhead Reduction 
>Extensions), which (among other things) supports reliable RSVP 
>message delivery.

Yes, I wanted to imply that RSVP requires refresh mechanics. 

>
>Wrt maintaining/refreshing state, we could still rely on RSVP 
>refresh messages.  But wrt detecting liveness of the 
>neighbor's RSVP module, I think using RSVP Hellos is a better 
>alternative than relying on on RSVP refresh messages.
>

For what you are saying, why would someone not use RSVP/ GR? IMO the
best thing to do is to use RSVP GR procedure. If RSVP/ GR is NOT
enabled, what actions you expect a node to take when it detects failures
at the neighbor's RSVP module. Are such actions documented and agreed
upon some where? No matter what your answer would be, my question will
remain, "in such case, why would someone not use RSVP/ GR?". 

Thanks

Regards... Zafar




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 21:41:30 +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: Stepping back from the ASON Routing Discussion
Date: Wed, 17 Mar 2004 15:40:25 -0600
Message-ID: <[e-mail]>
Thread-Topic: Stepping back from the ASON Routing Discussion
Thread-Index: AcQLtT3EilCesBAuQMeB+oFi9XU4awAnl0Bg
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Agree, it would be better to separate and focus on the requirements =
first. Additional comments below. As I summarized below, the DT will =
redo the draft and limit to requirements only.
Thanks,
Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Adrian Farrel
Sent: Tuesday, March 16, 2004 5:44 PM
To: [e-mail]
Subject: Stepping back from the ASON Routing Discussion


Just stepping back a moment...

It feels to me that we are getting drawn into discussions of what can =
and cannot be
achieved using existing protocols. This is all very valid, but is =
clearly not part of the
requirements work.

I understand that the DT wishes to analyse the changes to existing =
protocols to meet the
requirements under the charter phrase "to capture
what's missing from current CCAMP work", but I feel that this is =
clouding (and delaying)
the production of a clear requirements draft.

So looking at the three topics that Deborah raised.

1.
Some members of the Design Team noted that reachability information (as =
described in
Section 4.5.3) may be advertised as a set of UNI Transport Resource =
address prefixes
(assigned and selected consistently in their applicability scope). These =
members of the
Design Team raised a concern that existing methods of advertising =
reachability may need to
be examined (on a per-protocol basis) to determine if they are also =
applicable for UNI
Transport Resource addresses. They invite CCAMP discussion on this =
aspect.

The first sentence is about requirements.
Do we, or do we not, need to support advertising UNI Transport Resource =
address prefixes?

The second sentence is about solutions and is not relevant in this =
draft.

db> As Jonathan corrected, reachability information advertised will =
depend on the applicable scope. The definition/requirement is the first =
sentence of the paragraph "Reachability information describes the set of =
endpoints that are reachable by the associated node." How (UNI =
address/SNPP) this is advertised is a "MAY". Additional note, on-going =
discussion in ITU is considering more appropriate terminology for UNI =
address is "name". Also, G7715.1 does not specify how/what reachability =
information is exchanged. Two hierarchical approaches are described, it =
is acknowledged in G7715.1 that multiple approaches exist.=20

2.
ASON does not restrict the architecture choices used, either a =
co-located architecture or
a physically separated architecture may be used. Some members of the =
Design Team are
concerned that GMPLS's concept of the LSR requires a 1-to-1 relationship =
between the
transport plane entity and the control plane entity (Router). They =
invite CCAMP input on
GMPLS capabilities to support multiple architectures i.e. how routing =
protocols would
identify the transport node ID vs. the router or routing controller ID =
when scoping Link
IDs in a link advertisement.

The first sentence is about requirements.
Do we, or do we not need to support a physically separated architecture =
with a 1-n
relationship between control plane and transport plane entities?

The remaining text is about solutions and not relevant in this draft.

db> Support by "one" of "all" physical architectures is a "MAY". ASON =
does not restrict the architecture choice or realization. As ASON does =
not (at this time) include any performance requirements, as a carrier, I =
need to understand the protocol choices/tradeoffs if supporting a =
co-located (integrated) model vs. targeting a "one for all".

3.
In order to support operator assisted changes in the containment =
relationships of RAs, the
GMPLS routing protocol is expected to support evolution in terms of =
number of hierarchical
levels of RAs (adding and removing RAs at the top/bottom of the =
hierarchy), as well as
aggregation and segmentation of RAs. These GMPLS routing capabilities =
are considered of
lower priority as they are implementation specific and their method of =
support should be
evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition, support =
of non-disruptive
operations such as adding or removing a hierarchical level of RAs in or =
from the middle of
the routing hierarchy are considered as the lowest priority =
requirements. Note also that
the number of hierarchical levels to be supported is implementation =
specific, and reflects
a containment relationship e.g. a RA insertion involves supporting a =
different routing
protocol domain in a portion of the network.
Note: some members of the Design Team question if the ASON requirement =
for supporting
architecture evolution is a requirement on the routing protocol =
(protocol specific
capability) vs. a capability to be provided by the architecture. For =
example, ASON allows
for supporting multiple protocols within each RA. The multiple protocols =
share a common
routing information database (RDB), and the RDB is the component, which =
needs to support
architecture evolution. The Design Team invites CCAMP input to =
understand the
protocol-specific impacts.

This seems to mix up requirements and solutions.
It is not relevant what OSPF and IS-IS can or cannot do.

The requirements questions are:
A. What does ASON require in terms of evolution of hierarchies?

db> As Jonathan's notes, it is RA evolution (not the protocol). An ASON =
RA is a network subdivision (hierarchical level) which may contain =
multiple (different) routing protocols, it is not referring to one =
protocol's architectural subdivision. Jonathan's "further illustrated" =
list (for those unfamiliar with ITU terminology) is from an appendix =
illustrating examples (i.e. non-normative).

B. Are these requirements immediate and high priority?

db> The requirements are differentiated as shall/must and should/may.

Is it reasonable to make this separation between requirements, and =
consequent required
changes to the protocols? If so, can we focus on the requirements and =
make some
rapid progress?

db>The Design Team will redo the draft and limit to requirements only.

Thanks,
Adrian





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 21:19:16 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Mar 2004 22:19:41 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Jonathan Sadler <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: Stepping back from the ASON Routing Discussion
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

jonathan,

Jonathan Sadler wrote:

> Hi Adrian -
> 
> Adrian Farrel wrote:
> 
> 
>>Just stepping back a moment...
>>
>>It feels to me that we are getting drawn into discussions of what can and cannot be
>>achieved using existing protocols. This is all very valid, but is clearly not part of the
>>requirements work.
>>
>>I understand that the DT wishes to analyse the changes to existing protocols to meet the
>>requirements under the charter phrase "to capture
>>what's missing from current CCAMP work", but I feel that this is clouding (and delaying)
>>the production of a clear requirements draft.
>>
>>So looking at the three topics that Deborah raised.
>>
>>1.
>>Some members of the Design Team noted that reachability information (as described in
>>Section 4.5.3) may be advertised as a set of UNI Transport Resource address prefixes
>>(assigned and selected consistently in their applicability scope). These members of the
>>Design Team raised a concern that existing methods of advertising reachability may need to
>>be examined (on a per-protocol basis) to determine if they are also applicable for UNI
>>Transport Resource addresses. They invite CCAMP discussion on this aspect.
>>
>>The first sentence is about requirements.
>>Do we, or do we not, need to support advertising UNI Transport Resource address prefixes?
> 
> 
> There is a requirement to be able to advertise reachability (G.7715 sec7.1.1, G.7715.1 sec
> 9.4).  G.7715.1 states:
>   Reachability Information: Reachability information describes
>   the set of endpoints that are reachable by the associated node.
>   It may be advertised either as a set of UNI Transport Resource
>   addresses/address prefixes, or a set of associated
>   SNPP IDs/SNPP ID prefixes, the selection of which must be
>   consistent within the applicable scope.
> so technically, there isn't a requirement to advertise UNI Transport Resource Addresses -- the
> requirement is to advertise reachability in terms of SNPP IDs or UNI Transport Resources
> Addresses.

i've checked in the i-d and it also says "may" inline with this but then 
the question becomes (assuming that reachability information is a 
requirement) that the alternatives may not be suitable for one
reason or another, most people say yes but this is not how imho .1 
reads, it is non limitative but not all inclusive for all control plane 
realizations

> It should be noted that there is a unique attribute of SNPP Prefixes and UNI Transport
> Resource Addresses -- they exist independant of layer networks.  More specifically, UNI
> Transport Resource Addresses are used to name an Access Group Container, where the Access
> Groups within the Container can be in one or more layer networks.  So, it cannot be assumed
> that a specific UNI Transport Resource Address is in Layer Network A or B.
> 
> 
>>The second sentence is about solutions and is not relevant in this draft.
>>
>>2.
>>ASON does not restrict the architecture choices used, either a co-located architecture or
>>a physically separated architecture may be used. Some members of the Design Team are
>>concerned that GMPLS's concept of the LSR requires a 1-to-1 relationship between the
>>transport plane entity and the control plane entity (Router). They invite CCAMP input on
>>GMPLS capabilities to support multiple architectures i.e. how routing protocols would
>>identify the transport node ID vs. the router or routing controller ID when scoping Link
>>IDs in a link advertisement.
>>
>>The first sentence is about requirements.
>>Do we, or do we not need to support a physically separated architecture with a 1-n
>>relationship between control plane and transport plane entities?
> 
> 
> Yes.

if the sentence reads "ASON does not restrict the architecture choices 
used, either a 1-1 architecture or a 1-n architecture between control
plane and transport plane entities" - this issue about physical co-
location is not a control plane requirement i don't think ASON has any
requirement in terms of internal vs external bus vs external network,
you're just degrading the performance - said in another way no control 
plane restricts this you can run 1000 of instances of the control plane 
on a single control plane entity to manage 1000 devices is there 
something specific to ASON here ? so as this a requirement shouldn't be 
something like "ASON control plane entity distribution and behaviour is 
independent of the actual distribution of the resources it controls."
in charge for the protocol to deliver the mechanism(s) to support this
flexibility in the architecture ?

>>The remaining text is about solutions and not relevant in this draft.
>>
>>3.
>>In order to support operator assisted changes in the containment relationships of RAs, the
>>GMPLS routing protocol is expected to support evolution in terms of number of hierarchical
>>levels of RAs (adding and removing RAs at the top/bottom of the hierarchy), as well as
>>aggregation and segmentation of RAs. These GMPLS routing capabilities are considered of
>>lower priority as they are implementation specific and their method of support should be
>>evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition, support of non-disruptive
>>operations such as adding or removing a hierarchical level of RAs in or from the middle of
>>the routing hierarchy are considered as the lowest priority requirements. Note also that
>>the number of hierarchical levels to be supported is implementation specific, and reflects
>>a containment relationship e.g. a RA insertion involves supporting a different routing
>>protocol domain in a portion of the network.
>>Note: some members of the Design Team question if the ASON requirement for supporting
>>architecture evolution is a requirement on the routing protocol (protocol specific
>>capability) vs. a capability to be provided by the architecture. For example, ASON allows
>>for supporting multiple protocols within each RA. The multiple protocols share a common
>>routing information database (RDB), and the RDB is the component, which needs to support
>>architecture evolution. The Design Team invites CCAMP input to understand the
>>protocol-specific impacts.
>>
>>This seems to mix up requirements and solutions.
>>It is not relevant what OSPF and IS-IS can or cannot do.
>>
>>The requirements questions are:
>>A. What does ASON require in terms of evolution of hierarchies?
> 
> 
> The requirements stated in G.7715.1 are:
>   "...the routing protocol shall be capable of supporting
>   architectural evolution in terms of number of hierarchical
>   levels, as well as aggregation and segmentation of RAs."
> 
> This is further illustrated as being:
>  - Segmentation of one Routing Area into two separate RAs
>  - Aggregation of two RAs into one RA
>  - Renaming of RAs
>  - Insertion of an RA into the hierarchy
>  - Deletion of an RA from the hierarchy
> 
> Insertion and Deletion can be done at any point in the hierarchy -- it is not limited to just
> the top or bottom of the hierarchy.
> 
> 
>>B. Are these requirements immediate and high priority?
> 
> 
> No statement of immediate/high priority exists in the ASON documents for any ASON requirement.

on this one rephrasing is needed, can we agree on a specific (condensed) 
text and say re-ask the same question, what i would propose is

"In order to support operator assisted changes in the containment 
relationships of RAs, the GMPLS routing protocol is expected to support 
evolution in terms of number of hierarchical levels of RAs. Example: 
support of non-disruptive operations such as adding and removing RAs at 
the top/bottom of the hierarchy, adding or removing a hierarchical level 
of RAs in or from the middle of the hierarchy, as well as aggregation 
and segmentation of RAs."

as the illustration was non-normative anyway

>>Is it reasonable to make this separation between requirements, and consequent required
>>changes to the protocols? If so, can we focus on the requirements and make some
>>rapid progress?
>>
>>Thanks,
>>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
> ============================================================

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 21:05:08 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Mar 2004 22:06:17 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Don Fedyk <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: Stepping back from the ASON Routing Discussion
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

don

Don Fedyk wrote:

> Hi Adrian
> 
> I had to step away from my computer for a snowstorm looks like there was a
> bit of a flurry here too;-) 
> I'll try to stick to the questions and answers as I know them. 
> 
> See inline
> 
> 
>>-----Original Message-----
>>From: Adrian Farrel [mailto:[e-mail]] 
>>Sent: Tuesday, March 16, 2004 5:44 PM
>>To: [e-mail]
>>Subject: Stepping back from the ASON Routing Discussion
>>
>>
>>Just stepping back a moment...
>>
>>It feels to me that we are getting drawn into discussions of 
>>what can and cannot be achieved using existing protocols. 
>>This is all very valid, but is clearly not part of the 
>>requirements work.
>>
>>I understand that the DT wishes to analyse the changes to 
>>existing protocols to meet the requirements under the charter 
>>phrase "to capture what's missing from current CCAMP work", 
>>but I feel that this is clouding (and delaying) the 
>>production of a clear requirements draft.
>>
>>So looking at the three topics that Deborah raised.
>>
>>1.
>>Some members of the Design Team noted that reachability 
>>information (as described in Section 4.5.3) may be advertised 
>>as a set of UNI Transport Resource address prefixes (assigned 
>>and selected consistently in their applicability scope). 
>>These members of the Design Team raised a concern that 
>>existing methods of advertising reachability may need to be 
>>examined (on a per-protocol basis) to determine if they are 
>>also applicable for UNI Transport Resource addresses. They 
>>invite CCAMP discussion on this aspect.
>>
>>The first sentence is about requirements.
>>Do we, or do we not, need to support advertising UNI 
>>Transport Resource address prefixes?
> 
> My opinion is Yes there is a requirement in signaling protocols requirement
> to signal a name i.e. UNI TR address (complete). 

i have some difficulties to map the above sentence with the
below, for me reading this it is yes and then no i've another
way so i don't need, and the below is the real problem of
course the name resolution into the address prefix and one
uses the address prefix not the name in the signaling, why
shall you assume that the names are distributed but not their
corresponding prefixes or the mechanism to resolve them?

> No in inter domain routing. Requirement addresses must be able to be
> aggregated and names are not. The requirement is that a UNI TR address must
> resolve to an Prefix address (For GMPLS routing IP prefix fits). 
> That leaves intra domain routing. The requirement is to have a destination
> address resolution. You are signaling with a UNI TR address (complete) and
> you have a IP address prefix or nothing.  The problem is IP cannot take you
> all the way because resolving completely outside of the area is not a
> requirement. But inside the area you should be able to resolve a UNI TR
> address to a IP address Control plane element. 
> 
> 
>>The second sentence is about solutions and is not relevant in 
>>this draft.
>>
>>2.
>>ASON does not restrict the architecture choices used, either 
>>a co-located architecture or a physically separated 
>>architecture may be used. Some members of the Design Team are 
>>concerned that GMPLS's concept of the LSR requires a 1-to-1 
>>relationship between the transport plane entity and the 
>>control plane entity (Router). They invite CCAMP input on 
>>GMPLS capabilities to support multiple architectures i.e. how 
>>routing protocols would identify the transport node ID vs. 
>>the router or routing controller ID when scoping Link IDs in 
>>a link advertisement.
>>
>>The first sentence is about requirements.
>>Do we, or do we not need to support a physically separated 
>>architecture with a 1-n relationship between control plane 
>>and transport plane entities?
> 
> I would say yes. The requirement I see here is devices not capable of
> participating fully in GMPLS routing.

but in 1-n, 1 controls n, and 1 participates to the routing,
the devices (part of the set n) are data plane entities that
are by definition not gmpls capable, so i don't understand
what you try to say here by the above justification

>>The remaining text is about solutions and not relevant in this draft.
>>
>>3.
>>In order to support operator assisted changes in the 
>>containment relationships of RAs, the GMPLS routing protocol 
>>is expected to support evolution in terms of number of 
>>hierarchical levels of RAs (adding and removing RAs at the 
>>top/bottom of the hierarchy), as well as aggregation and 
>>segmentation of RAs. These GMPLS routing capabilities are 
>>considered of lower priority as they are implementation 
>>specific and their method of support should be evaluated on 
>>per-protocol basis e.g. OSPF vs IS-IS. In addition, support 
>>of non-disruptive operations such as adding or removing a 
>>hierarchical level of RAs in or from the middle of the 
>>routing hierarchy are considered as the lowest priority 
>>requirements. Note also that the number of hierarchical 
>>levels to be supported is implementation specific, and 
>>reflects a containment relationship e.g. a RA insertion 
>>involves supporting a different routing protocol domain in a 
>>portion of the network.
>>Note: some members of the Design Team question if the ASON 
>>requirement for supporting architecture evolution is a 
>>requirement on the routing protocol (protocol specific
>>capability) vs. a capability to be provided by the 
>>architecture. For example, ASON allows for supporting 
>>multiple protocols within each RA. The multiple protocols 
>>share a common routing information database (RDB), and the 
>>RDB is the component, which needs to support architecture 
>>evolution. The Design Team invites CCAMP input to understand 
>>the protocol-specific impacts.
>>
>>This seems to mix up requirements and solutions.
>>It is not relevant what OSPF and IS-IS can or cannot do.
>>
>>The requirements questions are:
>>A. What does ASON require in terms of evolution of 
>>hierarchies? B. Are these requirements immediate and high priority?
> 
> No comment from me. 
> 
> 
>>
>>Is it reasonable to make this separation between 
>>requirements, and consequent required changes to the 
>>protocols? If so, can we focus on the requirements and make 
>>some rapid progress?
> 
> 
> Hope that helps,
> Don 
> 
>>Thanks,
>>Adrian
>>
>>
>>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 20:58:59 +0000
Message-Id: <[e-mail]>
To: "zafar ali" <[e-mail]>
cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, [e-mail], "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, [e-mail], "'Reshad Rahman'" <[e-mail]>, [e-mail]
Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 17 Mar 2004 12:57:45 -0800
From: Yakov Rekhter <[e-mail]>

Zafar,

[clipped...]

> >> >> >In principle one could use the refresh mechanism as a liveness 
> >> >> >detection of the RSVP module of the control plane. However, the 
> >> >> >overhead of the refresh mechanism is certainly higher than of 
> >> >> >Hello. And that is why using RSVP Hellos for detecting liveness of 
> >> >> >RSVP module of the control plane seems to be the best available 
> >> >> >today (note that "best" does not imply "the only").
> >> >> 
> >> >> So we are in agreement :-)
> >> >
> >> >So you agree that (a) RSVP Hello should be used to detect
> >> >liveness of RSVP module, and (b) any use of RSVP should 
> >> >include (among other
> >> >things) the ability to detect liveness of the RSVP module of a 
> >> >neighbor. Correct ?
> >> >
> >> 
> >> No, unless you can please point me to a place where such use of RSVP 
> >> Hello is documented. What you wanted to do can ONLY be achieved if 
> >> RSVP Hello protocol is mandatory. The fact remains that RSVP Hellos 
> >> are "optional" and standard RSVP (RFC2205) "IS" required to maintain 
> >> state via the generation of RSVP refresh messages.
> >
> >And what is wrong with making RSVP Hellos mandatory, and use it as
> >*the* mechanism to determing the state of the RSVP module on a 
> >neighbor ?
> 
> Are you saying that just because RSVP control plan at the neighbor is up
> means that it's in-sync, given that we don't use a reliable transport
> mechanics? We still need to rely on RSVP refresh messages for
> maintaining states; this is just "HOW" RSVP protocol is defined. And NOT
> to mention about existing implementations and deployments. 

Wrt "we don't use a reliable transport mechanics", I assume that
one uses rfc2961 (RSVP Refresh Overhead Reduction Extensions),
which (among other things) supports reliable RSVP message delivery.

Wrt maintaining/refreshing state, we could still rely on RSVP
refresh messages.  But wrt detecting liveness of the neighbor's
RSVP module, I think using RSVP Hellos is a better alternative than
relying on on RSVP refresh messages.

More generally, refreshing state and protocol liveness detection
need not be coupled, and should not be coupled. For an example look
at ISIS or OSPF - resending LSAs to refresh state, sending Hellos
to provide protocol liveness detection.

Yakov.



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 20:11:56 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Mar 2004 21:10:56 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Tomonori TAKEDA <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [RE] Layer One VPNs - sorry for the previous email
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi tomonori,

Tomonori TAKEDA wrote:

> Hi, Dimitri
> 
> Thank you for your comments. Please see my comments in line.
> 
> At 18:39 04/03/15 +0100, [e-mail] wrote:
> 
>> hi tomonori, young, all,
>>
>> the proposed framework document (part of this discussion)
>> deliversa good starting point in terms of functionality
>>
>> some more specific comment on this document:
>>
>> - it mentions an issue concerning the "shared control link" it
>> may be advisable to detail more accurately the expectation in
>> terms of functionality and then assess whether a shared control
>> link can be used in this context, the addition to which you're
>> referring seems to imply a mux/de-mux mechanism - it would be
>> of great interest to see how this compares with Section 4 of
>> the GVPN id
> 
> 
> Okay, let me try to answer your comments.
> 
> For control link between the CE and the PE, I would say there are three 
> categories.
> 
> 1) Physically disjoint control link
> 2) IP-level disjoint control link (e.g., GRE tunnel)
> 3) IP-level shared control link
> 
> Shared control link generally refers to category 3).
> 
>  From here, I am describing more than what is described in the ID.
> 
> Category 3) is typically the case that the same CE device belongs to 
> multiple VPNs (or the CE device contains multiple VPN instances), as 
> described in section 6.1 of the ID. In this case, to distinguish 
> messages exchanged over the control channel, some mechanisms are needed, 
> and addition of VPN ID seems one way to do.
> 
> In GVPN ID, my understanding is that logical CE-PE links (or 
> association) belong to each VPN. L1VPN framework ID is in line with this 
> (as described in section 6.1), but this ID goes beyond and tackles the 
> case for shared control channel.

this was over time also my understanding of your intention and we may 
point this as something to be further discussed from a solution 
perspective in case of acceptance of this work item w/i ietf scope

>> - section 4.1, performance is included as service do you mean
>> this as a classification of the quality of the delivered service
>> or do you mean that it is a service to allow customer to monitor
>> performance of the delivered service ?
> 
> 
> I mean the former.
> 
> To make sure, I mean that performance is one of the items that specify 
> the service. (or the service defines the level of performance.)

ok, this clarifies

>> - there is the issue of the "PE-PE virtual links" and in case of
>> "Per VPN Peer model" more details should be provided in order to
>> assess whether existing GMPLS mechanisms are sufficient (from
>> that perspective details about the following sentence might be
>> of interest because it seems you took this as initial working
>> assumption "there is currently no leakage of routing information
>> across the PE to CE boundary.")
> 
> 
> Agree. Providing more details about service requirements may be helpful 
> ? Functional requirements are also important, but before going that in 
> details, more clear service level requirements may be useful.

do you plan to deliver those as part of the user community or do you 
expect this input to come from SG13 - or both - ? just to know about the 
timeframe we may expect here since there are very interesting issues 
you're introducing with the above approaches

> Concerning the initial working assumption you mentioned, we started from 
> the most acknowledged model for the service interface, that is the UNI. 
> That is why we put above text.

so you started with a signaling interface, and then try to build on top 
of it the necessary pieces

>> - i would suggest to conclude the document with the expected
>> delta requirement from gmpls perspective (this would help in
>> assessing what's expected in terms of protocol for the next
>> step(s))
> 
> 
> Okay, if CCAMP is going to work on the L1 VPN, I agree delta requirement 
> would be an important step.
> 
> Do you have anything in your mind ?

try to collect all the sentences that are part of the present document 
that either implicitly or explicitly determine a feature to be covered
list them in terms of signaling and routing, i think we would gain a lot 
of precious time in having such conclusion in case decision to work on 
solution is accepted

>> - an edit concerning the section on terminology it would be
>> of great help for this community to point the differences (if
>> any) from the existing [TERM] document
> 
> 
> Thanks. I would take that into the next version.

thanks,
- dimitri.

> Best regards,
> 
>> thanks,
>> - dimitri.
> 
> 
> -----
> Tomonori TAKEDA
> NTT Network Service Systems Lab.
> Phone: [phone]
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 17:40:47 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Mar 2004 11:39:55 -0600
From: Jonathan Sadler <[e-mail]>
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Stepping back from the ASON Routing Discussion
Content-Type: multipart/alternative; boundary="------------6E0BA8908C9D638C4DBC24EA"

--------------6E0BA8908C9D638C4DBC24EA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Adrian -

Adrian Farrel wrote:

> Just stepping back a moment...
>
> It feels to me that we are getting drawn into discussions of what can and cannot be
> achieved using existing protocols. This is all very valid, but is clearly not part of the
> requirements work.
>
> I understand that the DT wishes to analyse the changes to existing protocols to meet the
> requirements under the charter phrase "to capture
> what's missing from current CCAMP work", but I feel that this is clouding (and delaying)
> the production of a clear requirements draft.
>
> So looking at the three topics that Deborah raised.
>
> 1.
> Some members of the Design Team noted that reachability information (as described in
> Section 4.5.3) may be advertised as a set of UNI Transport Resource address prefixes
> (assigned and selected consistently in their applicability scope). These members of the
> Design Team raised a concern that existing methods of advertising reachability may need to
> be examined (on a per-protocol basis) to determine if they are also applicable for UNI
> Transport Resource addresses. They invite CCAMP discussion on this aspect.
>
> The first sentence is about requirements.
> Do we, or do we not, need to support advertising UNI Transport Resource address prefixes?

There is a requirement to be able to advertise reachability (G.7715 sec7.1.1, G.7715.1 sec
9.4).  G.7715.1 states:
  Reachability Information: Reachability information describes
  the set of endpoints that are reachable by the associated node.
  It may be advertised either as a set of UNI Transport Resource
  addresses/address prefixes, or a set of associated
  SNPP IDs/SNPP ID prefixes, the selection of which must be
  consistent within the applicable scope.
so technically, there isn't a requirement to advertise UNI Transport Resource Addresses -- the
requirement is to advertise reachability in terms of SNPP IDs or UNI Transport Resources
Addresses.

It should be noted that there is a unique attribute of SNPP Prefixes and UNI Transport
Resource Addresses -- they exist independant of layer networks.  More specifically, UNI
Transport Resource Addresses are used to name an Access Group Container, where the Access
Groups within the Container can be in one or more layer networks.  So, it cannot be assumed
that a specific UNI Transport Resource Address is in Layer Network A or B.

> The second sentence is about solutions and is not relevant in this draft.
>
> 2.
> ASON does not restrict the architecture choices used, either a co-located architecture or
> a physically separated architecture may be used. Some members of the Design Team are
> concerned that GMPLS's concept of the LSR requires a 1-to-1 relationship between the
> transport plane entity and the control plane entity (Router). They invite CCAMP input on
> GMPLS capabilities to support multiple architectures i.e. how routing protocols would
> identify the transport node ID vs. the router or routing controller ID when scoping Link
> IDs in a link advertisement.
>
> The first sentence is about requirements.
> Do we, or do we not need to support a physically separated architecture with a 1-n
> relationship between control plane and transport plane entities?

Yes.

> The remaining text is about solutions and not relevant in this draft.
>
> 3.
> In order to support operator assisted changes in the containment relationships of RAs, the
> GMPLS routing protocol is expected to support evolution in terms of number of hierarchical
> levels of RAs (adding and removing RAs at the top/bottom of the hierarchy), as well as
> aggregation and segmentation of RAs. These GMPLS routing capabilities are considered of
> lower priority as they are implementation specific and their method of support should be
> evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition, support of non-disruptive
> operations such as adding or removing a hierarchical level of RAs in or from the middle of
> the routing hierarchy are considered as the lowest priority requirements. Note also that
> the number of hierarchical levels to be supported is implementation specific, and reflects
> a containment relationship e.g. a RA insertion involves supporting a different routing
> protocol domain in a portion of the network.
> Note: some members of the Design Team question if the ASON requirement for supporting
> architecture evolution is a requirement on the routing protocol (protocol specific
> capability) vs. a capability to be provided by the architecture. For example, ASON allows
> for supporting multiple protocols within each RA. The multiple protocols share a common
> routing information database (RDB), and the RDB is the component, which needs to support
> architecture evolution. The Design Team invites CCAMP input to understand the
> protocol-specific impacts.
>
> This seems to mix up requirements and solutions.
> It is not relevant what OSPF and IS-IS can or cannot do.
>
> The requirements questions are:
> A. What does ASON require in terms of evolution of hierarchies?

The requirements stated in G.7715.1 are:
  "...the routing protocol shall be capable of supporting
  architectural evolution in terms of number of hierarchical
  levels, as well as aggregation and segmentation of RAs."

This is further illustrated as being:
 - Segmentation of one Routing Area into two separate RAs
 - Aggregation of two RAs into one RA
 - Renaming of RAs
 - Insertion of an RA into the hierarchy
 - Deletion of an RA from the hierarchy

Insertion and Deletion can be done at any point in the hierarchy -- it is not limited to just
the top or bottom of the hierarchy.

> B. Are these requirements immediate and high priority?

No statement of immediate/high priority exists in the ASON documents for any ASON requirement.

> Is it reasonable to make this separation between requirements, and consequent required
> changes to the protocols? If so, can we focus on the requirements and make some
> rapid progress?
>
> Thanks,
> 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
============================================================
--------------6E0BA8908C9D638C4DBC24EA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

<HTML>
<BODY>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Adrian -
<p>Adrian Farrel wrote:
<blockquote TYPE=CITE>Just stepping back a moment...
<p>It feels to me that we are getting drawn into discussions of what can
and cannot be
<br>achieved using existing protocols. This is all very valid, but is clearly
not part of the
<br>requirements work.
<p>I understand that the DT wishes to analyse the changes to existing protocols
to meet the
<br>requirements under the charter phrase "to capture
<br>what's missing from current CCAMP work", but I feel that this is clouding
(and delaying)
<br>the production of a clear requirements draft.
<p>So looking at the three topics that Deborah raised.
<p>1.
<br>Some members of the Design Team noted that reachability information
(as described in
<br>Section 4.5.3) may be advertised as a set of UNI Transport Resource
address prefixes
<br>(assigned and selected consistently in their applicability scope).
These members of the
<br>Design Team raised a concern that existing methods of advertising reachability
may need to
<br>be examined (on a per-protocol basis) to determine if they are also
applicable for UNI
<br>Transport Resource addresses. They invite CCAMP discussion on this
aspect.
<p>The first sentence is about requirements.
<br>Do we, or do we not, need to support advertising UNI Transport Resource
address prefixes?</blockquote>
There is a requirement to be able to advertise reachability (G.7715 sec7.1.1,
G.7715.1 sec 9.4).&nbsp; G.7715.1 states:
<br><tt>&nbsp; Reachability Information: Reachability information describes</tt>
<br><tt>&nbsp; the set of endpoints that are reachable by the associated
node.</tt>
<br><tt>&nbsp; It may be advertised either as a set of UNI Transport Resource</tt>
<br><tt>&nbsp; addresses/address prefixes, or a set of associated</tt>
<br><tt>&nbsp; SNPP IDs/SNPP ID prefixes, the selection of which must be</tt>
<br><tt>&nbsp; consistent within the applicable scope.</tt>
<br>so technically, there isn't a requirement to advertise UNI Transport
Resource Addresses -- the requirement is to advertise reachability in terms
of SNPP IDs or UNI Transport Resources Addresses.
<p>It should be noted that there is a unique attribute of SNPP Prefixes
and UNI Transport Resource Addresses -- they exist independant of layer
networks.&nbsp; More specifically, UNI Transport Resource Addresses are
used to name an Access Group Container, where the Access Groups within
the Container can be in one or more layer networks.&nbsp; So, it cannot
be assumed that a specific UNI Transport Resource Address is in Layer Network
A or B.
<blockquote TYPE=CITE>The second sentence is about solutions and is not
relevant in this draft.
<p>2.
<br>ASON does not restrict the architecture choices used, either a co-located
architecture or
<br>a physically separated architecture may be used. Some members of the
Design Team are
<br>concerned that GMPLS's concept of the LSR requires a 1-to-1 relationship
between the
<br>transport plane entity and the control plane entity (Router). They
invite CCAMP input on
<br>GMPLS capabilities to support multiple architectures i.e. how routing
protocols would
<br>identify the transport node ID vs. the router or routing controller
ID when scoping Link
<br>IDs in a link advertisement.
<p>The first sentence is about requirements.
<br>Do we, or do we not need to support a physically separated architecture
with a 1-n
<br>relationship between control plane and transport plane entities?</blockquote>
Yes.
<blockquote TYPE=CITE>The remaining text is about solutions and not relevant
in this draft.
<p>3.
<br>In order to support operator assisted changes in the containment relationships
of RAs, the
<br>GMPLS routing protocol is expected to support evolution in terms of
number of hierarchical
<br>levels of RAs (adding and removing RAs at the top/bottom of the hierarchy),
as well as
<br>aggregation and segmentation of RAs. These GMPLS routing capabilities
are considered of
<br>lower priority as they are implementation specific and their method
of support should be
<br>evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition, support
of non-disruptive
<br>operations such as adding or removing a hierarchical level of RAs in
or from the middle of
<br>the routing hierarchy are considered as the lowest priority requirements.
Note also that
<br>the number of hierarchical levels to be supported is implementation
specific, and reflects
<br>a containment relationship e.g. a RA insertion involves supporting
a different routing
<br>protocol domain in a portion of the network.
<br>Note: some members of the Design Team question if the ASON requirement
for supporting
<br>architecture evolution is a requirement on the routing protocol (protocol
specific
<br>capability) vs. a capability to be provided by the architecture. For
example, ASON allows
<br>for supporting multiple protocols within each RA. The multiple protocols
share a common
<br>routing information database (RDB), and the RDB is the component, which
needs to support
<br>architecture evolution. The Design Team invites CCAMP input to understand
the
<br>protocol-specific impacts.
<p>This seems to mix up requirements and solutions.
<br>It is not relevant what OSPF and IS-IS can or cannot do.
<p>The requirements questions are:
<br>A. What does ASON require in terms of evolution of hierarchies?</blockquote>
The requirements stated in G.7715.1 are:
<br><tt>&nbsp; "...the routing protocol shall be capable of supporting</tt>
<br><tt>&nbsp; architectural evolution in terms of number of hierarchical</tt>
<br><tt>&nbsp; levels, as well as aggregation and segmentation of RAs."</tt>
<p>This is further illustrated as being:
<br>&nbsp;- Segmentation of one Routing Area into two separate RAs
<br>&nbsp;- Aggregation of two RAs into one RA
<br>&nbsp;- Renaming of RAs
<br>&nbsp;- Insertion of an RA into the hierarchy
<br>&nbsp;- Deletion of an RA from the hierarchy
<p>Insertion and Deletion can be done at any point in the hierarchy --
it is not limited to just the top or bottom of the hierarchy.
<blockquote TYPE=CITE>B. Are these requirements immediate and high priority?</blockquote>
No statement of immediate/high priority exists in the ASON documents for
any ASON requirement.
<blockquote TYPE=CITE>Is it reasonable to make this separation between
requirements, and consequent required
<br>changes to the protocols? If so, can we focus on the requirements and
make some
<br>rapid progress?
<p>Thanks,
<br>Adrian</blockquote>
</html>


<P><hr size=1></P>
<P><STRONG>============================================================<br>The information contained in this message may be privileged <br>and confidential and protected from disclosure.  If the <br>reader of this message is not the intended recipient, or an <br>employee or agent responsible for delivering this message to <br>the intended recipient, you are hereby notified that any <br>reproduction, dissemination or distribution of this <br>communication is strictly prohibited. If you have received <br>this communication in error, please notify us immediately by <br>replying to the message and deleting it from your computer.<br><br>Thank you.<br>Tellabs<br>============================================================</STRONG></P>
</BODY>
</HTML>
--------------6E0BA8908C9D638C4DBC24EA--




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 17:40:20 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Adrian Farrel' <[e-mail]>, Stephen Shew <[e-mail]>, [e-mail]
Cc: Don Fedyk <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Wed, 17 Mar 2004 09:39:09 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40C46.C0A465E0"

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_01C40C46.C0A465E0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Adrian,
 
If you follow this through, is there a visible difference between the following cases:
 
        A)                       B)
           ------------------       ------   ------   ------
          |R1                |     |R1    | |R2    | |R3    |
          |  --    --    --  |     |  --  | |  --  | |  --  |
          | |L1|  |L2|  |L3| |     | |L1| | | |L2| | | |L3| |
          |  --    --    --  |     |  --  | |  --  | |  --  |
          |   :     :     :  |     |   :  | |   :  | |   :  |
Control    ---+-----+-----+--       ---+--   ---+--   ---+--
Plane         :     :     :            :        :        :
--------------+-----+-----+----    ----+--------+--------+----
Data          :     :     :            :        :        :
Plane        --     :    --           --        :       --
        ----|P1|--------|P3|---   ---|P1|--------------|P3|---
             -- \   :  / --           --    \   :  /    --
                 \ -- /                      \ -- /
                  |P2|                        |P2|
                   --                          --

Thanks,
 
Lyndon

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Tuesday, March 16, 2004 2:27 PM
To: Stephen Shew; Ong, Lyndon; [e-mail]
Cc: Don Fedyk; Brungard, Deborah A, ALABS; [e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture


Seems you are all a bit hung up on the definition of a "router".
 
Because GMPLS comes from a perspective where an LSR was a router was a single bearer plane device you are assuming that the identity advertised it the router id. But really the "TE router id" is the physical node id (or the logical router id - Ln in my figure).
 
Stephen has it when he says...
 
> One instantiation that is possible would be for R1 in Adrian's diagram to
> advertise on behalf of each of the P1/P2/P3 nodes, not as one abstract node.
> In that case, it would be confusing to scope the P1-P2 link using the router
> id of R1.
 
This is exactly right. And why would you scope the P1-P2 link using the router id of R1?
Why not use the node id P1 or the logical router id L1?
 
Adrian
 

> >              ------------------     ------    
> >             |R1                |   |R2    |   
> >             |  --    --    --  |   |  --  |    ------
> >             | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
> >             |  --    --    --  |   |  --  |   |  --  |
> >             |   :     :     :  |   |   :  |   | |L5| |
> > Control      ---+-----+-----+--     ---+--    |  --  |
> > Plane           :     :     :          :      |   :  |
> > ----------------+-----+-----+----------+------+---+--+-
> > Data            :     :     :          :      |   :  |
> > Plane          --     :    --         --      |  --  |
> >           ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
> >                -- \   :  / --         --      |  --  |
> >                    \ -- /                     |      |
> >                     |P2|                       ------
> >                      --
> > 
> > Pn is a physical (bearer/data/transport plane) node.
> > Rn is a control plane "router"
> > Ln is a logical control plane entity that manages a single
> >    physical node.
> > 
> > Thus:
> > R3 represents an LSR with all components collocated.
> > R2 shows how the "router" component may be disjoint from
> >    the switch
> > R1 shows how a single "router" may manage multiple switches



------_=_NextPart_001_01C40C46.C0A465E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><SPAN class=3D676332617-17032004><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
Adrian,</FONT></SPAN></DIV>
<DIV><SPAN class=3D676332617-17032004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D676332617-17032004><FONT face=3DArial =
color=3D#0000ff size=3D2>If you=20
follow this through, is there a visible difference between the =
following=20
cases:</FONT></SPAN></DIV>
<DIV><SPAN class=3D676332617-17032004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D676332617-17032004><FONT face=3DArial =
color=3D#0000ff size=3D2><FONT=20
face=3DCourier =
color=3D#000000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
A)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;B)</=
FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D676332617-17032004><FONT face=3DArial =
color=3D#0000ff size=3D2><FONT=20
face=3DCourier=20
color=3D#000000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
------------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
------&nbsp;&nbsp;=20
------&nbsp;&nbsp;=20
------<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp; |R1&nbsp;&nbsp;&nbsp; | |R2&nbsp;&nbsp;&nbsp; =
|=20
|R3&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;=20
--&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp; --&nbsp; | |&nbsp; --&nbsp; | |&nbsp; --&nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
|L1|&nbsp;=20
|L2|&nbsp; |L3| |&nbsp;&nbsp;&nbsp;&nbsp; | |L1| | | |L2| | | |L3|=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;=20
--&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp; --&nbsp; | |&nbsp; --&nbsp; | |&nbsp; --&nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; | |&nbsp;&nbsp; :&nbsp; =
|=20
|&nbsp;&nbsp; :&nbsp; |<BR>Control&nbsp;&nbsp;&nbsp;=20
---+-----+-----+--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
---+--&nbsp;&nbsp;=20
---+--&nbsp;&nbsp;=20
---+--<BR>Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:<BR>--------------+-----+-----+----&nbsp;&nbsp;&nbsp;=20
----+--------+--------+----<BR>Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:<BR>Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
----|P1|--------|P3|---&nbsp;&nbsp;=20
---|P1|--------------|P3|---<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
-- \&nbsp;&nbsp; :&nbsp; /=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp; \&nbsp;&nbsp; :&nbsp; /&nbsp;&nbsp;&nbsp;=20
--<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\ --=20
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\ --=20
/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|P2|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|P2|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
--<BR></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D676332617-17032004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D676332617-17032004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D676332617-17032004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Lyndon</DIV></FONT></SPAN>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Adrian Farrel=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, March 16, 2004 =
2:27=20
  PM<BR><B>To:</B> Stephen Shew; Ong, Lyndon;=20
  [e-mail]<BR><B>Cc:</B> Don Fedyk; Brungard, =
Deborah A,=20
  ALABS; [e-mail]<BR><B>Subject:</B> Re: ason-routing-reqts: =
issue 2=20
  architecture<BR><BR></FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Seems you are all a bit hung up on =
the=20
  definition of a "router".</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Because GMPLS comes from a =
perspective where an=20
  LSR was a router was a single bearer plane device you are assuming =
that the=20
  identity advertised it the router id. But really the "TE router id" =
is the=20
  physical node id (or the logical router id - Ln in my =
figure).</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Stephen has it when he =
says...</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; One instantiation that is =
possible would=20
  be for R1 in Adrian's diagram to<BR>&gt; advertise on behalf of each =
of the=20
  P1/P2/P3 nodes, not as one abstract node.<BR>&gt; In that case, it =
would be=20
  confusing to scope the P1-P2 link using the router<BR>&gt; id of=20
  R1.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>This is exactly right. And why =
would you scope=20
  the P1-P2 link using the router id of R1?</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Why not use the node id P1 or the =
logical=20
  router id L1?</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2><BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  ------------------&nbsp;&nbsp;&nbsp;&nbsp; ------&nbsp;&nbsp;&nbsp; =
<BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
  =
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp; |R2&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; <BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
  |&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; =
|&nbsp;&nbsp;=20
  |&nbsp; --&nbsp; |&nbsp;&nbsp;&nbsp; ------<BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; |=20
  |L1|&nbsp; |L2|&nbsp; |L3| |&nbsp;&nbsp; | |L4| |&nbsp;&nbsp;=20
  |R3&nbsp;&nbsp;&nbsp; |<BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
  |&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; =
|&nbsp;&nbsp;=20
  |&nbsp; --&nbsp; |&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
  |&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;=20
  |&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |&nbsp;&nbsp; | |L5| |<BR>&gt; =
&gt;=20
  Control&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ---+-----+-----+--&nbsp;&nbsp;&nbsp;&nbsp; ---+--&nbsp;&nbsp;&nbsp; =
|&nbsp;=20
  --&nbsp; |<BR>&gt; &gt;=20
  Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
  :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |<BR>&gt; &gt;=20
  ----------------+-----+-----+----------+------+---+--+-<BR>&gt; &gt;=20
  =
Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
  :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |<BR>&gt; &gt;=20
  Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  --&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;=20
  --&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  --&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt;=20
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ----|P1|--------|P3|-------|P4|-----+-|P5|-+-<BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
  -- \&nbsp;&nbsp; :&nbsp; / =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  --&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  \ --=20
  =
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|P2|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ------<BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  --<BR>&gt; &gt; <BR>&gt; &gt; Pn is a physical (bearer/data/transport =
plane)=20
  node.<BR>&gt; &gt; Rn is a control plane "router"<BR>&gt; &gt; Ln is =
a logical=20
  control plane entity that manages a single<BR>&gt; =
&gt;&nbsp;&nbsp;&nbsp;=20
  physical node.<BR>&gt; &gt; <BR>&gt; &gt; Thus:<BR>&gt; &gt; R3 =
represents an=20
  LSR with all components collocated.<BR>&gt; &gt; R2 shows how the =
"router"=20
  component may be disjoint from<BR>&gt; &gt;&nbsp;&nbsp;&nbsp; the=20
  switch<BR>&gt; &gt; R1 shows how a single "router" may manage =
multiple=20
  switches<BR></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C40C46.C0A465E0--



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 16:46:40 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Wed, 17 Mar 2004 11:45:31 -0500
Organization: Cisco Systems
Message-ID: <000901c40c3f$4410c840$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see my comments in-line. 

>-----Original Message-----
>From: Yakov Rekhter [mailto:[e-mail]] 
>Sent: Wednesday, March 17, 2004 11:30 AM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>> >> >> >> >> SPs don't like to see RSVP Hello running even when there 
>> >> >> >> >> is
>> >> >> >> >> no
>> >> >> >> >> application requiring them.
>> >> >> >> >
>> >> >> >> >Could you please describe scenario(s) where you would
>> >have RSVP
>> >> >> >> >Hello running "even when there is no application
>> >> >> >requiring them".
>> >> >> >> >
>> >> >> >> >Yakov.
>> >> >> >> >
>> >> >> >> 
>> >> >> >> Hi Yakov,
>> >> >> >> 
>> >> >> >> Here is a scenario:
>> >> >> >> 
>> >> >> >> 1. You start without any application that require RSVP 
>> >> >> >> Hellos.
>> >> >> >> --> You will see RSVP Hellos are NOT running.
>> >> >> >> 
>> >> >> >> 2. You enable an application (GR/ FRR) requiring 
>RSVP Hellos.
>> >> >> >> --> You will see RSVP Hellos start running.
>> >> >> >> 
>> >> >> >> So far so good :-)
>> >> >> >> 
>> >> >> >> 3. You disable application requiring RSVP Hello.
>> >> >> >> --> One would expect RSVP Hellos to stop but they keeps
>> >> >> >running :-( If
>> >> >> >> one side stops replying to RSVP Hello, it would 
>cause traffic
>> >> >> >> disruption for LSPs that depend on the health of the Hello 
>> >> >> >> session. The only way to get around this limitation is to 
>> >> >> >> continue to run Hellos.
>> >> >> >
>> >> >> >The scenario you described above seems to assume that 
>there are
>> >> >> >RSVP applications that do *not* require to run RSVP Hellos.
>> >> >> 
>> >> >> Yes. Specifically, basic RSVP signaling does NOT require use of
>> >> >> RSVP
>> >> >> Hello to detect liveness of RSVP module at the neighbor 
>> >and instead
>> >> >> uses refresh mechanics for this purpose.
>> >> >
>> >> >In principle one could use the refresh mechanism as a liveness 
>> >> >detection of the RSVP module of the control plane. However, the 
>> >> >overhead of the refresh mechanism is certainly higher than of 
>> >> >Hello. And that is why using RSVP Hellos for detecting 
>liveness of 
>> >> >RSVP module of the control plane seems to be the best available 
>> >> >today (note that "best" does not imply "the only").
>> >> 
>> >> So we are in agreement :-)
>> >
>> >So you agree that (a) RSVP Hello should be used to detect
>> >liveness of RSVP module, and (b) any use of RSVP should 
>> >include (among other
>> >things) the ability to detect liveness of the RSVP module of a 
>> >neighbor. Correct ?
>> >
>> 
>> No, unless you can please point me to a place where such use of RSVP 
>> Hello is documented. What you wanted to do can ONLY be achieved if 
>> RSVP Hello protocol is mandatory. The fact remains that RSVP Hellos 
>> are "optional" and standard RSVP (RFC2205) "IS" required to maintain 
>> state via the generation of RSVP refresh messages.
>
>And what is wrong with making RSVP Hellos mandatory, and use it as
>*the* mechanism to determing the state of the RSVP module on a 
>neighbor ?
>

Are you saying that just because RSVP control plan at the neighbor is up
means that it's in-sync, given that we don't use a reliable transport
mechanics? We still need to rely on RSVP refresh messages for
maintaining states; this is just "HOW" RSVP protocol is defined. And NOT
to mention about existing implementations and deployments. 

Thanks

Regards... Zafar

>Yakov.
>




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 16:30:43 +0000
Message-Id: <[e-mail]>
To: "zafar ali" <[e-mail]>
cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, [e-mail], "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, [e-mail], "'Reshad Rahman'" <[e-mail]>, [e-mail]
Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 17 Mar 2004 08:29:47 -0800
From: Yakov Rekhter <[e-mail]>

Zafar,

> >> >> >> >> SPs don't like to see RSVP Hello running even when there is 
> >> >> >> >> no
> >> >> >> >> application requiring them.
> >> >> >> >
> >> >> >> >Could you please describe scenario(s) where you would 
> >have RSVP
> >> >> >> >Hello running "even when there is no application
> >> >> >requiring them".
> >> >> >> >
> >> >> >> >Yakov.
> >> >> >> >
> >> >> >> 
> >> >> >> Hi Yakov,
> >> >> >> 
> >> >> >> Here is a scenario:
> >> >> >> 
> >> >> >> 1. You start without any application that require RSVP Hellos.
> >> >> >> --> You will see RSVP Hellos are NOT running.
> >> >> >> 
> >> >> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
> >> >> >> --> You will see RSVP Hellos start running.
> >> >> >> 
> >> >> >> So far so good :-)
> >> >> >> 
> >> >> >> 3. You disable application requiring RSVP Hello.
> >> >> >> --> One would expect RSVP Hellos to stop but they keeps
> >> >> >running :-( If
> >> >> >> one side stops replying to RSVP Hello, it would cause traffic 
> >> >> >> disruption for LSPs that depend on the health of the Hello 
> >> >> >> session. The only way to get around this limitation is to 
> >> >> >> continue to run Hellos.
> >> >> >
> >> >> >The scenario you described above seems to assume that there are 
> >> >> >RSVP applications that do *not* require to run RSVP Hellos.
> >> >> 
> >> >> Yes. Specifically, basic RSVP signaling does NOT require use of 
> >> >> RSVP
> >> >> Hello to detect liveness of RSVP module at the neighbor 
> >and instead 
> >> >> uses refresh mechanics for this purpose.
> >> >
> >> >In principle one could use the refresh mechanism as a liveness
> >> >detection of the RSVP module of the control plane. However, 
> >> >the overhead of the refresh mechanism is certainly higher than 
> >> >of Hello. And that is why using RSVP Hellos for detecting 
> >> >liveness of RSVP module of the control plane seems to be the 
> >> >best available today (note that "best" does not imply "the only").
> >> 
> >> So we are in agreement :-)
> >
> >So you agree that (a) RSVP Hello should be used to detect 
> >liveness of RSVP module, and (b) any use of RSVP should 
> >include (among other
> >things) the ability to detect liveness of the RSVP module of a 
> >neighbor. Correct ?
> >
> 
> No, unless you can please point me to a place where such use of RSVP
> Hello is documented. What you wanted to do can ONLY be achieved if RSVP
> Hello protocol is mandatory. The fact remains that RSVP Hellos are
> "optional" and standard RSVP (RFC2205) "IS" required to maintain state
> via the generation of RSVP refresh messages. 

And what is wrong with making RSVP Hellos mandatory, and use it as
*the* mechanism to determing the state of the RSVP module on a neighbor ?

Yakov.



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 16:25:26 +0000
From: "zafar ali" <[e-mail]>
To: "'Tomonori TAKEDA'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [RE] Layer One VPNs - sorry for the previous email
Date: Wed, 17 Mar 2004 11:24:38 -0500
Organization: Cisco Systems
Message-ID: <000801c40c3c$58eb8e60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Tomonori, 

We still need to find a way to allow more time for face-to-face
discussions in CCAMP WG meeting. My point was coming from the fact that
we have been really pressed for time during CCAMP meetings, to the
extent that we had to skip through various important discussions. Which
IMO is not the best use of a face-to-face opportunity. 

Thanks

Regards... Zafar

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Tomonori TAKEDA
>Sent: Wednesday, March 17, 2004 10:41 AM
>To: zafar ali; [e-mail]; [e-mail]
>Subject: RE: [RE] Layer One VPNs - sorry for the previous email
>
>
>Hi, Zafar,
>
>Thank you for your comments.
>
>Technically, GMPLS protocols seem to have many common pieces 
>for the L1VPN 
>as suggested by some of the voices during the CCAMP meeting.
>
>Any suggestion ?
>
>Best regards,
>
>At 17:09 04/03/15 -0500, zafar ali wrote:
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On 
>>Behalf
>>Of [e-mail]
>>Sent: Monday, March 15, 2004 3:40 AM
>>To: [e-mail]
>>Subject: [RE] Layer One VPNs - sorry for the previous email
>>Hi,
>>I think the framework document has good guidelins for 
>realizing the L1VPN 
>>in the GMPLS networks.
>>Yes, I agree the framework document is a good start.
>>
>>I'm not sure that the L1VPN service itself could be included in the 
>>CCAMP
>>charter or not, but
>>I think functional enhancements for supporting the L1VPN in 
>GMPLS should 
>>be covered in the CCAMP.
>>There were also talks about creating a new WG for it. 
>Considering current 
>>work load at CCAMP, this may be a sensible option. I hope we 
>are able to 
>>clarify on home for this work soon.
>>Thanks
>>
>>Regards... Zafar
>>
>>
>>Thanks,
>>Young
>>
>> > Hi,
>> > Although Layer One VPNs do not currently have a home in any IETF
>> working group, we were
>> > the recipients of a liaison from ITU-T SG13 informing us about the
>> work they are doing on
>> > this topic and pointing us at
>> > 
>> 
><http://www.ietf.org/internet-drafts/draft->takeda-l1vpn-framework-00.t
>> 
>xt>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00
>> .txt
>>
>> > If anyone has comments on this work they can send them to this
>> mailing list (until another
>> > home is found in the IETF) or to the authors direct. Thanks,
>> > Adrian
>
>-----
>Tomonori TAKEDA
>NTT Network Service Systems Lab.
>Phone: [phone]
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 16:12:38 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Wed, 17 Mar 2004 11:11:09 -0500
Organization: Cisco Systems
Message-ID: <000001c40c3a$77c2d430$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see my response in-line. 

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Yakov Rekhter
>Sent: Wednesday, March 17, 2004 10:15 AM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>> >> >> >> SPs don't like to see RSVP Hello running even when there is 
>> >> >> >> no
>> >> >> >> application requiring them.
>> >> >> >
>> >> >> >Could you please describe scenario(s) where you would 
>have RSVP
>> >> >> >Hello running "even when there is no application
>> >> >requiring them".
>> >> >> >
>> >> >> >Yakov.
>> >> >> >
>> >> >> 
>> >> >> Hi Yakov,
>> >> >> 
>> >> >> Here is a scenario:
>> >> >> 
>> >> >> 1. You start without any application that require RSVP Hellos.
>> >> >> --> You will see RSVP Hellos are NOT running.
>> >> >> 
>> >> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
>> >> >> --> You will see RSVP Hellos start running.
>> >> >> 
>> >> >> So far so good :-)
>> >> >> 
>> >> >> 3. You disable application requiring RSVP Hello.
>> >> >> --> One would expect RSVP Hellos to stop but they keeps
>> >> >running :-( If
>> >> >> one side stops replying to RSVP Hello, it would cause traffic 
>> >> >> disruption for LSPs that depend on the health of the Hello 
>> >> >> session. The only way to get around this limitation is to 
>> >> >> continue to run Hellos.
>> >> >
>> >> >The scenario you described above seems to assume that there are 
>> >> >RSVP applications that do *not* require to run RSVP Hellos.
>> >> 
>> >> Yes. Specifically, basic RSVP signaling does NOT require use of 
>> >> RSVP
>> >> Hello to detect liveness of RSVP module at the neighbor 
>and instead 
>> >> uses refresh mechanics for this purpose.
>> >
>> >In principle one could use the refresh mechanism as a liveness
>> >detection of the RSVP module of the control plane. However, 
>> >the overhead of the refresh mechanism is certainly higher than 
>> >of Hello. And that is why using RSVP Hellos for detecting 
>> >liveness of RSVP module of the control plane seems to be the 
>> >best available today (note that "best" does not imply "the only").
>> 
>> So we are in agreement :-)
>
>So you agree that (a) RSVP Hello should be used to detect 
>liveness of RSVP module, and (b) any use of RSVP should 
>include (among other
>things) the ability to detect liveness of the RSVP module of a 
>neighbor. Correct ?
>

No, unless you can please point me to a place where such use of RSVP
Hello is documented. What you wanted to do can ONLY be achieved if RSVP
Hello protocol is mandatory. The fact remains that RSVP Hellos are
"optional" and standard RSVP (RFC2205) "IS" required to maintain state
via the generation of RSVP refresh messages. 

Thanks

Regards... Zafar 

>Yakov.
>




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 15:43:39 +0000
Message-Id: <[e-mail]>
Date: Thu, 18 Mar 2004 00:40:57 +0900
To: "zafar ali" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Tomonori TAKEDA <[e-mail]>
Subject: RE: [RE] Layer One VPNs - sorry for the previous email
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi, Zafar,

Thank you for your comments.

Technically, GMPLS protocols seem to have many common pieces for the L1VPN 
as suggested by some of the voices during the CCAMP meeting.

Any suggestion ?

Best regards,

At 17:09 04/03/15 -0500, zafar ali wrote:
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf 
>Of [e-mail]
>Sent: Monday, March 15, 2004 3:40 AM
>To: [e-mail]
>Subject: [RE] Layer One VPNs - sorry for the previous email
>Hi,
>I think the framework document has good guidelins for realizing the L1VPN 
>in the GMPLS networks.
>Yes, I agree the framework document is a good start.
>
>I'm not sure that the L1VPN service itself could be included in the CCAMP 
>charter or not, but
>I think functional enhancements for supporting the L1VPN in GMPLS should 
>be covered in the CCAMP.
>There were also talks about creating a new WG for it. Considering current 
>work load at CCAMP, this may be a sensible option. I hope we are able to 
>clarify on home for this work soon.
>Thanks
>
>Regards... Zafar
>
>
>Thanks,
>Young
>
> > Hi,
> > Although Layer One VPNs do not currently have a home in any IETF 
> working group, we were
> > the recipients of a liaison from ITU-T SG13 informing us about the 
> work they are doing on
> > this topic and pointing us at
> > 
> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt 
>
> > If anyone has comments on this work they can send them to this 
> mailing list (until another
> > home is found in the IETF) or to the authors direct.
> > Thanks,
> > Adrian

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: [phone]





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 15:15:55 +0000
Message-Id: <[e-mail]>
To: "zafar ali" <[e-mail]>
cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, [e-mail], "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, [e-mail], "'Reshad Rahman'" <[e-mail]>, [e-mail]
Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 17 Mar 2004 07:15:04 -0800
From: Yakov Rekhter <[e-mail]>

Zafar,

> >> >> >> SPs don't like to see RSVP Hello running even when there is no 
> >> >> >> application requiring them.
> >> >> >
> >> >> >Could you please describe scenario(s) where you would have RSVP 
> >> >> >Hello running "even when there is no application
> >> >requiring them".
> >> >> >
> >> >> >Yakov.
> >> >> >
> >> >> 
> >> >> Hi Yakov,
> >> >> 
> >> >> Here is a scenario:
> >> >> 
> >> >> 1. You start without any application that require RSVP Hellos.
> >> >> --> You will see RSVP Hellos are NOT running.
> >> >> 
> >> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
> >> >> --> You will see RSVP Hellos start running.
> >> >> 
> >> >> So far so good :-)
> >> >> 
> >> >> 3. You disable application requiring RSVP Hello.
> >> >> --> One would expect RSVP Hellos to stop but they keeps
> >> >running :-( If
> >> >> one side stops replying to RSVP Hello, it would cause traffic
> >> >> disruption for LSPs that depend on the health of the Hello session. 
> >> >> The only way to get around this limitation is to continue to run 
> >> >> Hellos.
> >> >
> >> >The scenario you described above seems to assume that there
> >> >are RSVP applications that do *not* require to run RSVP 
> >> >Hellos. 
> >> 
> >> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP 
> >> Hello to detect liveness of RSVP module at the neighbor and instead 
> >> uses refresh mechanics for this purpose.
> >
> >In principle one could use the refresh mechanism as a liveness 
> >detection of the RSVP module of the control plane. However, 
> >the overhead of the refresh mechanism is certainly higher than 
> >of Hello. And that is why using RSVP Hellos for detecting 
> >liveness of RSVP module of the control plane seems to be the 
> >best available today (note that "best" does not imply "the only").
> 
> So we are in agreement :-) 

So you agree that (a) RSVP Hello should be used to detect liveness
of RSVP module, and (b) any use of RSVP should include (among other
things) the ability to detect liveness of the RSVP module of a neighbor.
Correct ?

Yakov.



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 15:11:33 +0000
Message-Id: <[e-mail]>
Date: Thu, 18 Mar 2004 00:10:31 +0900
To: [e-mail]
From: Tomonori TAKEDA <[e-mail]>
Subject: Re: [RE] Layer One VPNs - sorry for the previous email
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi, Dimitri

Thank you for your comments. Please see my comments in line.

At 18:39 04/03/15 +0100, [e-mail] wrote:
>hi tomonori, young, all,
>
>the proposed framework document (part of this discussion)
>deliversa good starting point in terms of functionality
>
>some more specific comment on this document:
>
>- it mentions an issue concerning the "shared control link" it
>may be advisable to detail more accurately the expectation in
>terms of functionality and then assess whether a shared control
>link can be used in this context, the addition to which you're
>referring seems to imply a mux/de-mux mechanism - it would be
>of great interest to see how this compares with Section 4 of
>the GVPN id

Okay, let me try to answer your comments.

For control link between the CE and the PE, I would say there are three 
categories.

1) Physically disjoint control link
2) IP-level disjoint control link (e.g., GRE tunnel)
3) IP-level shared control link

Shared control link generally refers to category 3).

 From here, I am describing more than what is described in the ID.

Category 3) is typically the case that the same CE device belongs to 
multiple VPNs (or the CE device contains multiple VPN instances), as 
described in section 6.1 of the ID. In this case, to distinguish messages 
exchanged over the control channel, some mechanisms are needed, and 
addition of VPN ID seems one way to do.

In GVPN ID, my understanding is that logical CE-PE links (or association) 
belong to each VPN. L1VPN framework ID is in line with this (as described 
in section 6.1), but this ID goes beyond and tackles the case for shared 
control channel.


>- section 4.1, performance is included as service do you mean
>this as a classification of the quality of the delivered service
>or do you mean that it is a service to allow customer to monitor
>performance of the delivered service ?

I mean the former.

To make sure, I mean that performance is one of the items that specify the 
service. (or the service defines the level of performance.)

>- there is the issue of the "PE-PE virtual links" and in case of
>"Per VPN Peer model" more details should be provided in order to
>assess whether existing GMPLS mechanisms are sufficient (from
>that perspective details about the following sentence might be
>of interest because it seems you took this as initial working
>assumption "there is currently no leakage of routing information
>across the PE to CE boundary.")

Agree. Providing more details about service requirements may be helpful ? 
Functional requirements are also important, but before going that in 
details, more clear service level requirements may be useful.

Concerning the initial working assumption you mentioned, we started from 
the most acknowledged model for the service interface, that is the UNI. 
That is why we put above text.

>- i would suggest to conclude the document with the expected
>delta requirement from gmpls perspective (this would help in
>assessing what's expected in terms of protocol for the next
>step(s))

Okay, if CCAMP is going to work on the L1 VPN, I agree delta requirement 
would be an important step.

Do you have anything in your mind ?

>- an edit concerning the section on terminology it would be
>of great help for this community to point the differences (if
>any) from the existing [TERM] document

Thanks. I would take that into the next version.

Best regards,

>thanks,
>- dimitri.

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: [phone]





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 14:27:12 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Mar 2004 15:28:39 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: WG Chair review of draft-ietf-ccamp-gmpls-g709-06.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: base64

dGhhbmtzLCBhZHJpYW4gLSB3aWxsIGNvbW1pdCBjaGFuZ2VzIGFuZCBzdWJtaXQgYSB2MDcudHh0
DQp3aGVuIGNhbGwgZW5kcy4NCg0KQWRyaWFuIEZhcnJlbCB3cm90ZToNCg0KPiBIZXJld2l0aCBh
IGJ1bmNoIG9mIG5pdHMgdG8gYmUgZml4ZWQgYWZ0ZXIgbGFzdCBjYWxsLCBwbGVhc2UuDQo+IA0K
PiBUaGFua3MsDQo+IEFkcmlhbg0KPiANCj4gDQo+PlRoaXMgZW1haWwgYmVnaW5zIGEgd29ya2lu
ZyBncm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LTA2LnR4dA0K
Pj5UaGUgbGFzdCBjYWxsIHdpbGwgZW5kIG9uIEZyaWRheSAyNnRoIE1hcmNoIGF0IDEyIG5vb24g
R01ULg0KPj4NCj4+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0
Zi1jY2FtcC1nbXBscy1nNzA5LTA2LnR4dA0KPiANCj4gDQo+IA0KPiBQcmVhbWJsZQ0KPiAgICBU
aGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1h
bmNlIHdpdGgNCj4gICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2IFsx
XS4NCj4gUmVmZXJlbmNlIFsxXSBpcyBub3QgaW4gdGhlIGNpdGF0aW9ucyBsaXN0Lg0KPiANCj4g
UGxlYXNlIHBsYWNlIHRoZSBEaXNjbGFpbWVyIGJlZm9yZSB0aGUgQWJzdHJhY3QuIFBsZWFzZSBj
aGFuZ2UNCj4gIkRpc2NsYWltZXIiIHRvICJOb3RlIG9uIElUVS1UIFJlY29tbWVuZGF0aW9uIEcu
NzA5Ig0KPiANCj4gRGlzY2xhaW1lciB0ZXh0Li4uDQo+IFJlcGxhY2UNCj4gICAgSW4gdGhpcyBk
b2N1bWVudCwgdGhlIHByZXNlbnRlZCB2aWV3cyBvbiBJVFUtVCBHLjcwOSBPVE4NCj4gICAgUmVj
b21tZW5kYXRpb24gKGFuZCByZWZlcmVuY2VkKSBhcmUgaW50ZW50aW9uYWxseSByZXN0cmljdGVk
IGFzDQo+ICAgIG5lZWRlZCBmcm9tIHRoZSBHTVBMUyBwZXJzcGVjdGl2ZSB3aXRoaW4gdGhlIElF
VEYgQ0NBTVAgV0cgY29udGV4dC4NCj4gV2l0aA0KPiAgICBUaGUgdmlld3Mgb24gdGhlIElUVS1U
IEcuNzA5IE9UTiBSZWNvbW1lbmRhdGlvbiBwcmVzZW50ZWQgaW4gdGhpcw0KPiAgICBkb2N1bWVu
dCBhcmUgaW50ZW50aW9uYWxseSByZXN0cmljdGVkIHRvIHRoZSBHTVBMUyBwZXJzcGVjdGl2ZSB3
aXRoaW4NCj4gICAgdGhlIElFVEYgQ0NBTVAgV0cgY29udGV4dC4NCj4gDQo+IFJlcGxhY2UNCj4g
VGFibGUgb2YgQ29udGVudA0KPiB3aXRoDQo+IFRhYmxlIG9mIENvbnRlbnRzDQo+IA0KPiBSZXBs
YWNlDQo+ICAgIFRhYmxlIG9mIENvbnRlbnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uIDINCj4gd2l0aA0KPiAgICBUYWJsZSBvZiBDb250ZW50cyAuLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAyDQo+IA0KPiBTZWN0
aW9uIDINCj4gICAgVGhlIE9DaA0KPiAgICBvdmVyaGVhZCBpcyB0cmFuc3BvcnRlZCBpbiBhIG5v
bi1hc3NvY2lhdGVkIG1hbm5lciAoc28gYWxzbyByZWZlcnJlZA0KPiAgICB0byBhcyB0aGUgbm9u
LWFzc29jaWF0ZWQgb3ZlcmhlYWQg+yBuYU9IKQ0KPiBSZWFkDQo+ICAgIFRoZSBPQ2gNCj4gICAg
b3ZlcmhlYWQgaXMgdHJhbnNwb3J0ZWQgaW4gYSBub24tYXNzb2NpYXRlZCBtYW5uZXIgKGFsc28g
cmVmZXJyZWQNCj4gICAgdG8gYXMgdGhlIG5vbi1hc3NvY2lhdGVkIG92ZXJoZWFkIG5hT0gpDQo+
IA0KPiBTZWN0aW9uIDINCj4gICAgVGhlcmVmb3JlLCBhZGFwdGluZyBHTVBMUyB0byBjb250cm9s
IEcuNzA5IE9UTiwgY2FuIGJlIGFjaGlldmVkIGJ5DQo+ICAgIGNvbnNpZGVyaW5nIHRoYXQ6DQo+
IFJlYWQNCj4gICAgQWRhcHRpbmcgR01QTFMgdG8gY29udHJvbCBHLjcwOSBPVE4sIGNhbiBiZSBh
Y2hpZXZlZCBieSBjcmVhdGluZzoNCj4gDQo+IFNlY3Rpb24gMg0KPiAgICBNb3Jlb3Zlciwgc2lu
Y2UgdGhlIG11bHRpcGxleGluZyBpbiB0aGUgZGlnaXRhbCBkb21haW4NCj4gUmVhZA0KPiAgICBN
b3Jlb3Zlciwgc2luY2UgbXVsdGlwbGV4aW5nIGluIHRoZSBkaWdpdGFsIGRvbWFpbg0KPiANCj4g
U2VjdGlvbiAyDQo+ICAgIE5vdGljZSBhbHNvIHRoYXQgb25lIGRpcmVjdGx5IHVzZXMgdGhlIEcu
NzA5IE9EVWsgKGkuZS4NCj4gICAgRGlnaXRhbCBQYXRoKSBhbmQgT0NoIChpLmUuIE9wdGljYWwg
UGF0aCkgbGF5ZXJzIGluIG9yZGVyIHRvIGRlZmluZQ0KPiAgICB0aGUgY29ycmVzcG9uZGluZyBs
YWJlbCBzcGFjZXMuDQo+IFJlYWQNCj4gICAgTm90aWNlIGFsc28gdGhhdCBvbmUgdXNlcyB0aGUg
Ry43MDkgT0RVayAoaS5lLiBEaWdpdGFsIFBhdGgpIGFuZA0KPiAgICBPQ2ggKGkuZS4gT3B0aWNh
bCBQYXRoKSBsYXllcnMgZGlyZWN0bHkgaW4gb3JkZXIgdG8gZGVmaW5lIHRoZQ0KPiAgICBjb3Jy
ZXNwb25kaW5nIGxhYmVsIHNwYWNlcy4NCj4gDQo+IFNlY3Rpb24gMw0KPiAgICBJbiB0aGlzIHNl
Y3Rpb24sIGJvdGggcGFydHMgYXJlIGV4dGVuZGVkIHRvDQo+ICAgIGFjY29tbW9kYXRlIHRoZSBH
TVBMUyBTaWduYWxsaW5nIHRvIHRoZSBHLjcwOSB0cmFuc3BvcnQgcGxhbmUNCj4gICAgcmVjb21t
ZW5kYXRpb24gKHNlZSBbSVRVVC1HNzA5XSkuDQo+IFJlYWQNCj4gICAgSW4gdGhpcyBzZWN0aW9u
LCBib3RoIHBhcnRzIGFyZSBleHRlbmRlZCB0bw0KPiAgICBhY2NvbW1vZGF0ZSBHTVBMUyBTaWdu
YWxsaW5nIHRvIHRoZSBHLjcwOSB0cmFuc3BvcnQgcGxhbmUNCj4gICAgcmVjb21tZW5kYXRpb24g
KHNlZSBbSVRVVC1HNzA5XSkuDQo+IA0KPiBTZWN0aW9uIDMuMQ0KPiAgICBBcyBtZW50aW9uZWQg
aGVyZSBhYm92ZSwgdGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBMU1AgRW5jb2RpbmcNCj4gUmVh
ZA0KPiAgICBBcyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgZG9jdW1lbnQgZXh0ZW5kcyB0aGUgTFNQ
IEVuY29kaW5nDQo+IA0KPiBTZWN0aW9uIDMuMS4xDQo+ICAgIFRoZXJlZm9yZSwgdGhlIGN1cnJl
bnQgIkRpZ2l0YWwgV3JhcHBlciIgY29kZS1wb2ludCBkZWZpbmVkIGluDQo+ICAgIFtSRkMzNDcx
XSBjYW4gYmUgcmVwbGFjZWQgYnkgdHdvIHNlcGFyYXRlZCBjb2RlLXBvaW50czoNCj4gUmVhZA0K
PiAgICBUaGVyZWZvcmUsIHRoZSBjdXJyZW50ICJEaWdpdGFsIFdyYXBwZXIiIGNvZGUtcG9pbnQg
ZGVmaW5lZCBpbg0KPiAgICBbUkZDMzQ3MV0gY2FuIGJlIHJlcGxhY2VkIGJ5IHR3byBzZXBhcmF0
ZSBjb2RlLXBvaW50czoNCj4gDQo+IFNlY3Rpb24gMy4xLjENCj4gICAgSW4gdGhlIHNhbWUgd2F5
LCB0d28gc2VwYXJhdGVkIGNvZGUtcG9pbnRzIGNhbiByZXBsYWNlIHRoZSBjdXJyZW50DQo+ICAg
IGRlZmluZWQgIkxhbWJkYSIgY29kZS1wb2ludDoNCj4gUmVhZA0KPiAgICBJbiB0aGUgc2FtZSB3
YXksIHR3byBzZXBhcmF0ZSBjb2RlLXBvaW50cyBjYW4gcmVwbGFjZSB0aGUgY3VycmVudA0KPiAg
ICBkZWZpbmVkICJMYW1iZGEiIGNvZGUtcG9pbnQ6DQo+IA0KPiBTZWN0aW9uIDMuMS4zDQo+ICAg
IE5vdGU6IFZhbHVlIDQ5IGFuZCA1MCBpbmNsdWRlcyBtYXBwaW5nIG9mIFNESA0KPiBSZWFkDQo+
ICAgIE5vdGU6IFZhbHVlcyA0OSBhbmQgNTAgaW5jbHVkZSBtYXBwaW5nIG9mIFNESC4NCj4gDQo+
IDMuMi4xIFNpZ25hbCBUeXBlIChTVCkNCj4gQ2FuIEkgYXNzdW1lIHRoYXQgdGhlIGNob2ljZSBv
ZiB2YWx1ZXMgaGVyZSBpcyBpbnRlbmRlZCB0byBtYXRjaCBhIGxpc3QNCj4gb2YgdmFsdWVzIGRl
ZmluZWQgc29tZXdoZXJlIGVsc2U/IEEgbm90ZSB0byB0aGF0IGVmZmVjdCB3b3VsZCBiZQ0KPiBo
ZWxwZnVsLiAoSWYgbm90LCB3aHkgZG8geW91IGhhdmUgZ2Fwcz8pLg0KPiANCj4gU2VjdGlvbiAz
LjIuMw0KPiAgICBOb3RlIHRoYXQgdGhlIGN1cnJlbnQgdXNhZ2Ugb2YgdGhpcyBmaWVsZCBvbmx5
IGFwcGxpZXMgZm9yIEcuNzA5DQo+ICAgIE9EVWsgTFNQIGkuZS4gdmFsdWVzIGdyZWF0ZXIgdGhh
biB6ZXJvLCBhcmUgb25seSBhY2NlcHRhYmxlIGZvciBPRFVrDQo+IFJlYWQNCj4gICAgTm90ZSB0
aGF0IHRoZSBjdXJyZW50IHVzYWdlIG9mIHRoaXMgZmllbGQgb25seSBhcHBsaWVzIGZvciBHLjcw
OQ0KPiAgICBPRFVrIExTUHMgaS5lLiB2YWx1ZXMgZ3JlYXRlciB0aGFuIHplcm8sIGFyZSBvbmx5
IGFjY2VwdGFibGUgZm9yIE9EVWsNCj4gDQo+IFNlY3Rpb24gMy4yLjMNCj4gICAgVGhlcmVmb3Jl
LCBpdCBNVVNUIGJlIHNldCB0byB6ZXJvIChOVkMgPSAwKSB3aGVuDQo+ICAgIHJlcXVlc3Rpbmcg
YSBHLjcwOSBPQ2ggTFNQIGFuZCBzaG91bGQgYmUgaWdub3JlZCB3aGVuIHJlY2VpdmVkLg0KPiBS
ZWFkDQo+ICAgIFRoZXJlZm9yZSwgaXQgTVVTVCBiZSBzZXQgdG8gemVybyAoTlZDID0gMCksIGFu
ZCBzaG91bGQgYmUgaWdub3JlZA0KPiAgICB3aGVuIHJlY2VpdmVkLCB3aGVuIGEgRy43MDkgT0No
IExTUCBpcyByZXF1ZXN0ZWQuDQo+IA0KPiBTZWN0aW9uIDMuMi41DQo+ICAgIFRoZSByZXNlcnZl
ZCBmaWVsZHMgKDggYml0cyBpbiByb3cgMSBhbmQgMzIgYml0cyBmaWVsZHMgaW4gcm93IDMpDQo+
IFJlYWQNCj4gICAgVGhlIHJlc2VydmVkIGZpZWxkcyAoOCBiaXRzIGluIHJvdyAxIGFuZCAzMiBi
aXRzIGluIHJvdyAzKQ0KPiANCj4gU2VjdGlvbiA0LjENCj4gICAgICAgICAtIHQyPTEgaW5kaWNh
dGVzIGEgbm90IGZ1cnRoZXIgc3ViLWRpdmlkZWQgT0RVMiBzaWduYWwuDQo+IFJlYWQNCj4gICAg
ICAgICAtIHQyPTEgaW5kaWNhdGVzIGFuIE9EVTIgc2lnbmFsIHRoYXQgaXMgbm90IGZ1cnRoZXIg
c3ViLWRpdmlkZWQuDQo+IA0KPiBTZWN0aW9uIDQuMQ0KPiAgICAgICAgIC0gdDM9MSBpbmRpY2F0
ZXMgYSBub3QgZnVydGhlciBzdWItZGl2aWRlZCBPRFUzIHNpZ25hbC4NCj4gUmVhZA0KPiAgICAg
ICAgIC0gdDM9MSBpbmRpY2F0ZXMgYW4gT0RVMyBzaWduYWwgdGhhdCBpcyBub3QgZnVydGhlciBz
dWItZGl2aWRlZC4NCj4gDQo+IFNlY3Rpb24gNC4yDQo+ICAgIE5vdGU6IGFzIGRlZmluZWQgaW4g
W1JGQzM0NzFdLCBsYWJlbCBmaWVsZCB2YWx1ZXMgb25seSBoYXZlDQo+ICAgIHNpZ25pZmljYW5j
ZSBiZXR3ZWVuIHR3byBuZWlnaGJvcnMsIGFuZCB0aGUgcmVjZWl2ZXIgbWF5IG5lZWQgKGluDQo+
ICAgIHNvbWUgcGFydGljdWxhciBjYXNlcykgdG8gY29udmVydCB0aGUgcmVjZWl2ZWQgdmFsdWUg
aW50byBhIHZhbHVlDQo+ICAgIHRoYXQgaGFzIGxvY2FsIHNpZ25pZmljYW5jZS4NCj4gSSBhbSBu
b3QgY2xlYXIgYWJvdXQgdGhpcyB0ZXh0LiBZb3UgaGF2ZSB2ZXJ5IHByZWNpc2VseSBkZWZpbmVk
IHRoZQ0KPiBtZWFuaW5nIG9mIHRoZSBsYWJlbCBmaWVsZCB2YWx1ZXMuIElmIHRoaXMgbm90ZSBp
cyB0cnVlLCB0aGUgd2hvbGUgb2YNCj4gc2VjdGlvbiA0LjEgc2VlbXMgdG8gYmUgd2FzdGVkLg0K
PiANCj4gU2VjdGlvbiA0LjINCj4gV2h5IGlzIHRoaXMgc2VjdGlvbiBwbGFjZWQgYmV0d2VlbiB0
aGUgdHdvIHNlY3Rpb25zICg0LjEgYW5kIDQuMykgdGhhdA0KPiBkZWZpbmUgdGhlIGxhYmVsIHNw
YWNlcz8NCj4gDQo+IFNlY3Rpb24gOA0KPiAgICBUaHJlZSB2YWx1ZXMgaGF2ZSB0byBiZSBkZWZp
bmVkIGJ5IElBTkEgZm9yIHRoaXMgZG9jdW1lbnQ6DQo+IFdoYXQgaXMgdGhlIHRoaXJkIHZhbHVl
Pw0KPiANCj4gU2VjdGlvbiA4IElBTkEgY29uc2lkZXJhdGlvbnMNCj4gSXQgd291bGQgYmUgaGVs
cGZ1bCBpZiB5b3UgcmVxdWVzdGVkIElBTkEgdG8gdHJhY2sgdGhlIGNvZGVwb2ludCBzcGFjZXMN
Cj4gdGhhdCB5b3UgYXJlIGV4dGVuZGluZyBhbmQgdXBkYXRpbmcuIFRoYXQgaXM6DQo+IC0gTFNQ
IEVuY29kaW5nIFR5cGVzDQo+IC0gR2VuZXJhbGl6ZWQgUElEDQo+IA0KPiBQbGVhc2UgdXNlIG5l
dyBJUFIgYm9pbGVycGxhdGUuDQo+IA0KPiBQbGVhc2UgbWFrZSBub24tSUVURiBkb2N1bWVudHMg
KGkuZS4gSVRVLVQgZG9jdW1lbnRzIGluZm9ybWF0aW9uYWwsIG5vdA0KPiBub3JtYXRpdmUpDQo+
IA0KPiBbUkZDMzQ3M10gaXMgc29tZXRpbWVzIHJlZmVyZW5jZWQgYXMgW0dNUExTLVNJR10NCj4g
DQo+IFtHTVBMUy1BUkNIXSBpcyBub3QgcmVmZXJlbmNlZC4gUGxlYXNlIG1vdmUgaXQgdG8gSW5m
b3JtYXRpb25hbC4NCj4gDQo+IFNvbWUgY29udHJpYnV0b3JzJyBhZGRyZXNzZXMgYW5kIGNvbnRh
Y3QgZGV0YWlscyBhcmUgb3V0IG9mIGRhdGUuDQo+IA0KPiAxMy4gQXV0aG9yJ3MgQWRkcmVzcw0K
PiBzaG91bGQgcmVhZA0KPiAxMy4gRWRpdG9yJ3MgQWRkcmVzcw0KPiANCj4gQXBwZW5kaXggMg0K
PiAgICAtIEluZGV4IG06IFRoZSBpbmRleCAibSIgaXMgdXNlZCB0byByZXByZXNlbnQgdGhlIGJp
dCByYXRlIG9yIHNldCBvZg0KPiAgICBiaXQgcmF0ZXMgc3VwcG9ydGVkIG9uIHRoZSBpbnRlcmZh
Y2UuIFRoaXMgaXMgYSBvbmUgb3IgbW9yZSBkaWdpdA0KPiAgICD0a/YsIHdoZXJlIGVhY2gg9Gv2
IHJlcHJlc2VudHMgYSBwYXJ0aWN1bGFyIGJpdCByYXRlLiBUaGUgdmFsaWQNCj4gICAgdmFsdWVz
IGZvciBtIGFyZSAoMSwgMiwgMywgMTIsIDIzLCAxMjMpLg0KPiBHb3R0YSBsb3ZlIHRob3NlIGZ1
bmt5IGNoYXJhY3RlcnMhDQo+IA0KPiBQbGVhc2UgdXNlIHRoZSBuZXcgY29weXJpZ2h0IGJvaWxl
cnBsYXRlDQo+IA0KPiBQbGVhc2UgZmlsbCBpbiBjb3B5cmlnaHQgZGF0ZS4NCj4gDQo+IA0KDQot
LSANClBhcGFkaW1pdHJpb3UgRGltaXRyaQ0KRS1tYWlsIDogZGltaXRyaS5wYXBhZGltaXRyaW91
QGFsY2F0ZWwuYmUNCkUtbWFpbCA6IGRwYXBhZGltaXRyaW91QHBzZy5jb20NCldlYnBhZ2U6IGh0
dHA6Ly9wc2cuY29tL35kcGFwYWRpbWl0cmlvdS8NCkFkZHJlc3M6IEZyLiBXZWxsZXNwbGVpbiAx
LCBCLTIwMTggQW50d2VycGVuLCBCZWxnaXVtDQpQaG9uZSAgOiArMzIgMyAyNDAtODQ5MQ0KDQo=



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 14:19:18 +0000
Message-ID: <0d9c01c40c2a$af08dd50$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Dimitri Papadimitriou" <[e-mail]>
Subject: WG Chair review of draft-ietf-ccamp-gmpls-g709-06.txt
Date: Wed, 17 Mar 2004 14:16:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Herewith a bunch of nits to be fixed after last call, please.

Thanks,
Adrian

> This email begins a working group last call on draft-ietf-ccamp-gmpls-g709-06.txt
> The last call will end on Friday 26th March at 12 noon GMT.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-06.txt


Preamble
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].
Reference [1] is not in the citations list.

Please place the Disclaimer before the Abstract. Please change
"Disclaimer" to "Note on ITU-T Recommendation G.709"

Disclaimer text...
Replace
   In this document, the presented views on ITU-T G.709 OTN
   Recommendation (and referenced) are intentionally restricted as
   needed from the GMPLS perspective within the IETF CCAMP WG context.
With
   The views on the ITU-T G.709 OTN Recommendation presented in this
   document are intentionally restricted to the GMPLS perspective within
   the IETF CCAMP WG context.

Replace
Table of Content
with
Table of Contents

Replace
   Table of Content ................................................ 2
with
   Table of Contents ............................................... 2

Section 2
   The OCh
   overhead is transported in a non-associated manner (so also referred
   to as the non-associated overhead û naOH)
Read
   The OCh
   overhead is transported in a non-associated manner (also referred
   to as the non-associated overhead naOH)

Section 2
   Therefore, adapting GMPLS to control G.709 OTN, can be achieved by
   considering that:
Read
   Adapting GMPLS to control G.709 OTN, can be achieved by creating:

Section 2
   Moreover, since the multiplexing in the digital domain
Read
   Moreover, since multiplexing in the digital domain

Section 2
   Notice also that one directly uses the G.709 ODUk (i.e.
   Digital Path) and OCh (i.e. Optical Path) layers in order to define
   the corresponding label spaces.
Read
   Notice also that one uses the G.709 ODUk (i.e. Digital Path) and
   OCh (i.e. Optical Path) layers directly in order to define the
   corresponding label spaces.

Section 3
   In this section, both parts are extended to
   accommodate the GMPLS Signalling to the G.709 transport plane
   recommendation (see [ITUT-G709]).
Read
   In this section, both parts are extended to
   accommodate GMPLS Signalling to the G.709 transport plane
   recommendation (see [ITUT-G709]).

Section 3.1
   As mentioned here above, this document extends the LSP Encoding
Read
   As mentioned above, this document extends the LSP Encoding

Section 3.1.1
   Therefore, the current "Digital Wrapper" code-point defined in
   [RFC3471] can be replaced by two separated code-points:
Read
   Therefore, the current "Digital Wrapper" code-point defined in
   [RFC3471] can be replaced by two separate code-points:

Section 3.1.1
   In the same way, two separated code-points can replace the current
   defined "Lambda" code-point:
Read
   In the same way, two separate code-points can replace the current
   defined "Lambda" code-point:

Section 3.1.3
   Note: Value 49 and 50 includes mapping of SDH
Read
   Note: Values 49 and 50 include mapping of SDH.

3.2.1 Signal Type (ST)
Can I assume that the choice of values here is intended to match a list
of values defined somewhere else? A note to that effect would be
helpful. (If not, why do you have gaps?).

Section 3.2.3
   Note that the current usage of this field only applies for G.709
   ODUk LSP i.e. values greater than zero, are only acceptable for ODUk
Read
   Note that the current usage of this field only applies for G.709
   ODUk LSPs i.e. values greater than zero, are only acceptable for ODUk

Section 3.2.3
   Therefore, it MUST be set to zero (NVC = 0) when
   requesting a G.709 OCh LSP and should be ignored when received.
Read
   Therefore, it MUST be set to zero (NVC = 0), and should be ignored
   when received, when a G.709 OCh LSP is requested.

Section 3.2.5
   The reserved fields (8 bits in row 1 and 32 bits fields in row 3)
Read
   The reserved fields (8 bits in row 1 and 32 bits in row 3)

Section 4.1
        - t2=1 indicates a not further sub-divided ODU2 signal.
Read
        - t2=1 indicates an ODU2 signal that is not further sub-divided.

Section 4.1
        - t3=1 indicates a not further sub-divided ODU3 signal.
Read
        - t3=1 indicates an ODU3 signal that is not further sub-divided.

Section 4.2
   Note: as defined in [RFC3471], label field values only have
   significance between two neighbors, and the receiver may need (in
   some particular cases) to convert the received value into a value
   that has local significance.
I am not clear about this text. You have very precisely defined the
meaning of the label field values. If this note is true, the whole of
section 4.1 seems to be wasted.

Section 4.2
Why is this section placed between the two sections (4.1 and 4.3) that
define the label spaces?

Section 8
   Three values have to be defined by IANA for this document:
What is the third value?

Section 8 IANA considerations
It would be helpful if you requested IANA to track the codepoint spaces
that you are extending and updating. That is:
- LSP Encoding Types
- Generalized PID

Please use new IPR boilerplate.

Please make non-IETF documents (i.e. ITU-T documents informational, not
normative)

[RFC3473] is sometimes referenced as [GMPLS-SIG]

[GMPLS-ARCH] is not referenced. Please move it to Informational.

Some contributors' addresses and contact details are out of date.

13. Author's Address
should read
13. Editor's Address

Appendix 2
   - Index m: The index "m" is used to represent the bit rate or set of
   bit rates supported on the interface. This is a one or more digit
   ôkö, where each ôkö represents a particular bit rate. The valid
   values for m are (1, 2, 3, 12, 23, 123).
Gotta love those funky characters!

Please use the new copyright boilerplate

Please fill in copyright date.





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 11:09:25 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Mar 2004 12:09:00 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Don Fedyk <[e-mail]>
Cc: "Ong, Lyndon" <[e-mail]>, Adrian Farrel <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

don,

> So Adrian took us back to requirements. But I think we agree there are at
> least 2 ways to do it and both may be required in the end.

(1) that's fine, we reached the first discussion point which is how 
local representation of such construct can be done and achieved, it 
clearly shows there are several ways (btw, i assume here that we agreed 
on the "external" link representation)

(2) the second point of discussion is how much of this information is 
really needed externally (ie the common set of information) and a common 
semantic to what it represents to make the control plane working in a 
standardized and interoperable way (note: point (1) discussion showed 
that what's internal will be more elaborated than what is externally 
known and this in any case)

-> it seems that the following responds to the question: "A collection 
of links and nodes such as a subnetwork or RA must be able to represent 
itself to the wider network as a single logical entity with only its 
external links visible to the topology database.)" can we agree on this one

(3) and then, but i don't think we will be capable to enter into that 
discussion for the time being since back to the functional requirements:
- (3a) what's needed to represent this information in the routing
   protocol
- (3b) and what's needed as routing mechanism to exchange this
   information

thanks,
- dimitri.
> Don 
> 
> <snip>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 04:09:22 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: [e-mail]
Cc: "Ong, Lyndon" <[e-mail]>, Adrian Farrel <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 23:08:21 -0500

Hi Dmitri

I had to leave and then I answered some of this already so I'll be brief. 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 
> Sent: Tuesday, March 16, 2004 3:14 PM
> 
> 
> don,
> 
> > If you are saying the real or logical node id that is 
> associated with 
> > the Data (bearer) plane should be unique? I would say yes.
> 
> see below
> 
> > If you are saying could it be IP address format? I would say yes. 
> > (Note the link identifiers in IP address format are unique 
> only with 
> > respect to the node id).
> 
> see below
> 
> > But if you say Should it then follow each piece of equipment has 
> > knowledge of this IP address format that is assigned to it? I would 
> > say no because there is equipment that won't have this for 
> some time. (A requirement I
> > understand from ASON).   
> 
> i'll restate, because i think the issue is, can a CP entity 
> be assigned an IP address from which all links could be 
> addressed independently of their physical distribution 
> (single data plane entity or multiple data plane entity)

That depends on what you want to do with the information. What is the scope?
To identify links. Sure <IP, id>. That is unique. The question comes down to
are you representing a distributed node or a set of nodes that cannot speak
the right flavor of routing so they require a proxy. This is a valid
requirement for legacy equipment. 

> 
> > So what I believe you are left with is some bearer 
> equipment which has 
> > TE resources (a node Identifier (non-IP) and link identifiers 
> > (non-IP)). This equipment is known by its native identifiers to the 
> > entity in the control plane which can assign: IP format 
> identifiers to 
> > the equipment (through some
> > means) and an unique node identifier. This can then be 
> advertised on its
> > behalf as a GMPLS compatible TE LSA. 
> 
> again here, if the concatenation <IP address, id> allows to 
> uniquely identify all the "logical node end-points" at the 
> control plane level then independently of the native data 
> plane address space value, we're fine (there is no need to 
> duplicate the identifier of the owner of this space)
> 
> > This does create some challenges but in reality I think 
> many devices 
> > are known by more than one name. (Look at VoIP, devices they have 2 
> > identifiers E.164 and IP. I personally never use my IP 
> address to make 
> > a VoIP phone call but I know that it is routed to a IP 
> address along 
> > the way that is hidden from me.)
> > 
> > I tend to agree with Lyndon that Topology is derived from TE 
> > advertisements. I don't understand what you could do 
> without a unique 
> > logical node associated with the TE links.
> 
> i don't think the issue is on feasibility (both are here 
> feasible and works) it is to assess whether at the control 
> plane level an additional level of indirection is *required* 
> to identify the DP resources or not - and it just a practice 
> issue, does the user community assign an IP address to each 
> of their node and then on top another for the log. construct 
> that they can map to the router address or do they assign an 
> address for the logical construct and then number each of the 
> endpoints, it may even be that both are required, you will 
> also see that in each case the response to your 1st question 
> is yes and the second one as well
> 
> note: i'm not saying also that it is the only issue here, but 
> we have to start from somewhere in order to solve this

So Adrian took us back to requirements. But I think we agree there are at
least 2 ways to do it and both may be required in the end.

Don 

<snip>



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 03:57:28 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail], "Ong, Lyndon" <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 22:56:03 -0500

Hi Deborah

> -----Original Message-----
> From: Brungard, Deborah A, ALABS [mailto:[e-mail]] 
> Sent: Tuesday, March 16, 2004 5:11 PM
> 
> Hi Don,
> 
> The different terminology used in ITU/IETF may be what is 
> causing confusion. This issue is not on how a control plane 
> entity identifies it's own associated data plane resources. 
> The question is what does a control plane entity (via I-NNI, 
> E-NNI, UNI) "need to know" (to identify) of another control 
> plane entity's resources? Here the example is on the "need to 
> know" if multiple physical nodes are supported, others have 
> suggested identifying physical locations, bays, individual 
> circuit packs.

I think I answered that in Adrian's requirements question. And I'm confused
on terminology. 
> 
> A key ASON requirement has been for the control plane to 
> provide a logical abstraction of the physical resources (e.g. 
> to "hide" internal physical implementations of a carrier, to 
> support scalability, etc). If choose to use physical node ids 
> for TEs, then this will always be the overriding constraint. 
> Example, what if I want to bundle some resources of one node 
> with another node for TE advertisement? We've had this 
> limitation with management plane addressing, and only with 
> the newer management models (Corba) are getting past it. 
> Let's not go backwards.
O.K. I did not answer that part and I think the discussion will go on. The
requirements I put on NodeIds were simply to resolve Endpoints within and
area. I'm not a big fan of exporting real routing information out of the
area but if it is performed I would assume some form of abstraction would
take place that would present virtual nodeIds and links in the area. 

> 
> Looking at the email activity, I see Adrian is also seeing 
> this confusion, and has provided an example clarifying if we 
> are discussing internal interfaces/GSMP or routing interfaces.
> 
> Deborah
> 
Its a valid question. My belief is that in the spirit of RFC3630 what makes
a link a link and what makes a node a node is what is in question. Just
reusing the existing structure give me "links in space" when an entity does
the control plane for several objects. I know Dmitri was getting at this. My
instinct is telling me that if an entity in the control plane is routable
and logically could have GMPLS routing on it some day but does it by proxy
by some controller then it should have a node id. But if an entity is some
subset of a larger switch entity then it should perhaps be controlled by
GSMP and represented a single node.  The question comes down to do you
represent a set of entities a distributed switch or a set of nodes. 

Don   

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Don Fedyk
> Sent: Tuesday, March 16, 2004 2:35 PM
> To: [e-mail]; Ong, Lyndon
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> Subject: RE: ason-routing-reqts: issue 2 architecture
> 
> 
> Dimitri
> 
> If you are saying the real or logical node id that is 
> associated with the Data (bearer) plane should be unique? I 
> would say yes. 
> 
> If you are saying could it be IP address format? I would say 
> yes. (Note the link identifiers in IP address format are 
> unique only with respect to the node id).
> 
> But if you say Should it then follow each piece of equipment 
> has knowledge of this IP address format that is assigned to 
> it? I would say no because there is equipment that won't have 
> this for some time. (A requirement I
> understand from ASON).   
> 
> So what I believe you are left with is some bearer equipment 
> which has TE resources (a node Identifier (non-IP) and link 
> identifiers (non-IP)). This equipment is known by its native 
> identifiers to the entity in the control plane which can 
> assign: IP format identifiers to the equipment (through some
> means) and an unique node identifier. This can then be 
> advertised on its behalf as a GMPLS compatible TE LSA. 
> 
> This does create some challenges but in reality I think many 
> devices are known by more than one name. (Look at VoIP, 
> devices they have 2 identifiers E.164 and IP. I personally 
> never use my IP address to make a VoIP phone call but I know 
> that it is routed to a IP address along the way that is 
> hidden from me.)
> 
> I tend to agree with Lyndon that Topology is derived from TE 
> advertisements. I don't understand what you could do without 
> a unique logical node associated with the TE links. 
> 
> Don 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] 
> > Sent: Tuesday, March 16, 2004 1:48 PM
> > To: Ong, Lyndon
> > Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, 
> > Deborah A, ALABS; [e-mail]
> > Subject: Re: ason-routing-reqts: issue 2 architecture
> > 
> > 
> > the problem is not an issue of being cleaner, the issue
> > is once the following assumption is taken (which is the logical 
> > consequence of rfc 3630 in the gmpls context)
> > 
> > "a stable IP address of the control plane entity that
> > manages the resources on behalf of the data plane
> > entity whose resources are being advertised."
> > 
> > can we assume that wrt to this stable IP address the
> > resource identification will be unique (throughout
> > these multiple data plane entities) and in this case
> > it holds (no additional level of indirection needed),
> > or not (i.e. you will find duplicated id space values
> > and then an additional level of indirection is needed)
> > 
> > the problem of the design team was not define the issue
> > but to find enough arguments wrt to the operational
> > practices (ie user community) in order to close this
> > 
> > thanks,
> > - dimitri.
> > 
> > Ong, Lyndon wrote:
> > > I had the same assumption as Don, that the RFC treats the
> > advertising
> > > router and the bearer plane node as the same. It would be
> > cleaner if
> > > there was also a bearer plane node identifier in the 
> advertisement.
> > > 
> > > Cheers,
> > > 
> > > Lyndon
> > > 
> > > -----Original Message-----
> > > From: Don Fedyk [mailto:[e-mail]]
> > > Sent: Tuesday, March 16, 2004 9:56 AM
> > > To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> > > Subject: RE: ason-routing-reqts: issue 2 architecture
> > > 
> > > 
> > > Hi Adrian
> > > 
> > > See Comments Below,
> > > 
> > > 
> > >>-----Original Message-----
> > >>From: Adrian Farrel [mailto:[e-mail]]
> > >>Sent: Monday, March 15, 2004 4:18 PM
> > >>To: Brungard, Deborah A, ALABS; [e-mail]
> > >>Subject: Re: ason-routing-reqts: issue 2 architecture
> > >>
> > >>
> > >>I assume that the desire is to have one control plane 
> entity mange 
> > >>multiple data plane entities (not to have one data plane entity 
> > >>managed by multiple control plane entities).
> > > 
> > > 
> > > I agree.
> > > 
> > >>I believe. in this context, it might be helpful to separate the 
> > >>signaling function (and the associated routing function for the 
> > >>delivery of the signaling messages) from the TE advertisement 
> > >>routing function. Since we are discussing the routing 
> requirements 
> > >>(this is the routing DT) can I assume that the discussion 
> is limited 
> > >>to the TE advertisement routing function, with the aim to 
> have one 
> > >>control plane entity advertise the resources on behalf of 
> multiple 
> > >>data plane entities.
> > >>
> > >>If all of the above, why could you not simply do this 
> using RFC3630? 
> > >>The only wrinkle might be that the Router Address TLV is 
> described 
> > >>as carrying "a stable IP address of the advertising router". 
> > >>Clearly, this needs to be interpreted as "a stable IP 
> address of the 
> > >>control plane entity that manages the resources on behalf of the 
> > >>data plane entity whose resources are being advertised."
> > > 
> > > 
> > > Interesting. I thought that you need a logical node id for
> > the bearer
> > > plane as well even though you are only advertising from a single
> > > entity.  In other words, is it not the desire to have the TE 
> > > advertisements contain the same information regardless of whether 
> > > there is a one to one correspondence between the nodes in 
> > control and
> > > the data plane or there is a one to many relationship? My
> > > interpretation of RFC3630 is that it assumes the 
> > advertising router is
> > > the same as the logical node in the bearer plane that owns the
> > > resources. If a logical node id was added to the 
> > advertisement for the
> > > node terminating the resources when the advertising router
> > was not the
> > > bearer node that owned the resources it would be clearer to me.
> > > 
> > > Don
> > > 
> > > 
> > > 
> > >>Am I missing something?
> > >>
> > >>Adrian
> > >>
> > >>----- Original Message -----
> > >>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> > >>To: <[e-mail]>
> > >>Sent: Monday, March 15, 2004 7:43 PM
> > >>Subject: ason-routing-reqts: issue 2 architecture
> > >>
> > >>
> > > 
> > > 
> > ftp://ftp.isi.edu/internet-drafts/draft-ietf-> 
> > ccamp-gmpls-ason-routing-
> > > reqts-
> > > 02.txt
> > > 
> > > The second DT issue is on the physical architecture which can be
> > > supported by GMPLS (from the draft):
> > > 
> > > ASON does not restrict the architecture choices used, either a
> > > co-located architecture or a physically separated 
> > architecture may be
> > > used. Some members of the Design Team are concerned that GMPLS's
> > > concept of the LSR requires a 1-to-1 relationship between the 
> > > transport plane entity and the control plane entity 
> (Router). They 
> > > invite CCAMP input on GMPLS capabilities to support multiple 
> > > architectures i.e. how routing protocols would identify the 
> > transport
> > > node ID vs. the router or routing controller ID when
> > scoping Link IDs
> > > in a link advertisement. Deborah
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > --
> > Papadimitriou Dimitri
> > E-mail : [e-mail]
> > E-mail : [e-mail]
> > Webpage: http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : [phone]
> > 
> > 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Mar 2004 02:42:40 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Stepping back from the ASON Routing Discussion
Date: Tue, 16 Mar 2004 21:41:18 -0500

Hi Adrian

I had to step away from my computer for a snowstorm looks like there was a
bit of a flurry here too;-) 
I'll try to stick to the questions and answers as I know them. 

See inline

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Tuesday, March 16, 2004 5:44 PM
> To: [e-mail]
> Subject: Stepping back from the ASON Routing Discussion
> 
> 
> Just stepping back a moment...
> 
> It feels to me that we are getting drawn into discussions of 
> what can and cannot be achieved using existing protocols. 
> This is all very valid, but is clearly not part of the 
> requirements work.
> 
> I understand that the DT wishes to analyse the changes to 
> existing protocols to meet the requirements under the charter 
> phrase "to capture what's missing from current CCAMP work", 
> but I feel that this is clouding (and delaying) the 
> production of a clear requirements draft.
> 
> So looking at the three topics that Deborah raised.
> 
> 1.
> Some members of the Design Team noted that reachability 
> information (as described in Section 4.5.3) may be advertised 
> as a set of UNI Transport Resource address prefixes (assigned 
> and selected consistently in their applicability scope). 
> These members of the Design Team raised a concern that 
> existing methods of advertising reachability may need to be 
> examined (on a per-protocol basis) to determine if they are 
> also applicable for UNI Transport Resource addresses. They 
> invite CCAMP discussion on this aspect.
> 
> The first sentence is about requirements.
> Do we, or do we not, need to support advertising UNI 
> Transport Resource address prefixes?
My opinion is Yes there is a requirement in signaling protocols requirement
to signal a name i.e. UNI TR address (complete). 
No in inter domain routing. Requirement addresses must be able to be
aggregated and names are not. The requirement is that a UNI TR address must
resolve to an Prefix address (For GMPLS routing IP prefix fits). 
That leaves intra domain routing. The requirement is to have a destination
address resolution. You are signaling with a UNI TR address (complete) and
you have a IP address prefix or nothing.  The problem is IP cannot take you
all the way because resolving completely outside of the area is not a
requirement. But inside the area you should be able to resolve a UNI TR
address to a IP address Control plane element. 

> 
> The second sentence is about solutions and is not relevant in 
> this draft.
> 
> 2.
> ASON does not restrict the architecture choices used, either 
> a co-located architecture or a physically separated 
> architecture may be used. Some members of the Design Team are 
> concerned that GMPLS's concept of the LSR requires a 1-to-1 
> relationship between the transport plane entity and the 
> control plane entity (Router). They invite CCAMP input on 
> GMPLS capabilities to support multiple architectures i.e. how 
> routing protocols would identify the transport node ID vs. 
> the router or routing controller ID when scoping Link IDs in 
> a link advertisement.
> 
> The first sentence is about requirements.
> Do we, or do we not need to support a physically separated 
> architecture with a 1-n relationship between control plane 
> and transport plane entities?
I would say yes. The requirement I see here is devices not capable of
participating fully in GMPLS routing.

> 
> The remaining text is about solutions and not relevant in this draft.
> 
> 3.
> In order to support operator assisted changes in the 
> containment relationships of RAs, the GMPLS routing protocol 
> is expected to support evolution in terms of number of 
> hierarchical levels of RAs (adding and removing RAs at the 
> top/bottom of the hierarchy), as well as aggregation and 
> segmentation of RAs. These GMPLS routing capabilities are 
> considered of lower priority as they are implementation 
> specific and their method of support should be evaluated on 
> per-protocol basis e.g. OSPF vs IS-IS. In addition, support 
> of non-disruptive operations such as adding or removing a 
> hierarchical level of RAs in or from the middle of the 
> routing hierarchy are considered as the lowest priority 
> requirements. Note also that the number of hierarchical 
> levels to be supported is implementation specific, and 
> reflects a containment relationship e.g. a RA insertion 
> involves supporting a different routing protocol domain in a 
> portion of the network.
> Note: some members of the Design Team question if the ASON 
> requirement for supporting architecture evolution is a 
> requirement on the routing protocol (protocol specific
> capability) vs. a capability to be provided by the 
> architecture. For example, ASON allows for supporting 
> multiple protocols within each RA. The multiple protocols 
> share a common routing information database (RDB), and the 
> RDB is the component, which needs to support architecture 
> evolution. The Design Team invites CCAMP input to understand 
> the protocol-specific impacts.
> 
> This seems to mix up requirements and solutions.
> It is not relevant what OSPF and IS-IS can or cannot do.
> 
> The requirements questions are:
> A. What does ASON require in terms of evolution of 
> hierarchies? B. Are these requirements immediate and high priority?
No comment from me. 

> 
> 
> Is it reasonable to make this separation between 
> requirements, and consequent required changes to the 
> protocols? If so, can we focus on the requirements and make 
> some rapid progress?

Hope that helps,
Don 
> 
> Thanks,
> Adrian
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 23:57:36 +0000
Message-Id: <[e-mail]>
To: "zafar ali" <[e-mail]>
cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, [e-mail], "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, [e-mail], "'Reshad Rahman'" <[e-mail]>, [e-mail]
Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 15 Mar 2004 13:28:15 -0800
From: Yakov Rekhter <[e-mail]>

Zafar,

> >> >> SPs don't like to see RSVP Hello running even when there is
> >> >> no application requiring them.
> >> >
> >> >Could you please describe scenario(s) where you would have
> >> >RSVP Hello running "even when there is no application 
> >requiring them".
> >> >
> >> >Yakov.
> >> >
> >> 
> >> Hi Yakov,
> >> 
> >> Here is a scenario:
> >> 
> >> 1. You start without any application that require RSVP Hellos.
> >> --> You will see RSVP Hellos are NOT running.
> >> 
> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
> >> --> You will see RSVP Hellos start running.
> >> 
> >> So far so good :-)
> >> 
> >> 3. You disable application requiring RSVP Hello.
> >> --> One would expect RSVP Hellos to stop but they keeps 
> >running :-( If
> >> one side stops replying to RSVP Hello, it would cause traffic 
> >> disruption for LSPs that depend on the health of the Hello session. 
> >> The only way to get around this limitation is to continue to run 
> >> Hellos.
> >
> >The scenario you described above seems to assume that there 
> >are RSVP applications that do *not* require to run RSVP 
> >Hellos. 
> 
> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP
> Hello to detect liveness of RSVP module at the neighbor and instead uses
> refresh mechanics for this purpose. 

In principle one could use the refresh mechanism as a liveness
detection of the RSVP module of the control plane. However, the
overhead of the refresh mechanism is certainly higher than of Hello.
And that is why using RSVP Hellos for detecting liveness of RSVP
module of the control plane seems to be the best available today
(note that "best" does not imply "the only").

Yakov.



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 23:34:44 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Vishal Sharma' <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Stepping back from the ASON Routing Discussion
Date: Tue, 16 Mar 2004 15:32:40 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Adrian, Vishal,

Just when we had a good argument going!

Seriously, I would say yes to the first two requirements,
with the addition of the more detailed requirements you asked
to be captured from my email and Jon's email

(LYO: If it is possible
> to advertise from R1 that P1/P2/P3 are separate nodes with 
> links in-between, then that would I think be satisfactory.)

(JS/AF:    A collection of links and nodes such as a subnetwork or RA must
   be able to represent itself to the wider network as a single 
   logical entity with only its external links visible to the 
   topology database.)

Cheers,

Lyndon




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 23:06:40 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: RE: Stepping back from the ASON Routing Discussion
Date: Tue, 16 Mar 2004 15:05:49 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian,

This is the clearest statement of requirements on these three
counts that I have yet seen! Thanks for zeroing in on these
so succinctly.

(And, yes, I agree that we are getting drawn into solutions; I
think the implication being that there is agreement on the
requirements?)

Responses in-line.

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, March 16, 2004 2:44 PM
> To: [e-mail]
> Subject: Stepping back from the ASON Routing Discussion
>
>
> Just stepping back a moment...
>
> It feels to me that we are getting drawn into discussions of what
> can and cannot be
> achieved using existing protocols. This is all very valid, but is
> clearly not part of the
> requirements work.
>
> I understand that the DT wishes to analyse the changes to
> existing protocols to meet the
> requirements under the charter phrase "to capture
> what's missing from current CCAMP work", but I feel that this is
> clouding (and delaying)
> the production of a clear requirements draft.
>
> So looking at the three topics that Deborah raised.
>
> 1.
> Some members of the Design Team noted that reachability
> information (as described in
> Section 4.5.3) may be advertised as a set of UNI Transport
> Resource address prefixes
> (assigned and selected consistently in their applicability
> scope). These members of the
> Design Team raised a concern that existing methods of advertising
> reachability may need to
> be examined (on a per-protocol basis) to determine if they are
> also applicable for UNI
> Transport Resource addresses. They invite CCAMP discussion on this aspect.
>
> The first sentence is about requirements.
> Do we, or do we not, need to support advertising UNI Transport
> Resource address prefixes?

I would say "Yes."

> The second sentence is about solutions and is not relevant in this draft.
>
> 2.
> ASON does not restrict the architecture choices used, either a
> co-located architecture or
> a physically separated architecture may be used. Some members of
> the Design Team are
> concerned that GMPLS's concept of the LSR requires a 1-to-1
> relationship between the
> transport plane entity and the control plane entity (Router).
> They invite CCAMP input on
> GMPLS capabilities to support multiple architectures i.e. how
> routing protocols would
> identify the transport node ID vs. the router or routing
> controller ID when scoping Link
> IDs in a link advertisement.
>
> The first sentence is about requirements.
> Do we, or do we not need to support a physically separated
> architecture with a 1-n
> relationship between control plane and transport plane entities?

I would say an emphatic "Yes."

(Recall Lyndon's ADM example, and
plenty of others, where such intelligence may not be co-incidental with,
or exclusive to, each data plane entity. And, recall Jonathan's logical
node Tn, in response to Issue 2)

> The remaining text is about solutions and not relevant in this draft.
>
> 3.
> In order to support operator assisted changes in the containment
> relationships of RAs, the
> GMPLS routing protocol is expected to support evolution in terms
> of number of hierarchical
> levels of RAs (adding and removing RAs at the top/bottom of the
> hierarchy), as well as
> aggregation and segmentation of RAs. These GMPLS routing
> capabilities are considered of
> lower priority as they are implementation specific and their
> method of support should be
> evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition,
> support of non-disruptive
> operations such as adding or removing a hierarchical level of RAs
> in or from the middle of
> the routing hierarchy are considered as the lowest priority
> requirements. Note also that
> the number of hierarchical levels to be supported is
> implementation specific, and reflects
> a containment relationship e.g. a RA insertion involves
> supporting a different routing
> protocol domain in a portion of the network.
> Note: some members of the Design Team question if the ASON
> requirement for supporting
> architecture evolution is a requirement on the routing protocol
> (protocol specific
> capability) vs. a capability to be provided by the architecture.
> For example, ASON allows
> for supporting multiple protocols within each RA. The multiple
> protocols share a common
> routing information database (RDB), and the RDB is the component,
> which needs to support
> architecture evolution. The Design Team invites CCAMP input to
> understand the
> protocol-specific impacts.
>
> This seems to mix up requirements and solutions.
> It is not relevant what OSPF and IS-IS can or cannot do.

I agree, but would add "for the moment." Clearly, the next step
would be to move into the protocol capabilities.

> The requirements questions are:
> A. What does ASON require in terms of evolution of hierarchies?
> B. Are these requirements immediate and high priority?


I would add...

C. Are the hierarchy requirements, requirements on the routing protocol
or on the realization of the architecture?
(Strictly speaking, even this may not be part of the requirements
document, but it would be nice to know (and agree on) the answer
to this, because it dictates what we focus on next.)


> Is it reasonable to make this separation between requirements,
> and consequent required
> changes to the protocols?

I think very much so.

If so, can we focus on the requirements
> and make some
> rapid progress?
>
> Thanks,
> Adrian
>




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:59:37 +0000
Message-Id: <[e-mail]>
To: "zafar ali" <[e-mail]>
cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, [e-mail], "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, [e-mail], "'Reshad Rahman'" <[e-mail]>, [e-mail]
Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 15 Mar 2004 13:28:15 -0800
From: Yakov Rekhter <[e-mail]>

Zafar,

> >> >> SPs don't like to see RSVP Hello running even when there is
> >> >> no application requiring them.
> >> >
> >> >Could you please describe scenario(s) where you would have
> >> >RSVP Hello running "even when there is no application 
> >requiring them".
> >> >
> >> >Yakov.
> >> >
> >> 
> >> Hi Yakov,
> >> 
> >> Here is a scenario:
> >> 
> >> 1. You start without any application that require RSVP Hellos.
> >> --> You will see RSVP Hellos are NOT running.
> >> 
> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
> >> --> You will see RSVP Hellos start running.
> >> 
> >> So far so good :-)
> >> 
> >> 3. You disable application requiring RSVP Hello.
> >> --> One would expect RSVP Hellos to stop but they keeps 
> >running :-( If
> >> one side stops replying to RSVP Hello, it would cause traffic 
> >> disruption for LSPs that depend on the health of the Hello session. 
> >> The only way to get around this limitation is to continue to run 
> >> Hellos.
> >
> >The scenario you described above seems to assume that there 
> >are RSVP applications that do *not* require to run RSVP 
> >Hellos. 
> 
> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP
> Hello to detect liveness of RSVP module at the neighbor and instead uses
> refresh mechanics for this purpose. 

In principle one could use the refresh mechanism as a liveness
detection of the RSVP module of the control plane. However, the
overhead of the refresh mechanism is certainly higher than of Hello.
And that is why using RSVP Hellos for detecting liveness of RSVP
module of the control plane seems to be the best available today
(note that "best" does not imply "the only").

Yakov.



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:55:50 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Jonathan Sadler" <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 14:55:00 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Lyndon, Adrian,

Thanks for the clarification. I don't think Adrian had specified
how the advertizements themselves happen, only put the physical
topology in place.

I think the question of whether the appropriate info. can
be actually be advertized with existing mechanisms is an open one, that
folks are trying to answer.

In fact, Jonathan's recent email outlines a scenario where it
may not be desirable to advertize these details externally (even
assuming they could be).

Adrian, to answer your question of whether there is a functional
requirement to know R1's router address, I think this would
depend on the logical topology being advertized. Since the ASON
architecture allows for various logical groupings (and advertizings)
of control and data plane physical realizations, in the event that
R1 is advertized as a logical node, there would be a need to
know its address externally.

If, however, as Jonathan's example shows, Tn is the logical node
advertized, there wouldn't be a need to specifically know R1's
router address externally (although there would be a need to know some
router
address, charaterizing Tn, externally).

-Vishal


> -----Original Message-----
> From: Ong, Lyndon [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 2:20 PM
> To: 'Vishal Sharma'; [e-mail]; Adrian Farrel
> Cc: Don Fedyk; Brungard, Deborah A, ALABS; [e-mail]
> Subject: RE: ason-routing-reqts: issue 2 architecture
>
>
> Hi Vishal, Adrian,
>
> Maybe I am misinterpreting Adrian's figure.  If it is possible
> to advertise from R1 that P1/P2/P3 are separate nodes with
> links in-between, then that would I think be satisfactory.
>
> It was my belief (and maybe Don's as well) that to do this
> you needed to include node IDs for P1/P2/P3 in addition to
> R1 as the router address.
>
> Sorry about using some poor terminology...
>
> Cheers,
>
> Lyndon
>
> -----Original Message-----
> From: Vishal Sharma [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 2:11 PM
> To: Ong, Lyndon; [e-mail]; Adrian Farrel
> Cc: Don Fedyk; Brungard, Deborah A, ALABS; [e-mail]
> Subject: RE: ason-routing-reqts: issue 2 architecture
>
>
> Adrian, Lyndon,
>
> Adrian, based on what I've been following of the discussions, I think
> your figure is right on target, and captures the various scenarios
> that people were discussing (in abstraction) so far.
>
> Lyndon, with respect to your email below, is it true that if
> R1 is the control plane entity responsible for P1/P2/P3 that it
> must necessarily advertize them as an abstract node?
>
> (I thought we were distinguishing between data-plane nodes and nodes
> in the control plane that manage them, but am not sure if this
> implies the above.)
>
> Also, not sure I understand what is meant by "advertise P1/P2/P3
> directly"?
> Which entity would do such a direct advertizement? Wouldn't it be
> R1, if it was the control plane entity responsible for P1/P2/P3?
> (Which would I guess be possible only if the abstract node advertizement
> was not a requirement.)
>
> Thanks,
> -Vishal
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Ong, Lyndon
> > Sent: Tuesday, March 16, 2004 1:37 PM
> > To: '[e-mail]'; Adrian Farrel
> > Cc: Don Fedyk; Brungard, Deborah A, ALABS; [e-mail]
> > Subject: RE: ason-routing-reqts: issue 2 architecture
> >
> >
> > Hi Guys,
> >
> > R1 was what I was referring to in my side note: it is
> > possible to treat P1/P2/P3 as separate
> > interfaces on a single abstract node, but you lose
> > information about the physical topology and
> > connectivity of the nodes.  Also, this puts a
> > constraint on the allocation of interface IDs across
> > multiple nodes.
> >
> > Would it not be simpler and more straightforward to
> > advertise P1/P2/P3 directly?
> >
> > Cheers,
> >
> > Lyndon
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > Sent: Tuesday, March 16, 2004 12:58 PM
> > To: Adrian Farrel
> > Cc: Don Fedyk; Ong, Lyndon; Brungard, Deborah A, ALABS;
> > [e-mail]
> > Subject: Re: ason-routing-reqts: issue 2 architecture
> >
> >
> > adrian,
> >
> > yes, it reproduces the three cases, i had in mind over this
> > discussion
> >
> > see in-line:
> >
> > > All,
> > > Does the following picture capture what we want to achieve?
> > >
> > >
> > >              ------------------     ------
> > >             |R1                |   |R2    |
> > >             |  --    --    --  |   |  --  |    ------
> > >             | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
> > >             |  --    --    --  |   |  --  |   |  --  |
> > >             |   :     :     :  |   |   :  |   | |L5| |
> > > Control      ---+-----+-----+--     ---+--    |  --  |
> > > Plane           :     :     :          :      |   :  |
> > > ----------------+-----+-----+----------+------+---+--+-
> > > Data            :     :     :          :      |   :  |
> > > Plane          --     :    --         --      |  --  |
> > >           ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
> > >                -- \   :  / --         --      |  --  |
> > >                    \ -- /                     |      |
> > >                     |P2|                       ------
> > >                      --
> > >
> > > Pn is a physical (bearer/data/transport plane) node.
> > > Rn is a control plane "router"
> > > Ln is a logical control plane entity that manages a single
> > >    physical node.
> > >
> > > Thus:
> > > R3 represents an LSR with all components collocated.
> > > R2 shows how the "router" component may be disjoint from
> > >    the switch
> > > R1 shows how a single "router" may manage multiple switches
> > >
> > > If you can confirm this generalisation, then we can show (or
> > fail to show)
> > > A. That this is a requirement
> >
> > to support all them yes (i think that from a protocol
> > capability perspective it is advisable)
> >
> > > B. That this can be achieved using existing protocols
> >
> > there is no difference between R2 and R3 since the DP
> > to CP interactions were never part of the GMPLS routing
> > discussions:
> > - R2 <- Router_Address, R3 <- Router_Address
> > - If_Id assigned to each interface
> >
> > for R1 (externally since representing an abstract node):
> > - R1 <- Router_Address
> > - If_Id assigned to each interface (with a value space
> >    common to P1, P2 and P3)
> >
> > for R1 if there is a need to cover also the internal
> > (abstract node) links (is that the case?), in such a
> > case, the Link_Id sub-TLV value should be discussed
> >
> > > Cheers,
> > > Adrian.
> > >
> > > PS. Those not familiar with GSMP may want to take a quick peak.
> > >
> > > ----- Original Message -----
> > > From: "Don Fedyk" <[e-mail]>
> > > To: <[e-mail]>; "Ong, Lyndon"
> <[e-mail]>
> > > Cc: "Adrian Farrel" <[e-mail]>; "Brungard, Deborah
> > A, ALABS" <[e-mail]>; <[e-mail]>
> > > Sent: Tuesday, March 16, 2004 7:34 PM
> > > Subject: RE: ason-routing-reqts: issue 2 architecture
> > >
> > >
> > >
> > >>Dimitri
> > >>
> > >>If you are saying the real or logical node id that is
> > associated with the
> > >>Data (bearer) plane should be unique? I would say yes.
> > >>
> > >>If you are saying could it be IP address format? I would say
> > yes. (Note the
> > >>link identifiers in IP address format are unique only with
> > respect to the
> > >>node id).
> > >>
> > >>But if you say Should it then follow each piece of equipment
> > has knowledge
> > >>of this IP address format that is assigned to it? I would say
> no because
> > >>there is equipment that won't have this for some time. (A
> requirement I
> > >>understand from ASON).
> > >>
> > >>So what I believe you are left with is some bearer equipment
> > which has TE
> > >>resources (a node Identifier (non-IP) and link identifiers
> > (non-IP)). This
> > >>equipment is known by its native identifiers to the entity in
> > the control
> > >>plane which can assign: IP format identifiers to the equipment
> > (through some
> > >>means) and an unique node identifier. This can then be
> advertised on its
> > >>behalf as a GMPLS compatible TE LSA.
> > >>
> > >>This does create some challenges but in reality I think many
> devices are
> > >>known by more than one name. (Look at VoIP, devices they have 2
> > identifiers
> > >>E.164 and IP. I personally never use my IP address to make a
> > VoIP phone call
> > >>but I know that it is routed to a IP address along the way that
> > is hidden
> > >>from me.)
> > >>
> > >>I tend to agree with Lyndon that Topology is derived from TE
> > advertisements.
> > >>I don't understand what you could do without a unique logical node
> > >>associated with the TE links.
> > >>
> > >>Don
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: [e-mail]
> > >>>[mailto:[e-mail]]
> > >>>Sent: Tuesday, March 16, 2004 1:48 PM
> > >>>To: Ong, Lyndon
> > >>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard,
> > >>>Deborah A, ALABS; [e-mail]
> > >>>Subject: Re: ason-routing-reqts: issue 2 architecture
> > >>>
> > >>>
> > >>>the problem is not an issue of being cleaner, the issue
> > >>>is once the following assumption is taken (which is the
> > >>>logical consequence of rfc 3630 in the gmpls context)
> > >>>
> > >>>"a stable IP address of the control plane entity that
> > >>>manages the resources on behalf of the data plane
> > >>>entity whose resources are being advertised."
> > >>>
> > >>>can we assume that wrt to this stable IP address the
> > >>>resource identification will be unique (throughout
> > >>>these multiple data plane entities) and in this case
> > >>>it holds (no additional level of indirection needed),
> > >>>or not (i.e. you will find duplicated id space values
> > >>>and then an additional level of indirection is needed)
> > >>>
> > >>>the problem of the design team was not define the issue
> > >>>but to find enough arguments wrt to the operational
> > >>>practices (ie user community) in order to close this
> > >>>
> > >>>thanks,
> > >>>- dimitri.
> > >>>
> > >>>Ong, Lyndon wrote:
> > >>>
> > >>>>I had the same assumption as Don, that the RFC treats the
> > >>>
> > >>>advertising
> > >>>
> > >>>>router and the bearer plane node as the same. It would be
> > >>>
> > >>>cleaner if
> > >>>
> > >>>>there was also a bearer plane node identifier in the advertisement.
> > >>>>
> > >>>>Cheers,
> > >>>>
> > >>>>Lyndon
> > >>>>
> > >>>>-----Original Message-----
> > >>>>From: Don Fedyk [mailto:[e-mail]]
> > >>>>Sent: Tuesday, March 16, 2004 9:56 AM
> > >>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> > >>>>Subject: RE: ason-routing-reqts: issue 2 architecture
> > >>>>
> > >>>>
> > >>>>Hi Adrian
> > >>>>
> > >>>>See Comments Below,
> > >>>>
> > >>>>
> > >>>>
> > >>>>>-----Original Message-----
> > >>>>>From: Adrian Farrel [mailto:[e-mail]]
> > >>>>>Sent: Monday, March 15, 2004 4:18 PM
> > >>>>>To: Brungard, Deborah A, ALABS; [e-mail]
> > >>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
> > >>>>>
> > >>>>>
> > >>>>>I assume that the desire is to have one control plane entity
> > >>>>>mange multiple data plane entities (not to have one data
> > >>>>>plane entity managed by multiple control plane entities).
> > >>>>
> > >>>>
> > >>>>I agree.
> > >>>>
> > >>>>
> > >>>>>I believe. in this context, it might be helpful to separate
> > >>>>>the signaling function (and the associated routing function
> > >>>>>for the delivery of the signaling messages) from the TE
> > >>>>>advertisement routing function. Since we are discussing the
> > >>>>>routing requirements (this is the routing DT) can I assume
> > >>>>>that the discussion is limited to the TE advertisement
> > >>>>>routing function, with the aim to have one control plane
> > >>>>>entity advertise the resources on behalf of multiple data
> > >>>>>plane entities.
> > >>>>>
> > >>>>>If all of the above, why could you not simply do this using
> > >>>>>RFC3630? The only wrinkle might be that the Router Address
> > >>>>>TLV is described as carrying "a stable IP address of the
> > >>>>>advertising router". Clearly, this needs to be interpreted as
> > >>>>>"a stable IP address of the control plane entity that manages
> > >>>>>the resources on behalf of the data plane entity whose
> > >>>>>resources are being advertised."
> > >>>>
> > >>>>
> > >>>>Interesting. I thought that you need a logical node id for
> > >>>
> > >>>the bearer
> > >>>
> > >>>>plane as well even though you are only advertising from a single
> > >>>>entity.  In other words, is it not the desire to have the TE
> > >>>>advertisements contain the same information regardless of whether
> > >>>>there is a one to one correspondence between the nodes in
> > >>>
> > >>>control and
> > >>>
> > >>>>the data plane or there is a one to many relationship? My
> > >>>>interpretation of RFC3630 is that it assumes the
> > >>>
> > >>>advertising router is
> > >>>
> > >>>>the same as the logical node in the bearer plane that owns the
> > >>>>resources. If a logical node id was added to the
> > >>>
> > >>>advertisement for the
> > >>>
> > >>>>node terminating the resources when the advertising router
> > >>>
> > >>>was not the
> > >>>
> > >>>>bearer node that owned the resources it would be clearer to me.
> > >>>>
> > >>>>Don
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>Am I missing something?
> > >>>>>
> > >>>>>Adrian
> > >>>>>
> > >>>>>----- Original Message -----
> > >>>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> > >>>>>To: <[e-mail]>
> > >>>>>Sent: Monday, March 15, 2004 7:43 PM
> > >>>>>Subject: ason-routing-reqts: issue 2 architecture
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>ftp://ftp.isi.edu/internet-drafts/draft-ietf->
> > ccamp-gmpls-ason-routing-
> > >>>
> > >>>>reqts-
> > >>>>02.txt
> > >>>>
> > >>>>The second DT issue is on the physical architecture which can be
> > >>>>supported by GMPLS (from the draft):
> > >>>>
> > >>>>ASON does not restrict the architecture choices used, either a
> > >>>>co-located architecture or a physically separated
> > >>>
> > >>>architecture may be
> > >>>
> > >>>>used. Some members of the Design Team are concerned that GMPLS's
> > >>>>concept of the LSR requires a 1-to-1 relationship between the
> > >>>>transport plane entity and the control plane entity (Router). They
> > >>>>invite CCAMP input on GMPLS capabilities to support multiple
> > >>>>architectures i.e. how routing protocols would identify the
> > >>>
> > >>>transport
> > >>>
> > >>>>node ID vs. the router or routing controller ID when
> > >>>
> > >>>scoping Link IDs
> > >>>
> > >>>>in a link advertisement. Deborah
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>--
> > >>>Papadimitriou Dimitri
> > >>>E-mail : [e-mail]
> > >>>E-mail : [e-mail]
> > >>>Webpage: http://psg.com/~dpapadimitriou/
> > >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > >>>Phone  : [phone]
> > >>>
> > >>>
> > >>
> > >
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [e-mail]
> > E-mail : [e-mail]
> > Webpage: http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:44:57 +0000
Message-ID: <0ce301c40ba8$3d80a9b0$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Stepping back from the ASON Routing Discussion
Date: Tue, 16 Mar 2004 22:44:23 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Just stepping back a moment...

It feels to me that we are getting drawn into discussions of what can and cannot be
achieved using existing protocols. This is all very valid, but is clearly not part of the
requirements work.

I understand that the DT wishes to analyse the changes to existing protocols to meet the
requirements under the charter phrase "to capture
what's missing from current CCAMP work", but I feel that this is clouding (and delaying)
the production of a clear requirements draft.

So looking at the three topics that Deborah raised.

1.
Some members of the Design Team noted that reachability information (as described in
Section 4.5.3) may be advertised as a set of UNI Transport Resource address prefixes
(assigned and selected consistently in their applicability scope). These members of the
Design Team raised a concern that existing methods of advertising reachability may need to
be examined (on a per-protocol basis) to determine if they are also applicable for UNI
Transport Resource addresses. They invite CCAMP discussion on this aspect.

The first sentence is about requirements.
Do we, or do we not, need to support advertising UNI Transport Resource address prefixes?

The second sentence is about solutions and is not relevant in this draft.

2.
ASON does not restrict the architecture choices used, either a co-located architecture or
a physically separated architecture may be used. Some members of the Design Team are
concerned that GMPLS's concept of the LSR requires a 1-to-1 relationship between the
transport plane entity and the control plane entity (Router). They invite CCAMP input on
GMPLS capabilities to support multiple architectures i.e. how routing protocols would
identify the transport node ID vs. the router or routing controller ID when scoping Link
IDs in a link advertisement.

The first sentence is about requirements.
Do we, or do we not need to support a physically separated architecture with a 1-n
relationship between control plane and transport plane entities?

The remaining text is about solutions and not relevant in this draft.

3.
In order to support operator assisted changes in the containment relationships of RAs, the
GMPLS routing protocol is expected to support evolution in terms of number of hierarchical
levels of RAs (adding and removing RAs at the top/bottom of the hierarchy), as well as
aggregation and segmentation of RAs. These GMPLS routing capabilities are considered of
lower priority as they are implementation specific and their method of support should be
evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition, support of non-disruptive
operations such as adding or removing a hierarchical level of RAs in or from the middle of
the routing hierarchy are considered as the lowest priority requirements. Note also that
the number of hierarchical levels to be supported is implementation specific, and reflects
a containment relationship e.g. a RA insertion involves supporting a different routing
protocol domain in a portion of the network.
Note: some members of the Design Team question if the ASON requirement for supporting
architecture evolution is a requirement on the routing protocol (protocol specific
capability) vs. a capability to be provided by the architecture. For example, ASON allows
for supporting multiple protocols within each RA. The multiple protocols share a common
routing information database (RDB), and the RDB is the component, which needs to support
architecture evolution. The Design Team invites CCAMP input to understand the
protocol-specific impacts.

This seems to mix up requirements and solutions.
It is not relevant what OSPF and IS-IS can or cannot do.

The requirements questions are:
A. What does ASON require in terms of evolution of hierarchies?
B. Are these requirements immediate and high priority?


Is it reasonable to make this separation between requirements, and consequent required
changes to the protocols? If so, can we focus on the requirements and make some
rapid progress?

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:40:22 +0000
Message-ID: <0cc701c40ba7$8c04df30$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, "'Vishal Sharma'" <[e-mail]>, <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Subject: Re: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 22:36:08 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> Maybe I am misinterpreting Adrian's figure.  If it is possible
> to advertise from R1 that P1/P2/P3 are separate nodes with 
> links in-between, then that would I think be satisfactory.

Good. Let's state this requirement and move on.

> It was my belief (and maybe Don's as well) that to do this
> you needed to include node IDs for P1/P2/P3 in addition to
> R1 as the router address.  

Why do you need to know the R1 address?
Hint: Don't answer "because that is what the protocol says you must advertise"!

Is there a finctional requirement to know R1's router address?

> Sorry about using some poor terminology...

We're all learning.

Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:36:13 +0000
Message-ID: <0cc201c40ba6$f416ad20$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Jonathan Sadler" <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, <[e-mail]>, "Ong, Lyndon" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Subject: Re: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 22:33:44 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CBB_01C40BA6.BDBC08B0"

This is a multi-part message in MIME format.

------=_NextPart_000_0CBB_01C40BA6.BDBC08B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

But this is just Forwarding Adjacencies, link bundles and logical nodes, =
isn't it?

So let's state the requirement and move on.

   A collection of links and nodes such as a subnetwork or RA must
   be able to represent itself to the wider network as a single=20
   logical entity with only its external links visible to the=20
   topology database.

Agreed?

Adrian

----- Original Message -----=20
From: "Jonathan Sadler" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>; =
<[e-mail]>; "Ong, Lyndon" <[e-mail]>; =
"Brungard, Deborah A, ALABS" <[e-mail]>; <[e-mail]>
Sent: Tuesday, March 16, 2004 10:08 PM
Subject: Re: ason-routing-reqts: issue 2 architecture


> Adrian -
>=20
> Yes, however it isn't limited to what you have in the picture.  Take =
the
> following picture:
>=20
> Logical
> Topology           +-++
>            --------+T1+--------
>                    +--+
>=20
> Physical
> Realization
>=20
>           ---------------   ----   ----
>          |R1             | |R2  | |R3  |
>          | +-----------+ | |+--+| |+--+|
>          | |L1         | | ||L2|| ||L3||
>          | +-----------+ | |+--+| |+--+|
>          | :     :     : | | :  | | :  |
>           -+-----+-----+-   -+--  | :  |
>  Control   :     :     :     :    | :  |
>  ----------+-----+-----+-----+----+-+--+-------
>  Data      :     :     :     :    | :  |
>           -+     :     +-    :    | +- |
>    ------+P1+---------+P3+--------+|P5|+----
>           --     :    /--\   :    | -- |
>              \  -+-  /    \  +-  / ----
>               \|P2 |/      \|P4|/
>                 ---          --
>=20
>=20
> L1, L2, and L3 are aware of the topology of P1-P5, and therefore can
> progress a signalling request presented to L1 through the nodes, but =
are
> not sharing it with the outside world.  The only topology seen is T1.
> The reason for doing this could be due to policy (hiding) or
> scalability.  (See draft-ietf-ipo-carrier-requirements for more
> explanation on why this is good)
>=20
> Note here that the Logical topology being advertized (characterized by
> Tn) is different from the control plane realization (Ln) as well as =
the
> data plane realization (Pn).  This is possible in the ASON =
architecure,
> as there is no limitation in how a function is realized.
>=20
> In this case, you wouldn't be able to have separate Router IDs for =
each
> Pn, as the single T1 shown above must use the same Router ID for the
> link endpoint names in order make only a single node appear in the
> topology.  However, since the resource information for the link
> ingressing at P1 as well as the link egressing at P5 are in R1 and R3,
> it is problematic to have a single Router ID.
>=20
> Jonathan Sadler
>=20
> Adrian Farrel wrote:
>=20
> > All,Does the following picture capture what we want to
> > achieve?               ------------------     ------
> > |R1                |   |R2    |            |  --    --    --  |   |
> > --  |    ------            | |L1|  |L2|  |L3| |   | |L4| |   |R3
> > |            |  --    --    --  |   |  --  |   |  --  |            |
> > :     :     :  |   |   :  |   | |L5| |Control
> > ---+-----+-----+--     ---+--    |  --  |Plane           :     :
> > :          :      |   :
> > |----------------+-----+-----+----------+------+---+--+-Data
> > :     :     :          :      |   :  |Plane          --     :
> > --         --      |  --  |
> > ----|P1|--------|P3|-------|P4|-----+-|P5|-+-               -- \   :
> > / --         --      |  --  |                   \ --
> > /                     |      |
> > |P2|                       ------                     -- Pn is a
> > physical (bearer/data/transport plane) node.Rn is a control plane
> > "router"Ln is a logical control plane entity that manages a single
> > physical node. Thus:R3 represents an LSR with all components
> > collocated.R2 shows how the "router" component may be disjoint from
> > the switchR1 shows how a single "router" may manage multiple =
switches
> > If you can confirm this generalisation, then we can show (or fail to
> > show)A. That this is a requirementB. That this can be achieved using
> > existing protocols  Cheers,Adrian. PS. Those not familiar with GSMP
> > may want to take a quick peak. ----- Original Message -----From: =
"Don
> > Fedyk" <[e-mail]>To:
> > <[e-mail]>; "Ong, Lyndon" =
<[e-mail]>Cc:
> > "Adrian Farrel" <[e-mail]>; "Brungard, Deborah A, ALABS"
> > <[e-mail]>; <[e-mail]>Sent: Tuesday, March 16, =
2004
> > 7:34 PMSubject: RE: ason-routing-reqts: issue 2 architecture > =
Dimitri
> >
> > >
> > > If you are saying the real or logical node id that is associated
> > with the
> > > Data (bearer) plane should be unique? I would say yes.
> > >
> > > If you are saying could it be IP address format? I would say yes.
> > (Note the
> > > link identifiers in IP address format are unique only with respect
> > to the
> > > node id).
> > >
> > > But if you say Should it then follow each piece of equipment has
> > knowledge
> > > of this IP address format that is assigned to it? I would say no
> > because
> > > there is equipment that won't have this for some time. (A
> > requirement I
> > > understand from ASON).
> > >
> > > So what I believe you are left with is some bearer equipment which
> > has TE
> > > resources (a node Identifier (non-IP) and link identifiers
> > (non-IP)). This
> > > equipment is known by its native identifiers to the entity in the
> > control
> > > plane which can assign: IP format identifiers to the equipment
> > (through some
> > > means) and an unique node identifier. This can then be advertised =
on
> > its
> > > behalf as a GMPLS compatible TE LSA.
> > >
> > > This does create some challenges but in reality I think many =
devices
> > are
> > > known by more than one name. (Look at VoIP, devices they have 2
> > identifiers
> > > E.164 and IP. I personally never use my IP address to make a VoIP
> > phone call
> > > but I know that it is routed to a IP address along the way that is
> > hidden
> > > from me.)
> > >
> > > I tend to agree with Lyndon that Topology is derived from TE
> > advertisements.
> > > I don't understand what you could do without a unique logical node
> > > associated with the TE links.
> > >
> > > Don
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]
> > > > Sent: Tuesday, March 16, 2004 1:48 PM
> > > > To: Ong, Lyndon
> > > > Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard,
> > > > Deborah A, ALABS; [e-mail]
> > > > Subject: Re: ason-routing-reqts: issue 2 architecture
> > > >
> > > >
> > > > the problem is not an issue of being cleaner, the issue
> > > > is once the following assumption is taken (which is the
> > > > logical consequence of rfc 3630 in the gmpls context)
> > > >
> > > > "a stable IP address of the control plane entity that
> > > > manages the resources on behalf of the data plane
> > > > entity whose resources are being advertised."
> > > >
> > > > can we assume that wrt to this stable IP address the
> > > > resource identification will be unique (throughout
> > > > these multiple data plane entities) and in this case
> > > > it holds (no additional level of indirection needed),
> > > > or not (i.e. you will find duplicated id space values
> > > > and then an additional level of indirection is needed)
> > > >
> > > > the problem of the design team was not define the issue
> > > > but to find enough arguments wrt to the operational
> > > > practices (ie user community) in order to close this
> > > >
> > > > thanks,
> > > > - dimitri.
> > > >
> > > > Ong, Lyndon wrote:
> > > > > I had the same assumption as Don, that the RFC treats the
> > > > advertising
> > > > > router and the bearer plane node as the same. It would be
> > > > cleaner if
> > > > > there was also a bearer plane node identifier in the
> > advertisement.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Lyndon
> > > > >
> > > > > -----Original Message-----
> > > > > From: Don Fedyk [mailto:[e-mail]]
> > > > > Sent: Tuesday, March 16, 2004 9:56 AM
> > > > > To: Adrian Farrel; Brungard, Deborah A, ALABS;
> > [e-mail]
> > > > > Subject: RE: ason-routing-reqts: issue 2 architecture
> > > > >
> > > > >
> > > > > Hi Adrian
> > > > >
> > > > > See Comments Below,
> > > > >
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: Adrian Farrel [mailto:[e-mail]]
> > > > >>Sent: Monday, March 15, 2004 4:18 PM
> > > > >>To: Brungard, Deborah A, ALABS; [e-mail]
> > > > >>Subject: Re: ason-routing-reqts: issue 2 architecture
> > > > >>
> > > > >>
> > > > >>I assume that the desire is to have one control plane entity
> > > > >>mange multiple data plane entities (not to have one data
> > > > >>plane entity managed by multiple control plane entities).
> > > > >
> > > > >
> > > > > I agree.
> > > > >
> > > > >>I believe. in this context, it might be helpful to separate
> > > > >>the signaling function (and the associated routing function
> > > > >>for the delivery of the signaling messages) from the TE
> > > > >>advertisement routing function. Since we are discussing the
> > > > >>routing requirements (this is the routing DT) can I assume
> > > > >>that the discussion is limited to the TE advertisement
> > > > >>routing function, with the aim to have one control plane
> > > > >>entity advertise the resources on behalf of multiple data
> > > > >>plane entities.
> > > > >>
> > > > >>If all of the above, why could you not simply do this using
> > > > >>RFC3630? The only wrinkle might be that the Router Address
> > > > >>TLV is described as carrying "a stable IP address of the
> > > > >>advertising router". Clearly, this needs to be interpreted as
> > > > >>"a stable IP address of the control plane entity that manages
> > > > >>the resources on behalf of the data plane entity whose
> > > > >>resources are being advertised."
> > > > >
> > > > >
> > > > > Interesting. I thought that you need a logical node id for
> > > > the bearer
> > > > > plane as well even though you are only advertising from a =
single
> >
> > > > > entity.  In other words, is it not the desire to have the TE
> > > > > advertisements contain the same information regardless of
> > whether
> > > > > there is a one to one correspondence between the nodes in
> > > > control and
> > > > > the data plane or there is a one to many relationship? My
> > > > > interpretation of RFC3630 is that it assumes the
> > > > advertising router is
> > > > > the same as the logical node in the bearer plane that owns the
> > > > > resources. If a logical node id was added to the
> > > > advertisement for the
> > > > > node terminating the resources when the advertising router
> > > > was not the
> > > > > bearer node that owned the resources it would be clearer to =
me.
> > > > >
> > > > > Don
> > > > >
> > > > >
> > > > >
> > > > >>Am I missing something?
> > > > >>
> > > > >>Adrian
> > > > >>
> > > > >>----- Original Message -----
> > > > >>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> > > > >>To: <[e-mail]>
> > > > >>Sent: Monday, March 15, 2004 7:43 PM
> > > > >>Subject: ason-routing-reqts: issue 2 architecture
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > ftp://ftp.isi.edu/internet-drafts/draft-ietf->
> > ccamp-gmpls-ason-routing-
> > > > > reqts-
> > > > > 02.txt
> > > > >
> > > > > The second DT issue is on the physical architecture which can =
be
> >
> > > > > supported by GMPLS (from the draft):
> > > > >
> > > > > ASON does not restrict the architecture choices used, either a
> > > > > co-located architecture or a physically separated
> > > > architecture may be
> > > > > used. Some members of the Design Team are concerned that =
GMPLS's
> >
> > > > > concept of the LSR requires a 1-to-1 relationship between the
> > > > > transport plane entity and the control plane entity (Router).
> > They
> > > > > invite CCAMP input on GMPLS capabilities to support multiple
> > > > > architectures i.e. how routing protocols would identify the
> > > > transport
> > > > > node ID vs. the router or routing controller ID when
> > > > scoping Link IDs
> > > > > in a link advertisement. Deborah
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Papadimitriou Dimitri
> > > > E-mail : [e-mail]
> > > > E-mail : [e-mail]
> > > > Webpage: http://psg.com/~dpapadimitriou/
> > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > > Phone  : [phone]
> > > >
> > > >
> > >
> > >
>=20
>=20
>=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=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.
> 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_000_0CBB_01C40BA6.BDBC08B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>But this is just Forwarding =
Adjacencies, link=20
bundles and&nbsp;logical nodes, isn't it?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>So let's state the requirement and =
move=20
on.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; A collection of links =
and nodes such=20
as a subnetwork or RA must</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; &nbsp;be able to=20
represent&nbsp;i</FONT><FONT face=3DCourier size=3D2>tself to the wider =
network as a=20
single </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; logical entity with only =
its=20
external links visible to the </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; topology =
database.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Agreed?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT><FONT face=3DCourier=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DCourier size=3D2>From: "Jonathan Sadler" &lt;</FONT><A =

href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>To: "Adrian Farrel" &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Cc: "Don Fedyk" &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;;=20
&lt;</FONT><A href=3D"mailto:[e-mail]"><FONT =
face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =

size=3D2>&gt;; "Ong, Lyndon" &lt;</FONT><A =
href=3D"mailto:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;;=20
"Brungard, Deborah A, ALABS" &lt;</FONT><A =
href=3D"mailto:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;;=20
&lt;</FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Sent: Tuesday, March 16, 2004 10:08=20
PM</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Subject: Re: ason-routing-reqts: =
issue 2=20
architecture</FONT></DIV></DIV>
<DIV><FONT face=3DCourier><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DCourier=20
size=3D2>&gt; Adrian -<BR>&gt; <BR>&gt; Yes, however it isn't limited to =
what you=20
have in the picture.&nbsp; Take the<BR>&gt; following picture:<BR>&gt; =
<BR>&gt;=20
Logical<BR>&gt;=20
Topology&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+-++<BR>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--------+T1+--------<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+--+<BR>&gt; <BR>&gt; Physical<BR>&gt; Realization<BR>&gt; <BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
---------------&nbsp;&nbsp; ----&nbsp;&nbsp; ----<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |=20
|R2&nbsp; | |R3&nbsp; |<BR>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
| +-----------+ | |+--+| |+--+|<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
|L1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | ||L2|| =
||L3||<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | +-----------+ | =
|+--+|=20
|+--+|<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; : | | :&nbsp; | | =
:&nbsp;=20
|<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
-+-----+-----+-&nbsp;&nbsp; -+--&nbsp; | :&nbsp; |<BR>&gt;=20
&nbsp;Control&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp; | :&nbsp; |<BR>&gt;=20
&nbsp;----------+-----+-----+-----+----+-+--+-------<BR>&gt;=20
&nbsp;Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp; =
|=20
:&nbsp; |<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

-+&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; =
+-&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp; | +- |<BR>&gt; &nbsp;&nbsp;=20
------+P1+---------+P3+--------+|P5|+----<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp; /--\&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp; | -- |<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
\&nbsp;=20
-+-&nbsp; /&nbsp;&nbsp;&nbsp; \&nbsp; +-&nbsp; / ----<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
\|P2 |/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \|P4|/<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
---&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --<BR>&gt; =
<BR>&gt;=20
<BR>&gt; L1, L2, and L3 are aware of the topology of P1-P5, and =
therefore=20
can<BR>&gt; progress a signalling request presented to L1 through the =
nodes, but=20
are<BR>&gt; not sharing it with the outside world.&nbsp; The only =
topology seen=20
is T1.<BR>&gt; The reason for doing this could be due to policy (hiding) =

or<BR>&gt; scalability.&nbsp; (See draft-ietf-ipo-carrier-requirements =
for=20
more<BR>&gt; explanation on why this is good)<BR>&gt; <BR>&gt; Note here =
that=20
the Logical topology being advertized (characterized by<BR>&gt; Tn) is =
different=20
from the control plane realization (Ln) as well as the<BR>&gt; data =
plane=20
realization (Pn).&nbsp; This is possible in the ASON =
architecure,<BR>&gt; as=20
there is no limitation in how a function is realized.<BR>&gt; <BR>&gt; =
In this=20
case, you wouldn't be able to have separate Router IDs for each<BR>&gt; =
Pn, as=20
the single T1 shown above must use the same Router ID for the<BR>&gt; =
link=20
endpoint names in order make only a single node appear in the<BR>&gt;=20
topology.&nbsp; However, since the resource information for the =
link<BR>&gt;=20
ingressing at P1 as well as the link egressing at P5 are in R1 and =
R3,<BR>&gt;=20
it is problematic to have a single Router ID.<BR>&gt; <BR>&gt; Jonathan=20
Sadler<BR>&gt; <BR>&gt; Adrian Farrel wrote:<BR>&gt; <BR>&gt; &gt; =
All,Does the=20
following picture capture what we want to<BR>&gt; &gt;=20
achieve?&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
------------------&nbsp;&nbsp;&nbsp;&nbsp; ------<BR>&gt; &gt;=20
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp; |R2&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;=20
--&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; |&nbsp;&nbsp; =
|<BR>&gt; &gt;=20
--&nbsp; |&nbsp;&nbsp;&nbsp;=20
------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|=20
|L1|&nbsp; |L2|&nbsp; |L3| |&nbsp;&nbsp; | |L4| |&nbsp;&nbsp; =
|R3<BR>&gt; &gt;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;=20
--&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; |&nbsp;&nbsp; |&nbsp; =

--&nbsp; |&nbsp;&nbsp; |&nbsp; --&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|<BR>&gt;=20
&gt; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp; =
|&nbsp;&nbsp;=20
|&nbsp;&nbsp; :&nbsp; |&nbsp;&nbsp; | |L5| |Control<BR>&gt; &gt;=20
---+-----+-----+--&nbsp;&nbsp;&nbsp;&nbsp; ---+--&nbsp;&nbsp;&nbsp; =
|&nbsp;=20
--&nbsp; =
|Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :<BR>&gt; &gt;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :<BR>&gt; &gt;=20
|----------------+-----+-----+----------+------+---+--+-Data<BR>&gt; =
&gt;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp;=20
|Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp; :<BR>&gt; &gt;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt; &gt;=20
----|P1|--------|P3|-------|P4|-----+-|P5|-+-&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
-- \&nbsp;&nbsp; :<BR>&gt; &gt; /=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\ --<BR>&gt; &gt;=20
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&gt; &gt;=20
|P2|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
-- Pn is a<BR>&gt; &gt; physical (bearer/data/transport plane) node.Rn =
is a=20
control plane<BR>&gt; &gt; "router"Ln is a logical control plane entity =
that=20
manages a single<BR>&gt; &gt; physical node. Thus:R3 represents an LSR =
with all=20
components<BR>&gt; &gt; collocated.R2 shows how the "router" component =
may be=20
disjoint from<BR>&gt; &gt; the switchR1 shows how a single "router" may =
manage=20
multiple switches<BR>&gt; &gt; If you can confirm this generalisation, =
then we=20
can show (or fail to<BR>&gt; &gt; show)A. That this is a requirementB. =
That this=20
can be achieved using<BR>&gt; &gt; existing protocols&nbsp; =
Cheers,Adrian. PS.=20
Those not familiar with GSMP<BR>&gt; &gt; may want to take a quick peak. =
-----=20
Original Message -----From: "Don<BR>&gt; &gt; Fedyk" &lt;</FONT><A=20
href=3D"mailto:[e-mail]>To"><FONT face=3DCourier=20
size=3D2>[e-mail]&gt;To</FONT></A><FONT face=3DCourier =

size=3D2>:<BR>&gt; &gt; &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =

size=3D2>&gt;; "Ong, Lyndon" &lt;</FONT><A =
href=3D"mailto:[e-mail]>Cc"><FONT=20
face=3DCourier size=3D2>[e-mail]&gt;Cc</FONT></A><FONT =
face=3DCourier=20
size=3D2>:<BR>&gt; &gt; "Adrian Farrel" &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;; "Brungard,=20
Deborah A, ALABS"<BR>&gt; &gt; &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[e-mail]>Sent"><FONT face=3DCourier=20
size=3D2>[e-mail]&gt;Sent</FONT></A><FONT face=3DCourier =
size=3D2>: Tuesday,=20
March 16, 2004<BR>&gt; &gt; 7:34 PMSubject: RE: ason-routing-reqts: =
issue 2=20
architecture &gt; Dimitri<BR>&gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; =
&gt; If=20
you are saying the real or logical node id that is associated<BR>&gt; =
&gt; with=20
the<BR>&gt; &gt; &gt; Data (bearer) plane should be unique? I would say=20
yes.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; If you are saying could it be =
IP=20
address format? I would say yes.<BR>&gt; &gt; (Note the<BR>&gt; &gt; =
&gt; link=20
identifiers in IP address format are unique only with respect<BR>&gt; =
&gt; to=20
the<BR>&gt; &gt; &gt; node id).<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; But =
if you=20
say Should it then follow each piece of equipment has<BR>&gt; &gt;=20
knowledge<BR>&gt; &gt; &gt; of this IP address format that is assigned =
to it? I=20
would say no<BR>&gt; &gt; because<BR>&gt; &gt; &gt; there is equipment =
that=20
won't have this for some time. (A<BR>&gt; &gt; requirement I<BR>&gt; =
&gt; &gt;=20
understand from ASON).<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; So what I =
believe you=20
are left with is some bearer equipment which<BR>&gt; &gt; has TE<BR>&gt; =
&gt;=20
&gt; resources (a node Identifier (non-IP) and link identifiers<BR>&gt; =
&gt;=20
(non-IP)). This<BR>&gt; &gt; &gt; equipment is known by its native =
identifiers=20
to the entity in the<BR>&gt; &gt; control<BR>&gt; &gt; &gt; plane which =
can=20
assign: IP format identifiers to the equipment<BR>&gt; &gt; (through=20
some<BR>&gt; &gt; &gt; means) and an unique node identifier. This can =
then be=20
advertised on<BR>&gt; &gt; its<BR>&gt; &gt; &gt; behalf as a GMPLS =
compatible TE=20
LSA.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; This does create some =
challenges but in=20
reality I think many devices<BR>&gt; &gt; are<BR>&gt; &gt; &gt; known by =
more=20
than one name. (Look at VoIP, devices they have 2<BR>&gt; &gt;=20
identifiers<BR>&gt; &gt; &gt; E.164 and IP. I personally never use my IP =
address=20
to make a VoIP<BR>&gt; &gt; phone call<BR>&gt; &gt; &gt; but I know that =
it is=20
routed to a IP address along the way that is<BR>&gt; &gt; hidden<BR>&gt; =
&gt;=20
&gt; from me.)<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; I tend to agree with =
Lyndon=20
that Topology is derived from TE<BR>&gt; &gt; advertisements.<BR>&gt; =
&gt; &gt;=20
I don't understand what you could do without a unique logical =
node<BR>&gt; &gt;=20
&gt; associated with the TE links.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;=20
Don<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; -----Original =
Message-----<BR>&gt;=20
&gt; &gt; &gt; From: </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT =
face=3DCourier=20
size=3D2>&gt; &gt; &gt; &gt; =
[mailto:[e-mail]]<BR>&gt;=20
&gt; &gt; &gt; Sent: Tuesday, March 16, 2004 1:48 PM<BR>&gt; &gt; &gt; =
&gt; To:=20
Ong, Lyndon<BR>&gt; &gt; &gt; &gt; Cc: Fedyk, Don [BL60:1A00:EXCH]; =
Adrian=20
Farrel; Brungard,<BR>&gt; &gt; &gt; &gt; Deborah A, ALABS; </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; &gt; &gt;=20
&gt; Subject: Re: ason-routing-reqts: issue 2 architecture<BR>&gt; &gt; =
&gt;=20
&gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; the problem is not an =
issue=20
of being cleaner, the issue<BR>&gt; &gt; &gt; &gt; is once the following =

assumption is taken (which is the<BR>&gt; &gt; &gt; &gt; logical =
consequence of=20
rfc 3630 in the gmpls context)<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; =
&gt; "a=20
stable IP address of the control plane entity that<BR>&gt; &gt; &gt; =
&gt;=20
manages the resources on behalf of the data plane<BR>&gt; &gt; &gt; &gt; =
entity=20
whose resources are being advertised."<BR>&gt; &gt; &gt; &gt;<BR>&gt; =
&gt; &gt;=20
&gt; can we assume that wrt to this stable IP address the<BR>&gt; &gt; =
&gt; &gt;=20
resource identification will be unique (throughout<BR>&gt; &gt; &gt; =
&gt; these=20
multiple data plane entities) and in this case<BR>&gt; &gt; &gt; &gt; it =
holds=20
(no additional level of indirection needed),<BR>&gt; &gt; &gt; &gt; or =
not (i.e.=20
you will find duplicated id space values<BR>&gt; &gt; &gt; &gt; and then =
an=20
additional level of indirection is needed)<BR>&gt; &gt; &gt; =
&gt;<BR>&gt; &gt;=20
&gt; &gt; the problem of the design team was not define the =
issue<BR>&gt; &gt;=20
&gt; &gt; but to find enough arguments wrt to the operational<BR>&gt; =
&gt; &gt;=20
&gt; practices (ie user community) in order to close this<BR>&gt; &gt; =
&gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; thanks,<BR>&gt; &gt; &gt; &gt; - =
dimitri.<BR>&gt;=20
&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Ong, Lyndon wrote:<BR>&gt; &gt; =
&gt; &gt;=20
&gt; I had the same assumption as Don, that the RFC treats the<BR>&gt; =
&gt; &gt;=20
&gt; advertising<BR>&gt; &gt; &gt; &gt; &gt; router and the bearer plane =
node as=20
the same. It would be<BR>&gt; &gt; &gt; &gt; cleaner if<BR>&gt; &gt; =
&gt; &gt;=20
&gt; there was also a bearer plane node identifier in the<BR>&gt; &gt;=20
advertisement.<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt;=20
Cheers,<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; =
Lyndon<BR>&gt;=20
&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; -----Original=20
Message-----<BR>&gt; &gt; &gt; &gt; &gt; From: Don Fedyk=20
[mailto:[e-mail]]<BR>&gt; &gt; &gt; &gt; &gt; Sent: =
Tuesday,=20
March 16, 2004 9:56 AM<BR>&gt; &gt; &gt; &gt; &gt; To: Adrian Farrel; =
Brungard,=20
Deborah A, ALABS;<BR>&gt; &gt; </FONT><A =
href=3D"mailto:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</FONT></A><BR><FONT =
face=3DCourier=20
size=3D2>&gt; &gt; &gt; &gt; &gt; Subject: RE: ason-routing-reqts: issue =
2=20
architecture<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; =
&gt;<BR>&gt;=20
&gt; &gt; &gt; &gt; Hi Adrian<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; =
&gt; &gt;=20
&gt; See Comments Below,<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; =
&gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; &gt;&gt;-----Original Message-----<BR>&gt; =
&gt; &gt;=20
&gt; &gt;&gt;From: Adrian Farrel [mailto:[e-mail]]<BR>&gt; =
&gt; &gt;=20
&gt; &gt;&gt;Sent: Monday, March 15, 2004 4:18 PM<BR>&gt; &gt; &gt; &gt; =

&gt;&gt;To: Brungard, Deborah A, ALABS; </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; &gt; &gt;=20
&gt; &gt;&gt;Subject: Re: ason-routing-reqts: issue 2 =
architecture<BR>&gt; &gt;=20
&gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; =
&gt;=20
&gt;&gt;I assume that the desire is to have one control plane =
entity<BR>&gt;=20
&gt; &gt; &gt; &gt;&gt;mange multiple data plane entities (not to have =
one=20
data<BR>&gt; &gt; &gt; &gt; &gt;&gt;plane entity managed by multiple =
control=20
plane entities).<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; =
&gt;<BR>&gt;=20
&gt; &gt; &gt; &gt; I agree.<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; =
&gt; &gt;=20
&gt;&gt;I believe. in this context, it might be helpful to =
separate<BR>&gt; &gt;=20
&gt; &gt; &gt;&gt;the signaling function (and the associated routing=20
function<BR>&gt; &gt; &gt; &gt; &gt;&gt;for the delivery of the =
signaling=20
messages) from the TE<BR>&gt; &gt; &gt; &gt; &gt;&gt;advertisement =
routing=20
function. Since we are discussing the<BR>&gt; &gt; &gt; &gt; =
&gt;&gt;routing=20
requirements (this is the routing DT) can I assume<BR>&gt; &gt; &gt; =
&gt;=20
&gt;&gt;that the discussion is limited to the TE advertisement<BR>&gt; =
&gt; &gt;=20
&gt; &gt;&gt;routing function, with the aim to have one control =
plane<BR>&gt;=20
&gt; &gt; &gt; &gt;&gt;entity advertise the resources on behalf of =
multiple=20
data<BR>&gt; &gt; &gt; &gt; &gt;&gt;plane entities.<BR>&gt; &gt; &gt; =
&gt;=20
&gt;&gt;<BR>&gt; &gt; &gt; &gt; &gt;&gt;If all of the above, why could =
you not=20
simply do this using<BR>&gt; &gt; &gt; &gt; &gt;&gt;RFC3630? The only =
wrinkle=20
might be that the Router Address<BR>&gt; &gt; &gt; &gt; &gt;&gt;TLV is =
described=20
as carrying "a stable IP address of the<BR>&gt; &gt; &gt; &gt;=20
&gt;&gt;advertising router". Clearly, this needs to be interpreted =
as<BR>&gt;=20
&gt; &gt; &gt; &gt;&gt;"a stable IP address of the control plane entity =
that=20
manages<BR>&gt; &gt; &gt; &gt; &gt;&gt;the resources on behalf of the =
data plane=20
entity whose<BR>&gt; &gt; &gt; &gt; &gt;&gt;resources are being=20
advertised."<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; =
&gt;<BR>&gt;=20
&gt; &gt; &gt; &gt; Interesting. I thought that you need a logical node =
id=20
for<BR>&gt; &gt; &gt; &gt; the bearer<BR>&gt; &gt; &gt; &gt; &gt; plane =
as well=20
even though you are only advertising from a single<BR>&gt; &gt;<BR>&gt; =
&gt;=20
&gt; &gt; &gt; entity.&nbsp; In other words, is it not the desire to =
have the=20
TE<BR>&gt; &gt; &gt; &gt; &gt; advertisements contain the same =
information=20
regardless of<BR>&gt; &gt; whether<BR>&gt; &gt; &gt; &gt; &gt; there is =
a one to=20
one correspondence between the nodes in<BR>&gt; &gt; &gt; &gt; control=20
and<BR>&gt; &gt; &gt; &gt; &gt; the data plane or there is a one to many =

relationship? My<BR>&gt; &gt; &gt; &gt; &gt; interpretation of RFC3630 =
is that=20
it assumes the<BR>&gt; &gt; &gt; &gt; advertising router is<BR>&gt; &gt; =
&gt;=20
&gt; &gt; the same as the logical node in the bearer plane that owns =
the<BR>&gt;=20
&gt; &gt; &gt; &gt; resources. If a logical node id was added to =
the<BR>&gt;=20
&gt; &gt; &gt; advertisement for the<BR>&gt; &gt; &gt; &gt; &gt; node=20
terminating the resources when the advertising router<BR>&gt; &gt; &gt; =
&gt; was=20
not the<BR>&gt; &gt; &gt; &gt; &gt; bearer node that owned the resources =
it=20
would be clearer to me.<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; =
&gt; &gt;=20
Don<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; =
&gt;=20
&gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt;&gt;Am I missing something?<BR>&gt; =
&gt;=20
&gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; &gt; &gt;&gt;Adrian<BR>&gt; &gt; =
&gt; &gt;=20
&gt;&gt;<BR>&gt; &gt; &gt; &gt; &gt;&gt;----- Original Message =
-----<BR>&gt;=20
&gt; &gt; &gt; &gt;&gt;From: "Brungard, Deborah A, ALABS" &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;<BR>&gt; &gt;=20
&gt; &gt; &gt;&gt;To: &lt;</FONT><A =
href=3D"mailto:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</FONT></A><FONT =
face=3DCourier=20
size=3D2>&gt;<BR>&gt; &gt; &gt; &gt; &gt;&gt;Sent: Monday, March 15, =
2004 7:43=20
PM<BR>&gt; &gt; &gt; &gt; &gt;&gt;Subject: ason-routing-reqts: issue 2=20
architecture<BR>&gt; &gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; &gt;=20
&gt;&gt;<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; =
&gt;=20
&gt; &gt; </FONT><A =
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf"><FONT=20
face=3DCourier =
size=3D2>ftp://ftp.isi.edu/internet-drafts/draft-ietf</FONT></A><FONT=20
face=3DCourier size=3D2>-&gt;<BR>&gt; &gt; =
ccamp-gmpls-ason-routing-<BR>&gt; &gt;=20
&gt; &gt; &gt; reqts-<BR>&gt; &gt; &gt; &gt; &gt; 02.txt<BR>&gt; &gt; =
&gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; &gt; The second DT issue is on the physical=20
architecture which can be<BR>&gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; =
supported by=20
GMPLS (from the draft):<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; =
&gt; &gt;=20
ASON does not restrict the architecture choices used, either a<BR>&gt; =
&gt; &gt;=20
&gt; &gt; co-located architecture or a physically separated<BR>&gt; &gt; =
&gt;=20
&gt; architecture may be<BR>&gt; &gt; &gt; &gt; &gt; used. Some members =
of the=20
Design Team are concerned that GMPLS's<BR>&gt; &gt;<BR>&gt; &gt; &gt; =
&gt; &gt;=20
concept of the LSR requires a 1-to-1 relationship between the<BR>&gt; =
&gt; &gt;=20
&gt; &gt; transport plane entity and the control plane entity =
(Router).<BR>&gt;=20
&gt; They<BR>&gt; &gt; &gt; &gt; &gt; invite CCAMP input on GMPLS =
capabilities=20
to support multiple<BR>&gt; &gt; &gt; &gt; &gt; architectures i.e. how =
routing=20
protocols would identify the<BR>&gt; &gt; &gt; &gt; transport<BR>&gt; =
&gt; &gt;=20
&gt; &gt; node ID vs. the router or routing controller ID when<BR>&gt; =
&gt; &gt;=20
&gt; scoping Link IDs<BR>&gt; &gt; &gt; &gt; &gt; in a link =
advertisement.=20
Deborah<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; =
&gt;=20
&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; =
&gt;<BR>&gt;=20
&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; --<BR>&gt; &gt; &gt; &gt; =
Papadimitriou=20
Dimitri<BR>&gt; &gt; &gt; &gt; E-mail : </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT =
face=3DCourier=20
size=3D2>&gt; &gt; &gt; &gt; E-mail : </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; &gt;=20
&gt; &gt; Webpage: </FONT><A =
href=3D"http://psg.com/~dpapadimitriou/"><FONT=20
face=3DCourier =
size=3D2>http://psg.com/~dpapadimitriou/</FONT></A><BR><FONT=20
face=3DCourier size=3D2>&gt; &gt; &gt; &gt; Address: Fr. Wellesplein 1, =
B-2018=20
Antwerpen, Belgium<BR>&gt; &gt; &gt; &gt; Phone&nbsp; : +32 3 =
240-8491<BR>&gt;=20
&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;=20
&gt;<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt;=20
-----------------------------------------<BR>&gt;=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<BR>&gt; The=20
information contained in this message may be privileged <BR>&gt; and=20
confidential and protected from disclosure.&nbsp; If the <BR>&gt; reader =
of this=20
message is not the intended recipient, or an <BR>&gt; employee or agent=20
responsible for delivering this message to <BR>&gt; the intended =
recipient, you=20
are hereby notified that any <BR>&gt; reproduction, dissemination or=20
distribution of this <BR>&gt; communication is strictly prohibited. If =
you have=20
received <BR>&gt; this communication in error, please notify us =
immediately by=20
<BR>&gt; replying to the message and deleting it from your =
computer.<BR>&gt;=20
<BR>&gt; Thank you.<BR>&gt; Tellabs<BR>&gt;=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</FONT></BODY></HTML>

------=_NextPart_000_0CBB_01C40BA6.BDBC08B0--




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:31:44 +0000
Message-ID: <0cba01c40ba6$5e1ad530$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Stephen Shew" <[e-mail]>, "'Ong, Lyndon'" <[e-mail]>, <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Subject: Re: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 22:26:53 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CA8_01C40BA5.C84B1650"

This is a multi-part message in MIME format.

------=_NextPart_000_0CA8_01C40BA5.C84B1650
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Seems you are all a bit hung up on the definition of a "router".

Because GMPLS comes from a perspective where an LSR was a router was a =
single bearer plane device you are assuming that the identity advertised =
it the router id. But really the "TE router id" is the physical node id =
(or the logical router id - Ln in my figure).

Stephen has it when he says...

> One instantiation that is possible would be for R1 in Adrian's diagram =
to
> advertise on behalf of each of the P1/P2/P3 nodes, not as one abstract =
node.
> In that case, it would be confusing to scope the P1-P2 link using the =
router
> id of R1.

This is exactly right. And why would you scope the P1-P2 link using the =
router id of R1?
Why not use the node id P1 or the logical router id L1?

Adrian

=20
> >              ------------------     ------   =20
> >             |R1                |   |R2    |  =20
> >             |  --    --    --  |   |  --  |    ------
> >             | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
> >             |  --    --    --  |   |  --  |   |  --  |
> >             |   :     :     :  |   |   :  |   | |L5| |
> > Control      ---+-----+-----+--     ---+--    |  --  |
> > Plane           :     :     :          :      |   :  |
> > ----------------+-----+-----+----------+------+---+--+-
> > Data            :     :     :          :      |   :  |
> > Plane          --     :    --         --      |  --  |
> >           ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
> >                -- \   :  / --         --      |  --  |
> >                    \ -- /                     |      |
> >                     |P2|                       ------
> >                      --
> >=20
> > Pn is a physical (bearer/data/transport plane) node.
> > Rn is a control plane "router"
> > Ln is a logical control plane entity that manages a single
> >    physical node.
> >=20
> > Thus:
> > R3 represents an LSR with all components collocated.
> > R2 shows how the "router" component may be disjoint from
> >    the switch
> > R1 shows how a single "router" may manage multiple switches

------=_NextPart_000_0CA8_01C40BA5.C84B1650
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Seems you are all a bit hung up on =
the definition=20
of a "router".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Because GMPLS comes from a =
perspective where an=20
LSR was a router was a single bearer plane device you are assuming that =
the=20
identity advertised it the router id. But really the "TE router id" is =
the=20
physical node id (or the logical router id - Ln in my =
figure).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Stephen has it when he =
says...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; One instantiation that is =
possible would be=20
for R1 in Adrian's diagram to<BR>&gt; advertise on behalf of each of the =

P1/P2/P3 nodes, not as one abstract node.<BR>&gt; In that case, it would =
be=20
confusing to scope the P1-P2 link using the router<BR>&gt; id of=20
R1.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>This is exactly right. And why would =
you scope=20
the P1-P2 link using the router id of R1?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Why not use the node id P1 or the =
logical router=20
id L1?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
------------------&nbsp;&nbsp;&nbsp;&nbsp; ------&nbsp;&nbsp;&nbsp; =
<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp; |R2&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; <BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
|&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; |&nbsp;&nbsp; =
|&nbsp;=20
--&nbsp; |&nbsp;&nbsp;&nbsp; ------<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; |=20
|L1|&nbsp; |L2|&nbsp; |L3| |&nbsp;&nbsp; | |L4| |&nbsp;&nbsp;=20
|R3&nbsp;&nbsp;&nbsp; |<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
|&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; |&nbsp;&nbsp; =
|&nbsp;=20
--&nbsp; |&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
|&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;=20
|&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |&nbsp;&nbsp; | |L5| |<BR>&gt; &gt;=20
Control&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
---+-----+-----+--&nbsp;&nbsp;&nbsp;&nbsp;=20
---+--&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt; &gt;=20
Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |<BR>&gt; &gt;=20
----------------+-----+-----+----------+------+---+--+-<BR>&gt; &gt;=20
Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |<BR>&gt; &gt;=20
Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
----|P1|--------|P3|-------|P4|-----+-|P5|-+-<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
-- \&nbsp;&nbsp; :&nbsp; / =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\ --=20
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|P2|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
------<BR>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--<BR>&gt; &gt; <BR>&gt; &gt; Pn is a physical (bearer/data/transport =
plane)=20
node.<BR>&gt; &gt; Rn is a control plane "router"<BR>&gt; &gt; Ln is a =
logical=20
control plane entity that manages a single<BR>&gt; =
&gt;&nbsp;&nbsp;&nbsp;=20
physical node.<BR>&gt; &gt; <BR>&gt; &gt; Thus:<BR>&gt; &gt; R3 =
represents an=20
LSR with all components collocated.<BR>&gt; &gt; R2 shows how the =
"router"=20
component may be disjoint from<BR>&gt; &gt;&nbsp;&nbsp;&nbsp; the =
switch<BR>&gt;=20
&gt; R1 shows how a single "router" may manage multiple=20
switches<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0CA8_01C40BA5.C84B1650--




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:20:55 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Vishal Sharma' <[e-mail]>, [e-mail],  Adrian Farrel <[e-mail]>
Cc: Don Fedyk <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 14:20:03 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Vishal, Adrian,

Maybe I am misinterpreting Adrian's figure.  If it is possible
to advertise from R1 that P1/P2/P3 are separate nodes with 
links in-between, then that would I think be satisfactory.

It was my belief (and maybe Don's as well) that to do this
you needed to include node IDs for P1/P2/P3 in addition to
R1 as the router address.  

Sorry about using some poor terminology...

Cheers,

Lyndon

-----Original Message-----
From: Vishal Sharma [mailto:[e-mail]]
Sent: Tuesday, March 16, 2004 2:11 PM
To: Ong, Lyndon; [e-mail]; Adrian Farrel
Cc: Don Fedyk; Brungard, Deborah A, ALABS; [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture


Adrian, Lyndon,

Adrian, based on what I've been following of the discussions, I think
your figure is right on target, and captures the various scenarios
that people were discussing (in abstraction) so far.

Lyndon, with respect to your email below, is it true that if
R1 is the control plane entity responsible for P1/P2/P3 that it
must necessarily advertize them as an abstract node?

(I thought we were distinguishing between data-plane nodes and nodes
in the control plane that manage them, but am not sure if this
implies the above.)

Also, not sure I understand what is meant by "advertise P1/P2/P3
directly"?
Which entity would do such a direct advertizement? Wouldn't it be
R1, if it was the control plane entity responsible for P1/P2/P3?
(Which would I guess be possible only if the abstract node advertizement
was not a requirement.)

Thanks,
-Vishal


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Ong, Lyndon
> Sent: Tuesday, March 16, 2004 1:37 PM
> To: '[e-mail]'; Adrian Farrel
> Cc: Don Fedyk; Brungard, Deborah A, ALABS; [e-mail]
> Subject: RE: ason-routing-reqts: issue 2 architecture
>
>
> Hi Guys,
>
> R1 was what I was referring to in my side note: it is
> possible to treat P1/P2/P3 as separate
> interfaces on a single abstract node, but you lose
> information about the physical topology and
> connectivity of the nodes.  Also, this puts a
> constraint on the allocation of interface IDs across
> multiple nodes.
>
> Would it not be simpler and more straightforward to
> advertise P1/P2/P3 directly?
>
> Cheers,
>
> Lyndon
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 12:58 PM
> To: Adrian Farrel
> Cc: Don Fedyk; Ong, Lyndon; Brungard, Deborah A, ALABS;
> [e-mail]
> Subject: Re: ason-routing-reqts: issue 2 architecture
>
>
> adrian,
>
> yes, it reproduces the three cases, i had in mind over this
> discussion
>
> see in-line:
>
> > All,
> > Does the following picture capture what we want to achieve?
> >
> >
> >              ------------------     ------
> >             |R1                |   |R2    |
> >             |  --    --    --  |   |  --  |    ------
> >             | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
> >             |  --    --    --  |   |  --  |   |  --  |
> >             |   :     :     :  |   |   :  |   | |L5| |
> > Control      ---+-----+-----+--     ---+--    |  --  |
> > Plane           :     :     :          :      |   :  |
> > ----------------+-----+-----+----------+------+---+--+-
> > Data            :     :     :          :      |   :  |
> > Plane          --     :    --         --      |  --  |
> >           ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
> >                -- \   :  / --         --      |  --  |
> >                    \ -- /                     |      |
> >                     |P2|                       ------
> >                      --
> >
> > Pn is a physical (bearer/data/transport plane) node.
> > Rn is a control plane "router"
> > Ln is a logical control plane entity that manages a single
> >    physical node.
> >
> > Thus:
> > R3 represents an LSR with all components collocated.
> > R2 shows how the "router" component may be disjoint from
> >    the switch
> > R1 shows how a single "router" may manage multiple switches
> >
> > If you can confirm this generalisation, then we can show (or
> fail to show)
> > A. That this is a requirement
>
> to support all them yes (i think that from a protocol
> capability perspective it is advisable)
>
> > B. That this can be achieved using existing protocols
>
> there is no difference between R2 and R3 since the DP
> to CP interactions were never part of the GMPLS routing
> discussions:
> - R2 <- Router_Address, R3 <- Router_Address
> - If_Id assigned to each interface
>
> for R1 (externally since representing an abstract node):
> - R1 <- Router_Address
> - If_Id assigned to each interface (with a value space
>    common to P1, P2 and P3)
>
> for R1 if there is a need to cover also the internal
> (abstract node) links (is that the case?), in such a
> case, the Link_Id sub-TLV value should be discussed
>
> > Cheers,
> > Adrian.
> >
> > PS. Those not familiar with GSMP may want to take a quick peak.
> >
> > ----- Original Message -----
> > From: "Don Fedyk" <[e-mail]>
> > To: <[e-mail]>; "Ong, Lyndon" <[e-mail]>
> > Cc: "Adrian Farrel" <[e-mail]>; "Brungard, Deborah
> A, ALABS" <[e-mail]>; <[e-mail]>
> > Sent: Tuesday, March 16, 2004 7:34 PM
> > Subject: RE: ason-routing-reqts: issue 2 architecture
> >
> >
> >
> >>Dimitri
> >>
> >>If you are saying the real or logical node id that is
> associated with the
> >>Data (bearer) plane should be unique? I would say yes.
> >>
> >>If you are saying could it be IP address format? I would say
> yes. (Note the
> >>link identifiers in IP address format are unique only with
> respect to the
> >>node id).
> >>
> >>But if you say Should it then follow each piece of equipment
> has knowledge
> >>of this IP address format that is assigned to it? I would say no because
> >>there is equipment that won't have this for some time. (A requirement I
> >>understand from ASON).
> >>
> >>So what I believe you are left with is some bearer equipment
> which has TE
> >>resources (a node Identifier (non-IP) and link identifiers
> (non-IP)). This
> >>equipment is known by its native identifiers to the entity in
> the control
> >>plane which can assign: IP format identifiers to the equipment
> (through some
> >>means) and an unique node identifier. This can then be advertised on its
> >>behalf as a GMPLS compatible TE LSA.
> >>
> >>This does create some challenges but in reality I think many devices are
> >>known by more than one name. (Look at VoIP, devices they have 2
> identifiers
> >>E.164 and IP. I personally never use my IP address to make a
> VoIP phone call
> >>but I know that it is routed to a IP address along the way that
> is hidden
> >>from me.)
> >>
> >>I tend to agree with Lyndon that Topology is derived from TE
> advertisements.
> >>I don't understand what you could do without a unique logical node
> >>associated with the TE links.
> >>
> >>Don
> >>
> >>
> >>>-----Original Message-----
> >>>From: [e-mail]
> >>>[mailto:[e-mail]]
> >>>Sent: Tuesday, March 16, 2004 1:48 PM
> >>>To: Ong, Lyndon
> >>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard,
> >>>Deborah A, ALABS; [e-mail]
> >>>Subject: Re: ason-routing-reqts: issue 2 architecture
> >>>
> >>>
> >>>the problem is not an issue of being cleaner, the issue
> >>>is once the following assumption is taken (which is the
> >>>logical consequence of rfc 3630 in the gmpls context)
> >>>
> >>>"a stable IP address of the control plane entity that
> >>>manages the resources on behalf of the data plane
> >>>entity whose resources are being advertised."
> >>>
> >>>can we assume that wrt to this stable IP address the
> >>>resource identification will be unique (throughout
> >>>these multiple data plane entities) and in this case
> >>>it holds (no additional level of indirection needed),
> >>>or not (i.e. you will find duplicated id space values
> >>>and then an additional level of indirection is needed)
> >>>
> >>>the problem of the design team was not define the issue
> >>>but to find enough arguments wrt to the operational
> >>>practices (ie user community) in order to close this
> >>>
> >>>thanks,
> >>>- dimitri.
> >>>
> >>>Ong, Lyndon wrote:
> >>>
> >>>>I had the same assumption as Don, that the RFC treats the
> >>>
> >>>advertising
> >>>
> >>>>router and the bearer plane node as the same. It would be
> >>>
> >>>cleaner if
> >>>
> >>>>there was also a bearer plane node identifier in the advertisement.
> >>>>
> >>>>Cheers,
> >>>>
> >>>>Lyndon
> >>>>
> >>>>-----Original Message-----
> >>>>From: Don Fedyk [mailto:[e-mail]]
> >>>>Sent: Tuesday, March 16, 2004 9:56 AM
> >>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> >>>>Subject: RE: ason-routing-reqts: issue 2 architecture
> >>>>
> >>>>
> >>>>Hi Adrian
> >>>>
> >>>>See Comments Below,
> >>>>
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Adrian Farrel [mailto:[e-mail]]
> >>>>>Sent: Monday, March 15, 2004 4:18 PM
> >>>>>To: Brungard, Deborah A, ALABS; [e-mail]
> >>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
> >>>>>
> >>>>>
> >>>>>I assume that the desire is to have one control plane entity
> >>>>>mange multiple data plane entities (not to have one data
> >>>>>plane entity managed by multiple control plane entities).
> >>>>
> >>>>
> >>>>I agree.
> >>>>
> >>>>
> >>>>>I believe. in this context, it might be helpful to separate
> >>>>>the signaling function (and the associated routing function
> >>>>>for the delivery of the signaling messages) from the TE
> >>>>>advertisement routing function. Since we are discussing the
> >>>>>routing requirements (this is the routing DT) can I assume
> >>>>>that the discussion is limited to the TE advertisement
> >>>>>routing function, with the aim to have one control plane
> >>>>>entity advertise the resources on behalf of multiple data
> >>>>>plane entities.
> >>>>>
> >>>>>If all of the above, why could you not simply do this using
> >>>>>RFC3630? The only wrinkle might be that the Router Address
> >>>>>TLV is described as carrying "a stable IP address of the
> >>>>>advertising router". Clearly, this needs to be interpreted as
> >>>>>"a stable IP address of the control plane entity that manages
> >>>>>the resources on behalf of the data plane entity whose
> >>>>>resources are being advertised."
> >>>>
> >>>>
> >>>>Interesting. I thought that you need a logical node id for
> >>>
> >>>the bearer
> >>>
> >>>>plane as well even though you are only advertising from a single
> >>>>entity.  In other words, is it not the desire to have the TE
> >>>>advertisements contain the same information regardless of whether
> >>>>there is a one to one correspondence between the nodes in
> >>>
> >>>control and
> >>>
> >>>>the data plane or there is a one to many relationship? My
> >>>>interpretation of RFC3630 is that it assumes the
> >>>
> >>>advertising router is
> >>>
> >>>>the same as the logical node in the bearer plane that owns the
> >>>>resources. If a logical node id was added to the
> >>>
> >>>advertisement for the
> >>>
> >>>>node terminating the resources when the advertising router
> >>>
> >>>was not the
> >>>
> >>>>bearer node that owned the resources it would be clearer to me.
> >>>>
> >>>>Don
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Am I missing something?
> >>>>>
> >>>>>Adrian
> >>>>>
> >>>>>----- Original Message -----
> >>>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> >>>>>To: <[e-mail]>
> >>>>>Sent: Monday, March 15, 2004 7:43 PM
> >>>>>Subject: ason-routing-reqts: issue 2 architecture
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>ftp://ftp.isi.edu/internet-drafts/draft-ietf->
> ccamp-gmpls-ason-routing-
> >>>
> >>>>reqts-
> >>>>02.txt
> >>>>
> >>>>The second DT issue is on the physical architecture which can be
> >>>>supported by GMPLS (from the draft):
> >>>>
> >>>>ASON does not restrict the architecture choices used, either a
> >>>>co-located architecture or a physically separated
> >>>
> >>>architecture may be
> >>>
> >>>>used. Some members of the Design Team are concerned that GMPLS's
> >>>>concept of the LSR requires a 1-to-1 relationship between the
> >>>>transport plane entity and the control plane entity (Router). They
> >>>>invite CCAMP input on GMPLS capabilities to support multiple
> >>>>architectures i.e. how routing protocols would identify the
> >>>
> >>>transport
> >>>
> >>>>node ID vs. the router or routing controller ID when
> >>>
> >>>scoping Link IDs
> >>>
> >>>>in a link advertisement. Deborah
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>--
> >>>Papadimitriou Dimitri
> >>>E-mail : [e-mail]
> >>>E-mail : [e-mail]
> >>>Webpage: http://psg.com/~dpapadimitriou/
> >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >>>Phone  : [phone]
> >>>
> >>>
> >>
> >
>
> --
> Papadimitriou Dimitri
> E-mail : [e-mail]
> E-mail : [e-mail]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : [phone]



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:11: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: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 16:10:54 -0600
Message-ID: <[e-mail]>
Thread-Topic: ason-routing-reqts: issue 2 architecture
Thread-Index: AcQLjvkx0+jObYAyTpu3nTxU1jM3HAAA1PzA
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Don Fedyk" <[e-mail]>, <[e-mail]>, "Ong, Lyndon" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi Don,

The different terminology used in ITU/IETF may be what is causing =
confusion. This issue is not on how a control plane entity identifies =
it's own associated data plane resources. The question is what does a =
control plane entity (via I-NNI, E-NNI, UNI) "need to know" (to =
identify) of another control plane entity's resources? Here the example =
is on the "need to know" if multiple physical nodes are supported, =
others have suggested identifying physical locations, bays, individual =
circuit packs.

A key ASON requirement has been for the control plane to provide a =
logical abstraction of the physical resources (e.g. to "hide" internal =
physical implementations of a carrier, to support scalability, etc). If =
choose to use physical node ids for TEs, then this will always be the =
overriding constraint. Example, what if I want to bundle some resources =
of one node with another node for TE advertisement? We've had this =
limitation with management plane addressing, and only with the newer =
management models (Corba) are getting past it. Let's not go backwards.

Looking at the email activity, I see Adrian is also seeing this =
confusion, and has provided an example clarifying if we are discussing =
internal interfaces/GSMP or routing interfaces.

Deborah







-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Don Fedyk
Sent: Tuesday, March 16, 2004 2:35 PM
To: [e-mail]; Ong, Lyndon
Cc: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture


Dimitri

If you are saying the real or logical node id that is associated with =
the
Data (bearer) plane should be unique? I would say yes.=20

If you are saying could it be IP address format? I would say yes. (Note =
the
link identifiers in IP address format are unique only with respect to =
the
node id).

But if you say Should it then follow each piece of equipment has =
knowledge
of this IP address format that is assigned to it? I would say no because
there is equipment that won't have this for some time. (A requirement I
understand from ASON).  =20

So what I believe you are left with is some bearer equipment which has =
TE
resources (a node Identifier (non-IP) and link identifiers (non-IP)). =
This
equipment is known by its native identifiers to the entity in the =
control
plane which can assign: IP format identifiers to the equipment (through =
some
means) and an unique node identifier. This can then be advertised on its
behalf as a GMPLS compatible TE LSA.=20

This does create some challenges but in reality I think many devices are
known by more than one name. (Look at VoIP, devices they have 2 =
identifiers
E.164 and IP. I personally never use my IP address to make a VoIP phone =
call
but I know that it is routed to a IP address along the way that is =
hidden
from me.)

I tend to agree with Lyndon that Topology is derived from TE =
advertisements.
I don't understand what you could do without a unique logical node
associated with the TE links.=20

Don=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]]=20
> Sent: Tuesday, March 16, 2004 1:48 PM
> To: Ong, Lyndon
> Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard,=20
> Deborah A, ALABS; [e-mail]
> Subject: Re: ason-routing-reqts: issue 2 architecture
>=20
>=20
> the problem is not an issue of being cleaner, the issue
> is once the following assumption is taken (which is the
> logical consequence of rfc 3630 in the gmpls context)
>=20
> "a stable IP address of the control plane entity that
> manages the resources on behalf of the data plane
> entity whose resources are being advertised."
>=20
> can we assume that wrt to this stable IP address the
> resource identification will be unique (throughout
> these multiple data plane entities) and in this case
> it holds (no additional level of indirection needed),
> or not (i.e. you will find duplicated id space values
> and then an additional level of indirection is needed)
>=20
> the problem of the design team was not define the issue
> but to find enough arguments wrt to the operational
> practices (ie user community) in order to close this
>=20
> thanks,
> - dimitri.
>=20
> Ong, Lyndon wrote:
> > I had the same assumption as Don, that the RFC treats the=20
> advertising=20
> > router and the bearer plane node as the same. It would be=20
> cleaner if=20
> > there was also a bearer plane node identifier in the advertisement.
> >=20
> > Cheers,
> >=20
> > Lyndon
> >=20
> > -----Original Message-----
> > From: Don Fedyk [mailto:[e-mail]]
> > Sent: Tuesday, March 16, 2004 9:56 AM
> > To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> > Subject: RE: ason-routing-reqts: issue 2 architecture
> >=20
> >=20
> > Hi Adrian
> >=20
> > See Comments Below,
> >=20
> >=20
> >>-----Original Message-----
> >>From: Adrian Farrel [mailto:[e-mail]]
> >>Sent: Monday, March 15, 2004 4:18 PM
> >>To: Brungard, Deborah A, ALABS; [e-mail]
> >>Subject: Re: ason-routing-reqts: issue 2 architecture
> >>
> >>
> >>I assume that the desire is to have one control plane entity
> >>mange multiple data plane entities (not to have one data=20
> >>plane entity managed by multiple control plane entities).
> >=20
> >=20
> > I agree.
> >=20
> >>I believe. in this context, it might be helpful to separate
> >>the signaling function (and the associated routing function=20
> >>for the delivery of the signaling messages) from the TE=20
> >>advertisement routing function. Since we are discussing the=20
> >>routing requirements (this is the routing DT) can I assume=20
> >>that the discussion is limited to the TE advertisement=20
> >>routing function, with the aim to have one control plane=20
> >>entity advertise the resources on behalf of multiple data=20
> >>plane entities.
> >>
> >>If all of the above, why could you not simply do this using
> >>RFC3630? The only wrinkle might be that the Router Address=20
> >>TLV is described as carrying "a stable IP address of the=20
> >>advertising router". Clearly, this needs to be interpreted as=20
> >>"a stable IP address of the control plane entity that manages=20
> >>the resources on behalf of the data plane entity whose=20
> >>resources are being advertised."
> >=20
> >=20
> > Interesting. I thought that you need a logical node id for=20
> the bearer=20
> > plane as well even though you are only advertising from a single=20
> > entity.  In other words, is it not the desire to have the TE=20
> > advertisements contain the same information regardless of whether=20
> > there is a one to one correspondence between the nodes in=20
> control and=20
> > the data plane or there is a one to many relationship? My=20
> > interpretation of RFC3630 is that it assumes the=20
> advertising router is=20
> > the same as the logical node in the bearer plane that owns the=20
> > resources. If a logical node id was added to the=20
> advertisement for the=20
> > node terminating the resources when the advertising router=20
> was not the=20
> > bearer node that owned the resources it would be clearer to me.
> >=20
> > Don
> >=20
> >=20
> >=20
> >>Am I missing something?
> >>
> >>Adrian
> >>
> >>----- Original Message -----
> >>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> >>To: <[e-mail]>
> >>Sent: Monday, March 15, 2004 7:43 PM
> >>Subject: ason-routing-reqts: issue 2 architecture
> >>
> >>
> >=20
> >=20
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-> =
ccamp-gmpls-ason-routing-
> > reqts-
> > 02.txt
> >=20
> > The second DT issue is on the physical architecture which can be=20
> > supported by GMPLS (from the draft):
> >=20
> > ASON does not restrict the architecture choices used, either a=20
> > co-located architecture or a physically separated=20
> architecture may be=20
> > used. Some members of the Design Team are concerned that GMPLS's=20
> > concept of the LSR requires a 1-to-1 relationship between the=20
> > transport plane entity and the control plane entity (Router). They=20
> > invite CCAMP input on GMPLS capabilities to support multiple=20
> > architectures i.e. how routing protocols would identify the=20
> transport=20
> > node ID vs. the router or routing controller ID when=20
> scoping Link IDs=20
> > in a link advertisement. Deborah
> >=20
> >=20
> >=20
> >=20
> >=20
>=20
> --=20
> Papadimitriou Dimitri
> E-mail : [e-mail]
> E-mail : [e-mail]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : [phone]
>=20
>=20




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:11:40 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 14:10:52 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian, Lyndon,

Adrian, based on what I've been following of the discussions, I think
your figure is right on target, and captures the various scenarios
that people were discussing (in abstraction) so far.

Lyndon, with respect to your email below, is it true that if
R1 is the control plane entity responsible for P1/P2/P3 that it
must necessarily advertize them as an abstract node?

(I thought we were distinguishing between data-plane nodes and nodes
in the control plane that manage them, but am not sure if this
implies the above.)

Also, not sure I understand what is meant by "advertise P1/P2/P3
directly"?
Which entity would do such a direct advertizement? Wouldn't it be
R1, if it was the control plane entity responsible for P1/P2/P3?
(Which would I guess be possible only if the abstract node advertizement
was not a requirement.)

Thanks,
-Vishal


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Ong, Lyndon
> Sent: Tuesday, March 16, 2004 1:37 PM
> To: '[e-mail]'; Adrian Farrel
> Cc: Don Fedyk; Brungard, Deborah A, ALABS; [e-mail]
> Subject: RE: ason-routing-reqts: issue 2 architecture
>
>
> Hi Guys,
>
> R1 was what I was referring to in my side note: it is
> possible to treat P1/P2/P3 as separate
> interfaces on a single abstract node, but you lose
> information about the physical topology and
> connectivity of the nodes.  Also, this puts a
> constraint on the allocation of interface IDs across
> multiple nodes.
>
> Would it not be simpler and more straightforward to
> advertise P1/P2/P3 directly?
>
> Cheers,
>
> Lyndon
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 12:58 PM
> To: Adrian Farrel
> Cc: Don Fedyk; Ong, Lyndon; Brungard, Deborah A, ALABS;
> [e-mail]
> Subject: Re: ason-routing-reqts: issue 2 architecture
>
>
> adrian,
>
> yes, it reproduces the three cases, i had in mind over this
> discussion
>
> see in-line:
>
> > All,
> > Does the following picture capture what we want to achieve?
> >
> >
> >              ------------------     ------
> >             |R1                |   |R2    |
> >             |  --    --    --  |   |  --  |    ------
> >             | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
> >             |  --    --    --  |   |  --  |   |  --  |
> >             |   :     :     :  |   |   :  |   | |L5| |
> > Control      ---+-----+-----+--     ---+--    |  --  |
> > Plane           :     :     :          :      |   :  |
> > ----------------+-----+-----+----------+------+---+--+-
> > Data            :     :     :          :      |   :  |
> > Plane          --     :    --         --      |  --  |
> >           ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
> >                -- \   :  / --         --      |  --  |
> >                    \ -- /                     |      |
> >                     |P2|                       ------
> >                      --
> >
> > Pn is a physical (bearer/data/transport plane) node.
> > Rn is a control plane "router"
> > Ln is a logical control plane entity that manages a single
> >    physical node.
> >
> > Thus:
> > R3 represents an LSR with all components collocated.
> > R2 shows how the "router" component may be disjoint from
> >    the switch
> > R1 shows how a single "router" may manage multiple switches
> >
> > If you can confirm this generalisation, then we can show (or
> fail to show)
> > A. That this is a requirement
>
> to support all them yes (i think that from a protocol
> capability perspective it is advisable)
>
> > B. That this can be achieved using existing protocols
>
> there is no difference between R2 and R3 since the DP
> to CP interactions were never part of the GMPLS routing
> discussions:
> - R2 <- Router_Address, R3 <- Router_Address
> - If_Id assigned to each interface
>
> for R1 (externally since representing an abstract node):
> - R1 <- Router_Address
> - If_Id assigned to each interface (with a value space
>    common to P1, P2 and P3)
>
> for R1 if there is a need to cover also the internal
> (abstract node) links (is that the case?), in such a
> case, the Link_Id sub-TLV value should be discussed
>
> > Cheers,
> > Adrian.
> >
> > PS. Those not familiar with GSMP may want to take a quick peak.
> >
> > ----- Original Message -----
> > From: "Don Fedyk" <[e-mail]>
> > To: <[e-mail]>; "Ong, Lyndon" <[e-mail]>
> > Cc: "Adrian Farrel" <[e-mail]>; "Brungard, Deborah
> A, ALABS" <[e-mail]>; <[e-mail]>
> > Sent: Tuesday, March 16, 2004 7:34 PM
> > Subject: RE: ason-routing-reqts: issue 2 architecture
> >
> >
> >
> >>Dimitri
> >>
> >>If you are saying the real or logical node id that is
> associated with the
> >>Data (bearer) plane should be unique? I would say yes.
> >>
> >>If you are saying could it be IP address format? I would say
> yes. (Note the
> >>link identifiers in IP address format are unique only with
> respect to the
> >>node id).
> >>
> >>But if you say Should it then follow each piece of equipment
> has knowledge
> >>of this IP address format that is assigned to it? I would say no because
> >>there is equipment that won't have this for some time. (A requirement I
> >>understand from ASON).
> >>
> >>So what I believe you are left with is some bearer equipment
> which has TE
> >>resources (a node Identifier (non-IP) and link identifiers
> (non-IP)). This
> >>equipment is known by its native identifiers to the entity in
> the control
> >>plane which can assign: IP format identifiers to the equipment
> (through some
> >>means) and an unique node identifier. This can then be advertised on its
> >>behalf as a GMPLS compatible TE LSA.
> >>
> >>This does create some challenges but in reality I think many devices are
> >>known by more than one name. (Look at VoIP, devices they have 2
> identifiers
> >>E.164 and IP. I personally never use my IP address to make a
> VoIP phone call
> >>but I know that it is routed to a IP address along the way that
> is hidden
> >>from me.)
> >>
> >>I tend to agree with Lyndon that Topology is derived from TE
> advertisements.
> >>I don't understand what you could do without a unique logical node
> >>associated with the TE links.
> >>
> >>Don
> >>
> >>
> >>>-----Original Message-----
> >>>From: [e-mail]
> >>>[mailto:[e-mail]]
> >>>Sent: Tuesday, March 16, 2004 1:48 PM
> >>>To: Ong, Lyndon
> >>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard,
> >>>Deborah A, ALABS; [e-mail]
> >>>Subject: Re: ason-routing-reqts: issue 2 architecture
> >>>
> >>>
> >>>the problem is not an issue of being cleaner, the issue
> >>>is once the following assumption is taken (which is the
> >>>logical consequence of rfc 3630 in the gmpls context)
> >>>
> >>>"a stable IP address of the control plane entity that
> >>>manages the resources on behalf of the data plane
> >>>entity whose resources are being advertised."
> >>>
> >>>can we assume that wrt to this stable IP address the
> >>>resource identification will be unique (throughout
> >>>these multiple data plane entities) and in this case
> >>>it holds (no additional level of indirection needed),
> >>>or not (i.e. you will find duplicated id space values
> >>>and then an additional level of indirection is needed)
> >>>
> >>>the problem of the design team was not define the issue
> >>>but to find enough arguments wrt to the operational
> >>>practices (ie user community) in order to close this
> >>>
> >>>thanks,
> >>>- dimitri.
> >>>
> >>>Ong, Lyndon wrote:
> >>>
> >>>>I had the same assumption as Don, that the RFC treats the
> >>>
> >>>advertising
> >>>
> >>>>router and the bearer plane node as the same. It would be
> >>>
> >>>cleaner if
> >>>
> >>>>there was also a bearer plane node identifier in the advertisement.
> >>>>
> >>>>Cheers,
> >>>>
> >>>>Lyndon
> >>>>
> >>>>-----Original Message-----
> >>>>From: Don Fedyk [mailto:[e-mail]]
> >>>>Sent: Tuesday, March 16, 2004 9:56 AM
> >>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> >>>>Subject: RE: ason-routing-reqts: issue 2 architecture
> >>>>
> >>>>
> >>>>Hi Adrian
> >>>>
> >>>>See Comments Below,
> >>>>
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Adrian Farrel [mailto:[e-mail]]
> >>>>>Sent: Monday, March 15, 2004 4:18 PM
> >>>>>To: Brungard, Deborah A, ALABS; [e-mail]
> >>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
> >>>>>
> >>>>>
> >>>>>I assume that the desire is to have one control plane entity
> >>>>>mange multiple data plane entities (not to have one data
> >>>>>plane entity managed by multiple control plane entities).
> >>>>
> >>>>
> >>>>I agree.
> >>>>
> >>>>
> >>>>>I believe. in this context, it might be helpful to separate
> >>>>>the signaling function (and the associated routing function
> >>>>>for the delivery of the signaling messages) from the TE
> >>>>>advertisement routing function. Since we are discussing the
> >>>>>routing requirements (this is the routing DT) can I assume
> >>>>>that the discussion is limited to the TE advertisement
> >>>>>routing function, with the aim to have one control plane
> >>>>>entity advertise the resources on behalf of multiple data
> >>>>>plane entities.
> >>>>>
> >>>>>If all of the above, why could you not simply do this using
> >>>>>RFC3630? The only wrinkle might be that the Router Address
> >>>>>TLV is described as carrying "a stable IP address of the
> >>>>>advertising router". Clearly, this needs to be interpreted as
> >>>>>"a stable IP address of the control plane entity that manages
> >>>>>the resources on behalf of the data plane entity whose
> >>>>>resources are being advertised."
> >>>>
> >>>>
> >>>>Interesting. I thought that you need a logical node id for
> >>>
> >>>the bearer
> >>>
> >>>>plane as well even though you are only advertising from a single
> >>>>entity.  In other words, is it not the desire to have the TE
> >>>>advertisements contain the same information regardless of whether
> >>>>there is a one to one correspondence between the nodes in
> >>>
> >>>control and
> >>>
> >>>>the data plane or there is a one to many relationship? My
> >>>>interpretation of RFC3630 is that it assumes the
> >>>
> >>>advertising router is
> >>>
> >>>>the same as the logical node in the bearer plane that owns the
> >>>>resources. If a logical node id was added to the
> >>>
> >>>advertisement for the
> >>>
> >>>>node terminating the resources when the advertising router
> >>>
> >>>was not the
> >>>
> >>>>bearer node that owned the resources it would be clearer to me.
> >>>>
> >>>>Don
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Am I missing something?
> >>>>>
> >>>>>Adrian
> >>>>>
> >>>>>----- Original Message -----
> >>>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> >>>>>To: <[e-mail]>
> >>>>>Sent: Monday, March 15, 2004 7:43 PM
> >>>>>Subject: ason-routing-reqts: issue 2 architecture
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>ftp://ftp.isi.edu/internet-drafts/draft-ietf->
> ccamp-gmpls-ason-routing-
> >>>
> >>>>reqts-
> >>>>02.txt
> >>>>
> >>>>The second DT issue is on the physical architecture which can be
> >>>>supported by GMPLS (from the draft):
> >>>>
> >>>>ASON does not restrict the architecture choices used, either a
> >>>>co-located architecture or a physically separated
> >>>
> >>>architecture may be
> >>>
> >>>>used. Some members of the Design Team are concerned that GMPLS's
> >>>>concept of the LSR requires a 1-to-1 relationship between the
> >>>>transport plane entity and the control plane entity (Router). They
> >>>>invite CCAMP input on GMPLS capabilities to support multiple
> >>>>architectures i.e. how routing protocols would identify the
> >>>
> >>>transport
> >>>
> >>>>node ID vs. the router or routing controller ID when
> >>>
> >>>scoping Link IDs
> >>>
> >>>>in a link advertisement. Deborah
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>--
> >>>Papadimitriou Dimitri
> >>>E-mail : [e-mail]
> >>>E-mail : [e-mail]
> >>>Webpage: http://psg.com/~dpapadimitriou/
> >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >>>Phone  : [phone]
> >>>
> >>>
> >>
> >
>
> --
> Papadimitriou Dimitri
> E-mail : [e-mail]
> E-mail : [e-mail]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:11:14 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 2004 23:12:15 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: "Ong, Lyndon" <[e-mail]>
Cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 1 addressing
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi lyndon,

> Maybe the issue needs to be worded more clearly...
> 
> Can existing address reachability mechanisms support
> (and if so, how)
> 
> a) distinguishing between the control plane address
> for a client and the data plane address for a client
> which might be two different things?

there is no "data plane" address under discussion here
all entities carried in the control plane are control
plane objects - you may want to reformulate this as
is there any specific need to carry a separate set of
values that translates the reachable end-points ?

i restate that if there was DP addresses to be carried
their mapping should be maintained locally the CP

> b) distinguishing between the internal network address
> space and an external client address space?

and "external reachable end-points" you mix this the
client address space

> c) advertising reachability to a client whose address 
> space is non-IP?

i don't understand, most (if not all) devices we are
discussing here are non-IP terminating devices, how
this differentiates the clients from network nodes
from that perspective ?

> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 11:43 AM
> To: Ong, Lyndon
> Cc: 'Brungard, Deborah A, ALABS'; [e-mail]
> Subject: Re: ason-routing-reqts: issue 1 addressing
> 
> 
> hi lyndon,
> 
> some hints in-line, i start worrying about the arguments
> you've been listed here below since here except (2) they
> are not related to this issue 1:
> 
> Ong, Lyndon wrote:
> 
> 
>>Hi Folks,
>>
>>Let me kick off some discussion on issue 1 by noting some of the 
>>concerns with using existing methods of advertising reachability for
>>this purpose:
>>
>>1) the client system may not be an IP system, but another transport 
>>device with an IP control interface - for example, an ADM (add-drop 
>>multiplexer) acting as a client to an optical network.  Advertising 
>>reachability using normal means might imply that the system can be 
>>used for IP traffic routing.
> 
> 
> -> the SC capability of the end-point is orthogonal to its
>     numbering (in addition, this way of thinking will make us
>     advertising MAC addresses when end-points will terminate
>     Ethernet)
> 
> 
>>2) the client system may use a different addressing space than the 
>>internal network addressing space.  Carriers may wish to use a 
>>different addressing space for administrative or policy reasons.
> 
> 
> -> i don't think there is any discussion here, the thread
>     focuses on "external" reachability - and this is the
>     issue, how this "external" reachability information
>     needs to be advertised to maintain the properties of
>     the control plane (in particular scalability)
> 
> 
>>(Note: one model for this is the VPN model, which would allow private
>>networks to have their own address spaces.  Another model is a
>>telephone number-like model, where clients obtain addresses from a
>>space maintained by the carrier.)
>>
>>3) the client system may use a non-IP address for compatibility 
>>reasons, for example, a client with an existing management plane 
>>address that the carrier wants to access without having to add a new
>>address and translation mechanism.
> 
> 
> -> mapping of MP <-> CP and CP <-> DP are outside the scope
>     of the present discussion, note if your argument was valid,
>     the argument (2) wouldn't since in this case you would
>     have been advertising your management plane addresses
> 
> 
>>Cheers,
>>
>>Lyndon
>>
>>-----Original Message----- From: Brungard, Deborah A, ALABS
>>[mailto:[e-mail]] Sent: Monday, March 15, 2004 11:29 AM To:
>>[e-mail] Subject: ason-routing-reqts: issue 1 addressing
>>
>>
>>As noted in the CCAMP minutes and the DT's presentation, the ASON
>>routing DT had three issues regarding GMPLS support for which they
>>lacked agreement and request support of the WG. The issues are
>>identified in Section 7 (Conclusions) of the draft: 
>>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
>>
>>
>>I will post three separate email threads to cover each issue. The
>>first issue is on address reachability. The following is the text
>>from the draft:
>>
>>Some members of the Design Team noted that reachability information
>>(as described in Section 4.5.3) may be advertised as a set of UNI
>>Transport Resource address prefixes (assigned and selected
>>consistently in their applicability scope). These members of the
>>Design Team raised a concern that existing methods of advertising
>>reachability may need to be examined (on a per-protocol basis) to
>>determine if they are also applicable for UNI Transport Resource
>>addresses. They invite CCAMP discussion on this aspect. Deborah
>>
>>
>>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:10:27 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, Don Fedyk <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 14:09:44 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Dimitri,

I understand, I think, that for processing purposes there may
be an impact to identifying P1/P2/P3 as opposed to R1.
However, isn't the ability to distinguish P1/P2/P3 as
separate physical nodes very important to the routing of
a connection across the network?  It is actually not so
important to know if they are controlled by a single
routing entity or not, except for maintaining the routing
protocol itself.

Cheers,

Lyndon

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Tuesday, March 16, 2004 1:59 PM
To: Ong, Lyndon
Cc: Adrian Farrel; Don Fedyk; Brungard, Deborah A, ALABS;
[e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture


hi lyndon,

the question is not only to be more simpler for R1 (i don't think you 
are more simpler you're just mapping the hierarchy of the abstract node 
within the identification space) it is to so see how it impacts R2 and 
R3, in term of the processing, how it impacts the abstraction level that 
you want to achieve (do external R2 and R3 really care about the way R1 
is performing id assignment) and finally what it brings in terms of 
control plane functionality, arguments like cleaner, or simpler (what 
simple means) are probably not be used in the present context, at the 
end the issue is about practice and relevance

it also clear that if this additional level of indirection is proven to 
be required nothing is said about the way to deliver it while you 
already assumed it must take the form of a node_id (why a node_id ? why 
not a shelve_id ? or a rack_id ?)

thanks,
- dimitri.

Ong, Lyndon wrote:

> Hi Guys,
> 
> R1 was what I was referring to in my side note: it is
> possible to treat P1/P2/P3 as separate
> interfaces on a single abstract node, but you lose
> information about the physical topology and
> connectivity of the nodes.  Also, this puts a 
> constraint on the allocation of interface IDs across
> multiple nodes.  
> 
> Would it not be simpler and more straightforward to
> advertise P1/P2/P3 directly?
> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 12:58 PM
> To: Adrian Farrel
> Cc: Don Fedyk; Ong, Lyndon; Brungard, Deborah A, ALABS;
> [e-mail]
> Subject: Re: ason-routing-reqts: issue 2 architecture
> 
> 
> adrian,
> 
> yes, it reproduces the three cases, i had in mind over this
> discussion
> 
> see in-line:
> 
> 
>>All,
>>Does the following picture capture what we want to achieve?
>>
>>
>>             ------------------     ------    
>>            |R1                |   |R2    |   
>>            |  --    --    --  |   |  --  |    ------
>>            | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
>>            |  --    --    --  |   |  --  |   |  --  |
>>            |   :     :     :  |   |   :  |   | |L5| |
>>Control      ---+-----+-----+--     ---+--    |  --  |
>>Plane           :     :     :          :      |   :  |
>>----------------+-----+-----+----------+------+---+--+-
>>Data            :     :     :          :      |   :  |
>>Plane          --     :    --         --      |  --  |
>>          ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
>>               -- \   :  / --         --      |  --  |
>>                   \ -- /                     |      |
>>                    |P2|                       ------
>>                     --
>>
>>Pn is a physical (bearer/data/transport plane) node.
>>Rn is a control plane "router"
>>Ln is a logical control plane entity that manages a single
>>   physical node.
>>
>>Thus:
>>R3 represents an LSR with all components collocated.
>>R2 shows how the "router" component may be disjoint from
>>   the switch
>>R1 shows how a single "router" may manage multiple switches
>>
>>If you can confirm this generalisation, then we can show (or fail to show)
>>A. That this is a requirement
> 
> 
> to support all them yes (i think that from a protocol
> capability perspective it is advisable)
> 
> 
>>B. That this can be achieved using existing protocols
> 
> 
> there is no difference between R2 and R3 since the DP
> to CP interactions were never part of the GMPLS routing
> discussions:
> - R2 <- Router_Address, R3 <- Router_Address
> - If_Id assigned to each interface
> 
> for R1 (externally since representing an abstract node):
> - R1 <- Router_Address
> - If_Id assigned to each interface (with a value space
>    common to P1, P2 and P3)
> 
> for R1 if there is a need to cover also the internal
> (abstract node) links (is that the case?), in such a
> case, the Link_Id sub-TLV value should be discussed
> 
> 
>>Cheers,
>>Adrian.
>>
>>PS. Those not familiar with GSMP may want to take a quick peak.
>>
>>----- Original Message ----- 
>>From: "Don Fedyk" <[e-mail]>
>>To: <[e-mail]>; "Ong, Lyndon" <[e-mail]>
>>Cc: "Adrian Farrel" <[e-mail]>; "Brungard, Deborah A, ALABS" <[e-mail]>; <[e-mail]>
>>Sent: Tuesday, March 16, 2004 7:34 PM
>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>
>>
>>
>>
>>>Dimitri
>>>
>>>If you are saying the real or logical node id that is associated with the
>>>Data (bearer) plane should be unique? I would say yes. 
>>>
>>>If you are saying could it be IP address format? I would say yes. (Note the
>>>link identifiers in IP address format are unique only with respect to the
>>>node id).
>>>
>>>But if you say Should it then follow each piece of equipment has knowledge
>>>of this IP address format that is assigned to it? I would say no because
>>>there is equipment that won't have this for some time. (A requirement I
>>>understand from ASON).   
>>>
>>>So what I believe you are left with is some bearer equipment which has TE
>>>resources (a node Identifier (non-IP) and link identifiers (non-IP)). This
>>>equipment is known by its native identifiers to the entity in the control
>>>plane which can assign: IP format identifiers to the equipment (through some
>>>means) and an unique node identifier. This can then be advertised on its
>>>behalf as a GMPLS compatible TE LSA. 
>>>
>>>This does create some challenges but in reality I think many devices are
>>>known by more than one name. (Look at VoIP, devices they have 2 identifiers
>>>E.164 and IP. I personally never use my IP address to make a VoIP phone call
>>>but I know that it is routed to a IP address along the way that is hidden
>>
>>>from me.)
>>
>>>I tend to agree with Lyndon that Topology is derived from TE advertisements.
>>>I don't understand what you could do without a unique logical node
>>>associated with the TE links. 
>>>
>>>Don 
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail] 
>>>>[mailto:[e-mail]] 
>>>>Sent: Tuesday, March 16, 2004 1:48 PM
>>>>To: Ong, Lyndon
>>>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, 
>>>>Deborah A, ALABS; [e-mail]
>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>>
>>>>
>>>>the problem is not an issue of being cleaner, the issue
>>>>is once the following assumption is taken (which is the
>>>>logical consequence of rfc 3630 in the gmpls context)
>>>>
>>>>"a stable IP address of the control plane entity that
>>>>manages the resources on behalf of the data plane
>>>>entity whose resources are being advertised."
>>>>
>>>>can we assume that wrt to this stable IP address the
>>>>resource identification will be unique (throughout
>>>>these multiple data plane entities) and in this case
>>>>it holds (no additional level of indirection needed),
>>>>or not (i.e. you will find duplicated id space values
>>>>and then an additional level of indirection is needed)
>>>>
>>>>the problem of the design team was not define the issue
>>>>but to find enough arguments wrt to the operational
>>>>practices (ie user community) in order to close this
>>>>
>>>>thanks,
>>>>- dimitri.
>>>>
>>>>Ong, Lyndon wrote:
>>>>
>>>>
>>>>>I had the same assumption as Don, that the RFC treats the 
>>>>
>>>>advertising 
>>>>
>>>>
>>>>>router and the bearer plane node as the same. It would be 
>>>>
>>>>cleaner if 
>>>>
>>>>
>>>>>there was also a bearer plane node identifier in the advertisement.
>>>>>
>>>>>Cheers,
>>>>>
>>>>>Lyndon
>>>>>
>>>>>-----Original Message-----
>>>>>From: Don Fedyk [mailto:[e-mail]]
>>>>>Sent: Tuesday, March 16, 2004 9:56 AM
>>>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
>>>>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>>>>
>>>>>
>>>>>Hi Adrian
>>>>>
>>>>>See Comments Below,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Adrian Farrel [mailto:[e-mail]]
>>>>>>Sent: Monday, March 15, 2004 4:18 PM
>>>>>>To: Brungard, Deborah A, ALABS; [e-mail]
>>>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>>>>
>>>>>>
>>>>>>I assume that the desire is to have one control plane entity
>>>>>>mange multiple data plane entities (not to have one data 
>>>>>>plane entity managed by multiple control plane entities).
>>>>>
>>>>>
>>>>>I agree.
>>>>>
>>>>>
>>>>>
>>>>>>I believe. in this context, it might be helpful to separate
>>>>>>the signaling function (and the associated routing function 
>>>>>>for the delivery of the signaling messages) from the TE 
>>>>>>advertisement routing function. Since we are discussing the 
>>>>>>routing requirements (this is the routing DT) can I assume 
>>>>>>that the discussion is limited to the TE advertisement 
>>>>>>routing function, with the aim to have one control plane 
>>>>>>entity advertise the resources on behalf of multiple data 
>>>>>>plane entities.
>>>>>>
>>>>>>If all of the above, why could you not simply do this using
>>>>>>RFC3630? The only wrinkle might be that the Router Address 
>>>>>>TLV is described as carrying "a stable IP address of the 
>>>>>>advertising router". Clearly, this needs to be interpreted as 
>>>>>>"a stable IP address of the control plane entity that manages 
>>>>>>the resources on behalf of the data plane entity whose 
>>>>>>resources are being advertised."
>>>>>
>>>>>
>>>>>Interesting. I thought that you need a logical node id for 
>>>>
>>>>the bearer 
>>>>
>>>>
>>>>>plane as well even though you are only advertising from a single 
>>>>>entity.  In other words, is it not the desire to have the TE 
>>>>>advertisements contain the same information regardless of whether 
>>>>>there is a one to one correspondence between the nodes in 
>>>>
>>>>control and 
>>>>
>>>>
>>>>>the data plane or there is a one to many relationship? My 
>>>>>interpretation of RFC3630 is that it assumes the 
>>>>
>>>>advertising router is 
>>>>
>>>>
>>>>>the same as the logical node in the bearer plane that owns the 
>>>>>resources. If a logical node id was added to the 
>>>>
>>>>advertisement for the 
>>>>
>>>>
>>>>>node terminating the resources when the advertising router 
>>>>
>>>>was not the 
>>>>
>>>>
>>>>>bearer node that owned the resources it would be clearer to me.
>>>>>
>>>>>Don
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Am I missing something?
>>>>>>
>>>>>>Adrian
>>>>>>
>>>>>>----- Original Message -----
>>>>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>>>>>To: <[e-mail]>
>>>>>>Sent: Monday, March 15, 2004 7:43 PM
>>>>>>Subject: ason-routing-reqts: issue 2 architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>ftp://ftp.isi.edu/internet-drafts/draft-ietf-> ccamp-gmpls-ason-routing-
>>>>
>>>>
>>>>>reqts-
>>>>>02.txt
>>>>>
>>>>>The second DT issue is on the physical architecture which can be 
>>>>>supported by GMPLS (from the draft):
>>>>>
>>>>>ASON does not restrict the architecture choices used, either a 
>>>>>co-located architecture or a physically separated 
>>>>
>>>>architecture may be 
>>>>
>>>>
>>>>>used. Some members of the Design Team are concerned that GMPLS's 
>>>>>concept of the LSR requires a 1-to-1 relationship between the 
>>>>>transport plane entity and the control plane entity (Router). They 
>>>>>invite CCAMP input on GMPLS capabilities to support multiple 
>>>>>architectures i.e. how routing protocols would identify the 
>>>>
>>>>transport 
>>>>
>>>>
>>>>>node ID vs. the router or routing controller ID when 
>>>>
>>>>scoping Link IDs 
>>>>
>>>>
>>>>>in a link advertisement. Deborah
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>-- 
>>>>Papadimitriou Dimitri
>>>>E-mail : [e-mail]
>>>>E-mail : [e-mail]
>>>>Webpage: http://psg.com/~dpapadimitriou/
>>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>>>Phone  : [phone]
>>>>
>>>>
>>>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:09:06 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 2004 16:08:03 -0600
From: Jonathan Sadler <[e-mail]>
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: Don Fedyk <[e-mail]>, [e-mail], "Ong, Lyndon" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture
Content-Type: multipart/alternative; boundary="------------8DE4C807CEF9D6CD06830578"

--------------8DE4C807CEF9D6CD06830578
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Adrian -

Yes, however it isn't limited to what you have in the picture.  Take the
following picture:

Logical
Topology           +-++
           --------+T1+--------
                   +--+

Physical
Realization

          ---------------   ----   ----
         |R1             | |R2  | |R3  |
         | +-----------+ | |+--+| |+--+|
         | |L1         | | ||L2|| ||L3||
         | +-----------+ | |+--+| |+--+|
         | :     :     : | | :  | | :  |
          -+-----+-----+-   -+--  | :  |
 Control   :     :     :     :    | :  |
 ----------+-----+-----+-----+----+-+--+-------
 Data      :     :     :     :    | :  |
          -+     :     +-    :    | +- |
   ------+P1+---------+P3+--------+|P5|+----
          --     :    /--\   :    | -- |
             \  -+-  /    \  +-  / ----
              \|P2 |/      \|P4|/
                ---          --


L1, L2, and L3 are aware of the topology of P1-P5, and therefore can
progress a signalling request presented to L1 through the nodes, but are
not sharing it with the outside world.  The only topology seen is T1.
The reason for doing this could be due to policy (hiding) or
scalability.  (See draft-ietf-ipo-carrier-requirements for more
explanation on why this is good)

Note here that the Logical topology being advertized (characterized by
Tn) is different from the control plane realization (Ln) as well as the
data plane realization (Pn).  This is possible in the ASON architecure,
as there is no limitation in how a function is realized.

In this case, you wouldn't be able to have separate Router IDs for each
Pn, as the single T1 shown above must use the same Router ID for the
link endpoint names in order make only a single node appear in the
topology.  However, since the resource information for the link
ingressing at P1 as well as the link egressing at P5 are in R1 and R3,
it is problematic to have a single Router ID.

Jonathan Sadler

Adrian Farrel wrote:

> All,Does the following picture capture what we want to
> achieve?               ------------------     ------
> |R1                |   |R2    |            |  --    --    --  |   |
> --  |    ------            | |L1|  |L2|  |L3| |   | |L4| |   |R3
> |            |  --    --    --  |   |  --  |   |  --  |            |
> :     :     :  |   |   :  |   | |L5| |Control
> ---+-----+-----+--     ---+--    |  --  |Plane           :     :
> :          :      |   :
> |----------------+-----+-----+----------+------+---+--+-Data
> :     :     :          :      |   :  |Plane          --     :
> --         --      |  --  |
> ----|P1|--------|P3|-------|P4|-----+-|P5|-+-               -- \   :
> / --         --      |  --  |                   \ --
> /                     |      |
> |P2|                       ------                     -- Pn is a
> physical (bearer/data/transport plane) node.Rn is a control plane
> "router"Ln is a logical control plane entity that manages a single
> physical node. Thus:R3 represents an LSR with all components
> collocated.R2 shows how the "router" component may be disjoint from
> the switchR1 shows how a single "router" may manage multiple switches
> If you can confirm this generalisation, then we can show (or fail to
> show)A. That this is a requirementB. That this can be achieved using
> existing protocols  Cheers,Adrian. PS. Those not familiar with GSMP
> may want to take a quick peak. ----- Original Message -----From: "Don
> Fedyk" <[e-mail]>To:
> <[e-mail]>; "Ong, Lyndon" <[e-mail]>Cc:
> "Adrian Farrel" <[e-mail]>; "Brungard, Deborah A, ALABS"
> <[e-mail]>; <[e-mail]>Sent: Tuesday, March 16, 2004
> 7:34 PMSubject: RE: ason-routing-reqts: issue 2 architecture > Dimitri
>
> >
> > If you are saying the real or logical node id that is associated
> with the
> > Data (bearer) plane should be unique? I would say yes.
> >
> > If you are saying could it be IP address format? I would say yes.
> (Note the
> > link identifiers in IP address format are unique only with respect
> to the
> > node id).
> >
> > But if you say Should it then follow each piece of equipment has
> knowledge
> > of this IP address format that is assigned to it? I would say no
> because
> > there is equipment that won't have this for some time. (A
> requirement I
> > understand from ASON).
> >
> > So what I believe you are left with is some bearer equipment which
> has TE
> > resources (a node Identifier (non-IP) and link identifiers
> (non-IP)). This
> > equipment is known by its native identifiers to the entity in the
> control
> > plane which can assign: IP format identifiers to the equipment
> (through some
> > means) and an unique node identifier. This can then be advertised on
> its
> > behalf as a GMPLS compatible TE LSA.
> >
> > This does create some challenges but in reality I think many devices
> are
> > known by more than one name. (Look at VoIP, devices they have 2
> identifiers
> > E.164 and IP. I personally never use my IP address to make a VoIP
> phone call
> > but I know that it is routed to a IP address along the way that is
> hidden
> > from me.)
> >
> > I tend to agree with Lyndon that Topology is derived from TE
> advertisements.
> > I don't understand what you could do without a unique logical node
> > associated with the TE links.
> >
> > Don
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > Sent: Tuesday, March 16, 2004 1:48 PM
> > > To: Ong, Lyndon
> > > Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard,
> > > Deborah A, ALABS; [e-mail]
> > > Subject: Re: ason-routing-reqts: issue 2 architecture
> > >
> > >
> > > the problem is not an issue of being cleaner, the issue
> > > is once the following assumption is taken (which is the
> > > logical consequence of rfc 3630 in the gmpls context)
> > >
> > > "a stable IP address of the control plane entity that
> > > manages the resources on behalf of the data plane
> > > entity whose resources are being advertised."
> > >
> > > can we assume that wrt to this stable IP address the
> > > resource identification will be unique (throughout
> > > these multiple data plane entities) and in this case
> > > it holds (no additional level of indirection needed),
> > > or not (i.e. you will find duplicated id space values
> > > and then an additional level of indirection is needed)
> > >
> > > the problem of the design team was not define the issue
> > > but to find enough arguments wrt to the operational
> > > practices (ie user community) in order to close this
> > >
> > > thanks,
> > > - dimitri.
> > >
> > > Ong, Lyndon wrote:
> > > > I had the same assumption as Don, that the RFC treats the
> > > advertising
> > > > router and the bearer plane node as the same. It would be
> > > cleaner if
> > > > there was also a bearer plane node identifier in the
> advertisement.
> > > >
> > > > Cheers,
> > > >
> > > > Lyndon
> > > >
> > > > -----Original Message-----
> > > > From: Don Fedyk [mailto:[e-mail]]
> > > > Sent: Tuesday, March 16, 2004 9:56 AM
> > > > To: Adrian Farrel; Brungard, Deborah A, ALABS;
> [e-mail]
> > > > Subject: RE: ason-routing-reqts: issue 2 architecture
> > > >
> > > >
> > > > Hi Adrian
> > > >
> > > > See Comments Below,
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Adrian Farrel [mailto:[e-mail]]
> > > >>Sent: Monday, March 15, 2004 4:18 PM
> > > >>To: Brungard, Deborah A, ALABS; [e-mail]
> > > >>Subject: Re: ason-routing-reqts: issue 2 architecture
> > > >>
> > > >>
> > > >>I assume that the desire is to have one control plane entity
> > > >>mange multiple data plane entities (not to have one data
> > > >>plane entity managed by multiple control plane entities).
> > > >
> > > >
> > > > I agree.
> > > >
> > > >>I believe. in this context, it might be helpful to separate
> > > >>the signaling function (and the associated routing function
> > > >>for the delivery of the signaling messages) from the TE
> > > >>advertisement routing function. Since we are discussing the
> > > >>routing requirements (this is the routing DT) can I assume
> > > >>that the discussion is limited to the TE advertisement
> > > >>routing function, with the aim to have one control plane
> > > >>entity advertise the resources on behalf of multiple data
> > > >>plane entities.
> > > >>
> > > >>If all of the above, why could you not simply do this using
> > > >>RFC3630? The only wrinkle might be that the Router Address
> > > >>TLV is described as carrying "a stable IP address of the
> > > >>advertising router". Clearly, this needs to be interpreted as
> > > >>"a stable IP address of the control plane entity that manages
> > > >>the resources on behalf of the data plane entity whose
> > > >>resources are being advertised."
> > > >
> > > >
> > > > Interesting. I thought that you need a logical node id for
> > > the bearer
> > > > plane as well even though you are only advertising from a single
>
> > > > entity.  In other words, is it not the desire to have the TE
> > > > advertisements contain the same information regardless of
> whether
> > > > there is a one to one correspondence between the nodes in
> > > control and
> > > > the data plane or there is a one to many relationship? My
> > > > interpretation of RFC3630 is that it assumes the
> > > advertising router is
> > > > the same as the logical node in the bearer plane that owns the
> > > > resources. If a logical node id was added to the
> > > advertisement for the
> > > > node terminating the resources when the advertising router
> > > was not the
> > > > bearer node that owned the resources it would be clearer to me.
> > > >
> > > > Don
> > > >
> > > >
> > > >
> > > >>Am I missing something?
> > > >>
> > > >>Adrian
> > > >>
> > > >>----- Original Message -----
> > > >>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> > > >>To: <[e-mail]>
> > > >>Sent: Monday, March 15, 2004 7:43 PM
> > > >>Subject: ason-routing-reqts: issue 2 architecture
> > > >>
> > > >>
> > > >
> > > >
> > > ftp://ftp.isi.edu/internet-drafts/draft-ietf->
> ccamp-gmpls-ason-routing-
> > > > reqts-
> > > > 02.txt
> > > >
> > > > The second DT issue is on the physical architecture which can be
>
> > > > supported by GMPLS (from the draft):
> > > >
> > > > ASON does not restrict the architecture choices used, either a
> > > > co-located architecture or a physically separated
> > > architecture may be
> > > > used. Some members of the Design Team are concerned that GMPLS's
>
> > > > concept of the LSR requires a 1-to-1 relationship between the
> > > > transport plane entity and the control plane entity (Router).
> They
> > > > invite CCAMP input on GMPLS capabilities to support multiple
> > > > architectures i.e. how routing protocols would identify the
> > > transport
> > > > node ID vs. the router or routing controller ID when
> > > scoping Link IDs
> > > > in a link advertisement. Deborah
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : [e-mail]
> > > E-mail : [e-mail]
> > > Webpage: http://psg.com/~dpapadimitriou/
> > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > Phone  : [phone]
> > >
> > >
> >
> >



-----------------------------------------
============================================================
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
============================================================
--------------8DE4C807CEF9D6CD06830578
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

<HTML>
<BODY>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Adrian -</tt>
<p><tt>Yes, however it isn't limited to what you have in the picture.&nbsp;
Take the following picture:</tt>
<p><tt>Logical</tt>
<br><tt>Topology&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-++</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --------+T1+--------</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+--+</tt>
<p><tt>Physical</tt>
<br><tt>Realization</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ---------------&nbsp;&nbsp;
----&nbsp;&nbsp; ----</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |R2&nbsp; | |R3&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | +-----------+
| |+--+| |+--+|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |L1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| | ||L2|| ||L3||</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | +-----------+
| |+--+| |+--+|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | :&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp; : | | :&nbsp; | | :&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -+-----+-----+-&nbsp;&nbsp;
-+--&nbsp; | :&nbsp; |</tt>
<br><tt>&nbsp;Control&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp; | :&nbsp; |</tt>
<br><tt>&nbsp;----------+-----+-----+-----+----+-+--+-------</tt>
<br><tt>&nbsp;Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;
| :&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -+&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp; +-&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp; | +-
|</tt>
<br><tt>&nbsp;&nbsp; ------+P1+---------+P3+--------+|P5|+----</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp; /--\&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp; | -- |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\&nbsp; -+-&nbsp; /&nbsp;&nbsp;&nbsp; \&nbsp; +-&nbsp; / ----</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\|P2 |/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \|P4|/</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
---&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --</tt>
<br>&nbsp;
<p>L1, L2, and L3 are aware of the topology of P1-P5, and therefore can
progress a signalling request presented to L1 through the nodes, but are
not sharing it with the outside world.&nbsp; The only topology seen is
T1.&nbsp; The reason for doing this could be due to policy (hiding) or
scalability.&nbsp; (See draft-ietf-ipo-carrier-requirements for more explanation
on why this is good)
<p>Note here that the Logical topology being advertized (characterized
by Tn) is different from the control plane realization (Ln) as well as
the data plane realization (Pn).&nbsp; This is possible in the ASON architecure,
as there is no limitation in how a function is realized.
<p>In this case, you wouldn't be able to have separate Router IDs for each
Pn, as the single T1 shown above must use the same Router ID for the link
endpoint names in order make only a single node appear in the topology.&nbsp;
However, since the resource information for the link ingressing at P1 as
well as the link egressing at P5 are in R1 and R3, it is problematic to
have a single Router ID.
<p>Jonathan Sadler
<p>Adrian Farrel wrote:
<blockquote TYPE=CITE><style></style>
<font face="Courier"><font size=-1>All,Does
the following picture capture what we want to achieve?</font></font>&nbsp;&nbsp;<font face="Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------------------&nbsp;&nbsp;&nbsp;&nbsp; ------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |R2&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; |&nbsp;&nbsp;
|&nbsp; --&nbsp; |&nbsp;&nbsp;&nbsp; ------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |L1|&nbsp; |L2|&nbsp; |L3| |&nbsp;&nbsp; | |L4| |&nbsp;&nbsp; |R3&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
--&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp; |&nbsp;&nbsp; |&nbsp;
--&nbsp; |&nbsp;&nbsp; |&nbsp; --&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |&nbsp;&nbsp; | |L5| |Control&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
---+-----+-----+--&nbsp;&nbsp;&nbsp;&nbsp; ---+--&nbsp;&nbsp;&nbsp; |&nbsp;
--&nbsp; |Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |----------------+-----+-----+----------+------+---+--+-Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
----|P1|--------|P3|-------|P4|-----+-|P5|-+-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-- \&nbsp;&nbsp; :&nbsp; / --&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\ -- /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|P2|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--</font></font> <font face="Courier"><font size=-1>Pn is a physical (bearer/data/transport
plane) node.Rn is a control plane "router"Ln is a logical control plane
entity that manages a single&nbsp;&nbsp; physical node.</font></font> <font face="Courier"><font size=-1>Thus:R3
represents an LSR with all components collocated.R2 shows how the "router"
component may be disjoint from&nbsp;&nbsp; the switchR1 shows how a single
"router" may manage multiple switches</font></font> <font face="Courier"><font size=-1>If
you can confirm this generalisation, then we can show (or fail to show)A.
That this is a requirementB. That this can be achieved using existing protocols</font></font>&nbsp;
<font face="Courier"><font size=-1>Cheers,Adrian.</font></font> <font face="Courier"><font size=-1>PS.
Those not familiar with GSMP may want to take a quick peak.</font></font>
<font face="Courier"><font size=-1>----- Original Message -----From: "Don
Fedyk" &lt;<a href="mailto:[e-mail]">[e-mail]</a>>To:
&lt;<a href="mailto:[e-mail]">[e-mail]</a>>;
"Ong, Lyndon" &lt;<a href="mailto:[e-mail]">[e-mail]</a>>Cc:
"Adrian Farrel" &lt;<a href="mailto:[e-mail]">[e-mail]</a>>;
"Brungard, Deborah A, ALABS" &lt;<a href="mailto:[e-mail]">[e-mail]</a>>;
&lt;<a href="mailto:[e-mail]">[e-mail]</a>>Sent: Tuesday,
March 16, 2004 7:34 PMSubject: RE: ason-routing-reqts: issue 2 architecture</font></font>
<font face="Courier"><font size=-1>> Dimitri</font></font>
<br><font face="Courier"><font size=-1>></font></font>
<br><font face="Courier"><font size=-1>> If you are saying the real or
logical node id that is associated with the</font></font>
<br><font face="Courier"><font size=-1>> Data (bearer) plane should be
unique? I would say yes.</font></font>
<br><font face="Courier"><font size=-1>></font></font>
<br><font face="Courier"><font size=-1>> If you are saying could it be
IP address format? I would say yes. (Note the</font></font>
<br><font face="Courier"><font size=-1>> link identifiers in IP address
format are unique only with respect to the</font></font>
<br><font face="Courier"><font size=-1>> node id).</font></font>
<br><font face="Courier"><font size=-1>></font></font>
<br><font face="Courier"><font size=-1>> But if you say Should it then
follow each piece of equipment has knowledge</font></font>
<br><font face="Courier"><font size=-1>> of this IP address format that
is assigned to it? I would say no because</font></font>
<br><font face="Courier"><font size=-1>> there is equipment that won't
have this for some time. (A requirement I</font></font>
<br><font face="Courier"><font size=-1>> understand from ASON).</font></font>
<br><font face="Courier"><font size=-1>></font></font>
<br><font face="Courier"><font size=-1>> So what I believe you are left
with is some bearer equipment which has TE</font></font>
<br><font face="Courier"><font size=-1>> resources (a node Identifier (non-IP)
and link identifiers (non-IP)). This</font></font>
<br><font face="Courier"><font size=-1>> equipment is known by its native
identifiers to the entity in the control</font></font>
<br><font face="Courier"><font size=-1>> plane which can assign: IP format
identifiers to the equipment (through some</font></font>
<br><font face="Courier"><font size=-1>> means) and an unique node identifier.
This can then be advertised on its</font></font>
<br><font face="Courier"><font size=-1>> behalf as a GMPLS compatible TE
LSA.</font></font>
<br><font face="Courier"><font size=-1>></font></font>
<br><font face="Courier"><font size=-1>> This does create some challenges
but in reality I think many devices are</font></font>
<br><font face="Courier"><font size=-1>> known by more than one name. (Look
at VoIP, devices they have 2 identifiers</font></font>
<br><font face="Courier"><font size=-1>> E.164 and IP. I personally never
use my IP address to make a VoIP phone call</font></font>
<br><font face="Courier"><font size=-1>> but I know that it is routed to
a IP address along the way that is hidden</font></font>
<br><font face="Courier"><font size=-1>> from me.)</font></font>
<br><font face="Courier"><font size=-1>></font></font>
<br><font face="Courier"><font size=-1>> I tend to agree with Lyndon that
Topology is derived from TE advertisements.</font></font>
<br><font face="Courier"><font size=-1>> I don't understand what you could
do without a unique logical node</font></font>
<br><font face="Courier"><font size=-1>> associated with the TE links.</font></font>
<br><font face="Courier"><font size=-1>></font></font>
<br><font face="Courier"><font size=-1>> Don</font></font>
<br><font face="Courier"><font size=-1>></font></font>
<br><font face="Courier"><font size=-1>> > -----Original Message-----</font></font>
<br><font face="Courier"><font size=-1>> > From: <a href="mailto:[e-mail]">[e-mail]</a></font></font>
<br><font face="Courier"><font size=-1>> > [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</font></font>
<br><font face="Courier"><font size=-1>> > Sent: Tuesday, March 16, 2004
1:48 PM</font></font>
<br><font face="Courier"><font size=-1>> > To: Ong, Lyndon</font></font>
<br><font face="Courier"><font size=-1>> > Cc: Fedyk, Don [BL60:1A00:EXCH];
Adrian Farrel; Brungard,</font></font>
<br><font face="Courier"><font size=-1>> > Deborah A, ALABS; <a href="mailto:[e-mail]">[e-mail]</a></font></font>
<br><font face="Courier"><font size=-1>> > Subject: Re: ason-routing-reqts:
issue 2 architecture</font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>> > the problem is not an issue
of being cleaner, the issue</font></font>
<br><font face="Courier"><font size=-1>> > is once the following assumption
is taken (which is the</font></font>
<br><font face="Courier"><font size=-1>> > logical consequence of rfc 3630
in the gmpls context)</font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>> > "a stable IP address of the
control plane entity that</font></font>
<br><font face="Courier"><font size=-1>> > manages the resources on behalf
of the data plane</font></font>
<br><font face="Courier"><font size=-1>> > entity whose resources are being
advertised."</font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>> > can we assume that wrt to this
stable IP address the</font></font>
<br><font face="Courier"><font size=-1>> > resource identification will
be unique (throughout</font></font>
<br><font face="Courier"><font size=-1>> > these multiple data plane entities)
and in this case</font></font>
<br><font face="Courier"><font size=-1>> > it holds (no additional level
of indirection needed),</font></font>
<br><font face="Courier"><font size=-1>> > or not (i.e. you will find duplicated
id space values</font></font>
<br><font face="Courier"><font size=-1>> > and then an additional level
of indirection is needed)</font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>> > the problem of the design team
was not define the issue</font></font>
<br><font face="Courier"><font size=-1>> > but to find enough arguments
wrt to the operational</font></font>
<br><font face="Courier"><font size=-1>> > practices (ie user community)
in order to close this</font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>> > thanks,</font></font>
<br><font face="Courier"><font size=-1>> > - dimitri.</font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>> > Ong, Lyndon wrote:</font></font>
<br><font face="Courier"><font size=-1>> > > I had the same assumption
as Don, that the RFC treats the</font></font>
<br><font face="Courier"><font size=-1>> > advertising</font></font>
<br><font face="Courier"><font size=-1>> > > router and the bearer plane
node as the same. It would be</font></font>
<br><font face="Courier"><font size=-1>> > cleaner if</font></font>
<br><font face="Courier"><font size=-1>> > > there was also a bearer plane
node identifier in the advertisement.</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > Cheers,</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > Lyndon</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > -----Original Message-----</font></font>
<br><font face="Courier"><font size=-1>> > > From: Don Fedyk [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</font></font>
<br><font face="Courier"><font size=-1>> > > Sent: Tuesday, March 16, 2004
9:56 AM</font></font>
<br><font face="Courier"><font size=-1>> > > To: Adrian Farrel; Brungard,
Deborah A, ALABS; <a href="mailto:[e-mail]">[e-mail]</a></font></font>
<br><font face="Courier"><font size=-1>> > > Subject: RE: ason-routing-reqts:
issue 2 architecture</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > Hi Adrian</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > See Comments Below,</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > >>-----Original Message-----</font></font>
<br><font face="Courier"><font size=-1>> > >>From: Adrian Farrel [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</font></font>
<br><font face="Courier"><font size=-1>> > >>Sent: Monday, March 15, 2004
4:18 PM</font></font>
<br><font face="Courier"><font size=-1>> > >>To: Brungard, Deborah A, ALABS;
<a href="mailto:[e-mail]">[e-mail]</a></font></font>
<br><font face="Courier"><font size=-1>> > >>Subject: Re: ason-routing-reqts:
issue 2 architecture</font></font>
<br><font face="Courier"><font size=-1>> > >></font></font>
<br><font face="Courier"><font size=-1>> > >></font></font>
<br><font face="Courier"><font size=-1>> > >>I assume that the desire is
to have one control plane entity</font></font>
<br><font face="Courier"><font size=-1>> > >>mange multiple data plane
entities (not to have one data</font></font>
<br><font face="Courier"><font size=-1>> > >>plane entity managed by multiple
control plane entities).</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > I agree.</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > >>I believe. in this context,
it might be helpful to separate</font></font>
<br><font face="Courier"><font size=-1>> > >>the signaling function (and
the associated routing function</font></font>
<br><font face="Courier"><font size=-1>> > >>for the delivery of the signaling
messages) from the TE</font></font>
<br><font face="Courier"><font size=-1>> > >>advertisement routing function.
Since we are discussing the</font></font>
<br><font face="Courier"><font size=-1>> > >>routing requirements (this
is the routing DT) can I assume</font></font>
<br><font face="Courier"><font size=-1>> > >>that the discussion is limited
to the TE advertisement</font></font>
<br><font face="Courier"><font size=-1>> > >>routing function, with the
aim to have one control plane</font></font>
<br><font face="Courier"><font size=-1>> > >>entity advertise the resources
on behalf of multiple data</font></font>
<br><font face="Courier"><font size=-1>> > >>plane entities.</font></font>
<br><font face="Courier"><font size=-1>> > >></font></font>
<br><font face="Courier"><font size=-1>> > >>If all of the above, why could
you not simply do this using</font></font>
<br><font face="Courier"><font size=-1>> > >>RFC3630? The only wrinkle
might be that the Router Address</font></font>
<br><font face="Courier"><font size=-1>> > >>TLV is described as carrying
"a stable IP address of the</font></font>
<br><font face="Courier"><font size=-1>> > >>advertising router". Clearly,
this needs to be interpreted as</font></font>
<br><font face="Courier"><font size=-1>> > >>"a stable IP address of the
control plane entity that manages</font></font>
<br><font face="Courier"><font size=-1>> > >>the resources on behalf of
the data plane entity whose</font></font>
<br><font face="Courier"><font size=-1>> > >>resources are being advertised."</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > Interesting. I thought that
you need a logical node id for</font></font>
<br><font face="Courier"><font size=-1>> > the bearer</font></font>
<br><font face="Courier"><font size=-1>> > > plane as well even though
you are only advertising from a single</font></font>
<br><font face="Courier"><font size=-1>> > > entity.&nbsp; In other words,
is it not the desire to have the TE</font></font>
<br><font face="Courier"><font size=-1>> > > advertisements contain the
same information regardless of whether</font></font>
<br><font face="Courier"><font size=-1>> > > there is a one to one correspondence
between the nodes in</font></font>
<br><font face="Courier"><font size=-1>> > control and</font></font>
<br><font face="Courier"><font size=-1>> > > the data plane or there is
a one to many relationship? My</font></font>
<br><font face="Courier"><font size=-1>> > > interpretation of RFC3630
is that it assumes the</font></font>
<br><font face="Courier"><font size=-1>> > advertising router is</font></font>
<br><font face="Courier"><font size=-1>> > > the same as the logical node
in the bearer plane that owns the</font></font>
<br><font face="Courier"><font size=-1>> > > resources. If a logical node
id was added to the</font></font>
<br><font face="Courier"><font size=-1>> > advertisement for the</font></font>
<br><font face="Courier"><font size=-1>> > > node terminating the resources
when the advertising router</font></font>
<br><font face="Courier"><font size=-1>> > was not the</font></font>
<br><font face="Courier"><font size=-1>> > > bearer node that owned the
resources it would be clearer to me.</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > Don</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > >>Am I missing something?</font></font>
<br><font face="Courier"><font size=-1>> > >></font></font>
<br><font face="Courier"><font size=-1>> > >>Adrian</font></font>
<br><font face="Courier"><font size=-1>> > >></font></font>
<br><font face="Courier"><font size=-1>> > >>----- Original Message -----</font></font>
<br><font face="Courier"><font size=-1>> > >>From: "Brungard, Deborah A,
ALABS" &lt;<a href="mailto:[e-mail]">[e-mail]</a>></font></font>
<br><font face="Courier"><font size=-1>> > >>To: &lt;<a href="mailto:[e-mail]">[e-mail]</a>></font></font>
<br><font face="Courier"><font size=-1>> > >>Sent: Monday, March 15, 2004
7:43 PM</font></font>
<br><font face="Courier"><font size=-1>> > >>Subject: ason-routing-reqts:
issue 2 architecture</font></font>
<br><font face="Courier"><font size=-1>> > >></font></font>
<br><font face="Courier"><font size=-1>> > >></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > <a href="ftp://ftp.isi.edu/internet-drafts/draft-ietf">ftp://ftp.isi.edu/internet-drafts/draft-ietf</a>->
ccamp-gmpls-ason-routing-</font></font>
<br><font face="Courier"><font size=-1>> > > reqts-</font></font>
<br><font face="Courier"><font size=-1>> > > 02.txt</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > The second DT issue is on
the physical architecture which can be</font></font>
<br><font face="Courier"><font size=-1>> > > supported by GMPLS (from the
draft):</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > > ASON does not restrict the
architecture choices used, either a</font></font>
<br><font face="Courier"><font size=-1>> > > co-located architecture or
a physically separated</font></font>
<br><font face="Courier"><font size=-1>> > architecture may be</font></font>
<br><font face="Courier"><font size=-1>> > > used. Some members of the
Design Team are concerned that GMPLS's</font></font>
<br><font face="Courier"><font size=-1>> > > concept of the LSR requires
a 1-to-1 relationship between the</font></font>
<br><font face="Courier"><font size=-1>> > > transport plane entity and
the control plane entity (Router). They</font></font>
<br><font face="Courier"><font size=-1>> > > invite CCAMP input on GMPLS
capabilities to support multiple</font></font>
<br><font face="Courier"><font size=-1>> > > architectures i.e. how routing
protocols would identify the</font></font>
<br><font face="Courier"><font size=-1>> > transport</font></font>
<br><font face="Courier"><font size=-1>> > > node ID vs. the router or
routing controller ID when</font></font>
<br><font face="Courier"><font size=-1>> > scoping Link IDs</font></font>
<br><font face="Courier"><font size=-1>> > > in a link advertisement. Deborah</font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> > ></font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>> > --</font></font>
<br><font face="Courier"><font size=-1>> > Papadimitriou Dimitri</font></font>
<br><font face="Courier"><font size=-1>> > E-mail : <a href="mailto:[e-mail]">[e-mail]</a></font></font>
<br><font face="Courier"><font size=-1>> > E-mail : <a href="mailto:[e-mail]">[e-mail]</a></font></font>
<br><font face="Courier"><font size=-1>> > Webpage: <a href="http://psg.com/~dpapadimitriou/">http://psg.com/~dpapadimitriou/</a></font></font>
<br><font face="Courier"><font size=-1>> > Address: Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium</font></font>
<br><font face="Courier"><font size=-1>> > Phone&nbsp; : [phone]</font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>> ></font></font>
<br><font face="Courier"><font size=-1>></font></font>
<br><font face="Courier"><font size=-1>></font></font></blockquote>
</html>


<P><hr size=1></P>
<P><STRONG>============================================================<br>The information contained in this message may be privileged <br>and confidential and protected from disclosure.  If the <br>reader of this message is not the intended recipient, or an <br>employee or agent responsible for delivering this message to <br>the intended recipient, you are hereby notified that any <br>reproduction, dissemination or distribution of this <br>communication is strictly prohibited. If you have received <br>this communication in error, please notify us immediately by <br>replying to the message and deleting it from your computer.<br><br>Thank you.<br>Tellabs<br>============================================================</STRONG></P>
</BODY>
</HTML>
--------------8DE4C807CEF9D6CD06830578--




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 22:05:16 +0000
Message-ID: <[e-mail]>
From: "Stephen Shew" <[e-mail]>
To: "'Ong, Lyndon'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Adrian Farrel <[e-mail]>
Cc: "Don Fedyk" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 17:04:17 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40BA2.A02835B6"

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_01C40BA2.A02835B6
Content-Type: text/plain

I agree with Lyndon and Don regarding the need to have a bearer plane
identifier for the node.  To answer Adrian's first question, the RFC3630
makes the assumption that the link is scoped to a router.  Another quote
from RFC3630 is "The Link ID sub-TLV identifies the other end of the link.
For point-to-point links, this is the Router ID of the neighbor.".  This
derives from the assumption that a "router" is both a control entity and a
packet forwarding entity (bearer) and that they are 1:1.

What ASON does is describe a control plane architecture that can be
instantiated a number of ways onto a G.805 bearer plane.  A link in that
context is always associated with a (G.805) subnetwork which is also a
bearer entity.  The smallest subnetwork is a matrix or node/switch.  So
applying the ASON principle, the link is scoped to a node and not a control
entity (routing) or its identifier (router id).

One instantiation that is possible would be for R1 in Adrian's diagram to
advertise on behalf of each of the P1/P2/P3 nodes, not as one abstract node.
In that case, it would be confusing to scope the P1-P2 link using the router
id of R1.

-----Original Message-----
From: Ong, Lyndon [mailto:[e-mail]] 
Sent: Tuesday, March 16, 2004 16:37
To: '[e-mail]'; Adrian Farrel
Cc: Fedyk, Don [BL60:1A00:EXCH]; Brungard, Deborah A, ALABS;
[e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture


Hi Guys,

R1 was what I was referring to in my side note: it is
possible to treat P1/P2/P3 as separate
interfaces on a single abstract node, but you lose
information about the physical topology and
connectivity of the nodes.  Also, this puts a 
constraint on the allocation of interface IDs across
multiple nodes.  

Would it not be simpler and more straightforward to
advertise P1/P2/P3 directly?

Cheers,

Lyndon

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Tuesday, March 16, 2004 12:58 PM
To: Adrian Farrel
Cc: Don Fedyk; Ong, Lyndon; Brungard, Deborah A, ALABS; [e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture


adrian,

yes, it reproduces the three cases, i had in mind over this discussion

see in-line:

> All,
> Does the following picture capture what we want to achieve?
> 
> 
>              ------------------     ------    
>             |R1                |   |R2    |   
>             |  --    --    --  |   |  --  |    ------
>             | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
>             |  --    --    --  |   |  --  |   |  --  |
>             |   :     :     :  |   |   :  |   | |L5| |
> Control      ---+-----+-----+--     ---+--    |  --  |
> Plane           :     :     :          :      |   :  |
> ----------------+-----+-----+----------+------+---+--+-
> Data            :     :     :          :      |   :  |
> Plane          --     :    --         --      |  --  |
>           ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
>                -- \   :  / --         --      |  --  |
>                    \ -- /                     |      |
>                     |P2|                       ------
>                      --
> 
> Pn is a physical (bearer/data/transport plane) node.
> Rn is a control plane "router"
> Ln is a logical control plane entity that manages a single
>    physical node.
> 
> Thus:
> R3 represents an LSR with all components collocated.
> R2 shows how the "router" component may be disjoint from
>    the switch
> R1 shows how a single "router" may manage multiple switches
> 
> If you can confirm this generalisation, then we can show (or fail to 
> show) A. That this is a requirement

to support all them yes (i think that from a protocol capability perspective
it is advisable)

> B. That this can be achieved using existing protocols

there is no difference between R2 and R3 since the DP
to CP interactions were never part of the GMPLS routing
discussions:
- R2 <- Router_Address, R3 <- Router_Address
- If_Id assigned to each interface

for R1 (externally since representing an abstract node):
- R1 <- Router_Address
- If_Id assigned to each interface (with a value space
   common to P1, P2 and P3)

for R1 if there is a need to cover also the internal
(abstract node) links (is that the case?), in such a
case, the Link_Id sub-TLV value should be discussed

> Cheers,
> Adrian.
> 
> PS. Those not familiar with GSMP may want to take a quick peak.
> 
> ----- Original Message -----
> From: "Don Fedyk" <[e-mail]>
> To: <[e-mail]>; "Ong, Lyndon" <[e-mail]>
> Cc: "Adrian Farrel" <[e-mail]>; "Brungard, Deborah A, ALABS"
<[e-mail]>; <[e-mail]>
> Sent: Tuesday, March 16, 2004 7:34 PM
> Subject: RE: ason-routing-reqts: issue 2 architecture
> 
> 
> 
>>Dimitri
>>
>>If you are saying the real or logical node id that is associated with 
>>the Data (bearer) plane should be unique? I would say yes.
>>
>>If you are saying could it be IP address format? I would say yes. 
>>(Note the link identifiers in IP address format are unique only with 
>>respect to the node id).
>>
>>But if you say Should it then follow each piece of equipment has 
>>knowledge of this IP address format that is assigned to it? I would 
>>say no because there is equipment that won't have this for some time. (A
requirement I
>>understand from ASON).   
>>
>>So what I believe you are left with is some bearer equipment which has 
>>TE resources (a node Identifier (non-IP) and link identifiers 
>>(non-IP)). This equipment is known by its native identifiers to the 
>>entity in the control plane which can assign: IP format identifiers to 
>>the equipment (through some
>>means) and an unique node identifier. This can then be advertised on its
>>behalf as a GMPLS compatible TE LSA. 
>>
>>This does create some challenges but in reality I think many devices 
>>are known by more than one name. (Look at VoIP, devices they have 2 
>>identifiers E.164 and IP. I personally never use my IP address to make 
>>a VoIP phone call but I know that it is routed to a IP address along 
>>the way that is hidden from me.)
>>
>>I tend to agree with Lyndon that Topology is derived from TE 
>>advertisements. I don't understand what you could do without a unique 
>>logical node associated with the TE links.
>>
>>Don
>>
>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] 
>>>Sent: Tuesday, March 16, 2004 1:48 PM
>>>To: Ong, Lyndon
>>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, 
>>>Deborah A, ALABS; [e-mail]
>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>
>>>
>>>the problem is not an issue of being cleaner, the issue
>>>is once the following assumption is taken (which is the logical 
>>>consequence of rfc 3630 in the gmpls context)
>>>
>>>"a stable IP address of the control plane entity that manages the 
>>>resources on behalf of the data plane entity whose resources are 
>>>being advertised."
>>>
>>>can we assume that wrt to this stable IP address the resource 
>>>identification will be unique (throughout these multiple data plane 
>>>entities) and in this case it holds (no additional level of 
>>>indirection needed), or not (i.e. you will find duplicated id space 
>>>values and then an additional level of indirection is needed)
>>>
>>>the problem of the design team was not define the issue
>>>but to find enough arguments wrt to the operational practices (ie 
>>>user community) in order to close this
>>>
>>>thanks,
>>>- dimitri.
>>>
>>>Ong, Lyndon wrote:
>>>
>>>>I had the same assumption as Don, that the RFC treats the
>>>
>>>advertising
>>>
>>>>router and the bearer plane node as the same. It would be
>>>
>>>cleaner if
>>>
>>>>there was also a bearer plane node identifier in the advertisement.
>>>>
>>>>Cheers,
>>>>
>>>>Lyndon
>>>>
>>>>-----Original Message-----
>>>>From: Don Fedyk [mailto:[e-mail]]
>>>>Sent: Tuesday, March 16, 2004 9:56 AM
>>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
>>>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>>>
>>>>
>>>>Hi Adrian
>>>>
>>>>See Comments Below,
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Adrian Farrel [mailto:[e-mail]]
>>>>>Sent: Monday, March 15, 2004 4:18 PM
>>>>>To: Brungard, Deborah A, ALABS; [e-mail]
>>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>>>
>>>>>
>>>>>I assume that the desire is to have one control plane entity mange 
>>>>>multiple data plane entities (not to have one data plane entity 
>>>>>managed by multiple control plane entities).
>>>>
>>>>
>>>>I agree.
>>>>
>>>>
>>>>>I believe. in this context, it might be helpful to separate the 
>>>>>signaling function (and the associated routing function for the 
>>>>>delivery of the signaling messages) from the TE advertisement 
>>>>>routing function. Since we are discussing the routing requirements 
>>>>>(this is the routing DT) can I assume that the discussion is 
>>>>>limited to the TE advertisement routing function, with the aim to 
>>>>>have one control plane entity advertise the resources on behalf of 
>>>>>multiple data plane entities.
>>>>>
>>>>>If all of the above, why could you not simply do this using 
>>>>>RFC3630? The only wrinkle might be that the Router Address TLV is 
>>>>>described as carrying "a stable IP address of the advertising 
>>>>>router". Clearly, this needs to be interpreted as "a stable IP 
>>>>>address of the control plane entity that manages the resources on 
>>>>>behalf of the data plane entity whose resources are being 
>>>>>advertised."
>>>>
>>>>
>>>>Interesting. I thought that you need a logical node id for
>>>
>>>the bearer
>>>
>>>>plane as well even though you are only advertising from a single
>>>>entity.  In other words, is it not the desire to have the TE 
>>>>advertisements contain the same information regardless of whether 
>>>>there is a one to one correspondence between the nodes in 
>>>
>>>control and
>>>
>>>>the data plane or there is a one to many relationship? My
>>>>interpretation of RFC3630 is that it assumes the 
>>>
>>>advertising router is
>>>
>>>>the same as the logical node in the bearer plane that owns the
>>>>resources. If a logical node id was added to the 
>>>
>>>advertisement for the
>>>
>>>>node terminating the resources when the advertising router
>>>
>>>was not the
>>>
>>>>bearer node that owned the resources it would be clearer to me.
>>>>
>>>>Don
>>>>
>>>>
>>>>
>>>>
>>>>>Am I missing something?



------_=_NextPart_001_01C40BA2.A02835B6
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: ason-routing-reqts: issue 2 architecture</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with Lyndon and Don regarding the need to =
have a bearer plane identifier for the node.&nbsp; To answer Adrian's =
first question, the RFC3630 makes the assumption that the link is =
scoped to a router.&nbsp; Another quote from RFC3630 is &quot;The Link =
ID sub-TLV identifies the other end of the link.&nbsp; For =
point-to-point links, this is the Router ID of the =
neighbor.&quot;.&nbsp; This derives from the assumption that a =
&quot;router&quot; is both a control entity and a packet forwarding =
entity (bearer) and that they are 1:1.</FONT></P>

<P><FONT SIZE=3D2>What ASON does is describe a control plane =
architecture that can be instantiated a number of ways onto a G.805 =
bearer plane.&nbsp; A link in that context is always associated with a =
(G.805) subnetwork which is also a bearer entity.&nbsp; The smallest =
subnetwork is a matrix or node/switch.&nbsp; So applying the ASON =
principle, the link is scoped to a node and not a control entity =
(routing) or its identifier (router id).</FONT></P>

<P><FONT SIZE=3D2>One instantiation that is possible would be for R1 in =
Adrian's diagram to advertise on behalf of each of the P1/P2/P3 nodes, =
not as one abstract node.&nbsp; In that case, it would be confusing to =
scope the P1-P2 link using the router id of R1.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ong, Lyndon [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 16, 2004 16:37</FONT>
<BR><FONT SIZE=3D2>To: '[e-mail]'; Adrian =
Farrel</FONT>
<BR><FONT SIZE=3D2>Cc: Fedyk, Don [BL60:1A00:EXCH]; Brungard, Deborah =
A, ALABS; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: ason-routing-reqts: issue 2 =
architecture</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Guys,</FONT>
</P>

<P><FONT SIZE=3D2>R1 was what I was referring to in my side note: it =
is</FONT>
<BR><FONT SIZE=3D2>possible to treat P1/P2/P3 as separate</FONT>
<BR><FONT SIZE=3D2>interfaces on a single abstract node, but you =
lose</FONT>
<BR><FONT SIZE=3D2>information about the physical topology and</FONT>
<BR><FONT SIZE=3D2>connectivity of the nodes.&nbsp; Also, this puts a =
</FONT>
<BR><FONT SIZE=3D2>constraint on the allocation of interface IDs =
across</FONT>
<BR><FONT SIZE=3D2>multiple nodes.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Would it not be simpler and more straightforward =
to</FONT>
<BR><FONT SIZE=3D2>advertise P1/P2/P3 directly?</FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
</P>

<P><FONT SIZE=3D2>Lyndon</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:Dimitri.Papadimi=
[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 16, 2004 12:58 PM</FONT>
<BR><FONT SIZE=3D2>To: Adrian Farrel</FONT>
<BR><FONT SIZE=3D2>Cc: Don Fedyk; Ong, Lyndon; Brungard, Deborah A, =
ALABS; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: ason-routing-reqts: issue 2 =
architecture</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>adrian,</FONT>
</P>

<P><FONT SIZE=3D2>yes, it reproduces the three cases, i had in mind =
over this discussion</FONT>
</P>

<P><FONT SIZE=3D2>see in-line:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; Does the following picture capture what we want =
to achieve?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; ------------------&nbsp;&nbsp;&nbsp;&nbsp; =
------&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |R2&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; =
</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; |&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; =
--&nbsp; |&nbsp;&nbsp; |&nbsp; --&nbsp; |&nbsp;&nbsp;&nbsp; =
------</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; | |L1|&nbsp; |L2|&nbsp; |L3| |&nbsp;&nbsp; | |L4| =
|&nbsp;&nbsp; |R3&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; |&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp; =
--&nbsp; |&nbsp;&nbsp; |&nbsp; --&nbsp; |&nbsp;&nbsp; |&nbsp; --&nbsp; =
|</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; =
|&nbsp;&nbsp; | |L5| |</FONT>
<BR><FONT SIZE=3D2>&gt; Control&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
---+-----+-----+--&nbsp;&nbsp;&nbsp;&nbsp; ---+--&nbsp;&nbsp;&nbsp; =
|&nbsp; --&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; =
Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; =
----------------+-----+-----+----------+------+---+--+-</FONT>
<BR><FONT SIZE=3D2>&gt; =
Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; :&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; =
Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; ----|P1|--------|P3|-------|P4|-----+-|P5|-+-</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- \&nbsp;&nbsp; :&nbsp; / =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \ -- =
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|P2|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
------</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Pn is a physical (bearer/data/transport plane) =
node.</FONT>
<BR><FONT SIZE=3D2>&gt; Rn is a control plane &quot;router&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; Ln is a logical control plane entity that =
manages a single</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; physical node.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thus:</FONT>
<BR><FONT SIZE=3D2>&gt; R3 represents an LSR with all components =
collocated.</FONT>
<BR><FONT SIZE=3D2>&gt; R2 shows how the &quot;router&quot; component =
may be disjoint from</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the switch</FONT>
<BR><FONT SIZE=3D2>&gt; R1 shows how a single &quot;router&quot; may =
manage multiple switches</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If you can confirm this generalisation, then we =
can show (or fail to </FONT>
<BR><FONT SIZE=3D2>&gt; show) A. That this is a requirement</FONT>
</P>

<P><FONT SIZE=3D2>to support all them yes (i think that from a protocol =
capability perspective it is advisable)</FONT>
</P>

<P><FONT SIZE=3D2>&gt; B. That this can be achieved using existing =
protocols</FONT>
</P>

<P><FONT SIZE=3D2>there is no difference between R2 and R3 since the =
DP</FONT>
<BR><FONT SIZE=3D2>to CP interactions were never part of the GMPLS =
routing</FONT>
<BR><FONT SIZE=3D2>discussions:</FONT>
<BR><FONT SIZE=3D2>- R2 &lt;- Router_Address, R3 &lt;- =
Router_Address</FONT>
<BR><FONT SIZE=3D2>- If_Id assigned to each interface</FONT>
</P>

<P><FONT SIZE=3D2>for R1 (externally since representing an abstract =
node):</FONT>
<BR><FONT SIZE=3D2>- R1 &lt;- Router_Address</FONT>
<BR><FONT SIZE=3D2>- If_Id assigned to each interface (with a value =
space</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; common to P1, P2 and P3)</FONT>
</P>

<P><FONT SIZE=3D2>for R1 if there is a need to cover also the =
internal</FONT>
<BR><FONT SIZE=3D2>(abstract node) links (is that the case?), in such =
a</FONT>
<BR><FONT SIZE=3D2>case, the Link_Id sub-TLV value should be =
discussed</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Cheers,</FONT>
<BR><FONT SIZE=3D2>&gt; Adrian.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PS. Those not familiar with GSMP may want to =
take a quick peak.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt; From: &quot;Don Fedyk&quot; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To: &lt;[e-mail]&gt;; =
&quot;Ong, Lyndon&quot; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: &quot;Adrian Farrel&quot; =
&lt;[e-mail]&gt;; &quot;Brungard, Deborah A, ALABS&quot; =
&lt;[e-mail]&gt;; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, March 16, 2004 7:34 PM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: ason-routing-reqts: issue 2 =
architecture</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Dimitri</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;If you are saying the real or logical node =
id that is associated with </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;the Data (bearer) plane should be unique? I =
would say yes.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;If you are saying could it be IP address =
format? I would say yes. </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;(Note the link identifiers in IP address =
format are unique only with </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;respect to the node id).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;But if you say Should it then follow each =
piece of equipment has </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;knowledge of this IP address format that is =
assigned to it? I would </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;say no because there is equipment that won't =
have this for some time. (A requirement I</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;understand from ASON).&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;So what I believe you are left with is some =
bearer equipment which has </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;TE resources (a node Identifier (non-IP) and =
link identifiers </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;(non-IP)). This equipment is known by its =
native identifiers to the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;entity in the control plane which can =
assign: IP format identifiers to </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;the equipment (through some</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;means) and an unique node identifier. This =
can then be advertised on its</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;behalf as a GMPLS compatible TE LSA. </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;This does create some challenges but in =
reality I think many devices </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;are known by more than one name. (Look at =
VoIP, devices they have 2 </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;identifiers E.164 and IP. I personally never =
use my IP address to make </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;a VoIP phone call but I know that it is =
routed to a IP address along </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;the way that is hidden from me.)</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;I tend to agree with Lyndon that Topology is =
derived from TE </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;advertisements. I don't understand what you =
could do without a unique </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;logical node associated with the TE =
links.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Don</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;From: =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;[<A =
HREF=3D"mailto:[e-mail]">mailto:Dimitri.Papadimi=
[e-mail]</A>] </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Sent: Tuesday, March 16, 2004 1:48 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;To: Ong, Lyndon</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian =
Farrel; Brungard, </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Deborah A, ALABS; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Subject: Re: ason-routing-reqts: issue 2 =
architecture</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;the problem is not an issue of being =
cleaner, the issue</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;is once the following assumption is =
taken (which is the logical </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;consequence of rfc 3630 in the gmpls =
context)</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&quot;a stable IP address of the control =
plane entity that manages the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;resources on behalf of the data plane =
entity whose resources are </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;being advertised.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;can we assume that wrt to this stable IP =
address the resource </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;identification will be unique =
(throughout these multiple data plane </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;entities) and in this case it holds (no =
additional level of </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;indirection needed), or not (i.e. you =
will find duplicated id space </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;values and then an additional level of =
indirection is needed)</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;the problem of the design team was not =
define the issue</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;but to find enough arguments wrt to the =
operational practices (ie </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;user community) in order to close =
this</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;thanks,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;- dimitri.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;Ong, Lyndon wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;I had the same assumption as Don, =
that the RFC treats the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;advertising</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;router and the bearer plane node as =
the same. It would be</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;cleaner if</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;there was also a bearer plane node =
identifier in the advertisement.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;Cheers,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;Lyndon</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;From: Don Fedyk [<A =
HREF=3D"mailto:[e-mail]">mailto:dwfedyk@nortelnetworks=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;Sent: Tuesday, March 16, 2004 9:56 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;To: Adrian Farrel; Brungard, Deborah =
A, ALABS; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;Subject: RE: ason-routing-reqts: =
issue 2 architecture</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;Hi Adrian</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;See Comments Below,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;-----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;From: Adrian Farrel [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;Sent: Monday, March 15, 2004 =
4:18 PM</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;To: Brungard, Deborah A, ALABS; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;Subject: Re: ason-routing-reqts: =
issue 2 architecture</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;I assume that the desire is to =
have one control plane entity mange </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;multiple data plane entities =
(not to have one data plane entity </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;managed by multiple control =
plane entities).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;I agree.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;I believe. in this context, it =
might be helpful to separate the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;signaling function (and the =
associated routing function for the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;delivery of the signaling =
messages) from the TE advertisement </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;routing function. Since we are =
discussing the routing requirements </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;(this is the routing DT) can I =
assume that the discussion is </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;limited to the TE advertisement =
routing function, with the aim to </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;have one control plane entity =
advertise the resources on behalf of </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;multiple data plane =
entities.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;If all of the above, why could =
you not simply do this using </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;RFC3630? The only wrinkle might =
be that the Router Address TLV is </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;described as carrying &quot;a =
stable IP address of the advertising </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;router&quot;. Clearly, this =
needs to be interpreted as &quot;a stable IP </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;address of the control plane =
entity that manages the resources on </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;behalf of the data plane entity =
whose resources are being </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;advertised.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;Interesting. I thought that you need =
a logical node id for</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;the bearer</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;plane as well even though you are =
only advertising from a single</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;entity.&nbsp; In other words, is it =
not the desire to have the TE </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;advertisements contain the same =
information regardless of whether </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;there is a one to one correspondence =
between the nodes in </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;control and</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;the data plane or there is a one to =
many relationship? My</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;interpretation of RFC3630 is that it =
assumes the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;advertising router is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;the same as the logical node in the =
bearer plane that owns the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;resources. If a logical node id was =
added to the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;advertisement for the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;node terminating the resources when =
the advertising router</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;was not the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;bearer node that owned the resources =
it would be clearer to me.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;Don</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt;Am I missing something?</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C40BA2.A02835B6--



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 21:58:23 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 2004 22:59:06 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: "Ong, Lyndon" <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, Don Fedyk <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi lyndon,

the question is not only to be more simpler for R1 (i don't think you 
are more simpler you're just mapping the hierarchy of the abstract node 
within the identification space) it is to so see how it impacts R2 and 
R3, in term of the processing, how it impacts the abstraction level that 
you want to achieve (do external R2 and R3 really care about the way R1 
is performing id assignment) and finally what it brings in terms of 
control plane functionality, arguments like cleaner, or simpler (what 
simple means) are probably not be used in the present context, at the 
end the issue is about practice and relevance

it also clear that if this additional level of indirection is proven to 
be required nothing is said about the way to deliver it while you 
already assumed it must take the form of a node_id (why a node_id ? why 
not a shelve_id ? or a rack_id ?)

thanks,
- dimitri.

Ong, Lyndon wrote:

> Hi Guys,
> 
> R1 was what I was referring to in my side note: it is
> possible to treat P1/P2/P3 as separate
> interfaces on a single abstract node, but you lose
> information about the physical topology and
> connectivity of the nodes.  Also, this puts a 
> constraint on the allocation of interface IDs across
> multiple nodes.  
> 
> Would it not be simpler and more straightforward to
> advertise P1/P2/P3 directly?
> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 12:58 PM
> To: Adrian Farrel
> Cc: Don Fedyk; Ong, Lyndon; Brungard, Deborah A, ALABS;
> [e-mail]
> Subject: Re: ason-routing-reqts: issue 2 architecture
> 
> 
> adrian,
> 
> yes, it reproduces the three cases, i had in mind over this
> discussion
> 
> see in-line:
> 
> 
>>All,
>>Does the following picture capture what we want to achieve?
>>
>>
>>             ------------------     ------    
>>            |R1                |   |R2    |   
>>            |  --    --    --  |   |  --  |    ------
>>            | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
>>            |  --    --    --  |   |  --  |   |  --  |
>>            |   :     :     :  |   |   :  |   | |L5| |
>>Control      ---+-----+-----+--     ---+--    |  --  |
>>Plane           :     :     :          :      |   :  |
>>----------------+-----+-----+----------+------+---+--+-
>>Data            :     :     :          :      |   :  |
>>Plane          --     :    --         --      |  --  |
>>          ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
>>               -- \   :  / --         --      |  --  |
>>                   \ -- /                     |      |
>>                    |P2|                       ------
>>                     --
>>
>>Pn is a physical (bearer/data/transport plane) node.
>>Rn is a control plane "router"
>>Ln is a logical control plane entity that manages a single
>>   physical node.
>>
>>Thus:
>>R3 represents an LSR with all components collocated.
>>R2 shows how the "router" component may be disjoint from
>>   the switch
>>R1 shows how a single "router" may manage multiple switches
>>
>>If you can confirm this generalisation, then we can show (or fail to show)
>>A. That this is a requirement
> 
> 
> to support all them yes (i think that from a protocol
> capability perspective it is advisable)
> 
> 
>>B. That this can be achieved using existing protocols
> 
> 
> there is no difference between R2 and R3 since the DP
> to CP interactions were never part of the GMPLS routing
> discussions:
> - R2 <- Router_Address, R3 <- Router_Address
> - If_Id assigned to each interface
> 
> for R1 (externally since representing an abstract node):
> - R1 <- Router_Address
> - If_Id assigned to each interface (with a value space
>    common to P1, P2 and P3)
> 
> for R1 if there is a need to cover also the internal
> (abstract node) links (is that the case?), in such a
> case, the Link_Id sub-TLV value should be discussed
> 
> 
>>Cheers,
>>Adrian.
>>
>>PS. Those not familiar with GSMP may want to take a quick peak.
>>
>>----- Original Message ----- 
>>From: "Don Fedyk" <[e-mail]>
>>To: <[e-mail]>; "Ong, Lyndon" <[e-mail]>
>>Cc: "Adrian Farrel" <[e-mail]>; "Brungard, Deborah A, ALABS" <[e-mail]>; <[e-mail]>
>>Sent: Tuesday, March 16, 2004 7:34 PM
>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>
>>
>>
>>
>>>Dimitri
>>>
>>>If you are saying the real or logical node id that is associated with the
>>>Data (bearer) plane should be unique? I would say yes. 
>>>
>>>If you are saying could it be IP address format? I would say yes. (Note the
>>>link identifiers in IP address format are unique only with respect to the
>>>node id).
>>>
>>>But if you say Should it then follow each piece of equipment has knowledge
>>>of this IP address format that is assigned to it? I would say no because
>>>there is equipment that won't have this for some time. (A requirement I
>>>understand from ASON).   
>>>
>>>So what I believe you are left with is some bearer equipment which has TE
>>>resources (a node Identifier (non-IP) and link identifiers (non-IP)). This
>>>equipment is known by its native identifiers to the entity in the control
>>>plane which can assign: IP format identifiers to the equipment (through some
>>>means) and an unique node identifier. This can then be advertised on its
>>>behalf as a GMPLS compatible TE LSA. 
>>>
>>>This does create some challenges but in reality I think many devices are
>>>known by more than one name. (Look at VoIP, devices they have 2 identifiers
>>>E.164 and IP. I personally never use my IP address to make a VoIP phone call
>>>but I know that it is routed to a IP address along the way that is hidden
>>
>>>from me.)
>>
>>>I tend to agree with Lyndon that Topology is derived from TE advertisements.
>>>I don't understand what you could do without a unique logical node
>>>associated with the TE links. 
>>>
>>>Don 
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail] 
>>>>[mailto:[e-mail]] 
>>>>Sent: Tuesday, March 16, 2004 1:48 PM
>>>>To: Ong, Lyndon
>>>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, 
>>>>Deborah A, ALABS; [e-mail]
>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>>
>>>>
>>>>the problem is not an issue of being cleaner, the issue
>>>>is once the following assumption is taken (which is the
>>>>logical consequence of rfc 3630 in the gmpls context)
>>>>
>>>>"a stable IP address of the control plane entity that
>>>>manages the resources on behalf of the data plane
>>>>entity whose resources are being advertised."
>>>>
>>>>can we assume that wrt to this stable IP address the
>>>>resource identification will be unique (throughout
>>>>these multiple data plane entities) and in this case
>>>>it holds (no additional level of indirection needed),
>>>>or not (i.e. you will find duplicated id space values
>>>>and then an additional level of indirection is needed)
>>>>
>>>>the problem of the design team was not define the issue
>>>>but to find enough arguments wrt to the operational
>>>>practices (ie user community) in order to close this
>>>>
>>>>thanks,
>>>>- dimitri.
>>>>
>>>>Ong, Lyndon wrote:
>>>>
>>>>
>>>>>I had the same assumption as Don, that the RFC treats the 
>>>>
>>>>advertising 
>>>>
>>>>
>>>>>router and the bearer plane node as the same. It would be 
>>>>
>>>>cleaner if 
>>>>
>>>>
>>>>>there was also a bearer plane node identifier in the advertisement.
>>>>>
>>>>>Cheers,
>>>>>
>>>>>Lyndon
>>>>>
>>>>>-----Original Message-----
>>>>>From: Don Fedyk [mailto:[e-mail]]
>>>>>Sent: Tuesday, March 16, 2004 9:56 AM
>>>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
>>>>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>>>>
>>>>>
>>>>>Hi Adrian
>>>>>
>>>>>See Comments Below,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Adrian Farrel [mailto:[e-mail]]
>>>>>>Sent: Monday, March 15, 2004 4:18 PM
>>>>>>To: Brungard, Deborah A, ALABS; [e-mail]
>>>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>>>>
>>>>>>
>>>>>>I assume that the desire is to have one control plane entity
>>>>>>mange multiple data plane entities (not to have one data 
>>>>>>plane entity managed by multiple control plane entities).
>>>>>
>>>>>
>>>>>I agree.
>>>>>
>>>>>
>>>>>
>>>>>>I believe. in this context, it might be helpful to separate
>>>>>>the signaling function (and the associated routing function 
>>>>>>for the delivery of the signaling messages) from the TE 
>>>>>>advertisement routing function. Since we are discussing the 
>>>>>>routing requirements (this is the routing DT) can I assume 
>>>>>>that the discussion is limited to the TE advertisement 
>>>>>>routing function, with the aim to have one control plane 
>>>>>>entity advertise the resources on behalf of multiple data 
>>>>>>plane entities.
>>>>>>
>>>>>>If all of the above, why could you not simply do this using
>>>>>>RFC3630? The only wrinkle might be that the Router Address 
>>>>>>TLV is described as carrying "a stable IP address of the 
>>>>>>advertising router". Clearly, this needs to be interpreted as 
>>>>>>"a stable IP address of the control plane entity that manages 
>>>>>>the resources on behalf of the data plane entity whose 
>>>>>>resources are being advertised."
>>>>>
>>>>>
>>>>>Interesting. I thought that you need a logical node id for 
>>>>
>>>>the bearer 
>>>>
>>>>
>>>>>plane as well even though you are only advertising from a single 
>>>>>entity.  In other words, is it not the desire to have the TE 
>>>>>advertisements contain the same information regardless of whether 
>>>>>there is a one to one correspondence between the nodes in 
>>>>
>>>>control and 
>>>>
>>>>
>>>>>the data plane or there is a one to many relationship? My 
>>>>>interpretation of RFC3630 is that it assumes the 
>>>>
>>>>advertising router is 
>>>>
>>>>
>>>>>the same as the logical node in the bearer plane that owns the 
>>>>>resources. If a logical node id was added to the 
>>>>
>>>>advertisement for the 
>>>>
>>>>
>>>>>node terminating the resources when the advertising router 
>>>>
>>>>was not the 
>>>>
>>>>
>>>>>bearer node that owned the resources it would be clearer to me.
>>>>>
>>>>>Don
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Am I missing something?
>>>>>>
>>>>>>Adrian
>>>>>>
>>>>>>----- Original Message -----
>>>>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>>>>>To: <[e-mail]>
>>>>>>Sent: Monday, March 15, 2004 7:43 PM
>>>>>>Subject: ason-routing-reqts: issue 2 architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>ftp://ftp.isi.edu/internet-drafts/draft-ietf-> ccamp-gmpls-ason-routing-
>>>>
>>>>
>>>>>reqts-
>>>>>02.txt
>>>>>
>>>>>The second DT issue is on the physical architecture which can be 
>>>>>supported by GMPLS (from the draft):
>>>>>
>>>>>ASON does not restrict the architecture choices used, either a 
>>>>>co-located architecture or a physically separated 
>>>>
>>>>architecture may be 
>>>>
>>>>
>>>>>used. Some members of the Design Team are concerned that GMPLS's 
>>>>>concept of the LSR requires a 1-to-1 relationship between the 
>>>>>transport plane entity and the control plane entity (Router). They 
>>>>>invite CCAMP input on GMPLS capabilities to support multiple 
>>>>>architectures i.e. how routing protocols would identify the 
>>>>
>>>>transport 
>>>>
>>>>
>>>>>node ID vs. the router or routing controller ID when 
>>>>
>>>>scoping Link IDs 
>>>>
>>>>
>>>>>in a link advertisement. Deborah
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>-- 
>>>>Papadimitriou Dimitri
>>>>E-mail : [e-mail]
>>>>E-mail : [e-mail]
>>>>Webpage: http://psg.com/~dpapadimitriou/
>>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>>>Phone  : [phone]
>>>>
>>>>
>>>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 21:46:56 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing
Date: Tue, 16 Mar 2004 13:46:04 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Dimitri,

Maybe the issue needs to be worded more clearly...

Can existing address reachability mechanisms support
(and if so, how)

a) distinguishing between the control plane address
for a client and the data plane address for a client
which might be two different things?

b) distinguishing between the internal network address
space and an external client address space?

c) advertising reachability to a client whose address 
space is non-IP?

Cheers,

Lyndon

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Tuesday, March 16, 2004 11:43 AM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABS'; [e-mail]
Subject: Re: ason-routing-reqts: issue 1 addressing


hi lyndon,

some hints in-line, i start worrying about the arguments
you've been listed here below since here except (2) they
are not related to this issue 1:

Ong, Lyndon wrote:

> Hi Folks,
> 
> Let me kick off some discussion on issue 1 by noting some of the 
> concerns with using existing methods of advertising reachability for
> this purpose:
> 
> 1) the client system may not be an IP system, but another transport 
> device with an IP control interface - for example, an ADM (add-drop 
> multiplexer) acting as a client to an optical network.  Advertising 
> reachability using normal means might imply that the system can be 
> used for IP traffic routing.

-> the SC capability of the end-point is orthogonal to its
    numbering (in addition, this way of thinking will make us
    advertising MAC addresses when end-points will terminate
    Ethernet)

> 2) the client system may use a different addressing space than the 
> internal network addressing space.  Carriers may wish to use a 
> different addressing space for administrative or policy reasons.

-> i don't think there is any discussion here, the thread
    focuses on "external" reachability - and this is the
    issue, how this "external" reachability information
    needs to be advertised to maintain the properties of
    the control plane (in particular scalability)

> (Note: one model for this is the VPN model, which would allow private
> networks to have their own address spaces.  Another model is a
> telephone number-like model, where clients obtain addresses from a
> space maintained by the carrier.)
> 
> 3) the client system may use a non-IP address for compatibility 
> reasons, for example, a client with an existing management plane 
> address that the carrier wants to access without having to add a new
> address and translation mechanism.

-> mapping of MP <-> CP and CP <-> DP are outside the scope
    of the present discussion, note if your argument was valid,
    the argument (2) wouldn't since in this case you would
    have been advertising your management plane addresses

> Cheers,
> 
> Lyndon
> 
> -----Original Message----- From: Brungard, Deborah A, ALABS
> [mailto:[e-mail]] Sent: Monday, March 15, 2004 11:29 AM To:
> [e-mail] Subject: ason-routing-reqts: issue 1 addressing
> 
> 
> As noted in the CCAMP minutes and the DT's presentation, the ASON
> routing DT had three issues regarding GMPLS support for which they
> lacked agreement and request support of the WG. The issues are
> identified in Section 7 (Conclusions) of the draft: 
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
> 
> 
> I will post three separate email threads to cover each issue. The
> first issue is on address reachability. The following is the text
> from the draft:
> 
> Some members of the Design Team noted that reachability information
> (as described in Section 4.5.3) may be advertised as a set of UNI
> Transport Resource address prefixes (assigned and selected
> consistently in their applicability scope). These members of the
> Design Team raised a concern that existing methods of advertising
> reachability may need to be examined (on a per-protocol basis) to
> determine if they are also applicable for UNI Transport Resource
> addresses. They invite CCAMP discussion on this aspect. Deborah
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 21:37:36 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Adrian Farrel <[e-mail]>
Cc: Don Fedyk <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 13:36:34 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Guys,

R1 was what I was referring to in my side note: it is
possible to treat P1/P2/P3 as separate
interfaces on a single abstract node, but you lose
information about the physical topology and
connectivity of the nodes.  Also, this puts a 
constraint on the allocation of interface IDs across
multiple nodes.  

Would it not be simpler and more straightforward to
advertise P1/P2/P3 directly?

Cheers,

Lyndon

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Tuesday, March 16, 2004 12:58 PM
To: Adrian Farrel
Cc: Don Fedyk; Ong, Lyndon; Brungard, Deborah A, ALABS;
[e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture


adrian,

yes, it reproduces the three cases, i had in mind over this
discussion

see in-line:

> All,
> Does the following picture capture what we want to achieve?
> 
> 
>              ------------------     ------    
>             |R1                |   |R2    |   
>             |  --    --    --  |   |  --  |    ------
>             | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
>             |  --    --    --  |   |  --  |   |  --  |
>             |   :     :     :  |   |   :  |   | |L5| |
> Control      ---+-----+-----+--     ---+--    |  --  |
> Plane           :     :     :          :      |   :  |
> ----------------+-----+-----+----------+------+---+--+-
> Data            :     :     :          :      |   :  |
> Plane          --     :    --         --      |  --  |
>           ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
>                -- \   :  / --         --      |  --  |
>                    \ -- /                     |      |
>                     |P2|                       ------
>                      --
> 
> Pn is a physical (bearer/data/transport plane) node.
> Rn is a control plane "router"
> Ln is a logical control plane entity that manages a single
>    physical node.
> 
> Thus:
> R3 represents an LSR with all components collocated.
> R2 shows how the "router" component may be disjoint from
>    the switch
> R1 shows how a single "router" may manage multiple switches
> 
> If you can confirm this generalisation, then we can show (or fail to show)
> A. That this is a requirement

to support all them yes (i think that from a protocol
capability perspective it is advisable)

> B. That this can be achieved using existing protocols

there is no difference between R2 and R3 since the DP
to CP interactions were never part of the GMPLS routing
discussions:
- R2 <- Router_Address, R3 <- Router_Address
- If_Id assigned to each interface

for R1 (externally since representing an abstract node):
- R1 <- Router_Address
- If_Id assigned to each interface (with a value space
   common to P1, P2 and P3)

for R1 if there is a need to cover also the internal
(abstract node) links (is that the case?), in such a
case, the Link_Id sub-TLV value should be discussed

> Cheers,
> Adrian.
> 
> PS. Those not familiar with GSMP may want to take a quick peak.
> 
> ----- Original Message ----- 
> From: "Don Fedyk" <[e-mail]>
> To: <[e-mail]>; "Ong, Lyndon" <[e-mail]>
> Cc: "Adrian Farrel" <[e-mail]>; "Brungard, Deborah A, ALABS" <[e-mail]>; <[e-mail]>
> Sent: Tuesday, March 16, 2004 7:34 PM
> Subject: RE: ason-routing-reqts: issue 2 architecture
> 
> 
> 
>>Dimitri
>>
>>If you are saying the real or logical node id that is associated with the
>>Data (bearer) plane should be unique? I would say yes. 
>>
>>If you are saying could it be IP address format? I would say yes. (Note the
>>link identifiers in IP address format are unique only with respect to the
>>node id).
>>
>>But if you say Should it then follow each piece of equipment has knowledge
>>of this IP address format that is assigned to it? I would say no because
>>there is equipment that won't have this for some time. (A requirement I
>>understand from ASON).   
>>
>>So what I believe you are left with is some bearer equipment which has TE
>>resources (a node Identifier (non-IP) and link identifiers (non-IP)). This
>>equipment is known by its native identifiers to the entity in the control
>>plane which can assign: IP format identifiers to the equipment (through some
>>means) and an unique node identifier. This can then be advertised on its
>>behalf as a GMPLS compatible TE LSA. 
>>
>>This does create some challenges but in reality I think many devices are
>>known by more than one name. (Look at VoIP, devices they have 2 identifiers
>>E.164 and IP. I personally never use my IP address to make a VoIP phone call
>>but I know that it is routed to a IP address along the way that is hidden
>>from me.)
>>
>>I tend to agree with Lyndon that Topology is derived from TE advertisements.
>>I don't understand what you could do without a unique logical node
>>associated with the TE links. 
>>
>>Don 
>>
>>
>>>-----Original Message-----
>>>From: [e-mail] 
>>>[mailto:[e-mail]] 
>>>Sent: Tuesday, March 16, 2004 1:48 PM
>>>To: Ong, Lyndon
>>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, 
>>>Deborah A, ALABS; [e-mail]
>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>
>>>
>>>the problem is not an issue of being cleaner, the issue
>>>is once the following assumption is taken (which is the
>>>logical consequence of rfc 3630 in the gmpls context)
>>>
>>>"a stable IP address of the control plane entity that
>>>manages the resources on behalf of the data plane
>>>entity whose resources are being advertised."
>>>
>>>can we assume that wrt to this stable IP address the
>>>resource identification will be unique (throughout
>>>these multiple data plane entities) and in this case
>>>it holds (no additional level of indirection needed),
>>>or not (i.e. you will find duplicated id space values
>>>and then an additional level of indirection is needed)
>>>
>>>the problem of the design team was not define the issue
>>>but to find enough arguments wrt to the operational
>>>practices (ie user community) in order to close this
>>>
>>>thanks,
>>>- dimitri.
>>>
>>>Ong, Lyndon wrote:
>>>
>>>>I had the same assumption as Don, that the RFC treats the 
>>>
>>>advertising 
>>>
>>>>router and the bearer plane node as the same. It would be 
>>>
>>>cleaner if 
>>>
>>>>there was also a bearer plane node identifier in the advertisement.
>>>>
>>>>Cheers,
>>>>
>>>>Lyndon
>>>>
>>>>-----Original Message-----
>>>>From: Don Fedyk [mailto:[e-mail]]
>>>>Sent: Tuesday, March 16, 2004 9:56 AM
>>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
>>>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>>>
>>>>
>>>>Hi Adrian
>>>>
>>>>See Comments Below,
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Adrian Farrel [mailto:[e-mail]]
>>>>>Sent: Monday, March 15, 2004 4:18 PM
>>>>>To: Brungard, Deborah A, ALABS; [e-mail]
>>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>>>
>>>>>
>>>>>I assume that the desire is to have one control plane entity
>>>>>mange multiple data plane entities (not to have one data 
>>>>>plane entity managed by multiple control plane entities).
>>>>
>>>>
>>>>I agree.
>>>>
>>>>
>>>>>I believe. in this context, it might be helpful to separate
>>>>>the signaling function (and the associated routing function 
>>>>>for the delivery of the signaling messages) from the TE 
>>>>>advertisement routing function. Since we are discussing the 
>>>>>routing requirements (this is the routing DT) can I assume 
>>>>>that the discussion is limited to the TE advertisement 
>>>>>routing function, with the aim to have one control plane 
>>>>>entity advertise the resources on behalf of multiple data 
>>>>>plane entities.
>>>>>
>>>>>If all of the above, why could you not simply do this using
>>>>>RFC3630? The only wrinkle might be that the Router Address 
>>>>>TLV is described as carrying "a stable IP address of the 
>>>>>advertising router". Clearly, this needs to be interpreted as 
>>>>>"a stable IP address of the control plane entity that manages 
>>>>>the resources on behalf of the data plane entity whose 
>>>>>resources are being advertised."
>>>>
>>>>
>>>>Interesting. I thought that you need a logical node id for 
>>>
>>>the bearer 
>>>
>>>>plane as well even though you are only advertising from a single 
>>>>entity.  In other words, is it not the desire to have the TE 
>>>>advertisements contain the same information regardless of whether 
>>>>there is a one to one correspondence between the nodes in 
>>>
>>>control and 
>>>
>>>>the data plane or there is a one to many relationship? My 
>>>>interpretation of RFC3630 is that it assumes the 
>>>
>>>advertising router is 
>>>
>>>>the same as the logical node in the bearer plane that owns the 
>>>>resources. If a logical node id was added to the 
>>>
>>>advertisement for the 
>>>
>>>>node terminating the resources when the advertising router 
>>>
>>>was not the 
>>>
>>>>bearer node that owned the resources it would be clearer to me.
>>>>
>>>>Don
>>>>
>>>>
>>>>
>>>>
>>>>>Am I missing something?
>>>>>
>>>>>Adrian
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>>>>To: <[e-mail]>
>>>>>Sent: Monday, March 15, 2004 7:43 PM
>>>>>Subject: ason-routing-reqts: issue 2 architecture
>>>>>
>>>>>
>>>>
>>>>
>>>ftp://ftp.isi.edu/internet-drafts/draft-ietf-> ccamp-gmpls-ason-routing-
>>>
>>>>reqts-
>>>>02.txt
>>>>
>>>>The second DT issue is on the physical architecture which can be 
>>>>supported by GMPLS (from the draft):
>>>>
>>>>ASON does not restrict the architecture choices used, either a 
>>>>co-located architecture or a physically separated 
>>>
>>>architecture may be 
>>>
>>>>used. Some members of the Design Team are concerned that GMPLS's 
>>>>concept of the LSR requires a 1-to-1 relationship between the 
>>>>transport plane entity and the control plane entity (Router). They 
>>>>invite CCAMP input on GMPLS capabilities to support multiple 
>>>>architectures i.e. how routing protocols would identify the 
>>>
>>>transport 
>>>
>>>>node ID vs. the router or routing controller ID when 
>>>
>>>scoping Link IDs 
>>>
>>>>in a link advertisement. Deborah
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>-- 
>>>Papadimitriou Dimitri
>>>E-mail : [e-mail]
>>>E-mail : [e-mail]
>>>Webpage: http://psg.com/~dpapadimitriou/
>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>>Phone  : [phone]
>>>
>>>
>>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 20:57:09 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 2004 21:57:42 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: Don Fedyk <[e-mail]>, "Ong, Lyndon" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

adrian,

yes, it reproduces the three cases, i had in mind over this
discussion

see in-line:

> All,
> Does the following picture capture what we want to achieve?
> 
> 
>              ------------------     ------    
>             |R1                |   |R2    |   
>             |  --    --    --  |   |  --  |    ------
>             | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
>             |  --    --    --  |   |  --  |   |  --  |
>             |   :     :     :  |   |   :  |   | |L5| |
> Control      ---+-----+-----+--     ---+--    |  --  |
> Plane           :     :     :          :      |   :  |
> ----------------+-----+-----+----------+------+---+--+-
> Data            :     :     :          :      |   :  |
> Plane          --     :    --         --      |  --  |
>           ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
>                -- \   :  / --         --      |  --  |
>                    \ -- /                     |      |
>                     |P2|                       ------
>                      --
> 
> Pn is a physical (bearer/data/transport plane) node.
> Rn is a control plane "router"
> Ln is a logical control plane entity that manages a single
>    physical node.
> 
> Thus:
> R3 represents an LSR with all components collocated.
> R2 shows how the "router" component may be disjoint from
>    the switch
> R1 shows how a single "router" may manage multiple switches
> 
> If you can confirm this generalisation, then we can show (or fail to show)
> A. That this is a requirement

to support all them yes (i think that from a protocol
capability perspective it is advisable)

> B. That this can be achieved using existing protocols

there is no difference between R2 and R3 since the DP
to CP interactions were never part of the GMPLS routing
discussions:
- R2 <- Router_Address, R3 <- Router_Address
- If_Id assigned to each interface

for R1 (externally since representing an abstract node):
- R1 <- Router_Address
- If_Id assigned to each interface (with a value space
   common to P1, P2 and P3)

for R1 if there is a need to cover also the internal
(abstract node) links (is that the case?), in such a
case, the Link_Id sub-TLV value should be discussed

> Cheers,
> Adrian.
> 
> PS. Those not familiar with GSMP may want to take a quick peak.
> 
> ----- Original Message ----- 
> From: "Don Fedyk" <[e-mail]>
> To: <[e-mail]>; "Ong, Lyndon" <[e-mail]>
> Cc: "Adrian Farrel" <[e-mail]>; "Brungard, Deborah A, ALABS" <[e-mail]>; <[e-mail]>
> Sent: Tuesday, March 16, 2004 7:34 PM
> Subject: RE: ason-routing-reqts: issue 2 architecture
> 
> 
> 
>>Dimitri
>>
>>If you are saying the real or logical node id that is associated with the
>>Data (bearer) plane should be unique? I would say yes. 
>>
>>If you are saying could it be IP address format? I would say yes. (Note the
>>link identifiers in IP address format are unique only with respect to the
>>node id).
>>
>>But if you say Should it then follow each piece of equipment has knowledge
>>of this IP address format that is assigned to it? I would say no because
>>there is equipment that won't have this for some time. (A requirement I
>>understand from ASON).   
>>
>>So what I believe you are left with is some bearer equipment which has TE
>>resources (a node Identifier (non-IP) and link identifiers (non-IP)). This
>>equipment is known by its native identifiers to the entity in the control
>>plane which can assign: IP format identifiers to the equipment (through some
>>means) and an unique node identifier. This can then be advertised on its
>>behalf as a GMPLS compatible TE LSA. 
>>
>>This does create some challenges but in reality I think many devices are
>>known by more than one name. (Look at VoIP, devices they have 2 identifiers
>>E.164 and IP. I personally never use my IP address to make a VoIP phone call
>>but I know that it is routed to a IP address along the way that is hidden
>>from me.)
>>
>>I tend to agree with Lyndon that Topology is derived from TE advertisements.
>>I don't understand what you could do without a unique logical node
>>associated with the TE links. 
>>
>>Don 
>>
>>
>>>-----Original Message-----
>>>From: [e-mail] 
>>>[mailto:[e-mail]] 
>>>Sent: Tuesday, March 16, 2004 1:48 PM
>>>To: Ong, Lyndon
>>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, 
>>>Deborah A, ALABS; [e-mail]
>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>
>>>
>>>the problem is not an issue of being cleaner, the issue
>>>is once the following assumption is taken (which is the
>>>logical consequence of rfc 3630 in the gmpls context)
>>>
>>>"a stable IP address of the control plane entity that
>>>manages the resources on behalf of the data plane
>>>entity whose resources are being advertised."
>>>
>>>can we assume that wrt to this stable IP address the
>>>resource identification will be unique (throughout
>>>these multiple data plane entities) and in this case
>>>it holds (no additional level of indirection needed),
>>>or not (i.e. you will find duplicated id space values
>>>and then an additional level of indirection is needed)
>>>
>>>the problem of the design team was not define the issue
>>>but to find enough arguments wrt to the operational
>>>practices (ie user community) in order to close this
>>>
>>>thanks,
>>>- dimitri.
>>>
>>>Ong, Lyndon wrote:
>>>
>>>>I had the same assumption as Don, that the RFC treats the 
>>>
>>>advertising 
>>>
>>>>router and the bearer plane node as the same. It would be 
>>>
>>>cleaner if 
>>>
>>>>there was also a bearer plane node identifier in the advertisement.
>>>>
>>>>Cheers,
>>>>
>>>>Lyndon
>>>>
>>>>-----Original Message-----
>>>>From: Don Fedyk [mailto:[e-mail]]
>>>>Sent: Tuesday, March 16, 2004 9:56 AM
>>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
>>>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>>>
>>>>
>>>>Hi Adrian
>>>>
>>>>See Comments Below,
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Adrian Farrel [mailto:[e-mail]]
>>>>>Sent: Monday, March 15, 2004 4:18 PM
>>>>>To: Brungard, Deborah A, ALABS; [e-mail]
>>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>>>
>>>>>
>>>>>I assume that the desire is to have one control plane entity
>>>>>mange multiple data plane entities (not to have one data 
>>>>>plane entity managed by multiple control plane entities).
>>>>
>>>>
>>>>I agree.
>>>>
>>>>
>>>>>I believe. in this context, it might be helpful to separate
>>>>>the signaling function (and the associated routing function 
>>>>>for the delivery of the signaling messages) from the TE 
>>>>>advertisement routing function. Since we are discussing the 
>>>>>routing requirements (this is the routing DT) can I assume 
>>>>>that the discussion is limited to the TE advertisement 
>>>>>routing function, with the aim to have one control plane 
>>>>>entity advertise the resources on behalf of multiple data 
>>>>>plane entities.
>>>>>
>>>>>If all of the above, why could you not simply do this using
>>>>>RFC3630? The only wrinkle might be that the Router Address 
>>>>>TLV is described as carrying "a stable IP address of the 
>>>>>advertising router". Clearly, this needs to be interpreted as 
>>>>>"a stable IP address of the control plane entity that manages 
>>>>>the resources on behalf of the data plane entity whose 
>>>>>resources are being advertised."
>>>>
>>>>
>>>>Interesting. I thought that you need a logical node id for 
>>>
>>>the bearer 
>>>
>>>>plane as well even though you are only advertising from a single 
>>>>entity.  In other words, is it not the desire to have the TE 
>>>>advertisements contain the same information regardless of whether 
>>>>there is a one to one correspondence between the nodes in 
>>>
>>>control and 
>>>
>>>>the data plane or there is a one to many relationship? My 
>>>>interpretation of RFC3630 is that it assumes the 
>>>
>>>advertising router is 
>>>
>>>>the same as the logical node in the bearer plane that owns the 
>>>>resources. If a logical node id was added to the 
>>>
>>>advertisement for the 
>>>
>>>>node terminating the resources when the advertising router 
>>>
>>>was not the 
>>>
>>>>bearer node that owned the resources it would be clearer to me.
>>>>
>>>>Don
>>>>
>>>>
>>>>
>>>>
>>>>>Am I missing something?
>>>>>
>>>>>Adrian
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>>>>To: <[e-mail]>
>>>>>Sent: Monday, March 15, 2004 7:43 PM
>>>>>Subject: ason-routing-reqts: issue 2 architecture
>>>>>
>>>>>
>>>>
>>>>
>>>ftp://ftp.isi.edu/internet-drafts/draft-ietf-> ccamp-gmpls-ason-routing-
>>>
>>>>reqts-
>>>>02.txt
>>>>
>>>>The second DT issue is on the physical architecture which can be 
>>>>supported by GMPLS (from the draft):
>>>>
>>>>ASON does not restrict the architecture choices used, either a 
>>>>co-located architecture or a physically separated 
>>>
>>>architecture may be 
>>>
>>>>used. Some members of the Design Team are concerned that GMPLS's 
>>>>concept of the LSR requires a 1-to-1 relationship between the 
>>>>transport plane entity and the control plane entity (Router). They 
>>>>invite CCAMP input on GMPLS capabilities to support multiple 
>>>>architectures i.e. how routing protocols would identify the 
>>>
>>>transport 
>>>
>>>>node ID vs. the router or routing controller ID when 
>>>
>>>scoping Link IDs 
>>>
>>>>in a link advertisement. Deborah
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>-- 
>>>Papadimitriou Dimitri
>>>E-mail : [e-mail]
>>>E-mail : [e-mail]
>>>Webpage: http://psg.com/~dpapadimitriou/
>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>>Phone  : [phone]
>>>
>>>
>>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 20:22:48 +0000
Message-ID: <0c4d01c40b94$5a3ed8b0$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Don Fedyk" <[e-mail]>, <[e-mail]>, "Ong, Lyndon" <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Subject: Re: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 20:20:21 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C44_01C40B94.1B8A4B90"

This is a multi-part message in MIME format.

------=_NextPart_000_0C44_01C40B94.1B8A4B90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All,
Does the following picture capture what we want to achieve?


             ------------------     ------   =20
            |R1                |   |R2    |  =20
            |  --    --    --  |   |  --  |    ------
            | |L1|  |L2|  |L3| |   | |L4| |   |R3    |
            |  --    --    --  |   |  --  |   |  --  |
            |   :     :     :  |   |   :  |   | |L5| |
Control      ---+-----+-----+--     ---+--    |  --  |
Plane           :     :     :          :      |   :  |
----------------+-----+-----+----------+------+---+--+-
Data            :     :     :          :      |   :  |
Plane          --     :    --         --      |  --  |
          ----|P1|--------|P3|-------|P4|-----+-|P5|-+-
               -- \   :  / --         --      |  --  |
                   \ -- /                     |      |
                    |P2|                       ------
                     --

Pn is a physical (bearer/data/transport plane) node.
Rn is a control plane "router"
Ln is a logical control plane entity that manages a single
   physical node.

Thus:
R3 represents an LSR with all components collocated.
R2 shows how the "router" component may be disjoint from
   the switch
R1 shows how a single "router" may manage multiple switches

If you can confirm this generalisation, then we can show (or fail to =
show)
A. That this is a requirement
B. That this can be achieved using existing protocols


Cheers,
Adrian.

PS. Those not familiar with GSMP may want to take a quick peak.

----- Original Message -----=20
From: "Don Fedyk" <[e-mail]>
To: <[e-mail]>; "Ong, Lyndon" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>; "Brungard, Deborah A, ALABS" =
<[e-mail]>; <[e-mail]>
Sent: Tuesday, March 16, 2004 7:34 PM
Subject: RE: ason-routing-reqts: issue 2 architecture


> Dimitri
>=20
> If you are saying the real or logical node id that is associated with =
the
> Data (bearer) plane should be unique? I would say yes.=20
>=20
> If you are saying could it be IP address format? I would say yes. =
(Note the
> link identifiers in IP address format are unique only with respect to =
the
> node id).
>=20
> But if you say Should it then follow each piece of equipment has =
knowledge
> of this IP address format that is assigned to it? I would say no =
because
> there is equipment that won't have this for some time. (A requirement =
I
> understand from ASON).  =20
>=20
> So what I believe you are left with is some bearer equipment which has =
TE
> resources (a node Identifier (non-IP) and link identifiers (non-IP)). =
This
> equipment is known by its native identifiers to the entity in the =
control
> plane which can assign: IP format identifiers to the equipment =
(through some
> means) and an unique node identifier. This can then be advertised on =
its
> behalf as a GMPLS compatible TE LSA.=20
>=20
> This does create some challenges but in reality I think many devices =
are
> known by more than one name. (Look at VoIP, devices they have 2 =
identifiers
> E.164 and IP. I personally never use my IP address to make a VoIP =
phone call
> but I know that it is routed to a IP address along the way that is =
hidden
> from me.)
>=20
> I tend to agree with Lyndon that Topology is derived from TE =
advertisements.
> I don't understand what you could do without a unique logical node
> associated with the TE links.=20
>=20
> Don=20
>=20
> > -----Original Message-----
> > From: [e-mail]=20
> > [mailto:[e-mail]]=20
> > Sent: Tuesday, March 16, 2004 1:48 PM
> > To: Ong, Lyndon
> > Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard,=20
> > Deborah A, ALABS; [e-mail]
> > Subject: Re: ason-routing-reqts: issue 2 architecture
> >=20
> >=20
> > the problem is not an issue of being cleaner, the issue
> > is once the following assumption is taken (which is the
> > logical consequence of rfc 3630 in the gmpls context)
> >=20
> > "a stable IP address of the control plane entity that
> > manages the resources on behalf of the data plane
> > entity whose resources are being advertised."
> >=20
> > can we assume that wrt to this stable IP address the
> > resource identification will be unique (throughout
> > these multiple data plane entities) and in this case
> > it holds (no additional level of indirection needed),
> > or not (i.e. you will find duplicated id space values
> > and then an additional level of indirection is needed)
> >=20
> > the problem of the design team was not define the issue
> > but to find enough arguments wrt to the operational
> > practices (ie user community) in order to close this
> >=20
> > thanks,
> > - dimitri.
> >=20
> > Ong, Lyndon wrote:
> > > I had the same assumption as Don, that the RFC treats the=20
> > advertising=20
> > > router and the bearer plane node as the same. It would be=20
> > cleaner if=20
> > > there was also a bearer plane node identifier in the =
advertisement.
> > >=20
> > > Cheers,
> > >=20
> > > Lyndon
> > >=20
> > > -----Original Message-----
> > > From: Don Fedyk [mailto:[e-mail]]
> > > Sent: Tuesday, March 16, 2004 9:56 AM
> > > To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> > > Subject: RE: ason-routing-reqts: issue 2 architecture
> > >=20
> > >=20
> > > Hi Adrian
> > >=20
> > > See Comments Below,
> > >=20
> > >=20
> > >>-----Original Message-----
> > >>From: Adrian Farrel [mailto:[e-mail]]
> > >>Sent: Monday, March 15, 2004 4:18 PM
> > >>To: Brungard, Deborah A, ALABS; [e-mail]
> > >>Subject: Re: ason-routing-reqts: issue 2 architecture
> > >>
> > >>
> > >>I assume that the desire is to have one control plane entity
> > >>mange multiple data plane entities (not to have one data=20
> > >>plane entity managed by multiple control plane entities).
> > >=20
> > >=20
> > > I agree.
> > >=20
> > >>I believe. in this context, it might be helpful to separate
> > >>the signaling function (and the associated routing function=20
> > >>for the delivery of the signaling messages) from the TE=20
> > >>advertisement routing function. Since we are discussing the=20
> > >>routing requirements (this is the routing DT) can I assume=20
> > >>that the discussion is limited to the TE advertisement=20
> > >>routing function, with the aim to have one control plane=20
> > >>entity advertise the resources on behalf of multiple data=20
> > >>plane entities.
> > >>
> > >>If all of the above, why could you not simply do this using
> > >>RFC3630? The only wrinkle might be that the Router Address=20
> > >>TLV is described as carrying "a stable IP address of the=20
> > >>advertising router". Clearly, this needs to be interpreted as=20
> > >>"a stable IP address of the control plane entity that manages=20
> > >>the resources on behalf of the data plane entity whose=20
> > >>resources are being advertised."
> > >=20
> > >=20
> > > Interesting. I thought that you need a logical node id for=20
> > the bearer=20
> > > plane as well even though you are only advertising from a single=20
> > > entity.  In other words, is it not the desire to have the TE=20
> > > advertisements contain the same information regardless of whether=20
> > > there is a one to one correspondence between the nodes in=20
> > control and=20
> > > the data plane or there is a one to many relationship? My=20
> > > interpretation of RFC3630 is that it assumes the=20
> > advertising router is=20
> > > the same as the logical node in the bearer plane that owns the=20
> > > resources. If a logical node id was added to the=20
> > advertisement for the=20
> > > node terminating the resources when the advertising router=20
> > was not the=20
> > > bearer node that owned the resources it would be clearer to me.
> > >=20
> > > Don
> > >=20
> > >=20
> > >=20
> > >>Am I missing something?
> > >>
> > >>Adrian
> > >>
> > >>----- Original Message -----
> > >>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> > >>To: <[e-mail]>
> > >>Sent: Monday, March 15, 2004 7:43 PM
> > >>Subject: ason-routing-reqts: issue 2 architecture
> > >>
> > >>
> > >=20
> > >=20
> > ftp://ftp.isi.edu/internet-drafts/draft-ietf-> =
ccamp-gmpls-ason-routing-
> > > reqts-
> > > 02.txt
> > >=20
> > > The second DT issue is on the physical architecture which can be=20
> > > supported by GMPLS (from the draft):
> > >=20
> > > ASON does not restrict the architecture choices used, either a=20
> > > co-located architecture or a physically separated=20
> > architecture may be=20
> > > used. Some members of the Design Team are concerned that GMPLS's=20
> > > concept of the LSR requires a 1-to-1 relationship between the=20
> > > transport plane entity and the control plane entity (Router). They =

> > > invite CCAMP input on GMPLS capabilities to support multiple=20
> > > architectures i.e. how routing protocols would identify the=20
> > transport=20
> > > node ID vs. the router or routing controller ID when=20
> > scoping Link IDs=20
> > > in a link advertisement. Deborah
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> > --=20
> > Papadimitriou Dimitri
> > E-mail : [e-mail]
> > E-mail : [e-mail]
> > Webpage: http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : [phone]
> >=20
> >=20
>=20
> 
------=_NextPart_000_0C44_01C40B94.1B8A4B90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>All,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Does the following picture capture =
what we want=20
to achieve?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
------------------&nbsp;&nbsp;&nbsp;&nbsp;=20
------&nbsp;&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
|R1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;|R2&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
|&nbsp; --&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;|&nbsp; --&nbsp; |&nbsp;&nbsp;&nbsp;=20
------</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;|&nbsp;|L1|&nbsp;=20
|L2|&nbsp; |L3| |&nbsp;&nbsp;&nbsp;| |L4|&nbsp;|&nbsp;&nbsp;=20
|R3&nbsp;&nbsp;&nbsp;&nbsp;|</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;|&nbsp;=20
--&nbsp;&nbsp; &nbsp;--&nbsp;&nbsp;&nbsp; --&nbsp; =
|&nbsp;&nbsp;&nbsp;|&nbsp;=20
--&nbsp; |&nbsp;&nbsp; |&nbsp; --&nbsp; |</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
|&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;:&nbsp;&nbsp;|&nbsp;&n=
bsp; |=20
|L5| |</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Control&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

---+-----+-----+--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;---+--&nbsp;&nbsp;&nbsp;&=
nbsp;|&nbsp;=20
--&nbsp;&nbsp;|</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
:&nbsp;&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;:&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;=20
:&nbsp; |</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>----------------+-----+-----+----------+------+---+--+-</FONT></=
DIV>
<DIV><FONT face=3DCourier=20
size=3D2>Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;:&nbsp;&nbsp;&nbsp;&nbsp;=20
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;:&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp; :&nbsp; |</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>Plane&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;:&nbsp;&nbsp;&nbsp;&nbsp;--&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; --&nbsp; |</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
----|P1|--------|P3|-------|P4|-----+-|P5|-+-</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
-- \&nbsp;&nbsp;&nbsp;:&nbsp; /=20
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
|&nbsp; --&nbsp;&nbsp;|</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
\ --=20
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|P2|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;----=
--</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Pn is a physical =
(bearer/data/transport plane)=20
node.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Rn is a control plane =
"router"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Ln is a logical control plane entity =
that manages=20
a single</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; physical =
node.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thus:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>R3 represents an LSR with all =
components=20
collocated.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>R2 shows how the "router" component =
may be=20
disjoint from</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; the switch</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>R1 shows how a single "router" may =
manage=20
multiple switches</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>If you can confirm this =
generalisation, then we=20
can show (or fail to show)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>A. That this is a =
requirement</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>B. That this can be achieved using =
existing=20
protocols</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Cheers,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>PS. Those not familiar with GSMP may =
want to take=20
a quick peak.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DCourier size=3D2>From: "Don Fedyk" &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>To: &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =

size=3D2>&gt;; "Ong, Lyndon" &lt;</FONT><A =
href=3D"mailto:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Cc: "Adrian Farrel" &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;; "Brungard,=20
Deborah A, ALABS" &lt;</FONT><A href=3D"mailto:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;;=20
&lt;</FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Sent: Tuesday, March 16, 2004 7:34=20
PM</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Subject: RE: ason-routing-reqts: =
issue 2=20
architecture</FONT></DIV></DIV>
<DIV><FONT face=3DCourier><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DCourier=20
size=3D2>&gt; Dimitri<BR>&gt; <BR>&gt; If you are saying the real or =
logical node=20
id that is associated with the<BR>&gt; Data (bearer) plane should be =
unique? I=20
would say yes. <BR>&gt; <BR>&gt; If you are saying could it be IP =
address=20
format? I would say yes. (Note the<BR>&gt; link identifiers in IP =
address format=20
are unique only with respect to the<BR>&gt; node id).<BR>&gt; <BR>&gt; =
But if=20
you say Should it then follow each piece of equipment has =
knowledge<BR>&gt; of=20
this IP address format that is assigned to it? I would say no =
because<BR>&gt;=20
there is equipment that won't have this for some time. (A requirement =
I<BR>&gt;=20
understand from ASON).&nbsp;&nbsp; <BR>&gt; <BR>&gt; So what I believe =
you are=20
left with is some bearer equipment which has TE<BR>&gt; resources (a =
node=20
Identifier (non-IP) and link identifiers (non-IP)). This<BR>&gt; =
equipment is=20
known by its native identifiers to the entity in the control<BR>&gt; =
plane which=20
can assign: IP format identifiers to the equipment (through some<BR>&gt; =
means)=20
and an unique node identifier. This can then be advertised on =
its<BR>&gt; behalf=20
as a GMPLS compatible TE LSA. <BR>&gt; <BR>&gt; This does create some =
challenges=20
but in reality I think many devices are<BR>&gt; known by more than one =
name.=20
(Look at VoIP, devices they have 2 identifiers<BR>&gt; E.164 and IP. I=20
personally never use my IP address to make a VoIP phone call<BR>&gt; but =
I know=20
that it is routed to a IP address along the way that is hidden<BR>&gt; =
from=20
me.)<BR>&gt; <BR>&gt; I tend to agree with Lyndon that Topology is =
derived from=20
TE advertisements.<BR>&gt; I don't understand what you could do without =
a unique=20
logical node<BR>&gt; associated with the TE links. <BR>&gt; <BR>&gt; Don =

<BR>&gt; <BR>&gt; &gt; -----Original Message-----<BR>&gt; &gt; From: =
</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>=20
<BR>&gt; &gt; [mailto:[e-mail]] <BR>&gt; &gt; =
Sent:=20
Tuesday, March 16, 2004 1:48 PM<BR>&gt; &gt; To: Ong, Lyndon<BR>&gt; =
&gt; Cc:=20
Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, <BR>&gt; &gt; =
Deborah A,=20
ALABS; </FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier =

size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; &gt;=20
Subject: Re: ason-routing-reqts: issue 2 architecture<BR>&gt; &gt; =
<BR>&gt; &gt;=20
<BR>&gt; &gt; the problem is not an issue of being cleaner, the =
issue<BR>&gt;=20
&gt; is once the following assumption is taken (which is the<BR>&gt; =
&gt;=20
logical consequence of rfc 3630 in the gmpls context)<BR>&gt; &gt; =
<BR>&gt; &gt;=20
"a stable IP address of the control plane entity that<BR>&gt; &gt; =
manages the=20
resources on behalf of the data plane<BR>&gt; &gt; entity whose =
resources are=20
being advertised."<BR>&gt; &gt; <BR>&gt; &gt; can we assume that wrt to =
this=20
stable IP address the<BR>&gt; &gt; resource identification will be =
unique=20
(throughout<BR>&gt; &gt; these multiple data plane entities) and in this =

case<BR>&gt; &gt; it holds (no additional level of indirection =
needed),<BR>&gt;=20
&gt; or not (i.e. you will find duplicated id space values<BR>&gt; &gt; =
and then=20
an additional level of indirection is needed)<BR>&gt; &gt; <BR>&gt; &gt; =
the=20
problem of the design team was not define the issue<BR>&gt; &gt; but to =
find=20
enough arguments wrt to the operational<BR>&gt; &gt; practices (ie user=20
community) in order to close this<BR>&gt; &gt; <BR>&gt; &gt; =
thanks,<BR>&gt;=20
&gt; - dimitri.<BR>&gt; &gt; <BR>&gt; &gt; Ong, Lyndon wrote:<BR>&gt; =
&gt; &gt;=20
I had the same assumption as Don, that the RFC treats the <BR>&gt; &gt;=20
advertising <BR>&gt; &gt; &gt; router and the bearer plane node as the =
same. It=20
would be <BR>&gt; &gt; cleaner if <BR>&gt; &gt; &gt; there was also a =
bearer=20
plane node identifier in the advertisement.<BR>&gt; &gt; &gt; <BR>&gt; =
&gt; &gt;=20
Cheers,<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; Lyndon<BR>&gt; &gt; &gt; =
<BR>&gt;=20
&gt; &gt; -----Original Message-----<BR>&gt; &gt; &gt; From: Don Fedyk=20
[mailto:[e-mail]]<BR>&gt; &gt; &gt; Sent: Tuesday, =
March 16,=20
2004 9:56 AM<BR>&gt; &gt; &gt; To: Adrian Farrel; Brungard, Deborah A, =
ALABS;=20
</FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; &gt; &gt;=20
Subject: RE: ason-routing-reqts: issue 2 architecture<BR>&gt; &gt; &gt; =
<BR>&gt;=20
&gt; &gt; <BR>&gt; &gt; &gt; Hi Adrian<BR>&gt; &gt; &gt; <BR>&gt; &gt; =
&gt; See=20
Comments Below,<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; <BR>&gt; &gt;=20
&gt;&gt;-----Original Message-----<BR>&gt; &gt; &gt;&gt;From: Adrian =
Farrel=20
[mailto:[e-mail]]<BR>&gt; &gt; &gt;&gt;Sent: Monday, March =
15, 2004=20
4:18 PM<BR>&gt; &gt; &gt;&gt;To: Brungard, Deborah A, ALABS; </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; &gt;=20
&gt;&gt;Subject: Re: ason-routing-reqts: issue 2 architecture<BR>&gt; =
&gt;=20
&gt;&gt;<BR>&gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt;&gt;I assume that the =
desire is=20
to have one control plane entity<BR>&gt; &gt; &gt;&gt;mange multiple =
data plane=20
entities (not to have one data <BR>&gt; &gt; &gt;&gt;plane entity =
managed by=20
multiple control plane entities).<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; =
<BR>&gt;=20
&gt; &gt; I agree.<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt;&gt;I believe. in =
this=20
context, it might be helpful to separate<BR>&gt; &gt; &gt;&gt;the =
signaling=20
function (and the associated routing function <BR>&gt; &gt; &gt;&gt;for =
the=20
delivery of the signaling messages) from the TE <BR>&gt; &gt;=20
&gt;&gt;advertisement routing function. Since we are discussing the =
<BR>&gt;=20
&gt; &gt;&gt;routing requirements (this is the routing DT) can I assume =
<BR>&gt;=20
&gt; &gt;&gt;that the discussion is limited to the TE advertisement =
<BR>&gt;=20
&gt; &gt;&gt;routing function, with the aim to have one control plane =
<BR>&gt;=20
&gt; &gt;&gt;entity advertise the resources on behalf of multiple data =
<BR>&gt;=20
&gt; &gt;&gt;plane entities.<BR>&gt; &gt; &gt;&gt;<BR>&gt; &gt; =
&gt;&gt;If all=20
of the above, why could you not simply do this using<BR>&gt; &gt;=20
&gt;&gt;RFC3630? The only wrinkle might be that the Router Address =
<BR>&gt; &gt;=20
&gt;&gt;TLV is described as carrying "a stable IP address of the =
<BR>&gt; &gt;=20
&gt;&gt;advertising router". Clearly, this needs to be interpreted as =
<BR>&gt;=20
&gt; &gt;&gt;"a stable IP address of the control plane entity that =
manages=20
<BR>&gt; &gt; &gt;&gt;the resources on behalf of the data plane entity =
whose=20
<BR>&gt; &gt; &gt;&gt;resources are being advertised."<BR>&gt; &gt; &gt; =

<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; Interesting. I thought that you =
need a=20
logical node id for <BR>&gt; &gt; the bearer <BR>&gt; &gt; &gt; plane as =
well=20
even though you are only advertising from a single <BR>&gt; &gt; &gt;=20
entity.&nbsp; In other words, is it not the desire to have the TE =
<BR>&gt; &gt;=20
&gt; advertisements contain the same information regardless of whether =
<BR>&gt;=20
&gt; &gt; there is a one to one correspondence between the nodes in =
<BR>&gt;=20
&gt; control and <BR>&gt; &gt; &gt; the data plane or there is a one to =
many=20
relationship? My <BR>&gt; &gt; &gt; interpretation of RFC3630 is that it =
assumes=20
the <BR>&gt; &gt; advertising router is <BR>&gt; &gt; &gt; the same as =
the=20
logical node in the bearer plane that owns the <BR>&gt; &gt; &gt; =
resources. If=20
a logical node id was added to the <BR>&gt; &gt; advertisement for the =
<BR>&gt;=20
&gt; &gt; node terminating the resources when the advertising router =
<BR>&gt;=20
&gt; was not the <BR>&gt; &gt; &gt; bearer node that owned the resources =
it=20
would be clearer to me.<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; Don<BR>&gt; =
&gt;=20
&gt; <BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt;&gt;Am I =
missing=20
something?<BR>&gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt;&gt;Adrian<BR>&gt; =
&gt;=20
&gt;&gt;<BR>&gt; &gt; &gt;&gt;----- Original Message -----<BR>&gt; &gt;=20
&gt;&gt;From: "Brungard, Deborah A, ALABS" &lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;<BR>&gt; &gt;=20
&gt;&gt;To: &lt;</FONT><A href=3D"mailto:[e-mail]"><FONT =
face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;<BR>&gt; &gt;=20
&gt;&gt;Sent: Monday, March 15, 2004 7:43 PM<BR>&gt; &gt; =
&gt;&gt;Subject:=20
ason-routing-reqts: issue 2 architecture<BR>&gt; &gt; &gt;&gt;<BR>&gt; =
&gt;=20
&gt;&gt;<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; <BR>&gt; &gt; </FONT><A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf"><FONT =
face=3DCourier=20
size=3D2>ftp://ftp.isi.edu/internet-drafts/draft-ietf</FONT></A><FONT =
face=3DCourier=20
size=3D2>-&gt; ccamp-gmpls-ason-routing-<BR>&gt; &gt; &gt; =
reqts-<BR>&gt; &gt;=20
&gt; 02.txt<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; The second DT issue is =
on the=20
physical architecture which can be <BR>&gt; &gt; &gt; supported by GMPLS =
(from=20
the draft):<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; ASON does not restrict =
the=20
architecture choices used, either a <BR>&gt; &gt; &gt; co-located =
architecture=20
or a physically separated <BR>&gt; &gt; architecture may be <BR>&gt; =
&gt; &gt;=20
used. Some members of the Design Team are concerned that GMPLS's =
<BR>&gt; &gt;=20
&gt; concept of the LSR requires a 1-to-1 relationship between the =
<BR>&gt; &gt;=20
&gt; transport plane entity and the control plane entity (Router). They =
<BR>&gt;=20
&gt; &gt; invite CCAMP input on GMPLS capabilities to support multiple =
<BR>&gt;=20
&gt; &gt; architectures i.e. how routing protocols would identify the =
<BR>&gt;=20
&gt; transport <BR>&gt; &gt; &gt; node ID vs. the router or routing =
controller=20
ID when <BR>&gt; &gt; scoping Link IDs <BR>&gt; &gt; &gt; in a link=20
advertisement. Deborah<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; <BR>&gt; =
&gt; &gt;=20
<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; -- =
<BR>&gt;=20
&gt; Papadimitriou Dimitri<BR>&gt; &gt; E-mail : </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT =
face=3DCourier=20
size=3D2>&gt; &gt; E-mail : </FONT><A =
href=3D"mailto:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</FONT></A><BR><FONT =
face=3DCourier=20
size=3D2>&gt; &gt; Webpage: </FONT><A =
href=3D"http://psg.com/~dpapadimitriou/"><FONT=20
face=3DCourier =
size=3D2>http://psg.com/~dpapadimitriou/</FONT></A><BR><FONT=20
face=3DCourier size=3D2>&gt; &gt; Address: Fr. Wellesplein 1, B-2018 =
Antwerpen,=20
Belgium<BR>&gt; &gt; Phone&nbsp; : [phone]<BR>&gt; &gt; <BR>&gt; =
&gt;=20
<BR>&gt; <BR>&gt; </FONT></BODY></HTML>

------=_NextPart_000_0C44_01C40B94.1B8A4B90--




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 20:13:11 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 2004 21:13:53 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Don Fedyk <[e-mail]>
Cc: "Ong, Lyndon" <[e-mail]>, Adrian Farrel <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

don,

> If you are saying the real or logical node id that is associated with the
> Data (bearer) plane should be unique? I would say yes. 

see below

> If you are saying could it be IP address format? I would say yes. (Note the
> link identifiers in IP address format are unique only with respect to the
> node id).

see below

> But if you say Should it then follow each piece of equipment has knowledge
> of this IP address format that is assigned to it? I would say no because
> there is equipment that won't have this for some time. (A requirement I
> understand from ASON).   

i'll restate, because i think the issue is, can a CP entity be
assigned an IP address from which all links could be addressed
independently of their physical distribution (single data
plane entity or multiple data plane entity)

> So what I believe you are left with is some bearer equipment which has TE
> resources (a node Identifier (non-IP) and link identifiers (non-IP)). This
> equipment is known by its native identifiers to the entity in the control
> plane which can assign: IP format identifiers to the equipment (through some
> means) and an unique node identifier. This can then be advertised on its
> behalf as a GMPLS compatible TE LSA. 

again here, if the concatenation <IP address, id> allows to
uniquely identify all the "logical node end-points" at the
control plane level then independently of the native data
plane address space value, we're fine (there is no need
to duplicate the identifier of the owner of this space)

> This does create some challenges but in reality I think many devices are
> known by more than one name. (Look at VoIP, devices they have 2 identifiers
> E.164 and IP. I personally never use my IP address to make a VoIP phone call
> but I know that it is routed to a IP address along the way that is hidden
> from me.)
> 
> I tend to agree with Lyndon that Topology is derived from TE advertisements.
> I don't understand what you could do without a unique logical node
> associated with the TE links. 

i don't think the issue is on feasibility (both are here
feasible and works) it is to assess whether at the control
plane level an additional level of indirection is *required*
to identify the DP resources or not - and it just a practice
issue, does the user community assign an IP address to each
of their node and then on top another for the log. construct
that they can map to the router address or do they assign an
address for the logical construct and then number each of the
endpoints, it may even be that both are required, you will
also see that in each case the response to your 1st question
is yes and the second one as well

note: i'm not saying also that it is the only issue here, but
we have to start from somewhere in order to solve this

> Don 
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] 
>>Sent: Tuesday, March 16, 2004 1:48 PM
>>To: Ong, Lyndon
>>Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, 
>>Deborah A, ALABS; [e-mail]
>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>
>>
>>the problem is not an issue of being cleaner, the issue
>>is once the following assumption is taken (which is the
>>logical consequence of rfc 3630 in the gmpls context)
>>
>>"a stable IP address of the control plane entity that
>>manages the resources on behalf of the data plane
>>entity whose resources are being advertised."
>>
>>can we assume that wrt to this stable IP address the
>>resource identification will be unique (throughout
>>these multiple data plane entities) and in this case
>>it holds (no additional level of indirection needed),
>>or not (i.e. you will find duplicated id space values
>>and then an additional level of indirection is needed)
>>
>>the problem of the design team was not define the issue
>>but to find enough arguments wrt to the operational
>>practices (ie user community) in order to close this
>>
>>thanks,
>>- dimitri.
>>
>>Ong, Lyndon wrote:
>>
>>>I had the same assumption as Don, that the RFC treats the 
>>
>>advertising 
>>
>>>router and the bearer plane node as the same. It would be 
>>
>>cleaner if 
>>
>>>there was also a bearer plane node identifier in the advertisement.
>>>
>>>Cheers,
>>>
>>>Lyndon
>>>
>>>-----Original Message-----
>>>From: Don Fedyk [mailto:[e-mail]]
>>>Sent: Tuesday, March 16, 2004 9:56 AM
>>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
>>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>>
>>>
>>>Hi Adrian
>>>
>>>See Comments Below,
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Adrian Farrel [mailto:[e-mail]]
>>>>Sent: Monday, March 15, 2004 4:18 PM
>>>>To: Brungard, Deborah A, ALABS; [e-mail]
>>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>>
>>>>
>>>>I assume that the desire is to have one control plane entity
>>>>mange multiple data plane entities (not to have one data 
>>>>plane entity managed by multiple control plane entities).
>>>
>>>
>>>I agree.
>>>
>>>
>>>>I believe. in this context, it might be helpful to separate
>>>>the signaling function (and the associated routing function 
>>>>for the delivery of the signaling messages) from the TE 
>>>>advertisement routing function. Since we are discussing the 
>>>>routing requirements (this is the routing DT) can I assume 
>>>>that the discussion is limited to the TE advertisement 
>>>>routing function, with the aim to have one control plane 
>>>>entity advertise the resources on behalf of multiple data 
>>>>plane entities.
>>>>
>>>>If all of the above, why could you not simply do this using
>>>>RFC3630? The only wrinkle might be that the Router Address 
>>>>TLV is described as carrying "a stable IP address of the 
>>>>advertising router". Clearly, this needs to be interpreted as 
>>>>"a stable IP address of the control plane entity that manages 
>>>>the resources on behalf of the data plane entity whose 
>>>>resources are being advertised."
>>>
>>>
>>>Interesting. I thought that you need a logical node id for 
>>
>>the bearer 
>>
>>>plane as well even though you are only advertising from a single 
>>>entity.  In other words, is it not the desire to have the TE 
>>>advertisements contain the same information regardless of whether 
>>>there is a one to one correspondence between the nodes in 
>>
>>control and 
>>
>>>the data plane or there is a one to many relationship? My 
>>>interpretation of RFC3630 is that it assumes the 
>>
>>advertising router is 
>>
>>>the same as the logical node in the bearer plane that owns the 
>>>resources. If a logical node id was added to the 
>>
>>advertisement for the 
>>
>>>node terminating the resources when the advertising router 
>>
>>was not the 
>>
>>>bearer node that owned the resources it would be clearer to me.
>>>
>>>Don
>>>
>>>
>>>
>>>
>>>>Am I missing something?
>>>>
>>>>Adrian
>>>>
>>>>----- Original Message -----
>>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>>>To: <[e-mail]>
>>>>Sent: Monday, March 15, 2004 7:43 PM
>>>>Subject: ason-routing-reqts: issue 2 architecture
>>>>
>>>>
>>>
>>>
>>ftp://ftp.isi.edu/internet-drafts/draft-ietf-> ccamp-gmpls-ason-routing-
>>
>>>reqts-
>>>02.txt
>>>
>>>The second DT issue is on the physical architecture which can be 
>>>supported by GMPLS (from the draft):
>>>
>>>ASON does not restrict the architecture choices used, either a 
>>>co-located architecture or a physically separated 
>>
>>architecture may be 
>>
>>>used. Some members of the Design Team are concerned that GMPLS's 
>>>concept of the LSR requires a 1-to-1 relationship between the 
>>>transport plane entity and the control plane entity (Router). They 
>>>invite CCAMP input on GMPLS capabilities to support multiple 
>>>architectures i.e. how routing protocols would identify the 
>>
>>transport 
>>
>>>node ID vs. the router or routing controller ID when 
>>
>>scoping Link IDs 
>>
>>>in a link advertisement. Deborah
>>>
>>>
>>>
>>>
>>>
>>
>>-- 
>>Papadimitriou Dimitri
>>E-mail : [e-mail]
>>E-mail : [e-mail]
>>Webpage: http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : [phone]
>>
>>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 19:48:40 +0000
Message-ID: <0bee01c40b8f$9c9b5170$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Don't forget to ask the questions carried over from Seoul
Date: Tue, 16 Mar 2004 18:56:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I know a lot of you were frustrated at the microphone in Seoul.
Apologies for having such a full agenda that very little discussion was possible (ideas to
manage this would be very welcome off-list).

Please don't forget to raise the issues that you wanted to discuss by sending mail to the
list.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 19:41:43 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 2004 20:42:39 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: "Ong, Lyndon" <[e-mail]>
Cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 1 addressing
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi lyndon,

some hints in-line, i start worrying about the arguments
you've been listed here below since here except (2) they
are not related to this issue 1:

Ong, Lyndon wrote:

> Hi Folks,
> 
> Let me kick off some discussion on issue 1 by noting some of the 
> concerns with using existing methods of advertising reachability for
> this purpose:
> 
> 1) the client system may not be an IP system, but another transport 
> device with an IP control interface - for example, an ADM (add-drop 
> multiplexer) acting as a client to an optical network.  Advertising 
> reachability using normal means might imply that the system can be 
> used for IP traffic routing.

-> the SC capability of the end-point is orthogonal to its
    numbering (in addition, this way of thinking will make us
    advertising MAC addresses when end-points will terminate
    Ethernet)

> 2) the client system may use a different addressing space than the 
> internal network addressing space.  Carriers may wish to use a 
> different addressing space for administrative or policy reasons.

-> i don't think there is any discussion here, the thread
    focuses on "external" reachability - and this is the
    issue, how this "external" reachability information
    needs to be advertised to maintain the properties of
    the control plane (in particular scalability)

> (Note: one model for this is the VPN model, which would allow private
> networks to have their own address spaces.  Another model is a
> telephone number-like model, where clients obtain addresses from a
> space maintained by the carrier.)
> 
> 3) the client system may use a non-IP address for compatibility 
> reasons, for example, a client with an existing management plane 
> address that the carrier wants to access without having to add a new
> address and translation mechanism.

-> mapping of MP <-> CP and CP <-> DP are outside the scope
    of the present discussion, note if your argument was valid,
    the argument (2) wouldn't since in this case you would
    have been advertising your management plane addresses

> Cheers,
> 
> Lyndon
> 
> -----Original Message----- From: Brungard, Deborah A, ALABS
> [mailto:[e-mail]] Sent: Monday, March 15, 2004 11:29 AM To:
> [e-mail] Subject: ason-routing-reqts: issue 1 addressing
> 
> 
> As noted in the CCAMP minutes and the DT's presentation, the ASON
> routing DT had three issues regarding GMPLS support for which they
> lacked agreement and request support of the WG. The issues are
> identified in Section 7 (Conclusions) of the draft: 
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
> 
> 
> I will post three separate email threads to cover each issue. The
> first issue is on address reachability. The following is the text
> from the draft:
> 
> Some members of the Design Team noted that reachability information
> (as described in Section 4.5.3) may be advertised as a set of UNI
> Transport Resource address prefixes (assigned and selected
> consistently in their applicability scope). These members of the
> Design Team raised a concern that existing methods of advertising
> reachability may need to be examined (on a per-protocol basis) to
> determine if they are also applicable for UNI Transport Resource
> addresses. They invite CCAMP discussion on this aspect. Deborah
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 19:35:57 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: [e-mail], "Ong, Lyndon" <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 14:34:41 -0500

Dimitri

If you are saying the real or logical node id that is associated with the
Data (bearer) plane should be unique? I would say yes. 

If you are saying could it be IP address format? I would say yes. (Note the
link identifiers in IP address format are unique only with respect to the
node id).

But if you say Should it then follow each piece of equipment has knowledge
of this IP address format that is assigned to it? I would say no because
there is equipment that won't have this for some time. (A requirement I
understand from ASON).   

So what I believe you are left with is some bearer equipment which has TE
resources (a node Identifier (non-IP) and link identifiers (non-IP)). This
equipment is known by its native identifiers to the entity in the control
plane which can assign: IP format identifiers to the equipment (through some
means) and an unique node identifier. This can then be advertised on its
behalf as a GMPLS compatible TE LSA. 

This does create some challenges but in reality I think many devices are
known by more than one name. (Look at VoIP, devices they have 2 identifiers
E.164 and IP. I personally never use my IP address to make a VoIP phone call
but I know that it is routed to a IP address along the way that is hidden
from me.)

I tend to agree with Lyndon that Topology is derived from TE advertisements.
I don't understand what you could do without a unique logical node
associated with the TE links. 

Don 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 
> Sent: Tuesday, March 16, 2004 1:48 PM
> To: Ong, Lyndon
> Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard, 
> Deborah A, ALABS; [e-mail]
> Subject: Re: ason-routing-reqts: issue 2 architecture
> 
> 
> the problem is not an issue of being cleaner, the issue
> is once the following assumption is taken (which is the
> logical consequence of rfc 3630 in the gmpls context)
> 
> "a stable IP address of the control plane entity that
> manages the resources on behalf of the data plane
> entity whose resources are being advertised."
> 
> can we assume that wrt to this stable IP address the
> resource identification will be unique (throughout
> these multiple data plane entities) and in this case
> it holds (no additional level of indirection needed),
> or not (i.e. you will find duplicated id space values
> and then an additional level of indirection is needed)
> 
> the problem of the design team was not define the issue
> but to find enough arguments wrt to the operational
> practices (ie user community) in order to close this
> 
> thanks,
> - dimitri.
> 
> Ong, Lyndon wrote:
> > I had the same assumption as Don, that the RFC treats the 
> advertising 
> > router and the bearer plane node as the same. It would be 
> cleaner if 
> > there was also a bearer plane node identifier in the advertisement.
> > 
> > Cheers,
> > 
> > Lyndon
> > 
> > -----Original Message-----
> > From: Don Fedyk [mailto:[e-mail]]
> > Sent: Tuesday, March 16, 2004 9:56 AM
> > To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> > Subject: RE: ason-routing-reqts: issue 2 architecture
> > 
> > 
> > Hi Adrian
> > 
> > See Comments Below,
> > 
> > 
> >>-----Original Message-----
> >>From: Adrian Farrel [mailto:[e-mail]]
> >>Sent: Monday, March 15, 2004 4:18 PM
> >>To: Brungard, Deborah A, ALABS; [e-mail]
> >>Subject: Re: ason-routing-reqts: issue 2 architecture
> >>
> >>
> >>I assume that the desire is to have one control plane entity
> >>mange multiple data plane entities (not to have one data 
> >>plane entity managed by multiple control plane entities).
> > 
> > 
> > I agree.
> > 
> >>I believe. in this context, it might be helpful to separate
> >>the signaling function (and the associated routing function 
> >>for the delivery of the signaling messages) from the TE 
> >>advertisement routing function. Since we are discussing the 
> >>routing requirements (this is the routing DT) can I assume 
> >>that the discussion is limited to the TE advertisement 
> >>routing function, with the aim to have one control plane 
> >>entity advertise the resources on behalf of multiple data 
> >>plane entities.
> >>
> >>If all of the above, why could you not simply do this using
> >>RFC3630? The only wrinkle might be that the Router Address 
> >>TLV is described as carrying "a stable IP address of the 
> >>advertising router". Clearly, this needs to be interpreted as 
> >>"a stable IP address of the control plane entity that manages 
> >>the resources on behalf of the data plane entity whose 
> >>resources are being advertised."
> > 
> > 
> > Interesting. I thought that you need a logical node id for 
> the bearer 
> > plane as well even though you are only advertising from a single 
> > entity.  In other words, is it not the desire to have the TE 
> > advertisements contain the same information regardless of whether 
> > there is a one to one correspondence between the nodes in 
> control and 
> > the data plane or there is a one to many relationship? My 
> > interpretation of RFC3630 is that it assumes the 
> advertising router is 
> > the same as the logical node in the bearer plane that owns the 
> > resources. If a logical node id was added to the 
> advertisement for the 
> > node terminating the resources when the advertising router 
> was not the 
> > bearer node that owned the resources it would be clearer to me.
> > 
> > Don
> > 
> > 
> > 
> >>Am I missing something?
> >>
> >>Adrian
> >>
> >>----- Original Message -----
> >>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> >>To: <[e-mail]>
> >>Sent: Monday, March 15, 2004 7:43 PM
> >>Subject: ason-routing-reqts: issue 2 architecture
> >>
> >>
> > 
> > 
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-> ccamp-gmpls-ason-routing-
> > reqts-
> > 02.txt
> > 
> > The second DT issue is on the physical architecture which can be 
> > supported by GMPLS (from the draft):
> > 
> > ASON does not restrict the architecture choices used, either a 
> > co-located architecture or a physically separated 
> architecture may be 
> > used. Some members of the Design Team are concerned that GMPLS's 
> > concept of the LSR requires a 1-to-1 relationship between the 
> > transport plane entity and the control plane entity (Router). They 
> > invite CCAMP input on GMPLS capabilities to support multiple 
> > architectures i.e. how routing protocols would identify the 
> transport 
> > node ID vs. the router or routing controller ID when 
> scoping Link IDs 
> > in a link advertisement. Deborah
> > 
> > 
> > 
> > 
> > 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : [e-mail]
> E-mail : [e-mail]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : [phone]
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 19:10:10 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 2004 20:11:08 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: "Ong, Lyndon" <[e-mail]>
Cc: "'Don Fedyk'" <[e-mail]>, Adrian Farrel <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi lyndon,

Ong, Lyndon wrote:
> Hi Dimitri,
> 
> Can you reference the quote?  Thanks (could not find it
> in 3630).

this is part of the task we're currently trying to sort
out (i've said a logical consequence or said in another
way interpretation)

> Also one side note - one thing to keep in mind is that
> people on the transport network side may be looking at
> the routing protocol to provide more than just pure
> connection routing functions, e.g., it may also provide
> a topological map of the transport network in a way that
> is easier to access than using the management system to
> contact each node.  In this regard, you could have a single
> control plane entity managing many data plane entities and
> still want to advertise the existence and connectivity of
> the data plane entities.

it is possible, keeping the below interpretation, the
question is (repeating myself) does each of the data
plane entities maintain its own id_space or can we
assume that each of them is part of a larger address
space

thanks for the side note anyway which is completely
orthogonal to the management system,

- dimitri.
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 10:48 AM
> To: Ong, Lyndon
> Cc: 'Don Fedyk'; Adrian Farrel; Brungard, Deborah A, ALABS;
> [e-mail]
> Subject: Re: ason-routing-reqts: issue 2 architecture
> 
> 
> the problem is not an issue of being cleaner, the issue
> is once the following assumption is taken (which is the
> logical consequence of rfc 3630 in the gmpls context)
> 
> "a stable IP address of the control plane entity that
> manages the resources on behalf of the data plane
> entity whose resources are being advertised."
> 
> can we assume that wrt to this stable IP address the
> resource identification will be unique (throughout
> these multiple data plane entities) and in this case
> it holds (no additional level of indirection needed),
> or not (i.e. you will find duplicated id space values
> and then an additional level of indirection is needed)
> 
> the problem of the design team was not define the issue
> but to find enough arguments wrt to the operational
> practices (ie user community) in order to close this
> 
> thanks,
> - dimitri.
> 
> Ong, Lyndon wrote:
> 
>>I had the same assumption as Don, that the RFC treats the
>>advertising router and the bearer plane node as the same.
>>It would be cleaner if there was also a bearer plane node
>>identifier in the advertisement.
>>
>>Cheers,
>>
>>Lyndon
>>
>>-----Original Message-----
>>From: Don Fedyk [mailto:[e-mail]]
>>Sent: Tuesday, March 16, 2004 9:56 AM
>>To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
>>Subject: RE: ason-routing-reqts: issue 2 architecture
>>
>>
>>Hi Adrian
>>
>>See Comments Below,
>>
>>
>>
>>>-----Original Message-----
>>>From: Adrian Farrel [mailto:[e-mail]] 
>>>Sent: Monday, March 15, 2004 4:18 PM
>>>To: Brungard, Deborah A, ALABS; [e-mail]
>>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>>
>>>
>>>I assume that the desire is to have one control plane entity 
>>>mange multiple data plane entities (not to have one data 
>>>plane entity managed by multiple control plane entities).
>>
>>
>>I agree.
>>
>>
>>>I believe. in this context, it might be helpful to separate 
>>>the signaling function (and the associated routing function 
>>>for the delivery of the signaling messages) from the TE 
>>>advertisement routing function. Since we are discussing the 
>>>routing requirements (this is the routing DT) can I assume 
>>>that the discussion is limited to the TE advertisement 
>>>routing function, with the aim to have one control plane 
>>>entity advertise the resources on behalf of multiple data 
>>>plane entities.
>>>
>>>If all of the above, why could you not simply do this using 
>>>RFC3630? The only wrinkle might be that the Router Address 
>>>TLV is described as carrying "a stable IP address of the 
>>>advertising router". Clearly, this needs to be interpreted as 
>>>"a stable IP address of the control plane entity that manages 
>>>the resources on behalf of the data plane entity whose 
>>>resources are being advertised."
>>
>>
>>Interesting. I thought that you need a logical node id for the bearer plane
>>as well even though you are only advertising from a single entity.  In other
>>words, is it not the desire to have the TE advertisements contain the same
>>information regardless of whether there is a one to one correspondence
>>between the nodes in control and the data plane or there is a one to many
>>relationship? My interpretation of RFC3630 is that it assumes the
>>advertising router is the same as the logical node in the bearer plane that
>>owns the resources. If a logical node id was added to the advertisement for
>>the node terminating the resources when the advertising router was not the
>>bearer node that owned the resources it would be clearer to me. 
>>
>>Don 
>>
>>
>>
>>
>>>Am I missing something?
>>>
>>>Adrian
>>>
>>>----- Original Message ----- 
>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>>To: <[e-mail]>
>>>Sent: Monday, March 15, 2004 7:43 PM
>>>Subject: ason-routing-reqts: issue 2 architecture
>>>
>>>
>>
>>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-
>>02.txt
>>
>>The second DT issue is on the physical architecture which can be supported
>>by GMPLS (from the draft):
>>
>>ASON does not restrict the architecture choices used, either a co-located
>>architecture or a physically separated architecture may be used. Some
>>members of the Design Team are concerned that GMPLS's concept of the LSR
>>requires a 1-to-1 relationship between the transport plane entity and the
>>control plane entity (Router). They invite CCAMP input on GMPLS capabilities
>>to support multiple architectures i.e. how routing protocols would identify
>>the transport node ID vs. the router or routing controller ID when scoping
>>Link IDs in a link advertisement. Deborah
>>
>>
>>
>>
>>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 19:00:19 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: 'Don Fedyk' <[e-mail]>, Adrian Farrel <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>,  [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 10:59:15 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Dimitri,

Can you reference the quote?  Thanks (could not find it
in 3630).

Also one side note - one thing to keep in mind is that
people on the transport network side may be looking at
the routing protocol to provide more than just pure
connection routing functions, e.g., it may also provide
a topological map of the transport network in a way that
is easier to access than using the management system to
contact each node.  In this regard, you could have a single
control plane entity managing many data plane entities and
still want to advertise the existence and connectivity of
the data plane entities.

Cheers,

Lyndon

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Tuesday, March 16, 2004 10:48 AM
To: Ong, Lyndon
Cc: 'Don Fedyk'; Adrian Farrel; Brungard, Deborah A, ALABS;
[e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture


the problem is not an issue of being cleaner, the issue
is once the following assumption is taken (which is the
logical consequence of rfc 3630 in the gmpls context)

"a stable IP address of the control plane entity that
manages the resources on behalf of the data plane
entity whose resources are being advertised."

can we assume that wrt to this stable IP address the
resource identification will be unique (throughout
these multiple data plane entities) and in this case
it holds (no additional level of indirection needed),
or not (i.e. you will find duplicated id space values
and then an additional level of indirection is needed)

the problem of the design team was not define the issue
but to find enough arguments wrt to the operational
practices (ie user community) in order to close this

thanks,
- dimitri.

Ong, Lyndon wrote:
> I had the same assumption as Don, that the RFC treats the
> advertising router and the bearer plane node as the same.
> It would be cleaner if there was also a bearer plane node
> identifier in the advertisement.
> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: Don Fedyk [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 9:56 AM
> To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> Subject: RE: ason-routing-reqts: issue 2 architecture
> 
> 
> Hi Adrian
> 
> See Comments Below,
> 
> 
>>-----Original Message-----
>>From: Adrian Farrel [mailto:[e-mail]] 
>>Sent: Monday, March 15, 2004 4:18 PM
>>To: Brungard, Deborah A, ALABS; [e-mail]
>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>
>>
>>I assume that the desire is to have one control plane entity 
>>mange multiple data plane entities (not to have one data 
>>plane entity managed by multiple control plane entities).
> 
> 
> I agree.
> 
>>I believe. in this context, it might be helpful to separate 
>>the signaling function (and the associated routing function 
>>for the delivery of the signaling messages) from the TE 
>>advertisement routing function. Since we are discussing the 
>>routing requirements (this is the routing DT) can I assume 
>>that the discussion is limited to the TE advertisement 
>>routing function, with the aim to have one control plane 
>>entity advertise the resources on behalf of multiple data 
>>plane entities.
>>
>>If all of the above, why could you not simply do this using 
>>RFC3630? The only wrinkle might be that the Router Address 
>>TLV is described as carrying "a stable IP address of the 
>>advertising router". Clearly, this needs to be interpreted as 
>>"a stable IP address of the control plane entity that manages 
>>the resources on behalf of the data plane entity whose 
>>resources are being advertised."
> 
> 
> Interesting. I thought that you need a logical node id for the bearer plane
> as well even though you are only advertising from a single entity.  In other
> words, is it not the desire to have the TE advertisements contain the same
> information regardless of whether there is a one to one correspondence
> between the nodes in control and the data plane or there is a one to many
> relationship? My interpretation of RFC3630 is that it assumes the
> advertising router is the same as the logical node in the bearer plane that
> owns the resources. If a logical node id was added to the advertisement for
> the node terminating the resources when the advertising router was not the
> bearer node that owned the resources it would be clearer to me. 
> 
> Don 
> 
> 
> 
>>Am I missing something?
>>
>>Adrian
>>
>>----- Original Message ----- 
>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>To: <[e-mail]>
>>Sent: Monday, March 15, 2004 7:43 PM
>>Subject: ason-routing-reqts: issue 2 architecture
>>
>>
> 
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-
> 02.txt
> 
> The second DT issue is on the physical architecture which can be supported
> by GMPLS (from the draft):
> 
> ASON does not restrict the architecture choices used, either a co-located
> architecture or a physically separated architecture may be used. Some
> members of the Design Team are concerned that GMPLS's concept of the LSR
> requires a 1-to-1 relationship between the transport plane entity and the
> control plane entity (Router). They invite CCAMP input on GMPLS capabilities
> to support multiple architectures i.e. how routing protocols would identify
> the transport node ID vs. the router or routing controller ID when scoping
> Link IDs in a link advertisement. Deborah
> 
> 
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 18:47:39 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 2004 19:48:26 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: "Ong, Lyndon" <[e-mail]>
Cc: "'Don Fedyk'" <[e-mail]>, Adrian Farrel <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: Re: ason-routing-reqts: issue 2 architecture
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

the problem is not an issue of being cleaner, the issue
is once the following assumption is taken (which is the
logical consequence of rfc 3630 in the gmpls context)

"a stable IP address of the control plane entity that
manages the resources on behalf of the data plane
entity whose resources are being advertised."

can we assume that wrt to this stable IP address the
resource identification will be unique (throughout
these multiple data plane entities) and in this case
it holds (no additional level of indirection needed),
or not (i.e. you will find duplicated id space values
and then an additional level of indirection is needed)

the problem of the design team was not define the issue
but to find enough arguments wrt to the operational
practices (ie user community) in order to close this

thanks,
- dimitri.

Ong, Lyndon wrote:
> I had the same assumption as Don, that the RFC treats the
> advertising router and the bearer plane node as the same.
> It would be cleaner if there was also a bearer plane node
> identifier in the advertisement.
> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: Don Fedyk [mailto:[e-mail]]
> Sent: Tuesday, March 16, 2004 9:56 AM
> To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
> Subject: RE: ason-routing-reqts: issue 2 architecture
> 
> 
> Hi Adrian
> 
> See Comments Below,
> 
> 
>>-----Original Message-----
>>From: Adrian Farrel [mailto:[e-mail]] 
>>Sent: Monday, March 15, 2004 4:18 PM
>>To: Brungard, Deborah A, ALABS; [e-mail]
>>Subject: Re: ason-routing-reqts: issue 2 architecture
>>
>>
>>I assume that the desire is to have one control plane entity 
>>mange multiple data plane entities (not to have one data 
>>plane entity managed by multiple control plane entities).
> 
> 
> I agree.
> 
>>I believe. in this context, it might be helpful to separate 
>>the signaling function (and the associated routing function 
>>for the delivery of the signaling messages) from the TE 
>>advertisement routing function. Since we are discussing the 
>>routing requirements (this is the routing DT) can I assume 
>>that the discussion is limited to the TE advertisement 
>>routing function, with the aim to have one control plane 
>>entity advertise the resources on behalf of multiple data 
>>plane entities.
>>
>>If all of the above, why could you not simply do this using 
>>RFC3630? The only wrinkle might be that the Router Address 
>>TLV is described as carrying "a stable IP address of the 
>>advertising router". Clearly, this needs to be interpreted as 
>>"a stable IP address of the control plane entity that manages 
>>the resources on behalf of the data plane entity whose 
>>resources are being advertised."
> 
> 
> Interesting. I thought that you need a logical node id for the bearer plane
> as well even though you are only advertising from a single entity.  In other
> words, is it not the desire to have the TE advertisements contain the same
> information regardless of whether there is a one to one correspondence
> between the nodes in control and the data plane or there is a one to many
> relationship? My interpretation of RFC3630 is that it assumes the
> advertising router is the same as the logical node in the bearer plane that
> owns the resources. If a logical node id was added to the advertisement for
> the node terminating the resources when the advertising router was not the
> bearer node that owned the resources it would be clearer to me. 
> 
> Don 
> 
> 
> 
>>Am I missing something?
>>
>>Adrian
>>
>>----- Original Message ----- 
>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>To: <[e-mail]>
>>Sent: Monday, March 15, 2004 7:43 PM
>>Subject: ason-routing-reqts: issue 2 architecture
>>
>>
> 
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-
> 02.txt
> 
> The second DT issue is on the physical architecture which can be supported
> by GMPLS (from the draft):
> 
> ASON does not restrict the architecture choices used, either a co-located
> architecture or a physically separated architecture may be used. Some
> members of the Design Team are concerned that GMPLS's concept of the LSR
> requires a 1-to-1 relationship between the transport plane entity and the
> control plane entity (Router). They invite CCAMP input on GMPLS capabilities
> to support multiple architectures i.e. how routing protocols would identify
> the transport node ID vs. the router or routing controller ID when scoping
> Link IDs in a link advertisement. Deborah
> 
> 
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 18:25:42 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Mon, 15 Mar 2004 17:29:20 -0500
Organization: Cisco Systems
Message-ID: <000e01c40adc$f7f09ac0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Yakov Rekhter
>Sent: Monday, March 15, 2004 4:28 PM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>> >> >> SPs don't like to see RSVP Hello running even when there is no 
>> >> >> application requiring them.
>> >> >
>> >> >Could you please describe scenario(s) where you would have RSVP 
>> >> >Hello running "even when there is no application
>> >requiring them".
>> >> >
>> >> >Yakov.
>> >> >
>> >> 
>> >> Hi Yakov,
>> >> 
>> >> Here is a scenario:
>> >> 
>> >> 1. You start without any application that require RSVP Hellos.
>> >> --> You will see RSVP Hellos are NOT running.
>> >> 
>> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
>> >> --> You will see RSVP Hellos start running.
>> >> 
>> >> So far so good :-)
>> >> 
>> >> 3. You disable application requiring RSVP Hello.
>> >> --> One would expect RSVP Hellos to stop but they keeps
>> >running :-( If
>> >> one side stops replying to RSVP Hello, it would cause traffic
>> >> disruption for LSPs that depend on the health of the 
>Hello session. 
>> >> The only way to get around this limitation is to continue to run 
>> >> Hellos.
>> >
>> >The scenario you described above seems to assume that there
>> >are RSVP applications that do *not* require to run RSVP 
>> >Hellos. 
>> 
>> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP 
>> Hello to detect liveness of RSVP module at the neighbor and instead 
>> uses refresh mechanics for this purpose.
>
>In principle one could use the refresh mechanism as a liveness 
>detection of the RSVP module of the control plane. However, 
>the overhead of the refresh mechanism is certainly higher than 
>of Hello. And that is why using RSVP Hellos for detecting 
>liveness of RSVP module of the control plane seems to be the 
>best available today (note that "best" does not imply "the only").
>

So we are in agreement :-) The fact of the matter is that RSVP Hellos
are "optional" and an LSR (say LSR-B) may not reply to RSVP Hello
messages unless the LSR-B ALSO thinks that it needs to establish an RSVP
Hello adjacency. In such cases it is even better if the initiating LSR
(LSR-A) knows intent of LSR-B. In other words, the draft in question
does NOT change the equation, but only helps. 

>Yakov.
>





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 18:25:17 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Mon, 15 Mar 2004 17:29:20 -0500
Organization: Cisco Systems
Message-ID: <000e01c40adc$f7f09ac0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Yakov Rekhter
>Sent: Monday, March 15, 2004 4:28 PM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>> >> >> SPs don't like to see RSVP Hello running even when there is no 
>> >> >> application requiring them.
>> >> >
>> >> >Could you please describe scenario(s) where you would have RSVP 
>> >> >Hello running "even when there is no application
>> >requiring them".
>> >> >
>> >> >Yakov.
>> >> >
>> >> 
>> >> Hi Yakov,
>> >> 
>> >> Here is a scenario:
>> >> 
>> >> 1. You start without any application that require RSVP Hellos.
>> >> --> You will see RSVP Hellos are NOT running.
>> >> 
>> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
>> >> --> You will see RSVP Hellos start running.
>> >> 
>> >> So far so good :-)
>> >> 
>> >> 3. You disable application requiring RSVP Hello.
>> >> --> One would expect RSVP Hellos to stop but they keeps
>> >running :-( If
>> >> one side stops replying to RSVP Hello, it would cause traffic
>> >> disruption for LSPs that depend on the health of the 
>Hello session. 
>> >> The only way to get around this limitation is to continue to run 
>> >> Hellos.
>> >
>> >The scenario you described above seems to assume that there
>> >are RSVP applications that do *not* require to run RSVP 
>> >Hellos. 
>> 
>> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP 
>> Hello to detect liveness of RSVP module at the neighbor and instead 
>> uses refresh mechanics for this purpose.
>
>In principle one could use the refresh mechanism as a liveness 
>detection of the RSVP module of the control plane. However, 
>the overhead of the refresh mechanism is certainly higher than 
>of Hello. And that is why using RSVP Hellos for detecting 
>liveness of RSVP module of the control plane seems to be the 
>best available today (note that "best" does not imply "the only").
>

So we are in agreement :-) The fact of the matter is that RSVP Hellos
are "optional" and an LSR (say LSR-B) may not reply to RSVP Hello
messages unless the LSR-B ALSO thinks that it needs to establish an RSVP
Hello adjacency. In such cases it is even better if the initiating LSR
(LSR-A) knows intent of LSR-B. In other words, the draft in question
does NOT change the equation, but only helps. 

>Yakov.
>





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 18:25:02 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Mon, 15 Mar 2004 17:29:20 -0500
Organization: Cisco Systems
Message-ID: <000e01c40adc$f7f09ac0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Yakov Rekhter
>Sent: Monday, March 15, 2004 4:28 PM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>> >> >> SPs don't like to see RSVP Hello running even when there is no 
>> >> >> application requiring them.
>> >> >
>> >> >Could you please describe scenario(s) where you would have RSVP 
>> >> >Hello running "even when there is no application
>> >requiring them".
>> >> >
>> >> >Yakov.
>> >> >
>> >> 
>> >> Hi Yakov,
>> >> 
>> >> Here is a scenario:
>> >> 
>> >> 1. You start without any application that require RSVP Hellos.
>> >> --> You will see RSVP Hellos are NOT running.
>> >> 
>> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
>> >> --> You will see RSVP Hellos start running.
>> >> 
>> >> So far so good :-)
>> >> 
>> >> 3. You disable application requiring RSVP Hello.
>> >> --> One would expect RSVP Hellos to stop but they keeps
>> >running :-( If
>> >> one side stops replying to RSVP Hello, it would cause traffic
>> >> disruption for LSPs that depend on the health of the 
>Hello session. 
>> >> The only way to get around this limitation is to continue to run 
>> >> Hellos.
>> >
>> >The scenario you described above seems to assume that there
>> >are RSVP applications that do *not* require to run RSVP 
>> >Hellos. 
>> 
>> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP 
>> Hello to detect liveness of RSVP module at the neighbor and instead 
>> uses refresh mechanics for this purpose.
>
>In principle one could use the refresh mechanism as a liveness 
>detection of the RSVP module of the control plane. However, 
>the overhead of the refresh mechanism is certainly higher than 
>of Hello. And that is why using RSVP Hellos for detecting 
>liveness of RSVP module of the control plane seems to be the 
>best available today (note that "best" does not imply "the only").
>

So we are in agreement :-) The fact of the matter is that RSVP Hellos
are "optional" and an LSR (say LSR-B) may not reply to RSVP Hello
messages unless the LSR-B ALSO thinks that it needs to establish an RSVP
Hello adjacency. In such cases it is even better if the initiating LSR
(LSR-A) knows intent of LSR-B. In other words, the draft in question
does NOT change the equation, but only helps. 

>Yakov.
>





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 18:24:45 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Mon, 15 Mar 2004 17:29:20 -0500
Organization: Cisco Systems
Message-ID: <000e01c40adc$f7f09ac0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Yakov Rekhter
>Sent: Monday, March 15, 2004 4:28 PM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>> >> >> SPs don't like to see RSVP Hello running even when there is no 
>> >> >> application requiring them.
>> >> >
>> >> >Could you please describe scenario(s) where you would have RSVP 
>> >> >Hello running "even when there is no application
>> >requiring them".
>> >> >
>> >> >Yakov.
>> >> >
>> >> 
>> >> Hi Yakov,
>> >> 
>> >> Here is a scenario:
>> >> 
>> >> 1. You start without any application that require RSVP Hellos.
>> >> --> You will see RSVP Hellos are NOT running.
>> >> 
>> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
>> >> --> You will see RSVP Hellos start running.
>> >> 
>> >> So far so good :-)
>> >> 
>> >> 3. You disable application requiring RSVP Hello.
>> >> --> One would expect RSVP Hellos to stop but they keeps
>> >running :-( If
>> >> one side stops replying to RSVP Hello, it would cause traffic
>> >> disruption for LSPs that depend on the health of the 
>Hello session. 
>> >> The only way to get around this limitation is to continue to run 
>> >> Hellos.
>> >
>> >The scenario you described above seems to assume that there
>> >are RSVP applications that do *not* require to run RSVP 
>> >Hellos. 
>> 
>> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP 
>> Hello to detect liveness of RSVP module at the neighbor and instead 
>> uses refresh mechanics for this purpose.
>
>In principle one could use the refresh mechanism as a liveness 
>detection of the RSVP module of the control plane. However, 
>the overhead of the refresh mechanism is certainly higher than 
>of Hello. And that is why using RSVP Hellos for detecting 
>liveness of RSVP module of the control plane seems to be the 
>best available today (note that "best" does not imply "the only").
>

So we are in agreement :-) The fact of the matter is that RSVP Hellos
are "optional" and an LSR (say LSR-B) may not reply to RSVP Hello
messages unless the LSR-B ALSO thinks that it needs to establish an RSVP
Hello adjacency. In such cases it is even better if the initiating LSR
(LSR-A) knows intent of LSR-B. In other words, the draft in question
does NOT change the equation, but only helps. 

>Yakov.
>





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 18:24:29 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Mon, 15 Mar 2004 17:29:20 -0500
Organization: Cisco Systems
Message-ID: <000e01c40adc$f7f09ac0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Yakov Rekhter
>Sent: Monday, March 15, 2004 4:28 PM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>> >> >> SPs don't like to see RSVP Hello running even when there is no 
>> >> >> application requiring them.
>> >> >
>> >> >Could you please describe scenario(s) where you would have RSVP 
>> >> >Hello running "even when there is no application
>> >requiring them".
>> >> >
>> >> >Yakov.
>> >> >
>> >> 
>> >> Hi Yakov,
>> >> 
>> >> Here is a scenario:
>> >> 
>> >> 1. You start without any application that require RSVP Hellos.
>> >> --> You will see RSVP Hellos are NOT running.
>> >> 
>> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
>> >> --> You will see RSVP Hellos start running.
>> >> 
>> >> So far so good :-)
>> >> 
>> >> 3. You disable application requiring RSVP Hello.
>> >> --> One would expect RSVP Hellos to stop but they keeps
>> >running :-( If
>> >> one side stops replying to RSVP Hello, it would cause traffic
>> >> disruption for LSPs that depend on the health of the 
>Hello session. 
>> >> The only way to get around this limitation is to continue to run 
>> >> Hellos.
>> >
>> >The scenario you described above seems to assume that there
>> >are RSVP applications that do *not* require to run RSVP 
>> >Hellos. 
>> 
>> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP 
>> Hello to detect liveness of RSVP module at the neighbor and instead 
>> uses refresh mechanics for this purpose.
>
>In principle one could use the refresh mechanism as a liveness 
>detection of the RSVP module of the control plane. However, 
>the overhead of the refresh mechanism is certainly higher than 
>of Hello. And that is why using RSVP Hellos for detecting 
>liveness of RSVP module of the control plane seems to be the 
>best available today (note that "best" does not imply "the only").
>

So we are in agreement :-) The fact of the matter is that RSVP Hellos
are "optional" and an LSR (say LSR-B) may not reply to RSVP Hello
messages unless the LSR-B ALSO thinks that it needs to establish an RSVP
Hello adjacency. In such cases it is even better if the initiating LSR
(LSR-A) knows intent of LSR-B. In other words, the draft in question
does NOT change the equation, but only helps. 

>Yakov.
>





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 18:11:37 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: "'Brungard, Deborah A, ALABS'" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 1 addressing
Date: Tue, 16 Mar 2004 10:10:43 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Folks,

Let me kick off some discussion on issue 1 by noting some of the
concerns with using existing methods of advertising reachability
for this purpose:

1) the client system may not be an IP system, but another transport
device with an IP control interface - for example, an ADM (add-drop
multiplexer) acting as a client to an optical network.  Advertising
reachability using normal means might imply that the system can be
used for IP traffic routing.

2) the client system may use a different addressing space than the
internal network addressing space.  Carriers may wish to use a
different addressing space for administrative or policy reasons.

(Note: one model for this is the VPN model, which would allow 
private networks to have their own address spaces.  Another model
is a telephone number-like model, where clients obtain addresses
from a space maintained by the carrier.)

3) the client system may use a non-IP address for compatibility
reasons, for example, a client with an existing management plane
address that the carrier wants to access without having to
add a new address and translation mechanism.  

Cheers,

Lyndon

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[e-mail]]
Sent: Monday, March 15, 2004 11:29 AM
To: [e-mail]
Subject: ason-routing-reqts: issue 1 addressing


As noted in the CCAMP minutes and the DT's presentation, the ASON routing DT had three issues regarding GMPLS support for which they lacked agreement and request support of the WG. The issues are identified in Section 7 (Conclusions) of the draft:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

I will post three separate email threads to cover each issue. The first issue is on address reachability. The following is the text from the draft:

Some members of the Design Team noted that reachability information (as described in Section 4.5.3) may be advertised as a set of UNI Transport Resource address prefixes (assigned and selected consistently in their applicability scope). These members of the Design Team raised a concern that existing methods of advertising reachability may need to be examined (on a per-protocol basis) to determine if they are also applicable for UNI Transport Resource addresses. They invite CCAMP discussion on this aspect.
Deborah





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 18:07:28 +0000
Message-Id: <[e-mail]>
Date: Tue, 16 Mar 2004 13:05:47 -0500
To: [e-mail]
From: Jean Philippe Vasseur <[e-mail]>
Subject: draft-vasseur-ccamp-loose-path-reopt
Cc: yuichi Ikejiri <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

As you know, draft-vasseur-ccamp-loose-path-reopt has recently been moved 
to CCAMP where the inter-area/AS related items are discussed. This ID 
proposes a method to perform reoptimization of inter-area/AS TE defined as 
a set of loose hops with a head-end LSR control (item explicitly listed in 
the requirements draft). This draft is in fact the third revision, after 
several comments have been received and incorporated.

Any additional comments would be more than welcome.

Thanks.

JP.




Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 18:07:12 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Don Fedyk' <[e-mail]>, Adrian Farrel <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>,  [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 10:06:32 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

I had the same assumption as Don, that the RFC treats the
advertising router and the bearer plane node as the same.
It would be cleaner if there was also a bearer plane node
identifier in the advertisement.

Cheers,

Lyndon

-----Original Message-----
From: Don Fedyk [mailto:[e-mail]]
Sent: Tuesday, March 16, 2004 9:56 AM
To: Adrian Farrel; Brungard, Deborah A, ALABS; [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture


Hi Adrian

See Comments Below,

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Monday, March 15, 2004 4:18 PM
> To: Brungard, Deborah A, ALABS; [e-mail]
> Subject: Re: ason-routing-reqts: issue 2 architecture
> 
> 
> I assume that the desire is to have one control plane entity 
> mange multiple data plane entities (not to have one data 
> plane entity managed by multiple control plane entities).

I agree.
> 
> I believe. in this context, it might be helpful to separate 
> the signaling function (and the associated routing function 
> for the delivery of the signaling messages) from the TE 
> advertisement routing function. Since we are discussing the 
> routing requirements (this is the routing DT) can I assume 
> that the discussion is limited to the TE advertisement 
> routing function, with the aim to have one control plane 
> entity advertise the resources on behalf of multiple data 
> plane entities.
> 
> If all of the above, why could you not simply do this using 
> RFC3630? The only wrinkle might be that the Router Address 
> TLV is described as carrying "a stable IP address of the 
> advertising router". Clearly, this needs to be interpreted as 
> "a stable IP address of the control plane entity that manages 
> the resources on behalf of the data plane entity whose 
> resources are being advertised."

Interesting. I thought that you need a logical node id for the bearer plane
as well even though you are only advertising from a single entity.  In other
words, is it not the desire to have the TE advertisements contain the same
information regardless of whether there is a one to one correspondence
between the nodes in control and the data plane or there is a one to many
relationship? My interpretation of RFC3630 is that it assumes the
advertising router is the same as the logical node in the bearer plane that
owns the resources. If a logical node id was added to the advertisement for
the node terminating the resources when the advertising router was not the
bearer node that owned the resources it would be clearer to me. 

Don 


> 
> Am I missing something?
> 
> Adrian
> 
> ----- Original Message ----- 
> From: "Brungard, Deborah A, ALABS" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, March 15, 2004 7:43 PM
> Subject: ason-routing-reqts: issue 2 architecture
> 
> 
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-
02.txt

The second DT issue is on the physical architecture which can be supported
by GMPLS (from the draft):

ASON does not restrict the architecture choices used, either a co-located
architecture or a physically separated architecture may be used. Some
members of the Design Team are concerned that GMPLS's concept of the LSR
requires a 1-to-1 relationship between the transport plane entity and the
control plane entity (Router). They invite CCAMP input on GMPLS capabilities
to support multiple architectures i.e. how routing protocols would identify
the transport node ID vs. the router or routing controller ID when scoping
Link IDs in a link advertisement. Deborah







Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 17:57:53 +0000
Message-ID: <[e-mail]>
From: "Don Fedyk" <[e-mail]>
To: Adrian Farrel <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, [e-mail]
Subject: RE: ason-routing-reqts: issue 2 architecture
Date: Tue, 16 Mar 2004 12:55:57 -0500

Hi Adrian

See Comments Below,

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Monday, March 15, 2004 4:18 PM
> To: Brungard, Deborah A, ALABS; [e-mail]
> Subject: Re: ason-routing-reqts: issue 2 architecture
> 
> 
> I assume that the desire is to have one control plane entity 
> mange multiple data plane entities (not to have one data 
> plane entity managed by multiple control plane entities).

I agree.
> 
> I believe. in this context, it might be helpful to separate 
> the signaling function (and the associated routing function 
> for the delivery of the signaling messages) from the TE 
> advertisement routing function. Since we are discussing the 
> routing requirements (this is the routing DT) can I assume 
> that the discussion is limited to the TE advertisement 
> routing function, with the aim to have one control plane 
> entity advertise the resources on behalf of multiple data 
> plane entities.
> 
> If all of the above, why could you not simply do this using 
> RFC3630? The only wrinkle might be that the Router Address 
> TLV is described as carrying "a stable IP address of the 
> advertising router". Clearly, this needs to be interpreted as 
> "a stable IP address of the control plane entity that manages 
> the resources on behalf of the data plane entity whose 
> resources are being advertised."

Interesting. I thought that you need a logical node id for the bearer plane
as well even though you are only advertising from a single entity.  In other
words, is it not the desire to have the TE advertisements contain the same
information regardless of whether there is a one to one correspondence
between the nodes in control and the data plane or there is a one to many
relationship? My interpretation of RFC3630 is that it assumes the
advertising router is the same as the logical node in the bearer plane that
owns the resources. If a logical node id was added to the advertisement for
the node terminating the resources when the advertising router was not the
bearer node that owned the resources it would be clearer to me. 

Don 


> 
> Am I missing something?
> 
> Adrian
> 
> ----- Original Message ----- 
> From: "Brungard, Deborah A, ALABS" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, March 15, 2004 7:43 PM
> Subject: ason-routing-reqts: issue 2 architecture
> 
> 
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-
02.txt

The second DT issue is on the physical architecture which can be supported
by GMPLS (from the draft):

ASON does not restrict the architecture choices used, either a co-located
architecture or a physically separated architecture may be used. Some
members of the Design Team are concerned that GMPLS's concept of the LSR
requires a 1-to-1 relationship between the transport plane entity and the
control plane entity (Router). They invite CCAMP input on GMPLS capabilities
to support multiple architectures i.e. how routing protocols would identify
the transport node ID vs. the router or routing controller ID when scoping
Link IDs in a link advertisement. Deborah







Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 15:51:38 +0000
Date: Tue, 16 Mar 2004 07:49:13 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: Adrian Farrel <[e-mail]>
cc: [e-mail]
Subject: Re: Revised draft minutes
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Adrian,

Just a couple of minor corrections below.

thanks,
-arthi

> Lou Berger presented an overview of work on Segment
> Recovery - draft-berger-ccamp-gmpls-segment-recovery-00.txt
>
>   He also talked about what still needs to be done (next
>   steps), including more usage scenarios, more explanatory
>   text and see if the WG will adopt this work.
>
>   Arthi Ayyangar asked if the association object is required
>   even if we are only doing segment recovery (as opposed to
>   e2e).  She had follow up questions that Kireeti asked her
>   to take to the list.
---------> To the above you may want to add, "Arthi asked why couldn't we
extend the Detour Object to achieve the same".

>   Adrian polled for support of accepting this as a WG draft.
>   There was moderate support and no objection.
>
> ---
> Lou Berger went over Extensions to GMPLS RSVP Graceful
> Restart
> draft-aruns-ccamp-rsvp-restart-ext-00
>
>   He emphasized that egress restart is already covered in
>   RFC3473 and this work has no effect on that functionality.
>   He gave a brief overview and listed open issues.
>
>   Next steps include merging with other restart drafts and
>   seeing if this work can become a WG draft.
>

>   Arthi said that she feels that the document focuses too
>   much on the ERO. She feels that the draft should address
>   other issues and concerns with the mechanism.
-------> Replace with: "Arthi said that the text at the beginning of the
draft seems to talk only about the recovery ERO, although using the
RecoveryPath one can recover many objects besides the ERO. So the text
should be clarified to this effect."

>     Lou asked if she would like to contribute text.

-------> There was a discussion on adjacent node restart. "Arthi
asked why adjacent node restart was an issue being addressed in RSVP. She
pointed out that before this becomes an issue to be solved in RSVP, we would
first need to check if adjacent node restart even works for IGPs."

>   The chairs then asked for other discussion to go to the
>   list.
>
> ---
> Zafar Ali talked about Extensions to GMPLS RSVP Graceful
> Restart
> draft-rahman-ccamp-rsvp-restart-extensions-00.txt
>
>   Kireeti said that he appreciated the honesty of the
>   authors in acknowledging other work.
>
>   Nurit Sprecher asked about the relationship to FRR and
>   similar issues.
>
>     Adrian agreed that these were important issues and had
>     been raised on the list in recent days. He asked the
>     authors to make sure that they cover the points in the
>     draft.
>
> ---
> Zafar then covered modifications to Hello procedures
> 1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
> 2) draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
>
>   He wants to go forward with draft 1 above.
>
>   Adrian polled and there was some interest and no strong
>   objection.
>
>   Kireeti said that this work cannot be informational if
>   it has - or proposes - changes to a standard.
>
>   Zafar also wants draft 2 to be a WG document.
>
>   Kireeti said that we need to take this to the list, but
>   Zafar also needs to socialize the work he is doing so that
>   people may decide whether or not this is work we want to
>   do.
>
> ===
> Everything Else
> ---
> Emmanuel Dotaro gave status of Multi-region protection -
> draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt
>
>   He briefly covered changes since previous versions.
>
>   He proposes that we may need to make changes to the
>   charter to include all of this work. In particular to
>   include in the charter the complete set of GMPLS
>   mechanisms for integrated control planes, and not only
>   multi-layer recovery (as it stands today).
>>   Adrian suggested that the authors need to get more people
>   involved in this important work and revisit this later.
>
> ---
> Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs
> draft-vasseur-ccamp-isis-te-caps-00.txt
>
>   He would like to have this accepted as a WG document.
>
>   Adrian asked to hold off on this until after the OSPF talk
>   below.
>
> ---
> Seisho Yasukawa
> draft-vasseur-ccamp-ospf-te-caps-00.txt
>
>   He would like to have this accepted as a WG document.
>
>   Regarding both drafts, Kireeti is not sure that this work
>   belongs in this WG. The decision is driven by the
>   generality of its applicability. If we do take it on, their
>   needs to be a functional specification (independent of IGP)
>   as well.
>
>   He asked that further discussion be taken to the list.
>
> ---
> The Following presentations were postponed as we ran out
> of time. Adrian made a couple of brief comments as follows:
>   ---
>   Zafar Ali - Explicit Resource Control and Tracking
>   draft-zamfir-explicit-resource-control-bundle-03.txt
>
>     This work concerns identification of component links in
>     EROs and RROs.
>
>     A small group is currently examining other issues
>     concerning identification of component links in all
>     aspects of GMPLS. A draft is expected soon. Please mail
>     Adrian or the list, if you want to be involved in this
>     work.
>
>   ---
>   Lou Berger - Alarm Reporting
>   draft-berger-ccamp-gmpls-alarm-spec-01.txt
>
>     This draft is stable and complete in the view of the
>     authors.
>
>     A quick poll showed some support for this being a WG
>     document, and no opposition. This will be taken to the
>     list.
>



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 06:05:49 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 2004 15:03:53 +0900
From: Kohei Shiomoto <[e-mail]>
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: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Revised draft minutes
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Adrian,

Please let me put my comments in the two blank portions of the revised 
agenda.
See in line.

Kohei

>This draft incorporates feedback from Dimitri and Vishal
>and from an anonymous reviewer. Thanks.
>
>Further comments ASAP.
>
>Adrian
>
>
>Common Control and Measurement Plane WG (ccamp)
>
>THURSDAY, March 4 at 0900-1130
>===============================
>
>CHAIRS: Kireeti Kompella <[e-mail]>
>        Adrian Farrel <[e-mail]>
>
>AGENDA:
>
>===
>Group Admin
>---
>Chairs
>  Admin - Nothing much to say (in English anyway)
>        - In Korean, however, the following was said:
>          "Jigeumbuteo CCAMP meetingeul sijakhagesumnida".
>
>  Agenda bash (5 mins) - No changes
>  Status of WG drafts and milestones
>    Adrian's slides showed that we do have some draft
>    congestion in the WG.
>    - RFC editor queue
>    - status of IANA for SONET/SDH
>      Kireeti talked about an issue with SONET/SDH IANA
>      assignments
>    - need a means to get early assignments.
>      There is WIP to accomplish this, and it is moving
>      ahead.
>    - future allocation of "experimental" values
>
>Liaisons
>---
>Marco Carugi talked about work in SG-13 (SG13 liaison).
>  He covered topics, new study areas, timescales, objectives
>  and status. They are also looking for people interested in
>  doing work in these areas.
>
>  An L1 VPN questionnaire and framework draft were attached
>  to the liaison.
>
>  Tomonori Takeda talked about the technical issues and
>  details of the work.
>
>  Monique Morrow had a couple of clarification for Marco -
>  When will the consent portion of the work be done in the
>  ITU?
>
>    Marco said that the different pieces of work were
>    progressing at different speeds. Some material is
>    already embodied in recommendations. The next SG13
>    meetings are in June and September.
>
>  Dimitri Papadimitriou asked if the draft (l1vpn 
>  framework) provided in the liaison could include a 
>  summarization (as conclusion) on the expected GMPLS work
>  for the CCAMP WG, this would clarify the intent of the
>  liaison in term of expected effort for the CCAMP WG
>
>    Kireeti answered. If CCAMP's rechartering this month
>    results in the addition of L1VPNs to the charter, then
>    a Liaison response from the IETF will include this
>    information, plus a request for a cooperative effort,
>    preferably along the lines of the ASON routing work,
>    wherein the ITU-T defines the requirements and the IETF
>    does the protocol extensions.
>
>  Alex Zinin said that we will have to make a decision at
>  some point as to whether or not we want to do this work
>  here.
>
>  Someone from NTT raised a point that was not captured in
>  the minutes.
>
Kohei Shiomoto said that the protocol for the L1VPN should be developed 
at the IETF as long as it uses IP protocol. There are already 
internet-drafts on GVPN and CCAMP is the best place to discuss it.

>
>  Deborah Brungard said that there is work and some synergy
>  and that we should continue to work on this.
>
>    Monique Morrow agrees that we should work on that.
>
>    Marco added some comments that were not captured in the
>    minutes.
>
>    Malcolm Betts said he also feels that we should do this.
>
>  Adrian took a quick poll and it seems as if nobody is
>  against doing this work.
>
>  Kireeti reminded people to continue this discussion on
>  the list.
>
>---
>Lyndon Ong talked about work in SG-15 (3 liaisons).
>
>  Liaisons were on ASON routing requirements, response to
>  comments on Q14 for G.7713.2 and comments on the CCAMP
>  ASON signaling requirements draft.
>
>  Lyndon spent much of the time on the details of response
>  to comments on Q14. It seems that some of the differences
>  in architectural models revolve around "end-to-end" and
>  "call segment" operating models.
>
>  Kireeti asked for the reply by date.
>
>    Lyndon did not have that.
>
>    Steve Trowbridge said that the meeting starts on April
>    19th
>
>  Dimitri had a question on the deadline. There is a
>  deadline on G.7713 (April 2004), isn't there a similar
>  deadline on G.7713.2 (since this is the document to which
>  convergence is expected) ?
>
>    Lyndon said that he had not gone into that. He gave a
>    reason, but this was not captured in the minutes.
>
>  Deborah said that the liaison for 7713.2 does not say any
>  thing about convergence.
>
>    Lyndon said that they are still looking for a "meeting
>    of the minds".
>
>  Deborah said that there is an issue with G.7713.2 because
>  of compatibility.
>
>    Lyndon said that yes there has been a lot of discussion
>    of compatibility questions and requirements.
>
>  Kireeti said that we should not discuss this here.
>
>  Steve Trowbridge added some comments that were not
>  captured in the minutes.
>
>  Kireeti asked the WG to take this discussion to the list
>  and try to keep that discussion on a productive basis.
>
>  Adrian said that he wanted to recognize the efforts of
>  the ITU folks in this work.
>
>===
>ASON Requirements and Solutions
>---
>Dimitri Papadimitriou presented status of ASON Signaling
>Requirements (draft-ietf-ccamp-gmpls-ason-reqts-05.txt.
>
>  The requirements were driven by last year's liaison from
>  the ITU.
>
>  The discussion slides proposed to defer to the GROW WG 
>  (cf. RIFT WG item) concerning the (external) non-IP
>  reachability issue since much broader than just CCAMP
>  GMPLS/ASON context
>
>  After this meeting, Dimitri would like to re-spin the
>  draft and have a two week last call.
>
>  Lyndon said he want to capture the requirement on "non-IP
>  reachability" - whether or not we will work on it here
>
>  Kireeti said that we first need to understand importance
>  of this and then we can look to the ADs for guidance on
>  handling this.  He also said that we should take some time
>  to work out what we want to say to the ITU when we include
>  the current draft.
>
>---
>Dimitri Papadimitriou gave status ASON Signaling Solutions
>(draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt) status.
>
>  He would like feedback on whether or not the current draft
>  deals correctly with the session attribute object that
>  encodes the long call_id (alternatives were also proposed)
>
>  His objective at this point is to try to have a document
>  ready for last call for the next IETF 60 meeting in San
>  Diego
>
>  Lyndon suggested that we might remove the comparison with
>  G.7713 from the draft.
>
>    Adrian asked if this meant that the interworking draft
>    for RFC3473/4 interworking was now obsolete.
>
>      Lyndon said maybe, if interworking is removed as a
>      requirement.
>
>---
>Lou Berger talked about Egress Control -
>draft-berger-gmpls-egress-control-01.txt -
>
>  Original egress label control became explicit label
>  control. This draft attempts to capture the original
>  intent.
>
>  He wants to know if the WG feels that this is ready to
>  be a BCP and what the chairs think the next steps should
>  be.
>
>  Lou re-iterated that the purpose and scope of the draft
>  is for clarification. He does not see any value in adding
>  to this intent or combining it with other work.
>
>  Adrian then took a poll and nobody objected to take this
>  on as a WG item (more than a third were in favor).
>
>---
>Lyndon Ong went over status on ASON Routing Requirements -
>draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
>
>  He includes in his presentation the Design Team's 
>  conclusions as to what there is agreement about what's
>  missing from GMPLS (delta), and what are the areas on 
>  which there is no agreement about what's missing from 
>  GMPLS.
>
>  Vishal Sharma asked if the three issues (slide 6) were 
>  already opened up for discussion on the list, or would 
>  they be formally opened up with the DT members initiating
>  a discussion on these on the list?
>
>    Lyndon Ong replied that a discussion had not been
>    formally opened up yet (although people were free to
>    discuss/comment).
>
>      Kireeti asked Lyndon to more formally open this
>      discussion on the mailing list.
>
>  Vishal Sharma said that he supports this.
>
>  Kireeti said he would like - after checking with the AD -
>  that we should take this work to the IS-IS and OSPF WGs.
>
>    Alex Zinin said this is a good idea.
>
>===
>Tunnel Trace
>---
>Ron Bonica presented status on draft-bonica-tunproto-05.txt
>
>  The solution is very similar to Trace-Route but does not
>  require that each node in a tunnel supports TTL decrement.
>
>  He gave a few examples as to how the idea in the draft
>  will work in a few scenarios.
>
>  There are a couple of outstanding issues:
>  - trace requires a route to tunnel head end
>  - integration with LSP ping.
>
>  He would like to get the draft accepted as a WG draft.
>
>  Yakov asked what SPs use today for tunnel tracing.
>
>    Ron said that in some case people can use ICMP for MPLS.
>
>  Yakov then asked if we could get a BCP on what people are
>  doing.
>
>    Ron asked if he should resubmit his earlier draft on
>    this.
>
>      Kireeti said that we do not want to decide that now.
>
>===
>Protection and Restoration
>---
>Dimitri Papadimitriou presented status on the work of the
>Protection and Restoration Team - specifically:
>1) draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>2) draft-ietf-ccamp-gmpls-recovery-functional-01.txt
>3) draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
>4) draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt
>
>  He gave estimates on the timing for each of the above
>  drafts (estimated completion dates).
>
>  He outlined the changes to the e2e signaling ID (draft 4,
>  above).
>
>  He encouraged the WG to really read the documents and
>  comment.
>
>  Kireeti polled for consensus on the following:
>
>    a) Analysis - last call? Some support, no objection
>    b) Functional - last call? Some support, no objection
>    c) Terminology - last call? Some support, no objection
>    d) e2e Signaling - WG document? Some support, no object
>
>  People at the microphone were asked to take their
>  questions to the list.
>
Kohei said that the e2e Signaling draft does not address the 
misconnection issues raised in the mailing list.
Dimitri answered that it is addressed in 8.3 of the draft.

Kohei said that the misconnection issue does not happen only in the P&R 
context but also in more general context and therefore should be 
addressed in more general context as well.
Kireeti said that the questions should be contiuned to the mailing list.

>
>---
>Lou Berger presented an overview of work on Segment
>Recovery - draft-berger-ccamp-gmpls-segment-recovery-00.txt
>
>  He also talked about what still needs to be done (next
>  steps), including more usage scenarios, more explanatory
>  text and see if the WG will adopt this work.
>
>  Arthi Ayyangar asked if the association object is required
>  even if we are only doing segment recovery (as opposed to
>  e2e).  She had follow up questions that Kireeti asked her
>  to take to the list.
>
>  Adrian polled for support of accepting this as a WG draft.
>  There was moderate support and no objection.
>
>===
>Inter-Area/AS
>---
>Arthi Ayyangar talked about the status of the merged draft
>on Inter-area/AS signaling -
>draft-vasseur-ccamp-inter-area-as-te-00.txt
>
>  The draft currently represents a full merge - work is 
>  still required to strip out redundant and unneeded text.
>
>  She said that the authors encourage people to come forward
>  with their comments.  She would also like to see if there
>  is interest in this work becoming a WG document.
>
>  Vishal Sharma said that the work should apply to general 
>  path computation domains and GMPLS LSPs.
>  In response to Arthi's question on Slide "Outstanding
>  Issues" (about whether detailed description of various 
>  path computation algorithms should be part of this 
>  document or separate document(s)), he supported the 
>  document being split into a framework document, discussing
>  signaling, and another document(s), discussing the path 
>  computation mechanisms, since the latter do not need to be
>  standardized.
>  In response to Slide "Outstanding Issues: Size of the 
>  document" and for clarity, he supported the splitting of 
>  the applicability statement into an independent document.
>
>  Dimitri agreed on the subject of separating the document.
>  In addition, he questioned about the relevance of using 
>  the LSP_Attributes to signal the signaling method for the
>  intra-area/-AS provisioning of the LSP.
>  In particular, he proposed to not include protocol 
>  procedures within examples/scenarios that makes the
>  document difficult to read.
>
>    Arthi asked that Dimitri take his specific comments to
>    the list.
>
>  Kireeti said that he agrees that the document needs to be
>  split - one as a signaling and another (informational) to
>  provide examples for path computation. He also said that
>  we need a separate applicability document.
>
>    Vishal Sharma then said that he would be happy to help 
>    with these tasks.
>
>---
>Vishal Sharma talked about work on Inter-area path
>protection
>draft-dachille-inter-area-path-protection-00.txt
>
>  He provided a brief overview of how it works, and showed
>  how it relates to other work in progress. He also listed
>  the next steps.
>
>  He emphasized that this is really a generic mechanism for
>  diverse path computation, and protection is one 
>  application of it, so the authors would respin with a new
>  name and emphasis to reflect this."
>
>  Zafar Ali asked how this would work if there is a failure
>  at the time during which the backup path is being setup.
>
>    Vishal replied that the solutions to this were, so far,
>    not discussed in the draft, but that there are several 
>    options. 
>
>    He then outlined some of the options. E.g. either 
>    default in such a case to a sequential computation, and
>    use XRO to exclude the link/node where backup path setup
>    failed, and retry the backup (and optimize both primary 
>    and secondary later using the techniques in the draft).
>    Or, set up the primary and the backup again, using the 
>    techniques described in the draft.
>
>    Vishal said they would be happy to add some discussion 
>    in the document, and welcomed feedback on the list.
>
>  Zafar asked how this work relates to PCS/PCE work.
>    
>    Vishal replied that it could actually be made use of by
>    the PCS/PCE approach, and could be viewed as 
>    complementary.
>
>  Kireeti asked that further discussion be taken to the 
>  list.
>
>  Vishal said he welcomed further feedback on the document.
> 
>  Dimitri asked why, knowing that the proposed approach 
>  works as expected in the intra-domain case when the 
>  number of ABRs (where computation can be executed at each
>  stage) does not increase, this approach is so focused on 
>  optimization (since it can't be achieved if this
>  condition is not met).
>
>    Vishal clarified that the focus of the work is to 
>    propose a generic mechanism to facilitate diverse path
>    setup by communicating alternate path info, with 
>    optimization a desired goal (for reasons explained in
>    the document).
>
>    Vishal added that given the network model (where border
>    nodes are not assumed to have visibility in areas other
>    than their own), the scheme was not trying to be 
>    globally optimal.
>
>    Vishal explained that in such cases some selection needs
>    to be performed at each stage.
>
>  Kireeti asked that further discussion on this should be
>  taken to the list.
>
>  Also, he said that Dimitri had a good point - we need to
>  define criteria on which any optimization is based.
>
>  Kireeti concluded by saying that path protection and 
>  inter-area are both in the charter, but that this document
>  could only be considered for a WG document after there was 
>  discussion about the document on the list.
>
>===
>Control Pane Resilience, Hello Protocol and Graceful Restart
>---
>Young Hwa Kim gave a presentation on Requirements for the
>Resilience of Control Plane in GMPLS -
>draft-kim-ccamp-cpr-reqts-00.txt
>
>  He described the reasons why control plane resilience is
>  needed.
>
>  Zafar asked how control plane resilience is different from
>  anything else in IP.
>
>  Steve Trowbridge said that their is also some work in this
>  area in the ITU and he would try to get this in as a
>  liaison as soon as possible.
>
>  Kireeti said that this is an important discussion and
>  there are a lot of things to do. Specific topics should be
>  raised on the list when appropriate.
>
>---
>Lou Berger went over Extensions to GMPLS RSVP Graceful
>Restart
>draft-aruns-ccamp-rsvp-restart-ext-00
>
>  He emphasized that egress restart is already covered in
>  RFC3473 and this work has no effect on that functionality.
>  He gave a brief overview and listed open issues.
>
>  Next steps include merging with other restart drafts and
>  seeing if this work can become a WG draft.
>
>  Arthi said that she feels that the document focuses too
>  much on the ERO. She feels that the draft should address
>  other issues and concerns with the mechanism.
>
>    Lou asked if she would like to contribute text.
>
>  The chairs then asked for other discussion to go to the
>  list.
>
>---
>Zafar Ali talked about Extensions to GMPLS RSVP Graceful
>Restart
>draft-rahman-ccamp-rsvp-restart-extensions-00.txt
>
>  Kireeti said that he appreciated the honesty of the
>  authors in acknowledging other work.
>
>  Nurit Sprecher asked about the relationship to FRR and
>  similar issues.
>
>    Adrian agreed that these were important issues and had
>    been raised on the list in recent days. He asked the
>    authors to make sure that they cover the points in the
>    draft.
>
>---
>Zafar then covered modifications to Hello procedures
>1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>2) draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
>
>  He wants to go forward with draft 1 above.
>
>  Adrian polled and there was some interest and no strong
>  objection.
>
>  Kireeti said that this work cannot be informational if
>  it has - or proposes - changes to a standard.
>
>  Zafar also wants draft 2 to be a WG document.
>
>  Kireeti said that we need to take this to the list, but
>  Zafar also needs to socialize the work he is doing so that
>  people may decide whether or not this is work we want to
>  do.
>
>===
>Everything Else
>---
>Emmanuel Dotaro gave status of Multi-region protection -
>draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt
>
>  He briefly covered changes since previous versions.
>
>  He proposes that we may need to make changes to the
>  charter to include all of this work. In particular to
>  include in the charter the complete set of GMPLS 
>  mechanisms for integrated control planes, and not only
>  multi-layer recovery (as it stands today).
>
>  Adrian suggested that the authors need to get more people
>  involved in this important work and revisit this later.
>
>---
>Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs
>draft-vasseur-ccamp-isis-te-caps-00.txt
>
>  He would like to have this accepted as a WG document.
>
>  Adrian asked to hold off on this until after the OSPF talk
>  below.
>
>---
>Seisho Yasukawa
>draft-vasseur-ccamp-ospf-te-caps-00.txt
>
>  He would like to have this accepted as a WG document.
>
>  Regarding both drafts, Kireeti is not sure that this work
>  belongs in this WG. The decision is driven by the
>  generality of its applicability. If we do take it on, their
>  needs to be a functional specification (independent of IGP)
>  as well.
>
>  He asked that further discussion be taken to the list.
>
>---
>The Following presentations were postponed as we ran out
>of time. Adrian made a couple of brief comments as follows:
>  ---
>  Zafar Ali - Explicit Resource Control and Tracking
>  draft-zamfir-explicit-resource-control-bundle-03.txt
>
>    This work concerns identification of component links in
>    EROs and RROs.
>
>    A small group is currently examining other issues
>    concerning identification of component links in all
>    aspects of GMPLS. A draft is expected soon. Please mail
>    Adrian or the list, if you want to be involved in this
>    work.
>
>  ---
>  Lou Berger - Alarm Reporting
>  draft-berger-ccamp-gmpls-alarm-spec-01.txt
>
>    This draft is stable and complete in the view of the
>    authors.
>
>    A quick poll showed some support for this being a WG
>    document, and no opposition. This will be taken to the
>    list.
>
>
>  
>

-- 
Kohei Shiomoto
NTT Network Innovation Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone]    Fax [phone]






Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2004 00:24:51 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Alex Zinin" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Greg Bernstein" <[e-mail]>, "Eric Mannie" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Kireeti Kompella" <[e-mail]>, "Bert Wijnen" <[e-mail]>
Subject: Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Mon, 15 Mar 2004 16:23:14 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Alex,

In response to the feedback from the RTG-Area Directorate, please find
attached our responses about how we intend incorporating their
feedback.

BTW, thanks to the Directorate for their careful review of the document
and their feedback, we think it will help improve the doc. further.

Once we receive a confirmation that these additions look good, we
will modify the draft, and repost to the IETF drafts directory (I
am assuming that is the next step), and cc  you.

Thanks,
-Vishal, Greg, Eric


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Alex Zinin
> Sent: Thursday, March 04, 2004 4:49 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> Folks-
>
>  Please find below comments from the RTG area directorate that I would
>  like the WG to consider.
>
>  Thank you.
>
> --
> Alex Zinin
>
> Technical:
> ----------
>
> Section 3.2:
>
> 1. Figure 1 misses the STM-0 branch

Thanks for noticing! We will add this using G.707.

> Section 3.4.3:
>
> 2. In comparison table, PNNI word appears for the first time in this
>     document, any specific reason to mention PNNI in a GMPLS context ?

The intent here was just to ask whether a packet-based control
plane was valuable for advanced TDM service provisioning and mgt.
We could reword this to
"Packet-based control plane (like MPLS or PNNI-based) useful?"

> Section 3.5
>
> 3. "New simplified encapsulations could reduce this overhead to as low
>     as 3%, but the gain is not huge compared to SDH and SONET, which have
>     other benefits as well.)" any reference available for these new
>     simplified encapsulation(s) ?


I believe Eric might be able to locate a reference for this. If not, we
will remove in the revised version.

> 4. "Any encapsulation of IP over WDM should at least provide error
>     monitoring capabilities (to detect signal degradation), error
>     correction capabilities, such as FEC (Forward Error Correction) that
>     are particularly needed for ultra long haul transmission, sufficient
>     timing information, to allow robust synchronization (that is, to
>     detect the beginning of a packet), and capacity to transport
>     signaling, routing and management messages, in order to control the
>     optical switches."
>
>     The first part refers to data plane capabilities, however the
>     requirement: the "encapsulation of IP over WDM" should deliver
>     the capacity to transport IP based control plane information -
>     why is this the case ? an out of band network would also do the
>     job and this statement makes thus the implicit assumption that
>     data and control plane topology is congruent

This is an accurate observation.
However, since standardization of IP over WDM without SDH/SONET
is beyond scope here, this could be removed. Although, there still
tends to be confusion when there is talk of "putting IP over lambda",
which does not happen directly.

Alternatively, we could reword this to decouple what
is needed in the data plane from what is required in the control plane,
and mention, in fact, that associated signaling is not a requirement
for GMPLS-based control of SDH/SONET networks, merely one option, and
mention non-associated signaling as the other.


> Section 6:
>
> 5. "Due to the increase in information transferred in the routing
>     protocol, it may be useful to separate the relatively static
>     parameters concerning a link from those that may be subject to
>     frequent changes. The current GMPLS routing extensions [12],[13],
>     [14] do not make such a separation, however."
>
>    it may be thus worth asking the question was the dissemination
>    of these quasi-static "link capabilities" using the same rules
>    as for any other TE LSA Type 1 sub-TLV the right approach ?

>From the carriers perspective, the up-to-date dissemination of all link
properties is essential and desired. The use of a link-state routing
protocol to distribute this information provides timely and efficient
delivery.  Now, if we got to the point that bandwidth updates happened
very frequently, it makes sense, from an efficiency point of view, to
separate them out for update.  This situation is not yet seen in
actual networks, however if GMPLS signaling is put into widespread use
then the need could arise.


> Section 6.1:
>
> 6. what does the following sentence brings in the scope of this control
>     plane framework (and this is even not necessarily true when vcat is
>     provided over different line cards):
>
>     "Note that this inverse multiplexing process can be significantly
>     easier to implement with SONET/SDH signals rather than packets."


Note that the "inverse multiplexing" in this context was used instead of
the then not-yet-standardized VCAT.  This is simpler than doing inverse
multiplexing with packets, because the timing and in-order delivery
of frames is more easily ensured with SDH/SONET signals than it is
with packets (where more sophisticated techniques are needed).

Also, not sure if the reviewer had a different setup in mind, but
component connections of a given VCAT group must terminate on the same
interface.

(As an aside, the signaling framework needs to have hooks for supporting
VCAT.  In particular, multiple VCAT groups can terminate on the same
interface, hence we need be able to tell them apart.  This is even more
important when LCAS capabilities are included since one would want to use
GMPLS signaling to setup and tear down individual "component
connections" of a VCAT group.)


> Section 6.3:
>
> 7. "However, if only standard concatenation is supported then reporting
>     gets trickier since there are constraints on where the STS-1s can be
>     placed. SDH has still more options and constraints, hence it is not
>     yet clear which is the best way to advertise bandwidth resource
>     availability/usage in SONET/SDH. At present, the GMPLS routing
>     protocol extensions define minimum and maximum values for available
>     bandwidth, which allows a remote node to make some deductions about
>     the amount of capacity available at a remote link and the types of
>     signals it can accommodate. However, due to the multiplexed nature
>     of the signals, the authors are of the opinion that reporting of
>     bandwidth particular to signal types rather than as a single
>     aggregate bit rate is probably very desirable."
>
>     -> the authors do not explain from which perspective and the reasons
>     this particular bw accounting report is desirable (sections 2.4.3 &
>     2.4.8 of GMPLS routing explains how these values are used to take
>     into account the multiplexing capability of a SONET/SDH interface),
>     there is no real determination of the missing information at remote
>     nodes for the establishment of an LSP with a certain amount of bw
>     (note that it is not an issue of flexible vs standard concatenation
>     issue but a control plane issue)


This is explained in detail in other sources that would be the
more appropriate references here. So we will provide a reference to
ITU-T documentation (G.7715.1, which outlines this as one of the
requirements)and
to "Optical Network Control, Chapter 12," which provides
an example that underscores reasons why such bandwidth accounting is
desirable.



> Section 7.3:
>
> 8. "This information is specified in three parts [17], each of which
>     refers to a different network layer."
>
> The description of the signaling elements shall mention the following:
> (section 7.3 refers to [17] but the latter does not correspond to the
> description given in this section)
>
>   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
>      which contains three parts: LSP Encoding Type, Switching Type, G-PID
>
>   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as SENDER_TSPEC/FLOWSPEC
>      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT, Transparency,
>      Profile
>
>   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
>
>   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473])

As of the last revision of this document, these were still being worked
out, so the draft spoke about these in generic terms. We will now refer
to the SDH/SONET encoding document, explain that the above parameters
are required, and expand on the use of each a bit, similar to how
it is there in the current text.

>
>
> Editorial:
> ----------
>
> Section 3:
>
> 1. Sometimes this document refers to GMPLS other to MPLS and
>     sometimes as above as "extending IP technology"


The usage of these terms was generally made in the context of how
things were being explained. We will try to uniformize the terms,
and refer consistently to "extending IP/MPLS technology", since both
have been extended for TDM and optical networks.

> Section 3.1
>
> 2. "When a packet reaches a core packet LSR, this LSR uses the label as
>     an index into a forwarding table to determine the next hop and the
>     corresponding outgoing label (and, possibly, the QoS treatment to be
>     given to the packet), writes the new label into the packet, and
>     forwards the packet to the next hop. "
>
> -> replace "core packet LSR" by "packet LSR"

Noted, will do in the revised version.

> Section 3.2:
>
> 3. "SDH and SONET are two TDM standards widely used by operators to
>     transport and multiplex different tributary signals over optical
>     links, thus creating a multiplexing structure, which we call the
>     SDH/SONET multiplex. SDH, which was developed by the ETSI and later
>     standardized by the ITU-T [4], is now used worldwide, while SONET,
>     which was standardized by the ANSI [5], is mainly used in the US.
>     However, these two standards have several similarities, and to some
>     extent SONET can be viewed as a subset of SDH. Internetworking
>     between the two is possible using gateways.
>
>     Should be rather as "ITU-T SDH (G.707) includes both the European
>     ETSI SDH hierarchy and the USA ANSI SONET hierarchy (T1.105)." [...]
>     "The ETSI SDH and SONET standards regarding frame structures and
>     higher order multiplexing are the same. There are some regional
>     differences on the terminology, on the use of some overhead bytes,
>     and lower order multiplexing. Interworking between the two lower
>     order hierarchies is possible using gateways."


Thanks for the new wording! We will make the change as suggested.

> Section 3.2
>
> 4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes)
>     indicates the beginning of the VC/SPE in the payload of the overall
>     STM/SDH frame."
>
> -> replace "STM/SDH frame" by "STM/STS frame"

Thanks, will make the change.

> Section 4.1
>
> 5. "The SONET case is a bit difficult to explain since, unlike in SDH,
>     SPEs in SONET do not have individual names." they are simply referred
>     to as VT-N SPE

We will remove this sentence and instead use the term VT-N SPE,
where needed.

> Section 6:
>
> 6. Since this document distinguishes between "optical networks", TDM,
>     and WDM it would advisable to avoid the "optical TDM" as mentioned
>     in the below sentence (it has another meaning than MSn/RSn switching)

The specific sentence referred to is missing, but we think it's the
one in Section 8 (Conclusions).
"Finally, we reviewed  the signaling elements involved when setting up an
optical TDM
 circuit, ..."

We will remove the word "optical" for clarity.

> Section 6.1:
>
> 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE

Great, thanks for the catch! We will insert that in the second col.

>  > Section 6.1:
>
> 8. "Standard and flexible concatenations are network services, while
>     virtual concatenation is a SONET/SDH end-system service recently
>     approved by the committee T1 of ANSI and ITU-T." remove "recently
>     approved by the committee T1 of ANSI and ITU-T." and add the corr.
>     reference.

Sure, we will add appropriate reference.

> 9. "In one example of virtual concatenation, two end systems supporting
>     this feature could essentially "inverse multiplex" two STS-1s into a
>     virtual STS-2c for the efficient transport of 100 Mbps
> Ethernet traffic."
>
> -> STS-1-2v instead of "virtual STS-2c"

Great, will make the change.

> 10. "Section layer: Preserves all section overhead, Basically does not
>      touch any of the SONET/SDH bits."
>
> -> replace last part by "Basically does not modify or terminate
>     any of the SONET/SDH overhead bits"

Thanks, this is much clearer. We will reword.

>     left column of the table misses the SDH overhead equivalent

<Not sure which table this is referring to. There are only two
in the draft, that I don't see where the overhead is?>

> 11. Multiplexing of (?) in the following sentence "To perform
>      multiplexing, a SONET network element should be line terminating."

Thanks. We will reword as "To perform pipe multiplexing (i.e., multiplexing
of
50 Mbps or 150 Mbps chunks)".

<Guys, is this the right terminology.>

> Section 6.2:
>
> 12. In the following "Standardized SONET line level protection techniques
>      include: Linear 1+1 and linear 1:N automatic protection switching
>      (APS) and both two-fiber and four-fiber bi-directional line switched
>      rings (BLSRs). At the path layer, SONET offers uni-directional path
>      switched ring protection." the same applies to SDH (to be adapted
>      using the corr. terminology)

We will add a corresponding paragraph for SDH.


> Section 7:
>
> 13. "This VC-4 LSP can, in fact, be established between two non-
>      adjacent internal nodes in an SDH network, and later
>      advertised by a routing protocol as a new (virtual) link
>      called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as
>      reference

Sure, will add reference to the hierarchy document.

> 14. The following paragraph
>      "For instance, the payload of an SDH STM-1 frame does not fully
>       contain a complete unit of user data. In fact, the user data is
>       contained in a virtual container (VC) that is allowed to float over
>       two contiguous frames for synchronization purposes. A pointer in the
>       Section Overhead (SOH) indicates the beginning of the VC in the
>       payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3

Thanks, we will fix the text.







Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 22:30:06 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Mon, 15 Mar 2004 17:29:20 -0500
Organization: Cisco Systems
Message-ID: <000e01c40adc$f7f09ac0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see in-line. 

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Yakov Rekhter
>Sent: Monday, March 15, 2004 4:28 PM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>> >> >> SPs don't like to see RSVP Hello running even when there is no 
>> >> >> application requiring them.
>> >> >
>> >> >Could you please describe scenario(s) where you would have RSVP 
>> >> >Hello running "even when there is no application
>> >requiring them".
>> >> >
>> >> >Yakov.
>> >> >
>> >> 
>> >> Hi Yakov,
>> >> 
>> >> Here is a scenario:
>> >> 
>> >> 1. You start without any application that require RSVP Hellos.
>> >> --> You will see RSVP Hellos are NOT running.
>> >> 
>> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
>> >> --> You will see RSVP Hellos start running.
>> >> 
>> >> So far so good :-)
>> >> 
>> >> 3. You disable application requiring RSVP Hello.
>> >> --> One would expect RSVP Hellos to stop but they keeps
>> >running :-( If
>> >> one side stops replying to RSVP Hello, it would cause traffic
>> >> disruption for LSPs that depend on the health of the 
>Hello session. 
>> >> The only way to get around this limitation is to continue to run 
>> >> Hellos.
>> >
>> >The scenario you described above seems to assume that there
>> >are RSVP applications that do *not* require to run RSVP 
>> >Hellos. 
>> 
>> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP 
>> Hello to detect liveness of RSVP module at the neighbor and instead 
>> uses refresh mechanics for this purpose.
>
>In principle one could use the refresh mechanism as a liveness 
>detection of the RSVP module of the control plane. However, 
>the overhead of the refresh mechanism is certainly higher than 
>of Hello. And that is why using RSVP Hellos for detecting 
>liveness of RSVP module of the control plane seems to be the 
>best available today (note that "best" does not imply "the only").
>

So we are in agreement :-) The fact of the matter is that RSVP Hellos
are "optional" and an LSR (say LSR-B) may not reply to RSVP Hello
messages unless the LSR-B ALSO thinks that it needs to establish an RSVP
Hello adjacency. In such cases it is even better if the initiating LSR
(LSR-A) knows intent of LSR-B. In other words, the draft in question
does NOT change the equation, but only helps. 

>Yakov.
>




Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 22:11:12 +0000
From: "zafar ali" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: [RE] Layer One VPNs - sorry for the previous email
Date: Mon, 15 Mar 2004 17:09:59 -0500
Organization: Cisco Systems
Message-ID: <000201c40ada$4283f8f0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C40AB0.59B0FE30"

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C40AB0.59B0FE30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Monday, March 15, 2004 3:40 AM
To: [e-mail]
Subject: [RE] Layer One VPNs - sorry for the previous email



Hi, 
I think the framework document has good guidelins for realizing the
L1VPN in the GMPLS networks.  

Yes, I agree the framework document is a good start. 

 
I'm not sure that the L1VPN service itself could be included in the
CCAMP charter or not, but 
I think functional enhancements for supporting the L1VPN in GMPLS should
be covered in the CCAMP.  

There were also talks about creating a new WG for it. Considering
current work load at CCAMP, this may be a sensible option. I hope we are
able to clarify on home for this work soon. 

Thanks
 
Regards... Zafar

 
Thanks, 
Young 



> Hi, 
> Although Layer One VPNs do not currently have a home in any IETF
working group, we were 
> the recipients of a liaison from ITU-T SG13 informing us about the
work they are doing on 
> this topic and pointing us at 
>
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt 
> If anyone has comments on this work they can send them to this mailing
list (until another 
> home is found in the IETF) or to the authors direct. 
> Thanks, 
> Adrian 


------=_NextPart_000_0003_01C40AB0.59B0FE30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<DIV></DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
[e-mail] [mailto:[e-mail]] <B>On Behalf =
Of=20
</B>[e-mail]<BR><B>Sent:</B> Monday, March 15, 2004 3:40=20
AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> [RE] Layer One =
VPNs -=20
sorry for the previous email<BR><BR></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>Hi, </FONT><BR><FONT size=3D2>I think the framework =
document has=20
  good guidelins for realizing the L1VPN in the GMPLS =
networks.&nbsp;<SPAN=20
  class=3D810130222-15032004><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P></BLOCKQUOTE><FONT =
size=3D2><SPAN=20
class=3D810130222-15032004>
<DIV><SPAN class=3D810130222-15032004><FONT face=3DArial color=3D#000080 =
size=3D2>Yes, I=20
agree the framework document is a good start. =
</FONT></SPAN></DIV></SPAN></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <P><FONT size=3D2><SPAN =
class=3D810130222-15032004>&nbsp;</SPAN></FONT><BR><FONT=20
  size=3D2>I'm not sure that the L1VPN service itself could be included =
in the=20
  CCAMP charter or not, but </FONT><BR><FONT size=3D2>I think functional =

  enhancements for supporting the L1VPN in GMPLS should be covered in =
the=20
  CCAMP.&nbsp;<SPAN class=3D810130222-15032004><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P></BLOCKQUOTE>
<P dir=3Dltr><FONT size=3D2><SPAN class=3D810130222-15032004><FONT =
face=3DArial=20
color=3D#000080>There were also talks about creating a new WG for it. =
Considering=20
current work load at CCAMP, this may be a sensible option. I hope we are =
able to=20
clarify on home for this work soon. </FONT></P>
<DIV align=3Dleft><FONT face=3DArial color=3D#000080 =
size=3D2>Thanks</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#000080 =
size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#000080 size=3D2>Regards... =

Zafar</FONT></DIV>
<P dir=3Dltr>&nbsp;</SPAN></FONT><BR><FONT size=3D2>Thanks,</FONT> =
<BR><FONT=20
size=3D2>Young</FONT> </P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px"><BR><BR>
  <P><FONT size=3D2>&gt; Hi,</FONT> <BR><FONT size=3D2>&gt; Although =
Layer One VPNs=20
  do not currently have a home in any IETF working group, we were=20
  </FONT><BR><FONT size=3D2>&gt; the recipients of a liaison from ITU-T =
SG13=20
  informing us about the work they are doing on </FONT><BR><FONT =
size=3D2>&gt;=20
  this topic and pointing us at </FONT><BR><FONT size=3D2>&gt; <A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-=
00.txt"=20
  =
target=3D_blank>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-fr=
amework-00.txt</A></FONT>=20
  <BR><FONT size=3D2>&gt; If anyone has comments on this work they can =
send them=20
  to this mailing list (until another </FONT><BR><FONT size=3D2>&gt; =
home is found=20
  in the IETF) or to the authors direct.</FONT> <BR><FONT size=3D2>&gt; =
Thanks,=20
  </FONT><BR><FONT size=3D2>&gt; Adrian</FONT> =
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0003_01C40AB0.59B0FE30--




Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 21:28:57 +0000
Message-Id: <[e-mail]>
To: "zafar ali" <[e-mail]>
cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, [e-mail], "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, [e-mail], "'Reshad Rahman'" <[e-mail]>, [e-mail]
Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 15 Mar 2004 13:28:15 -0800
From: Yakov Rekhter <[e-mail]>

Zafar,

> >> >> SPs don't like to see RSVP Hello running even when there is
> >> >> no application requiring them.
> >> >
> >> >Could you please describe scenario(s) where you would have
> >> >RSVP Hello running "even when there is no application 
> >requiring them".
> >> >
> >> >Yakov.
> >> >
> >> 
> >> Hi Yakov,
> >> 
> >> Here is a scenario:
> >> 
> >> 1. You start without any application that require RSVP Hellos.
> >> --> You will see RSVP Hellos are NOT running.
> >> 
> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
> >> --> You will see RSVP Hellos start running.
> >> 
> >> So far so good :-)
> >> 
> >> 3. You disable application requiring RSVP Hello.
> >> --> One would expect RSVP Hellos to stop but they keeps 
> >running :-( If
> >> one side stops replying to RSVP Hello, it would cause traffic 
> >> disruption for LSPs that depend on the health of the Hello session. 
> >> The only way to get around this limitation is to continue to run 
> >> Hellos.
> >
> >The scenario you described above seems to assume that there 
> >are RSVP applications that do *not* require to run RSVP 
> >Hellos. 
> 
> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP
> Hello to detect liveness of RSVP module at the neighbor and instead uses
> refresh mechanics for this purpose. 

In principle one could use the refresh mechanism as a liveness
detection of the RSVP module of the control plane. However, the
overhead of the refresh mechanism is certainly higher than of Hello.
And that is why using RSVP Hellos for detecting liveness of RSVP
module of the control plane seems to be the best available today
(note that "best" does not imply "the only").

Yakov.



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 21:20:18 +0000
Message-ID: <0ac201c40ad3$31073670$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, <[e-mail]>
Subject: Re: ason-routing-reqts: issue 2 architecture
Date: Mon, 15 Mar 2004 21:18:06 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I assume that the desire is to have one control plane entity mange multiple data plane
entities (not to have one data plane entity managed by multiple control plane entities).

I believe. in this context, it might be helpful to separate the signaling function (and
the associated routing function for the delivery of the signaling messages) from the TE
advertisement routing function. Since we are discussing the routing requirements (this is
the routing DT) can I assume that the discussion is limited to the TE advertisement
routing function, with the aim to have one control plane entity advertise the resources on
behalf of multiple data plane entities.

If all of the above, why could you not simply do this using RFC3630? The only wrinkle
might be that the Router Address TLV is described as carrying "a stable IP address of the
advertising router". Clearly, this needs to be interpreted as "a stable IP address of the
control plane entity that manages the resources on behalf of the data plane entity whose
resources are being advertised."

Am I missing something?

Adrian

----- Original Message ----- 
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>
Sent: Monday, March 15, 2004 7:43 PM
Subject: ason-routing-reqts: issue 2 architecture


ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

The second DT issue is on the physical architecture which can be supported by GMPLS (from
the draft):

ASON does not restrict the architecture choices used, either a co-located architecture or
a physically separated architecture may be used. Some members of the Design Team are
concerned that GMPLS's concept of the LSR requires a 1-to-1 relationship between the
transport plane entity and the control plane entity (Router). They invite CCAMP input on
GMPLS capabilities to support multiple architectures i.e. how routing protocols would
identify the transport node ID vs. the router or routing controller ID when scoping Link
IDs in a link advertisement.
Deborah






Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 20:59:21 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Mon, 15 Mar 2004 15:58:24 -0500
Organization: Cisco Systems
Message-ID: <000001c40ad0$44a2c5d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yakov, 

Please see my reply in-line. 

Thanks
 
Regards... Zafar

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf 
>Of Yakov Rekhter
>Sent: Monday, March 15, 2004 2:31 PM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>[e-mail]; 'Loa Andersson'; 'George Swallow'; 
>[e-mail]; 'Reshad Rahman'; [e-mail]
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>Zafar,
>
>> >> SPs don't like to see RSVP Hello running even when there is
>> >> no application requiring them.
>> >
>> >Could you please describe scenario(s) where you would have
>> >RSVP Hello running "even when there is no application 
>requiring them".
>> >
>> >Yakov.
>> >
>> 
>> Hi Yakov,
>> 
>> Here is a scenario:
>> 
>> 1. You start without any application that require RSVP Hellos.
>> --> You will see RSVP Hellos are NOT running.
>> 
>> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
>> --> You will see RSVP Hellos start running.
>> 
>> So far so good :-)
>> 
>> 3. You disable application requiring RSVP Hello.
>> --> One would expect RSVP Hellos to stop but they keeps 
>running :-( If
>> one side stops replying to RSVP Hello, it would cause traffic 
>> disruption for LSPs that depend on the health of the Hello session. 
>> The only way to get around this limitation is to continue to run 
>> Hellos.
>
>The scenario you described above seems to assume that there 
>are RSVP applications that do *not* require to run RSVP 
>Hellos. 

Yes. Specifically, basic RSVP signaling does NOT require use of RSVP
Hello to detect liveness of RSVP module at the neighbor and instead uses
refresh mechanics for this purpose. Furthermore, RFC3209 says that "The
Hello Message is completely OPTIONAL". 

>However, I think this assumption is fairly problematic 
>for the following reason.
>
>RSVP Hello have dual semantics - (a) liveness of RSVP module 
>of the control plane, and (b) liveness of data plane between 
>RSVP neighbors.  While there are better ways to detect 
>liveness of the data plane than to use RSVP Hellos (BFD is 
>certainly better than RSVP Hello for that purpose), using RSVP 
>Hellos for detecting liveness of RSVP module of the control 
>plane seems to be the best available today. 

Agreed! And I did not say that. Yes, RSVP/ GR is one such application
that makes use of RSVP Hello for this purpose. 

> And running an 
>application that uses RSVP, without being able to detect the 
>state of the RSVP module of the control plane of a neighbor 
>seems to be fairly problematic (to say the least).

Yes, I agree. I think your and my definition of "application" is
different. Nonetheless, do you agree that basic RSVP signaling can work
without RSVP Hello? Otherwise I would expect your implementation starts
sending RSVP Hellos as soon as RSVP is configured on an interface, is
this the case? Please advise. 

>
>Yakov.
>




Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 20:04: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: ason-routing-reqts: issue 3 evolution
Date: Mon, 15 Mar 2004 14:03:54 -0600
Message-ID: <[e-mail]>
Thread-Topic: ason-routing-reqts: issue 3 evolution
Thread-Index: AcQKyKXj/oKmZnaGEdikGURFU1QAAA==
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>

ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-req=
ts-02.txt

The third DT issue is on the support of GMPLS for evolution (from the =
draft):

In order to support operator assisted changes in the containment =
relationships of RAs, the GMPLS routing protocol is expected to support =
evolution in terms of number of hierarchical levels of RAs (adding and =
removing RAs at the top/bottom of the hierarchy), as well as aggregation =
and segmentation of RAs. These GMPLS routing capabilities are considered =
of lower priority as they are implementation specific and their method =
of support should be evaluated on per-protocol basis e.g. OSPF vs IS-IS. =
In addition, support of non-disruptive operations such as adding or =
removing a hierarchical level of RAs in or from the middle of the =
routing hierarchy are considered as the lowest priority requirements. =
Note also that the number of hierarchical levels to be supported is =
implementation specific, and reflects a containment relationship e.g. a =
RA insertion involves supporting a different routing protocol domain in =
a portion of the network.
Note: some members of the Design Team question if the ASON requirement =
for supporting architecture evolution is a requirement on the routing =
protocol (protocol specific capability) vs. a capability to be provided =
by the architecture. For example, ASON allows for supporting multiple =
protocols within each RA. The multiple protocols share a common routing =
information database (RDB), and the RDB is the component, which needs to =
support architecture evolution. The Design Team invites CCAMP input to =
understand the protocol-specific impacts.=20
Deborah




Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 19:44:25 +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: ason-routing-reqts: issue 2 architecture
Date: Mon, 15 Mar 2004 13:43:41 -0600
Message-ID: <[e-mail]>
Thread-Topic: ason-routing-reqts: issue 2 architecture
Thread-Index: AcQKxdKr/oKmZXaGEdikGURFU1QAAA==
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>

ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-req=
ts-02.txt

The second DT issue is on the physical architecture which can be =
supported by GMPLS (from the draft):

ASON does not restrict the architecture choices used, either a =
co-located architecture or a physically separated architecture may be =
used. Some members of the Design Team are concerned that GMPLS's concept =
of the LSR requires a 1-to-1 relationship between the transport plane =
entity and the control plane entity (Router). They invite CCAMP input on =
GMPLS capabilities to support multiple architectures i.e. how routing =
protocols would identify the transport node ID vs. the router or routing =
controller ID when scoping Link IDs in a link advertisement.=20
Deborah



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 19:31:58 +0000
Message-Id: <[e-mail]>
To: "zafar ali" <[e-mail]>
cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, [e-mail], "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, [e-mail], "'Reshad Rahman'" <[e-mail]>, [e-mail]
Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 15 Mar 2004 11:31:18 -0800
From: Yakov Rekhter <[e-mail]>

Zafar,

> >> SPs don't like to see RSVP Hello running even when there is 
> >> no application requiring them.
> >
> >Could you please describe scenario(s) where you would have 
> >RSVP Hello running "even when there is no application requiring them".
> >
> >Yakov.
> >
> 
> Hi Yakov, 
> 
> Here is a scenario: 
> 
> 1. You start without any application that require RSVP Hellos. 
> --> You will see RSVP Hellos are NOT running. 
> 
> 2. You enable an application (GR/ FRR) requiring RSVP Hellos. 
> --> You will see RSVP Hellos start running. 
> 
> So far so good :-) 
> 
> 3. You disable application requiring RSVP Hello. 
> --> One would expect RSVP Hellos to stop but they keeps running :-( If
> one side stops replying to RSVP Hello, it would cause traffic disruption
> for LSPs that depend on the health of the Hello session. The only way to
> get around this limitation is to continue to run Hellos. 

The scenario you described above seems to assume that there are
RSVP applications that do *not* require to run RSVP Hellos. However,
I think this assumption is fairly problematic for the following
reason.

RSVP Hello have dual semantics - (a) liveness of RSVP module of
the control plane, and (b) liveness of data plane between RSVP
neighbors.  While there are better ways to detect liveness of the
data plane than to use RSVP Hellos (BFD is certainly better than
RSVP Hello for that purpose), using RSVP Hellos for detecting
liveness of RSVP module of the control plane seems to be the best
available today.  And running an application that uses RSVP, without
being able to detect the state of the RSVP module of the control
plane of a neighbor seems to be fairly problematic (to say the least).

Yakov.



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 19:30:40 +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: ason-routing-reqts: issue 1 addressing
Date: Mon, 15 Mar 2004 13:29:21 -0600
Message-ID: <[e-mail]>
Thread-Topic: ason-routing-reqts: issue 1 addressing
Thread-Index: AcQKw9Io/oKmZHaGEdikGURFU1QAAA==
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>

As noted in the CCAMP minutes and the DT's presentation, the ASON =
routing DT had three issues regarding GMPLS support for which they =
lacked agreement and request support of the WG. The issues are =
identified in Section 7 (Conclusions) of the draft:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-req=
ts-02.txt

I will post three separate email threads to cover each issue. The first =
issue is on address reachability. The following is the text from the =
draft:

Some members of the Design Team noted that reachability information (as =
described in Section 4.5.3) may be advertised as a set of UNI Transport =
Resource address prefixes (assigned and selected consistently in their =
applicability scope). These members of the Design Team raised a concern =
that existing methods of advertising reachability may need to be =
examined (on a per-protocol basis) to determine if they are also =
applicable for UNI Transport Resource addresses. They invite CCAMP =
discussion on this aspect.
Deborah





Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 18:22:22 +0000
Date: Mon, 15 Mar 2004 13:21:08 -0500
Message-Id: <[e-mail]>
From: "Amy Katherine" <[e-mail]>
To: [e-mail]
Subject: Re: [iesg-secretary #20173] Liaison statement from ITU-T SG 13 to IETF Routing Area (CCAMP) o
Cc: [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]

Your request #20173 was updated by amyk:

Dear Georges,

Your Liaison Statement entitled "Information on L1VPN related
work," with its two attachments, "Layer 1 VPN work in SG 13 up to
now" and "Questionaire in the area of Layer 1 VPN series," have
been posted on the "Liaison Statements" Web page
(http://www.ietf.org/IESG/liaison.html).

Thank you,

The IETF Secretariat



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 17:39:14 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Mar 2004 18:39:35 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Tomonori TAKEDA <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [RE] Layer One VPNs - sorry for the previous email
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi tomonori, young, all,

the proposed framework document (part of this discussion)
deliversa good starting point in terms of functionality

some more specific comment on this document:

- it mentions an issue concerning the "shared control link" it
may be advisable to detail more accurately the expectation in
terms of functionality and then assess whether a shared control
link can be used in this context, the addition to which you're
referring seems to imply a mux/de-mux mechanism - it would be
of great interest to see how this compares with Section 4 of
the GVPN id

- section 4.1, performance is included as service do you mean
this as a classification of the quality of the delivered service
or do you mean that it is a service to allow customer to monitor
performance of the delivered service ?

- there is the issue of the "PE-PE virtual links" and in case of
"Per VPN Peer model" more details should be provided in order to
assess whether existing GMPLS mechanisms are sufficient (from
that perspective details about the following sentence might be
of interest because it seems you took this as initial working
assumption "there is currently no leakage of routing information
across the PE to CE boundary.")

- i would suggest to conclude the document with the expected
delta requirement from gmpls perspective (this would help in
assessing what's expected in terms of protocol for the next
step(s))

- an edit concerning the section on terminology it would be
of great help for this community to point the differences (if
any) from the existing [TERM] document

thanks,
- dimitri.

Tomonori TAKEDA wrote:

> Hi, Young,
> 
> Thank you for your comments.
> 
> Yes, I think the functional enhancement for UNI (overlay) and NNI (peer) 
> to support the Layer 1 VPN is a crucial point for the provider that 
> wants to provide connectivity services within limited group of customer 
> devices (enhancement from public services). I see that you are in line 
> with this important benefit of the L1 VPN. Comments are really appreciated.
> 
> At 17:40 04/03/15 +0900, [e-mail] wrote:
> 
>> Hi,
>> I think the framework document has good guidelins for realizing the 
>> L1VPN in the GMPLS networks.
>> I'm not sure that the L1VPN service itself could be included in the 
>> CCAMP charter or not, but
>> I think functional enhancements for supporting the L1VPN in GMPLS 
>> should be covered in the CCAMP.
>> Thanks,
>> Young
>>
>>
>> > Hi,
>> > Although Layer One VPNs do not currently have a home in any IETF 
>> working group, we were
>> > the recipients of a liaison from ITU-T SG13 informing us about the 
>> work they are doing on
>> > this topic and pointing us at
>> > 
>> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt 
>>
>> > If anyone has comments on this work they can send them to this 
>> mailing list (until another
>> > home is found in the IETF) or to the authors direct.
>> > Thanks,
>> > Adrian
> 
> 
> -----
> Tomonori TAKEDA
> NTT Network Service Systems Lab.
> Phone: [phone]
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 17:03:23 +0000
From: "zafar ali" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
Date: Mon, 15 Mar 2004 12:01:55 -0500
Organization: Cisco Systems
Message-ID: <000001c40aaf$3a90a8d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<snip>
>
>>          SPs don't like to see RSVP Hello running even when there is 
>> no application requiring them.
>
>Could you please describe scenario(s) where you would have 
>RSVP Hello running "even when there is no application requiring them".
>
>Yakov.
>

Hi Yakov, 

Here is a scenario: 

1. You start without any application that require RSVP Hellos. 
--> You will see RSVP Hellos are NOT running. 

2. You enable an application (GR/ FRR) requiring RSVP Hellos. 
--> You will see RSVP Hellos start running. 

So far so good :-) 

3. You disable application requiring RSVP Hello. 
--> One would expect RSVP Hellos to stop but they keeps running :-( If
one side stops replying to RSVP Hello, it would cause traffic disruption
for LSPs that depend on the health of the Hello session. The only way to
get around this limitation is to continue to run Hellos. 

Furthermore, the draft also formalizes procedure for disabling RSVP GR.
Hence in these respect the problem space for
draft-minei-mpls-ldp-planned-restart-00.txt &
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt is the same.  IMO both drafts
address a similar but useful need in operation of networks. 

Like we mentioned in CCAMP WG meeting, we are open to the solution for
administrative shut-down of RSVP Hellos. My comment for
draft-minei-mpls-ldp-planned-restart-00.txt to make the text more
generic as a way to enable/ disable LDP/ GR on the fly. Ina, et al may
like to consider this comment. 

Thanks

Regards... Zafar




Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 16:27:02 +0000
Message-Id: <[e-mail]>
To: "zafar ali" <[e-mail]>
cc: "'Rahul Aggarwal'" <[e-mail]>, "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, [e-mail], "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, [e-mail], "'Reshad Rahman'" <[e-mail]>, [e-mail]
Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 15 Mar 2004 08:26:00 -0800
From: Yakov Rekhter <[e-mail]>

Zafar,

> >Hi Zafar,
> >
> >[snipped]
> >
> >>
> >> Thanks for your reply. We have a similar draft in CCAMP that 
> >> formalized procedure for disabling RSVP GR (and Hello) (see,
> >> 
> >http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-hello-gr-admi
> >> n-
> >> 00.txt for details).
> >>
> >> The requirements/ motivations for the two drafts in question are 
> >> similar.
> >
> >The difference is that RSVP-TE already supports the ability to 
> >toggle the graceful restart capability of a router by 
> >including/excluding the restart capability object in RSVP-TE 
> >hellos. This can be done without breaking the neighbor 
> >relationship between the adjacent routers.
> >
> 
> Hi Rahul, 
> 
> We would not be having "part" of this discussion had there be a
> statement stating the same in RFC 3473; a clarification is needed.
> Furthermore, SPs have similar motivations for removing RSVP Hello
> adjacencies without cause triggering FRR or GR. 
> Not to mention due to possible millisecond
> interval, 

Perhaps running RSVP Hellos as millisecond interval is not a wise 
idea in the first place. 

>          SPs don't like to see RSVP Hello running even when there is no
> application requiring them. 

Could you please describe scenario(s) where you would have RSVP Hello
running "even when there is no application requiring them".

Yakov.



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 16:19:05 +0000
Message-Id: <6.0.3.0.2.20040315111651.02fdee20@mo-ex1>
Date: Mon, 15 Mar 2004 11:17:07 -0500
To: "Kireeti Kompella" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:46 PM 3/13/2004 -0500, Kireeti Kompella wrote:

>While there wasn't ringing approval for moving this forward, there was
>reasonable interest.  Lou, please republish as a WG doc.

Done.





Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 16:18:53 +0000
Message-Id: <6.0.3.0.2.20040315111608.032634d0@mo-ex1>
Date: Mon, 15 Mar 2004 11:16:31 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: draft-berger-gmpls-egress-control-01.txt to Working Group status
Cc: <[e-mail]>, "Berger, Lou" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Done.

I think your section refs are off...

Lou

At 05:40 AM 3/13/2004 -0500, Adrian Farrel wrote:

>All,
>
>We have heard consensus for this draft to become a working group document.
>
>Authors, please re-submit as draft-ietf-ccamp-gmpls-egress-control-00.txt 
>and with no
>other changes EXCEPT
>- dates
>- new IPR boilerplate (RFC3667, 8 and 9)
>
>Thanks,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 16:03:11 +0000
Message-Id: <[e-mail]>
Date: Tue, 16 Mar 2004 01:00:40 +0900
To: [e-mail], [e-mail]
From: Tomonori TAKEDA <[e-mail]>
Subject: Re: [RE] Layer One VPNs - sorry for the previous email
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi, Young,

Thank you for your comments.

Yes, I think the functional enhancement for UNI (overlay) and NNI (peer) to 
support the Layer 1 VPN is a crucial point for the provider that wants to 
provide connectivity services within limited group of customer devices 
(enhancement from public services). I see that you are in line with this 
important benefit of the L1 VPN. Comments are really appreciated.

At 17:40 04/03/15 +0900, [e-mail] wrote:

>Hi,
>I think the framework document has good guidelins for realizing the L1VPN 
>in the GMPLS networks.
>I'm not sure that the L1VPN service itself could be included in the CCAMP 
>charter or not, but
>I think functional enhancements for supporting the L1VPN in GMPLS should 
>be covered in the CCAMP.
>Thanks,
>Young
>
>
> > Hi,
> > Although Layer One VPNs do not currently have a home in any IETF 
> working group, we were
> > the recipients of a liaison from ITU-T SG13 informing us about the 
> work they are doing on
> > this topic and pointing us at
> > 
> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt 
>
> > If anyone has comments on this work they can send them to this 
> mailing list (until another
> > home is found in the IETF) or to the authors direct.
> > Thanks,
> > Adrian

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: [phone]





Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 08:38:55 +0000
Message-ID: <0957B4ABF486CF4E8494A29B85DEE51001068429@cms1>
From: [e-mail]
To: [e-mail]
Subject: [RE] Layer One VPNs - sorry for the previous email
Date: Mon, 15 Mar 2004 17:40:24 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40A69.28B10470"

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_01C40A69.28B10470
Content-Type: text/plain;
	charset="euc-kr"

Hi, 
I think the framework document has good guidelins for realizing the L1VPN
in the GMPLS networks. 
I'm not sure that the L1VPN service itself could be included in the CCAMP
charter or not, but 
I think functional enhancements for supporting the L1VPN in GMPLS should be
covered in the CCAMP. 
Thanks,
Young



> Hi,
> Although Layer One VPNs do not currently have a home in any IETF working
group, we were 
> the recipients of a liaison from ITU-T SG13 informing us about the work
they are doing on 
> this topic and pointing us at 
> http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
> If anyone has comments on this work they can send them to this mailing
list (until another 
> home is found in the IETF) or to the authors direct.
> Thanks, 
> Adrian

------_=_NextPart_001_01C40A69.28B10470
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>[RE] Layer One VPNs - sorry for the previous email</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi, </FONT>
<BR><FONT SIZE=3D2>I think the framework document has good guidelins =
for realizing the L1VPN in the GMPLS networks. </FONT>
<BR><FONT SIZE=3D2>I'm not sure that the L1VPN service itself could be =
included in the CCAMP charter or not, but </FONT>
<BR><FONT SIZE=3D2>I think functional enhancements for supporting the =
L1VPN in GMPLS should be covered in the CCAMP. </FONT>
<BR><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Young</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; Although Layer One VPNs do not currently have a =
home in any IETF working group, we were </FONT>
<BR><FONT SIZE=3D2>&gt; the recipients of a liaison from ITU-T SG13 =
informing us about the work they are doing on </FONT>
<BR><FONT SIZE=3D2>&gt; this topic and pointing us at </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework=
-00.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-takeda-l1vpn=
-framework-00.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; If anyone has comments on this work they can =
send them to this mailing list (until another </FONT>
<BR><FONT SIZE=3D2>&gt; home is found in the IETF) or to the authors =
direct.</FONT>
<BR><FONT SIZE=3D2>&gt; Thanks, </FONT>
<BR><FONT SIZE=3D2>&gt; Adrian</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C40A69.28B10470--



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 08:15:10 +0000
Message-ID: <0957B4ABF486CF4E8494A29B85DEE51001068427@cms1>
From: [e-mail]
To: [e-mail]
Subject: [RE] Layer One VPNs
Date: Mon, 15 Mar 2004 17:15:46 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40A65.B7ADCF54"

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_01C40A65.B7ADCF54
Content-Type: text/plain;
	charset="euc-kr"

Hi,
I think the framework document has good guidelins for realizing the L1VPN
in the GMPLS networks.
I'm not sure that the L1VPN service itself could be included in the CCAMP
charter or not, but
I think functional enhancements for supporting the L1VPN in GMPLS should be
covered in the CCAMP.

Hi,
Although Layer One VPNs do not currently have a home in any IETF working
group, we were 
the recipients of a liaison from ITU-T SG13 informing us about the work
they are doing on 
this topic and pointing us at 
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
If anyone has comments on this work they can send them to this mailing list
(until another 
home is found in the IETF) or to the authors direct.
Thanks, 
Adrian

------_=_NextPart_001_01C40A65.B7ADCF54
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>[RE] Layer One VPNs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
<BR><FONT SIZE=3D2>I think the framework document has good guidelins =
for realizing the L1VPN in the GMPLS networks.</FONT>
<BR><FONT SIZE=3D2>I'm not sure that the L1VPN service itself could be =
included in the CCAMP charter or not, but</FONT>
<BR><FONT SIZE=3D2>I think functional enhancements for supporting the =
L1VPN in GMPLS should be covered in the CCAMP.</FONT>
</P>

<P><FONT SIZE=3D2>Hi,</FONT>
<BR><FONT SIZE=3D2>Although Layer One VPNs do not currently have a home =
in any IETF working group, we were </FONT>
<BR><FONT SIZE=3D2>the recipients of a liaison from ITU-T SG13 =
informing us about the work they are doing on </FONT>
<BR><FONT SIZE=3D2>this topic and pointing us at </FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework=
-00.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-takeda-l1vpn=
-framework-00.txt</A></FONT>
<BR><FONT SIZE=3D2>If anyone has comments on this work they can send =
them to this mailing list (until another </FONT>
<BR><FONT SIZE=3D2>home is found in the IETF) or to the authors =
direct.</FONT>
<BR><FONT SIZE=3D2>Thanks, </FONT>
<BR><FONT SIZE=3D2>Adrian</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C40A65.B7ADCF54--



Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2004 01:40:09 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Last call on Protection and Restoration Design Team drafts
Date: Sun, 14 Mar 2004 17:37:20 -0800
Message-ID: <003701c40a2e$0f0b2ae0$6f01a8c0@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes to all,
Richard.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On =
Behalf
> Of Adrian Farrel
> Sent: Thursday, March 04, 2004 3:24 AM
> To: [e-mail]
> Subject: Last call on Protection and Restoration Design Team drafts
>=20
> As discussed in the CCAMP meeting today, the Protection and =
Restoration
> Design Team drafts
> have been around and stable for a long time.
>=20
> The terminology draft =
(draft-ietf-ccamp-gmpls-recovery-terminology-03.txt)
> is marked as
> standards track, but clearly does not require an implementation.
>=20
> The Functional Analysis draft =
(draft-ietf-ccamp-gmpls-recovery-functional-
> 01.txt) is
> neither marked as informational nor standards track - perhaps the =
editors
> would like to
> fix this as a last call comment. Nevertheless, this is clearly not =
aimed
> at having an
> implementation.
>=20
> The Recovery Analysis draft (draft-ietf-ccamp-gmpls-recovery-analysis-
> 02.txt) is
> informational and does not need an implementation.
>=20
>=20
> This email begins a working group last call on
> draft-ietf-ccamp-gmpls-recovery-terminology-03.txt,
> draft-ietf-ccamp-gmpls-recovery-functional-01.txt and
> draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>=20
> The last call will end on Friday 26th March at 12 noon GMT.
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-
> terminology-03.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-
> functional-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-
> analysis-02.txt
>=20
> Comments to the list or to the chairs direct.
> Thanks,
> Adrian
>=20





Envelope-to: [e-mail]
Delivery-date: Sun, 14 Mar 2004 12:02:35 +0000
Message-ID: <095801c409bb$c78a7210$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Revised draft minutes
Date: Sun, 14 Mar 2004 11:58:20 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This draft incorporates feedback from Dimitri and Vishal
and from an anonymous reviewer. Thanks.

Further comments ASAP.

Adrian


Common Control and Measurement Plane WG (ccamp)

THURSDAY, March 4 at 0900-1130
===============================

CHAIRS: Kireeti Kompella <[e-mail]>
        Adrian Farrel <[e-mail]>

AGENDA:

===
Group Admin
---
Chairs
  Admin - Nothing much to say (in English anyway)
        - In Korean, however, the following was said:
          "Jigeumbuteo CCAMP meetingeul sijakhagesumnida".

  Agenda bash (5 mins) - No changes
  Status of WG drafts and milestones
    Adrian's slides showed that we do have some draft
    congestion in the WG.
    - RFC editor queue
    - status of IANA for SONET/SDH
      Kireeti talked about an issue with SONET/SDH IANA
      assignments
    - need a means to get early assignments.
      There is WIP to accomplish this, and it is moving
      ahead.
    - future allocation of "experimental" values

Liaisons
---
Marco Carugi talked about work in SG-13 (SG13 liaison).
  He covered topics, new study areas, timescales, objectives
  and status. They are also looking for people interested in
  doing work in these areas.

  An L1 VPN questionnaire and framework draft were attached
  to the liaison.

  Tomonori Takeda talked about the technical issues and
  details of the work.

  Monique Morrow had a couple of clarification for Marco -
  When will the consent portion of the work be done in the
  ITU?

    Marco said that the different pieces of work were
    progressing at different speeds. Some material is
    already embodied in recommendations. The next SG13
    meetings are in June and September.

  Dimitri Papadimitriou asked if the draft (l1vpn 
  framework) provided in the liaison could include a 
  summarization (as conclusion) on the expected GMPLS work
  for the CCAMP WG, this would clarify the intent of the
  liaison in term of expected effort for the CCAMP WG

    Kireeti answered. If CCAMP's rechartering this month
    results in the addition of L1VPNs to the charter, then
    a Liaison response from the IETF will include this
    information, plus a request for a cooperative effort,
    preferably along the lines of the ASON routing work,
    wherein the ITU-T defines the requirements and the IETF
    does the protocol extensions.

  Alex Zinin said that we will have to make a decision at
  some point as to whether or not we want to do this work
  here.

  Someone from NTT raised a point that was not captured in
  the minutes.

  Deborah Brungard said that there is work and some synergy
  and that we should continue to work on this.

    Monique Morrow agrees that we should work on that.

    Marco added some comments that were not captured in the
    minutes.

    Malcolm Betts said he also feels that we should do this.

  Adrian took a quick poll and it seems as if nobody is
  against doing this work.

  Kireeti reminded people to continue this discussion on
  the list.

---
Lyndon Ong talked about work in SG-15 (3 liaisons).

  Liaisons were on ASON routing requirements, response to
  comments on Q14 for G.7713.2 and comments on the CCAMP
  ASON signaling requirements draft.

  Lyndon spent much of the time on the details of response
  to comments on Q14. It seems that some of the differences
  in architectural models revolve around "end-to-end" and
  "call segment" operating models.

  Kireeti asked for the reply by date.

    Lyndon did not have that.

    Steve Trowbridge said that the meeting starts on April
    19th

  Dimitri had a question on the deadline. There is a
  deadline on G.7713 (April 2004), isn't there a similar
  deadline on G.7713.2 (since this is the document to which
  convergence is expected) ?

    Lyndon said that he had not gone into that. He gave a
    reason, but this was not captured in the minutes.

  Deborah said that the liaison for 7713.2 does not say any
  thing about convergence.

    Lyndon said that they are still looking for a "meeting
    of the minds".

  Deborah said that there is an issue with G.7713.2 because
  of compatibility.

    Lyndon said that yes there has been a lot of discussion
    of compatibility questions and requirements.

  Kireeti said that we should not discuss this here.

  Steve Trowbridge added some comments that were not
  captured in the minutes.

  Kireeti asked the WG to take this discussion to the list
  and try to keep that discussion on a productive basis.

  Adrian said that he wanted to recognize the efforts of
  the ITU folks in this work.

===
ASON Requirements and Solutions
---
Dimitri Papadimitriou presented status of ASON Signaling
Requirements (draft-ietf-ccamp-gmpls-ason-reqts-05.txt.

  The requirements were driven by last year's liaison from
  the ITU.

  The discussion slides proposed to defer to the GROW WG 
  (cf. RIFT WG item) concerning the (external) non-IP
  reachability issue since much broader than just CCAMP
  GMPLS/ASON context

  After this meeting, Dimitri would like to re-spin the
  draft and have a two week last call.

  Lyndon said he want to capture the requirement on "non-IP
  reachability" - whether or not we will work on it here

  Kireeti said that we first need to understand importance
  of this and then we can look to the ADs for guidance on
  handling this.  He also said that we should take some time
  to work out what we want to say to the ITU when we include
  the current draft.

---
Dimitri Papadimitriou gave status ASON Signaling Solutions
(draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt) status.

  He would like feedback on whether or not the current draft
  deals correctly with the session attribute object that
  encodes the long call_id (alternatives were also proposed)

  His objective at this point is to try to have a document
  ready for last call for the next IETF 60 meeting in San
  Diego

  Lyndon suggested that we might remove the comparison with
  G.7713 from the draft.

    Adrian asked if this meant that the interworking draft
    for RFC3473/4 interworking was now obsolete.

      Lyndon said maybe, if interworking is removed as a
      requirement.

---
Lou Berger talked about Egress Control -
draft-berger-gmpls-egress-control-01.txt -

  Original egress label control became explicit label
  control. This draft attempts to capture the original
  intent.

  He wants to know if the WG feels that this is ready to
  be a BCP and what the chairs think the next steps should
  be.

  Lou re-iterated that the purpose and scope of the draft
  is for clarification. He does not see any value in adding
  to this intent or combining it with other work.

  Adrian then took a poll and nobody objected to take this
  on as a WG item (more than a third were in favor).

---
Lyndon Ong went over status on ASON Routing Requirements -
draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

  He includes in his presentation the Design Team's 
  conclusions as to what there is agreement about what's
  missing from GMPLS (delta), and what are the areas on 
  which there is no agreement about what's missing from 
  GMPLS.

  Vishal Sharma asked if the three issues (slide 6) were 
  already opened up for discussion on the list, or would 
  they be formally opened up with the DT members initiating
  a discussion on these on the list?

    Lyndon Ong replied that a discussion had not been
    formally opened up yet (although people were free to
    discuss/comment).

      Kireeti asked Lyndon to more formally open this
      discussion on the mailing list.

  Vishal Sharma said that he supports this.

  Kireeti said he would like - after checking with the AD -
  that we should take this work to the IS-IS and OSPF WGs.

    Alex Zinin said this is a good idea.

===
Tunnel Trace
---
Ron Bonica presented status on draft-bonica-tunproto-05.txt

  The solution is very similar to Trace-Route but does not
  require that each node in a tunnel supports TTL decrement.

  He gave a few examples as to how the idea in the draft
  will work in a few scenarios.

  There are a couple of outstanding issues:
  - trace requires a route to tunnel head end
  - integration with LSP ping.

  He would like to get the draft accepted as a WG draft.

  Yakov asked what SPs use today for tunnel tracing.

    Ron said that in some case people can use ICMP for MPLS.

  Yakov then asked if we could get a BCP on what people are
  doing.

    Ron asked if he should resubmit his earlier draft on
    this.

      Kireeti said that we do not want to decide that now.

===
Protection and Restoration
---
Dimitri Papadimitriou presented status on the work of the
Protection and Restoration Team - specifically:
1) draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
2) draft-ietf-ccamp-gmpls-recovery-functional-01.txt
3) draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
4) draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt

  He gave estimates on the timing for each of the above
  drafts (estimated completion dates).

  He outlined the changes to the e2e signaling ID (draft 4,
  above).

  He encouraged the WG to really read the documents and
  comment.

  Kireeti polled for consensus on the following:

    a) Analysis - last call? Some support, no objection
    b) Functional - last call? Some support, no objection
    c) Terminology - last call? Some support, no objection
    d) e2e Signaling - WG document? Some support, no object

  People at the microphone were asked to take their
  questions to the list.

---
Lou Berger presented an overview of work on Segment
Recovery - draft-berger-ccamp-gmpls-segment-recovery-00.txt

  He also talked about what still needs to be done (next
  steps), including more usage scenarios, more explanatory
  text and see if the WG will adopt this work.

  Arthi Ayyangar asked if the association object is required
  even if we are only doing segment recovery (as opposed to
  e2e).  She had follow up questions that Kireeti asked her
  to take to the list.

  Adrian polled for support of accepting this as a WG draft.
  There was moderate support and no objection.

===
Inter-Area/AS
---
Arthi Ayyangar talked about the status of the merged draft
on Inter-area/AS signaling -
draft-vasseur-ccamp-inter-area-as-te-00.txt

  The draft currently represents a full merge - work is 
  still required to strip out redundant and unneeded text.

  She said that the authors encourage people to come forward
  with their comments.  She would also like to see if there
  is interest in this work becoming a WG document.

  Vishal Sharma said that the work should apply to general 
  path computation domains and GMPLS LSPs.
  In response to Arthi's question on Slide "Outstanding
  Issues" (about whether detailed description of various 
  path computation algorithms should be part of this 
  document or separate document(s)), he supported the 
  document being split into a framework document, discussing
  signaling, and another document(s), discussing the path 
  computation mechanisms, since the latter do not need to be
  standardized.
  In response to Slide "Outstanding Issues: Size of the 
  document" and for clarity, he supported the splitting of 
  the applicability statement into an independent document.

  Dimitri agreed on the subject of separating the document.
  In addition, he questioned about the relevance of using 
  the LSP_Attributes to signal the signaling method for the
  intra-area/-AS provisioning of the LSP.
  In particular, he proposed to not include protocol 
  procedures within examples/scenarios that makes the
  document difficult to read.

    Arthi asked that Dimitri take his specific comments to
    the list.

  Kireeti said that he agrees that the document needs to be
  split - one as a signaling and another (informational) to
  provide examples for path computation. He also said that
  we need a separate applicability document.

    Vishal Sharma then said that he would be happy to help 
    with these tasks.

---
Vishal Sharma talked about work on Inter-area path
protection
draft-dachille-inter-area-path-protection-00.txt

  He provided a brief overview of how it works, and showed
  how it relates to other work in progress. He also listed
  the next steps.

  He emphasized that this is really a generic mechanism for
  diverse path computation, and protection is one 
  application of it, so the authors would respin with a new
  name and emphasis to reflect this."

  Zafar Ali asked how this would work if there is a failure
  at the time during which the backup path is being setup.

    Vishal replied that the solutions to this were, so far,
    not discussed in the draft, but that there are several 
    options. 

    He then outlined some of the options. E.g. either 
    default in such a case to a sequential computation, and
    use XRO to exclude the link/node where backup path setup
    failed, and retry the backup (and optimize both primary 
    and secondary later using the techniques in the draft).
    Or, set up the primary and the backup again, using the 
    techniques described in the draft.

    Vishal said they would be happy to add some discussion 
    in the document, and welcomed feedback on the list.

  Zafar asked how this work relates to PCS/PCE work.
    
    Vishal replied that it could actually be made use of by
    the PCS/PCE approach, and could be viewed as 
    complementary.

  Kireeti asked that further discussion be taken to the 
  list.

  Vishal said he welcomed further feedback on the document.
 
  Dimitri asked why, knowing that the proposed approach 
  works as expected in the intra-domain case when the 
  number of ABRs (where computation can be executed at each
  stage) does not increase, this approach is so focused on 
  optimization (since it can't be achieved if this
  condition is not met).

    Vishal clarified that the focus of the work is to 
    propose a generic mechanism to facilitate diverse path
    setup by communicating alternate path info, with 
    optimization a desired goal (for reasons explained in
    the document).

    Vishal added that given the network model (where border
    nodes are not assumed to have visibility in areas other
    than their own), the scheme was not trying to be 
    globally optimal.

    Vishal explained that in such cases some selection needs
    to be performed at each stage.

  Kireeti asked that further discussion on this should be
  taken to the list.

  Also, he said that Dimitri had a good point - we need to
  define criteria on which any optimization is based.

  Kireeti concluded by saying that path protection and 
  inter-area are both in the charter, but that this document
  could only be considered for a WG document after there was 
  discussion about the document on the list.

===
Control Pane Resilience, Hello Protocol and Graceful Restart
---
Young Hwa Kim gave a presentation on Requirements for the
Resilience of Control Plane in GMPLS -
draft-kim-ccamp-cpr-reqts-00.txt

  He described the reasons why control plane resilience is
  needed.

  Zafar asked how control plane resilience is different from
  anything else in IP.

  Steve Trowbridge said that their is also some work in this
  area in the ITU and he would try to get this in as a
  liaison as soon as possible.

  Kireeti said that this is an important discussion and
  there are a lot of things to do. Specific topics should be
  raised on the list when appropriate.

---
Lou Berger went over Extensions to GMPLS RSVP Graceful
Restart
draft-aruns-ccamp-rsvp-restart-ext-00

  He emphasized that egress restart is already covered in
  RFC3473 and this work has no effect on that functionality.
  He gave a brief overview and listed open issues.

  Next steps include merging with other restart drafts and
  seeing if this work can become a WG draft.

  Arthi said that she feels that the document focuses too
  much on the ERO. She feels that the draft should address
  other issues and concerns with the mechanism.

    Lou asked if she would like to contribute text.

  The chairs then asked for other discussion to go to the
  list.

---
Zafar Ali talked about Extensions to GMPLS RSVP Graceful
Restart
draft-rahman-ccamp-rsvp-restart-extensions-00.txt

  Kireeti said that he appreciated the honesty of the
  authors in acknowledging other work.

  Nurit Sprecher asked about the relationship to FRR and
  similar issues.

    Adrian agreed that these were important issues and had
    been raised on the list in recent days. He asked the
    authors to make sure that they cover the points in the
    draft.

---
Zafar then covered modifications to Hello procedures
1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
2) draft-ali-ccamp-rsvp-hello-gr-admin-00.txt

  He wants to go forward with draft 1 above.

  Adrian polled and there was some interest and no strong
  objection.

  Kireeti said that this work cannot be informational if
  it has - or proposes - changes to a standard.

  Zafar also wants draft 2 to be a WG document.

  Kireeti said that we need to take this to the list, but
  Zafar also needs to socialize the work he is doing so that
  people may decide whether or not this is work we want to
  do.

===
Everything Else
---
Emmanuel Dotaro gave status of Multi-region protection -
draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt

  He briefly covered changes since previous versions.

  He proposes that we may need to make changes to the
  charter to include all of this work. In particular to
  include in the charter the complete set of GMPLS 
  mechanisms for integrated control planes, and not only
  multi-layer recovery (as it stands today).

  Adrian suggested that the authors need to get more people
  involved in this important work and revisit this later.

---
Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs
draft-vasseur-ccamp-isis-te-caps-00.txt

  He would like to have this accepted as a WG document.

  Adrian asked to hold off on this until after the OSPF talk
  below.

---
Seisho Yasukawa
draft-vasseur-ccamp-ospf-te-caps-00.txt

  He would like to have this accepted as a WG document.

  Regarding both drafts, Kireeti is not sure that this work
  belongs in this WG. The decision is driven by the
  generality of its applicability. If we do take it on, their
  needs to be a functional specification (independent of IGP)
  as well.

  He asked that further discussion be taken to the list.

---
The Following presentations were postponed as we ran out
of time. Adrian made a couple of brief comments as follows:
  ---
  Zafar Ali - Explicit Resource Control and Tracking
  draft-zamfir-explicit-resource-control-bundle-03.txt

    This work concerns identification of component links in
    EROs and RROs.

    A small group is currently examining other issues
    concerning identification of component links in all
    aspects of GMPLS. A draft is expected soon. Please mail
    Adrian or the list, if you want to be involved in this
    work.

  ---
  Lou Berger - Alarm Reporting
  draft-berger-ccamp-gmpls-alarm-spec-01.txt

    This draft is stable and complete in the view of the
    authors.

    A quick poll showed some support for this being a WG
    document, and no opposition. This will be taken to the
    list.



Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 18:48:35 +0000
Date: Sat, 13 Mar 2004 10:46:55 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
cc: [e-mail]
Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 8 Mar 2004, Ash, Gerald R (Jerry), ALABS wrote:

> Yes, should be brought under the wing of the WG.
>
> Jerry
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Saturday, March 06, 2004 7:21 AM
> To: [e-mail]
> Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>
> In Seoul we ran out of time before we could discuss this draft.
>
> However, the draft is pretty stable, and it is the opinion of the authors that this should be brought under the wing of the WG.
>
> Can you please send your opinions to the list or to the chairs direct.
>
> Silence (as usual) will be interpreted as you saying nothing.
>
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt

Thanks Jerry et al for your comments.

While there wasn't ringing approval for moving this forward, there was
reasonable interest.  Lou, please republish as a WG doc.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 18:17:43 +0000
Date: Sat, 13 Mar 2004 10:15:05 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: Draft minutes from Seoul
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Thanks, Vishal and Dimitri for the clarifications on the minutes.
We'll wait a bit to see if there are other comments, then incorporate
them into the final minutes.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 14:44:02 +0000
Message-ID: <[e-mail]>
Date: Sat, 13 Mar 2004 15:43:05 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Draft minutes from Seoul
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

adrian, some hints inline:

Adrian Farrel wrote:
> Very many thanks to Eric Gray for doing the hard work and for
> supplying an excellent set of minutes.
> 
> There are a couple of gaps. Please let me know what you said (or want
> you want recorded :-).
> 
> Comments as soon as possible, please.
> 
> Thanks, Adrian
> 
> Common Control and Measurement Plane WG (ccamp)
> 
> THURSDAY, March 4 at 0900-1130 ===============================
> 
> CHAIRS: Kireeti Kompella <[e-mail]> Adrian Farrel
> <[e-mail]>
> 
> AGENDA:
> 
> === Group Admin --- Chairs Admin - Nothing much to say (in English
> anyway) - In Korean, however, the following was said: "Jigeumbuteo
> CCAMP meetingeul sijakhagesumnida".
> 
> Agenda bash (5 mins) - No changes Status of WG drafts and milestones 
> Adrian's slides showed that we do have some draft congestion in the
> WG. - RFC editor queue - status of IANA for SONET/SDH Kireeti talked
> about an issue with SONET/SDH IANA assignments - need a means to get
> early assignments. There is WIP to accomplish this, and it is moving 
> ahead. - future allocation of "experimental" values
> 
> Liaisons --- Marco Carugi talked about work in SG-13 (SG13 liaison). 
> He covered topics, new study areas, timescales, objectives and
> status. They are also looking for people interested in doing work in
> these areas.
> 
> An L1 VPN questionnaire and framework draft were attached to the
> liaison.
> 
> Tomonori Takeda talked about the technical issues and details of the
> work.
> 
> Monique Morrow had a couple of clarification for Marco - When will
> the consent portion of the work be done in the ITU?
> 
> Marco said that the different pieces of work were progressing at
> different speeds. Some material is already embodied in
> recommendations. The next SG13 meetings are in June and September.
> 
> Dimitri Papadimitriou asked if the liaison could include a
> summarization of the purpose and intent of the liaison.

if the draft (l1vpn framework) provided in the liaison could
include a summarization (as conclusion) on the expected GMPLS
work for the CCAMP WG, this would clarify the intent of the
liaison in term of expected effort for the CCAMP WG

> Kireeti answered. If CCAMP's rechartering this month results in the
> addition of L1VPNs to the charter, then a Liaison response from the
> IETF will include this information, plus a request for a cooperative
> effort, preferably along the lines of the ASON routing work, wherein
> the ITU-T defines the requirements and the IETF does the protocol
> extensions.
> 
> Alex Zinin said that we will have to make a decision at some point as
> to whether or not we want to do this work here.
> 
> Someone from NTT raised a point that was not captured in the minutes.
> 
> 
> Deborah Brungard said that there is work and some synergy and that we
> should continue to work on this.
> 
> Monique Morrow agrees that we should work on that.
> 
> Marco added some comments that were not captured in the minutes.
> 
> Malcolm Betts said he also feels that we should do this.
> 
> Adrian took a quick poll and it seems as if nobody is against doing
> this work.
> 
> Kireeti reminded people to continue this discussion on the list.
> 
> --- Lyndon Ong talked about work in SG-15 (3 liaisons).
> 
> Liaisons were on ASON routing requirements, response to comments on
> Q14 for G.7713.2 and comments on the CCAMP ASON signaling
> requirements draft.
> 
> Lyndon spent much of the time on the details of response to comments
> on Q14. It seems that some of the differences in architectural models
> revolve around "end-to-end" and "call segment" operating models.
> 
> Kireeti asked for the reply by date.
> 
> Lyndon did not have that.
> 
> Steve Trowbridge said that the meeting starts on April 19th
> 
> Dimitri had a question on the deadline. Isn't there a similar
> deadline on (G.7713).

-> There is a deadline on G.7713 (April 2004), isn't there a
    similar deadline on G.7713.2 (since this is the document
    to which convergence is expected) ?

> Lyndon said that he had not gone into that. He gave a reason, but
> this was not captured in the minutes.
> 
> Deborah said that the liaison for 7713.2 does not say any thing about
> convergence.
> 
> Lyndon said that they are still looking for a "meeting of the minds".
> 
> 
> Deborah said that there is an issue with G.7713.2 because of
> compatibility.
> 
> Lyndon said that yes there has been a lot of discussion of
> compatibility questions and requirements.
> 
> Kireeti said that we should not discuss this here.
> 
> Steve Trowbridge added some comments that were not captured in the
> minutes.
> 
> Kireeti asked the WG to take this discussion to the list and try to
> keep that discussion on a productive basis.
> 
> Adrian said that he wanted to recognize the efforts of the ITU folks
> in this work.
> 
> === ASON Requirements and Solutions --- Dimitri Papadimitriou
> presented status of ASON Signaling Requirements
> (draft-ietf-ccamp-gmpls-ason-reqts-05.txt.
> 
> The requirements were driven by last years liaison from the ITU.

-> also the discussion slides proposed to defer to the GROW
    WG (cfr. RIFT WG item) concerning the (external) non-IP
    reachability issue since much broader than just CCAMP
    GMPLS/ASON context

> After this meeting, Dimitri would like to re-spin the draft and have
> a two week last call.
> 
> Lyndon said he wants to capture the requirement - whether or not we
> will work on it here.

-> Lyndon said he want to capture the requirement on "non-IP
    reachability" - whether or not we will work on it here

> Kireeti said that we first need to understand importance of this and
> then we can look to the ADs for guidance on handling this.  He also
> said that we should take some time to work out what we want to say to
> the ITU when we include the current draft.
> 
> --- Dimitri Papadimitriou gave status ASON Signaling Solutions 
> (draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt) status.
> 
> He would like feedback on whether or not the current draft deals
> correctly with the session attribute.

-> He would like feedback on whether or not the current draft
    deals correctly with the session attribute object that
    encodes the long call_id (alternatives were also proposed)

> His objective at this point is to try to have last call on this

-> His objective at this point is to try to have a document
    ready for last call for the next IETF 60 meeting in San
    Diego

> Lyndon suggested that we might remove the comparison with G.7713 from
> the draft.
> 
> Adrian asked if this meant that the interworking draft for RFC3473/4
> interworking was now obsolete.
> 
> Lyndon said maybe, if interworking is removed as a requirement.
> 
> --- Lou Berger talked about Egress Control - 
> draft-berger-gmpls-egress-control-01.txt -
> 
> Original egress label control became explicit label control. This
> draft attempts to capture the original intent.
> 
> He wants to know if the WG feels that this is ready to be a BCP and
> what the chairs think the next steps should be.
> 
> Lou re-iterated that the purpose and scope of the draft is for
> clarification. He does not see any value in adding to this intent or
> combining it with other work.
> 
> Adrian then took a poll and nobody objected to take this on as a WG
> item (more than a third were in favor).
> 
> --- Lyndon Ong went over status on ASON Routing Requirements - 
> draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
> 
> He includes in his presentation his conclusions as to what there is
> agreement that stuff is missing and areas in which there is still
> contention.

-> replace "his conclusions" by "DT conclusions" and "as to what
    there is agreement on what's missing from GMPLS (delta) and
    what are the areas on which there is no agreement on what's
    missing from GMPLS)"

> Kireeti asked Lyndon to more formally open this discussion on the
> mailing list.
> 
> Vishal Sharma said that he supports this.
> 
> Kireeti said he would like - after checking with the AD - that we
> should take this work to the IS-IS and OSPF WGs.
> 
> Alex Zinin said this is a good idea.
> 
> === Tunnel Trace --- Ron Bonica presented status on
> draft-bonica-tunproto-05.txt
> 
> The solution is very similar to Trace-Route but does not require that
> each node in a tunnel supports TTL decrement.
> 
> He gave a few examples as to how the idea in the draft will work in a
> few scenarios.
> 
> There are a couple of outstanding issues: - trace requires a route to
> tunnel head end - integration with LSP ping.
> 
> He would like to get the draft accepted as a WG draft.
> 
> Yakov asked what SPs use today for tunnel tracing.
> 
> Ron said that in some case people can use ICMP for MPLS.
> 
> Yakov then asked if we could get a BCP on what people are doing.
> 
> Ron asked if he should resubmit his earlier draft on this.
> 
> Kireeti said that we do not want to decide that now.
> 
> === Protection and Restoration --- Dimitri Papadimitriou presented
> status on the work of the Protection and Restoration Team -
> specifically: 1) draft-ietf-ccamp-gmpls-recovery-analysis-02.txt 2)
> draft-ietf-ccamp-gmpls-recovery-functional-01.txt 3)
> draft-ietf-ccamp-gmpls-recovery-terminology-03.txt 4)
> draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt
> 
> He gave estimates on the timing for each of the above drafts
> (estimated completion dates).
> 
> He outlined the changes to the e2e signaling ID (draft 4, above).
> 
> He encouraged the WG to really read the documents and comment.
> 
> Kireeti polled for consensus on the following:
> 
> a) Analysis - last call? Some support, no objection b) Functional -
> last call? Some support, no objection c) Terminology - last call?
> Some support, no objection d) e2e Signaling - WG document? Some
> support, no object
> 
> People at the microphone were asked to take their questions to the
> list.
> 
> --- Lou Berger presented an overview of work on Segment Recovery -
> draft-berger-ccamp-gmpls-segment-recovery-00.txt
> 
> He also talked about what still needs to be done (next steps),
> including more usage scenarios, more explanatory text and see if the
> WG will adopt this work.
> 
> Arthi Ayyangar asked if the association object is required even if we
> are only doing segment recovery (as opposed to e2e).  She had follow
> up questions that Kireeti asked her to take to the list.
> 
> Adrian polled for support of accepting this as a WG draft. There was
> moderate support and no objection.
> 
> === Inter-Area/AS --- Arthi Ayyangar talked about the status of the
> merged draft on Inter-area/AS signaling - 
> draft-vasseur-ccamp-inter-area-as-te-00.txt
> 
> The draft currently represents a full merge - work is still required
> to strip out redundant and unneeded text.
> 
> She said that the authors encourage people to come forward with their
> comments.  She would also like to see if there is interest in this
> work becoming a WG document.
> 
> Vishal Sharma said that he supports separating some of the path
> computation mechanisms from the rest of the document and removal of
> applicability text.
> 
> Dimitri agreed on the subject of separating the document

-> in addition, he questioned about the relevance of using the
    LSP_Attributes to signal the signaling method for the intra-
    area/-AS provisioning of the LSP

> and made some suggestions for clarification of the draft.

-> in particular, he proposed to not include protocol procedures
    within examples/scenarios that makes the document difficult
    to read

> Arthi asked that Dimitri take his specific comments to the list.
> 
> Kireeti said that he agrees that the document needs to be split - one
> as a signaling and another (informational) to provide examples for
> path computation. He also said that we need a separate applicability
> document.
> 
> --- Vishal Sharma talked about work on Inter-area path protection 
> draft-dachille-inter-area-path-protection-00.txt
> 
> He provided a brief overview of how it works, and showed how it
> relates to other work in progress. He also listed the next steps.
> 
> Zafar Ali asked how this would work if there is a failure at the time
> during which the backup path is being setup.
> 
> Zafar and Vishal chatted for a while and then Kireeti asked them to
> take the discussion to the list.
> 
> Dimitri asked why the document is so focused on optimization.

-> knowing that the proposed approach works as expected in the
    intra-domain case when the number of ABRs (where computation
    can be executed at each stage) does not increase why this
    approach is so focused on optimization (since it can't be
    achieved if this condition is not met)

-> part of the Vishal's response was that in such case some
    selection needs to be performed at each stage

[note: that the issue is related to the fact that when the number
of ABRs is increasing, selection performed at the N-1 stage is
influecing the computation at the N (current) stage]

> Kireeti asked that further discussion on this should be taken to the
> list.
> 
> Also, he said that Dimitri had a good point - we need to define
> criteria on which any optimization is based.
> 
> === Control Pane Resilience, Hello Protocol and Graceful Restart --- 
> Young Hwa Kim gave a presentation on Requirements for the Resilience
> of Control Plane in GMPLS - draft-kim-ccamp-cpr-reqts-00.txt
> 
> He described the reasons why control plane resilience is needed.
> 
> Zafar asked how control plane resilience is different from anything
> else in IP.
> 
> Steve Trowbridge said that their is also some work in this area in
> the ITU and he would try to get this in as a liaison as soon as
> possible.
> 
> Kireeti said that this is an important discussion and there are a lot
> of things to do. Specific topics should be raised on the list when
> appropriate.
> 
> --- Lou Berger went over Extensions to GMPLS RSVP Graceful Restart 
> draft-aruns-ccamp-rsvp-restart-ext-00
> 
> He emphasized that egress restart is already covered in RFC3473 and
> this work has no effect on that functionality. He gave a brief
> overview and listed open issues.
> 
> Next steps include merging with other restart drafts and seeing if
> this work can become a WG draft.
> 
> Arthi said that she feels that the document focuses too much on the
> ERO. She feels that the draft should address other issues and
> concerns with the mechanism.
> 
> Lou asked if she would like to contribute text.
> 
> The chairs then asked for other discussion to go to the list.
> 
> --- Zafar Ali talked about Extensions to GMPLS RSVP Graceful Restart 
> draft-rahman-ccamp-rsvp-restart-extensions-00.txt
> 
> Kireeti said that he appreciated the honesty of the authors in
> acknowledging other work.
> 
> Nurit Sprecher asked about the relationship to FRR and similar
> issues.
> 
> Adrian agreed that these were important issues and had been raised on
> the list in recent days. He asked the authors to make sure that they
> cover the points in the draft.
> 
> --- Zafar then covered modifications to Hello procedures 1)
> draft-ali-ccamp-rsvp-node-id-based-hello-00.txt 2)
> draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
> 
> He wants to go forward with draft 1 above.
> 
> Adrian polled and there was some interest and no strong objection.
> 
> Kireeti said that this work cannot be informational if it has - or
> proposes - changes to a standard.
> 
> Zafar also wants draft 2 to be a WG document.
> 
> Kireeti said that we need to take this to the list, but Zafar also
> needs to socialize the work he is doing so that people may decide
> whether or not this is work we want to do.
> 
> === Everything Else --- Emmanuel Dotaro gave status of Multi-region
> protection - draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt
> 
> He briefly covered changes since previous versions.
> 
> He proposes that we may need to make changes to the charter to
> include all of this work.

-> Proposal was made to include in the charter the complete
    set of GMPLS mechanisms for integrated control planes and
    not only multi-layer recovery (as it stands today)

> Adrian suggested that the authors need to get more people involved in
> this important work and revisit this later.
> 
> --- Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs 
> draft-vasseur-ccamp-isis-te-caps-00.txt
> 
> He would like to have this accepted as a WG document.
> 
> Adrian asked to hold off on this until after the OSPF talk below.
> 
> --- Seisho Yasukawa draft-vasseur-ccamp-ospf-te-caps-00.txt
> 
> He would like to have this accepted as a WG document.
> 
> Regarding both drafts, Kireeti is not sure that this work belongs in
> this WG. The decision is driven by the generality of its
> applicability. If we do take it on, their needs to be a functional
> specification (independent of IGP) as well.
> 
> He asked that further discussion be taken to the list.
> 
> --- The Following presentations were postponed as we ran out of time.
> Adrian made a couple of brief comments as follows: --- Zafar Ali -
> Explicit Resource Control and Tracking 
> draft-zamfir-explicit-resource-control-bundle-03.txt
> 
> This work concerns identification of component links in EROs and
> RROs.
> 
> A small group is currently examining other issues concerning
> identification of component links in all aspects of GMPLS. A draft is
> expected soon. Please mail Adrian or the list, if you want to be
> involved in this work.
> 
> --- Lou Berger - Alarm Reporting 
> draft-berger-ccamp-gmpls-alarm-spec-01.txt
> 
> This draft is stable and complete in the view of the authors.
> 
> A quick poll showed some support for this being a WG document, and no
> opposition. This will be taken to the list.
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 11:30:35 +0000
Message-ID: <081401c408ee$67e81c40$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Layer One VPNs
Date: Sat, 13 Mar 2004 11:28:53 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Although Layer One VPNs do not currently have a home in any IETF working group, we were
the recipients of a liaison from ITU-T SG13 informing us about the work they are doing on
this topic and pointing us at
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt

If anyone has comments on this work they can send them to this mailing list (until another
home is found in the IETF) or to the authors direct.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 10:43:41 +0000
Message-ID: <07fd01c408e7$b406d230$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Jonathan Lang" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Subject: draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt to working group status
Date: Sat, 13 Mar 2004 10:40:35 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

We have heard consensus for this draft to become a working group document.

Authors, please re-submit as draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt and with
no other changes EXCEPT
- dates
- new IPR boilerplate (RFC3667, 8 and 9)

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 10:43:25 +0000
Message-ID: <07fb01c408e7$b1da7c50$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: draft-berger-gmpls-egress-control-01.txt to Working Group status
Date: Sat, 13 Mar 2004 10:40:16 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

We have heard consensus for this draft to become a working group document.

Authors, please re-submit as draft-ietf-ccamp-gmpls-egress-control-00.txt and with no
other changes EXCEPT
- dates
- new IPR boilerplate (RFC3667, 8 and 9)

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 10:43:09 +0000
Message-ID: <07fc01c408e7$b2f3b480$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ron Bonica" <[e-mail]>, "Eric Rosen" <[e-mail]>, "Dave Meyer" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "Rohit Dube" <[e-mail]>
Subject: draft-bonica-tunproto-05.txt to working group status
Date: Sat, 13 Mar 2004 10:40:25 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

We have heard consensus for this draft to become a working group document.

Authors, please re-submit as draft-ietf-ccamp-tunproto-00.txt and with no other changes
EXCEPT
- dates
- new IPR boilerplate (RFC3667, 8 and 9)

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 10:42:53 +0000
Message-ID: <07fe01c408e7$b49f8fc0$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: draft-berger-ccamp-gmpls-segment-recovery-00.txt
Date: Sat, 13 Mar 2004 10:40:38 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I have heard rough consensus on this draft becoming a working group draft, but in view of
a few people who have expressed concern, I would like to leave this open for a few more
days.

Please, if you have concrete issues with this draft, raise them on the list as soon as
possible.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 06:35:11 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Kireeti Kompella" <[e-mail]>
Subject: RE: Draft minutes from Seoul
Date: Fri, 12 Mar 2004 22:31:16 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Please see text in-line for appropriate additions/enhancements
relative to my comments during the meeting and comments
on my presentation of draft-dachille-inter-area-path-protection.

Thanks,
-Vishal

PS: Kireeti, please see if I captured your concluding comment
on my presentation accurately (at the very end of this email).

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Friday, March 12, 2004 6:30 AM
> To: [e-mail]
> Subject: Draft minutes from Seoul
> 
> 
> Very many thanks to Eric Gray for doing the hard work and
> for supplying an excellent set of minutes.
> 
> There are a couple of gaps. Please let me know what you said (or 
> want you want recorded
> :-).
> 
> Comments as soon as possible, please.
> 
> Thanks,
> Adrian
> 
> Common Control and Measurement Plane WG (ccamp)
> 
> THURSDAY, March 4 at 0900-1130
> ===============================
> 
> CHAIRS: Kireeti Kompella <[e-mail]>
>         Adrian Farrel <[e-mail]>
> 
> AGENDA:
> 
> ===
> Group Admin
> ---
> Chairs
>   Admin - Nothing much to say (in English anyway)
>         - In Korean, however, the following was said:
>           "Jigeumbuteo CCAMP meetingeul sijakhagesumnida".
> 

<<snip>>

> ---
> Lyndon Ong went over status on ASON Routing Requirements -
> draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
> 
>   He includes in his presentation his conclusions as to what
>   there is agreement that stuff is missing and areas in which
>   there is still contention.
> 
>   Kireeti asked Lyndon to more formally open this discussion
>   on the mailing list.
> 
>   Vishal Sharma said that he supports this.

I think the sequence went something like this ...

Vishal Sharma asked if the three issues (slide 6) were already 
opened up for discussion on the list, or would they be
formally opened up with the DT members initiating a discussion
on these on the list?

To this Lyndon Ong replied that a discussion had not been formally
opened up yet (although people were free to discuss/comment).

At that point, Kireeti asked Lyndon to more formally open this
discussion on the ML.

Vishal Sharma then said that he supports this.

>   Kireeti said he would like - after checking with the AD -
>   that we should take this work to the IS-IS and OSPF WGs.
> 
>     Alex Zinin said this is a good idea.
> 
<snip>

> ===
> Inter-Area/AS
> ---
> Arthi Ayyangar talked about the status of the merged draft
> on Inter-area/AS signaling -
> draft-vasseur-ccamp-inter-area-as-te-00.txt
> 
>   The draft currently represents a full merge - work is still
>   required to strip out redundant and unneeded text.
> 
>   She said that the authors encourage people to come forward
>   with their comments.  She would also like to see if there
>   is interest in this work becoming a WG document.
> 
>   Vishal Sharma said that he supports separating some of the
>   path computation mechanisms from the rest of the document
>   and removal of applicability text.

Vishal Sharma said that 
- The work should apply to general path computation domains and GMPLS LSPs
- In response to Aarthi's 
question on Slide "Outstanding Issues" (about whether detailed description 
of various path computation algorithms should be part of this document 
or separate document(s)), he supported
the document being split into a framework document, discussing
signaling, and another document(s), discussing the path computation
mechanisms, since the latter do not need to be standardized.

- In response to Slide "Outstanding Issues:
Size of the document" and for clarity, he supported the splitting 
of the applicability statement into an independent document.


>   Dimitri agreed on the subject of separating the document
>   and made some suggestions for clarification of the draft.
> 
>     Arthi asked that Dimitri take his specific comments to
>     the list.
> 
>   Kireeti said that he agrees that the document needs to be
>   split - one as a signaling and another (informational) to
>   provide examples for path computation. He also said that
>   we need a separate applicability document.

Vishal Sharma then said that he would be happy to help with
the above tasks.

> ---
> Vishal Sharma talked about work on Inter-area path
> protection
> draft-dachille-inter-area-path-protection-00.txt
> 
>   He provided a brief overview of how it works, and showed
>   how it relates to other work in progress. He also listed
>   the next steps.

I suggest that it also be noted here that "he emphasized that 
this is really a generic mechanism for diverse path computation, and
protection is one application of it, so the authors would respin
with a new name and emphasis to reflect this."

>   Zafar Ali asked how this would work if there is a failure
>   at the time during which the backup path is being setup.
> 
>     Zafar and Vishal chatted for a while and then Kireeti
>     asked them to take the discussion to the list.

More accurately ...

Vishal replied that the solutions to this were, so far, not discussed 
in the draft, but that there are several options. 

He then outlined some of the options. E.g. either default in such a
case to a sequential computation, and use XRO to exclude the link/node
where backup path setup failed, and retry the backup (and optimize
both primary and secondary later using the techniques in the draft).
Or, set up the primary and the backup again, using the techniques
described in the draft.

Vishal said they would be happy to add some discussion in the
document, and welcomed feedback on the list.

I believe Zafar also asked how this work relates to PCS/PCE
work, and I replied that it could actually be made use of
by the PCS/PCE approach, and could be viewed as complementary.

Kireeti then asked us to take the discussion to the list, and 
I welcomed further feedback on the document.
 
>   Dimitri asked why the document is so focused on
>   optimization.

Vishal clarified that as he had mentioned at the outset, the
focus of the work is to propose a generic mechanism to facilitate
diverse path setup by communicating alternate path info., with
optimization a desired goal (for reasons explained in the document).

Vishal added that given the network model (where border nodes
are not assumed to have visibility in areas other than their own), the 
scheme was not trying to be globally optimal.

At this point, Kireeti asked that further discussion on
this should be taken to the list.
 
>   Kireeti asked that further discussion on this should be
>   taken to the list.
> 
>   Also, he said that Dimitri had a good point - we need to
>   define criteria on which any optimization is based.

It should also be noted in the minutes that ...

Kireeti concluded by saying that this work was in the charter, but the 
document would be considered for a WG document only after there was 
discussion about the document on the list.

 



Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 03:28:41 +0000
From: "Vishal Sharma" <[e-mail]>
To: "zafar ali" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Cc: <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, "'Danny Prairie'" <[e-mail]>
Subject: RE: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
Date: Fri, 12 Mar 2004 19:25:29 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Zafar at al,

After having seen the discussion during CCAMP and having re-read
the draft, I support this action for the draft.

The draft provides a rather useful clarification, which would be good
to record.

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of zafar ali
> Sent: Thursday, March 11, 2004 11:14 PM
> To: 'Kireeti Kompella'
> Cc: [e-mail]; 'Adrian Farrel';
> [e-mail]; 'Reshad Rahman'; 'Danny Prairie'
> Subject: RE: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
> 
> 
> Hi Kireeti, Adrian, et al
> 
> This is a follow-up on Kireeti's comment on the above mentioned draft
> during the last CCAMP WG meeting. I looked through the
> http://www.ietf.org/rfc/rfc2026.txt, which states about BCP sub-series: 
> 
> (BCP sub-series) "is a vehicle by which the IETF community can define
> and ratify the community's best current thinking on a statement of
> principle or on what is believed to be the best way to perform some
> operations or IETF process function." RFC2026, Section5, page 16. 
> 
> We think that draft-ali-ccamp-rsvp-node-id-based-hello-00.txt fits this
> definition quite well. It does NOT define any protocol extensions and
> only formalizes use of node-id based RSVP Hello sessions. In the revised
> version we would like to position the draft as a BCP. 
> 
> Comments will be appreciated. 
> 
> Thanks
>  
> Regards... Zafar
> 
> 
> >-----Original Message-----
> >From: [e-mail] 
> >[mailto:[e-mail]] On Behalf Of zafar ali
> >Sent: Friday, February 06, 2004 3:25 PM
> >To: [e-mail]
> >Cc: [e-mail]
> >Subject: RE: comments on 
> >draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
> >
> >
> >Hi Dimitri, 
> >
> >Thanks for your comments and feedback. I have in-lined some 
> >new comments. 
> >
> >As I mentioned in my earlier email that we will take care of 
> >these comments in the next version of the document. 
> >
> >Thanks again for your feedback. 
> >
> >Regards... Zafar
> >
> >>-----Original Message-----
> >>From: [e-mail]
> >>[mailto:[e-mail]] On Behalf Of 
> >>[e-mail]
> >>Sent: Friday, February 06, 2004 11:17 AM
> >>To: zafar ali
> >>Cc: [e-mail]
> >>Subject: Re: comments on 
> >>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
> >>
> >>
> >>hi, some comments on this document that would imho
> >>beneficiate from the community
> >>
> >
> >Thanks, 
> >
> >>>>   Another scenario which introduces the need for node-id
> >>based Hellos
> >>>>   is when nodes support unnumbered TE links. Specifically, 
> >when all 
> >>>>TE
> >>>>   links between neighbor nodes are unnumbered, it is
> >>implied that the
> >>>>   nodes will use node-id based Hellos for detecting node
> >>>>failures. This
> >>>>   draft also clarifies the use of node-id based Hellos 
> >when all or a
> >>>>   sub-set of TE links are unnumbered.
> >>>>
> >>>>DP: the key point is "is the router id used to identify the te link 
> >>>>the same as the one used for the hello's ?"
> >>>  
> >>> Yes, the same router-id/ node-id is used.
> >>
> >>ok, that's what i wanted to know and i would propose to include the 
> >>above sentence in this i-d
> >>
> >
> >Agreed, we will. 
> >
> >>>>   When link level failure detection is performed by some 
> >means other
> >>>>   than RSVP Hellos (e.g., [BFD]), the use of node-id based 
> >Hellos is
> >>>>   also optimal for detection of nodal failures.
> >>>>
> >>>>DP: pin point that this is a particular case, it's not a nodal 
> >>>>failure but a RSVP-TE signaling adjacency failure, RSVP-TE 
> >signaling 
> >>>>controller failure,
> >>> 
> >>> Agreed! this is more precise statement.
> >>
> >>ok, thanks
> >>
> >>>>note that if this session is
> >>>>maintained and is used as the IP channel for all messages then
> >>>>it MAY also be used as "nodal failure"
> >>>>
> >>>>   An implementation may initiate a node-id based Hello 
> >session when 
> >>>>it
> >>>>   starts sharing RSVP states with the neighbor or at an
> >>earlier time.
> >>>>
> >>>>DP: i don't understand what you mean here
> >>>>
> >>> What we meant here is that an application may not run RSVP Hello
> >>> session all the time. It may initiate one when it has an 
> >application 
> >>> (e.g., when for GR when it start sharing states with the neighbor.
> >>
> >>this is an interesting statement to be considered in the
> >>scope of this document
> >
> >No, these details are implementation specific. The related 
> >para was included in the ID as a reference (to avoid confusion 
> >on how node-id's can be obtained.). Nonetheless, as you would 
> >agree that this is implementation specific detail, and hence 
> >is outside the scope of the ID.  
> >
> >>
> >>>>   Similarly, an implementation may use the IGP topology to 
> >determine
> >>>>   the remote node-id which matches an interface address(es) used in
> >>>>   RSVP signaling. These aspects are considered to be a local
> >>>>   implementation decision.
> >>>>
> >>>>DP: how is this possible since you're using the router_id being the 
> >>>>router_address advertized as top level te link 1 in ospf_te
> >>>>
> >>>  
> >>> In Inter-area and inter-AS case, this information is assumed to come
> >>> via configuration. Is this what you meant here?
> >>
> >>the above sentence introduces an issue once the interface
> >>is in failure state, i would provide more details here wrt
> >>to real expectations behind the above paragraph either it
> >>is implementation specific w/o impact on neighbors or it
> >>has and then would suggest some details on the last part.
> >>
> >
> >This is also an implementation specific detail.  
> >
> >>>>   When a node receives a Hello packet where the destination IP 
> >>>>address
> >>>>   is its local node-id as advertised in the IGP-TE
> >>topology, the node
> >>>>   MUST use its node-id in replying to the Hello message. In other
> >>>>   words, nodes must ensure that the node-ids used in RSVP Hello
> >>>>   messages are those derived/contained in the IGP-TE topology.
> >>>>   Furthermore, a node can only run one node-id based RSVP
> >>>>Hello session
> >>>>   with its neighbor.
> >>>>
> >>>>DP: well here in fact you have a real issue because, a may have 
> >>>>several node_id's on a node, so what you want to say is "one per 
> >>>>node_id pair"
> >>> 
> >>> Yes, in the cases when router is participating multiple topologies
> >>> (OSPF & ISIS). But AFAIK router can only advertsie ONLY one 
> >>address in
> >>> a given IGP instance.
> >>> 
> >>> We need to make statement clear for multiple IGP instances case. Is
> >>> this is what you meant?
> >>
> >>exactly
> >
> >This is a good point. New text will be updated based on your comment. 
> >
> >>
> >>>>   If all interfaces between a pair of nodes are unnumbered, the 
> >>>>optimal
> >>>>   way to use RSVP to detect nodal failure is to run node-id based
> >>>>   Hellos. Similarly, when link level failure detection is
> >>>>performed by
> >>>>   some means other than RSVP Hellos, use of node-id based Hellos is
> >>>>   also optimal in detecting nodal failures. Therefore, if all
> >>>>   interfaces between a pair of nodes are unnumbered or when 
> >>>>link level
> >>>>   failure detection is performed by some means other than 
> >>>>RSVP Hellos,
> >>>>   a node MUST run node-id based Hellos for node failure detection.
> >>>>
> >>>>DP: this is not true, i can run LMP, but a MUST for the signaling 
> >>>>adj. maintenance
> >>>>
> >>>  
> >>> Yes, we can clarify it in the next version.
> >>
> >>thanks,
> >>--
> >>Papadimitriou Dimitri
> >>E-mail : [e-mail]
> >>E-mail : [e-mail]
> >>Webpage: http://psg.com/~dpapadimitriou/
> >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >>Phone  : [phone]
> >>
> >>
> >
> >=====================================================================
> >Zafar Ali, Ph. D. 				  100 South Main St.
> >#200,
> >Technical Leader, 				  Ann Arbor, MI 48104,
> >USA.
> >Cisco Systems.					  [phone].
> >=====================================================================
> >
> >
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 13 Mar 2004 01:56:38 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Kireeti Kompella" <[e-mail]>
Subject: RE: Draft minutes from Seoul: Need enhancements
Date: Fri, 12 Mar 2004 17:53:15 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Just want to let you know that there are gaps in 
the minutes, with respect to the comments I made on 
various other drafts, and what was said in response to queries 
on draft-achille-inter-area-protection, which I had presented.

I will be sending the more accurate text to help complete
the minutes.

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Friday, March 12, 2004 6:30 AM
> To: [e-mail]
> Subject: Draft minutes from Seoul
> 
> 
> Very many thanks to Eric Gray for doing the hard work and
> for supplying an excellent set of minutes.
> 
> There are a couple of gaps. Please let me know what you said (or 
> want you want recorded
> :-).
> 
> Comments as soon as possible, please.
> 
> Thanks,
> Adrian
> 
> Common Control and Measurement Plane WG (ccamp)
> 
> THURSDAY, March 4 at 0900-1130
> ===============================
> 
> CHAIRS: Kireeti Kompella <[e-mail]>
>         Adrian Farrel <[e-mail]>
> 
> AGENDA:
> 
> ===
> Group Admin
> ---
> Chairs
>   Admin - Nothing much to say (in English anyway)
>         - In Korean, however, the following was said:
>           "Jigeumbuteo CCAMP meetingeul sijakhagesumnida".
> 
>   Agenda bash (5 mins) - No changes
>   Status of WG drafts and milestones
>     Adrian's slides showed that we do have some draft
>     congestion in the WG.
>     - RFC editor queue
>     - status of IANA for SONET/SDH
>       Kireeti talked about an issue with SONET/SDH IANA
>       assignments
>     - need a means to get early assignments.
>       There is WIP to accomplish this, and it is moving
>       ahead.
>     - future allocation of "experimental" values
> 
> Liaisons
> ---
> Marco Carugi talked about work in SG-13 (SG13 liaison).
>   He covered topics, new study areas, timescales, objectives
>   and status. They are also looking for people interested in
>   doing work in these areas.
> 
>   An L1 VPN questionnaire and framework draft were attached
>   to the liaison.
> 
>   Tomonori Takeda talked about the technical issues and
>   details of the work.
> 
>   Monique Morrow had a couple of clarification for Marco -
>   When will the consent portion of the work be done in the
>   ITU?
> 
>     Marco said that the different pieces of work were
>     progressing at different speeds. Some material is
>     already embodied in recommendations. The next SG13
>     meetings are in June and September.
> 
>   Dimitri Papadimitriou asked if the liaison could include
>   a summarization of the purpose and intent of the liaison.
> 
>     Kireeti answered. If CCAMP's rechartering this month
>     results in the addition of L1VPNs to the charter, then
>     a Liaison response from the IETF will include this
>     information, plus a request for a cooperative effort,
>     preferably along the lines of the ASON routing work,
>     wherein the ITU-T defines the requirements and the IETF
>     does the protocol extensions.
> 
>   Alex Zinin said that we will have to make a decision at
>   some point as to whether or not we want to do this work
>   here.
> 
>   Someone from NTT raised a point that was not captured in
>   the minutes.
> 
>   Deborah Brungard said that there is work and some synergy
>   and that we should continue to work on this.
> 
>     Monique Morrow agrees that we should work on that.
> 
>     Marco added some comments that were not captured in the
>     minutes.
> 
>     Malcolm Betts said he also feels that we should do this.
> 
>   Adrian took a quick poll and it seems as if nobody is
>   against doing this work.
> 
>   Kireeti reminded people to continue this discussion on
>   the list.
> 
> ---
> Lyndon Ong talked about work in SG-15 (3 liaisons).
> 
>   Liaisons were on ASON routing requirements, response to
>   comments on Q14 for G.7713.2 and comments on the CCAMP
>   ASON signaling requirements draft.
> 
>   Lyndon spent much of the time on the details of response
>   to comments on Q14. It seems that some of the differences
>   in architectural models revolve around "end-to-end" and
>   "call segment" operating models.
> 
>   Kireeti asked for the reply by date.
> 
>     Lyndon did not have that.
> 
>     Steve Trowbridge said that the meeting starts on April
>     19th
> 
>   Dimitri had a question on the deadline. Isn't there a
>   similar deadline on (G.7713).
> 
>     Lyndon said that he had not gone into that. He gave a
>     reason, but this was not captured in the minutes.
> 
>   Deborah said that the liaison for 7713.2 does not say any
>   thing about convergence.
> 
>     Lyndon said that they are still looking for a "meeting
>     of the minds".
> 
>   Deborah said that there is an issue with G.7713.2 because
>   of compatibility.
> 
>     Lyndon said that yes there has been a lot of discussion
>     of compatibility questions and requirements.
> 
>   Kireeti said that we should not discuss this here.
> 
>   Steve Trowbridge added some comments that were not
>   captured in the minutes.
> 
>   Kireeti asked the WG to take this discussion to the list
>   and try to keep that discussion on a productive basis.
> 
>   Adrian said that he wanted to recognize the efforts of
>   the ITU folks in this work.
> 
> ===
> ASON Requirements and Solutions
> ---
> Dimitri Papadimitriou presented status of ASON Signaling
> Requirements (draft-ietf-ccamp-gmpls-ason-reqts-05.txt.
> 
>   The requirements were driven by last years liaison from
>   the ITU.
> 
>   After this meeting, Dimitri would like to re-spin the
>   draft and have a two week last call.
> 
>   Lyndon said he wants to capture the requirement - whether
>   or not we will work on it here.
> 
>   Kireeti said that we first need to understand importance
>   of this and then we can look to the ADs for guidance on
>   handling this.  He also said that we should take some time
>   to work out what we want to say to the ITU when we include
>   the current draft.
> 
> ---
> Dimitri Papadimitriou gave status ASON Signaling Solutions
> (draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt) status.
> 
>   He would like feedback on whether or not the current draft
>   deals correctly with the session attribute.
> 
>   His objective at this point is to try to have last call
>   on this
> 
>   Lyndon suggested that we might remove the comparison with
>   G.7713 from the draft.
> 
>     Adrian asked if this meant that the interworking draft
>     for RFC3473/4 interworking was now obsolete.
> 
>       Lyndon said maybe, if interworking is removed as a
>       requirement.
> 
> ---
> Lou Berger talked about Egress Control -
> draft-berger-gmpls-egress-control-01.txt -
> 
>   Original egress label control became explicit label
>   control. This draft attempts to capture the original
>   intent.
> 
>   He wants to know if the WG feels that this is ready to
>   be a BCP and what the chairs think the next steps should
>   be.
> 
>   Lou re-iterated that the purpose and scope of the draft
>   is for clarification. He does not see any value in adding
>   to this intent or combining it with other work.
> 
>   Adrian then took a poll and nobody objected to take this
>   on as a WG item (more than a third were in favor).
> 
> ---
> Lyndon Ong went over status on ASON Routing Requirements -
> draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
> 
>   He includes in his presentation his conclusions as to what
>   there is agreement that stuff is missing and areas in which
>   there is still contention.
> 
>   Kireeti asked Lyndon to more formally open this discussion
>   on the mailing list.
> 
>   Vishal Sharma said that he supports this.
> 
>   Kireeti said he would like - after checking with the AD -
>   that we should take this work to the IS-IS and OSPF WGs.
> 
>     Alex Zinin said this is a good idea.
> 
> ===
> Tunnel Trace
> ---
> Ron Bonica presented status on draft-bonica-tunproto-05.txt
> 
>   The solution is very similar to Trace-Route but does not
>   require that each node in a tunnel supports TTL decrement.
> 
>   He gave a few examples as to how the idea in the draft
>   will work in a few scenarios.
> 
>   There are a couple of outstanding issues:
>   - trace requires a route to tunnel head end
>   - integration with LSP ping.
> 
>   He would like to get the draft accepted as a WG draft.
> 
>   Yakov asked what SPs use today for tunnel tracing.
> 
>     Ron said that in some case people can use ICMP for MPLS.
> 
>   Yakov then asked if we could get a BCP on what people are
>   doing.
> 
>     Ron asked if he should resubmit his earlier draft on
>     this.
> 
>       Kireeti said that we do not want to decide that now.
> 
> ===
> Protection and Restoration
> ---
> Dimitri Papadimitriou presented status on the work of the
> Protection and Restoration Team - specifically:
> 1) draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
> 2) draft-ietf-ccamp-gmpls-recovery-functional-01.txt
> 3) draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
> 4) draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt
> 
>   He gave estimates on the timing for each of the above
>   drafts (estimated completion dates).
> 
>   He outlined the changes to the e2e signaling ID (draft 4,
>   above).
> 
>   He encouraged the WG to really read the documents and
>   comment.
> 
>   Kireeti polled for consensus on the following:
> 
>     a) Analysis - last call? Some support, no objection
>     b) Functional - last call? Some support, no objection
>     c) Terminology - last call? Some support, no objection
>     d) e2e Signaling - WG document? Some support, no object
> 
>   People at the microphone were asked to take their
>   questions to the list.
> 
> ---
> Lou Berger presented an overview of work on Segment
> Recovery - draft-berger-ccamp-gmpls-segment-recovery-00.txt
> 
>   He also talked about what still needs to be done (next
>   steps), including more usage scenarios, more explanatory
>   text and see if the WG will adopt this work.
> 
>   Arthi Ayyangar asked if the association object is required
>   even if we are only doing segment recovery (as opposed to
>   e2e).  She had follow up questions that Kireeti asked her
>   to take to the list.
> 
>   Adrian polled for support of accepting this as a WG draft.
>   There was moderate support and no objection.
> 
> ===
> Inter-Area/AS
> ---
> Arthi Ayyangar talked about the status of the merged draft
> on Inter-area/AS signaling -
> draft-vasseur-ccamp-inter-area-as-te-00.txt
> 
>   The draft currently represents a full merge - work is still
>   required to strip out redundant and unneeded text.
> 
>   She said that the authors encourage people to come forward
>   with their comments.  She would also like to see if there
>   is interest in this work becoming a WG document.
> 
>   Vishal Sharma said that he supports separating some of the
>   path computation mechanisms from the rest of the document
>   and removal of applicability text.
> 
>   Dimitri agreed on the subject of separating the document
>   and made some suggestions for clarification of the draft.
> 
>     Arthi asked that Dimitri take his specific comments to
>     the list.
> 
>   Kireeti said that he agrees that the document needs to be
>   split - one as a signaling and another (informational) to
>   provide examples for path computation. He also said that
>   we need a separate applicability document.
> 
> ---
> Vishal Sharma talked about work on Inter-area path
> protection
> draft-dachille-inter-area-path-protection-00.txt
> 
>   He provided a brief overview of how it works, and showed
>   how it relates to other work in progress. He also listed
>   the next steps.
> 
>   Zafar Ali asked how this would work if there is a failure
>   at the time during which the backup path is being setup.
> 
>     Zafar and Vishal chatted for a while and then Kireeti
>     asked them to take the discussion to the list.
> 
>   Dimitri asked why the document is so focused on
>   optimization.
> 
>   Kireeti asked that further discussion on this should be
>   taken to the list.
> 
>   Also, he said that Dimitri had a good point - we need to
>   define criteria on which any optimization is based.
> 
> ===
> Control Pane Resilience, Hello Protocol and Graceful Restart
> ---
> Young Hwa Kim gave a presentation on Requirements for the
> Resilience of Control Plane in GMPLS -
> draft-kim-ccamp-cpr-reqts-00.txt
> 
>   He described the reasons why control plane resilience is
>   needed.
> 
>   Zafar asked how control plane resilience is different from
>   anything else in IP.
> 
>   Steve Trowbridge said that their is also some work in this
>   area in the ITU and he would try to get this in as a
>   liaison as soon as possible.
> 
>   Kireeti said that this is an important discussion and
>   there are a lot of things to do. Specific topics should be
>   raised on the list when appropriate.
> 
> ---
> Lou Berger went over Extensions to GMPLS RSVP Graceful
> Restart
> draft-aruns-ccamp-rsvp-restart-ext-00
> 
>   He emphasized that egress restart is already covered in
>   RFC3473 and this work has no effect on that functionality.
>   He gave a brief overview and listed open issues.
> 
>   Next steps include merging with other restart drafts and
>   seeing if this work can become a WG draft.
> 
>   Arthi said that she feels that the document focuses too
>   much on the ERO. She feels that the draft should address
>   other issues and concerns with the mechanism.
> 
>     Lou asked if she would like to contribute text.
> 
>   The chairs then asked for other discussion to go to the
>   list.
> 
> ---
> Zafar Ali talked about Extensions to GMPLS RSVP Graceful
> Restart
> draft-rahman-ccamp-rsvp-restart-extensions-00.txt
> 
>   Kireeti said that he appreciated the honesty of the
>   authors in acknowledging other work.
> 
>   Nurit Sprecher asked about the relationship to FRR and
>   similar issues.
> 
>     Adrian agreed that these were important issues and had
>     been raised on the list in recent days. He asked the
>     authors to make sure that they cover the points in the
>     draft.
> 
> ---
> Zafar then covered modifications to Hello procedures
> 1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
> 2) draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
> 
>   He wants to go forward with draft 1 above.
> 
>   Adrian polled and there was some interest and no strong
>   objection.
> 
>   Kireeti said that this work cannot be informational if
>   it has - or proposes - changes to a standard.
> 
>   Zafar also wants draft 2 to be a WG document.
> 
>   Kireeti said that we need to take this to the list, but
>   Zafar also needs to socialize the work he is doing so that
>   people may decide whether or not this is work we want to
>   do.
> 
> ===
> Everything Else
> ---
> Emmanuel Dotaro gave status of Multi-region protection -
> draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt
> 
>   He briefly covered changes since previous versions.
> 
>   He proposes that we may need to make changes to the
>   charter to include all of this work.
> 
>   Adrian suggested that the authors need to get more people
>   involved in this important work and revisit this later.
> 
> ---
> Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs
> draft-vasseur-ccamp-isis-te-caps-00.txt
> 
>   He would like to have this accepted as a WG document.
> 
>   Adrian asked to hold off on this until after the OSPF talk
>   below.
> 
> ---
> Seisho Yasukawa
> draft-vasseur-ccamp-ospf-te-caps-00.txt
> 
>   He would like to have this accepted as a WG document.
> 
>   Regarding both drafts, Kireeti is not sure that this work
>   belongs in this WG. The decision is driven by the
>   generality of its applicability. If we do take it on, their
>   needs to be a functional specification (independent of IGP)
>   as well.
> 
>   He asked that further discussion be taken to the list.
> 
> ---
> The Following presentations were postponed as we ran out
> of time. Adrian made a couple of brief comments as follows:
>   ---
>   Zafar Ali - Explicit Resource Control and Tracking
>   draft-zamfir-explicit-resource-control-bundle-03.txt
> 
>     This work concerns identification of component links in
>     EROs and RROs.
> 
>     A small group is currently examining other issues
>     concerning identification of component links in all
>     aspects of GMPLS. A draft is expected soon. Please mail
>     Adrian or the list, if you want to be involved in this
>     work.
> 
>   ---
>   Lou Berger - Alarm Reporting
>   draft-berger-ccamp-gmpls-alarm-spec-01.txt
> 
>     This draft is stable and complete in the view of the
>     authors.
> 
>     A quick poll showed some support for this being a WG
>     document, and no opposition. This will be taken to the
>     list.
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 12 Mar 2004 17:08:42 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Adrian Farrel' <[e-mail]>, [e-mail]
Subject: RE: Opinion sought on drafts being adopted by CCAMP
Date: Fri, 12 Mar 2004 09:07:13 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

In view of the discussions, you can remove my
objection to the e2e recovery draft.

The segment recovery draft, although I support
the idea, should get some more time for review,
I think.

Cheers,

Lyndon

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Wednesday, March 10, 2004 9:03 PM
To: Ong, Lyndon; [e-mail]
Subject: Re: Opinion sought on drafts being adopted by CCAMP


Hi Lyndon,

> -- rsvp for e2e recovery - there seemed to be still some concerns
>    at the meeting, so no (not yet)

Since the person that raised the concerns at the meeting has given support to this draft
becoming a WG draft, can we move on?

> -- segment recovery - no (not yet)

Would you care to say why?

Thanks,
Adrian



Envelope-to: [e-mail]
Delivery-date: Fri, 12 Mar 2004 14:32:07 +0000
Message-ID: <06bd01c4083e$a603d4c0$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Draft minutes from Seoul
Date: Fri, 12 Mar 2004 14:30:20 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Very many thanks to Eric Gray for doing the hard work and
for supplying an excellent set of minutes.

There are a couple of gaps. Please let me know what you said (or want you want recorded
:-).

Comments as soon as possible, please.

Thanks,
Adrian

Common Control and Measurement Plane WG (ccamp)

THURSDAY, March 4 at 0900-1130
===============================

CHAIRS: Kireeti Kompella <[e-mail]>
        Adrian Farrel <[e-mail]>

AGENDA:

===
Group Admin
---
Chairs
  Admin - Nothing much to say (in English anyway)
        - In Korean, however, the following was said:
          "Jigeumbuteo CCAMP meetingeul sijakhagesumnida".

  Agenda bash (5 mins) - No changes
  Status of WG drafts and milestones
    Adrian's slides showed that we do have some draft
    congestion in the WG.
    - RFC editor queue
    - status of IANA for SONET/SDH
      Kireeti talked about an issue with SONET/SDH IANA
      assignments
    - need a means to get early assignments.
      There is WIP to accomplish this, and it is moving
      ahead.
    - future allocation of "experimental" values

Liaisons
---
Marco Carugi talked about work in SG-13 (SG13 liaison).
  He covered topics, new study areas, timescales, objectives
  and status. They are also looking for people interested in
  doing work in these areas.

  An L1 VPN questionnaire and framework draft were attached
  to the liaison.

  Tomonori Takeda talked about the technical issues and
  details of the work.

  Monique Morrow had a couple of clarification for Marco -
  When will the consent portion of the work be done in the
  ITU?

    Marco said that the different pieces of work were
    progressing at different speeds. Some material is
    already embodied in recommendations. The next SG13
    meetings are in June and September.

  Dimitri Papadimitriou asked if the liaison could include
  a summarization of the purpose and intent of the liaison.

    Kireeti answered. If CCAMP's rechartering this month
    results in the addition of L1VPNs to the charter, then
    a Liaison response from the IETF will include this
    information, plus a request for a cooperative effort,
    preferably along the lines of the ASON routing work,
    wherein the ITU-T defines the requirements and the IETF
    does the protocol extensions.

  Alex Zinin said that we will have to make a decision at
  some point as to whether or not we want to do this work
  here.

  Someone from NTT raised a point that was not captured in
  the minutes.

  Deborah Brungard said that there is work and some synergy
  and that we should continue to work on this.

    Monique Morrow agrees that we should work on that.

    Marco added some comments that were not captured in the
    minutes.

    Malcolm Betts said he also feels that we should do this.

  Adrian took a quick poll and it seems as if nobody is
  against doing this work.

  Kireeti reminded people to continue this discussion on
  the list.

---
Lyndon Ong talked about work in SG-15 (3 liaisons).

  Liaisons were on ASON routing requirements, response to
  comments on Q14 for G.7713.2 and comments on the CCAMP
  ASON signaling requirements draft.

  Lyndon spent much of the time on the details of response
  to comments on Q14. It seems that some of the differences
  in architectural models revolve around "end-to-end" and
  "call segment" operating models.

  Kireeti asked for the reply by date.

    Lyndon did not have that.

    Steve Trowbridge said that the meeting starts on April
    19th

  Dimitri had a question on the deadline. Isn't there a
  similar deadline on (G.7713).

    Lyndon said that he had not gone into that. He gave a
    reason, but this was not captured in the minutes.

  Deborah said that the liaison for 7713.2 does not say any
  thing about convergence.

    Lyndon said that they are still looking for a "meeting
    of the minds".

  Deborah said that there is an issue with G.7713.2 because
  of compatibility.

    Lyndon said that yes there has been a lot of discussion
    of compatibility questions and requirements.

  Kireeti said that we should not discuss this here.

  Steve Trowbridge added some comments that were not
  captured in the minutes.

  Kireeti asked the WG to take this discussion to the list
  and try to keep that discussion on a productive basis.

  Adrian said that he wanted to recognize the efforts of
  the ITU folks in this work.

===
ASON Requirements and Solutions
---
Dimitri Papadimitriou presented status of ASON Signaling
Requirements (draft-ietf-ccamp-gmpls-ason-reqts-05.txt.

  The requirements were driven by last years liaison from
  the ITU.

  After this meeting, Dimitri would like to re-spin the
  draft and have a two week last call.

  Lyndon said he wants to capture the requirement - whether
  or not we will work on it here.

  Kireeti said that we first need to understand importance
  of this and then we can look to the ADs for guidance on
  handling this.  He also said that we should take some time
  to work out what we want to say to the ITU when we include
  the current draft.

---
Dimitri Papadimitriou gave status ASON Signaling Solutions
(draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt) status.

  He would like feedback on whether or not the current draft
  deals correctly with the session attribute.

  His objective at this point is to try to have last call
  on this

  Lyndon suggested that we might remove the comparison with
  G.7713 from the draft.

    Adrian asked if this meant that the interworking draft
    for RFC3473/4 interworking was now obsolete.

      Lyndon said maybe, if interworking is removed as a
      requirement.

---
Lou Berger talked about Egress Control -
draft-berger-gmpls-egress-control-01.txt -

  Original egress label control became explicit label
  control. This draft attempts to capture the original
  intent.

  He wants to know if the WG feels that this is ready to
  be a BCP and what the chairs think the next steps should
  be.

  Lou re-iterated that the purpose and scope of the draft
  is for clarification. He does not see any value in adding
  to this intent or combining it with other work.

  Adrian then took a poll and nobody objected to take this
  on as a WG item (more than a third were in favor).

---
Lyndon Ong went over status on ASON Routing Requirements -
draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

  He includes in his presentation his conclusions as to what
  there is agreement that stuff is missing and areas in which
  there is still contention.

  Kireeti asked Lyndon to more formally open this discussion
  on the mailing list.

  Vishal Sharma said that he supports this.

  Kireeti said he would like - after checking with the AD -
  that we should take this work to the IS-IS and OSPF WGs.

    Alex Zinin said this is a good idea.

===
Tunnel Trace
---
Ron Bonica presented status on draft-bonica-tunproto-05.txt

  The solution is very similar to Trace-Route but does not
  require that each node in a tunnel supports TTL decrement.

  He gave a few examples as to how the idea in the draft
  will work in a few scenarios.

  There are a couple of outstanding issues:
  - trace requires a route to tunnel head end
  - integration with LSP ping.

  He would like to get the draft accepted as a WG draft.

  Yakov asked what SPs use today for tunnel tracing.

    Ron said that in some case people can use ICMP for MPLS.

  Yakov then asked if we could get a BCP on what people are
  doing.

    Ron asked if he should resubmit his earlier draft on
    this.

      Kireeti said that we do not want to decide that now.

===
Protection and Restoration
---
Dimitri Papadimitriou presented status on the work of the
Protection and Restoration Team - specifically:
1) draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
2) draft-ietf-ccamp-gmpls-recovery-functional-01.txt
3) draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
4) draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt

  He gave estimates on the timing for each of the above
  drafts (estimated completion dates).

  He outlined the changes to the e2e signaling ID (draft 4,
  above).

  He encouraged the WG to really read the documents and
  comment.

  Kireeti polled for consensus on the following:

    a) Analysis - last call? Some support, no objection
    b) Functional - last call? Some support, no objection
    c) Terminology - last call? Some support, no objection
    d) e2e Signaling - WG document? Some support, no object

  People at the microphone were asked to take their
  questions to the list.

---
Lou Berger presented an overview of work on Segment
Recovery - draft-berger-ccamp-gmpls-segment-recovery-00.txt

  He also talked about what still needs to be done (next
  steps), including more usage scenarios, more explanatory
  text and see if the WG will adopt this work.

  Arthi Ayyangar asked if the association object is required
  even if we are only doing segment recovery (as opposed to
  e2e).  She had follow up questions that Kireeti asked her
  to take to the list.

  Adrian polled for support of accepting this as a WG draft.
  There was moderate support and no objection.

===
Inter-Area/AS
---
Arthi Ayyangar talked about the status of the merged draft
on Inter-area/AS signaling -
draft-vasseur-ccamp-inter-area-as-te-00.txt

  The draft currently represents a full merge - work is still
  required to strip out redundant and unneeded text.

  She said that the authors encourage people to come forward
  with their comments.  She would also like to see if there
  is interest in this work becoming a WG document.

  Vishal Sharma said that he supports separating some of the
  path computation mechanisms from the rest of the document
  and removal of applicability text.

  Dimitri agreed on the subject of separating the document
  and made some suggestions for clarification of the draft.

    Arthi asked that Dimitri take his specific comments to
    the list.

  Kireeti said that he agrees that the document needs to be
  split - one as a signaling and another (informational) to
  provide examples for path computation. He also said that
  we need a separate applicability document.

---
Vishal Sharma talked about work on Inter-area path
protection
draft-dachille-inter-area-path-protection-00.txt

  He provided a brief overview of how it works, and showed
  how it relates to other work in progress. He also listed
  the next steps.

  Zafar Ali asked how this would work if there is a failure
  at the time during which the backup path is being setup.

    Zafar and Vishal chatted for a while and then Kireeti
    asked them to take the discussion to the list.

  Dimitri asked why the document is so focused on
  optimization.

  Kireeti asked that further discussion on this should be
  taken to the list.

  Also, he said that Dimitri had a good point - we need to
  define criteria on which any optimization is based.

===
Control Pane Resilience, Hello Protocol and Graceful Restart
---
Young Hwa Kim gave a presentation on Requirements for the
Resilience of Control Plane in GMPLS -
draft-kim-ccamp-cpr-reqts-00.txt

  He described the reasons why control plane resilience is
  needed.

  Zafar asked how control plane resilience is different from
  anything else in IP.

  Steve Trowbridge said that their is also some work in this
  area in the ITU and he would try to get this in as a
  liaison as soon as possible.

  Kireeti said that this is an important discussion and
  there are a lot of things to do. Specific topics should be
  raised on the list when appropriate.

---
Lou Berger went over Extensions to GMPLS RSVP Graceful
Restart
draft-aruns-ccamp-rsvp-restart-ext-00

  He emphasized that egress restart is already covered in
  RFC3473 and this work has no effect on that functionality.
  He gave a brief overview and listed open issues.

  Next steps include merging with other restart drafts and
  seeing if this work can become a WG draft.

  Arthi said that she feels that the document focuses too
  much on the ERO. She feels that the draft should address
  other issues and concerns with the mechanism.

    Lou asked if she would like to contribute text.

  The chairs then asked for other discussion to go to the
  list.

---
Zafar Ali talked about Extensions to GMPLS RSVP Graceful
Restart
draft-rahman-ccamp-rsvp-restart-extensions-00.txt

  Kireeti said that he appreciated the honesty of the
  authors in acknowledging other work.

  Nurit Sprecher asked about the relationship to FRR and
  similar issues.

    Adrian agreed that these were important issues and had
    been raised on the list in recent days. He asked the
    authors to make sure that they cover the points in the
    draft.

---
Zafar then covered modifications to Hello procedures
1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
2) draft-ali-ccamp-rsvp-hello-gr-admin-00.txt

  He wants to go forward with draft 1 above.

  Adrian polled and there was some interest and no strong
  objection.

  Kireeti said that this work cannot be informational if
  it has - or proposes - changes to a standard.

  Zafar also wants draft 2 to be a WG document.

  Kireeti said that we need to take this to the list, but
  Zafar also needs to socialize the work he is doing so that
  people may decide whether or not this is work we want to
  do.

===
Everything Else
---
Emmanuel Dotaro gave status of Multi-region protection -
draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt

  He briefly covered changes since previous versions.

  He proposes that we may need to make changes to the
  charter to include all of this work.

  Adrian suggested that the authors need to get more people
  involved in this important work and revisit this later.

---
Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs
draft-vasseur-ccamp-isis-te-caps-00.txt

  He would like to have this accepted as a WG document.

  Adrian asked to hold off on this until after the OSPF talk
  below.

---
Seisho Yasukawa
draft-vasseur-ccamp-ospf-te-caps-00.txt

  He would like to have this accepted as a WG document.

  Regarding both drafts, Kireeti is not sure that this work
  belongs in this WG. The decision is driven by the
  generality of its applicability. If we do take it on, their
  needs to be a functional specification (independent of IGP)
  as well.

  He asked that further discussion be taken to the list.

---
The Following presentations were postponed as we ran out
of time. Adrian made a couple of brief comments as follows:
  ---
  Zafar Ali - Explicit Resource Control and Tracking
  draft-zamfir-explicit-resource-control-bundle-03.txt

    This work concerns identification of component links in
    EROs and RROs.

    A small group is currently examining other issues
    concerning identification of component links in all
    aspects of GMPLS. A draft is expected soon. Please mail
    Adrian or the list, if you want to be involved in this
    work.

  ---
  Lou Berger - Alarm Reporting
  draft-berger-ccamp-gmpls-alarm-spec-01.txt

    This draft is stable and complete in the view of the
    authors.

    A quick poll showed some support for this being a WG
    document, and no opposition. This will be taken to the
    list.




Envelope-to: [e-mail]
Delivery-date: Fri, 12 Mar 2004 14:01:23 +0000
Message-ID: <[e-mail]>
Date: Fri, 12 Mar 2004 08:58:54 -0500
From: Reshad Rahman <[e-mail]>
Organization: Cisco Systems
MIME-Version: 1.0
To: Lou Berger <[e-mail]>
CC: Nic Neate <[e-mail]>, Adrian Farrel <[e-mail]>, "Satyanarayana, Arun" <[e-mail]>, [e-mail], [e-mail], Anca Zamfir <[e-mail]>, Junaid Israr <[e-mail]>, Zafar Ali <[e-mail]>
Subject: Re: draft-aruns-ccamp-rsvp-restart-ext-00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We'll have the part for simultaneous adjacent restarts in ~2 weeks.

Regards,
Reshad.

Lou Berger wrote:
> 
> Nic,
>          In one-on-one discussions at the IETF the authors agreed to do
> just these two things!  I know we're hoping to get the first part done late
> this week/early next week.  I can't speak for the other authors (of the
> other half of the to-be-merged draft) on the second part.
> 
> Lou
> 
> At 07:41 AM 3/9/2004 -0500, Nic Neate wrote:
> 
> >Hi Adrian (and draft-aruns authors),
> >
> >Responses below.  In summary, I agree
> >  - with the suggestion of being able to request RecoveryPath messages
> >  - that it would be very helpful if the procedures for recovering from
> >simultaneous adjacent restarts could be clarified.
> >
> >Thanks,
> >
> >Nic
> >
> > > -----Original Message-----
> > > From: Adrian Farrel
> > [<mailto:[e-mail]>mailto:[e-mail]]
> > > Sent: Saturday, March 06, 2004 12:47 PM
> > > To: Nic Neate; [e-mail]; Movaz Networks - Louis Berger;
> > > [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: draft-aruns-ccamp-rsvp-restart-ext-00
> > >
> > >
> > > Hi Nic,
> > >
> > > > I've just read your draft-aruns-ccamp-rsvp-restart-ext-00
> > > and it looks good.
> > > > In particular, we've been looking at using Restart for Fast
> > > Reroute LSPs for
> > > > some time and this draft provides everything that is needed
> > > (like recovering
> > > > the FAST_REROUTE, DETOUR, SENDER_TEMPLATE and ERO
> > > > objects from the downstream node when they are not
> > > available from upstream).
> > >
> > > Good. This concern was also raised in Seoul, and I am pleased
> > > to hear that the draft
> > > addresses these requirements.
> > >
> > > > However, I have a couple of concerns (not related to Fast Reroute).
> > > >
> > > >  - Your draft doesn't tackle, and won't work for,
> > > simultaneous restart of
> > > > adjacent nodes.  This is a problem that is tackled by
> > > > draft-rahman-ccamp-rsvp-restart-extensions, so merging the
> > > two drafts in
> > > > some way may be the best way to resolve that.  I realize
> > > that the Aruns
> > > > draft aims to make Restart possible for nodes which cannot
> > > retrieve state
> > > > from the data plane, and in that case recovering from
> > > simultaneous restart
> > > > of adjacent nodes isn't easy.  I think including some
> > > further extensions for
> > > > nodes which can retrieve some state from the data plane would be
> > > > appropriate.
> > >
> > > Retrieving state from the data plane only answers half of the
> > > problem. However, it is
> > > certainly important to audit the recovered control plane
> > > information against the known
> > > data plane state.
> > >
> >
> >Indeed.  My point was that if you can't retrieve even the outgoing signaling
> >interface from your data plane following a "nodal fault", you haven't got
> >much hope of reconstructing protocol state in between two nodes which
> >restarted at the same time (without some serious protocol enhancement
> >anyway).  Hence the suggestion of additional extensions to recover from
> >adjacent restarts for nodes which can retrieve the outgoing signaling
> >interface.
> >
> > > With regard to adjacent node failures and restarts, I believe
> > > there are actually
> > > sufficient capabilities here. Perhaps the authors would like
> > > to include text to clarify
> > > the procedures.
> > >
> >
> >If this is the case, then no problem.  I agree that some text clarifying
> >that in the draft would be very helpful.
> >
> > > >  - The back compatibility with RFC 3473 restart looks
> > > risky.  Draft Aruns
> > > > mandates that restarted nodes don't send Path Refreshes
> > > until either the
> > > > recovery period expires or a RecoveryPath is received from
> > > downstream.  In
> > > > the case that the downstream node only supports RFC 3473
> > > restart (and so
> > > > doesn't send RecoveryPaths), it may well timeout Path state
> > > at the same time
> > > > as or very soon after the recovery period expires.  Hence a
> > > dangerous timing
> > > > window is created.
> > >
> > > You have something here.
> > > However, section 9.5.3 of RFC3473 does not say that the
> > > neighbor MUST discard state that
> > > is not restored in the recovery time interval. Presumably it
> > > would simply recommence
> > > waiting for state refresh and so would time out after a 3.5
> > > refresh intervals from the end
> > > of the recovery interval.
> > >
> >
> >That would be sensible behavior, yes.  My concern (as I'm sure you realize)
> >is that it won't happen like that in all cases in the real world.
> >
> > > Some compromise may be introduced here by noting that 3473
> > > says that Path state SHOULD be
> > > restored within 1/2 of the recovery time. So we could follow
> > > this logic and use the first
> > > half of the time interval for the RecoveryPath message and
> > > the second half for backwards
> > > compatible recovery.
> > >
> > > On the other hand, I would prefer that this new capability
> > > (support for RecoveryPath
> > > message) was signaled in the Restart_Capabilities object so
> > > that the restarting node can
> > > know whether to expect to receive a RecoveryPath or not.
> > >
> > > > As a potential solution to both problems I'd suggest that a
> > > restarting node
> > > > receiving a Path message with a recovery label should
> > > always forward it
> > > > immediately as well as it can, and include both a recovery
> > > label and (for
> > > > back compatibility) a suggested label.  Similarly, it should forward
> > > > RecoveryPath messages immediately as well as it can.  I'd
> > > be happy to
> > > > discuss any of this further.
> > >
> > > This sounds very dangerous.
> > > "As well as it can" may include path computation which may
> > > pick a path other than the one
> > > previously in use. Hence the new Path message will be sent to
> > > a new neighbor. This
> > > disaster is no better than the problem we are trying to solve.
> > >
> >
> >Fine.  I had in mind that a node should only forward a Path message before
> >receiving a RecoveryPath if it was sure that it could send it (as per
> >RFC3473) to the right place and without a dangerous ERO.  In any case, I
> >prefer the idea of being able to request RecoveryPath messages and it sounds
> >like that will make recovery possible in more situations.
> >
> > > Cheers,
> > > Adrian
> > >



Envelope-to: [e-mail]
Delivery-date: Fri, 12 Mar 2004 07:16:02 +0000
From: "zafar ali" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>
Cc: <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, "'Danny Prairie'" <[e-mail]>
Subject: RE: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
Date: Fri, 12 Mar 2004 02:14:29 -0500
Organization: Cisco Systems
Message-ID: <000201c40801$aa272c60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Kireeti, Adrian, et al

This is a follow-up on Kireeti's comment on the above mentioned draft
during the last CCAMP WG meeting. I looked through the
http://www.ietf.org/rfc/rfc2026.txt, which states about BCP sub-series: 

(BCP sub-series) "is a vehicle by which the IETF community can define
and ratify the community's best current thinking on a statement of
principle or on what is believed to be the best way to perform some
operations or IETF process function." RFC2026, Section5, page 16. 

We think that draft-ali-ccamp-rsvp-node-id-based-hello-00.txt fits this
definition quite well. It does NOT define any protocol extensions and
only formalizes use of node-id based RSVP Hello sessions. In the revised
version we would like to position the draft as a BCP. 

Comments will be appreciated. 

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of zafar ali
>Sent: Friday, February 06, 2004 3:25 PM
>To: [e-mail]
>Cc: [e-mail]
>Subject: RE: comments on 
>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>
>
>Hi Dimitri, 
>
>Thanks for your comments and feedback. I have in-lined some 
>new comments. 
>
>As I mentioned in my earlier email that we will take care of 
>these comments in the next version of the document. 
>
>Thanks again for your feedback. 
>
>Regards... Zafar
>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of 
>>[e-mail]
>>Sent: Friday, February 06, 2004 11:17 AM
>>To: zafar ali
>>Cc: [e-mail]
>>Subject: Re: comments on 
>>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>>
>>
>>hi, some comments on this document that would imho
>>beneficiate from the community
>>
>
>Thanks, 
>
>>>>   Another scenario which introduces the need for node-id
>>based Hellos
>>>>   is when nodes support unnumbered TE links. Specifically, 
>when all 
>>>>TE
>>>>   links between neighbor nodes are unnumbered, it is
>>implied that the
>>>>   nodes will use node-id based Hellos for detecting node
>>>>failures. This
>>>>   draft also clarifies the use of node-id based Hellos 
>when all or a
>>>>   sub-set of TE links are unnumbered.
>>>>
>>>>DP: the key point is "is the router id used to identify the te link 
>>>>the same as the one used for the hello's ?"
>>>  
>>> Yes, the same router-id/ node-id is used.
>>
>>ok, that's what i wanted to know and i would propose to include the 
>>above sentence in this i-d
>>
>
>Agreed, we will. 
>
>>>>   When link level failure detection is performed by some 
>means other
>>>>   than RSVP Hellos (e.g., [BFD]), the use of node-id based 
>Hellos is
>>>>   also optimal for detection of nodal failures.
>>>>
>>>>DP: pin point that this is a particular case, it's not a nodal 
>>>>failure but a RSVP-TE signaling adjacency failure, RSVP-TE 
>signaling 
>>>>controller failure,
>>> 
>>> Agreed! this is more precise statement.
>>
>>ok, thanks
>>
>>>>note that if this session is
>>>>maintained and is used as the IP channel for all messages then
>>>>it MAY also be used as "nodal failure"
>>>>
>>>>   An implementation may initiate a node-id based Hello 
>session when 
>>>>it
>>>>   starts sharing RSVP states with the neighbor or at an
>>earlier time.
>>>>
>>>>DP: i don't understand what you mean here
>>>>
>>> What we meant here is that an application may not run RSVP Hello
>>> session all the time. It may initiate one when it has an 
>application 
>>> (e.g., when for GR when it start sharing states with the neighbor.
>>
>>this is an interesting statement to be considered in the
>>scope of this document
>
>No, these details are implementation specific. The related 
>para was included in the ID as a reference (to avoid confusion 
>on how node-id's can be obtained.). Nonetheless, as you would 
>agree that this is implementation specific detail, and hence 
>is outside the scope of the ID.  
>
>>
>>>>   Similarly, an implementation may use the IGP topology to 
>determine
>>>>   the remote node-id which matches an interface address(es) used in
>>>>   RSVP signaling. These aspects are considered to be a local
>>>>   implementation decision.
>>>>
>>>>DP: how is this possible since you're using the router_id being the 
>>>>router_address advertized as top level te link 1 in ospf_te
>>>>
>>>  
>>> In Inter-area and inter-AS case, this information is assumed to come
>>> via configuration. Is this what you meant here?
>>
>>the above sentence introduces an issue once the interface
>>is in failure state, i would provide more details here wrt
>>to real expectations behind the above paragraph either it
>>is implementation specific w/o impact on neighbors or it
>>has and then would suggest some details on the last part.
>>
>
>This is also an implementation specific detail.  
>
>>>>   When a node receives a Hello packet where the destination IP 
>>>>address
>>>>   is its local node-id as advertised in the IGP-TE
>>topology, the node
>>>>   MUST use its node-id in replying to the Hello message. In other
>>>>   words, nodes must ensure that the node-ids used in RSVP Hello
>>>>   messages are those derived/contained in the IGP-TE topology.
>>>>   Furthermore, a node can only run one node-id based RSVP
>>>>Hello session
>>>>   with its neighbor.
>>>>
>>>>DP: well here in fact you have a real issue because, a may have 
>>>>several node_id's on a node, so what you want to say is "one per 
>>>>node_id pair"
>>> 
>>> Yes, in the cases when router is participating multiple topologies
>>> (OSPF & ISIS). But AFAIK router can only advertsie ONLY one 
>>address in
>>> a given IGP instance.
>>> 
>>> We need to make statement clear for multiple IGP instances case. Is
>>> this is what you meant?
>>
>>exactly
>
>This is a good point. New text will be updated based on your comment. 
>
>>
>>>>   If all interfaces between a pair of nodes are unnumbered, the 
>>>>optimal
>>>>   way to use RSVP to detect nodal failure is to run node-id based
>>>>   Hellos. Similarly, when link level failure detection is
>>>>performed by
>>>>   some means other than RSVP Hellos, use of node-id based Hellos is
>>>>   also optimal in detecting nodal failures. Therefore, if all
>>>>   interfaces between a pair of nodes are unnumbered or when 
>>>>link level
>>>>   failure detection is performed by some means other than 
>>>>RSVP Hellos,
>>>>   a node MUST run node-id based Hellos for node failure detection.
>>>>
>>>>DP: this is not true, i can run LMP, but a MUST for the signaling 
>>>>adj. maintenance
>>>>
>>>  
>>> Yes, we can clarify it in the next version.
>>
>>thanks,
>>--
>>Papadimitriou Dimitri
>>E-mail : [e-mail]
>>E-mail : [e-mail]
>>Webpage: http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : [phone]
>>
>>
>
>=====================================================================
>Zafar Ali, Ph. D. 				  100 South Main St.
>#200,
>Technical Leader, 				  Ann Arbor, MI 48104,
>USA.
>Cisco Systems.					  [phone].
>=====================================================================
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 12 Mar 2004 04:44:15 +0000
From: "zafar ali" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Opinion sought on drafts being adopted by CCAMP
Date: Thu, 11 Mar 2004 23:42:37 -0500
Organization: Cisco Systems
Message-ID: <000401c407ec$72db7dc0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Adrian, 

Yes to all. 

Thanks
 
Regards... Zafar

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Adrian Farrel
>Sent: Thursday, March 04, 2004 6:46 AM
>To: [e-mail]
>Subject: Opinion sought on drafts being adopted by CCAMP
>
>
>All,
>
>At the CCAMP meeting today we discussed making several drafts 
>working group items. Can you please express your opinion 
>(yes/no) on whether each of the following drafts is ready to 
>become a CCAMP working group draft.
>
>Feel free to express yes with reservations. If you have 
>reservations or objections, please express them on the list. 
>if you need anonymity for your comments then please filter 
>them through the chairs.
>
>Silence will be taken as meaning nothing, so please say what you think.
>
>GMPLS Signaling Procedure For Egress Control 
>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-c
ontrol-01.txt

Generic Tunnel Tracing Protocol (GTTP) Specification
http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-
signaling-03.txt

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-rec
overy-00.txt

Thank you,
Adrian





Envelope-to: [e-mail]
Delivery-date: Fri, 12 Mar 2004 03:41:55 +0000
Message-ID: <034901c407cb$01903500$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, <[e-mail]>
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Date: Thu, 11 Mar 2004 05:03:25 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Lyndon,

> -- rsvp for e2e recovery - there seemed to be still some concerns
>    at the meeting, so no (not yet)

Since the person that raised the concerns at the meeting has given support to this draft
becoming a WG draft, can we move on?

> -- segment recovery - no (not yet)

Would you care to say why?

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 12 Mar 2004 03:16:37 +0000
Message-ID: <035301c407cb$0679af10$1100050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [Re] Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
Date: Thu, 11 Mar 2004 08:18:53 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: 7bit

Hi,

Thanks for continuing this discussion on the list where it is visible to everyone.

Can you clarify for me (I'm an LCAS novice) why you propose extending GMPLS to handle the
fact that LCAS is unidirectional, instead of extending LCAS to be bidirectional?

Also, how is this problem any different from the issues of bidirectionality that GMPLS has
to solve (namely allocation of resources and labels for the reverse path during the
forward signaling)?

Lastly (and this really shows my ignorance!) why do you propose to use LCAS and GMPLS at
the same time? GMPLS has the capability to signal concatenated flows, and to set and vary
bandwidth reservations at transit nodes.

Thanks,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Sunday, February 29, 2004 9:12 AM
Subject: [Re] Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt


> Hi,
>
> Thank you for your detailed explanation.
>
> For your example of the call request for EPL of 10 M that I think is a uni-
> directional case,
> if a GMPLS signaling protocol is used, maybe two LSPs will be established
> with only uni-diretional connections
> because their paths are different each other. The case is not my hope.
>
> My intention is not to simplify the LCAS operation itself, but to simplify
> the initiation processes invoked by EMS/NMS systems.
>
> As indicated in G.7042, the operation of LCAS is uni-directional. This
> means that in order to bi-directionally add or remove members the procedure
> has to be repeated in the opposite direction.
>
> If the two uni-directional(downstream and upstream) connections for a call
> request have the same route,
> EMS/NMS systems should invoke two times of the LCAS operations towards
> ingress and egress nodes.
> I want to reduce into only one time using a GMPLS signaling protocol.
>
> Thanks,
>
> Young.
>




Envelope-to: [e-mail]
Delivery-date: Fri, 12 Mar 2004 00:01:48 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Alex Zinin" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Greg Bernstein" <[e-mail]>, "Eric Mannie" <[e-mail]>, <[e-mail]>, "Bert Wijnen" <[e-mail]>
Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Thu, 11 Mar 2004 16:00:13 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Alex,

Great! Thanks for clarifying. I think this clears up my confusion.

We will send a response to the various comments on the list
along the lines you have indicated, and also
start incorporating them appropriately in a revised of the
document, and (I assume) re-post to the IETF drafts directory,
so the document can move forward.

-Vishal

> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Thursday, March 11, 2004 2:35 PM
> To: Vishal Sharma
> Cc: Adrian Farrel; Greg Bernstein; Eric Mannie; [e-mail]; Bert
> Wijnen
> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> Vishal,
>
>  The technical part of the debate may in general continue up
> until the end of
>  the IESG review. Fortunately there is only a small percentage of
> documents
>  that end up in such situation.
>
>  Pass the WG LC means that the WG is comfortable sending the doc
> to the IESG.
>  However, the AD can bring back feedback for consideration by the
> WG. Possible
>  replies for each comment could be something like "yes, we'll
> address this", or
>  "we discussed this and decided to do that way, because...", or a
> discussion.
>
>  Thanks.
>
> --
> Alex
> http://www.psg.com/~zinin/
>
> Wednesday, March 10, 2004, 8:15:10 PM, Vishal Sharma wrote:
> > Alex,
>
> > Thank you for taking the time to clarify the process, and for having
> > the expert review of our document done.
> > (I think the suggestions and comments will be very valuable in helping
> > to further improve the document.)
>
> > Looking at your note, I think I understood the stages right, and also
> > understood correctly that changes/enhancements are normal in stages
> > 3-6 as well.
>
> > On the other hand, it is my understanding that the debate surrounding
> > a document (technical aspects, key content, applicability, etc.) is
> > completed
> > in stages 1 and 2. In fact, I understand that passing the final
> WG LC, is
> > the point that marks the conclusion of such a debate(s).
>
> > Thereafter, we essentially try to work to refine and tighten a document
> > for eventual publication as an RFC, in the appropriate category
> > (in this case informational). Hence, my confusion.
>
> > Is my understanding not correct?
>
> > Regards,
> > -Vishal
>
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]On
> >> Behalf Of Alex Zinin
> >> Sent: Wednesday, March 10, 2004 5:38 PM
> >> To: Vishal Sharma
> >> Cc: Adrian Farrel; Greg Bernstein; Eric Mannie;
> [e-mail]; Bert
> >> Wijnen
> >> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> >>
> >>
> >> Vishal,
> >>
> >>   To clarify the process, here's the list of stages a document
> >> usually goes
> >>   through:
> >>
> >>   1. WG discussion
> >>   2. WG Last Call
> >>   3. AD review (may include directorate       <-- You are here now
> >>      and expert reviews)
> >>   4. IETF LC (generally not needed for INFO)
> >>   5. IESG review
> >>   6. RFC Editor
> >>
> >>   I received the doc back in Sep 2003 and asked one of the Routing Area
> >>   directorate members for an expert review, which resulted in a
> >> long list of
> >>   comments. We had a long (and admittedly slow) discussion
> >> between the reviewer,
> >>   me, and the WG chairs in an attempt to distill it to a set of
> >> most significant
> >>   technical comments and editorial suggestions, which is what I
> >> brought back for
> >>   consideration by the WG.
> >>
> >>   On a related note: please do not assume that work is done once
> >> a document has
> >>   passed the WG LC. It is normal to receive comments from the ADs
> >> and IESG.
> >>
> >>   Regards.
> >>
> >> --
> >> Alex
> >> http://www.psg.com/~zinin/
> >>
> >> Sunday, March 7, 2004, 1:41:10 PM, Vishal Sharma wrote:
> >> > Adrian,
> >>
> >> > I am still very confused about what the debate is about at
> this point.
> >> > In any case, I would like to defer to my co-authors on this matter.
> >>
> >> > As for the enhancements/edits, I think we already stated that we
> >> > could do those.
> >>
> >> > -Vishal
> >>
> >> >> -----Original Message-----
> >> >> From: Adrian Farrel [mailto:[e-mail]]
> >> >> Sent: Sunday, March 07, 2004 3:24 AM
> >> >> To: Vishal Sharma; Greg Bernstein; Eric Mannie
> >> >> Cc: [e-mail]; Alexey Zinin; Bert Wijnen
> >> >> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> >> >>
> >> >>
> >> >> Thanks for your thoughts Vishal.
> >> >>
> >> >> The debate occurs now.
> >> >>
> >> >> Are the current authors willing and able to make the changes
> >> >> requested by the AD?
> >> >>
> >> >> Thanks,
> >> >> Adrian
> >> >> ----- Original Message -----
> >> >> From: "Vishal Sharma" <[e-mail]>
> >> >> To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
> >> >> <[e-mail]>;
> >> >> "Eric Mannie" <[e-mail]>
> >> >> Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>;
> >> "Bert Wijnen"
> >> >> <[e-mail]>
> >> >> Sent: Sunday, March 07, 2004 12:48 AM
> >> >> Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> >> >>
> >> >>
> >> >> > Adrian,
> >> >> >
> >> >> > Thanks for the clarification. Our (the authors) understanding is
> >> >> > that the draft had passed (quite a while back, in May 2002
> >> >> > actually, after we had addressed the very last round of
> comments from
> >> >> > Kireeti), all of the processes in the WG needed to advance it to
> >> >> > informational RFC.
> >> >> >
> >> >> > Its purpose is really to provide an overall view and framework for
> >> >> > SDH/SONET control using an IP/MPLS control plane.
> >> >> >
> >> >> > So it would be useful for us to know exactly where the
> >> debate occurred,
> >> >> > since we were not aware of it.
> >> >> > (As far as the WG is concerned,  the draft was approved
> such a while
> >> >> > back that it has been a completed item for over
> >> one-and-a-half years.)
> >> >> >
> >> >> > At the last discussion on it in Sept. 2003, we were told
> >> that the only
> >> >> > reason it had got delayed was because it somehow missed being
> >> >> sent to the
> >> >> > ADs on time.
> >> >> >
> >> >> > -Vishal
> >> >> >
> >> >> > > -----Original Message-----
> >> >> > > From: [e-mail]
> [mailto:[e-mail]]On
> >> >> > > Behalf Of Adrian Farrel
> >> >> > > Sent: Saturday, March 06, 2004 3:11 PM
> >> >> > > To: Vishal Sharma; Greg Bernstein; Eric Mannie
> >> >> > > Cc: [e-mail]; Alexey Zinin
> >> >> > > Subject: Re: AD-review comments on
> >> draft-ietf-ccamp-sdhsonet-control
> >> >> > >
> >> >> > >
> >> >> > > Vishal,
> >> >> > >
> >> >> > > The process is that the WG hands the draft off to the AD to take
> >> >> > > it to the IESG. At this
> >> >> > > point the AD performs a review before taking the draft to the
> >> >> > > IESG and this is what we are
> >> >> > > seeing the results of.
> >> >> > >
> >> >> > > Note that this particular draft has been under "AD watch" for a
> >> >> > > while. Alex may want to
> >> >> > > clarify the reason for this, but my understanding is that there
> >> >> > > was some debate as to
> >> >> > > whether the draft had served its purpose already (that is, as a
> >> >> > > design document for the
> >> >> > > other drafts on SONET/SDH) or whether it should continue and
> >> >> > > become an RFC. This review is
> >> >> > > the next step towards becoming an RFC.
> >> >> > >
> >> >> > > Cheers,
> >> >> > > Adrian
> >> >> > >
> >> >> > > ----- Original Message -----
> >> >> > > From: "Vishal Sharma" <[e-mail]>
> >> >> > > To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
> >> >> > > <[e-mail]>;
> >> >> > > "Eric Mannie" <[e-mail]>
> >> >> > > Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>
> >> >> > > Sent: Saturday, March 06, 2004 8:41 PM
> >> >> > > Subject: RE: AD-review comments on
> >> draft-ietf-ccamp-sdhsonet-control
> >> >> > >
> >> >> > >
> >> >> > > > Adrian et al,
> >> >> > > >
> >> >> > > > We will work on the document and make the appropriate
> >> modifications
> >> >> > > > to incorporate the comments.
> >> >> > > >
> >> >> > > > BTW, Alex could you please clarify whether this is an
> IESG review
> >> >> > > > or some other review?
> >> >> > > >
> >> >> > > > Our understanding after the last communication with
> >> Kireeti on this
> >> >> > > > subject, sometime
> >> >> > > > in July last year, was that this draft (after having
> >> passed several
> >> >> > > > last calls), was being sent to the IESG for completing
> >> the process
> >> >> > > > of advancing to informational RFC.
> >> >> > > >
> >> >> > > > Thanks,
> >> >> > > > -Vishal
> >> >> > > >
> >> >> > > > > -----Original Message-----
> >> >> > > > > From: Adrian Farrel [mailto:[e-mail]]
> >> >> > > > > Sent: Saturday, March 06, 2004 4:16 AM
> >> >> > > > > To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
> >> >> > > > > Cc: [e-mail]
> >> >> > > > > Subject: Re: AD-review comments on
> >> >> draft-ietf-ccamp-sdhsonet-control
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > Greg, Eric, Vishal,
> >> >> > > > > Are you willing and able to pick this draft up again
> >> and make the
> >> >> > > > > changes from Alex?
> >> >> > > > >
> >> >> > > > > Thanks,
> >> >> > > > > Adrian
> >> >> > > > >
> >> >> > > > > ----- Original Message -----
> >> >> > > > > From: "Alex Zinin" <[e-mail]>
> >> >> > > > > To: <[e-mail]>
> >> >> > > > > Cc: <[e-mail]>
> >> >> > > > > Sent: Thursday, March 04, 2004 12:48 PM
> >> >> > > > > Subject: AD-review comments on
> >> draft-ietf-ccamp-sdhsonet-control
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > > Folks-
> >> >> > > > > >
> >> >> > > > > >  Please find below comments from the RTG area directorate
> >> >> > > that I would
> >> >> > > > > >  like the WG to consider.
> >> >> > > > > >
> >> >> > > > > >  Thank you.
> >> >> > > > > >
> >> >> > > > > > --
> >> >> > > > > > Alex Zinin
> >> >> > > > > >
> >> >> > > > > > Technical:
> >> >> > > > > > ----------
> >> >> > > > > >
> >> >> > > > > > Section 3.2:
> >> >> > > > > >
> >> >> > > > > > 1. Figure 1 misses the STM-0 branch
> >> >> > > > > >
> >> >> > > > > > Section 3.4.3:
> >> >> > > > > >
> >> >> > > > > > 2. In comparison table, PNNI word appears for the first
> >> >> time in this
> >> >> > > > > >     document, any specific reason to mention PNNI in a
> >> >> > > GMPLS context ?
> >> >> > > > > >
> >> >> > > > > > Section 3.5
> >> >> > > > > >
> >> >> > > > > > 3. "New simplified encapsulations could reduce this
> >> >> > > overhead to as low
> >> >> > > > > >     as 3%, but the gain is not huge compared to SDH
> >> and SONET,
> >> >> > > > > which have
> >> >> > > > > >     other benefits as well.)" any reference available
> >> >> for these new
> >> >> > > > > >     simplified encapsulation(s) ?
> >> >> > > > > >
> >> >> > > > > > 4. "Any encapsulation of IP over WDM should at least
> >> >> provide error
> >> >> > > > > >     monitoring capabilities (to detect signal
> >> >> degradation), error
> >> >> > > > > >     correction capabilities, such as FEC (Forward Error
> >> >> > > Correction) that
> >> >> > > > > >     are particularly needed for ultra long haul
> >> >> > > transmission, sufficient
> >> >> > > > > >     timing information, to allow robust synchronization
> >> >> (that is, to
> >> >> > > > > >     detect the beginning of a packet), and capacity
> >> to transport
> >> >> > > > > >     signaling, routing and management messages,
> in order to
> >> >> > > control the
> >> >> > > > > >     optical switches."
> >> >> > > > > >
> >> >> > > > > >     The first part refers to data plane capabilities,
> >> >> however the
> >> >> > > > > >     requirement: the "encapsulation of IP over WDM"
> >> >> should deliver
> >> >> > > > > >     the capacity to transport IP based control plane
> >> >> information -
> >> >> > > > > >     why is this the case ? an out of band network would
> >> >> also do the
> >> >> > > > > >     job and this statement makes thus the implicit
> >> >> assumption that
> >> >> > > > > >     data and control plane topology is congruent
> >> >> > > > > >
> >> >> > > > > > Section 6:
> >> >> > > > > >
> >> >> > > > > > 5. "Due to the increase in information transferred in
> >> >> the routing
> >> >> > > > > >     protocol, it may be useful to separate the
> >> relatively static
> >> >> > > > > >     parameters concerning a link from those that may be
> >> >> subject to
> >> >> > > > > >     frequent changes. The current GMPLS routing extensions
> >> >> > > [12],[13],
> >> >> > > > > >     [14] do not make such a separation, however."
> >> >> > > > > >
> >> >> > > > > >    it may be thus worth asking the question was the
> >> >> dissemination
> >> >> > > > > >    of these quasi-static "link capabilities" using the
> >> >> same rules
> >> >> > > > > >    as for any other TE LSA Type 1 sub-TLV the right
> >> approach ?
> >> >> > > > > >
> >> >> > > > > > Section 6.1:
> >> >> > > > > >
> >> >> > > > > > 6. what does the following sentence brings in the scope of
> >> >> > > this control
> >> >> > > > > >     plane framework (and this is even not necessarily true
> >> >> > > when vcat is
> >> >> > > > > >     provided over different line cards):
> >> >> > > > > >
> >> >> > > > > >     "Note that this inverse multiplexing process can be
> >> >> > > significantly
> >> >> > > > > >     easier to implement with SONET/SDH signals rather
> >> >> than packets."
> >> >> > > > > >
> >> >> > > > > > Section 6.3:
> >> >> > > > > >
> >> >> > > > > > 7. "However, if only standard concatenation is supported
> >> >> > > then reporting
> >> >> > > > > >     gets trickier since there are constraints on where the
> >> >> > > STS-1s can be
> >> >> > > > > >     placed. SDH has still more options and constraints,
> >> >> > > hence it is not
> >> >> > > > > >     yet clear which is the best way to advertise
> >> >> bandwidth resource
> >> >> > > > > >     availability/usage in SONET/SDH. At present, the
> >> >> GMPLS routing
> >> >> > > > > >     protocol extensions define minimum and maximum values
> >> >> > > for available
> >> >> > > > > >     bandwidth, which allows a remote node to make some
> >> >> > > deductions about
> >> >> > > > > >     the amount of capacity available at a remote link and
> >> >> > > the types of
> >> >> > > > > >     signals it can accommodate. However, due to the
> >> >> > > multiplexed nature
> >> >> > > > > >     of the signals, the authors are of the opinion that
> >> >> reporting of
> >> >> > > > > >     bandwidth particular to signal types rather than
> >> as a single
> >> >> > > > > >     aggregate bit rate is probably very desirable."
> >> >> > > > > >
> >> >> > > > > >     -> the authors do not explain from which perspective
> >> >> > > and the reasons
> >> >> > > > > >     this particular bw accounting report is desirable
> >> >> > > (sections 2.4.3 &
> >> >> > > > > >     2.4.8 of GMPLS routing explains how these values are
> >> >> > > used to take
> >> >> > > > > >     into account the multiplexing capability of a
> SONET/SDH
> >> >> > > interface),
> >> >> > > > > >     there is no real determination of the missing
> >> >> > > information at remote
> >> >> > > > > >     nodes for the establishment of an LSP with a certain
> >> >> > > amount of bw
> >> >> > > > > >     (note that it is not an issue of flexible vs standard
> >> >> > > concatenation
> >> >> > > > > >     issue but a control plane issue)
> >> >> > > > > >
> >> >> > > > > > Section 7.3:
> >> >> > > > > >
> >> >> > > > > > 8. "This information is specified in three parts [17],
> >> >> each of which
> >> >> > > > > >     refers to a different network layer."
> >> >> > > > > >
> >> >> > > > > > The description of the signaling elements shall
> mention the
> >> >> > > following:
> >> >> > > > > > (section 7.3 refers to [17] but the latter does not
> >> >> > > correspond to the
> >> >> > > > > > description given in this section)
> >> >> > > > > >
> >> >> > > > > >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
> >> >> > > > > >      which contains three parts: LSP Encoding
> Type, Switching
> >> >> > > > > Type, G-PID
> >> >> > > > > >
> >> >> > > > > >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
> >> >> > > > > SENDER_TSPEC/FLOWSPEC
> >> >> > > > > >      which contains 6 parts: Signal Type,
> (RCC,NCC,NVC), MT,
> >> >> > > > > Transparency,
> >> >> > > > > >      Profile
> >> >> > > > > >
> >> >> > > > > >   3. UPSTREAM_LABEL for Bi-directional LSP's (as
> [RFC3471/3])
> >> >> > > > > >
> >> >> > > > > >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object
> >> >> (as [RFC3473])
> >> >> > > > > >
> >> >> > > > > > ----
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > > Editorial:
> >> >> > > > > > ----------
> >> >> > > > > >
> >> >> > > > > > Section 3:
> >> >> > > > > >
> >> >> > > > > > 1. Sometimes this document refers to GMPLS other
> to MPLS and
> >> >> > > > > >     sometimes as above as "extending IP technology"
> >> >> > > > > >
> >> >> > > > > > Section 3.1
> >> >> > > > > >
> >> >> > > > > > 2. "When a packet reaches a core packet LSR, this LSR uses
> >> >> > > the label as
> >> >> > > > > >     an index into a forwarding table to determine the next
> >> >> > > hop and the
> >> >> > > > > >     corresponding outgoing label (and, possibly, the QoS
> >> >> > > treatment to be
> >> >> > > > > >     given to the packet), writes the new label into the
> >> >> packet, and
> >> >> > > > > >     forwards the packet to the next hop. "
> >> >> > > > > >
> >> >> > > > > > -> replace "core packet LSR" by "packet LSR"
> >> >> > > > > >
> >> >> > > > > > Section 3.2:
> >> >> > > > > >
> >> >> > > > > > 3. "SDH and SONET are two TDM standards widely used by
> >> >> operators to
> >> >> > > > > >     transport and multiplex different tributary signals
> >> >> over optical
> >> >> > > > > >     links, thus creating a multiplexing structure,
> >> >> which we call the
> >> >> > > > > >     SDH/SONET multiplex. SDH, which was developed by the
> >> >> > > ETSI and later
> >> >> > > > > >     standardized by the ITU-T [4], is now used worldwide,
> >> >> > > while SONET,
> >> >> > > > > >     which was standardized by the ANSI [5], is mainly used
> >> >> > > in the US.
> >> >> > > > > >     However, these two standards have several
> similarities,
> >> >> > > and to some
> >> >> > > > > >     extent SONET can be viewed as a subset of SDH.
> >> >> Internetworking
> >> >> > > > > >     between the two is possible using gateways.
> >> >> > > > > >
> >> >> > > > > >     Should be rather as "ITU-T SDH (G.707) includes both
> >> >> > > the European
> >> >> > > > > >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy
> >> >> > > (T1.105)." [...]
> >> >> > > > > >     "The ETSI SDH and SONET standards regarding frame
> >> >> structures and
> >> >> > > > > >     higher order multiplexing are the same. There are
> >> >> some regional
> >> >> > > > > >     differences on the terminology, on the use of some
> >> >> > > overhead bytes,
> >> >> > > > > >     and lower order multiplexing. Interworking between
> >> >> the two lower
> >> >> > > > > >     order hierarchies is possible using gateways."
> >> >> > > > > >
> >> >> > > > > > Section 3.2
> >> >> > > > > >
> >> >> > > > > > 4. "In addition, a pointer (in the form of the H1, H2
> >> >> and H3 bytes)
> >> >> > > > > >     indicates the beginning of the VC/SPE in the
> payload of
> >> >> > > the overall
> >> >> > > > > >     STM/SDH frame."
> >> >> > > > > >
> >> >> > > > > > -> replace "STM/SDH frame" by "STM/STS frame"
> >> >> > > > > >
> >> >> > > > > > Section 4.1
> >> >> > > > > >
> >> >> > > > > > 5. "The SONET case is a bit difficult to explain since,
> >> >> > > unlike in SDH,
> >> >> > > > > >     SPEs in SONET do not have individual names." they are

> >> >> > > > > simply referred
> >> >> > > > > >     to as VT-N SPE
> >> >> > > > > >
> >> >> > > > > > Section 6:
> >> >> > > > > >
> >> >> > > > > > 6. Since this document distinguishes between "optical
> >> >> > > networks", TDM,
> >> >> > > > > >     and WDM it would advisable to avoid the "optical TDM"
> >> >> > > as mentioned
> >> >> > > > > >     in the below sentence (it has another meaning
> >> than MSn/RSn
> >> >> > > > > switching)
> >> >> > > > > >
> >> >> > > > > > Section 6.1:
> >> >> > > > > >
> >> >> > > > > > 7. Table 2, misses the equivalence between VC-4 and
> >> STS-3c SPE
> >> >> > > > > >
> >> >> > > > > >  > Section 6.1:
> >> >> > > > > >
> >> >> > > > > > 8. "Standard and flexible concatenations are network
> >> >> services, while
> >> >> > > > > >     virtual concatenation is a SONET/SDH end-system
> >> >> service recently
> >> >> > > > > >     approved by the committee T1 of ANSI and
> ITU-T." remove
> >> >> > > "recently
> >> >> > > > > >     approved by the committee T1 of ANSI and ITU-T." and
> >> >> > > add the corr.
> >> >> > > > > >     reference.
> >> >> > > > > >
> >> >> > > > > > 9. "In one example of virtual concatenation, two end
> >> >> > > systems supporting
> >> >> > > > > >     this feature could essentially "inverse multiplex" two
> >> >> > > STS-1s into a
> >> >> > > > > >     virtual STS-2c for the efficient transport of 100 Mbps
> >> >> > > > > Ethernet traffic."
> >> >> > > > > >
> >> >> > > > > > -> STS-1-2v instead of "virtual STS-2c"
> >> >> > > > > >
> >> >> > > > > > 10. "Section layer: Preserves all section overhead,
> >> >> > > Basically does not
> >> >> > > > > >      touch any of the SONET/SDH bits."
> >> >> > > > > >
> >> >> > > > > > -> replace last part by "Basically does not modify
> >> or terminate
> >> >> > > > > >     any of the SONET/SDH overhead bits"
> >> >> > > > > >
> >> >> > > > > >     left column of the table misses the SDH overhead
> >> equivalent
> >> >> > > > > >
> >> >> > > > > > 11. Multiplexing of (?) in the following sentence
> "To perform
> >> >> > > > > >      multiplexing, a SONET network element should be line
> >> >> > > terminating."
> >> >> > > > > >
> >> >> > > > > > Section 6.2:
> >> >> > > > > >
> >> >> > > > > > 12. In the following "Standardized SONET line level
> >> protection
> >> >> > > > > techniques
> >> >> > > > > >      include: Linear 1+1 and linear 1:N automatic
> >> >> > > protection switching
> >> >> > > > > >      (APS) and both two-fiber and four-fiber
> bi-directional
> >> >> > > > > line switched
> >> >> > > > > >      rings (BLSRs). At the path layer, SONET offers
> >> >> > > uni-directional path
> >> >> > > > > >      switched ring protection." the same applies
> to SDH (to
> >> >> > > be adapted
> >> >> > > > > >      using the corr. terminology)
> >> >> > > > > >
> >> >> > > > > > Section 7:
> >> >> > > > > >
> >> >> > > > > > 13. "This VC-4 LSP can, in fact, be established
> >> between two non-
> >> >> > > > > >      adjacent internal nodes in an SDH network, and later
> >> >> > > > > >      advertised by a routing protocol as a new
> (virtual) link
> >> >> > > > > >      called a Forwarding Adjacency (FA)." -> add
> >> >> MPLS-HIERARCHY as
> >> >> > > > > >      reference
> >> >> > > > > >
> >> >> > > > > > 14. The following paragraph
> >> >> > > > > >      "For instance, the payload of an SDH STM-1 frame
> >> >> does not fully
> >> >> > > > > >       contain a complete unit of user data. In fact, the
> >> >> > > user data is
> >> >> > > > > >       contained in a virtual container (VC) that is
> >> allowed to
> >> >> > > > > float over
> >> >> > > > > >       two contiguous frames for synchronization
> purposes. A
> >> >> > > > > pointer in the
> >> >> > > > > >       Section Overhead (SOH) indicates the
> beginning of the
> >> >> > > VC in the
> >> >> > > > > >       payload." mixes SDH with SONET - pointers in SDH
> >> >> in H1/H2/H3
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >>




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 22:36:07 +0000
Date: Thu, 11 Mar 2004 14:35:06 -0800
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: "Vishal Sharma" <[e-mail]>
CC: "Adrian Farrel" <[e-mail]>, "Greg Bernstein" <[e-mail]>,  "Eric Mannie" <[e-mail]>, <[e-mail]>, "Bert Wijnen" <[e-mail]>
Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vishal,

 The technical part of the debate may in general continue up until the end of
 the IESG review. Fortunately there is only a small percentage of documents
 that end up in such situation.

 Pass the WG LC means that the WG is comfortable sending the doc to the IESG.
 However, the AD can bring back feedback for consideration by the WG. Possible
 replies for each comment could be something like "yes, we'll address this", or
 "we discussed this and decided to do that way, because...", or a discussion.

 Thanks.
 
-- 
Alex
http://www.psg.com/~zinin/

Wednesday, March 10, 2004, 8:15:10 PM, Vishal Sharma wrote:
> Alex,

> Thank you for taking the time to clarify the process, and for having
> the expert review of our document done.
> (I think the suggestions and comments will be very valuable in helping
> to further improve the document.)

> Looking at your note, I think I understood the stages right, and also
> understood correctly that changes/enhancements are normal in stages
> 3-6 as well.

> On the other hand, it is my understanding that the debate surrounding
> a document (technical aspects, key content, applicability, etc.) is
> completed
> in stages 1 and 2. In fact, I understand that passing the final WG LC, is
> the point that marks the conclusion of such a debate(s).

> Thereafter, we essentially try to work to refine and tighten a document
> for eventual publication as an RFC, in the appropriate category
> (in this case informational). Hence, my confusion.

> Is my understanding not correct?

> Regards,
> -Vishal

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]On
>> Behalf Of Alex Zinin
>> Sent: Wednesday, March 10, 2004 5:38 PM
>> To: Vishal Sharma
>> Cc: Adrian Farrel; Greg Bernstein; Eric Mannie; [e-mail]; Bert
>> Wijnen
>> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>>
>>
>> Vishal,
>>
>>   To clarify the process, here's the list of stages a document
>> usually goes
>>   through:
>>
>>   1. WG discussion
>>   2. WG Last Call
>>   3. AD review (may include directorate       <-- You are here now
>>      and expert reviews)
>>   4. IETF LC (generally not needed for INFO)
>>   5. IESG review
>>   6. RFC Editor
>>
>>   I received the doc back in Sep 2003 and asked one of the Routing Area
>>   directorate members for an expert review, which resulted in a
>> long list of
>>   comments. We had a long (and admittedly slow) discussion
>> between the reviewer,
>>   me, and the WG chairs in an attempt to distill it to a set of
>> most significant
>>   technical comments and editorial suggestions, which is what I
>> brought back for
>>   consideration by the WG.
>>
>>   On a related note: please do not assume that work is done once
>> a document has
>>   passed the WG LC. It is normal to receive comments from the ADs
>> and IESG.
>>
>>   Regards.
>>
>> --
>> Alex
>> http://www.psg.com/~zinin/
>>
>> Sunday, March 7, 2004, 1:41:10 PM, Vishal Sharma wrote:
>> > Adrian,
>>
>> > I am still very confused about what the debate is about at this point.
>> > In any case, I would like to defer to my co-authors on this matter.
>>
>> > As for the enhancements/edits, I think we already stated that we
>> > could do those.
>>
>> > -Vishal
>>
>> >> -----Original Message-----
>> >> From: Adrian Farrel [mailto:[e-mail]]
>> >> Sent: Sunday, March 07, 2004 3:24 AM
>> >> To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> >> Cc: [e-mail]; Alexey Zinin; Bert Wijnen
>> >> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>> >>
>> >>
>> >> Thanks for your thoughts Vishal.
>> >>
>> >> The debate occurs now.
>> >>
>> >> Are the current authors willing and able to make the changes
>> >> requested by the AD?
>> >>
>> >> Thanks,
>> >> Adrian
>> >> ----- Original Message -----
>> >> From: "Vishal Sharma" <[e-mail]>
>> >> To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
>> >> <[e-mail]>;
>> >> "Eric Mannie" <[e-mail]>
>> >> Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>;
>> "Bert Wijnen"
>> >> <[e-mail]>
>> >> Sent: Sunday, March 07, 2004 12:48 AM
>> >> Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>> >>
>> >>
>> >> > Adrian,
>> >> >
>> >> > Thanks for the clarification. Our (the authors) understanding is
>> >> > that the draft had passed (quite a while back, in May 2002
>> >> > actually, after we had addressed the very last round of comments from
>> >> > Kireeti), all of the processes in the WG needed to advance it to
>> >> > informational RFC.
>> >> >
>> >> > Its purpose is really to provide an overall view and framework for
>> >> > SDH/SONET control using an IP/MPLS control plane.
>> >> >
>> >> > So it would be useful for us to know exactly where the
>> debate occurred,
>> >> > since we were not aware of it.
>> >> > (As far as the WG is concerned,  the draft was approved such a while
>> >> > back that it has been a completed item for over
>> one-and-a-half years.)
>> >> >
>> >> > At the last discussion on it in Sept. 2003, we were told
>> that the only
>> >> > reason it had got delayed was because it somehow missed being
>> >> sent to the
>> >> > ADs on time.
>> >> >
>> >> > -Vishal
>> >> >
>> >> > > -----Original Message-----
>> >> > > From: [e-mail] [mailto:[e-mail]]On
>> >> > > Behalf Of Adrian Farrel
>> >> > > Sent: Saturday, March 06, 2004 3:11 PM
>> >> > > To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> >> > > Cc: [e-mail]; Alexey Zinin
>> >> > > Subject: Re: AD-review comments on
>> draft-ietf-ccamp-sdhsonet-control
>> >> > >
>> >> > >
>> >> > > Vishal,
>> >> > >
>> >> > > The process is that the WG hands the draft off to the AD to take
>> >> > > it to the IESG. At this
>> >> > > point the AD performs a review before taking the draft to the
>> >> > > IESG and this is what we are
>> >> > > seeing the results of.
>> >> > >
>> >> > > Note that this particular draft has been under "AD watch" for a
>> >> > > while. Alex may want to
>> >> > > clarify the reason for this, but my understanding is that there
>> >> > > was some debate as to
>> >> > > whether the draft had served its purpose already (that is, as a
>> >> > > design document for the
>> >> > > other drafts on SONET/SDH) or whether it should continue and
>> >> > > become an RFC. This review is
>> >> > > the next step towards becoming an RFC.
>> >> > >
>> >> > > Cheers,
>> >> > > Adrian
>> >> > >
>> >> > > ----- Original Message -----
>> >> > > From: "Vishal Sharma" <[e-mail]>
>> >> > > To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
>> >> > > <[e-mail]>;
>> >> > > "Eric Mannie" <[e-mail]>
>> >> > > Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>
>> >> > > Sent: Saturday, March 06, 2004 8:41 PM
>> >> > > Subject: RE: AD-review comments on
>> draft-ietf-ccamp-sdhsonet-control
>> >> > >
>> >> > >
>> >> > > > Adrian et al,
>> >> > > >
>> >> > > > We will work on the document and make the appropriate
>> modifications
>> >> > > > to incorporate the comments.
>> >> > > >
>> >> > > > BTW, Alex could you please clarify whether this is an IESG review
>> >> > > > or some other review?
>> >> > > >
>> >> > > > Our understanding after the last communication with
>> Kireeti on this
>> >> > > > subject, sometime
>> >> > > > in July last year, was that this draft (after having
>> passed several
>> >> > > > last calls), was being sent to the IESG for completing
>> the process
>> >> > > > of advancing to informational RFC.
>> >> > > >
>> >> > > > Thanks,
>> >> > > > -Vishal
>> >> > > >
>> >> > > > > -----Original Message-----
>> >> > > > > From: Adrian Farrel [mailto:[e-mail]]
>> >> > > > > Sent: Saturday, March 06, 2004 4:16 AM
>> >> > > > > To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
>> >> > > > > Cc: [e-mail]
>> >> > > > > Subject: Re: AD-review comments on
>> >> draft-ietf-ccamp-sdhsonet-control
>> >> > > > >
>> >> > > > >
>> >> > > > > Greg, Eric, Vishal,
>> >> > > > > Are you willing and able to pick this draft up again
>> and make the
>> >> > > > > changes from Alex?
>> >> > > > >
>> >> > > > > Thanks,
>> >> > > > > Adrian
>> >> > > > >
>> >> > > > > ----- Original Message -----
>> >> > > > > From: "Alex Zinin" <[e-mail]>
>> >> > > > > To: <[e-mail]>
>> >> > > > > Cc: <[e-mail]>
>> >> > > > > Sent: Thursday, March 04, 2004 12:48 PM
>> >> > > > > Subject: AD-review comments on
>> draft-ietf-ccamp-sdhsonet-control
>> >> > > > >
>> >> > > > >
>> >> > > > > > Folks-
>> >> > > > > >
>> >> > > > > >  Please find below comments from the RTG area directorate
>> >> > > that I would
>> >> > > > > >  like the WG to consider.
>> >> > > > > >
>> >> > > > > >  Thank you.
>> >> > > > > >
>> >> > > > > > --
>> >> > > > > > Alex Zinin
>> >> > > > > >
>> >> > > > > > Technical:
>> >> > > > > > ----------
>> >> > > > > >
>> >> > > > > > Section 3.2:
>> >> > > > > >
>> >> > > > > > 1. Figure 1 misses the STM-0 branch
>> >> > > > > >
>> >> > > > > > Section 3.4.3:
>> >> > > > > >
>> >> > > > > > 2. In comparison table, PNNI word appears for the first
>> >> time in this
>> >> > > > > >     document, any specific reason to mention PNNI in a
>> >> > > GMPLS context ?
>> >> > > > > >
>> >> > > > > > Section 3.5
>> >> > > > > >
>> >> > > > > > 3. "New simplified encapsulations could reduce this
>> >> > > overhead to as low
>> >> > > > > >     as 3%, but the gain is not huge compared to SDH
>> and SONET,
>> >> > > > > which have
>> >> > > > > >     other benefits as well.)" any reference available
>> >> for these new
>> >> > > > > >     simplified encapsulation(s) ?
>> >> > > > > >
>> >> > > > > > 4. "Any encapsulation of IP over WDM should at least
>> >> provide error
>> >> > > > > >     monitoring capabilities (to detect signal
>> >> degradation), error
>> >> > > > > >     correction capabilities, such as FEC (Forward Error
>> >> > > Correction) that
>> >> > > > > >     are particularly needed for ultra long haul
>> >> > > transmission, sufficient
>> >> > > > > >     timing information, to allow robust synchronization
>> >> (that is, to
>> >> > > > > >     detect the beginning of a packet), and capacity
>> to transport
>> >> > > > > >     signaling, routing and management messages, in order to
>> >> > > control the
>> >> > > > > >     optical switches."
>> >> > > > > >
>> >> > > > > >     The first part refers to data plane capabilities,
>> >> however the
>> >> > > > > >     requirement: the "encapsulation of IP over WDM"
>> >> should deliver
>> >> > > > > >     the capacity to transport IP based control plane
>> >> information -
>> >> > > > > >     why is this the case ? an out of band network would
>> >> also do the
>> >> > > > > >     job and this statement makes thus the implicit
>> >> assumption that
>> >> > > > > >     data and control plane topology is congruent
>> >> > > > > >
>> >> > > > > > Section 6:
>> >> > > > > >
>> >> > > > > > 5. "Due to the increase in information transferred in
>> >> the routing
>> >> > > > > >     protocol, it may be useful to separate the
>> relatively static
>> >> > > > > >     parameters concerning a link from those that may be
>> >> subject to
>> >> > > > > >     frequent changes. The current GMPLS routing extensions
>> >> > > [12],[13],
>> >> > > > > >     [14] do not make such a separation, however."
>> >> > > > > >
>> >> > > > > >    it may be thus worth asking the question was the
>> >> dissemination
>> >> > > > > >    of these quasi-static "link capabilities" using the
>> >> same rules
>> >> > > > > >    as for any other TE LSA Type 1 sub-TLV the right
>> approach ?
>> >> > > > > >
>> >> > > > > > Section 6.1:
>> >> > > > > >
>> >> > > > > > 6. what does the following sentence brings in the scope of
>> >> > > this control
>> >> > > > > >     plane framework (and this is even not necessarily true
>> >> > > when vcat is
>> >> > > > > >     provided over different line cards):
>> >> > > > > >
>> >> > > > > >     "Note that this inverse multiplexing process can be
>> >> > > significantly
>> >> > > > > >     easier to implement with SONET/SDH signals rather
>> >> than packets."
>> >> > > > > >
>> >> > > > > > Section 6.3:
>> >> > > > > >
>> >> > > > > > 7. "However, if only standard concatenation is supported
>> >> > > then reporting
>> >> > > > > >     gets trickier since there are constraints on where the
>> >> > > STS-1s can be
>> >> > > > > >     placed. SDH has still more options and constraints,
>> >> > > hence it is not
>> >> > > > > >     yet clear which is the best way to advertise
>> >> bandwidth resource
>> >> > > > > >     availability/usage in SONET/SDH. At present, the
>> >> GMPLS routing
>> >> > > > > >     protocol extensions define minimum and maximum values
>> >> > > for available
>> >> > > > > >     bandwidth, which allows a remote node to make some
>> >> > > deductions about
>> >> > > > > >     the amount of capacity available at a remote link and
>> >> > > the types of
>> >> > > > > >     signals it can accommodate. However, due to the
>> >> > > multiplexed nature
>> >> > > > > >     of the signals, the authors are of the opinion that
>> >> reporting of
>> >> > > > > >     bandwidth particular to signal types rather than
>> as a single
>> >> > > > > >     aggregate bit rate is probably very desirable."
>> >> > > > > >
>> >> > > > > >     -> the authors do not explain from which perspective
>> >> > > and the reasons
>> >> > > > > >     this particular bw accounting report is desirable
>> >> > > (sections 2.4.3 &
>> >> > > > > >     2.4.8 of GMPLS routing explains how these values are
>> >> > > used to take
>> >> > > > > >     into account the multiplexing capability of a SONET/SDH
>> >> > > interface),
>> >> > > > > >     there is no real determination of the missing
>> >> > > information at remote
>> >> > > > > >     nodes for the establishment of an LSP with a certain
>> >> > > amount of bw
>> >> > > > > >     (note that it is not an issue of flexible vs standard
>> >> > > concatenation
>> >> > > > > >     issue but a control plane issue)
>> >> > > > > >
>> >> > > > > > Section 7.3:
>> >> > > > > >
>> >> > > > > > 8. "This information is specified in three parts [17],
>> >> each of which
>> >> > > > > >     refers to a different network layer."
>> >> > > > > >
>> >> > > > > > The description of the signaling elements shall mention the
>> >> > > following:
>> >> > > > > > (section 7.3 refers to [17] but the latter does not
>> >> > > correspond to the
>> >> > > > > > description given in this section)
>> >> > > > > >
>> >> > > > > >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
>> >> > > > > >      which contains three parts: LSP Encoding Type, Switching
>> >> > > > > Type, G-PID
>> >> > > > > >
>> >> > > > > >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
>> >> > > > > SENDER_TSPEC/FLOWSPEC
>> >> > > > > >      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT,
>> >> > > > > Transparency,
>> >> > > > > >      Profile
>> >> > > > > >
>> >> > > > > >   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
>> >> > > > > >
>> >> > > > > >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object
>> >> (as [RFC3473])
>> >> > > > > >
>> >> > > > > > ----
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > Editorial:
>> >> > > > > > ----------
>> >> > > > > >
>> >> > > > > > Section 3:
>> >> > > > > >
>> >> > > > > > 1. Sometimes this document refers to GMPLS other to MPLS and
>> >> > > > > >     sometimes as above as "extending IP technology"
>> >> > > > > >
>> >> > > > > > Section 3.1
>> >> > > > > >
>> >> > > > > > 2. "When a packet reaches a core packet LSR, this LSR uses
>> >> > > the label as
>> >> > > > > >     an index into a forwarding table to determine the next
>> >> > > hop and the
>> >> > > > > >     corresponding outgoing label (and, possibly, the QoS
>> >> > > treatment to be
>> >> > > > > >     given to the packet), writes the new label into the
>> >> packet, and
>> >> > > > > >     forwards the packet to the next hop. "
>> >> > > > > >
>> >> > > > > > -> replace "core packet LSR" by "packet LSR"
>> >> > > > > >
>> >> > > > > > Section 3.2:
>> >> > > > > >
>> >> > > > > > 3. "SDH and SONET are two TDM standards widely used by
>> >> operators to
>> >> > > > > >     transport and multiplex different tributary signals
>> >> over optical
>> >> > > > > >     links, thus creating a multiplexing structure,
>> >> which we call the
>> >> > > > > >     SDH/SONET multiplex. SDH, which was developed by the
>> >> > > ETSI and later
>> >> > > > > >     standardized by the ITU-T [4], is now used worldwide,
>> >> > > while SONET,
>> >> > > > > >     which was standardized by the ANSI [5], is mainly used
>> >> > > in the US.
>> >> > > > > >     However, these two standards have several similarities,
>> >> > > and to some
>> >> > > > > >     extent SONET can be viewed as a subset of SDH.
>> >> Internetworking
>> >> > > > > >     between the two is possible using gateways.
>> >> > > > > >
>> >> > > > > >     Should be rather as "ITU-T SDH (G.707) includes both
>> >> > > the European
>> >> > > > > >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy
>> >> > > (T1.105)." [...]
>> >> > > > > >     "The ETSI SDH and SONET standards regarding frame
>> >> structures and
>> >> > > > > >     higher order multiplexing are the same. There are
>> >> some regional
>> >> > > > > >     differences on the terminology, on the use of some
>> >> > > overhead bytes,
>> >> > > > > >     and lower order multiplexing. Interworking between
>> >> the two lower
>> >> > > > > >     order hierarchies is possible using gateways."
>> >> > > > > >
>> >> > > > > > Section 3.2
>> >> > > > > >
>> >> > > > > > 4. "In addition, a pointer (in the form of the H1, H2
>> >> and H3 bytes)
>> >> > > > > >     indicates the beginning of the VC/SPE in the payload of
>> >> > > the overall
>> >> > > > > >     STM/SDH frame."
>> >> > > > > >
>> >> > > > > > -> replace "STM/SDH frame" by "STM/STS frame"
>> >> > > > > >
>> >> > > > > > Section 4.1
>> >> > > > > >
>> >> > > > > > 5. "The SONET case is a bit difficult to explain since,
>> >> > > unlike in SDH,
>> >> > > > > >     SPEs in SONET do not have individual names." they are
>> >> > > > > simply referred
>> >> > > > > >     to as VT-N SPE
>> >> > > > > >
>> >> > > > > > Section 6:
>> >> > > > > >
>> >> > > > > > 6. Since this document distinguishes between "optical
>> >> > > networks", TDM,
>> >> > > > > >     and WDM it would advisable to avoid the "optical TDM"
>> >> > > as mentioned
>> >> > > > > >     in the below sentence (it has another meaning
>> than MSn/RSn
>> >> > > > > switching)
>> >> > > > > >
>> >> > > > > > Section 6.1:
>> >> > > > > >
>> >> > > > > > 7. Table 2, misses the equivalence between VC-4 and
>> STS-3c SPE
>> >> > > > > >
>> >> > > > > >  > Section 6.1:
>> >> > > > > >
>> >> > > > > > 8. "Standard and flexible concatenations are network
>> >> services, while
>> >> > > > > >     virtual concatenation is a SONET/SDH end-system
>> >> service recently
>> >> > > > > >     approved by the committee T1 of ANSI and ITU-T." remove
>> >> > > "recently
>> >> > > > > >     approved by the committee T1 of ANSI and ITU-T." and
>> >> > > add the corr.
>> >> > > > > >     reference.
>> >> > > > > >
>> >> > > > > > 9. "In one example of virtual concatenation, two end
>> >> > > systems supporting
>> >> > > > > >     this feature could essentially "inverse multiplex" two
>> >> > > STS-1s into a
>> >> > > > > >     virtual STS-2c for the efficient transport of 100 Mbps
>> >> > > > > Ethernet traffic."
>> >> > > > > >
>> >> > > > > > -> STS-1-2v instead of "virtual STS-2c"
>> >> > > > > >
>> >> > > > > > 10. "Section layer: Preserves all section overhead,
>> >> > > Basically does not
>> >> > > > > >      touch any of the SONET/SDH bits."
>> >> > > > > >
>> >> > > > > > -> replace last part by "Basically does not modify
>> or terminate
>> >> > > > > >     any of the SONET/SDH overhead bits"
>> >> > > > > >
>> >> > > > > >     left column of the table misses the SDH overhead
>> equivalent
>> >> > > > > >
>> >> > > > > > 11. Multiplexing of (?) in the following sentence "To perform
>> >> > > > > >      multiplexing, a SONET network element should be line
>> >> > > terminating."
>> >> > > > > >
>> >> > > > > > Section 6.2:
>> >> > > > > >
>> >> > > > > > 12. In the following "Standardized SONET line level
>> protection
>> >> > > > > techniques
>> >> > > > > >      include: Linear 1+1 and linear 1:N automatic
>> >> > > protection switching
>> >> > > > > >      (APS) and both two-fiber and four-fiber bi-directional
>> >> > > > > line switched
>> >> > > > > >      rings (BLSRs). At the path layer, SONET offers
>> >> > > uni-directional path
>> >> > > > > >      switched ring protection." the same applies to SDH (to
>> >> > > be adapted
>> >> > > > > >      using the corr. terminology)
>> >> > > > > >
>> >> > > > > > Section 7:
>> >> > > > > >
>> >> > > > > > 13. "This VC-4 LSP can, in fact, be established
>> between two non-
>> >> > > > > >      adjacent internal nodes in an SDH network, and later
>> >> > > > > >      advertised by a routing protocol as a new (virtual) link
>> >> > > > > >      called a Forwarding Adjacency (FA)." -> add
>> >> MPLS-HIERARCHY as
>> >> > > > > >      reference
>> >> > > > > >
>> >> > > > > > 14. The following paragraph
>> >> > > > > >      "For instance, the payload of an SDH STM-1 frame
>> >> does not fully
>> >> > > > > >       contain a complete unit of user data. In fact, the
>> >> > > user data is
>> >> > > > > >       contained in a virtual container (VC) that is
>> allowed to
>> >> > > > > float over
>> >> > > > > >       two contiguous frames for synchronization purposes. A
>> >> > > > > pointer in the
>> >> > > > > >       Section Overhead (SOH) indicates the beginning of the
>> >> > > VC in the
>> >> > > > > >       payload." mixes SDH with SONET - pointers in SDH
>> >> in H1/H2/H3
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > >
>> >> >
>> >> >
>> >> >
>>




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 22:33:09 +0000
Date: Thu, 11 Mar 2004 14:31:20 -0800
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: "Greg Bernstein" <[e-mail]>
CC: "'Vishal Sharma'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>,  "'Eric Mannie'" <[e-mail]>, <[e-mail]>, "'Bert Wijnen'" <[e-mail]>
Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greg,

  Regarding a consensus against having this go forward, I'll have to defer
  to the WG chairs. So far I haven't been informed about such thing, on the
  contrary--the fact that the doc has been submitted to me implies there
  should be consensus on it.

-- 
Alex
http://www.psg.com/~zinin/

Wednesday, March 10, 2004, 7:36:19 PM, Greg Bernstein wrote:
> Sounds good Alex. But please advise us if there seems to be a consensus
> against having this go forward.  Eric, Vishal and myself have published
> papers in several IEEE magazines on these topics (though not all this
> info in any one place and definitely not at this level of detail due to
> page count limitations). 

> On the other hand the document is a very nice reference/companion for
> anyone trying to understand this stuff (kind of a prerequisite to making
> it work or using it) and hence very convenient to have it archived at
> the IETF.  But, I still think it could hurt my book sales so on second
> thought.... ;-)

> Greg B.

> Dr. Greg M. Bernstein
> Grotto Networking


> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]] 
> Sent: Wednesday, March 10, 2004 5:38 PM
> To: Vishal Sharma
> Cc: Adrian Farrel; Greg Bernstein; Eric Mannie; [e-mail]; Bert
> Wijnen
> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control

> Vishal,

>   To clarify the process, here's the list of stages a document usually
> goes
>   through:

>   1. WG discussion
>   2. WG Last Call
>   3. AD review (may include directorate       <-- You are here now
>      and expert reviews)
>   4. IETF LC (generally not needed for INFO)
>   5. IESG review
>   6. RFC Editor

>   I received the doc back in Sep 2003 and asked one of the Routing Area
>   directorate members for an expert review, which resulted in a long
> list of
>   comments. We had a long (and admittedly slow) discussion between the
> reviewer,
>   me, and the WG chairs in an attempt to distill it to a set of most
> significant
>   technical comments and editorial suggestions, which is what I brought
> back for
>   consideration by the WG.

>   On a related note: please do not assume that work is done once a
> document has
>   passed the WG LC. It is normal to receive comments from the ADs and
> IESG.

>   Regards.




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 19:44:30 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>
Cc: "Yoshihiko SUEMURA" <[e-mail]>, <[e-mail]>, "Kohei Shiomoto" <[e-mail]>, "Lyndon Y. Ong" <[e-mail]>
Subject: RE: Minimizing misconnections in restoration signaling [Was: (Correct ver.) Avoiding misconnections in restoration signaling]
Date: Thu, 11 Mar 2004 11:42:16 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dimitri,

Thanks for your comments. It will be good to have
the various clarifications and expanded text in the document.

I will be happy to contribute to and/or review the new text
(quite a bit of which should be derivable simply from what I
explained in my earlier emails, and also from the notes below).

A couple of important follow-on comments in-line.

-Vishal

PS: Forgot to put Lyndon on the CC list the last time
around. Sorry Lyndon.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, March 11, 2004 4:53 AM
> To: Vishal Sharma
> Cc: Yoshihiko SUEMURA; [e-mail]; Kohei Shiomoto
> Subject: Re: (Correct ver.) Avoiding misconnections in restoration
> signaling [Was: Protection obj. in restoration signaling]
>
>
> vishal, see in-line:
>
> > In your exchange last month, the following text was proposed as
> > a way of activating the backup path in the 1:1/Shared Mesh case
> > to avoid misconnections:
> >
> > < 02/04/04 Dimitri Papadimitriou wrote:>
> >
> >>by re-reading it was also my understanding when performing the xc
> >>on the resv we got here a transient issue that may appear to be
> >>problematic as the length of the path in terms of number of hops
> >>increases (since the latency increases, the probability to be
> >>impacted by this also increases), so would the following text
> >>address your concern:
> >>
> >>"In certain circumstances, it MAY be desirable to perform the
> >>activation of the secondary LSP in the upstream direction (Resv
> >>trigger message) instead of using the default downstream method.
> >>In this case, and in order to avoid any mis-ordering and any mis-
> >>interpretation between a refresh Resv and a trigger Resv message
> >>at intermediate nodes along the secondary LSP, upon reception of
> >>the Path message, the egress node MAY include the PROTECTION
> >>object in the Resv message. The latter is then processed on a hop
> >>by hop basis to activate the secondary LSP until reaching the
> >>ingress node. The PROTECTION object included in the Path message
> >>MUST be set as specified in Section 8.3 and Section 9.3. The
> >>upstream activation behavior SHOULD be configurable on a local
> >>basis."
> >
> >
> >
> > However, after looking at the exchange in detail (and keeping
> > in mind the hard/soft preemption issue), I believe the
> > text needs to be somewhat more precise.
> >
> > The way it is worded at present (even though it satisfied Yoshihiko),
> > would appear to allow for the possibility of misconnections, just in
> > reverse,
> > as I explain below.
>
> it was assumed as inferred here below (from the
> discussion it was clear, otherwise there would have
> been no reason to do this)
>
> note as this was part of the discussion we had w/
> kohei concerning the detailed procedure - but since
> it seems that additional details are in expected in
> this document adding a paragraph along these lines
> will be done
>
> > The text, as worded, only provides for the activation of the secondary
> > LSP upon receipt of a Resv message for the secondary LSP (which would
> > be identified by the inclusion of the PROTECTION obj). However, it
> > makes an implicit assumption that the state for the extra-LSP, in both
> > the _control and the data_ plane, is brought down during the
> transmission
> > of the Path message for the secondary LSP.
> >
> > Given the debates on the hard/soft-preemption issue, it is not clear
> > that the state of the extra-LSP will be brought down upon the receipt
> > of the Path message for the secondary LSP. If that is not
> > the case, then a misconnection happens as follows.
> >
> >    A-----------B
> >     \         /
> >      C-------D
> >     /         \
> >    E           F
> >
> > A-B:     Primary LSP
> > A-C-D-B: Secondary LSP
> > E-C-D-F: Extra (preemptable) LSP
> >
> >
> > Node D, upon receipt of the Resv for the secondary LSP, brings
> down state
> > for the extra-LSP, and activates its cross-connect to switch from C-D ->
> > D-F to C-D -> D-B. However, since node C may not have done so, one again
> > has a misconnection with traffic flowing from E to B, instead of A to B.
> >
> >
> > So, it would be useful to have some text that makes explicit that
> > an intermediate node along the route of a secondary LSP must remove
> > the state, in the control and data planes, associated with the extra-LSP
> > (that uses resources required by the secondary LSP) before forwarding
> > the Path message for the secondary LSP.
>
> a paragraph along the above lines will be added
>
> > A few more editorial comments:
> >
> > i) If the text is under 1:1/Shared Mesh, why "under certain
> circumstances"
> > Haven't we established that the behavior suggested by Yoshihiko
> is needed
> > under _all_ circumstances.
>
> because it is a trade-off between recovery speed
> (also, nothing says that an operator must use the
> spare capacity) and resource efficiency usage -
> and there no reason to mandate one behaviour or
> another -

Let me see if I can elucidate a bit what you are saying.

-- You are arguing that even if spare capacity is in use (in
the shared mesh recovery case), the carrier/operator may _still_,
for faster recovery speed, choose to trade-off the possibility of
some amount of misconnection for recovery speed.

(Note the operator may choose to do something similar in the ordinary
pre-emption case as well (where recovery is not involved), but this is
something we need to look at when we work on the larger pre-emption
context brought up by Kohei.)

And so, there is no necessity to mandate that in the case where
spare capacity is in use the secondary LSP always be activated
in the upstream direction. It is an operator decision.

Ok, I can see that, and could agree with this line of reasoning.

-- You are also arguing that some resource efficiencies may
also be derived by the carrier, if they operate the network
as described above.

I am not sure I see this quite so clearly, but for the
purpose of this email, I'll take your word for it.

In any case, since in the 1:1/shared mesh case with extra traffic
misconnections can happen (even in the simplest cases), as
Yoshihiko's (and my) examples have illustrated, I think
that it is critical here to specify the behavior that one can
expect, even for an operator. (Kohei is an operator :-).)

What the text needs to do then, is to state what those
"certain circumstances" are under which misconnections can happen, and
specify what an operator could do to limit them (since they
cannot, as my related email
(http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00230.html)
showed, be always eliminated/avoided).

It seems that the circumstances in question are simply "usage of the
spare (secondary LSP) capacity by extra traffic LSPs."

If there are other circumstances, it is probably worth thinking
about them, and listing them also. Or, failing that, at least stating
that "In certain circumstances, such as when the spare
capacity is in use by extra traffic, it MAY be ..."

In addition, some explanatory text should also be put in the document
discussing exactly what we have discussed above.

> cf. our previous discussion where you
> are doing the policing for the operator instead
> of defining the set of tools it can use

Unsure of which prior discussion you are referring to
here. Regardless, I do not think that if the document states
what we discussed above, and adds the corresponding explanatory
text, it would be mandating anything for the operator.

It would simply specify the way in which an operator could
minimize misconnections for the 1:1/Shared Mesh (with usage of
spare capacity) case, and ways in which the operator could
make recovery speed and resource efficiency trade-off decisions.

> now of example of circumstances can be further
> detailed as long as they are not constraining

Not sure I copy this ... Could you explain and/or
rephrase?

> > ii) The phrase
> >
> >>"and in order to avoid any mis-ordering and any mis-
> >>interpretation between a refresh Resv and a trigger Resv message
> >>at intermediate nodes along the secondary LSP, upon reception of
> >>the Path message, the egress node MAY include the PROTECTION
> >>object in the Resv message.
> >
> >
> > is unduly long and complicated. It should be broken up into smaller
> > sentences. Moreover, it is not always clear what
> > "refresh Resv" and "trigger Resv" refer to. Isn't a "refresh Resv"
> > a Resv corresponding to the Extra LSP and a "trigger Resv" a
> > Resv corresponding to the Secondary LSP?
>
> will clarify,
>
> thanks,
> - dimitri.
>
> > Thanks,
> > -Vishal

<snipped>




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 19:30:39 +0000
Message-ID: <[e-mail]>
From: "David Allan" <[e-mail]>
To: "'Thomas D. Nadeau'" <[e-mail]>, "'Ronald Bonica'" <[e-mail]>, [e-mail]
Subject: RE: GTTP and LSP PING
Date: Thu, 11 Mar 2004 14:29:11 -0500

Tom/Ron:

I think there is a key delta in that I'm not sure that LSP-PING locates
lower MPLS tunnel ingresses directly (even beyond the requirement to find
other tunnels), in the section 4 processing rules, there is no return code
to indicate a PUSH operation (tunnel ingress). In theory when there is
uniform mode TTL copying, LSP-PING incrementally invoked by GTTP should
simply trace out everything in MPLS at the current level and below which
mitigates this somewhat. BTW The push part should be addressed in LSP-PING
regardless of the interaction with GTTP.... that piece COULD be extended to
indicate an ingress to a non MPLS tunnel which GTTP could then choose to use
independently of LSP-PING.

I don't think having PING trigger GTTP operations is tractable as the GTTP
third party trace paradigm and LSP-PING don;t fit. Nominally in the third
party model, each TTL permutation and each level would be originated by the
third party node. It would be best to preserve this and simply have PING
indicate to GTTP originator the ingress to the non-MPLS lower level and let
GTTP deal with it directly.

cheers
Dave



> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[e-mail]]
> Sent: Monday, March 08, 2004 12:51 PM
> To: 'Ronald Bonica'; [e-mail]
> Subject: RE: GTTP and LSP PING
> 
> 
> 
> 
> ] -----Original Message-----
> ] From: [e-mail]
> ] [mailto:[e-mail]] On Behalf Of Ronald 
> Bonica ] Sent: Saturday, March 06, 2004 12:43 PM ] To: 
> [e-mail] ] Subject: GTTP and LSP PING ] 
> ] 
> ] Folks,
> ] 
> ] At IETF 59, an issue regarding the relationship of GTTP to 
> ] LSP PING was raised and redirected toward the list. I am 
> ] posting this message in order to initiate discussion.
> ] 
> ] One might argue that GTTP should invoke LSP PING when tracing 
> ] though an MPLS LSP. (In fact, previous versions of the GTTP 
> ] draft stated that GTTP would invoke LSP PING.) I'm not sure 
> ] that this is a good idea.
> 
> 	Can you ellaborate why?
> 
> ] GTTP has a requirement to trace through multiple levels of
> ] heterogenous tunnels. For example, GTTP might be required to 
> ] discover IP over MPLS over IP. If GTTP were to invoke LSP 
> ] PING to discover LSP details, I fear that it would miss the 
> ] IP tunnel at the bottom of the stack.
> 
> 	That is an issue, as LSP ping/trace doesn't
> work for IP as far as I understand. One idea is that it
> may be possible that LSP ping/trace could invoke IP trace/ping 
> recursively.
> 
> 	--Tom
> 
> 
> 
> ] This assumption could be wrong. Comments?
> ]
> ] ----------------
> ] Ronald P. Bonica
> ] ----------------
> ] Sometimes the easiest way to 
> ] start a dialog is to start talking.
> 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 17:21:33 +0000
From: "Greg Bernstein" <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, "'Vishal Sharma'" <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, "'Eric Mannie'" <[e-mail]>, <[e-mail]>, "'Bert Wijnen'" <[e-mail]>
Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Wed, 10 Mar 2004 19:36:19 -0800
Message-ID: <000601c4071a$04c46360$6400a8c0@DADSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sounds good Alex. But please advise us if there seems to be a consensus
against having this go forward.  Eric, Vishal and myself have published
papers in several IEEE magazines on these topics (though not all this
info in any one place and definitely not at this level of detail due to
page count limitations).

On the other hand the document is a very nice reference/companion for
anyone trying to understand this stuff (kind of a prerequisite to making
it work or using it) and hence very convenient to have it archived at
the IETF.  But, I still think it could hurt my book sales so on second
thought.... ;-)

Greg B.

Dr. Greg M. Bernstein
Grotto Networking


-----Original Message-----
From: Alex Zinin [mailto:[e-mail]]
Sent: Wednesday, March 10, 2004 5:38 PM
To: Vishal Sharma
Cc: Adrian Farrel; Greg Bernstein; Eric Mannie; [e-mail]; Bert
Wijnen
Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control

Vishal,

  To clarify the process, here's the list of stages a document usually
goes
  through:

  1. WG discussion
  2. WG Last Call
  3. AD review (may include directorate       <-- You are here now
     and expert reviews)
  4. IETF LC (generally not needed for INFO)
  5. IESG review
  6. RFC Editor

  I received the doc back in Sep 2003 and asked one of the Routing Area
  directorate members for an expert review, which resulted in a long
list of
  comments. We had a long (and admittedly slow) discussion between the
reviewer,
  me, and the WG chairs in an attempt to distill it to a set of most
significant
  technical comments and editorial suggestions, which is what I brought
back for
  consideration by the WG.

  On a related note: please do not assume that work is done once a
document has
  passed the WG LC. It is normal to receive comments from the ADs and
IESG.

  Regards.

-- 
Alex
http://www.psg.com/~zinin/

Sunday, March 7, 2004, 1:41:10 PM, Vishal Sharma wrote:
> Adrian,

> I am still very confused about what the debate is about at this point.
> In any case, I would like to defer to my co-authors on this matter.

> As for the enhancements/edits, I think we already stated that we
> could do those.

> -Vishal

>> -----Original Message-----
>> From: Adrian Farrel [mailto:[e-mail]]
>> Sent: Sunday, March 07, 2004 3:24 AM
>> To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> Cc: [e-mail]; Alexey Zinin; Bert Wijnen
>> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>>
>>
>> Thanks for your thoughts Vishal.
>>
>> The debate occurs now.
>>
>> Are the current authors willing and able to make the changes
>> requested by the AD?
>>
>> Thanks,
>> Adrian
>> ----- Original Message -----
>> From: "Vishal Sharma" <[e-mail]>
>> To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
>> <[e-mail]>;
>> "Eric Mannie" <[e-mail]>
>> Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>; "Bert
Wijnen"
>> <[e-mail]>
>> Sent: Sunday, March 07, 2004 12:48 AM
>> Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>>
>>
>> > Adrian,
>> >
>> > Thanks for the clarification. Our (the authors) understanding is
>> > that the draft had passed (quite a while back, in May 2002
>> > actually, after we had addressed the very last round of comments
from
>> > Kireeti), all of the processes in the WG needed to advance it to
>> > informational RFC.
>> >
>> > Its purpose is really to provide an overall view and framework for
>> > SDH/SONET control using an IP/MPLS control plane.
>> >
>> > So it would be useful for us to know exactly where the debate
occurred,
>> > since we were not aware of it.
>> > (As far as the WG is concerned,  the draft was approved such a
while
>> > back that it has been a completed item for over one-and-a-half
years.)
>> >
>> > At the last discussion on it in Sept. 2003, we were told that the
only
>> > reason it had got delayed was because it somehow missed being
>> sent to the
>> > ADs on time.
>> >
>> > -Vishal
>> >
>> > > -----Original Message-----
>> > > From: [e-mail]
[mailto:[e-mail]]On
>> > > Behalf Of Adrian Farrel
>> > > Sent: Saturday, March 06, 2004 3:11 PM
>> > > To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> > > Cc: [e-mail]; Alexey Zinin
>> > > Subject: Re: AD-review comments on
draft-ietf-ccamp-sdhsonet-control
>> > >
>> > >
>> > > Vishal,
>> > >
>> > > The process is that the WG hands the draft off to the AD to take
>> > > it to the IESG. At this
>> > > point the AD performs a review before taking the draft to the
>> > > IESG and this is what we are
>> > > seeing the results of.
>> > >
>> > > Note that this particular draft has been under "AD watch" for a
>> > > while. Alex may want to
>> > > clarify the reason for this, but my understanding is that there
>> > > was some debate as to
>> > > whether the draft had served its purpose already (that is, as a
>> > > design document for the
>> > > other drafts on SONET/SDH) or whether it should continue and
>> > > become an RFC. This review is
>> > > the next step towards becoming an RFC.
>> > >
>> > > Cheers,
>> > > Adrian
>> > >
>> > > ----- Original Message -----
>> > > From: "Vishal Sharma" <[e-mail]>
>> > > To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
>> > > <[e-mail]>;
>> > > "Eric Mannie" <[e-mail]>
>> > > Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>
>> > > Sent: Saturday, March 06, 2004 8:41 PM
>> > > Subject: RE: AD-review comments on
draft-ietf-ccamp-sdhsonet-control
>> > >
>> > >
>> > > > Adrian et al,
>> > > >
>> > > > We will work on the document and make the appropriate
modifications
>> > > > to incorporate the comments.
>> > > >
>> > > > BTW, Alex could you please clarify whether this is an IESG
review
>> > > > or some other review?
>> > > >
>> > > > Our understanding after the last communication with Kireeti on
this
>> > > > subject, sometime
>> > > > in July last year, was that this draft (after having passed
several
>> > > > last calls), was being sent to the IESG for completing the
process
>> > > > of advancing to informational RFC.
>> > > >
>> > > > Thanks,
>> > > > -Vishal
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: Adrian Farrel [mailto:[e-mail]]
>> > > > > Sent: Saturday, March 06, 2004 4:16 AM
>> > > > > To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
>> > > > > Cc: [e-mail]
>> > > > > Subject: Re: AD-review comments on
>> draft-ietf-ccamp-sdhsonet-control
>> > > > >
>> > > > >
>> > > > > Greg, Eric, Vishal,
>> > > > > Are you willing and able to pick this draft up again and make
the
>> > > > > changes from Alex?
>> > > > >
>> > > > > Thanks,
>> > > > > Adrian
>> > > > >
>> > > > > ----- Original Message -----
>> > > > > From: "Alex Zinin" <[e-mail]>
>> > > > > To: <[e-mail]>
>> > > > > Cc: <[e-mail]>
>> > > > > Sent: Thursday, March 04, 2004 12:48 PM
>> > > > > Subject: AD-review comments on
draft-ietf-ccamp-sdhsonet-control
>> > > > >
>> > > > >
>> > > > > > Folks-
>> > > > > >
>> > > > > >  Please find below comments from the RTG area directorate
>> > > that I would
>> > > > > >  like the WG to consider.
>> > > > > >
>> > > > > >  Thank you.
>> > > > > >
>> > > > > > --
>> > > > > > Alex Zinin
>> > > > > >
>> > > > > > Technical:
>> > > > > > ----------
>> > > > > >
>> > > > > > Section 3.2:
>> > > > > >
>> > > > > > 1. Figure 1 misses the STM-0 branch
>> > > > > >
>> > > > > > Section 3.4.3:
>> > > > > >
>> > > > > > 2. In comparison table, PNNI word appears for the first
>> time in this
>> > > > > >     document, any specific reason to mention PNNI in a
>> > > GMPLS context ?
>> > > > > >
>> > > > > > Section 3.5
>> > > > > >
>> > > > > > 3. "New simplified encapsulations could reduce this
>> > > overhead to as low
>> > > > > >     as 3%, but the gain is not huge compared to SDH and
SONET,
>> > > > > which have
>> > > > > >     other benefits as well.)" any reference available
>> for these new
>> > > > > >     simplified encapsulation(s) ?
>> > > > > >
>> > > > > > 4. "Any encapsulation of IP over WDM should at least
>> provide error
>> > > > > >     monitoring capabilities (to detect signal
>> degradation), error
>> > > > > >     correction capabilities, such as FEC (Forward Error
>> > > Correction) that
>> > > > > >     are particularly needed for ultra long haul
>> > > transmission, sufficient
>> > > > > >     timing information, to allow robust synchronization
>> (that is, to
>> > > > > >     detect the beginning of a packet), and capacity to
transport
>> > > > > >     signaling, routing and management messages, in order to
>> > > control the
>> > > > > >     optical switches."
>> > > > > >
>> > > > > >     The first part refers to data plane capabilities,
>> however the
>> > > > > >     requirement: the "encapsulation of IP over WDM"
>> should deliver
>> > > > > >     the capacity to transport IP based control plane
>> information -
>> > > > > >     why is this the case ? an out of band network would
>> also do the
>> > > > > >     job and this statement makes thus the implicit
>> assumption that
>> > > > > >     data and control plane topology is congruent
>> > > > > >
>> > > > > > Section 6:
>> > > > > >
>> > > > > > 5. "Due to the increase in information transferred in
>> the routing
>> > > > > >     protocol, it may be useful to separate the relatively
static
>> > > > > >     parameters concerning a link from those that may be
>> subject to
>> > > > > >     frequent changes. The current GMPLS routing extensions
>> > > [12],[13],
>> > > > > >     [14] do not make such a separation, however."
>> > > > > >
>> > > > > >    it may be thus worth asking the question was the
>> dissemination
>> > > > > >    of these quasi-static "link capabilities" using the
>> same rules
>> > > > > >    as for any other TE LSA Type 1 sub-TLV the right
approach ?
>> > > > > >
>> > > > > > Section 6.1:
>> > > > > >
>> > > > > > 6. what does the following sentence brings in the scope of
>> > > this control
>> > > > > >     plane framework (and this is even not necessarily true
>> > > when vcat is
>> > > > > >     provided over different line cards):
>> > > > > >
>> > > > > >     "Note that this inverse multiplexing process can be
>> > > significantly
>> > > > > >     easier to implement with SONET/SDH signals rather
>> than packets."
>> > > > > >
>> > > > > > Section 6.3:
>> > > > > >
>> > > > > > 7. "However, if only standard concatenation is supported
>> > > then reporting
>> > > > > >     gets trickier since there are constraints on where the
>> > > STS-1s can be
>> > > > > >     placed. SDH has still more options and constraints,
>> > > hence it is not
>> > > > > >     yet clear which is the best way to advertise
>> bandwidth resource
>> > > > > >     availability/usage in SONET/SDH. At present, the
>> GMPLS routing
>> > > > > >     protocol extensions define minimum and maximum values
>> > > for available
>> > > > > >     bandwidth, which allows a remote node to make some
>> > > deductions about
>> > > > > >     the amount of capacity available at a remote link and
>> > > the types of
>> > > > > >     signals it can accommodate. However, due to the
>> > > multiplexed nature
>> > > > > >     of the signals, the authors are of the opinion that
>> reporting of
>> > > > > >     bandwidth particular to signal types rather than as a
single
>> > > > > >     aggregate bit rate is probably very desirable."
>> > > > > >
>> > > > > >     -> the authors do not explain from which perspective
>> > > and the reasons
>> > > > > >     this particular bw accounting report is desirable
>> > > (sections 2.4.3 &
>> > > > > >     2.4.8 of GMPLS routing explains how these values are
>> > > used to take
>> > > > > >     into account the multiplexing capability of a SONET/SDH
>> > > interface),
>> > > > > >     there is no real determination of the missing
>> > > information at remote
>> > > > > >     nodes for the establishment of an LSP with a certain
>> > > amount of bw
>> > > > > >     (note that it is not an issue of flexible vs standard
>> > > concatenation
>> > > > > >     issue but a control plane issue)
>> > > > > >
>> > > > > > Section 7.3:
>> > > > > >
>> > > > > > 8. "This information is specified in three parts [17],
>> each of which
>> > > > > >     refers to a different network layer."
>> > > > > >
>> > > > > > The description of the signaling elements shall mention the
>> > > following:
>> > > > > > (section 7.3 refers to [17] but the latter does not
>> > > correspond to the
>> > > > > > description given in this section)
>> > > > > >
>> > > > > >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
>> > > > > >      which contains three parts: LSP Encoding Type,
Switching
>> > > > > Type, G-PID
>> > > > > >
>> > > > > >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
>> > > > > SENDER_TSPEC/FLOWSPEC
>> > > > > >      which contains 6 parts: Signal Type, (RCC,NCC,NVC),
MT,
>> > > > > Transparency,
>> > > > > >      Profile
>> > > > > >
>> > > > > >   3. UPSTREAM_LABEL for Bi-directional LSP's (as
[RFC3471/3])
>> > > > > >
>> > > > > >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object
>> (as [RFC3473])
>> > > > > >
>> > > > > > ----
>> > > > > >
>> > > > > >
>> > > > > > Editorial:
>> > > > > > ----------
>> > > > > >
>> > > > > > Section 3:
>> > > > > >
>> > > > > > 1. Sometimes this document refers to GMPLS other to MPLS
and
>> > > > > >     sometimes as above as "extending IP technology"
>> > > > > >
>> > > > > > Section 3.1
>> > > > > >
>> > > > > > 2. "When a packet reaches a core packet LSR, this LSR uses
>> > > the label as
>> > > > > >     an index into a forwarding table to determine the next
>> > > hop and the
>> > > > > >     corresponding outgoing label (and, possibly, the QoS
>> > > treatment to be
>> > > > > >     given to the packet), writes the new label into the
>> packet, and
>> > > > > >     forwards the packet to the next hop. "
>> > > > > >
>> > > > > > -> replace "core packet LSR" by "packet LSR"
>> > > > > >
>> > > > > > Section 3.2:
>> > > > > >
>> > > > > > 3. "SDH and SONET are two TDM standards widely used by
>> operators to
>> > > > > >     transport and multiplex different tributary signals
>> over optical
>> > > > > >     links, thus creating a multiplexing structure,
>> which we call the
>> > > > > >     SDH/SONET multiplex. SDH, which was developed by the
>> > > ETSI and later
>> > > > > >     standardized by the ITU-T [4], is now used worldwide,
>> > > while SONET,
>> > > > > >     which was standardized by the ANSI [5], is mainly used
>> > > in the US.
>> > > > > >     However, these two standards have several similarities,
>> > > and to some
>> > > > > >     extent SONET can be viewed as a subset of SDH.
>> Internetworking
>> > > > > >     between the two is possible using gateways.
>> > > > > >
>> > > > > >     Should be rather as "ITU-T SDH (G.707) includes both
>> > > the European
>> > > > > >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy
>> > > (T1.105)." [...]
>> > > > > >     "The ETSI SDH and SONET standards regarding frame
>> structures and
>> > > > > >     higher order multiplexing are the same. There are
>> some regional
>> > > > > >     differences on the terminology, on the use of some
>> > > overhead bytes,
>> > > > > >     and lower order multiplexing. Interworking between
>> the two lower
>> > > > > >     order hierarchies is possible using gateways."
>> > > > > >
>> > > > > > Section 3.2
>> > > > > >
>> > > > > > 4. "In addition, a pointer (in the form of the H1, H2
>> and H3 bytes)
>> > > > > >     indicates the beginning of the VC/SPE in the payload of
>> > > the overall
>> > > > > >     STM/SDH frame."
>> > > > > >
>> > > > > > -> replace "STM/SDH frame" by "STM/STS frame"
>> > > > > >
>> > > > > > Section 4.1
>> > > > > >
>> > > > > > 5. "The SONET case is a bit difficult to explain since,
>> > > unlike in SDH,
>> > > > > >     SPEs in SONET do not have individual names." they are
>> > > > > simply referred
>> > > > > >     to as VT-N SPE
>> > > > > >
>> > > > > > Section 6:
>> > > > > >
>> > > > > > 6. Since this document distinguishes between "optical
>> > > networks", TDM,
>> > > > > >     and WDM it would advisable to avoid the "optical TDM"
>> > > as mentioned
>> > > > > >     in the below sentence (it has another meaning than
MSn/RSn
>> > > > > switching)
>> > > > > >
>> > > > > > Section 6.1:
>> > > > > >
>> > > > > > 7. Table 2, misses the equivalence between VC-4 and STS-3c
SPE
>> > > > > >
>> > > > > >  > Section 6.1:
>> > > > > >
>> > > > > > 8. "Standard and flexible concatenations are network
>> services, while
>> > > > > >     virtual concatenation is a SONET/SDH end-system
>> service recently
>> > > > > >     approved by the committee T1 of ANSI and ITU-T." remove
>> > > "recently
>> > > > > >     approved by the committee T1 of ANSI and ITU-T." and
>> > > add the corr.
>> > > > > >     reference.
>> > > > > >
>> > > > > > 9. "In one example of virtual concatenation, two end
>> > > systems supporting
>> > > > > >     this feature could essentially "inverse multiplex" two
>> > > STS-1s into a
>> > > > > >     virtual STS-2c for the efficient transport of 100 Mbps
>> > > > > Ethernet traffic."
>> > > > > >
>> > > > > > -> STS-1-2v instead of "virtual STS-2c"
>> > > > > >
>> > > > > > 10. "Section layer: Preserves all section overhead,
>> > > Basically does not
>> > > > > >      touch any of the SONET/SDH bits."
>> > > > > >
>> > > > > > -> replace last part by "Basically does not modify or
terminate
>> > > > > >     any of the SONET/SDH overhead bits"
>> > > > > >
>> > > > > >     left column of the table misses the SDH overhead
equivalent
>> > > > > >
>> > > > > > 11. Multiplexing of (?) in the following sentence "To
perform
>> > > > > >      multiplexing, a SONET network element should be line
>> > > terminating."
>> > > > > >
>> > > > > > Section 6.2:
>> > > > > >
>> > > > > > 12. In the following "Standardized SONET line level
protection
>> > > > > techniques
>> > > > > >      include: Linear 1+1 and linear 1:N automatic
>> > > protection switching
>> > > > > >      (APS) and both two-fiber and four-fiber bi-directional
>> > > > > line switched
>> > > > > >      rings (BLSRs). At the path layer, SONET offers
>> > > uni-directional path
>> > > > > >      switched ring protection." the same applies to SDH (to
>> > > be adapted
>> > > > > >      using the corr. terminology)
>> > > > > >
>> > > > > > Section 7:
>> > > > > >
>> > > > > > 13. "This VC-4 LSP can, in fact, be established between two
non-
>> > > > > >      adjacent internal nodes in an SDH network, and later
>> > > > > >      advertised by a routing protocol as a new (virtual)
link
>> > > > > >      called a Forwarding Adjacency (FA)." -> add
>> MPLS-HIERARCHY as
>> > > > > >      reference
>> > > > > >
>> > > > > > 14. The following paragraph
>> > > > > >      "For instance, the payload of an SDH STM-1 frame
>> does not fully
>> > > > > >       contain a complete unit of user data. In fact, the
>> > > user data is
>> > > > > >       contained in a virtual container (VC) that is allowed
to
>> > > > > float over
>> > > > > >       two contiguous frames for synchronization purposes. A
>> > > > > pointer in the
>> > > > > >       Section Overhead (SOH) indicates the beginning of the
>> > > VC in the
>> > > > > >       payload." mixes SDH with SONET - pointers in SDH
>> in H1/H2/H3
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > >
>> > > >
>> > > >
>> > >
>> >
>> >
>> >




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 12:55:59 +0000
Message-ID: <[e-mail]>
Date: Thu, 11 Mar 2004 13:53:28 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Vishal Sharma <[e-mail]>
Cc: Yoshihiko SUEMURA <[e-mail]>, [e-mail], Kohei Shiomoto <[e-mail]>
Subject: Re: (Correct ver.) Avoiding misconnections in restoration signaling [Was: Protection obj. in restoration signaling]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

vishal, see in-line:

> In your exchange last month, the following text was proposed as
> a way of activating the backup path in the 1:1/Shared Mesh case
> to avoid misconnections:
> 
> < 02/04/04 Dimitri Papadimitriou wrote:>
> 
>>by re-reading it was also my understanding when performing the xc
>>on the resv we got here a transient issue that may appear to be
>>problematic as the length of the path in terms of number of hops
>>increases (since the latency increases, the probability to be
>>impacted by this also increases), so would the following text
>>address your concern:
>>
>>"In certain circumstances, it MAY be desirable to perform the
>>activation of the secondary LSP in the upstream direction (Resv
>>trigger message) instead of using the default downstream method.
>>In this case, and in order to avoid any mis-ordering and any mis-
>>interpretation between a refresh Resv and a trigger Resv message
>>at intermediate nodes along the secondary LSP, upon reception of
>>the Path message, the egress node MAY include the PROTECTION
>>object in the Resv message. The latter is then processed on a hop
>>by hop basis to activate the secondary LSP until reaching the
>>ingress node. The PROTECTION object included in the Path message
>>MUST be set as specified in Section 8.3 and Section 9.3. The
>>upstream activation behavior SHOULD be configurable on a local
>>basis."
> 
> 
> 
> However, after looking at the exchange in detail (and keeping
> in mind the hard/soft preemption issue), I believe the
> text needs to be somewhat more precise.
> 
> The way it is worded at present (even though it satisfied Yoshihiko),
> would appear to allow for the possibility of misconnections, just in
> reverse,
> as I explain below.

it was assumed as inferred here below (from the
discussion it was clear, otherwise there would have
been no reason to do this)

note as this was part of the discussion we had w/
kohei concerning the detailed procedure - but since
it seems that additional details are in expected in
this document adding a paragraph along these lines
will be done

> The text, as worded, only provides for the activation of the secondary
> LSP upon receipt of a Resv message for the secondary LSP (which would
> be identified by the inclusion of the PROTECTION obj). However, it
> makes an implicit assumption that the state for the extra-LSP, in both
> the _control and the data_ plane, is brought down during the transmission
> of the Path message for the secondary LSP.
> 
> Given the debates on the hard/soft-preemption issue, it is not clear
> that the state of the extra-LSP will be brought down upon the receipt
> of the Path message for the secondary LSP. If that is not
> the case, then a misconnection happens as follows.
> 
>    A-----------B
>     \         /
>      C-------D
>     /         \
>    E           F
> 
> A-B:     Primary LSP
> A-C-D-B: Secondary LSP
> E-C-D-F: Extra (preemptable) LSP
> 
> 
> Node D, upon receipt of the Resv for the secondary LSP, brings down state
> for the extra-LSP, and activates its cross-connect to switch from C-D ->
> D-F to C-D -> D-B. However, since node C may not have done so, one again
> has a misconnection with traffic flowing from E to B, instead of A to B.
> 
> 
> So, it would be useful to have some text that makes explicit that
> an intermediate node along the route of a secondary LSP must remove
> the state, in the control and data planes, associated with the extra-LSP
> (that uses resources required by the secondary LSP) before forwarding
> the Path message for the secondary LSP.

a paragraph along the above lines will be added

> A few more editorial comments:
> 
> i) If the text is under 1:1/Shared Mesh, why "under certain circumstances"
> Haven't we established that the behavior suggested by Yoshihiko is needed
> under _all_ circumstances.

because it is a trade-off between recovery speed
(also, nothing says that an operator must use the
spare capacity) and resource efficiency usage -
and there no reason to mandate one behaviour or
another - cf. our previous discussion where you
are doing the policing for the operator instead
of defining the set of tools it can use

now of example of circumstances can be further
detailed as long as they are not constraining

> ii) The phrase
> 
>>"and in order to avoid any mis-ordering and any mis-
>>interpretation between a refresh Resv and a trigger Resv message
>>at intermediate nodes along the secondary LSP, upon reception of
>>the Path message, the egress node MAY include the PROTECTION
>>object in the Resv message.
> 
> 
> is unduly long and complicated. It should be broken up into smaller
> sentences. Moreover, it is not always clear what
> "refresh Resv" and "trigger Resv" refer to. Isn't a "refresh Resv"
> a Resv corresponding to the Extra LSP and a "trigger Resv" a
> Resv corresponding to the Secondary LSP?

will clarify,

thanks,
- dimitri.

> Thanks,
> -Vishal
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]On
>>Behalf Of [e-mail]
>>Sent: Wednesday, February 04, 2004 5:03 PM
>>To: Yoshihiko SUEMURA; [e-mail]
>>Subject: Re: Protection object in resv message
>>
>>
>>hi, see in-line
>>
>>Yoshihiko SUEMURA wrote:
>>
>>
>>>Hi Dimitri,
>>>
>>>Please see inline.
>>>
>>>On Sun, 01 Feb 2004 15:39:33 +0100,
>>>[e-mail] wrote:
>>>
>>>
>>>
>>>>hi, see in-line
>>>>
>>>>Yoshihiko SUEMURA wrote:
>>>>
>>>>
>>>>>P&R Design Team,
>>>>>
>>>>>In the 1:1/Shared Mesh Restoration described in
>>>>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
>>>>>secondary LSP is done only by a Path message. The Protection object is
>>>>>carried only in a Path message.
>>>>>However, I think a Resv message should also carry the
>>
>>Protection object.
>>
>>>>>Consider the following case.
>>>>>
>>>>>  A-----------B
>>>>>   \         /
>>>>>    C-------D
>>>>>   /         \
>>>>>  E           F
>>>>>
>>>>>A-B:     Primary LSP
>>>>>A-C-D-B: Secondary LSP
>>>>>E-C-D-F: Extra (preemptable) LSP
>>>>>
>>>>>Activating the Secondary LSP using only a Path message may cause
>>>>>unintended connection (A-C-D-F) between the Secondary LSP and the Extra
>>>>>LSP.
>>>>
>>>>here i would agree that there is a condition on the next_hop
>>>>to delete the extra_lsp state before activating the xc for
>>>>the secondary lsp and in order to guarantee this commit of
>>>>the resources activation may be done upon resv reception
>>>>
>>>>also the use of hard preemption before committing this
>>>>operation decreases (if not completely elevates if used
>>>>to commit action when received from D in this example)
>>>>the time occurrence of this transient state:
>>>>
>>>>- PathErr with PAth_State_Removed flag towards E and a PathTear
>>>>  to the destination F
>>>>- or a PathErr with Path_State_Removed flag towards F and a
>>>>  PathTear towards E
>>>>
>>>>therefore there are other faster triggers for this purpose
>>>>the issue being at the end to either perform this operation
>>>>as fast as possible when reaching the last common node,
>>>>or simply delete in downstream direction and commit along
>>>>the upstream direction as said above (there are more complex
>>>>cases where this might be at the end more easy to process)
>>>>
>>>>
>>>>
>>>>>This can be prevented by applying a two-way activation scheme using
>>>>>both Path and Resv messages.
>>>>
>>>>nothing prevent this from the above (the paragraph that
>>>>describes this doesn't say commit at the data plane this
>>>>is left out to the implementation) some clarification in
>>>>the document are certainly needed here
>>>>
>>>>
>>>>
>>>>>You can delete the Extra LSP by the Path
>>>>>message, and activate the Secondary LSP by the Resv message.
>>>>
>>>>you may want to apply this activation scheme, in such a case
>>>>all the nodes would have their extra-traffic lsp deleted
>>>>through the downstream path message
>>>
>>>
>>>Yes. This is what I want to apply. I want to delete all the
>>>extra-traffic LSPs through the downstream Path message, and then,
>>>activate the secondary LSP through the upstream Resv message.
>>>
>>>
>>>
>>>>>However, if the Resv message for activation does not carry the
>>>>>Protection object, it cannot be distinguished from a refresh Resv
>>>>>message. This still causes unintended connection in the following case.
>>>>>
>>>>>(1) At node C, a crossconnect for the Extra LSP is deleted when
>>>>>receiving a Path message.
>>>>>
>>>>>(2) Then, if node C receives a refresh Resv message from D, it
>>
>>sets up a
>>
>>>>>crossconnect for the Secondary LSP because it cannot distinguish the
>>>>>refresh Resv message from a Resv message for activation.
>>>>
>>>>referring to 2961 p12/13 don't see how see this could happen,
>>>>would you clarify, in order to address this point in case, also
>>>>the resv is considered implicitly here as trigger message
>>>
>>>
>>>After (1), node C waits for the upstream Resv message for activating the
>>>secondary LSP. However, it may receive a refresh Resv message (refresh
>>>for a Resv message for PROVISIONING the secondary LSP) from D before
>>>receiving the Resv for activation. Currently, C cannot distinguish it
>>>from the Resv for activation because there is no difference between
>>>their formats. This may trigger C to activate the secondary LSP
>>>unintentionally before the downstream nodes delete their extra-traffic
>>>LSPs.
>>
>>by re-reading it was also my understanding when performing the xc
>>on the resv we got here a transient issue that may appear to be
>>problematic as the length of the path in terms of number of hops
>>increases (since the latency increases, the probability to be
>>impacted by this also increases), so would the following text
>>address your concern:
>>
>>"In certain circumstances, it MAY be desirable to perform the
>>activation of the secondary LSP in the upstream direction (Resv
>>trigger message) instead of using the default downstream method.
>>In this case, and in order to avoid any mis-ordering and any mis-
>>interpretation between a refresh Resv and a trigger Resv message
>>at intermediate nodes along the secondary LSP, upon reception of
>>the Path message, the egress node MAY include the PROTECTION
>>object in the Resv message. The latter is then processed on a hop
>>by hop basis to activate the secondary LSP until reaching the
>>ingress node. The PROTECTION object included in the Path message
>>MUST be set as specified in Section 8.3 and Section 9.3. The
>>upstream activation behavior SHOULD be configurable on a local
>>basis."
>>
>>hope this addresses the concern,
>>thanks,
>>- dimitri.
>>
>>>Thank you,
>>>
>>>Yoshihiko
>>>
>>>
>>>
>>>>>If (2) occurs before D deletes a crossconnect for the Extra LSP, it
>>>>>causes unintended connection between the Secondary LSP and the
>>
>>Extra LSP.
>>
>>>>>As a solution for the above problem, I propose to add the Protection
>>>>>object to a Resv message. The unintended connection can be prevented
>>>>>because you can distinguish a Resv message for activation from
>>
>>a refresh
>>
>>>>>Resv message by watching the S bit.
>>>>
>>>>suggest to first clarify the previous point,
>>>>
>>>>thanks,
>>>>- dimitri.
>>>>
>>>>
>>>>
>>>>>Best regards,
>>>>>
>>>>>Yoshihiko
>>>>>
>>>>>-----------------------------------------------------------------
>>>>>Yoshihiko SUEMURA
>>>>>
>>>>>NEC Corporation
>>>>>E-mail: [e-mail]
>>>>>
>>>>>
>>>>
>>>>--
>>>>Papadimitriou Dimitri
>>>>E-mail : [e-mail]
>>>>E-mail : [e-mail]
>>>>Webpage: http://psg.com/~dpapadimitriou/
>>>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>>>Phone  : [phone]
>>>>
>>>
>>>
>>>
>>>-----------------------------------------------------------------
>>>Yoshihiko SUEMURA
>>>
>>>NEC Corporation
>>>E-mail: [e-mail]
>>>
>>
>>--
>>Papadimitriou Dimitri
>>E-mail : [e-mail]
>>E-mail : [e-mail]
>>Webpage: http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : [phone]
> 
> 
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 11:57:44 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>, "Yoshihiko SUEMURA" <[e-mail]>, <[e-mail]>
Subject: RE:(Correct ver.) Avoiding misconnections in restoration signaling [Was: Protection obj. in restoration signaling]
Date: Thu, 11 Mar 2004 03:56:36 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yoshihiko et al, (Correction at the end)

In your exchange last month, the following text was proposed as
a way of activating the backup path in the 1:1/Shared Mesh case
to avoid misconnections:

< 02/04/04 Dimitri Papadimitriou wrote:>

> by re-reading it was also my understanding when performing the xc
> on the resv we got here a transient issue that may appear to be
> problematic as the length of the path in terms of number of hops
> increases (since the latency increases, the probability to be
> impacted by this also increases), so would the following text
> address your concern:
>
> "In certain circumstances, it MAY be desirable to perform the
> activation of the secondary LSP in the upstream direction (Resv
> trigger message) instead of using the default downstream method.
> In this case, and in order to avoid any mis-ordering and any mis-
> interpretation between a refresh Resv and a trigger Resv message
> at intermediate nodes along the secondary LSP, upon reception of
> the Path message, the egress node MAY include the PROTECTION
> object in the Resv message. The latter is then processed on a hop
> by hop basis to activate the secondary LSP until reaching the
> ingress node. The PROTECTION object included in the Path message
> MUST be set as specified in Section 8.3 and Section 9.3. The
> upstream activation behavior SHOULD be configurable on a local
> basis."


However, after looking at the exchange in detail (and keeping
in mind the hard/soft preemption issue), I believe the
text needs to be somewhat more precise.

The way it is worded at present (even though it satisfied Yoshihiko),
would appear to allow for the possibility of misconnections, just in
reverse,
as I explain below.

The text, as worded, only provides for the activation of the secondary
LSP upon receipt of a Resv message for the secondary LSP (which would
be identified by the inclusion of the PROTECTION obj). However, it
makes an implicit assumption that the state for the extra-LSP, in both
the _control and the data_ plane, is brought down during the transmission
of the Path message for the secondary LSP.

Given the debates on the hard/soft-preemption issue, it is not clear
that the state of the extra-LSP will be brought down upon the receipt
of the Path message for the secondary LSP. If that is not
the case, then a misconnection happens as follows.

   A-----------B
    \         /
     C-------D
    /         \
   E           F

A-B:     Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptable) LSP


Node D, upon receipt of the Resv for the secondary LSP, brings down state
for the extra-LSP, and activates its cross-connect to switch from C-D ->
D-F to C-D -> D-B. However, since node C may not have done so, one again
has a misconnection with traffic flowing from E to B, instead of A to B.


So, it would be useful to have some text that makes explicit that
an intermediate node along the route of a secondary LSP must remove
the state, in the control and data planes, associated with the extra-LSP
(that uses resources required by the secondary LSP) before forwarding
the Path message for the secondary LSP.

A few more editorial comments:

i) If the text is under 1:1/Shared Mesh, why "under certain circumstances"
Haven't we established that the behavior suggested by Yoshihiko is needed
under _all_ circumstances.

ii) The phrase
> "and in order to avoid any mis-ordering and any mis-
> interpretation between a refresh Resv and a trigger Resv message
> at intermediate nodes along the secondary LSP, upon reception of
> the Path message, the egress node MAY include the PROTECTION
> object in the Resv message.

is unduly long and complicated. It should be broken up into smaller
sentences. Moreover, it is not always clear what
"refresh Resv" and "trigger Resv" refer to. Isn't a "refresh Resv"
a Resv corresponding to the Extra LSP and a "trigger Resv" a
Resv corresponding to the Secondary LSP?

Thanks,
-Vishal


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of [e-mail]
> Sent: Wednesday, February 04, 2004 5:03 PM
> To: Yoshihiko SUEMURA; [e-mail]
> Subject: Re: Protection object in resv message
>
>
> hi, see in-line
>
> Yoshihiko SUEMURA wrote:
>
> > Hi Dimitri,
> >
> > Please see inline.
> >
> > On Sun, 01 Feb 2004 15:39:33 +0100,
> > [e-mail] wrote:
> >
> >
> >>hi, see in-line
> >>
> >>Yoshihiko SUEMURA wrote:
> >>
> >>>P&R Design Team,
> >>>
> >>>In the 1:1/Shared Mesh Restoration described in
> >>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
> >>>secondary LSP is done only by a Path message. The Protection object is
> >>>carried only in a Path message.
> >>>However, I think a Resv message should also carry the
> Protection object.
> >>>
> >>>Consider the following case.
> >>>
> >>>   A-----------B
> >>>    \         /
> >>>     C-------D
> >>>    /         \
> >>>   E           F
> >>>
> >>>A-B:     Primary LSP
> >>>A-C-D-B: Secondary LSP
> >>>E-C-D-F: Extra (preemptable) LSP
> >>>
> >>>Activating the Secondary LSP using only a Path message may cause
> >>>unintended connection (A-C-D-F) between the Secondary LSP and the Extra
> >>>LSP.
> >>
> >>here i would agree that there is a condition on the next_hop
> >>to delete the extra_lsp state before activating the xc for
> >>the secondary lsp and in order to guarantee this commit of
> >>the resources activation may be done upon resv reception
> >>
> >>also the use of hard preemption before committing this
> >>operation decreases (if not completely elevates if used
> >>to commit action when received from D in this example)
> >>the time occurrence of this transient state:
> >>
> >>- PathErr with PAth_State_Removed flag towards E and a PathTear
> >>   to the destination F
> >>- or a PathErr with Path_State_Removed flag towards F and a
> >>   PathTear towards E
> >>
> >>therefore there are other faster triggers for this purpose
> >>the issue being at the end to either perform this operation
> >>as fast as possible when reaching the last common node,
> >>or simply delete in downstream direction and commit along
> >>the upstream direction as said above (there are more complex
> >>cases where this might be at the end more easy to process)
> >>
> >>
> >>>This can be prevented by applying a two-way activation scheme using
> >>>both Path and Resv messages.
> >>
> >>nothing prevent this from the above (the paragraph that
> >>describes this doesn't say commit at the data plane this
> >>is left out to the implementation) some clarification in
> >>the document are certainly needed here
> >>
> >>
> >>>You can delete the Extra LSP by the Path
> >>>message, and activate the Secondary LSP by the Resv message.
> >>
> >>you may want to apply this activation scheme, in such a case
> >>all the nodes would have their extra-traffic lsp deleted
> >>through the downstream path message
> >
> >
> > Yes. This is what I want to apply. I want to delete all the
> > extra-traffic LSPs through the downstream Path message, and then,
> > activate the secondary LSP through the upstream Resv message.
> >
> >
> >>>However, if the Resv message for activation does not carry the
> >>>Protection object, it cannot be distinguished from a refresh Resv
> >>>message. This still causes unintended connection in the following case.
> >>>
> >>>(1) At node C, a crossconnect for the Extra LSP is deleted when
> >>>receiving a Path message.
> >>>
> >>>(2) Then, if node C receives a refresh Resv message from D, it
> sets up a
> >>>crossconnect for the Secondary LSP because it cannot distinguish the
> >>>refresh Resv message from a Resv message for activation.
> >>
> >>referring to 2961 p12/13 don't see how see this could happen,
> >>would you clarify, in order to address this point in case, also
> >>the resv is considered implicitly here as trigger message
> >
> >
> > After (1), node C waits for the upstream Resv message for activating the
> > secondary LSP. However, it may receive a refresh Resv message (refresh
> > for a Resv message for PROVISIONING the secondary LSP) from D before
> > receiving the Resv for activation. Currently, C cannot distinguish it
> > from the Resv for activation because there is no difference between
> > their formats. This may trigger C to activate the secondary LSP
> > unintentionally before the downstream nodes delete their extra-traffic
> > LSPs.
>
> by re-reading it was also my understanding when performing the xc
> on the resv we got here a transient issue that may appear to be
> problematic as the length of the path in terms of number of hops
> increases (since the latency increases, the probability to be
> impacted by this also increases), so would the following text
> address your concern:
>
> "In certain circumstances, it MAY be desirable to perform the
> activation of the secondary LSP in the upstream direction (Resv
> trigger message) instead of using the default downstream method.
> In this case, and in order to avoid any mis-ordering and any mis-
> interpretation between a refresh Resv and a trigger Resv message
> at intermediate nodes along the secondary LSP, upon reception of
> the Path message, the egress node MAY include the PROTECTION
> object in the Resv message. The latter is then processed on a hop
> by hop basis to activate the secondary LSP until reaching the
> ingress node. The PROTECTION object included in the Path message
> MUST be set as specified in Section 8.3 and Section 9.3. The
> upstream activation behavior SHOULD be configurable on a local
> basis."
>
> hope this addresses the concern,
> thanks,
> - dimitri.
> > Thank you,
> >
> > Yoshihiko
> >
> >
> >>>If (2) occurs before D deletes a crossconnect for the Extra LSP, it
> >>>causes unintended connection between the Secondary LSP and the
> Extra LSP.
> >>>
> >>>As a solution for the above problem, I propose to add the Protection
> >>>object to a Resv message. The unintended connection can be prevented
> >>>because you can distinguish a Resv message for activation from
> a refresh
> >>>Resv message by watching the S bit.
> >>
> >>suggest to first clarify the previous point,
> >>
> >>thanks,
> >>- dimitri.
> >>
> >>
> >>>Best regards,
> >>>
> >>>Yoshihiko
> >>>
> >>>-----------------------------------------------------------------
> >>>Yoshihiko SUEMURA
> >>>
> >>>NEC Corporation
> >>>E-mail: [e-mail]
> >>>
> >>>
> >>
> >>--
> >>Papadimitriou Dimitri
> >>E-mail : [e-mail]
> >>E-mail : [e-mail]
> >>Webpage: http://psg.com/~dpapadimitriou/
> >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >>Phone  : [phone]
> >>
> >
> >
> >
> > -----------------------------------------------------------------
> > Yoshihiko SUEMURA
> >
> > NEC Corporation
> > E-mail: [e-mail]
> >
>
> --
> Papadimitriou Dimitri
> E-mail : [e-mail]
> E-mail : [e-mail]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : [phone]





Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 11:51:16 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>, "Yoshihiko SUEMURA" <[e-mail]>, <[e-mail]>
Subject: Avoiding misconnections in restoration signaling [Was: Protection obj. in restoration signaling]
Date: Thu, 11 Mar 2004 03:49:39 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yoshihiko et al,

In your exchange last month, the following text was proposed as
a way of activating the backup path in the 1:1/Shared Mesh case
to avoid misconnections:

< 02/04/04 Dimitri Papadimitriou wrote:>

> by re-reading it was also my understanding when performing the xc
> on the resv we got here a transient issue that may appear to be
> problematic as the length of the path in terms of number of hops
> increases (since the latency increases, the probability to be
> impacted by this also increases), so would the following text
> address your concern:
>
> "In certain circumstances, it MAY be desirable to perform the
> activation of the secondary LSP in the upstream direction (Resv
> trigger message) instead of using the default downstream method.
> In this case, and in order to avoid any mis-ordering and any mis-
> interpretation between a refresh Resv and a trigger Resv message
> at intermediate nodes along the secondary LSP, upon reception of
> the Path message, the egress node MAY include the PROTECTION
> object in the Resv message. The latter is then processed on a hop
> by hop basis to activate the secondary LSP until reaching the
> ingress node. The PROTECTION object included in the Path message
> MUST be set as specified in Section 8.3 and Section 9.3. The
> upstream activation behavior SHOULD be configurable on a local
> basis."


However, after looking at the exchange in detail (and keeping
in mind the hard/soft preemption issue), I believe the
text needs to be somewhat more precise.

The way it is worded at present (even though it satisfied Yoshihiko),
would appear to allow for the possibility of misconnections, just in
reverse,
as I explain below.

The text, as worded, only provides for the activation of the secondary
LSP upon receipt of a Resv message for the secondary LSP (which would
be identified by the inclusion of the PROTECTION obj). However, it
makes an implicit assumption that the state for the extra-LSP, in both
the _control and the data_ plane, is brought down during the transmission
of the Path message for the secondary LSP.

Given the debates on the hard/soft-preemption issue, it is not clear
that the state of the extra-LSP will be brought down upon the receipt
of the Path message for the secondary LSP. If that is not
the case, then a misconnection happens as follows.

   A-----------B
    \         /
     C-------D
    /         \
   E           F

A-B:     Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptable) LSP


Node D, upon receipt of the Resv for the secondary LSP, brings down state
for the extra-LSP, and activates its cross-connect to switch from C-D ->
D-F to C-D -> D-B. However, since node C may not have done so, one again
has a misconnection with traffic flowing from E to B, instead of A to B.


So, it would be useful to have some text that makes explicit that
an intermediate node along the route of a secondary LSP must remove
the state, in the control and data planes, associated with the extra-LSP
(that uses resources required by the secondary LSP) before forwarding
the Path message for the secondary LSP.

A few more editorial comments:

i) If the text is under 1:1/Shared Mesh, why "under certain circumstances"
Haven't we established that the behavior suggested by Yoshihiko is needed
under _all_ circumstances.

ii) The phrase
> "and in order to avoid any mis-ordering and any mis-
> interpretation between a refresh Resv and a trigger Resv message
> at intermediate nodes along the secondary LSP, upon reception of
> the Path message, the egress node MAY include the PROTECTION
> object in the Resv message.

is unduly long and complicated. It should be broken up into smaller
sentences. Moreover, it is not always clear what
"refresh Resv" and "trigger Resv" refer to. Isn't a "refresh Resv"
a Resv corresponding to the Extra LSP and a "trigger Resv" a
Resv corresponding to the Extra LSP?

Thanks,
-Vishal


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of [e-mail]
> Sent: Wednesday, February 04, 2004 5:03 PM
> To: Yoshihiko SUEMURA; [e-mail]
> Subject: Re: Protection object in resv message
>
>
> hi, see in-line
>
> Yoshihiko SUEMURA wrote:
>
> > Hi Dimitri,
> >
> > Please see inline.
> >
> > On Sun, 01 Feb 2004 15:39:33 +0100,
> > [e-mail] wrote:
> >
> >
> >>hi, see in-line
> >>
> >>Yoshihiko SUEMURA wrote:
> >>
> >>>P&R Design Team,
> >>>
> >>>In the 1:1/Shared Mesh Restoration described in
> >>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
> >>>secondary LSP is done only by a Path message. The Protection object is
> >>>carried only in a Path message.
> >>>However, I think a Resv message should also carry the
> Protection object.
> >>>
> >>>Consider the following case.
> >>>
> >>>   A-----------B
> >>>    \         /
> >>>     C-------D
> >>>    /         \
> >>>   E           F
> >>>
> >>>A-B:     Primary LSP
> >>>A-C-D-B: Secondary LSP
> >>>E-C-D-F: Extra (preemptable) LSP
> >>>
> >>>Activating the Secondary LSP using only a Path message may cause
> >>>unintended connection (A-C-D-F) between the Secondary LSP and the Extra
> >>>LSP.
> >>
> >>here i would agree that there is a condition on the next_hop
> >>to delete the extra_lsp state before activating the xc for
> >>the secondary lsp and in order to guarantee this commit of
> >>the resources activation may be done upon resv reception
> >>
> >>also the use of hard preemption before committing this
> >>operation decreases (if not completely elevates if used
> >>to commit action when received from D in this example)
> >>the time occurrence of this transient state:
> >>
> >>- PathErr with PAth_State_Removed flag towards E and a PathTear
> >>   to the destination F
> >>- or a PathErr with Path_State_Removed flag towards F and a
> >>   PathTear towards E
> >>
> >>therefore there are other faster triggers for this purpose
> >>the issue being at the end to either perform this operation
> >>as fast as possible when reaching the last common node,
> >>or simply delete in downstream direction and commit along
> >>the upstream direction as said above (there are more complex
> >>cases where this might be at the end more easy to process)
> >>
> >>
> >>>This can be prevented by applying a two-way activation scheme using
> >>>both Path and Resv messages.
> >>
> >>nothing prevent this from the above (the paragraph that
> >>describes this doesn't say commit at the data plane this
> >>is left out to the implementation) some clarification in
> >>the document are certainly needed here
> >>
> >>
> >>>You can delete the Extra LSP by the Path
> >>>message, and activate the Secondary LSP by the Resv message.
> >>
> >>you may want to apply this activation scheme, in such a case
> >>all the nodes would have their extra-traffic lsp deleted
> >>through the downstream path message
> >
> >
> > Yes. This is what I want to apply. I want to delete all the
> > extra-traffic LSPs through the downstream Path message, and then,
> > activate the secondary LSP through the upstream Resv message.
> >
> >
> >>>However, if the Resv message for activation does not carry the
> >>>Protection object, it cannot be distinguished from a refresh Resv
> >>>message. This still causes unintended connection in the following case.
> >>>
> >>>(1) At node C, a crossconnect for the Extra LSP is deleted when
> >>>receiving a Path message.
> >>>
> >>>(2) Then, if node C receives a refresh Resv message from D, it
> sets up a
> >>>crossconnect for the Secondary LSP because it cannot distinguish the
> >>>refresh Resv message from a Resv message for activation.
> >>
> >>referring to 2961 p12/13 don't see how see this could happen,
> >>would you clarify, in order to address this point in case, also
> >>the resv is considered implicitly here as trigger message
> >
> >
> > After (1), node C waits for the upstream Resv message for activating the
> > secondary LSP. However, it may receive a refresh Resv message (refresh
> > for a Resv message for PROVISIONING the secondary LSP) from D before
> > receiving the Resv for activation. Currently, C cannot distinguish it
> > from the Resv for activation because there is no difference between
> > their formats. This may trigger C to activate the secondary LSP
> > unintentionally before the downstream nodes delete their extra-traffic
> > LSPs.
>
> by re-reading it was also my understanding when performing the xc
> on the resv we got here a transient issue that may appear to be
> problematic as the length of the path in terms of number of hops
> increases (since the latency increases, the probability to be
> impacted by this also increases), so would the following text
> address your concern:
>
> "In certain circumstances, it MAY be desirable to perform the
> activation of the secondary LSP in the upstream direction (Resv
> trigger message) instead of using the default downstream method.
> In this case, and in order to avoid any mis-ordering and any mis-
> interpretation between a refresh Resv and a trigger Resv message
> at intermediate nodes along the secondary LSP, upon reception of
> the Path message, the egress node MAY include the PROTECTION
> object in the Resv message. The latter is then processed on a hop
> by hop basis to activate the secondary LSP until reaching the
> ingress node. The PROTECTION object included in the Path message
> MUST be set as specified in Section 8.3 and Section 9.3. The
> upstream activation behavior SHOULD be configurable on a local
> basis."
>
> hope this addresses the concern,
> thanks,
> - dimitri.
> > Thank you,
> >
> > Yoshihiko
> >
> >
> >>>If (2) occurs before D deletes a crossconnect for the Extra LSP, it
> >>>causes unintended connection between the Secondary LSP and the
> Extra LSP.
> >>>
> >>>As a solution for the above problem, I propose to add the Protection
> >>>object to a Resv message. The unintended connection can be prevented
> >>>because you can distinguish a Resv message for activation from
> a refresh
> >>>Resv message by watching the S bit.
> >>
> >>suggest to first clarify the previous point,
> >>
> >>thanks,
> >>- dimitri.
> >>
> >>
> >>>Best regards,
> >>>
> >>>Yoshihiko
> >>>
> >>>-----------------------------------------------------------------
> >>>Yoshihiko SUEMURA
> >>>
> >>>NEC Corporation
> >>>E-mail: [e-mail]
> >>>
> >>>
> >>
> >>--
> >>Papadimitriou Dimitri
> >>E-mail : [e-mail]
> >>E-mail : [e-mail]
> >>Webpage: http://psg.com/~dpapadimitriou/
> >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >>Phone  : [phone]
> >>
> >
> >
> >
> > -----------------------------------------------------------------
> > Yoshihiko SUEMURA
> >
> > NEC Corporation
> > E-mail: [e-mail]
> >
>
> --
> Papadimitriou Dimitri
> E-mail : [e-mail]
> E-mail : [e-mail]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 10:24:51 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Kohei Shiomoto" <[e-mail]>, <[e-mail]>, "Ong, Lyndon" <[e-mail]>, <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: Re: Misconnections during activation of backup LSPs
Date: Thu, 11 Mar 2004 02:23:09 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Kohei et al,

<Kohei Shiomoto wrote:>
> Yes, my concern is misconnection during activation of backup LSP
> procedure originally raised by Yoshihiko (See
> http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00079.html).  Similar
> situation can occur not only for P&R context but also for more general
> context when preemption takes place. Solutions should be explored in
> more general context and several solutions could be developed. I feel
> that the P&R solution document should also address the problem and give
> the solution referring some documents on preemption.

I think Kohei brings up an excellent point.

In fact, it would be good to provide solutions not only to
avoid misconnections, but to also detect and remove them in
a timely manner, since very simple malfunctions can lead to
misconnections (even if all protocols operate as desired).

[Having spent some reasonable time thinking about these issues,
I volunteer to, and will be happy to, provide inputs both to the P&R
solution documents as well as to any subsequent documents on this
issue that we as a WG decide to produce.]

For example, let us consider again Yoshihiro's original example.


   A-----------B
    \         /
     C-------D
    /         \
   E           F

A-B:     Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptable) LSP

Even if we apply Yoshihiro's suggestion of activating the secondary path
upon the receipt of the Resv message, we can _still_ have misconnections
as follows.

If node C deletes state for the extra-LSP in the control plane upon
receipt of the Path message
(which itself requires further clarification
in the documents, as I will point out in a separate email)
but, due to any malfunction whatsoever, fails to alter the cross-connect in
its
data plane (allowing it to still connect E-C to C-D), we will have a
misconnection.

This occurs as soon as node D, upon receiving the Resv for the
secondary from B (with the Protection obj.) correctly changes its
cross-connect
from C-D --> D-F to C-D --> D-B.  This is because traffic will now
(incorrectly) flow from E to B, instead of A to B.

Note that this could _continue indefinitely_ if C's control plane happens to
have gotten disconnected from its data plane (with neither stopping to
work).

Even if not, at the very least, there would be a misconnection
until C receives the Resv message, and then corrects for its previous
mistake, and rectifies its cross-connection in the data plane by changing
it from E-C -> C-D to A-C -> C-D.

Regards,
-Vishal


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Kohei Shiomoto
> Sent: Tuesday, March 09, 2004 5:00 PM
> To: [e-mail]; Ong, Lyndon
> Cc: 'Adrian Farrel'; [e-mail]
> Subject: Re: Opinion sought on drafts being adopted by CCAMP
>
>
> Hi, Dimitri and Lyndon
>
> Yes, my concern is misconnection during activation of backup LSP
> procedure originally raised by Yoshihiko (See
> http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00079.html).  Similar
> situation can occur not only for P&R context but also for more general
> context when preemption takes place. Solutions should be explored in
> more general context and several solutions could be developed. I feel
> that the P&R solution document should also address the problem and give
> the solution referring some documents on preemption.
> I feel that  "rsvp for e2e recovery" draft is ready for WG document.
>
> --
> Kohei Shiomoto
> NTT Network Innovation Laboratories
> 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
> Phone [phone]    Fax [phone]
>
>
>
>
> [e-mail] wrote:
>
> > lyndon:
> >
> >> -- egress control - yes.     The question of what kind of target came
> >> up, BCP, Info, etc -
> >>    Whatever kind of document it winds up being, I think one
> >>    important result should be marking 3473 as being supplemented
> >>    by the new document to avoid any future confusion.
> >>
> >> -- tunnel tracing - yes
> >>
> >> -- rsvp for e2e recovery - there seemed to be still some concerns
> >>    at the meeting, so no (not yet)
> >
> >
> > the concern raised (*) by kohei is the following what are
> > the exact steps happening during preemption of LSPs that
> > are using the spare capacity in dedicated/shared re-routing
> > schemes - however, this concern is broader than simply this
> > document - and there are two solutions either the steps
> > are being detailed in this document or preemption is going
> > to be addressed in a specific document and reference will
> > be provided
> >
> > (*) went to discuss privately since we didn't have the time
> > to discuss this point - kohei please correct me if i am
> > wrong here -
> >
> >> -- segment recovery - no (not yet)
> >>
> >> Cheers,
> >>
> >> Lyndon
> >>
> >> -----Original Message-----
> >> From: Adrian Farrel [mailto:[e-mail]]
> >> Sent: Thursday, March 04, 2004 3:46 AM
> >> To: [e-mail]
> >> Subject: Opinion sought on drafts being adopted by CCAMP
> >>
> >>
> >> All,
> >>
> >> At the CCAMP meeting today we discussed making several drafts working
> >> group items. Can you
> >> please express your opinion (yes/no) on whether each of the following
> >> drafts is ready to
> >> become a CCAMP working group draft.
> >>
> >> Feel free to express yes with reservations. If you have reservations
> >> or objections, please
> >> express them on the list. if you need anonymity for your comments
> >> then please filter them
> >> through the chairs.
> >>
> >> Silence will be taken as meaning nothing, so please say what you think.
> >>
> >> GMPLS Signaling Procedure For Egress Control
> >>
> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-cont
rol-01.txt
>>
>>
>> Generic Tunnel Tracing Protocol (GTTP) Specification
>> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
>>
>> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>>
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sign
aling-03.txt
>>
>>
>> GMPLS Based Segment Recovery
>>
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recover
y-00.txt
>>
>>
>> Thank you,
>> Adrian
>>
>>
>






Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 04:17:03 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Alex Zinin" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Greg Bernstein" <[e-mail]>, "Eric Mannie" <[e-mail]>, <[e-mail]>, "Bert Wijnen" <[e-mail]>
Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Wed, 10 Mar 2004 20:15:10 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Alex,

Thank you for taking the time to clarify the process, and for having
the expert review of our document done.
(I think the suggestions and comments will be very valuable in helping
to further improve the document.)

Looking at your note, I think I understood the stages right, and also
understood correctly that changes/enhancements are normal in stages
3-6 as well.

On the other hand, it is my understanding that the debate surrounding
a document (technical aspects, key content, applicability, etc.) is
completed
in stages 1 and 2. In fact, I understand that passing the final WG LC, is
the point that marks the conclusion of such a debate(s).

Thereafter, we essentially try to work to refine and tighten a document
for eventual publication as an RFC, in the appropriate category
(in this case informational). Hence, my confusion.

Is my understanding not correct?

Regards,
-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Alex Zinin
> Sent: Wednesday, March 10, 2004 5:38 PM
> To: Vishal Sharma
> Cc: Adrian Farrel; Greg Bernstein; Eric Mannie; [e-mail]; Bert
> Wijnen
> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> Vishal,
>
>   To clarify the process, here's the list of stages a document
> usually goes
>   through:
>
>   1. WG discussion
>   2. WG Last Call
>   3. AD review (may include directorate       <-- You are here now
>      and expert reviews)
>   4. IETF LC (generally not needed for INFO)
>   5. IESG review
>   6. RFC Editor
>
>   I received the doc back in Sep 2003 and asked one of the Routing Area
>   directorate members for an expert review, which resulted in a
> long list of
>   comments. We had a long (and admittedly slow) discussion
> between the reviewer,
>   me, and the WG chairs in an attempt to distill it to a set of
> most significant
>   technical comments and editorial suggestions, which is what I
> brought back for
>   consideration by the WG.
>
>   On a related note: please do not assume that work is done once
> a document has
>   passed the WG LC. It is normal to receive comments from the ADs
> and IESG.
>
>   Regards.
>
> --
> Alex
> http://www.psg.com/~zinin/
>
> Sunday, March 7, 2004, 1:41:10 PM, Vishal Sharma wrote:
> > Adrian,
>
> > I am still very confused about what the debate is about at this point.
> > In any case, I would like to defer to my co-authors on this matter.
>
> > As for the enhancements/edits, I think we already stated that we
> > could do those.
>
> > -Vishal
>
> >> -----Original Message-----
> >> From: Adrian Farrel [mailto:[e-mail]]
> >> Sent: Sunday, March 07, 2004 3:24 AM
> >> To: Vishal Sharma; Greg Bernstein; Eric Mannie
> >> Cc: [e-mail]; Alexey Zinin; Bert Wijnen
> >> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> >>
> >>
> >> Thanks for your thoughts Vishal.
> >>
> >> The debate occurs now.
> >>
> >> Are the current authors willing and able to make the changes
> >> requested by the AD?
> >>
> >> Thanks,
> >> Adrian
> >> ----- Original Message -----
> >> From: "Vishal Sharma" <[e-mail]>
> >> To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
> >> <[e-mail]>;
> >> "Eric Mannie" <[e-mail]>
> >> Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>;
> "Bert Wijnen"
> >> <[e-mail]>
> >> Sent: Sunday, March 07, 2004 12:48 AM
> >> Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> >>
> >>
> >> > Adrian,
> >> >
> >> > Thanks for the clarification. Our (the authors) understanding is
> >> > that the draft had passed (quite a while back, in May 2002
> >> > actually, after we had addressed the very last round of comments from
> >> > Kireeti), all of the processes in the WG needed to advance it to
> >> > informational RFC.
> >> >
> >> > Its purpose is really to provide an overall view and framework for
> >> > SDH/SONET control using an IP/MPLS control plane.
> >> >
> >> > So it would be useful for us to know exactly where the
> debate occurred,
> >> > since we were not aware of it.
> >> > (As far as the WG is concerned,  the draft was approved such a while
> >> > back that it has been a completed item for over
> one-and-a-half years.)
> >> >
> >> > At the last discussion on it in Sept. 2003, we were told
> that the only
> >> > reason it had got delayed was because it somehow missed being
> >> sent to the
> >> > ADs on time.
> >> >
> >> > -Vishal
> >> >
> >> > > -----Original Message-----
> >> > > From: [e-mail] [mailto:[e-mail]]On
> >> > > Behalf Of Adrian Farrel
> >> > > Sent: Saturday, March 06, 2004 3:11 PM
> >> > > To: Vishal Sharma; Greg Bernstein; Eric Mannie
> >> > > Cc: [e-mail]; Alexey Zinin
> >> > > Subject: Re: AD-review comments on
> draft-ietf-ccamp-sdhsonet-control
> >> > >
> >> > >
> >> > > Vishal,
> >> > >
> >> > > The process is that the WG hands the draft off to the AD to take
> >> > > it to the IESG. At this
> >> > > point the AD performs a review before taking the draft to the
> >> > > IESG and this is what we are
> >> > > seeing the results of.
> >> > >
> >> > > Note that this particular draft has been under "AD watch" for a
> >> > > while. Alex may want to
> >> > > clarify the reason for this, but my understanding is that there
> >> > > was some debate as to
> >> > > whether the draft had served its purpose already (that is, as a
> >> > > design document for the
> >> > > other drafts on SONET/SDH) or whether it should continue and
> >> > > become an RFC. This review is
> >> > > the next step towards becoming an RFC.
> >> > >
> >> > > Cheers,
> >> > > Adrian
> >> > >
> >> > > ----- Original Message -----
> >> > > From: "Vishal Sharma" <[e-mail]>
> >> > > To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
> >> > > <[e-mail]>;
> >> > > "Eric Mannie" <[e-mail]>
> >> > > Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>
> >> > > Sent: Saturday, March 06, 2004 8:41 PM
> >> > > Subject: RE: AD-review comments on
> draft-ietf-ccamp-sdhsonet-control
> >> > >
> >> > >
> >> > > > Adrian et al,
> >> > > >
> >> > > > We will work on the document and make the appropriate
> modifications
> >> > > > to incorporate the comments.
> >> > > >
> >> > > > BTW, Alex could you please clarify whether this is an IESG review
> >> > > > or some other review?
> >> > > >
> >> > > > Our understanding after the last communication with
> Kireeti on this
> >> > > > subject, sometime
> >> > > > in July last year, was that this draft (after having
> passed several
> >> > > > last calls), was being sent to the IESG for completing
> the process
> >> > > > of advancing to informational RFC.
> >> > > >
> >> > > > Thanks,
> >> > > > -Vishal
> >> > > >
> >> > > > > -----Original Message-----
> >> > > > > From: Adrian Farrel [mailto:[e-mail]]
> >> > > > > Sent: Saturday, March 06, 2004 4:16 AM
> >> > > > > To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
> >> > > > > Cc: [e-mail]
> >> > > > > Subject: Re: AD-review comments on
> >> draft-ietf-ccamp-sdhsonet-control
> >> > > > >
> >> > > > >
> >> > > > > Greg, Eric, Vishal,
> >> > > > > Are you willing and able to pick this draft up again
> and make the
> >> > > > > changes from Alex?
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Adrian
> >> > > > >
> >> > > > > ----- Original Message -----
> >> > > > > From: "Alex Zinin" <[e-mail]>
> >> > > > > To: <[e-mail]>
> >> > > > > Cc: <[e-mail]>
> >> > > > > Sent: Thursday, March 04, 2004 12:48 PM
> >> > > > > Subject: AD-review comments on
> draft-ietf-ccamp-sdhsonet-control
> >> > > > >
> >> > > > >
> >> > > > > > Folks-
> >> > > > > >
> >> > > > > >  Please find below comments from the RTG area directorate
> >> > > that I would
> >> > > > > >  like the WG to consider.
> >> > > > > >
> >> > > > > >  Thank you.
> >> > > > > >
> >> > > > > > --
> >> > > > > > Alex Zinin
> >> > > > > >
> >> > > > > > Technical:
> >> > > > > > ----------
> >> > > > > >
> >> > > > > > Section 3.2:
> >> > > > > >
> >> > > > > > 1. Figure 1 misses the STM-0 branch
> >> > > > > >
> >> > > > > > Section 3.4.3:
> >> > > > > >
> >> > > > > > 2. In comparison table, PNNI word appears for the first
> >> time in this
> >> > > > > >     document, any specific reason to mention PNNI in a
> >> > > GMPLS context ?
> >> > > > > >
> >> > > > > > Section 3.5
> >> > > > > >
> >> > > > > > 3. "New simplified encapsulations could reduce this
> >> > > overhead to as low
> >> > > > > >     as 3%, but the gain is not huge compared to SDH
> and SONET,
> >> > > > > which have
> >> > > > > >     other benefits as well.)" any reference available
> >> for these new
> >> > > > > >     simplified encapsulation(s) ?
> >> > > > > >
> >> > > > > > 4. "Any encapsulation of IP over WDM should at least
> >> provide error
> >> > > > > >     monitoring capabilities (to detect signal
> >> degradation), error
> >> > > > > >     correction capabilities, such as FEC (Forward Error
> >> > > Correction) that
> >> > > > > >     are particularly needed for ultra long haul
> >> > > transmission, sufficient
> >> > > > > >     timing information, to allow robust synchronization
> >> (that is, to
> >> > > > > >     detect the beginning of a packet), and capacity
> to transport
> >> > > > > >     signaling, routing and management messages, in order to
> >> > > control the
> >> > > > > >     optical switches."
> >> > > > > >
> >> > > > > >     The first part refers to data plane capabilities,
> >> however the
> >> > > > > >     requirement: the "encapsulation of IP over WDM"
> >> should deliver
> >> > > > > >     the capacity to transport IP based control plane
> >> information -
> >> > > > > >     why is this the case ? an out of band network would
> >> also do the
> >> > > > > >     job and this statement makes thus the implicit
> >> assumption that
> >> > > > > >     data and control plane topology is congruent
> >> > > > > >
> >> > > > > > Section 6:
> >> > > > > >
> >> > > > > > 5. "Due to the increase in information transferred in
> >> the routing
> >> > > > > >     protocol, it may be useful to separate the
> relatively static
> >> > > > > >     parameters concerning a link from those that may be
> >> subject to
> >> > > > > >     frequent changes. The current GMPLS routing extensions
> >> > > [12],[13],
> >> > > > > >     [14] do not make such a separation, however."
> >> > > > > >
> >> > > > > >    it may be thus worth asking the question was the
> >> dissemination
> >> > > > > >    of these quasi-static "link capabilities" using the
> >> same rules
> >> > > > > >    as for any other TE LSA Type 1 sub-TLV the right
> approach ?
> >> > > > > >
> >> > > > > > Section 6.1:
> >> > > > > >
> >> > > > > > 6. what does the following sentence brings in the scope of
> >> > > this control
> >> > > > > >     plane framework (and this is even not necessarily true
> >> > > when vcat is
> >> > > > > >     provided over different line cards):
> >> > > > > >
> >> > > > > >     "Note that this inverse multiplexing process can be
> >> > > significantly
> >> > > > > >     easier to implement with SONET/SDH signals rather
> >> than packets."
> >> > > > > >
> >> > > > > > Section 6.3:
> >> > > > > >
> >> > > > > > 7. "However, if only standard concatenation is supported
> >> > > then reporting
> >> > > > > >     gets trickier since there are constraints on where the
> >> > > STS-1s can be
> >> > > > > >     placed. SDH has still more options and constraints,
> >> > > hence it is not
> >> > > > > >     yet clear which is the best way to advertise
> >> bandwidth resource
> >> > > > > >     availability/usage in SONET/SDH. At present, the
> >> GMPLS routing
> >> > > > > >     protocol extensions define minimum and maximum values
> >> > > for available
> >> > > > > >     bandwidth, which allows a remote node to make some
> >> > > deductions about
> >> > > > > >     the amount of capacity available at a remote link and
> >> > > the types of
> >> > > > > >     signals it can accommodate. However, due to the
> >> > > multiplexed nature
> >> > > > > >     of the signals, the authors are of the opinion that
> >> reporting of
> >> > > > > >     bandwidth particular to signal types rather than
> as a single
> >> > > > > >     aggregate bit rate is probably very desirable."
> >> > > > > >
> >> > > > > >     -> the authors do not explain from which perspective
> >> > > and the reasons
> >> > > > > >     this particular bw accounting report is desirable
> >> > > (sections 2.4.3 &
> >> > > > > >     2.4.8 of GMPLS routing explains how these values are
> >> > > used to take
> >> > > > > >     into account the multiplexing capability of a SONET/SDH
> >> > > interface),
> >> > > > > >     there is no real determination of the missing
> >> > > information at remote
> >> > > > > >     nodes for the establishment of an LSP with a certain
> >> > > amount of bw
> >> > > > > >     (note that it is not an issue of flexible vs standard
> >> > > concatenation
> >> > > > > >     issue but a control plane issue)
> >> > > > > >
> >> > > > > > Section 7.3:
> >> > > > > >
> >> > > > > > 8. "This information is specified in three parts [17],
> >> each of which
> >> > > > > >     refers to a different network layer."
> >> > > > > >
> >> > > > > > The description of the signaling elements shall mention the
> >> > > following:
> >> > > > > > (section 7.3 refers to [17] but the latter does not
> >> > > correspond to the
> >> > > > > > description given in this section)
> >> > > > > >
> >> > > > > >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
> >> > > > > >      which contains three parts: LSP Encoding Type, Switching
> >> > > > > Type, G-PID
> >> > > > > >
> >> > > > > >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
> >> > > > > SENDER_TSPEC/FLOWSPEC
> >> > > > > >      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT,
> >> > > > > Transparency,
> >> > > > > >      Profile
> >> > > > > >
> >> > > > > >   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
> >> > > > > >
> >> > > > > >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object
> >> (as [RFC3473])
> >> > > > > >
> >> > > > > > ----
> >> > > > > >
> >> > > > > >
> >> > > > > > Editorial:
> >> > > > > > ----------
> >> > > > > >
> >> > > > > > Section 3:
> >> > > > > >
> >> > > > > > 1. Sometimes this document refers to GMPLS other to MPLS and
> >> > > > > >     sometimes as above as "extending IP technology"
> >> > > > > >
> >> > > > > > Section 3.1
> >> > > > > >
> >> > > > > > 2. "When a packet reaches a core packet LSR, this LSR uses
> >> > > the label as
> >> > > > > >     an index into a forwarding table to determine the next
> >> > > hop and the
> >> > > > > >     corresponding outgoing label (and, possibly, the QoS
> >> > > treatment to be
> >> > > > > >     given to the packet), writes the new label into the
> >> packet, and
> >> > > > > >     forwards the packet to the next hop. "
> >> > > > > >
> >> > > > > > -> replace "core packet LSR" by "packet LSR"
> >> > > > > >
> >> > > > > > Section 3.2:
> >> > > > > >
> >> > > > > > 3. "SDH and SONET are two TDM standards widely used by
> >> operators to
> >> > > > > >     transport and multiplex different tributary signals
> >> over optical
> >> > > > > >     links, thus creating a multiplexing structure,
> >> which we call the
> >> > > > > >     SDH/SONET multiplex. SDH, which was developed by the
> >> > > ETSI and later
> >> > > > > >     standardized by the ITU-T [4], is now used worldwide,
> >> > > while SONET,
> >> > > > > >     which was standardized by the ANSI [5], is mainly used
> >> > > in the US.
> >> > > > > >     However, these two standards have several similarities,
> >> > > and to some
> >> > > > > >     extent SONET can be viewed as a subset of SDH.
> >> Internetworking
> >> > > > > >     between the two is possible using gateways.
> >> > > > > >
> >> > > > > >     Should be rather as "ITU-T SDH (G.707) includes both
> >> > > the European
> >> > > > > >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy
> >> > > (T1.105)." [...]
> >> > > > > >     "The ETSI SDH and SONET standards regarding frame
> >> structures and
> >> > > > > >     higher order multiplexing are the same. There are
> >> some regional
> >> > > > > >     differences on the terminology, on the use of some
> >> > > overhead bytes,
> >> > > > > >     and lower order multiplexing. Interworking between
> >> the two lower
> >> > > > > >     order hierarchies is possible using gateways."
> >> > > > > >
> >> > > > > > Section 3.2
> >> > > > > >
> >> > > > > > 4. "In addition, a pointer (in the form of the H1, H2
> >> and H3 bytes)
> >> > > > > >     indicates the beginning of the VC/SPE in the payload of
> >> > > the overall
> >> > > > > >     STM/SDH frame."
> >> > > > > >
> >> > > > > > -> replace "STM/SDH frame" by "STM/STS frame"
> >> > > > > >
> >> > > > > > Section 4.1
> >> > > > > >
> >> > > > > > 5. "The SONET case is a bit difficult to explain since,
> >> > > unlike in SDH,
> >> > > > > >     SPEs in SONET do not have individual names." they are
> >> > > > > simply referred
> >> > > > > >     to as VT-N SPE
> >> > > > > >
> >> > > > > > Section 6:
> >> > > > > >
> >> > > > > > 6. Since this document distinguishes between "optical
> >> > > networks", TDM,
> >> > > > > >     and WDM it would advisable to avoid the "optical TDM"
> >> > > as mentioned
> >> > > > > >     in the below sentence (it has another meaning
> than MSn/RSn
> >> > > > > switching)
> >> > > > > >
> >> > > > > > Section 6.1:
> >> > > > > >
> >> > > > > > 7. Table 2, misses the equivalence between VC-4 and
> STS-3c SPE
> >> > > > > >
> >> > > > > >  > Section 6.1:
> >> > > > > >
> >> > > > > > 8. "Standard and flexible concatenations are network
> >> services, while
> >> > > > > >     virtual concatenation is a SONET/SDH end-system
> >> service recently
> >> > > > > >     approved by the committee T1 of ANSI and ITU-T." remove
> >> > > "recently
> >> > > > > >     approved by the committee T1 of ANSI and ITU-T." and
> >> > > add the corr.
> >> > > > > >     reference.
> >> > > > > >
> >> > > > > > 9. "In one example of virtual concatenation, two end
> >> > > systems supporting
> >> > > > > >     this feature could essentially "inverse multiplex" two
> >> > > STS-1s into a
> >> > > > > >     virtual STS-2c for the efficient transport of 100 Mbps
> >> > > > > Ethernet traffic."
> >> > > > > >
> >> > > > > > -> STS-1-2v instead of "virtual STS-2c"
> >> > > > > >
> >> > > > > > 10. "Section layer: Preserves all section overhead,
> >> > > Basically does not
> >> > > > > >      touch any of the SONET/SDH bits."
> >> > > > > >
> >> > > > > > -> replace last part by "Basically does not modify
> or terminate
> >> > > > > >     any of the SONET/SDH overhead bits"
> >> > > > > >
> >> > > > > >     left column of the table misses the SDH overhead
> equivalent
> >> > > > > >
> >> > > > > > 11. Multiplexing of (?) in the following sentence "To perform
> >> > > > > >      multiplexing, a SONET network element should be line
> >> > > terminating."
> >> > > > > >
> >> > > > > > Section 6.2:
> >> > > > > >
> >> > > > > > 12. In the following "Standardized SONET line level
> protection
> >> > > > > techniques
> >> > > > > >      include: Linear 1+1 and linear 1:N automatic
> >> > > protection switching
> >> > > > > >      (APS) and both two-fiber and four-fiber bi-directional
> >> > > > > line switched
> >> > > > > >      rings (BLSRs). At the path layer, SONET offers
> >> > > uni-directional path
> >> > > > > >      switched ring protection." the same applies to SDH (to
> >> > > be adapted
> >> > > > > >      using the corr. terminology)
> >> > > > > >
> >> > > > > > Section 7:
> >> > > > > >
> >> > > > > > 13. "This VC-4 LSP can, in fact, be established
> between two non-
> >> > > > > >      adjacent internal nodes in an SDH network, and later
> >> > > > > >      advertised by a routing protocol as a new (virtual) link
> >> > > > > >      called a Forwarding Adjacency (FA)." -> add
> >> MPLS-HIERARCHY as
> >> > > > > >      reference
> >> > > > > >
> >> > > > > > 14. The following paragraph
> >> > > > > >      "For instance, the payload of an SDH STM-1 frame
> >> does not fully
> >> > > > > >       contain a complete unit of user data. In fact, the
> >> > > user data is
> >> > > > > >       contained in a virtual container (VC) that is
> allowed to
> >> > > > > float over
> >> > > > > >       two contiguous frames for synchronization purposes. A
> >> > > > > pointer in the
> >> > > > > >       Section Overhead (SOH) indicates the beginning of the
> >> > > VC in the
> >> > > > > >       payload." mixes SDH with SONET - pointers in SDH
> >> in H1/H2/H3
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >> >
> >> >
>




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 01:54:46 +0000
From: "zafar ali" <[e-mail]>
To: "'Rahul Aggarwal'" <[e-mail]>
Cc: "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
Date: Wed, 10 Mar 2004 20:53:53 -0500
Organization: Cisco Systems
Message-ID: <001901c4070b$b6279aa0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: Rahul Aggarwal [mailto:[e-mail]] 
>Sent: Wednesday, March 10, 2004 8:27 PM
>To: zafar ali
>Cc: 'Ina Minei'; 'MPLS wg'; [e-mail]; 'Loa Andersson'; 
>'George Swallow'; [e-mail]; 'Reshad Rahman'; 
>[e-mail]
>Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
>
>
>
>Hi Zafar,
>
>[snipped]
>
>>
>> Thanks for your reply. We have a similar draft in CCAMP that 
>> formalized procedure for disabling RSVP GR (and Hello) (see,
>> 
>http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-hello-gr-admi
>> n-
>> 00.txt for details).
>>
>> The requirements/ motivations for the two drafts in question are 
>> similar.
>
>The difference is that RSVP-TE already supports the ability to 
>toggle the graceful restart capability of a router by 
>including/excluding the restart capability object in RSVP-TE 
>hellos. This can be done without breaking the neighbor 
>relationship between the adjacent routers.
>

Hi Rahul, 

We would not be having "part" of this discussion had there be a
statement stating the same in RFC 3473; a clarification is needed.
Furthermore, SPs have similar motivations for removing RSVP Hello
adjacencies without cause 
triggering FRR or GR. Not to mention due to possible millisecond
interval, SPs don't like to see RSVP Hello running even when there is no
application requiring them. You can argue that one node can back-off
RSVP hello interval, but the Hello frequency depends on min of the Hello
intervals at the peering nodes. 

Thanks

Regards... Zafar

>rahul
>
>>
>> Thanks
>>
>> Regards... Zafar
>>
>> >-----Original Message-----
>> >From: [e-mail] [mailto:[e-mail]] On Behalf Of Ina 
>> >Minei
>> >Sent: Tuesday, March 09, 2004 6:35 PM
>> >To: zafar ali
>> >Cc: 'MPLS wg'; [e-mail]; 'Rahul Aggarwal'; 'Loa Andersson'; 
>> >'George Swallow'
>> >Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt
>> >
>> >
>> >
>> >	Zafar,
>> >
>> >	3478 details the procedures for doing graceful restart
>> >in the case where the capability will be used irrespective of the 
>> >cause of the crash.
>> >
>> >	The proposed enhancement deals with a situation where
>> >the operator wants to perform graceful restart only when he 
>is doing 
>> >a planned upgrade. Why? Because a planned upgrade is a controled 
>> >environment. This is mostly a comfort-level issue for the operator 
>> >and a good way to let him convince himself that the feature is 
>> >working as expected. Many operators are wary of graceful 
>restart, but 
>> >would really like to see graceful upgrades.
>> >
>> >				Ina
>> >
>> >On Tue, 9 Mar 2004, zafar ali wrote:
>> >
>> >> Hi Ina, Rahul and Albert,
>> >>
>> >>
>> >>
>> >> I am not sure about motivation behind this draft. Why 
>procedures in 
>> >> RFC 3478 are are NOT enough to address planned outages? This
>> >question
>> >> was also raised at the last MPLS WG meeting but I did not 
>hear any 
>> >> convincing answer.
>> >>
>> >>
>> >>
>> >> Thanks
>> >>
>> >>
>> >>
>> >> Regards... Zafar
>> >>
>> >>
>> >
>>
>>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 01:39:09 +0000
Date: Wed, 10 Mar 2004 17:37:34 -0800
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: "Vishal Sharma" <[e-mail]>
CC: "Adrian Farrel" <[e-mail]>, "Greg Bernstein" <[e-mail]>,  "Eric Mannie" <[e-mail]>, <[e-mail]>, "Bert Wijnen" <[e-mail]>
Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vishal,

  To clarify the process, here's the list of stages a document usually goes
  through:

  1. WG discussion
  2. WG Last Call
  3. AD review (may include directorate       <-- You are here now
     and expert reviews)
  4. IETF LC (generally not needed for INFO)
  5. IESG review
  6. RFC Editor

  I received the doc back in Sep 2003 and asked one of the Routing Area
  directorate members for an expert review, which resulted in a long list of
  comments. We had a long (and admittedly slow) discussion between the reviewer,
  me, and the WG chairs in an attempt to distill it to a set of most significant
  technical comments and editorial suggestions, which is what I brought back for
  consideration by the WG.

  On a related note: please do not assume that work is done once a document has
  passed the WG LC. It is normal to receive comments from the ADs and IESG.

  Regards.
  
-- 
Alex
http://www.psg.com/~zinin/

Sunday, March 7, 2004, 1:41:10 PM, Vishal Sharma wrote:
> Adrian,

> I am still very confused about what the debate is about at this point.
> In any case, I would like to defer to my co-authors on this matter.

> As for the enhancements/edits, I think we already stated that we
> could do those.

> -Vishal

>> -----Original Message-----
>> From: Adrian Farrel [mailto:[e-mail]]
>> Sent: Sunday, March 07, 2004 3:24 AM
>> To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> Cc: [e-mail]; Alexey Zinin; Bert Wijnen
>> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>>
>>
>> Thanks for your thoughts Vishal.
>>
>> The debate occurs now.
>>
>> Are the current authors willing and able to make the changes
>> requested by the AD?
>>
>> Thanks,
>> Adrian
>> ----- Original Message -----
>> From: "Vishal Sharma" <[e-mail]>
>> To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
>> <[e-mail]>;
>> "Eric Mannie" <[e-mail]>
>> Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>; "Bert Wijnen"
>> <[e-mail]>
>> Sent: Sunday, March 07, 2004 12:48 AM
>> Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>>
>>
>> > Adrian,
>> >
>> > Thanks for the clarification. Our (the authors) understanding is
>> > that the draft had passed (quite a while back, in May 2002
>> > actually, after we had addressed the very last round of comments from
>> > Kireeti), all of the processes in the WG needed to advance it to
>> > informational RFC.
>> >
>> > Its purpose is really to provide an overall view and framework for
>> > SDH/SONET control using an IP/MPLS control plane.
>> >
>> > So it would be useful for us to know exactly where the debate occurred,
>> > since we were not aware of it.
>> > (As far as the WG is concerned,  the draft was approved such a while
>> > back that it has been a completed item for over one-and-a-half years.)
>> >
>> > At the last discussion on it in Sept. 2003, we were told that the only
>> > reason it had got delayed was because it somehow missed being
>> sent to the
>> > ADs on time.
>> >
>> > -Vishal
>> >
>> > > -----Original Message-----
>> > > From: [e-mail] [mailto:[e-mail]]On
>> > > Behalf Of Adrian Farrel
>> > > Sent: Saturday, March 06, 2004 3:11 PM
>> > > To: Vishal Sharma; Greg Bernstein; Eric Mannie
>> > > Cc: [e-mail]; Alexey Zinin
>> > > Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>> > >
>> > >
>> > > Vishal,
>> > >
>> > > The process is that the WG hands the draft off to the AD to take
>> > > it to the IESG. At this
>> > > point the AD performs a review before taking the draft to the
>> > > IESG and this is what we are
>> > > seeing the results of.
>> > >
>> > > Note that this particular draft has been under "AD watch" for a
>> > > while. Alex may want to
>> > > clarify the reason for this, but my understanding is that there
>> > > was some debate as to
>> > > whether the draft had served its purpose already (that is, as a
>> > > design document for the
>> > > other drafts on SONET/SDH) or whether it should continue and
>> > > become an RFC. This review is
>> > > the next step towards becoming an RFC.
>> > >
>> > > Cheers,
>> > > Adrian
>> > >
>> > > ----- Original Message -----
>> > > From: "Vishal Sharma" <[e-mail]>
>> > > To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
>> > > <[e-mail]>;
>> > > "Eric Mannie" <[e-mail]>
>> > > Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>
>> > > Sent: Saturday, March 06, 2004 8:41 PM
>> > > Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>> > >
>> > >
>> > > > Adrian et al,
>> > > >
>> > > > We will work on the document and make the appropriate modifications
>> > > > to incorporate the comments.
>> > > >
>> > > > BTW, Alex could you please clarify whether this is an IESG review
>> > > > or some other review?
>> > > >
>> > > > Our understanding after the last communication with Kireeti on this
>> > > > subject, sometime
>> > > > in July last year, was that this draft (after having passed several
>> > > > last calls), was being sent to the IESG for completing the process
>> > > > of advancing to informational RFC.
>> > > >
>> > > > Thanks,
>> > > > -Vishal
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: Adrian Farrel [mailto:[e-mail]]
>> > > > > Sent: Saturday, March 06, 2004 4:16 AM
>> > > > > To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
>> > > > > Cc: [e-mail]
>> > > > > Subject: Re: AD-review comments on
>> draft-ietf-ccamp-sdhsonet-control
>> > > > >
>> > > > >
>> > > > > Greg, Eric, Vishal,
>> > > > > Are you willing and able to pick this draft up again and make the
>> > > > > changes from Alex?
>> > > > >
>> > > > > Thanks,
>> > > > > Adrian
>> > > > >
>> > > > > ----- Original Message -----
>> > > > > From: "Alex Zinin" <[e-mail]>
>> > > > > To: <[e-mail]>
>> > > > > Cc: <[e-mail]>
>> > > > > Sent: Thursday, March 04, 2004 12:48 PM
>> > > > > Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>> > > > >
>> > > > >
>> > > > > > Folks-
>> > > > > >
>> > > > > >  Please find below comments from the RTG area directorate
>> > > that I would
>> > > > > >  like the WG to consider.
>> > > > > >
>> > > > > >  Thank you.
>> > > > > >
>> > > > > > --
>> > > > > > Alex Zinin
>> > > > > >
>> > > > > > Technical:
>> > > > > > ----------
>> > > > > >
>> > > > > > Section 3.2:
>> > > > > >
>> > > > > > 1. Figure 1 misses the STM-0 branch
>> > > > > >
>> > > > > > Section 3.4.3:
>> > > > > >
>> > > > > > 2. In comparison table, PNNI word appears for the first
>> time in this
>> > > > > >     document, any specific reason to mention PNNI in a
>> > > GMPLS context ?
>> > > > > >
>> > > > > > Section 3.5
>> > > > > >
>> > > > > > 3. "New simplified encapsulations could reduce this
>> > > overhead to as low
>> > > > > >     as 3%, but the gain is not huge compared to SDH and SONET,
>> > > > > which have
>> > > > > >     other benefits as well.)" any reference available
>> for these new
>> > > > > >     simplified encapsulation(s) ?
>> > > > > >
>> > > > > > 4. "Any encapsulation of IP over WDM should at least
>> provide error
>> > > > > >     monitoring capabilities (to detect signal
>> degradation), error
>> > > > > >     correction capabilities, such as FEC (Forward Error
>> > > Correction) that
>> > > > > >     are particularly needed for ultra long haul
>> > > transmission, sufficient
>> > > > > >     timing information, to allow robust synchronization
>> (that is, to
>> > > > > >     detect the beginning of a packet), and capacity to transport
>> > > > > >     signaling, routing and management messages, in order to
>> > > control the
>> > > > > >     optical switches."
>> > > > > >
>> > > > > >     The first part refers to data plane capabilities,
>> however the
>> > > > > >     requirement: the "encapsulation of IP over WDM"
>> should deliver
>> > > > > >     the capacity to transport IP based control plane
>> information -
>> > > > > >     why is this the case ? an out of band network would
>> also do the
>> > > > > >     job and this statement makes thus the implicit
>> assumption that
>> > > > > >     data and control plane topology is congruent
>> > > > > >
>> > > > > > Section 6:
>> > > > > >
>> > > > > > 5. "Due to the increase in information transferred in
>> the routing
>> > > > > >     protocol, it may be useful to separate the relatively static
>> > > > > >     parameters concerning a link from those that may be
>> subject to
>> > > > > >     frequent changes. The current GMPLS routing extensions
>> > > [12],[13],
>> > > > > >     [14] do not make such a separation, however."
>> > > > > >
>> > > > > >    it may be thus worth asking the question was the
>> dissemination
>> > > > > >    of these quasi-static "link capabilities" using the
>> same rules
>> > > > > >    as for any other TE LSA Type 1 sub-TLV the right approach ?
>> > > > > >
>> > > > > > Section 6.1:
>> > > > > >
>> > > > > > 6. what does the following sentence brings in the scope of
>> > > this control
>> > > > > >     plane framework (and this is even not necessarily true
>> > > when vcat is
>> > > > > >     provided over different line cards):
>> > > > > >
>> > > > > >     "Note that this inverse multiplexing process can be
>> > > significantly
>> > > > > >     easier to implement with SONET/SDH signals rather
>> than packets."
>> > > > > >
>> > > > > > Section 6.3:
>> > > > > >
>> > > > > > 7. "However, if only standard concatenation is supported
>> > > then reporting
>> > > > > >     gets trickier since there are constraints on where the
>> > > STS-1s can be
>> > > > > >     placed. SDH has still more options and constraints,
>> > > hence it is not
>> > > > > >     yet clear which is the best way to advertise
>> bandwidth resource
>> > > > > >     availability/usage in SONET/SDH. At present, the
>> GMPLS routing
>> > > > > >     protocol extensions define minimum and maximum values
>> > > for available
>> > > > > >     bandwidth, which allows a remote node to make some
>> > > deductions about
>> > > > > >     the amount of capacity available at a remote link and
>> > > the types of
>> > > > > >     signals it can accommodate. However, due to the
>> > > multiplexed nature
>> > > > > >     of the signals, the authors are of the opinion that
>> reporting of
>> > > > > >     bandwidth particular to signal types rather than as a single
>> > > > > >     aggregate bit rate is probably very desirable."
>> > > > > >
>> > > > > >     -> the authors do not explain from which perspective
>> > > and the reasons
>> > > > > >     this particular bw accounting report is desirable
>> > > (sections 2.4.3 &
>> > > > > >     2.4.8 of GMPLS routing explains how these values are
>> > > used to take
>> > > > > >     into account the multiplexing capability of a SONET/SDH
>> > > interface),
>> > > > > >     there is no real determination of the missing
>> > > information at remote
>> > > > > >     nodes for the establishment of an LSP with a certain
>> > > amount of bw
>> > > > > >     (note that it is not an issue of flexible vs standard
>> > > concatenation
>> > > > > >     issue but a control plane issue)
>> > > > > >
>> > > > > > Section 7.3:
>> > > > > >
>> > > > > > 8. "This information is specified in three parts [17],
>> each of which
>> > > > > >     refers to a different network layer."
>> > > > > >
>> > > > > > The description of the signaling elements shall mention the
>> > > following:
>> > > > > > (section 7.3 refers to [17] but the latter does not
>> > > correspond to the
>> > > > > > description given in this section)
>> > > > > >
>> > > > > >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
>> > > > > >      which contains three parts: LSP Encoding Type, Switching
>> > > > > Type, G-PID
>> > > > > >
>> > > > > >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
>> > > > > SENDER_TSPEC/FLOWSPEC
>> > > > > >      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT,
>> > > > > Transparency,
>> > > > > >      Profile
>> > > > > >
>> > > > > >   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
>> > > > > >
>> > > > > >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object
>> (as [RFC3473])
>> > > > > >
>> > > > > > ----
>> > > > > >
>> > > > > >
>> > > > > > Editorial:
>> > > > > > ----------
>> > > > > >
>> > > > > > Section 3:
>> > > > > >
>> > > > > > 1. Sometimes this document refers to GMPLS other to MPLS and
>> > > > > >     sometimes as above as "extending IP technology"
>> > > > > >
>> > > > > > Section 3.1
>> > > > > >
>> > > > > > 2. "When a packet reaches a core packet LSR, this LSR uses
>> > > the label as
>> > > > > >     an index into a forwarding table to determine the next
>> > > hop and the
>> > > > > >     corresponding outgoing label (and, possibly, the QoS
>> > > treatment to be
>> > > > > >     given to the packet), writes the new label into the
>> packet, and
>> > > > > >     forwards the packet to the next hop. "
>> > > > > >
>> > > > > > -> replace "core packet LSR" by "packet LSR"
>> > > > > >
>> > > > > > Section 3.2:
>> > > > > >
>> > > > > > 3. "SDH and SONET are two TDM standards widely used by
>> operators to
>> > > > > >     transport and multiplex different tributary signals
>> over optical
>> > > > > >     links, thus creating a multiplexing structure,
>> which we call the
>> > > > > >     SDH/SONET multiplex. SDH, which was developed by the
>> > > ETSI and later
>> > > > > >     standardized by the ITU-T [4], is now used worldwide,
>> > > while SONET,
>> > > > > >     which was standardized by the ANSI [5], is mainly used
>> > > in the US.
>> > > > > >     However, these two standards have several similarities,
>> > > and to some
>> > > > > >     extent SONET can be viewed as a subset of SDH.
>> Internetworking
>> > > > > >     between the two is possible using gateways.
>> > > > > >
>> > > > > >     Should be rather as "ITU-T SDH (G.707) includes both
>> > > the European
>> > > > > >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy
>> > > (T1.105)." [...]
>> > > > > >     "The ETSI SDH and SONET standards regarding frame
>> structures and
>> > > > > >     higher order multiplexing are the same. There are
>> some regional
>> > > > > >     differences on the terminology, on the use of some
>> > > overhead bytes,
>> > > > > >     and lower order multiplexing. Interworking between
>> the two lower
>> > > > > >     order hierarchies is possible using gateways."
>> > > > > >
>> > > > > > Section 3.2
>> > > > > >
>> > > > > > 4. "In addition, a pointer (in the form of the H1, H2
>> and H3 bytes)
>> > > > > >     indicates the beginning of the VC/SPE in the payload of
>> > > the overall
>> > > > > >     STM/SDH frame."
>> > > > > >
>> > > > > > -> replace "STM/SDH frame" by "STM/STS frame"
>> > > > > >
>> > > > > > Section 4.1
>> > > > > >
>> > > > > > 5. "The SONET case is a bit difficult to explain since,
>> > > unlike in SDH,
>> > > > > >     SPEs in SONET do not have individual names." they are
>> > > > > simply referred
>> > > > > >     to as VT-N SPE
>> > > > > >
>> > > > > > Section 6:
>> > > > > >
>> > > > > > 6. Since this document distinguishes between "optical
>> > > networks", TDM,
>> > > > > >     and WDM it would advisable to avoid the "optical TDM"
>> > > as mentioned
>> > > > > >     in the below sentence (it has another meaning than MSn/RSn
>> > > > > switching)
>> > > > > >
>> > > > > > Section 6.1:
>> > > > > >
>> > > > > > 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE
>> > > > > >
>> > > > > >  > Section 6.1:
>> > > > > >
>> > > > > > 8. "Standard and flexible concatenations are network
>> services, while
>> > > > > >     virtual concatenation is a SONET/SDH end-system
>> service recently
>> > > > > >     approved by the committee T1 of ANSI and ITU-T." remove
>> > > "recently
>> > > > > >     approved by the committee T1 of ANSI and ITU-T." and
>> > > add the corr.
>> > > > > >     reference.
>> > > > > >
>> > > > > > 9. "In one example of virtual concatenation, two end
>> > > systems supporting
>> > > > > >     this feature could essentially "inverse multiplex" two
>> > > STS-1s into a
>> > > > > >     virtual STS-2c for the efficient transport of 100 Mbps
>> > > > > Ethernet traffic."
>> > > > > >
>> > > > > > -> STS-1-2v instead of "virtual STS-2c"
>> > > > > >
>> > > > > > 10. "Section layer: Preserves all section overhead,
>> > > Basically does not
>> > > > > >      touch any of the SONET/SDH bits."
>> > > > > >
>> > > > > > -> replace last part by "Basically does not modify or terminate
>> > > > > >     any of the SONET/SDH overhead bits"
>> > > > > >
>> > > > > >     left column of the table misses the SDH overhead equivalent
>> > > > > >
>> > > > > > 11. Multiplexing of (?) in the following sentence "To perform
>> > > > > >      multiplexing, a SONET network element should be line
>> > > terminating."
>> > > > > >
>> > > > > > Section 6.2:
>> > > > > >
>> > > > > > 12. In the following "Standardized SONET line level protection
>> > > > > techniques
>> > > > > >      include: Linear 1+1 and linear 1:N automatic
>> > > protection switching
>> > > > > >      (APS) and both two-fiber and four-fiber bi-directional
>> > > > > line switched
>> > > > > >      rings (BLSRs). At the path layer, SONET offers
>> > > uni-directional path
>> > > > > >      switched ring protection." the same applies to SDH (to
>> > > be adapted
>> > > > > >      using the corr. terminology)
>> > > > > >
>> > > > > > Section 7:
>> > > > > >
>> > > > > > 13. "This VC-4 LSP can, in fact, be established between two non-
>> > > > > >      adjacent internal nodes in an SDH network, and later
>> > > > > >      advertised by a routing protocol as a new (virtual) link
>> > > > > >      called a Forwarding Adjacency (FA)." -> add
>> MPLS-HIERARCHY as
>> > > > > >      reference
>> > > > > >
>> > > > > > 14. The following paragraph
>> > > > > >      "For instance, the payload of an SDH STM-1 frame
>> does not fully
>> > > > > >       contain a complete unit of user data. In fact, the
>> > > user data is
>> > > > > >       contained in a virtual container (VC) that is allowed to
>> > > > > float over
>> > > > > >       two contiguous frames for synchronization purposes. A
>> > > > > pointer in the
>> > > > > >       Section Overhead (SOH) indicates the beginning of the
>> > > VC in the
>> > > > > >       payload." mixes SDH with SONET - pointers in SDH
>> in H1/H2/H3
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > >
>> > > >
>> > > >
>> > >
>> >
>> >
>> >




Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 01:27:28 +0000
Date: Wed, 10 Mar 2004 17:26:36 -0800 (PST)
From: Rahul Aggarwal <[e-mail]>
To: zafar ali <[e-mail]>
cc: "'Ina Minei'" <[e-mail]>, "'MPLS wg'" <[e-mail]>, "" <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, "" <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, "" <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Zafar,

[snipped]

>
> Thanks for your reply. We have a similar draft in CCAMP that formalized
> procedure for disabling RSVP GR (and Hello) (see,
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-hello-gr-admin-
> 00.txt for details).
>
> The requirements/ motivations for the two drafts in question are
> similar.

The difference is that RSVP-TE already supports the ability to toggle the
graceful restart capability of a router by including/excluding the restart
capability object in RSVP-TE hellos. This can be done without breaking the
neighbor relationship between the adjacent routers.

rahul

>
> Thanks
>
> Regards... Zafar
>
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On Behalf
> >Of Ina Minei
> >Sent: Tuesday, March 09, 2004 6:35 PM
> >To: zafar ali
> >Cc: 'MPLS wg'; [e-mail]; 'Rahul Aggarwal'; 'Loa
> >Andersson'; 'George Swallow'
> >Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt
> >
> >
> >
> >	Zafar,
> >
> >	3478 details the procedures for doing graceful restart
> >in the case where the capability will be used irrespective of
> >the cause of the crash.
> >
> >	The proposed enhancement deals with a situation where
> >the operator wants to perform graceful restart only when he is
> >doing a planned upgrade. Why? Because a planned upgrade is a
> >controled environment. This is mostly a comfort-level issue
> >for the operator and a good way to let him convince himself
> >that the feature is working as expected. Many operators are
> >wary of graceful restart, but would really like to see
> >graceful upgrades.
> >
> >				Ina
> >
> >On Tue, 9 Mar 2004, zafar ali wrote:
> >
> >> Hi Ina, Rahul and Albert,
> >>
> >>
> >>
> >> I am not sure about motivation behind this draft. Why procedures in
> >> RFC 3478 are are NOT enough to address planned outages? This
> >question
> >> was also raised at the last MPLS WG meeting but I did not hear any
> >> convincing answer.
> >>
> >>
> >>
> >> Thanks
> >>
> >>
> >>
> >> Regards... Zafar
> >>
> >>
> >
>
>



Envelope-to: [e-mail]
Delivery-date: Thu, 11 Mar 2004 01:20:26 +0000
From: "zafar ali" <[e-mail]>
To: "'Ina Minei'" <[e-mail]>
Cc: "'MPLS wg'" <[e-mail]>, <[e-mail]>, "'Rahul Aggarwal'" <[e-mail]>, "'Loa Andersson'" <[e-mail]>, "'George Swallow'" <[e-mail]>, <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
Date: Wed, 10 Mar 2004 20:17:18 -0500
Organization: Cisco Systems
Message-ID: <001601c40706$9a182b90$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Ina, Rahul, Albert, et al

Thanks for your reply. We have a similar draft in CCAMP that formalized
procedure for disabling RSVP GR (and Hello) (see,
http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-hello-gr-admin-
00.txt for details). 

The requirements/ motivations for the two drafts in question are
similar. Ideally what you would like to do in your draft is to also be
able to turn LDP GR on and off on the fly. I hope the two drafts will
get the same treatment from the WGs (adding CCAMP). 

Thanks

Regards... Zafar

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf 
>Of Ina Minei
>Sent: Tuesday, March 09, 2004 6:35 PM
>To: zafar ali
>Cc: 'MPLS wg'; [e-mail]; 'Rahul Aggarwal'; 'Loa 
>Andersson'; 'George Swallow'
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt
>
>
>
>	Zafar,
>
>	3478 details the procedures for doing graceful restart 
>in the case where the capability will be used irrespective of 
>the cause of the crash.
>
>	The proposed enhancement deals with a situation where 
>the operator wants to perform graceful restart only when he is 
>doing a planned upgrade. Why? Because a planned upgrade is a 
>controled environment. This is mostly a comfort-level issue 
>for the operator and a good way to let him convince himself 
>that the feature is working as expected. Many operators are 
>wary of graceful restart, but would really like to see 
>graceful upgrades.
>
>				Ina
>
>On Tue, 9 Mar 2004, zafar ali wrote:
>
>> Hi Ina, Rahul and Albert,
>>
>>
>>
>> I am not sure about motivation behind this draft. Why procedures in 
>> RFC 3478 are are NOT enough to address planned outages? This 
>question 
>> was also raised at the last MPLS WG meeting but I did not hear any 
>> convincing answer.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards... Zafar
>>
>>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 10 Mar 2004 15:45:43 +0000
Message-ID: <[e-mail]>
From: Ayan Banerjee <[e-mail]>
To: 'Adrian Farrel ' <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: Opinion sought on drafts being adopted by CCAMP
Date: Wed, 10 Mar 2004 07:43:55 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Yes to all.

Ayan

On Thu, 4 Mar 2004 11:46:04 -0000
"Adrian Farrel" <[e-mail]> wrote:

> All,
> 
> At the CCAMP meeting today we discussed making several drafts working
group items. Can you
> please express your opinion (yes/no) on whether each of the following
drafts is ready to
> become a CCAMP working group draft.
> 
> Feel free to express yes with reservations. If you have reservations
or objections, please
> express them on the list. if you need anonymity for your comments then
please filter them
> through the chairs.
> 
> Silence will be taken as meaning nothing, so please say what you
think.
> 
> GMPLS Signaling Procedure For Egress Control
>
http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01
.txt
> 
> Generic Tunnel Tracing Protocol (GTTP) Specification
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
> 
> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-
signaling-03.txt
> 
> GMPLS Based Segment Recovery
>
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-rec
overy-00.txt
> 
> Thank you,
> Adrian
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 10 Mar 2004 13:02:16 +0000
Date: Wed, 10 Mar 2004 22:00:05 +0900
From: Eiji Oki <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Cc: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Yes to all.

Eiji

On Thu, 4 Mar 2004 11:46:04 -0000
"Adrian Farrel" <[e-mail]> wrote:

> All,
> 
> At the CCAMP meeting today we discussed making several drafts working group items. Can you
> please express your opinion (yes/no) on whether each of the following drafts is ready to
> become a CCAMP working group draft.
> 
> Feel free to express yes with reservations. If you have reservations or objections, please
> express them on the list. if you need anonymity for your comments then please filter them
> through the chairs.
> 
> Silence will be taken as meaning nothing, so please say what you think.
> 
> GMPLS Signaling Procedure For Egress Control
> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
> 
> Generic Tunnel Tracing Protocol (GTTP) Specification
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
> 
> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
> 
> GMPLS Based Segment Recovery
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt
> 
> Thank you,
> Adrian
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 10 Mar 2004 11:31:31 +0000
Message-ID: <[e-mail]>
Date: Wed, 10 Mar 2004 12:29:59 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: [e-mail]
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

yes - to all

/Loa

Adrian Farrel wrote:

> All,
> 
> At the CCAMP meeting today we discussed making several drafts working group items. Can you
> please express your opinion (yes/no) on whether each of the following drafts is ready to
> become a CCAMP working group draft.
> 
> Feel free to express yes with reservations. If you have reservations or objections, please
> express them on the list. if you need anonymity for your comments then please filter them
> through the chairs.
> 
> Silence will be taken as meaning nothing, so please say what you think.
> 
> GMPLS Signaling Procedure For Egress Control
> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
> 
> Generic Tunnel Tracing Protocol (GTTP) Specification
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
> 
> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
> 
> GMPLS Based Segment Recovery
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt
> 
> Thank you,
> Adrian
> 
> 
> 
> 

-- 

Loa Andersson

mobile [phone]




Envelope-to: [e-mail]
Delivery-date: Wed, 10 Mar 2004 08:49:06 +0000
Message-ID: <[e-mail]>
Date: Wed, 10 Mar 2004 03:50:36 -0500
From: Sudheer Dharanikota <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

>GMPLS Signaling Procedure For Egress Control
>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
>  
>
Yes

>Generic Tunnel Tracing Protocol (GTTP) Specification
>http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
>  
>
No opinion.

>RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
>  
>
Yes

>GMPLS Based Segment Recovery
>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt
>  
>
Yes.

- sudheer

>Thank you,
>Adrian
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Wed, 10 Mar 2004 02:18:45 +0000
Message-ID: <002a01c40645$d6d04520$b900a8c0@BRAJADELL>
From: "Bala Rajagopalan" <[e-mail]>
To: <[e-mail]>
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Date: Tue, 9 Mar 2004 21:17:28 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sig
naling-03.txt

YES.

Bala





Envelope-to: [e-mail]
Delivery-date: Wed, 10 Mar 2004 01:03:02 +0000
Message-ID: <[e-mail]>
Date: Wed, 10 Mar 2004 10:01:40 +0900
From: Kohei Shiomoto <[e-mail]>
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: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Yes to all

Adrian Farrel wrote:

>All,
>
>At the CCAMP meeting today we discussed making several drafts working group items. Can you
>please express your opinion (yes/no) on whether each of the following drafts is ready to
>become a CCAMP working group draft.
>
>Feel free to express yes with reservations. If you have reservations or objections, please
>express them on the list. if you need anonymity for your comments then please filter them
>through the chairs.
>
>Silence will be taken as meaning nothing, so please say what you think.
>
>GMPLS Signaling Procedure For Egress Control
>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
>
>Generic Tunnel Tracing Protocol (GTTP) Specification
>http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
>
>RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
>
>GMPLS Based Segment Recovery
>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt
>
>Thank you,
>Adrian
>
>
>
>  
>

-- 
Kohei Shiomoto
NTT Network Innovation Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone]    Fax [phone]






Envelope-to: [e-mail]
Delivery-date: Wed, 10 Mar 2004 01:02:32 +0000
Message-ID: <[e-mail]>
Date: Wed, 10 Mar 2004 10:00:16 +0900
From: Kohei Shiomoto <[e-mail]>
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: [e-mail], "Ong, Lyndon" <[e-mail]>
CC: "'Adrian Farrel'" <[e-mail]>, [e-mail]
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Dimitri and Lyndon

Yes, my concern is misconnection during activation of backup LSP 
procedure originally raised by Yoshihiko (See
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00079.html).  Similar 
situation can occur not only for P&R context but also for more general 
context when preemption takes place. Solutions should be explored in 
more general context and several solutions could be developed. I feel 
that the P&R solution document should also address the problem and give 
the solution referring some documents on preemption.
I feel that  "rsvp for e2e recovery" draft is ready for WG document.

-- 
Kohei Shiomoto
NTT Network Innovation Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone]    Fax [phone]




[e-mail] wrote:

> lyndon:
>
>> -- egress control - yes.     The question of what kind of target came 
>> up, BCP, Info, etc -
>>    Whatever kind of document it winds up being, I think one
>>    important result should be marking 3473 as being supplemented
>>    by the new document to avoid any future confusion.
>>
>> -- tunnel tracing - yes
>>
>> -- rsvp for e2e recovery - there seemed to be still some concerns
>>    at the meeting, so no (not yet)
>
>
> the concern raised (*) by kohei is the following what are
> the exact steps happening during preemption of LSPs that
> are using the spare capacity in dedicated/shared re-routing
> schemes - however, this concern is broader than simply this
> document - and there are two solutions either the steps
> are being detailed in this document or preemption is going
> to be addressed in a specific document and reference will
> be provided
>
> (*) went to discuss privately since we didn't have the time
> to discuss this point - kohei please correct me if i am
> wrong here -
>
>> -- segment recovery - no (not yet)
>>
>> Cheers,
>>
>> Lyndon
>>   
>> -----Original Message-----
>> From: Adrian Farrel [mailto:[e-mail]]
>> Sent: Thursday, March 04, 2004 3:46 AM
>> To: [e-mail]
>> Subject: Opinion sought on drafts being adopted by CCAMP
>>
>>
>> All,
>>
>> At the CCAMP meeting today we discussed making several drafts working 
>> group items. Can you
>> please express your opinion (yes/no) on whether each of the following 
>> drafts is ready to
>> become a CCAMP working group draft.
>>
>> Feel free to express yes with reservations. If you have reservations 
>> or objections, please
>> express them on the list. if you need anonymity for your comments 
>> then please filter them
>> through the chairs.
>>
>> Silence will be taken as meaning nothing, so please say what you think.
>>
>> GMPLS Signaling Procedure For Egress Control
>> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt 
>>
>>
>> Generic Tunnel Tracing Protocol (GTTP) Specification
>> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
>>
>> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>> http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt 
>>
>>
>> GMPLS Based Segment Recovery
>> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt 
>>
>>
>> Thank you,
>> Adrian
>>
>>
>






Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 23:28:29 +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: Communication in response to the OIF
Date: Tue, 9 Mar 2004 17:26:25 -0600
Message-ID: <[e-mail]>
Thread-Topic: Communication in response to the OIF
Thread-Index: AcQGFlJREDu7npyLTPexFMweM/54vAAEDu6A
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Stephen Shew" <[e-mail]>, <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, <[e-mail]>, "Alex Zinin" <[e-mail]>, "Bill Fenner" <[e-mail]>

Stephen,
=20
The difficulty with the OIF liaison is to understand the intention of =
the communication and the expectation. The liaison states "to =
inform..attention and review". The documents are 100+ pages. And of =
completed work (already letter balloted and approved). Is the liaison =
informational? Or is it for action? What action is expected of IETF? To =
bless and BOF toast for global deployment? Approve, in what way, as =
RFCs? Without understanding the intention of the work, IETF can not =
"review". As Kireeti stated in his proposed response, this is the first =
question which needs clarification.
=20
Point b is stating that the "solution" work is already on-going in IETF, =
and the concern to hear OIF is also working "solutions". Especially =
considering the cross-participation in ITU/OIF/IETF. A valid concern for =
any SDO on hearing solutions (using an SDO's protocols) are being =
progressed in the industry for their on-going work items. Point b could =
use rewording to clarify if this is not clear.
=20
Deborah
=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On =
Behalf Of Stephen Shew
Sent: Tuesday, March 09, 2004 3:32 PM
To: '[e-mail]'
Cc: 'Kireeti Kompella'; [e-mail]; Alex Zinin; Bill Fenner
Subject: RE: Communication in response to the OIF



Dimitri, the point I was trying to make was that it should not alarm =
CCAMP that the OIF has a relationship with the ITU-T.  On the matter of =
not having work reviewed by CCAMP, surely you recognize that the OIF =
liaison itself is an opportunity for that review to occur.

Many individuals have participated in routing for optical networks over =
the last several years in IETF, ITU-T, T1X1 and OIF, including yourself. =
 That the OIF has entertained routing contributions is no secret.  =
Further, since OIF and IETF are working with G.7715 and G.7715.1 =
compliance in mind, the OIF work should yield improvements that can =
benefit everyone in this area.  Again, this shouldn't be a cause of =
alarm from an organization that has "running code" as a principle.  So, =
I don't see the need for point b).

Your point 1 raises the issue of divergence, and I agree with you that =
"rough consensus" is not desirable here.  Having the OIF liaise to the =
IETF helps this as does the IETF replying.  Your suggestions to include =
the ospf and isis WGs is good advice, as is the suggestion to send a =
delta.  However the OIF is working directly from ITU-T requirements =
recommendations and would likely use the liaison process.

-----Original Message-----=20
From: [e-mail] [ =
mailto:[e-mail]]=20
Sent: Tuesday, March 09, 2004 14:53=20
To: Shew, Stephen [CAR:QT00:EXCH]=20
Cc: 'Kireeti Kompella'; [e-mail]; Alex Zinin; Bill Fenner=20
Subject: Re: Communication in response to the OIF=20


stephen:=20

actually, i disagree with your suggestion, and this=20
for three reasons:=20

1) you're part of the ason routing design team so you=20
    should be aware that there is an effort to avoid=20
    another protocol clash (and this independently of=20
    its origin since the result is the same) and thus=20
    the aim is to converge from the early beginning -=20
    this has been re-stated during the last ccamp wg=20

2) yes, there is a clear concern about the "right way"=20
    to approach a given problem, during the last iet59=20
    meeting, w/i each non-protocol specific wg where=20
    protocol(s) procedures/extensions and usage were=20
    proposed exactly the same concern was raised - so=20
    i would even include ospf wg (and is-is wg in case)=20
    in the loop -=20

3) if oif wants to put their requirement and solution=20
    on the fast track nothing prevents they submit their=20
    solution as an internet draft but from the below=20
    proposal it seems much better they deliver their=20
    delta requirements so that ietf could address both=20
    oif and itu-t needs at once (btw these requirements=20
    should be aligned from an architectural but also=20
    functional perspective since they were already=20
    backed up from each other)=20

- dimitri.=20

Stephen Shew wrote:=20

> On the OIF contacts:=20
> Jim Jones' email address is: [e-mail], he is the OIF=20
> Architecture/Signaling WG chair John McDonough's email address is:=20
> [e-mail],he is the Vice-President of the OIF=20
> Steve Joiner's email address is: [e-mail]=20
>=20
> On point b) below, the OIF is a Rec. A5 qualified organization with=20
> the ITU-T and has liaised work many times with SG15 of the ITU-T.  In=20
> several meetings in 2002, the OIF voted to adopt ASON architecture and =

> requirements (including G.7715 on routing) for its Implementation=20
> Agreements to comply with.  It should not alarm CCAMP that the OIF=20
> also has a cooperative relationship with ITU-T with regard to ASON=20
> routing.  Hence I suggest removing point b).=20
>=20
<snip>=20




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 21:54:24 +0000
Message-ID: <[e-mail]>
Date: Tue, 09 Mar 2004 22:55:40 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: "Ong, Lyndon" <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, [e-mail]
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

lyndon:

> -- egress control - yes.  
>    The question of what kind of target came up, BCP, Info, etc -
>    Whatever kind of document it winds up being, I think one
>    important result should be marking 3473 as being supplemented
>    by the new document to avoid any future confusion.
> 
> -- tunnel tracing - yes
> 
> -- rsvp for e2e recovery - there seemed to be still some concerns
>    at the meeting, so no (not yet)

the concern raised (*) by kohei is the following what are
the exact steps happening during preemption of LSPs that
are using the spare capacity in dedicated/shared re-routing
schemes - however, this concern is broader than simply this
document - and there are two solutions either the steps
are being detailed in this document or preemption is going
to be addressed in a specific document and reference will
be provided

(*) went to discuss privately since we didn't have the time
to discuss this point - kohei please correct me if i am
wrong here -

> -- segment recovery - no (not yet)
> 
> Cheers,
> 
> Lyndon
>    
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Thursday, March 04, 2004 3:46 AM
> To: [e-mail]
> Subject: Opinion sought on drafts being adopted by CCAMP
> 
> 
> All,
> 
> At the CCAMP meeting today we discussed making several drafts working group items. Can you
> please express your opinion (yes/no) on whether each of the following drafts is ready to
> become a CCAMP working group draft.
> 
> Feel free to express yes with reservations. If you have reservations or objections, please
> express them on the list. if you need anonymity for your comments then please filter them
> through the chairs.
> 
> Silence will be taken as meaning nothing, so please say what you think.
> 
> GMPLS Signaling Procedure For Egress Control
> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
> 
> Generic Tunnel Tracing Protocol (GTTP) Specification
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
> 
> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
> 
> GMPLS Based Segment Recovery
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt
> 
> Thank you,
> Adrian
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 21:41:02 +0000
Date: Tue, 9 Mar 2004 13:40:10 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>
cc: [e-mail], Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: RE: Communication in response to the OIF
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Lyndon,

On Tue, 9 Mar 2004, Ong, Lyndon wrote:

> Hi Kireeti,
>
> The response looks generally good and I think it is good
> to open lines of communication between the groups.

Thanks, that's good to hear.

> A
> couple of things:
>
> -- I did not make the presentation as a formal representative
> of OIF, since there is no such person at this time.  It was
> made at the request of Adrian following our interaction at
> the ITU SG15 Rapporteur's meeting.  My only role in this is
> editor of the draft document at OIF (oif2003.259).

Understood.  Hopefully, in the process of formalizing the relation
between the IETF and the OIF, such a person will indeed be named.

> -- I believe there is no intention to publicize the OIF
> demonstration as in any way IETF-related; however it might
> be difficult to describe the routing without using the
> acronym "OSPF" :o)  I think OIF will be sensitive to the
> concerns that you identify.

Good news!

> BTW, I do think that Steve Trowbridge brings up a good point,
> which is that this work, while currently differing in the
> protocol details, does support the concept of GMPLS and the
> optical network control plane and in that sense should be
> seen as a positive thing.

I see that aspect, but it is incomplete.  As you well know, 7713.2 is
based on GMPLS RSVP-TE, but there are serious divergences as well.  I
would rather not see that happen again -- which is why I initiated the
ASON Routing Requirements Design Team, for example.  Now, the same
seems to be happening with the OIF :-(

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 21:36:46 +0000
Message-ID: <[e-mail]>
Date: Tue, 09 Mar 2004 22:37:31 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Stephen Shew <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: Re: Communication in response to the OIF
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

stephen,

just a minor hint, not only "running code":

- but "interoperability" and "backward/forward compatibility"
   i'm closing the loop here with the mail from fred either it
   is 100% interoperable and compatible or it is not ospf (or
   is-is or something else), there is no graduation here (i.e
   i don't think there in any value in saying "oif has endorsed
   gmpls concepts with differing ospf protocol details")

- and in the "right way" reason why i'm asking protocol
   specific reviews by the corresponding working groups,

both are the guarantees that an SDO gives to both vendors
and operators is succeeding in their developments on a
long term basis.

---

Stephen Shew wrote:
> Dimitri, the point I was trying to make was that it should not alarm CCAMP
> that the OIF has a relationship with the ITU-T.  On the matter of not having
> work reviewed by CCAMP, surely you recognize that the OIF liaison itself is
> an opportunity for that review to occur.
> 
> Many individuals have participated in routing for optical networks over the
> last several years in IETF, ITU-T, T1X1 and OIF, including yourself.  That
> the OIF has entertained routing contributions is no secret.  Further, since
> OIF and IETF are working with G.7715 and G.7715.1 compliance in mind, the
> OIF work should yield improvements that can benefit everyone in this area.
> Again, this shouldn't be a cause of alarm from an organization that has
> "running code" as a principle.  So, I don't see the need for point b).
> 
> Your point 1 raises the issue of divergence, and I agree with you that
> "rough consensus" is not desirable here.  Having the OIF liaise to the IETF
> helps this as does the IETF replying.  Your suggestions to include the ospf
> and isis WGs is good advice, as is the suggestion to send a delta.  However
> the OIF is working directly from ITU-T requirements recommendations and
> would likely use the liaison process.
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] 
> Sent: Tuesday, March 09, 2004 14:53
> To: Shew, Stephen [CAR:QT00:EXCH]
> Cc: 'Kireeti Kompella'; [e-mail]; Alex Zinin; Bill Fenner
> Subject: Re: Communication in response to the OIF
> 
> 
> stephen:
> 
> actually, i disagree with your suggestion, and this
> for three reasons:
> 
> 1) you're part of the ason routing design team so you
>     should be aware that there is an effort to avoid
>     another protocol clash (and this independently of
>     its origin since the result is the same) and thus
>     the aim is to converge from the early beginning -
>     this has been re-stated during the last ccamp wg
> 
> 2) yes, there is a clear concern about the "right way"
>     to approach a given problem, during the last iet59
>     meeting, w/i each non-protocol specific wg where
>     protocol(s) procedures/extensions and usage were
>     proposed exactly the same concern was raised - so
>     i would even include ospf wg (and is-is wg in case)
>     in the loop -
> 
> 3) if oif wants to put their requirement and solution
>     on the fast track nothing prevents they submit their
>     solution as an internet draft but from the below
>     proposal it seems much better they deliver their
>     delta requirements so that ietf could address both
>     oif and itu-t needs at once (btw these requirements
>     should be aligned from an architectural but also
>     functional perspective since they were already
>     backed up from each other)
> 
> - dimitri.
> 
> Stephen Shew wrote:
> 
> 
>>On the OIF contacts:
>>Jim Jones' email address is: [e-mail], he is the OIF 
>>Architecture/Signaling WG chair John McDonough's email address is: 
>>[e-mail],he is the Vice-President of the OIF
>>Steve Joiner's email address is: [e-mail]
>>
>>On point b) below, the OIF is a Rec. A5 qualified organization with 
>>the ITU-T and has liaised work many times with SG15 of the ITU-T.  In 
>>several meetings in 2002, the OIF voted to adopt ASON architecture and 
>>requirements (including G.7715 on routing) for its Implementation 
>>Agreements to comply with.  It should not alarm CCAMP that the OIF 
>>also has a cooperative relationship with ITU-T with regard to ASON 
>>routing.  Hence I suggest removing point b).
>>
> 
> <snip>
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 21:35:03 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Adrian Farrel' <[e-mail]>, [e-mail]
Subject: RE: Opinion sought on drafts being adopted by CCAMP
Date: Tue, 9 Mar 2004 13:34:05 -0800 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Adrian,

Comments:

-- egress control - yes.  
   The question of what kind of target came up, BCP, Info, etc -
   Whatever kind of document it winds up being, I think one
   important result should be marking 3473 as being supplemented
   by the new document to avoid any future confusion.

-- tunnel tracing - yes

-- rsvp for e2e recovery - there seemed to be still some concerns
   at the meeting, so no (not yet)

-- segment recovery - no (not yet)

Cheers,

Lyndon
   

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Thursday, March 04, 2004 3:46 AM
To: [e-mail]
Subject: Opinion sought on drafts being adopted by CCAMP


All,

At the CCAMP meeting today we discussed making several drafts working group items. Can you
please express your opinion (yes/no) on whether each of the following drafts is ready to
become a CCAMP working group draft.

Feel free to express yes with reservations. If you have reservations or objections, please
express them on the list. if you need anonymity for your comments then please filter them
through the chairs.

Silence will be taken as meaning nothing, so please say what you think.

GMPLS Signaling Procedure For Egress Control
http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt

Generic Tunnel Tracing Protocol (GTTP) Specification
http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt

Thank you,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 21:34:33 +0000
Date: Tue, 9 Mar 2004 13:33:22 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: "Alanqar, Wesam I [NTK]" <[e-mail]>
cc: [e-mail], Stephen J Trowbridge <[e-mail]>, Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: RE: Communication in response to the OIF
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Wesam, Steve:

On Tue, 9 Mar 2004, Alanqar, Wesam I [NTK] wrote:

> I totally agree with Steve. The IETF core design team for routing is one
> example of good collaboration.

I'm glad to hear that.  Let's push forward to a common solution as
well, and that will close a good chapter!

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 21:31:23 +0000
Date: Tue, 9 Mar 2004 13:30:07 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Stephen Shew <[e-mail]>
cc: [e-mail], Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: RE: Communication in response to the OIF
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Stephen,

On Tue, 9 Mar 2004, Stephen Shew wrote:

> On the OIF contacts:
> Jim Jones' email address is: [e-mail], he is the OIF
> Architecture/Signaling WG chair
> John McDonough's email address is: [e-mail],he is the
> Vice-President of the OIF
> Steve Joiner's email address is: [e-mail]

Thanks!  I got these from several others as well -- thanks to all.

> On point b) below, the OIF is a Rec. A5 qualified organization with the
> ITU-T and has liaised work many times with SG15 of the ITU-T.  In several
> meetings in 2002, the OIF voted to adopt ASON architecture and requirements
> (including G.7715 on routing) for its Implementation Agreements to comply
> with.  It should not alarm CCAMP that the OIF also has a cooperative
> relationship with ITU-T with regard to ASON routing.  Hence I suggest
> removing point b).

Let me clarify: the concern stems not from the OIF having a
relationship with the ITU-T -- that is not a matter for the IETF to
worry about either way.  Rather, the alarm is that the OIF's work on
routing overlaps with the IETF's, and the resultant fragmentation and
confusion in the marketplace is undesirable.  Hence point b).

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 21:23:34 +0000
Date: Tue, 9 Mar 2004 13:22:10 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Stephen J Trowbridge <[e-mail]>
cc: Fred Stringer <[e-mail]>, [e-mail]
Subject: Re: Communication in response to the OIF
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Steve,

On Tue, 9 Mar 2004, Stephen J Trowbridge wrote:

Let me skip to your questions:

> If we take this as a given, the next questions I would ask are:
> - Is it better for IETF to disavow any association with the OIF
> effort, with the result being that multiple "descendants" of the
> GMPLS protocols (whether OIF is allowed to use the "GMPLS" term or
> not) compete with each other in the market; or would it be better to
> try to constructively engage with OIF to try to limit the
> proliferation of solutions and to bring the OIF solution in line
> with IETF principles?

It's really too early to answer this: we (CCAMP and OSPF WGs) haven't
looked at the OIF solution in detail yet.  However, at this point, the
IETF should disavow any endorsement of the OIF "OSPF" solution.  In
the light of the current work in the IETF, perhaps this is the right
answer even in the future.

If there are multiple "descendant" solutions, so be it.  The IETF
clearly owns OSPF and RSVP-TE, and any change MUST be validated by the
IETF.  I remember the innumerable debates where the ITU-T demanded
that the IETF *not* change SDH/G.709/..., and the IETF complied.  We
could have done otherwise, and created "descendants" of SDH, but as a
responsible SDO, we did not.  Let's see how the OIF proceeds before we
make judgments on its level of responsibility.

> - Is it better in the demo if IETF gets credit (and presumably good
> press) for the base protocols that were employed to make it happen,
> or should this look like OIF did this single-handedly? (I would
> guess that ITU-T will probably ask to get credit for the technology
> from their organization that was used to make the demo happen.
> Shouldn't we do the same?).

My opinion: we should let this look like the OIF did this
single-handedly (which they did, so anything else would be less than
honest).  And no, we should not do the same as your presumption of
the ITU-T's behaviour.  The issue is not who gets the credit, but
what happens to standards.

BTW, I am *very* sure that had the IETF modified SDH on its own and
organized a demo event for it, the ITU-T would not have rallied round
asking for credit; they (at least some factions therein) would have
raised a stink so vociferous it would take years to mend relations.
I have the scars to prove this.  So, let's not guess what SDOs would
do; let's just do the right thing ourselves.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 20:55:48 +0000
Message-ID: <[e-mail]>
From: "Ong, Lyndon" <[e-mail]>
To: 'Kireeti Kompella' <[e-mail]>, [e-mail]
Cc: Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: RE: Communication in response to the OIF
Date: Tue, 9 Mar 2004 12:55:10 -0800 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Kireeti,

The response looks generally good and I think it is good
to open lines of communication between the groups.  A
couple of things:

-- I did not make the presentation as a formal representative
of OIF, since there is no such person at this time.  It was
made at the request of Adrian following our interaction at
the ITU SG15 Rapporteur's meeting.  My only role in this is
editor of the draft document at OIF (oif2003.259).

-- I believe there is no intention to publicize the OIF 
demonstration as in any way IETF-related; however it might
be difficult to describe the routing without using the
acronym "OSPF" :o)  I think OIF will be sensitive to the
concerns that you identify.

BTW, I do think that Steve Trowbridge brings up a good point,
which is that this work, while currently differing in the
protocol details, does support the concept of GMPLS and the
optical network control plane and in that sense should be
seen as a positive thing.

Cheers,

Lyndon

-----Original Message-----
From: Kireeti Kompella [mailto:[e-mail]]
Sent: Tuesday, March 09, 2004 6:13 AM
To: [e-mail]
Cc: Alex Zinin; Bill Fenner
Subject: Communication in response to the OIF


Hi All,

Here's a first draft of a reply to the OIF.  Please comment to the
list by Monday, March 15 2004.

If someone has email addresses for Steve Joiner, Jim Jones and John
McDonough (and titles for the last two), that would be very helpful.

Thanks,
Kireeti.
--------

<Date>

 From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs

To: Mr. Steve Joiner, OIF Technical Committee Chair
Cc: Jim Jones,
Cc: John McDonough,
Cc: Alex Zinin,       IETF Routing Area Director
Cc: Bill Fenner,      IETF Routing Area Director

Dear Steve,

Thank you for your communication regarding the current status of OIF
signaling and routing work, and the associated documentation.  This
communication is in response.  As there is no formal liaison
relationship yet between the IETF and the OIF, this communication is
not treated as a liaison; hopefully, this situation will be rectified
soon.

Thank you too for allowing Mr. Lyndon Ong to present a synopsis of
the work going on at the OIF with regard to Intra-carrier E-NNI
routing.  It was both useful and enlightening.

However, both of these gave us cause for alarm, on two fronts:
a) The development of new or modified code points and procedures
   in OSPF without expert review from the OSPF WG in the IETF
   contravenes IETF procedure, especially as the IETF pays special
   attention to changes in protocols in the Routing Area, such as
   OSPF.
b) The development of routing for optical networks without expert
   review from the CCAMP WG is also a source of concern, especially
   in the light of a cooperative effort between the ITU-T and the
   IETF in exactly this area.

Mr. Ong's emphasis that this work was experimental and purely for the
purpose of testing alleviated some of our concerns.  It would be very
helpful to hear this officially from the OIF; furthermore, in the
interests of openness and full disclosure, we would strongly urge the
modification of a paragraph in the Introduction of the draft routing
document OIF2003.259 as follows:

   "The base protocol as defined by this document is OSPF with
    extensions for Traffic Engineering and GMPLS.  This document
    proposes to use GMPLS-OSPF to operate at each hierarchical
    level, with multiple such levels stacking up to form the
    routing hierarchy.  Extensions have been defined in the forms
    of (sub-) TLVs to accommodate the requirements as defined in the
    G.8080, G.7715, and G.7715.1.  Note that these extensions as
    currently specified are purely for the purpose of experimentation
    and testing; in particular, they have not yet been reviewed by
    the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
    use experimental codepoints, and as such must not be used in
    production deployments."

Mr. Ong also brought to our attention that the OIF will be holding
an interoperability demonstration of this specification at the
SuperComm in June 2004.  Due to the preliminary nature of this
specification, the IETF would strongly recommend that the words
OSPF, OSPF-TE and GMPLS not be used in the context of this
demonstration, nor that there be any implication that this work
has been reviewed or sanctioned by the IETF.

It would be helpful in determining the future relationship between
the IETF and the OIF to understand how the OIF intends to progress
this document.

 o Is this intended to become an Implementation Agreement in
   something close to its current form?

 o Does the OIF intend to submit this as a submission in the ITU-T
   SG15 to become a Recommendation?

 o Does the OIF intend to submit this document as an Internet Draft
   to become an IETF RFC?

Thank you for your attention in this matter, and for initiating this
dialogue.  We hope that this develops into a fruitful relationship.
To that end, we enclose a product of the joint work between the
ITU-T and the IETF on Routing Requirements for ASON.  This is a
work in progress, and we solicit your comments:
 - to identify any requirements that the OIF has over and above those
    requirements established by the ITU-T ASON model
 - to ensure that the solution developed within the IETF addresses
    the requirements of both the ITU-T and OIF.

We hope that your feedback will signal the beginning of an active
cooperation between the IETF and the OIF.

Sincerely,
<etc.>

<attachment: current version of GMPLS ASON Routing Requirements doc>



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 20:54:50 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-08.txt
Date: Tue, 09 Mar 2004 15:54:19 -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		: Link Management Protocol Management Information Base
	Author(s)	: M. Dubuc, S. Dharanikota, T. Nadeau, J. Lang, E. McGinnis
	Filename	: draft-ietf-ccamp-lmp-mib-08.txt
	Pages		: 82
	Date		: 2004-3-9
	
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 for modeling the Link
Management Protocol (LMP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-mib-08.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-lmp-mib-08.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-08.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-mib-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 20:51:42 +0000
Date: Tue, 9 Mar 2004 12:51:05 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
cc: [e-mail], Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: RE: Communication in response to the OIF
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Jerry,

On Tue, 9 Mar 2004, Ash, Gerald R (Jerry), ALABS wrote:

> Kireeti,
>
> I would not characterize the interactions between ITU-T and IETF as
> a "cooperative effort" at this point.  IMO "adversarial effort"
> would be more accurate, but "joint effort" might be more PC.

Well, there are two fronts (yes, now it sounds like a battle :-)):
a) signaling, and
b) routing.

On the signaling front, what you say is the case, at present.
However, with routing, the IETF and ITU-T have gotten off to a better
start, and hopefully we'll come up with a solution agreeable to all,
at least within the bounds of "rough consensus".

The communication with the OIF focussed on routing, hence the term
"cooperative effort".

> I don't see that much cooperation between ITU-T and IETF quite yet
> on GMPLS/ASON.  The GMPLS/ASON signaling effort is still suffering
> from deep differences in views on G.7713.2 versus
> http://ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt.
> I believe that the signaling piece of the OIF interoperability demo
> is based on G.7713.2.  The GMPLS/ASON routing effort also appears to
> have some significant differences in views at this point, stemming
> in part from differences arising out of G.7715.1 IMO.
>
> Hopefully this will all work out, but the tone at IETF-59 didn't
> give me a lot of hope that this "cooperative effort" is going happen
> any time soon.

I (eternal optimist) hope that routing will work out.  Where we go
with signaling is unfortunately still unclear.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 20:49:17 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Stephen J Trowbridge" <[e-mail]>, "Fred Stringer" <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, <[e-mail]>, "Alexey Zinin" <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: RE: Communication in response to the OIF
Date: Tue, 9 Mar 2004 12:48:37 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve,

I think you make very good points. I especially concur with
the idea of the IETF ensuring that it gets rightful credit for being the
originator of the GMPLS family of protocols, as that is both
constructive and beneficial.

It would be important to have acknowledged that the IETF has
been _instrumental_ in developing these protocols, and that other
organizations are proposing enhancements for particular specialized
uses (or something to that effect).

I am not sure what will be needed to get the various versions aligned, but
even if actual alignment (however defined) between the OIF version
and the IETF version does not occur by the demo, perhaps there could
be (by some agreement between the OIF and the IETF?) a statement
that the home of these protocols is the IETF, and that the organizations
are working actively to bring these under one umbrella.

(The implication being that the technology developed so rapidly that
there arose some differences between how various organizations applied
(or enhanced) it, but that these are now being cooperatively harmonized
for the benefit of the industry at large.)

-Vishal


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Stephen J Trowbridge
> Sent: Tuesday, March 09, 2004 10:59 AM
> To: Fred Stringer
> Cc: Kireeti Kompella; [e-mail]
> Subject: Re: Communication in response to the OIF
>
>
> Hi Fred,
> I think rather than any kind of knee jerk reaction, it is
> probably better to
> think before we act.
>
> It isn't really important whether we like the situation as it is
> now and whether
> or not we like what OIF has done. What we should consider is,
> starting from
> where things stand now, what sort of response is likely to lead
> to the best
> result for IETF and for the industry?
>
> I think it is a good bet that the OIF demo is going to occur
> whether or not we
> like what they have done. Participants have made investments to
> make this happen
> and it isn't going to stop now. And as you say, even with the
> "experimental"
> characterization of what they are doing, a demonstration like
> this in such a
> high profile venue will surely develop a measure of credibility
> for the solution.
>
> If we take this as a given, the next questions I would ask are:
> - Is it better for IETF to disavow any association with the OIF
> effort, with the
> result being that multiple "descendants" of the GMPLS protocols
> (whether OIF is
> allowed to use the "GMPLS" term or not) compete with each other
> in the market;
> or would it be better to try to constructively engage with OIF to
> try to limit
> the proliferation of solutions and to bring the OIF solution in
> line with IETF
> principles?
>
> - Is it better in the demo if IETF gets credit (and presumably
> good press) for
> the base protocols that were employed to make it happen, or
> should this look
> like OIF did this single-handedly? (I would guess that ITU-T will
> probably ask
> to get credit for the technology from their organization that was
> used to make
> the demo happen. Shouldn't we do the same?).
>
> Regards,
> Steve
>
> On 3/9/2004 8:28 AM, Fred Stringer wrote:
> > Hi Kireeti,
> > A comment from the lurking gallery if I may.
> > You are probably representing the committee opinion here, but
> there seems
> > to be a conflict in the  message.
> > You stated that since the work was emphasized by Mr. Ong as
> "experimental"
> > alleviated some concerns - but then there is the concern over
> the SuperComm
> > testing.
> > I don't think INTEROPERABILITY demonstration in public forum is purely
> > experimental.
> > I don't see why the concerns are alleviated. You don't want to clobber
> > Lyndon but I think the concern is justified. The industry has enough
> > problems without fracturing the protocols it depends upon.
> >
> > The request of not using OSPF, OSPF-TE and GMPLS in the demo
> has teeth and
> > is good.
> >
> > Of all the comments you were probably expecting I'm sure this
> is not one of
> > them. But the situation did move me to come a little out of my
> lurking status.
> >
> > cheers
> > Fred
> >
> >
> > At Tuesday09:13 AM 3/9/2004, Kireeti Kompella wrote:
> >
> >>Hi All,
> >>
> >>Here's a first draft of a reply to the OIF.  Please comment to the
> >>list by Monday, March 15 2004.
> >>
> >>If someone has email addresses for Steve Joiner, Jim Jones and John
> >>McDonough (and titles for the last two), that would be very helpful.
> >>
> >>Thanks,
> >>Kireeti.
> >>--------
> >>
> >><Date>
> >>
> >> From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs
> >>
> >>To: Mr. Steve Joiner, OIF Technical Committee Chair
> >>Cc: Jim Jones,
> >>Cc: John McDonough,
> >>Cc: Alex Zinin,       IETF Routing Area Director
> >>Cc: Bill Fenner,      IETF Routing Area Director
> >>
> >>Dear Steve,
> >>
> >>Thank you for your communication regarding the current status of OIF
> >>signaling and routing work, and the associated documentation.  This
> >>communication is in response.  As there is no formal liaison
> >>relationship yet between the IETF and the OIF, this communication is
> >>not treated as a liaison; hopefully, this situation will be rectified
> >>soon.
> >>
> >>Thank you too for allowing Mr. Lyndon Ong to present a synopsis of
> >>the work going on at the OIF with regard to Intra-carrier E-NNI
> >>routing.  It was both useful and enlightening.
> >>
> >>However, both of these gave us cause for alarm, on two fronts:
> >>a) The development of new or modified code points and procedures
> >>   in OSPF without expert review from the OSPF WG in the IETF
> >>   contravenes IETF procedure, especially as the IETF pays special
> >>   attention to changes in protocols in the Routing Area, such as
> >>   OSPF.
> >>b) The development of routing for optical networks without expert
> >>   review from the CCAMP WG is also a source of concern, especially
> >>   in the light of a cooperative effort between the ITU-T and the
> >>   IETF in exactly this area.
> >>
> >>Mr. Ong's emphasis that this work was experimental and purely for the
> >>purpose of testing alleviated some of our concerns.  It would be very
> >>helpful to hear this officially from the OIF; furthermore, in the
> >>interests of openness and full disclosure, we would strongly urge the
> >>modification of a paragraph in the Introduction of the draft routing
> >>document OIF2003.259 as follows:
> >>
> >>   "The base protocol as defined by this document is OSPF with
> >>    extensions for Traffic Engineering and GMPLS.  This document
> >>    proposes to use GMPLS-OSPF to operate at each hierarchical
> >>    level, with multiple such levels stacking up to form the
> >>    routing hierarchy.  Extensions have been defined in the forms
> >>    of (sub-) TLVs to accommodate the requirements as defined in the
> >>    G.8080, G.7715, and G.7715.1.  Note that these extensions as
> >>    currently specified are purely for the purpose of experimentation
> >>    and testing; in particular, they have not yet been reviewed by
> >>    the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
> >>    use experimental codepoints, and as such must not be used in
> >>    production deployments."
> >>
> >>Mr. Ong also brought to our attention that the OIF will be holding
> >>an interoperability demonstration of this specification at the
> >>SuperComm in June 2004.  Due to the preliminary nature of this
> >>specification, the IETF would strongly recommend that the words
> >>OSPF, OSPF-TE and GMPLS not be used in the context of this
> >>demonstration, nor that there be any implication that this work
> >>has been reviewed or sanctioned by the IETF.
> >>
> >>It would be helpful in determining the future relationship between
> >>the IETF and the OIF to understand how the OIF intends to progress
> >>this document.
> >>
> >> o Is this intended to become an Implementation Agreement in
> >>   something close to its current form?
> >>
> >> o Does the OIF intend to submit this as a submission in the ITU-T
> >>   SG15 to become a Recommendation?
> >>
> >> o Does the OIF intend to submit this document as an Internet Draft
> >>   to become an IETF RFC?
> >>
> >>Thank you for your attention in this matter, and for initiating this
> >>dialogue.  We hope that this develops into a fruitful relationship.
> >>To that end, we enclose a product of the joint work between the
> >>ITU-T and the IETF on Routing Requirements for ASON.  This is a
> >>work in progress, and we solicit your comments:
> >> - to identify any requirements that the OIF has over and above those
> >>    requirements established by the ITU-T ASON model
> >> - to ensure that the solution developed within the IETF addresses
> >>    the requirements of both the ITU-T and OIF.
> >>
> >>We hope that your feedback will signal the beginning of an active
> >>cooperation between the IETF and the OIF.
> >>
> >>Sincerely,
> >><etc.>
> >>
> >><attachment: current version of GMPLS ASON Routing Requirements doc>
> >
> >
> >
> >
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 20:45:27 +0000
Date: Tue, 9 Mar 2004 12:44:42 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Fred Stringer <[e-mail]>
cc: [e-mail]
Subject: Re: Communication in response to the OIF
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Fred,

On Tue, 9 Mar 2004, Fred Stringer wrote:

> A comment from the lurking gallery if I may.
> You are probably representing the committee opinion here, but there seems
> to be a conflict in the  message.
> You stated that since the work was emphasized by Mr. Ong as "experimental"
> alleviated some concerns - but then there is the concern over the SuperComm
> testing.
> I don't think INTEROPERABILITY demonstration in public forum is purely
> experimental.
> I don't see why the concerns are alleviated. You don't want to clobber
> Lyndon but I think the concern is justified. The industry has enough
> problems without fracturing the protocols it depends upon.

Thanks for your comments.  I agree that there is a tension between
"experimental" and "interoperability".  The value of an interop event
that uses experimental (and hence subject to change) code points and
extensions is debatable, but the OIF has been doing these events for a
long time now.  I doubt they will stop calling them interop events;
hopefully, they will at least state that they are experiments.

As for concerns being alleviated, perhaps when the questions that were
listed are answered, we'll have a better grasp of the seriousness of
this situation.

> The request of not using OSPF, OSPF-TE and GMPLS in the demo has teeth and
> is good.

Okay, good.

> Of all the comments you were probably expecting I'm sure this is not one of
> them. But the situation did move me to come a little out of my lurking status.

With the CCAMP WG, I don't expect ... I send my mails and duck :-)

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 20:33:54 +0000
Message-ID: <[e-mail]>
From: "Stephen Shew" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: RE: Communication in response to the OIF
Date: Tue, 9 Mar 2004 15:32:25 -0500 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40615.A1A4F9C0"

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_01C40615.A1A4F9C0
Content-Type: text/plain

Dimitri, the point I was trying to make was that it should not alarm CCAMP
that the OIF has a relationship with the ITU-T.  On the matter of not having
work reviewed by CCAMP, surely you recognize that the OIF liaison itself is
an opportunity for that review to occur.

Many individuals have participated in routing for optical networks over the
last several years in IETF, ITU-T, T1X1 and OIF, including yourself.  That
the OIF has entertained routing contributions is no secret.  Further, since
OIF and IETF are working with G.7715 and G.7715.1 compliance in mind, the
OIF work should yield improvements that can benefit everyone in this area.
Again, this shouldn't be a cause of alarm from an organization that has
"running code" as a principle.  So, I don't see the need for point b).

Your point 1 raises the issue of divergence, and I agree with you that
"rough consensus" is not desirable here.  Having the OIF liaise to the IETF
helps this as does the IETF replying.  Your suggestions to include the ospf
and isis WGs is good advice, as is the suggestion to send a delta.  However
the OIF is working directly from ITU-T requirements recommendations and
would likely use the liaison process.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Tuesday, March 09, 2004 14:53
To: Shew, Stephen [CAR:QT00:EXCH]
Cc: 'Kireeti Kompella'; [e-mail]; Alex Zinin; Bill Fenner
Subject: Re: Communication in response to the OIF


stephen:

actually, i disagree with your suggestion, and this
for three reasons:

1) you're part of the ason routing design team so you
    should be aware that there is an effort to avoid
    another protocol clash (and this independently of
    its origin since the result is the same) and thus
    the aim is to converge from the early beginning -
    this has been re-stated during the last ccamp wg

2) yes, there is a clear concern about the "right way"
    to approach a given problem, during the last iet59
    meeting, w/i each non-protocol specific wg where
    protocol(s) procedures/extensions and usage were
    proposed exactly the same concern was raised - so
    i would even include ospf wg (and is-is wg in case)
    in the loop -

3) if oif wants to put their requirement and solution
    on the fast track nothing prevents they submit their
    solution as an internet draft but from the below
    proposal it seems much better they deliver their
    delta requirements so that ietf could address both
    oif and itu-t needs at once (btw these requirements
    should be aligned from an architectural but also
    functional perspective since they were already
    backed up from each other)

- dimitri.

Stephen Shew wrote:

> On the OIF contacts:
> Jim Jones' email address is: [e-mail], he is the OIF 
> Architecture/Signaling WG chair John McDonough's email address is: 
> [e-mail],he is the Vice-President of the OIF
> Steve Joiner's email address is: [e-mail]
> 
> On point b) below, the OIF is a Rec. A5 qualified organization with 
> the ITU-T and has liaised work many times with SG15 of the ITU-T.  In 
> several meetings in 2002, the OIF voted to adopt ASON architecture and 
> requirements (including G.7715 on routing) for its Implementation 
> Agreements to comply with.  It should not alarm CCAMP that the OIF 
> also has a cooperative relationship with ITU-T with regard to ASON 
> routing.  Hence I suggest removing point b).
>
<snip>

------_=_NextPart_001_01C40615.A1A4F9C0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: Communication in response to the OIF</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dimitri, the point I was trying to make was that it =
should not alarm CCAMP that the OIF has a relationship with the =
ITU-T.&nbsp; On the matter of not having work reviewed by CCAMP, surely =
you recognize that the OIF liaison itself is an opportunity for that =
review to occur.</FONT></P>

<P><FONT SIZE=3D2>Many individuals have participated in routing for =
optical networks over the last several years in IETF, ITU-T, T1X1 and =
OIF, including yourself.&nbsp; That the OIF has entertained routing =
contributions is no secret.&nbsp; Further, since OIF and IETF are =
working with G.7715 and G.7715.1 compliance in mind, the OIF work =
should yield improvements that can benefit everyone in this area.&nbsp; =
Again, this shouldn't be a cause of alarm from an organization that has =
&quot;running code&quot; as a principle.&nbsp; So, I don't see the need =
for point b).</FONT></P>

<P><FONT SIZE=3D2>Your point 1 raises the issue of divergence, and I =
agree with you that &quot;rough consensus&quot; is not desirable =
here.&nbsp; Having the OIF liaise to the IETF helps this as does the =
IETF replying.&nbsp; Your suggestions to include the ospf and isis WGs =
is good advice, as is the suggestion to send a delta.&nbsp; However the =
OIF is working directly from ITU-T requirements recommendations and =
would likely use the liaison process.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:Dimitri.Papadimi=
[e-mail]</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 09, 2004 14:53</FONT>
<BR><FONT SIZE=3D2>To: Shew, Stephen [CAR:QT00:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'Kireeti Kompella'; [e-mail]; Alex =
Zinin; Bill Fenner</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Communication in response to the =
OIF</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>stephen:</FONT>
</P>

<P><FONT SIZE=3D2>actually, i disagree with your suggestion, and =
this</FONT>
<BR><FONT SIZE=3D2>for three reasons:</FONT>
</P>

<P><FONT SIZE=3D2>1) you're part of the ason routing design team so =
you</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; should be aware that there is an =
effort to avoid</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; another protocol clash (and this =
independently of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; its origin since the result is =
the same) and thus</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; the aim is to converge from the =
early beginning -</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; this has been re-stated during =
the last ccamp wg</FONT>
</P>

<P><FONT SIZE=3D2>2) yes, there is a clear concern about the =
&quot;right way&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; to approach a given problem, =
during the last iet59</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; meeting, w/i each non-protocol =
specific wg where</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; protocol(s) procedures/extensions =
and usage were</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; proposed exactly the same concern =
was raised - so</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; i would even include ospf wg (and =
is-is wg in case)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; in the loop -</FONT>
</P>

<P><FONT SIZE=3D2>3) if oif wants to put their requirement and =
solution</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; on the fast track nothing =
prevents they submit their</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; solution as an internet draft but =
from the below</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; proposal it seems much better =
they deliver their</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; delta requirements so that ietf =
could address both</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; oif and itu-t needs at once (btw =
these requirements</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; should be aligned from an =
architectural but also</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; functional perspective since they =
were already</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; backed up from each other)</FONT>
</P>

<P><FONT SIZE=3D2>- dimitri.</FONT>
</P>

<P><FONT SIZE=3D2>Stephen Shew wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; On the OIF contacts:</FONT>
<BR><FONT SIZE=3D2>&gt; Jim Jones' email address is: =
[e-mail], he is the OIF </FONT>
<BR><FONT SIZE=3D2>&gt; Architecture/Signaling WG chair John =
McDonough's email address is: </FONT>
<BR><FONT SIZE=3D2>&gt; [e-mail],he is the Vice-President of =
the OIF</FONT>
<BR><FONT SIZE=3D2>&gt; Steve Joiner's email address is: =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On point b) below, the OIF is a Rec. A5 =
qualified organization with </FONT>
<BR><FONT SIZE=3D2>&gt; the ITU-T and has liaised work many times with =
SG15 of the ITU-T.&nbsp; In </FONT>
<BR><FONT SIZE=3D2>&gt; several meetings in 2002, the OIF voted to =
adopt ASON architecture and </FONT>
<BR><FONT SIZE=3D2>&gt; requirements (including G.7715 on routing) for =
its Implementation </FONT>
<BR><FONT SIZE=3D2>&gt; Agreements to comply with.&nbsp; It should not =
alarm CCAMP that the OIF </FONT>
<BR><FONT SIZE=3D2>&gt; also has a cooperative relationship with ITU-T =
with regard to ASON </FONT>
<BR><FONT SIZE=3D2>&gt; routing.&nbsp; Hence I suggest removing point =
b).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C40615.A1A4F9C0--



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 19:51:55 +0000
Message-ID: <[e-mail]>
Date: Tue, 09 Mar 2004 20:53:15 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Stephen Shew <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: Re: Communication in response to the OIF
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

stephen:

actually, i disagree with your suggestion, and this
for three reasons:

1) you're part of the ason routing design team so you
    should be aware that there is an effort to avoid
    another protocol clash (and this independently of
    its origin since the result is the same) and thus
    the aim is to converge from the early beginning -
    this has been re-stated during the last ccamp wg

2) yes, there is a clear concern about the "right way"
    to approach a given problem, during the last iet59
    meeting, w/i each non-protocol specific wg where
    protocol(s) procedures/extensions and usage were
    proposed exactly the same concern was raised - so
    i would even include ospf wg (and is-is wg in case)
    in the loop -

3) if oif wants to put their requirement and solution
    on the fast track nothing prevents they submit their
    solution as an internet draft but from the below
    proposal it seems much better they deliver their
    delta requirements so that ietf could address both
    oif and itu-t needs at once (btw these requirements
    should be aligned from an architectural but also
    functional perspective since they were already
    backed up from each other)

- dimitri.

Stephen Shew wrote:

> On the OIF contacts:
> Jim Jones' email address is: [e-mail], he is the OIF
> Architecture/Signaling WG chair
> John McDonough's email address is: [e-mail],he is the
> Vice-President of the OIF
> Steve Joiner's email address is: [e-mail]
> 
> On point b) below, the OIF is a Rec. A5 qualified organization with the
> ITU-T and has liaised work many times with SG15 of the ITU-T.  In several
> meetings in 2002, the OIF voted to adopt ASON architecture and requirements
> (including G.7715 on routing) for its Implementation Agreements to comply
> with.  It should not alarm CCAMP that the OIF also has a cooperative
> relationship with ITU-T with regard to ASON routing.  Hence I suggest
> removing point b).
> 
> -----Original Message-----
> From: Kireeti Kompella [mailto:[e-mail]] 
> Sent: Tuesday, March 09, 2004 09:13
> To: [e-mail]
> Cc: Alex Zinin; Bill Fenner
> Subject: Communication in response to the OIF
> 
> 
> Hi All,
> 
> Here's a first draft of a reply to the OIF.  Please comment to the list by
> Monday, March 15 2004.
> 
> If someone has email addresses for Steve Joiner, Jim Jones and John
> McDonough (and titles for the last two), that would be very helpful.
> 
> Thanks,
> Kireeti.
> --------
> 
> <Date>
> 
>  From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs
> 
> To: Mr. Steve Joiner, OIF Technical Committee Chair
> Cc: Jim Jones,
> Cc: John McDonough,
> Cc: Alex Zinin,       IETF Routing Area Director
> Cc: Bill Fenner,      IETF Routing Area Director
> 
> Dear Steve,
> 
> Thank you for your communication regarding the current status of OIF
> signaling and routing work, and the associated documentation.  This
> communication is in response.  As there is no formal liaison relationship
> yet between the IETF and the OIF, this communication is not treated as a
> liaison; hopefully, this situation will be rectified soon.
> 
> Thank you too for allowing Mr. Lyndon Ong to present a synopsis of the work
> going on at the OIF with regard to Intra-carrier E-NNI routing.  It was both
> useful and enlightening.
> 
> However, both of these gave us cause for alarm, on two fronts:
> a) The development of new or modified code points and procedures
>    in OSPF without expert review from the OSPF WG in the IETF
>    contravenes IETF procedure, especially as the IETF pays special
>    attention to changes in protocols in the Routing Area, such as
>    OSPF.
> b) The development of routing for optical networks without expert
>    review from the CCAMP WG is also a source of concern, especially
>    in the light of a cooperative effort between the ITU-T and the
>    IETF in exactly this area.
> 
> Mr. Ong's emphasis that this work was experimental and purely for the
> purpose of testing alleviated some of our concerns.  It would be very
> helpful to hear this officially from the OIF; furthermore, in the interests
> of openness and full disclosure, we would strongly urge the modification of
> a paragraph in the Introduction of the draft routing document OIF2003.259 as
> follows:
> 
>    "The base protocol as defined by this document is OSPF with
>     extensions for Traffic Engineering and GMPLS.  This document
>     proposes to use GMPLS-OSPF to operate at each hierarchical
>     level, with multiple such levels stacking up to form the
>     routing hierarchy.  Extensions have been defined in the forms
>     of (sub-) TLVs to accommodate the requirements as defined in the
>     G.8080, G.7715, and G.7715.1.  Note that these extensions as
>     currently specified are purely for the purpose of experimentation
>     and testing; in particular, they have not yet been reviewed by
>     the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
>     use experimental codepoints, and as such must not be used in
>     production deployments."
> 
> Mr. Ong also brought to our attention that the OIF will be holding an
> interoperability demonstration of this specification at the SuperComm in
> June 2004.  Due to the preliminary nature of this specification, the IETF
> would strongly recommend that the words OSPF, OSPF-TE and GMPLS not be used
> in the context of this demonstration, nor that there be any implication that
> this work has been reviewed or sanctioned by the IETF.
> 
> It would be helpful in determining the future relationship between the IETF
> and the OIF to understand how the OIF intends to progress this document.
> 
>  o Is this intended to become an Implementation Agreement in
>    something close to its current form?
> 
>  o Does the OIF intend to submit this as a submission in the ITU-T
>    SG15 to become a Recommendation?
> 
>  o Does the OIF intend to submit this document as an Internet Draft
>    to become an IETF RFC?
> 
> Thank you for your attention in this matter, and for initiating this
> dialogue.  We hope that this develops into a fruitful relationship. To that
> end, we enclose a product of the joint work between the ITU-T and the IETF
> on Routing Requirements for ASON.  This is a work in progress, and we
> solicit your comments:
>  - to identify any requirements that the OIF has over and above those
>     requirements established by the ITU-T ASON model
>  - to ensure that the solution developed within the IETF addresses
>     the requirements of both the ITU-T and OIF.
> 
> We hope that your feedback will signal the beginning of an active
> cooperation between the IETF and the OIF.
> 
> Sincerely,
> <etc.>
> 
> <attachment: current version of GMPLS ASON Routing Requirements doc>
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 19:28:10 +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: Communication in response to the OIF
Date: Tue, 9 Mar 2004 13:26:51 -0600
Message-ID: <[e-mail]>
Thread-Topic: Communication in response to the OIF
Thread-Index: AcQGC46kKReWDwbSThivngNGLoTkhQAAFLbw
From: "Alanqar, Wesam I [NTK]" <[e-mail]>
To: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, <[e-mail]>, "Stephen J Trowbridge" <[e-mail]>, "Alex Zinin" <[e-mail]>, "Bill Fenner" <[e-mail]>

Jerry,

I totally agree with Steve. The IETF core design team for routing is one
example of good collaboration. The aim of the team was to provide CCAMP
with a core team draft illustrating the ASON routing requirements based
on ITU-T G.7715 and G.7715.1. I believe that we can handle the signaling
issues via a similar method.=20

Thanks,
-Wesam

Wesam Alanqar                        =20
Sprint- Technology Research and Development

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen J Trowbridge
Sent: Tuesday, March 09, 2004 1:18 PM
To: Ash, Gerald R (Jerry), ALABS
Cc: Kireeti Kompella; [e-mail]; Alex Zinin; Bill Fenner
Subject: Re: Communication in response to the OIF


Jerry,
I see you missed the Q.14/15 Rapporteur's meeting in Chicago.

Once upon a time, what you say was true. ITU-T and IETF got off to a
very rocky start. ITU-T (which was accustomed to collaborating with
other standards
organizations) would routinely send information about what they were
doing to IETF (which has historically gone it alone). Most in IETF would
either not even read what ITU-T sent over, or would just get steamed
about the fact that ITU-T was doing something different without writing
down their concerns and sending it back to ITU-T in a form that could be
considered in their deliberations.

But of late, through a combination of cross participation (Kireeti and
Adrian have each attended Q.14 meetings) and regular and frequent
communications, this has been steadily improving. Many of the issues and
differences have been resolved, and of the issues and differences that
still remain, I think there is a growing understanding within each
organization of why the other organization has taken the direction they
have.

So let's not live in the past. Yes, things were very bad at the start.
Now we are talking, and things are getting steadily better. I think it
is accurate to characterize the way we are working today as cooperation.
Regards, Steve

On 3/9/2004 11:22 AM, Ash, Gerald R (Jerry), ALABS wrote:
> Kireeti,
>=20
> I would not characterize the interactions between ITU-T and IETF as a=20
> "cooperative effort" at this point.  IMO "adversarial effort" would be

> more accurate, but "joint effort" might be more PC.
>=20
> I don't see that much cooperation between ITU-T and IETF quite yet on=20
> GMPLS/ASON.  The GMPLS/ASON signaling effort is still suffering from=20
> deep differences in views on G.7713.2 versus=20
> http://ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01
> .txt.  I believe that the signaling piece of the OIF interoperability=20
> demo is based on G.7713.2.  The GMPLS/ASON routing effort also appears

> to have some significant differences in views at this point, stemming=20
> in part from differences arising out of G.7715.1 IMO.
>=20
> Hopefully this will all work out, but the tone at IETF-59 didn't give=20
> me a lot of hope that this "cooperative effort" is going happen any=20
> time soon.
>=20
> Thanks,
> Jerry
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Kireeti Kompella
> Sent: Tuesday, March 09, 2004 9:13 AM
> To: [e-mail]
> Cc: Alex Zinin; Bill Fenner
> Subject: Communication in response to the OIF
>=20
>=20
> Hi All,
>=20
> Here's a first draft of a reply to the OIF.  Please comment to the=20
> list by Monday, March 15 2004.
>=20
> If someone has email addresses for Steve Joiner, Jim Jones and John=20
> McDonough (and titles for the last two), that would be very helpful.
>=20
> Thanks,
> Kireeti.
> --------
>=20
> <Date>
>=20
>  From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group=20
> Chairs
>=20
> To: Mr. Steve Joiner, OIF Technical Committee Chair
> Cc: Jim Jones,
> Cc: John McDonough,
> Cc: Alex Zinin,       IETF Routing Area Director
> Cc: Bill Fenner,      IETF Routing Area Director
>=20
> Dear Steve,
>=20
> Thank you for your communication regarding the current status of OIF=20
> signaling and routing work, and the associated documentation.  This=20
> communication is in response.  As there is no formal liaison=20
> relationship yet between the IETF and the OIF, this communication is=20
> not treated as a liaison; hopefully, this situation will be rectified=20
> soon.
>=20
> Thank you too for allowing Mr. Lyndon Ong to present a synopsis of the

> work going on at the OIF with regard to Intra-carrier E-NNI routing. =20
> It was both useful and enlightening.
>=20
> However, both of these gave us cause for alarm, on two fronts:
> a) The development of new or modified code points and procedures
>    in OSPF without expert review from the OSPF WG in the IETF
>    contravenes IETF procedure, especially as the IETF pays special
>    attention to changes in protocols in the Routing Area, such as
>    OSPF.
> b) The development of routing for optical networks without expert
>    review from the CCAMP WG is also a source of concern, especially
>    in the light of a cooperative effort between the ITU-T and the
>    IETF in exactly this area.
>=20
> Mr. Ong's emphasis that this work was experimental and purely for the=20
> purpose of testing alleviated some of our concerns.  It would be very=20
> helpful to hear this officially from the OIF; furthermore, in the=20
> interests of openness and full disclosure, we would strongly urge the=20
> modification of a paragraph in the Introduction of the draft routing=20
> document OIF2003.259 as follows:
>=20
>    "The base protocol as defined by this document is OSPF with
>     extensions for Traffic Engineering and GMPLS.  This document
>     proposes to use GMPLS-OSPF to operate at each hierarchical
>     level, with multiple such levels stacking up to form the
>     routing hierarchy.  Extensions have been defined in the forms
>     of (sub-) TLVs to accommodate the requirements as defined in the
>     G.8080, G.7715, and G.7715.1.  Note that these extensions as
>     currently specified are purely for the purpose of experimentation
>     and testing; in particular, they have not yet been reviewed by
>     the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
>     use experimental codepoints, and as such must not be used in
>     production deployments."
>=20
> Mr. Ong also brought to our attention that the OIF will be holding an=20
> interoperability demonstration of this specification at the SuperComm=20
> in June 2004.  Due to the preliminary nature of this specification,=20
> the IETF would strongly recommend that the words OSPF, OSPF-TE and=20
> GMPLS not be used in the context of this demonstration, nor that there

> be any implication that this work has been reviewed or sanctioned by=20
> the IETF.
>=20
> It would be helpful in determining the future relationship between the

> IETF and the OIF to understand how the OIF intends to progress this=20
> document.
>=20
>  o Is this intended to become an Implementation Agreement in
>    something close to its current form?
>=20
>  o Does the OIF intend to submit this as a submission in the ITU-T
>    SG15 to become a Recommendation?
>=20
>  o Does the OIF intend to submit this document as an Internet Draft
>    to become an IETF RFC?
>=20
> Thank you for your attention in this matter, and for initiating this=20
> dialogue.  We hope that this develops into a fruitful relationship. To

> that end, we enclose a product of the joint work between the ITU-T and

> the IETF on Routing Requirements for ASON.  This is a work in=20
> progress, and we solicit your comments:
>  - to identify any requirements that the OIF has over and above those
>     requirements established by the ITU-T ASON model
>  - to ensure that the solution developed within the IETF addresses
>     the requirements of both the ITU-T and OIF.
>=20
> We hope that your feedback will signal the beginning of an active=20
> cooperation between the IETF and the OIF.
>=20
> Sincerely,
> <etc.>
>=20
> <attachment: current version of GMPLS ASON Routing Requirements doc>
>=20
>=20






Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 19:18:55 +0000
Message-ID: <[e-mail]>
Date: Tue, 09 Mar 2004 12:17:51 -0700
From: Stephen J Trowbridge <[e-mail]>
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: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
CC: Kireeti Kompella <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: Re: Communication in response to the OIF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jerry,
I see you missed the Q.14/15 Rapporteur's meeting in Chicago.

Once upon a time, what you say was true. ITU-T and IETF got off to a very rocky
start. ITU-T (which was accustomed to collaborating with other standards
organizations) would routinely send information about what they were doing to
IETF (which has historically gone it alone). Most in IETF would either not even
read what ITU-T sent over, or would just get steamed about the fact that ITU-T
was doing something different without writing down their concerns and sending it
back to ITU-T in a form that could be considered in their deliberations.

But of late, through a combination of cross participation (Kireeti and Adrian
have each attended Q.14 meetings) and regular and frequent communications, this
has been steadily improving. Many of the issues and differences have been
resolved, and of the issues and differences that still remain, I think there is
a growing understanding within each organization of why the other organization
has taken the direction they have.

So let's not live in the past. Yes, things were very bad at the start. Now we
are talking, and things are getting steadily better. I think it is accurate to
characterize the way we are working today as cooperation.
Regards,
Steve

On 3/9/2004 11:22 AM, Ash, Gerald R (Jerry), ALABS wrote:
> Kireeti,
> 
> I would not characterize the interactions between ITU-T and IETF as a "cooperative effort" at this point.  IMO "adversarial effort" would be more accurate, but "joint effort" might be more PC.
> 
> I don't see that much cooperation between ITU-T and IETF quite yet on GMPLS/ASON.  The GMPLS/ASON signaling effort is still suffering from deep differences in views on G.7713.2 versus http://ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt.  I believe that the signaling piece of the OIF interoperability demo is based on G.7713.2.  The GMPLS/ASON routing effort also appears to have some significant differences in views at this point, stemming in part from differences arising out of G.7715.1 IMO.
> 
> Hopefully this will all work out, but the tone at IETF-59 didn't give me a lot of hope that this "cooperative effort" is going happen any time soon.
> 
> Thanks,
> Jerry
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Kireeti Kompella
> Sent: Tuesday, March 09, 2004 9:13 AM
> To: [e-mail]
> Cc: Alex Zinin; Bill Fenner
> Subject: Communication in response to the OIF
> 
> 
> Hi All,
> 
> Here's a first draft of a reply to the OIF.  Please comment to the
> list by Monday, March 15 2004.
> 
> If someone has email addresses for Steve Joiner, Jim Jones and John
> McDonough (and titles for the last two), that would be very helpful.
> 
> Thanks,
> Kireeti.
> --------
> 
> <Date>
> 
>  From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs
> 
> To: Mr. Steve Joiner, OIF Technical Committee Chair
> Cc: Jim Jones,
> Cc: John McDonough,
> Cc: Alex Zinin,       IETF Routing Area Director
> Cc: Bill Fenner,      IETF Routing Area Director
> 
> Dear Steve,
> 
> Thank you for your communication regarding the current status of OIF
> signaling and routing work, and the associated documentation.  This
> communication is in response.  As there is no formal liaison
> relationship yet between the IETF and the OIF, this communication is
> not treated as a liaison; hopefully, this situation will be rectified
> soon.
> 
> Thank you too for allowing Mr. Lyndon Ong to present a synopsis of
> the work going on at the OIF with regard to Intra-carrier E-NNI
> routing.  It was both useful and enlightening.
> 
> However, both of these gave us cause for alarm, on two fronts:
> a) The development of new or modified code points and procedures
>    in OSPF without expert review from the OSPF WG in the IETF
>    contravenes IETF procedure, especially as the IETF pays special
>    attention to changes in protocols in the Routing Area, such as
>    OSPF.
> b) The development of routing for optical networks without expert
>    review from the CCAMP WG is also a source of concern, especially
>    in the light of a cooperative effort between the ITU-T and the
>    IETF in exactly this area.
> 
> Mr. Ong's emphasis that this work was experimental and purely for the
> purpose of testing alleviated some of our concerns.  It would be very
> helpful to hear this officially from the OIF; furthermore, in the
> interests of openness and full disclosure, we would strongly urge the
> modification of a paragraph in the Introduction of the draft routing
> document OIF2003.259 as follows:
> 
>    "The base protocol as defined by this document is OSPF with
>     extensions for Traffic Engineering and GMPLS.  This document
>     proposes to use GMPLS-OSPF to operate at each hierarchical
>     level, with multiple such levels stacking up to form the
>     routing hierarchy.  Extensions have been defined in the forms
>     of (sub-) TLVs to accommodate the requirements as defined in the
>     G.8080, G.7715, and G.7715.1.  Note that these extensions as
>     currently specified are purely for the purpose of experimentation
>     and testing; in particular, they have not yet been reviewed by
>     the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
>     use experimental codepoints, and as such must not be used in
>     production deployments."
> 
> Mr. Ong also brought to our attention that the OIF will be holding
> an interoperability demonstration of this specification at the
> SuperComm in June 2004.  Due to the preliminary nature of this
> specification, the IETF would strongly recommend that the words
> OSPF, OSPF-TE and GMPLS not be used in the context of this
> demonstration, nor that there be any implication that this work
> has been reviewed or sanctioned by the IETF.
> 
> It would be helpful in determining the future relationship between
> the IETF and the OIF to understand how the OIF intends to progress
> this document.
> 
>  o Is this intended to become an Implementation Agreement in
>    something close to its current form?
> 
>  o Does the OIF intend to submit this as a submission in the ITU-T
>    SG15 to become a Recommendation?
> 
>  o Does the OIF intend to submit this document as an Internet Draft
>    to become an IETF RFC?
> 
> Thank you for your attention in this matter, and for initiating this
> dialogue.  We hope that this develops into a fruitful relationship.
> To that end, we enclose a product of the joint work between the
> ITU-T and the IETF on Routing Requirements for ASON.  This is a
> work in progress, and we solicit your comments:
>  - to identify any requirements that the OIF has over and above those
>     requirements established by the ITU-T ASON model
>  - to ensure that the solution developed within the IETF addresses
>     the requirements of both the ITU-T and OIF.
> 
> We hope that your feedback will signal the beginning of an active
> cooperation between the IETF and the OIF.
> 
> Sincerely,
> <etc.>
> 
> <attachment: current version of GMPLS ASON Routing Requirements doc>
> 
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 19:10:43 +0000
Message-ID: <[e-mail]>
From: "Stephen Shew" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, [e-mail]
Cc: Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: RE: Communication in response to the OIF
Date: Tue, 9 Mar 2004 14:09:51 -0500 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4060A.18D6F31A"

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_01C4060A.18D6F31A
Content-Type: text/plain


On the OIF contacts:
Jim Jones' email address is: [e-mail], he is the OIF
Architecture/Signaling WG chair
John McDonough's email address is: [e-mail],he is the
Vice-President of the OIF
Steve Joiner's email address is: [e-mail]

On point b) below, the OIF is a Rec. A5 qualified organization with the
ITU-T and has liaised work many times with SG15 of the ITU-T.  In several
meetings in 2002, the OIF voted to adopt ASON architecture and requirements
(including G.7715 on routing) for its Implementation Agreements to comply
with.  It should not alarm CCAMP that the OIF also has a cooperative
relationship with ITU-T with regard to ASON routing.  Hence I suggest
removing point b).

-----Original Message-----
From: Kireeti Kompella [mailto:[e-mail]] 
Sent: Tuesday, March 09, 2004 09:13
To: [e-mail]
Cc: Alex Zinin; Bill Fenner
Subject: Communication in response to the OIF


Hi All,

Here's a first draft of a reply to the OIF.  Please comment to the list by
Monday, March 15 2004.

If someone has email addresses for Steve Joiner, Jim Jones and John
McDonough (and titles for the last two), that would be very helpful.

Thanks,
Kireeti.
--------

<Date>

 From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs

To: Mr. Steve Joiner, OIF Technical Committee Chair
Cc: Jim Jones,
Cc: John McDonough,
Cc: Alex Zinin,       IETF Routing Area Director
Cc: Bill Fenner,      IETF Routing Area Director

Dear Steve,

Thank you for your communication regarding the current status of OIF
signaling and routing work, and the associated documentation.  This
communication is in response.  As there is no formal liaison relationship
yet between the IETF and the OIF, this communication is not treated as a
liaison; hopefully, this situation will be rectified soon.

Thank you too for allowing Mr. Lyndon Ong to present a synopsis of the work
going on at the OIF with regard to Intra-carrier E-NNI routing.  It was both
useful and enlightening.

However, both of these gave us cause for alarm, on two fronts:
a) The development of new or modified code points and procedures
   in OSPF without expert review from the OSPF WG in the IETF
   contravenes IETF procedure, especially as the IETF pays special
   attention to changes in protocols in the Routing Area, such as
   OSPF.
b) The development of routing for optical networks without expert
   review from the CCAMP WG is also a source of concern, especially
   in the light of a cooperative effort between the ITU-T and the
   IETF in exactly this area.

Mr. Ong's emphasis that this work was experimental and purely for the
purpose of testing alleviated some of our concerns.  It would be very
helpful to hear this officially from the OIF; furthermore, in the interests
of openness and full disclosure, we would strongly urge the modification of
a paragraph in the Introduction of the draft routing document OIF2003.259 as
follows:

   "The base protocol as defined by this document is OSPF with
    extensions for Traffic Engineering and GMPLS.  This document
    proposes to use GMPLS-OSPF to operate at each hierarchical
    level, with multiple such levels stacking up to form the
    routing hierarchy.  Extensions have been defined in the forms
    of (sub-) TLVs to accommodate the requirements as defined in the
    G.8080, G.7715, and G.7715.1.  Note that these extensions as
    currently specified are purely for the purpose of experimentation
    and testing; in particular, they have not yet been reviewed by
    the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
    use experimental codepoints, and as such must not be used in
    production deployments."

Mr. Ong also brought to our attention that the OIF will be holding an
interoperability demonstration of this specification at the SuperComm in
June 2004.  Due to the preliminary nature of this specification, the IETF
would strongly recommend that the words OSPF, OSPF-TE and GMPLS not be used
in the context of this demonstration, nor that there be any implication that
this work has been reviewed or sanctioned by the IETF.

It would be helpful in determining the future relationship between the IETF
and the OIF to understand how the OIF intends to progress this document.

 o Is this intended to become an Implementation Agreement in
   something close to its current form?

 o Does the OIF intend to submit this as a submission in the ITU-T
   SG15 to become a Recommendation?

 o Does the OIF intend to submit this document as an Internet Draft
   to become an IETF RFC?

Thank you for your attention in this matter, and for initiating this
dialogue.  We hope that this develops into a fruitful relationship. To that
end, we enclose a product of the joint work between the ITU-T and the IETF
on Routing Requirements for ASON.  This is a work in progress, and we
solicit your comments:
 - to identify any requirements that the OIF has over and above those
    requirements established by the ITU-T ASON model
 - to ensure that the solution developed within the IETF addresses
    the requirements of both the ITU-T and OIF.

We hope that your feedback will signal the beginning of an active
cooperation between the IETF and the OIF.

Sincerely,
<etc.>

<attachment: current version of GMPLS ASON Routing Requirements doc>


------_=_NextPart_001_01C4060A.18D6F31A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: Communication in response to the OIF</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>On the OIF contacts:</FONT>
<BR><FONT SIZE=3D2>Jim Jones' email address is: =
[e-mail], he is the OIF Architecture/Signaling WG =
chair</FONT>
<BR><FONT SIZE=3D2>John McDonough's email address is: =
[e-mail],he is the Vice-President of the OIF</FONT>
<BR><FONT SIZE=3D2>Steve Joiner's email address is: =
[e-mail]</FONT>
</P>

<P><FONT SIZE=3D2>On point b) below, the OIF is a Rec. A5 qualified =
organization with the ITU-T and has liaised work many times with SG15 =
of the ITU-T.&nbsp; In several meetings in 2002, the OIF voted to adopt =
ASON architecture and requirements (including G.7715 on routing) for =
its Implementation Agreements to comply with.&nbsp; It should not alarm =
CCAMP that the OIF also has a cooperative relationship with ITU-T with =
regard to ASON routing.&nbsp; Hence I suggest removing point =
b).</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kireeti Kompella [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 09, 2004 09:13</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: Alex Zinin; Bill Fenner</FONT>
<BR><FONT SIZE=3D2>Subject: Communication in response to the OIF</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi All,</FONT>
</P>

<P><FONT SIZE=3D2>Here's a first draft of a reply to the OIF.&nbsp; =
Please comment to the list by Monday, March 15 2004.</FONT>
</P>

<P><FONT SIZE=3D2>If someone has email addresses for Steve Joiner, Jim =
Jones and John McDonough (and titles for the last two), that would be =
very helpful.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Kireeti.</FONT>
<BR><FONT SIZE=3D2>--------</FONT>
</P>

<P><FONT SIZE=3D2>&lt;Date&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;From: Kireeti Kompella &amp; Adrian Farrel, =
IETF CCAMP Working Group Chairs</FONT>
</P>

<P><FONT SIZE=3D2>To: Mr. Steve Joiner, OIF Technical Committee =
Chair</FONT>
<BR><FONT SIZE=3D2>Cc: Jim Jones,</FONT>
<BR><FONT SIZE=3D2>Cc: John McDonough,</FONT>
<BR><FONT SIZE=3D2>Cc: Alex Zinin,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
IETF Routing Area Director</FONT>
<BR><FONT SIZE=3D2>Cc: Bill Fenner,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IETF =
Routing Area Director</FONT>
</P>

<P><FONT SIZE=3D2>Dear Steve,</FONT>
</P>

<P><FONT SIZE=3D2>Thank you for your communication regarding the =
current status of OIF signaling and routing work, and the associated =
documentation.&nbsp; This communication is in response.&nbsp; As there =
is no formal liaison relationship yet between the IETF and the OIF, =
this communication is not treated as a liaison; hopefully, this =
situation will be rectified soon.</FONT></P>

<P><FONT SIZE=3D2>Thank you too for allowing Mr. Lyndon Ong to present =
a synopsis of the work going on at the OIF with regard to Intra-carrier =
E-NNI routing.&nbsp; It was both useful and enlightening.</FONT></P>

<P><FONT SIZE=3D2>However, both of these gave us cause for alarm, on =
two fronts:</FONT>
<BR><FONT SIZE=3D2>a) The development of new or modified code points =
and procedures</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; in OSPF without expert review from the =
OSPF WG in the IETF</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; contravenes IETF procedure, especially =
as the IETF pays special</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; attention to changes in protocols in =
the Routing Area, such as</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; OSPF.</FONT>
<BR><FONT SIZE=3D2>b) The development of routing for optical networks =
without expert</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; review from the CCAMP WG is also a =
source of concern, especially</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; in the light of a cooperative effort =
between the ITU-T and the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; IETF in exactly this area.</FONT>
</P>

<P><FONT SIZE=3D2>Mr. Ong's emphasis that this work was experimental =
and purely for the purpose of testing alleviated some of our =
concerns.&nbsp; It would be very helpful to hear this officially from =
the OIF; furthermore, in the interests of openness and full disclosure, =
we would strongly urge the modification of a paragraph in the =
Introduction of the draft routing document OIF2003.259 as =
follows:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &quot;The base protocol as defined by =
this document is OSPF with</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; extensions for Traffic =
Engineering and GMPLS.&nbsp; This document</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; proposes to use GMPLS-OSPF to =
operate at each hierarchical</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; level, with multiple such levels =
stacking up to form the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; routing hierarchy.&nbsp; =
Extensions have been defined in the forms</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; of (sub-) TLVs to accommodate the =
requirements as defined in the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; G.8080, G.7715, and =
G.7715.1.&nbsp; Note that these extensions as</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; currently specified are purely =
for the purpose of experimentation</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; and testing; in particular, they =
have not yet been reviewed by</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; the OSPF and CCAMP Working Groups =
in the IETF.&nbsp; Furthermore they</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; use experimental codepoints, and =
as such must not be used in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; production =
deployments.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Mr. Ong also brought to our attention that the OIF =
will be holding an interoperability demonstration of this specification =
at the SuperComm in June 2004.&nbsp; Due to the preliminary nature of =
this specification, the IETF would strongly recommend that the words =
OSPF, OSPF-TE and GMPLS not be used in the context of this =
demonstration, nor that there be any implication that this work has =
been reviewed or sanctioned by the IETF.</FONT></P>

<P><FONT SIZE=3D2>It would be helpful in determining the future =
relationship between the IETF and the OIF to understand how the OIF =
intends to progress this document.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;o Is this intended to become an Implementation =
Agreement in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; something close to its current =
form?</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;o Does the OIF intend to submit this as a =
submission in the ITU-T</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; SG15 to become a Recommendation?</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;o Does the OIF intend to submit this document =
as an Internet Draft</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; to become an IETF RFC?</FONT>
</P>

<P><FONT SIZE=3D2>Thank you for your attention in this matter, and for =
initiating this dialogue.&nbsp; We hope that this develops into a =
fruitful relationship. To that end, we enclose a product of the joint =
work between the ITU-T and the IETF on Routing Requirements for =
ASON.&nbsp; This is a work in progress, and we solicit your =
comments:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;- to identify any requirements that the OIF has =
over and above those</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; requirements established by the =
ITU-T ASON model</FONT>
<BR><FONT SIZE=3D2>&nbsp;- to ensure that the solution developed within =
the IETF addresses</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; the requirements of both the =
ITU-T and OIF.</FONT>
</P>

<P><FONT SIZE=3D2>We hope that your feedback will signal the beginning =
of an active cooperation between the IETF and the OIF.</FONT>
</P>

<P><FONT SIZE=3D2>Sincerely,</FONT>
<BR><FONT SIZE=3D2>&lt;etc.&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&lt;attachment: current version of GMPLS ASON Routing =
Requirements doc&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4060A.18D6F31A--



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 19:00:31 +0000
Message-ID: <[e-mail]>
Date: Tue, 09 Mar 2004 11:59:01 -0700
From: Stephen J Trowbridge <[e-mail]>
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: Fred Stringer <[e-mail]>
CC: Kireeti Kompella <[e-mail]>, [e-mail]
Subject: Re: Communication in response to the OIF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Fred,
I think rather than any kind of knee jerk reaction, it is probably better to
think before we act.

It isn't really important whether we like the situation as it is now and whether
or not we like what OIF has done. What we should consider is, starting from
where things stand now, what sort of response is likely to lead to the best
result for IETF and for the industry?

I think it is a good bet that the OIF demo is going to occur whether or not we
like what they have done. Participants have made investments to make this happen
and it isn't going to stop now. And as you say, even with the "experimental"
characterization of what they are doing, a demonstration like this in such a
high profile venue will surely develop a measure of credibility for the solution.

If we take this as a given, the next questions I would ask are:
- Is it better for IETF to disavow any association with the OIF effort, with the
result being that multiple "descendants" of the GMPLS protocols (whether OIF is
allowed to use the "GMPLS" term or not) compete with each other in the market;
or would it be better to try to constructively engage with OIF to try to limit
the proliferation of solutions and to bring the OIF solution in line with IETF
principles?

- Is it better in the demo if IETF gets credit (and presumably good press) for
the base protocols that were employed to make it happen, or should this look
like OIF did this single-handedly? (I would guess that ITU-T will probably ask
to get credit for the technology from their organization that was used to make
the demo happen. Shouldn't we do the same?).

Regards,
Steve

On 3/9/2004 8:28 AM, Fred Stringer wrote:
> Hi Kireeti,
> A comment from the lurking gallery if I may.
> You are probably representing the committee opinion here, but there seems 
> to be a conflict in the  message.
> You stated that since the work was emphasized by Mr. Ong as "experimental" 
> alleviated some concerns - but then there is the concern over the SuperComm 
> testing.
> I don't think INTEROPERABILITY demonstration in public forum is purely 
> experimental.
> I don't see why the concerns are alleviated. You don't want to clobber 
> Lyndon but I think the concern is justified. The industry has enough 
> problems without fracturing the protocols it depends upon.
> 
> The request of not using OSPF, OSPF-TE and GMPLS in the demo has teeth and 
> is good.
> 
> Of all the comments you were probably expecting I'm sure this is not one of 
> them. But the situation did move me to come a little out of my lurking status.
> 
> cheers
> Fred
> 
> 
> At Tuesday09:13 AM 3/9/2004, Kireeti Kompella wrote:
> 
>>Hi All,
>>
>>Here's a first draft of a reply to the OIF.  Please comment to the
>>list by Monday, March 15 2004.
>>
>>If someone has email addresses for Steve Joiner, Jim Jones and John
>>McDonough (and titles for the last two), that would be very helpful.
>>
>>Thanks,
>>Kireeti.
>>--------
>>
>><Date>
>>
>> From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs
>>
>>To: Mr. Steve Joiner, OIF Technical Committee Chair
>>Cc: Jim Jones,
>>Cc: John McDonough,
>>Cc: Alex Zinin,       IETF Routing Area Director
>>Cc: Bill Fenner,      IETF Routing Area Director
>>
>>Dear Steve,
>>
>>Thank you for your communication regarding the current status of OIF
>>signaling and routing work, and the associated documentation.  This
>>communication is in response.  As there is no formal liaison
>>relationship yet between the IETF and the OIF, this communication is
>>not treated as a liaison; hopefully, this situation will be rectified
>>soon.
>>
>>Thank you too for allowing Mr. Lyndon Ong to present a synopsis of
>>the work going on at the OIF with regard to Intra-carrier E-NNI
>>routing.  It was both useful and enlightening.
>>
>>However, both of these gave us cause for alarm, on two fronts:
>>a) The development of new or modified code points and procedures
>>   in OSPF without expert review from the OSPF WG in the IETF
>>   contravenes IETF procedure, especially as the IETF pays special
>>   attention to changes in protocols in the Routing Area, such as
>>   OSPF.
>>b) The development of routing for optical networks without expert
>>   review from the CCAMP WG is also a source of concern, especially
>>   in the light of a cooperative effort between the ITU-T and the
>>   IETF in exactly this area.
>>
>>Mr. Ong's emphasis that this work was experimental and purely for the
>>purpose of testing alleviated some of our concerns.  It would be very
>>helpful to hear this officially from the OIF; furthermore, in the
>>interests of openness and full disclosure, we would strongly urge the
>>modification of a paragraph in the Introduction of the draft routing
>>document OIF2003.259 as follows:
>>
>>   "The base protocol as defined by this document is OSPF with
>>    extensions for Traffic Engineering and GMPLS.  This document
>>    proposes to use GMPLS-OSPF to operate at each hierarchical
>>    level, with multiple such levels stacking up to form the
>>    routing hierarchy.  Extensions have been defined in the forms
>>    of (sub-) TLVs to accommodate the requirements as defined in the
>>    G.8080, G.7715, and G.7715.1.  Note that these extensions as
>>    currently specified are purely for the purpose of experimentation
>>    and testing; in particular, they have not yet been reviewed by
>>    the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
>>    use experimental codepoints, and as such must not be used in
>>    production deployments."
>>
>>Mr. Ong also brought to our attention that the OIF will be holding
>>an interoperability demonstration of this specification at the
>>SuperComm in June 2004.  Due to the preliminary nature of this
>>specification, the IETF would strongly recommend that the words
>>OSPF, OSPF-TE and GMPLS not be used in the context of this
>>demonstration, nor that there be any implication that this work
>>has been reviewed or sanctioned by the IETF.
>>
>>It would be helpful in determining the future relationship between
>>the IETF and the OIF to understand how the OIF intends to progress
>>this document.
>>
>> o Is this intended to become an Implementation Agreement in
>>   something close to its current form?
>>
>> o Does the OIF intend to submit this as a submission in the ITU-T
>>   SG15 to become a Recommendation?
>>
>> o Does the OIF intend to submit this document as an Internet Draft
>>   to become an IETF RFC?
>>
>>Thank you for your attention in this matter, and for initiating this
>>dialogue.  We hope that this develops into a fruitful relationship.
>>To that end, we enclose a product of the joint work between the
>>ITU-T and the IETF on Routing Requirements for ASON.  This is a
>>work in progress, and we solicit your comments:
>> - to identify any requirements that the OIF has over and above those
>>    requirements established by the ITU-T ASON model
>> - to ensure that the solution developed within the IETF addresses
>>    the requirements of both the ITU-T and OIF.
>>
>>We hope that your feedback will signal the beginning of an active
>>cooperation between the IETF and the OIF.
>>
>>Sincerely,
>><etc.>
>>
>><attachment: current version of GMPLS ASON Routing Requirements doc>
> 
> 
> 
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 18:25:43 +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: Communication in response to the OIF
Date: Tue, 9 Mar 2004 12:22:00 -0600
Message-ID: <[e-mail]>
Thread-Topic: Communication in response to the OIF
Thread-Index: AcQF4RwbCZxp/X/PRJSvG/mCA84JkwAHtxfg
From: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>, "Alex Zinin" <[e-mail]>, "Bill Fenner" <[e-mail]>

Kireeti,

I would not characterize the interactions between ITU-T and IETF as a =
"cooperative effort" at this point.  IMO "adversarial effort" would be =
more accurate, but "joint effort" might be more PC.

I don't see that much cooperation between ITU-T and IETF quite yet on =
GMPLS/ASON.  The GMPLS/ASON signaling effort is still suffering from =
deep differences in views on G.7713.2 versus =
http://ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.tx=
t.  I believe that the signaling piece of the OIF interoperability demo =
is based on G.7713.2.  The GMPLS/ASON routing effort also appears to =
have some significant differences in views at this point, stemming in =
part from differences arising out of G.7715.1 IMO.

Hopefully this will all work out, but the tone at IETF-59 didn't give me =
a lot of hope that this "cooperative effort" is going happen any time =
soon.

Thanks,
Jerry

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Kireeti Kompella
Sent: Tuesday, March 09, 2004 9:13 AM
To: [e-mail]
Cc: Alex Zinin; Bill Fenner
Subject: Communication in response to the OIF


Hi All,

Here's a first draft of a reply to the OIF.  Please comment to the
list by Monday, March 15 2004.

If someone has email addresses for Steve Joiner, Jim Jones and John
McDonough (and titles for the last two), that would be very helpful.

Thanks,
Kireeti.
--------

<Date>

 From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs

To: Mr. Steve Joiner, OIF Technical Committee Chair
Cc: Jim Jones,
Cc: John McDonough,
Cc: Alex Zinin,       IETF Routing Area Director
Cc: Bill Fenner,      IETF Routing Area Director

Dear Steve,

Thank you for your communication regarding the current status of OIF
signaling and routing work, and the associated documentation.  This
communication is in response.  As there is no formal liaison
relationship yet between the IETF and the OIF, this communication is
not treated as a liaison; hopefully, this situation will be rectified
soon.

Thank you too for allowing Mr. Lyndon Ong to present a synopsis of
the work going on at the OIF with regard to Intra-carrier E-NNI
routing.  It was both useful and enlightening.

However, both of these gave us cause for alarm, on two fronts:
a) The development of new or modified code points and procedures
   in OSPF without expert review from the OSPF WG in the IETF
   contravenes IETF procedure, especially as the IETF pays special
   attention to changes in protocols in the Routing Area, such as
   OSPF.
b) The development of routing for optical networks without expert
   review from the CCAMP WG is also a source of concern, especially
   in the light of a cooperative effort between the ITU-T and the
   IETF in exactly this area.

Mr. Ong's emphasis that this work was experimental and purely for the
purpose of testing alleviated some of our concerns.  It would be very
helpful to hear this officially from the OIF; furthermore, in the
interests of openness and full disclosure, we would strongly urge the
modification of a paragraph in the Introduction of the draft routing
document OIF2003.259 as follows:

   "The base protocol as defined by this document is OSPF with
    extensions for Traffic Engineering and GMPLS.  This document
    proposes to use GMPLS-OSPF to operate at each hierarchical
    level, with multiple such levels stacking up to form the
    routing hierarchy.  Extensions have been defined in the forms
    of (sub-) TLVs to accommodate the requirements as defined in the
    G.8080, G.7715, and G.7715.1.  Note that these extensions as
    currently specified are purely for the purpose of experimentation
    and testing; in particular, they have not yet been reviewed by
    the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
    use experimental codepoints, and as such must not be used in
    production deployments."

Mr. Ong also brought to our attention that the OIF will be holding
an interoperability demonstration of this specification at the
SuperComm in June 2004.  Due to the preliminary nature of this
specification, the IETF would strongly recommend that the words
OSPF, OSPF-TE and GMPLS not be used in the context of this
demonstration, nor that there be any implication that this work
has been reviewed or sanctioned by the IETF.

It would be helpful in determining the future relationship between
the IETF and the OIF to understand how the OIF intends to progress
this document.

 o Is this intended to become an Implementation Agreement in
   something close to its current form?

 o Does the OIF intend to submit this as a submission in the ITU-T
   SG15 to become a Recommendation?

 o Does the OIF intend to submit this document as an Internet Draft
   to become an IETF RFC?

Thank you for your attention in this matter, and for initiating this
dialogue.  We hope that this develops into a fruitful relationship.
To that end, we enclose a product of the joint work between the
ITU-T and the IETF on Routing Requirements for ASON.  This is a
work in progress, and we solicit your comments:
 - to identify any requirements that the OIF has over and above those
    requirements established by the ITU-T ASON model
 - to ensure that the solution developed within the IETF addresses
    the requirements of both the ITU-T and OIF.

We hope that your feedback will signal the beginning of an active
cooperation between the IETF and the OIF.

Sincerely,
<etc.>

<attachment: current version of GMPLS ASON Routing Requirements doc>




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 15:59:33 +0000
Message-Id: <6.0.3.0.2.20040309105433.04e3fcb8@mo-ex1>
Date: Tue, 09 Mar 2004 10:57:27 -0500
To: "Nic Neate" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: RE: draft-aruns-ccamp-rsvp-restart-ext-00
Cc: "Adrian Farrel" <[e-mail]>, "Satyanarayana, Arun" <[e-mail]>, "Berger, Lou" <[e-mail]>, <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Nic,
         In one-on-one discussions at the IETF the authors agreed to do 
just these two things!  I know we're hoping to get the first part done late 
this week/early next week.  I can't speak for the other authors (of the 
other half of the to-be-merged draft) on the second part.

Lou

At 07:41 AM 3/9/2004 -0500, Nic Neate wrote:

>Hi Adrian (and draft-aruns authors),
>
>Responses below.  In summary, I agree
>  - with the suggestion of being able to request RecoveryPath messages
>  - that it would be very helpful if the procedures for recovering from
>simultaneous adjacent restarts could be clarified.
>
>Thanks,
>
>Nic
>
> > -----Original Message-----
> > From: Adrian Farrel 
> [<mailto:[e-mail]>mailto:[e-mail]]
> > Sent: Saturday, March 06, 2004 12:47 PM
> > To: Nic Neate; [e-mail]; Movaz Networks - Louis Berger;
> > [e-mail]
> > Cc: [e-mail]
> > Subject: Re: draft-aruns-ccamp-rsvp-restart-ext-00
> >
> >
> > Hi Nic,
> >
> > > I've just read your draft-aruns-ccamp-rsvp-restart-ext-00
> > and it looks good.
> > > In particular, we've been looking at using Restart for Fast
> > Reroute LSPs for
> > > some time and this draft provides everything that is needed
> > (like recovering
> > > the FAST_REROUTE, DETOUR, SENDER_TEMPLATE and ERO
> > > objects from the downstream node when they are not
> > available from upstream).
> >
> > Good. This concern was also raised in Seoul, and I am pleased
> > to hear that the draft
> > addresses these requirements.
> >
> > > However, I have a couple of concerns (not related to Fast Reroute).
> > >
> > >  - Your draft doesn't tackle, and won't work for,
> > simultaneous restart of
> > > adjacent nodes.  This is a problem that is tackled by
> > > draft-rahman-ccamp-rsvp-restart-extensions, so merging the
> > two drafts in
> > > some way may be the best way to resolve that.  I realize
> > that the Aruns
> > > draft aims to make Restart possible for nodes which cannot
> > retrieve state
> > > from the data plane, and in that case recovering from
> > simultaneous restart
> > > of adjacent nodes isn't easy.  I think including some
> > further extensions for
> > > nodes which can retrieve some state from the data plane would be
> > > appropriate.
> >
> > Retrieving state from the data plane only answers half of the
> > problem. However, it is
> > certainly important to audit the recovered control plane
> > information against the known
> > data plane state.
> >
>
>Indeed.  My point was that if you can't retrieve even the outgoing signaling
>interface from your data plane following a "nodal fault", you haven't got
>much hope of reconstructing protocol state in between two nodes which
>restarted at the same time (without some serious protocol enhancement
>anyway).  Hence the suggestion of additional extensions to recover from
>adjacent restarts for nodes which can retrieve the outgoing signaling
>interface.
>
> > With regard to adjacent node failures and restarts, I believe
> > there are actually
> > sufficient capabilities here. Perhaps the authors would like
> > to include text to clarify
> > the procedures.
> >
>
>If this is the case, then no problem.  I agree that some text clarifying
>that in the draft would be very helpful.
>
> > >  - The back compatibility with RFC 3473 restart looks
> > risky.  Draft Aruns
> > > mandates that restarted nodes don't send Path Refreshes
> > until either the
> > > recovery period expires or a RecoveryPath is received from
> > downstream.  In
> > > the case that the downstream node only supports RFC 3473
> > restart (and so
> > > doesn't send RecoveryPaths), it may well timeout Path state
> > at the same time
> > > as or very soon after the recovery period expires.  Hence a
> > dangerous timing
> > > window is created.
> >
> > You have something here.
> > However, section 9.5.3 of RFC3473 does not say that the
> > neighbor MUST discard state that
> > is not restored in the recovery time interval. Presumably it
> > would simply recommence
> > waiting for state refresh and so would time out after a 3.5
> > refresh intervals from the end
> > of the recovery interval.
> >
>
>That would be sensible behavior, yes.  My concern (as I'm sure you realize)
>is that it won't happen like that in all cases in the real world.
>
> > Some compromise may be introduced here by noting that 3473
> > says that Path state SHOULD be
> > restored within 1/2 of the recovery time. So we could follow
> > this logic and use the first
> > half of the time interval for the RecoveryPath message and
> > the second half for backwards
> > compatible recovery.
> >
> > On the other hand, I would prefer that this new capability
> > (support for RecoveryPath
> > message) was signaled in the Restart_Capabilities object so
> > that the restarting node can
> > know whether to expect to receive a RecoveryPath or not.
> >
> > > As a potential solution to both problems I'd suggest that a
> > restarting node
> > > receiving a Path message with a recovery label should
> > always forward it
> > > immediately as well as it can, and include both a recovery
> > label and (for
> > > back compatibility) a suggested label.  Similarly, it should forward
> > > RecoveryPath messages immediately as well as it can.  I'd
> > be happy to
> > > discuss any of this further.
> >
> > This sounds very dangerous.
> > "As well as it can" may include path computation which may
> > pick a path other than the one
> > previously in use. Hence the new Path message will be sent to
> > a new neighbor. This
> > disaster is no better than the problem we are trying to solve.
> >
>
>Fine.  I had in mind that a node should only forward a Path message before
>receiving a RecoveryPath if it was sure that it could send it (as per
>RFC3473) to the right place and without a dangerous ERO.  In any case, I
>prefer the idea of being able to request RecoveryPath messages and it sounds
>like that will make recovery possible in more situations.
>
> > Cheers,
> > Adrian
> >




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 15:30:15 +0000
Message-Id: <[e-mail]>
Date: Tue, 09 Mar 2004 10:28:12 -0500
To: Kireeti Kompella <[e-mail]>, [e-mail]
From: Fred Stringer <[e-mail]>
Subject: Re: Communication in response to the OIF
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Kireeti,
A comment from the lurking gallery if I may.
You are probably representing the committee opinion here, but there seems 
to be a conflict in the  message.
You stated that since the work was emphasized by Mr. Ong as "experimental" 
alleviated some concerns - but then there is the concern over the SuperComm 
testing.
I don't think INTEROPERABILITY demonstration in public forum is purely 
experimental.
I don't see why the concerns are alleviated. You don't want to clobber 
Lyndon but I think the concern is justified. The industry has enough 
problems without fracturing the protocols it depends upon.

The request of not using OSPF, OSPF-TE and GMPLS in the demo has teeth and 
is good.

Of all the comments you were probably expecting I'm sure this is not one of 
them. But the situation did move me to come a little out of my lurking status.

cheers
Fred


At Tuesday09:13 AM 3/9/2004, Kireeti Kompella wrote:
>Hi All,
>
>Here's a first draft of a reply to the OIF.  Please comment to the
>list by Monday, March 15 2004.
>
>If someone has email addresses for Steve Joiner, Jim Jones and John
>McDonough (and titles for the last two), that would be very helpful.
>
>Thanks,
>Kireeti.
>--------
>
><Date>
>
>  From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs
>
>To: Mr. Steve Joiner, OIF Technical Committee Chair
>Cc: Jim Jones,
>Cc: John McDonough,
>Cc: Alex Zinin,       IETF Routing Area Director
>Cc: Bill Fenner,      IETF Routing Area Director
>
>Dear Steve,
>
>Thank you for your communication regarding the current status of OIF
>signaling and routing work, and the associated documentation.  This
>communication is in response.  As there is no formal liaison
>relationship yet between the IETF and the OIF, this communication is
>not treated as a liaison; hopefully, this situation will be rectified
>soon.
>
>Thank you too for allowing Mr. Lyndon Ong to present a synopsis of
>the work going on at the OIF with regard to Intra-carrier E-NNI
>routing.  It was both useful and enlightening.
>
>However, both of these gave us cause for alarm, on two fronts:
>a) The development of new or modified code points and procedures
>    in OSPF without expert review from the OSPF WG in the IETF
>    contravenes IETF procedure, especially as the IETF pays special
>    attention to changes in protocols in the Routing Area, such as
>    OSPF.
>b) The development of routing for optical networks without expert
>    review from the CCAMP WG is also a source of concern, especially
>    in the light of a cooperative effort between the ITU-T and the
>    IETF in exactly this area.
>
>Mr. Ong's emphasis that this work was experimental and purely for the
>purpose of testing alleviated some of our concerns.  It would be very
>helpful to hear this officially from the OIF; furthermore, in the
>interests of openness and full disclosure, we would strongly urge the
>modification of a paragraph in the Introduction of the draft routing
>document OIF2003.259 as follows:
>
>    "The base protocol as defined by this document is OSPF with
>     extensions for Traffic Engineering and GMPLS.  This document
>     proposes to use GMPLS-OSPF to operate at each hierarchical
>     level, with multiple such levels stacking up to form the
>     routing hierarchy.  Extensions have been defined in the forms
>     of (sub-) TLVs to accommodate the requirements as defined in the
>     G.8080, G.7715, and G.7715.1.  Note that these extensions as
>     currently specified are purely for the purpose of experimentation
>     and testing; in particular, they have not yet been reviewed by
>     the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
>     use experimental codepoints, and as such must not be used in
>     production deployments."
>
>Mr. Ong also brought to our attention that the OIF will be holding
>an interoperability demonstration of this specification at the
>SuperComm in June 2004.  Due to the preliminary nature of this
>specification, the IETF would strongly recommend that the words
>OSPF, OSPF-TE and GMPLS not be used in the context of this
>demonstration, nor that there be any implication that this work
>has been reviewed or sanctioned by the IETF.
>
>It would be helpful in determining the future relationship between
>the IETF and the OIF to understand how the OIF intends to progress
>this document.
>
>  o Is this intended to become an Implementation Agreement in
>    something close to its current form?
>
>  o Does the OIF intend to submit this as a submission in the ITU-T
>    SG15 to become a Recommendation?
>
>  o Does the OIF intend to submit this document as an Internet Draft
>    to become an IETF RFC?
>
>Thank you for your attention in this matter, and for initiating this
>dialogue.  We hope that this develops into a fruitful relationship.
>To that end, we enclose a product of the joint work between the
>ITU-T and the IETF on Routing Requirements for ASON.  This is a
>work in progress, and we solicit your comments:
>  - to identify any requirements that the OIF has over and above those
>     requirements established by the ITU-T ASON model
>  - to ensure that the solution developed within the IETF addresses
>     the requirements of both the ITU-T and OIF.
>
>We hope that your feedback will signal the beginning of an active
>cooperation between the IETF and the OIF.
>
>Sincerely,
><etc.>
>
><attachment: current version of GMPLS ASON Routing Requirements doc>





Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 14:14:58 +0000
Date: Tue, 9 Mar 2004 06:13:29 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
cc: Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Subject: Communication in response to the OIF
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi All,

Here's a first draft of a reply to the OIF.  Please comment to the
list by Monday, March 15 2004.

If someone has email addresses for Steve Joiner, Jim Jones and John
McDonough (and titles for the last two), that would be very helpful.

Thanks,
Kireeti.
--------

<Date>

 From: Kireeti Kompella & Adrian Farrel, IETF CCAMP Working Group Chairs

To: Mr. Steve Joiner, OIF Technical Committee Chair
Cc: Jim Jones,
Cc: John McDonough,
Cc: Alex Zinin,       IETF Routing Area Director
Cc: Bill Fenner,      IETF Routing Area Director

Dear Steve,

Thank you for your communication regarding the current status of OIF
signaling and routing work, and the associated documentation.  This
communication is in response.  As there is no formal liaison
relationship yet between the IETF and the OIF, this communication is
not treated as a liaison; hopefully, this situation will be rectified
soon.

Thank you too for allowing Mr. Lyndon Ong to present a synopsis of
the work going on at the OIF with regard to Intra-carrier E-NNI
routing.  It was both useful and enlightening.

However, both of these gave us cause for alarm, on two fronts:
a) The development of new or modified code points and procedures
   in OSPF without expert review from the OSPF WG in the IETF
   contravenes IETF procedure, especially as the IETF pays special
   attention to changes in protocols in the Routing Area, such as
   OSPF.
b) The development of routing for optical networks without expert
   review from the CCAMP WG is also a source of concern, especially
   in the light of a cooperative effort between the ITU-T and the
   IETF in exactly this area.

Mr. Ong's emphasis that this work was experimental and purely for the
purpose of testing alleviated some of our concerns.  It would be very
helpful to hear this officially from the OIF; furthermore, in the
interests of openness and full disclosure, we would strongly urge the
modification of a paragraph in the Introduction of the draft routing
document OIF2003.259 as follows:

   "The base protocol as defined by this document is OSPF with
    extensions for Traffic Engineering and GMPLS.  This document
    proposes to use GMPLS-OSPF to operate at each hierarchical
    level, with multiple such levels stacking up to form the
    routing hierarchy.  Extensions have been defined in the forms
    of (sub-) TLVs to accommodate the requirements as defined in the
    G.8080, G.7715, and G.7715.1.  Note that these extensions as
    currently specified are purely for the purpose of experimentation
    and testing; in particular, they have not yet been reviewed by
    the OSPF and CCAMP Working Groups in the IETF.  Furthermore they
    use experimental codepoints, and as such must not be used in
    production deployments."

Mr. Ong also brought to our attention that the OIF will be holding
an interoperability demonstration of this specification at the
SuperComm in June 2004.  Due to the preliminary nature of this
specification, the IETF would strongly recommend that the words
OSPF, OSPF-TE and GMPLS not be used in the context of this
demonstration, nor that there be any implication that this work
has been reviewed or sanctioned by the IETF.

It would be helpful in determining the future relationship between
the IETF and the OIF to understand how the OIF intends to progress
this document.

 o Is this intended to become an Implementation Agreement in
   something close to its current form?

 o Does the OIF intend to submit this as a submission in the ITU-T
   SG15 to become a Recommendation?

 o Does the OIF intend to submit this document as an Internet Draft
   to become an IETF RFC?

Thank you for your attention in this matter, and for initiating this
dialogue.  We hope that this develops into a fruitful relationship.
To that end, we enclose a product of the joint work between the
ITU-T and the IETF on Routing Requirements for ASON.  This is a
work in progress, and we solicit your comments:
 - to identify any requirements that the OIF has over and above those
    requirements established by the ITU-T ASON model
 - to ensure that the solution developed within the IETF addresses
    the requirements of both the ITU-T and OIF.

We hope that your feedback will signal the beginning of an active
cooperation between the IETF and the OIF.

Sincerely,
<etc.>

<attachment: current version of GMPLS ASON Routing Requirements doc>



Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2004 12:43:45 +0000
Message-ID: <[e-mail]>
From: Nic Neate <[e-mail]>
To: 'Adrian Farrel' <[e-mail]>, [e-mail],  Movaz Networks - Louis Berger <[e-mail]>,  [e-mail]
Cc: [e-mail]
Subject: RE: draft-aruns-ccamp-rsvp-restart-ext-00
Date: Tue, 9 Mar 2004 12:41:10 -0000 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Adrian (and draft-aruns authors),

Responses below.  In summary, I agree
 - with the suggestion of being able to request RecoveryPath messages
 - that it would be very helpful if the procedures for recovering from
simultaneous adjacent restarts could be clarified.

Thanks,

Nic


> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Saturday, March 06, 2004 12:47 PM
> To: Nic Neate; [e-mail]; Movaz Networks - Louis Berger;
> [e-mail]
> Cc: [e-mail]
> Subject: Re: draft-aruns-ccamp-rsvp-restart-ext-00
> 
> 
> Hi Nic,
> 
> > I've just read your draft-aruns-ccamp-rsvp-restart-ext-00 
> and it looks good.
> > In particular, we've been looking at using Restart for Fast 
> Reroute LSPs for
> > some time and this draft provides everything that is needed 
> (like recovering
> > the FAST_REROUTE, DETOUR, SENDER_TEMPLATE and ERO
> > objects from the downstream node when they are not 
> available from upstream).
> 
> Good. This concern was also raised in Seoul, and I am pleased 
> to hear that the draft
> addresses these requirements.
> 
> > However, I have a couple of concerns (not related to Fast Reroute).
> >
> >  - Your draft doesn't tackle, and won't work for, 
> simultaneous restart of
> > adjacent nodes.  This is a problem that is tackled by
> > draft-rahman-ccamp-rsvp-restart-extensions, so merging the 
> two drafts in
> > some way may be the best way to resolve that.  I realize 
> that the Aruns
> > draft aims to make Restart possible for nodes which cannot 
> retrieve state
> > from the data plane, and in that case recovering from 
> simultaneous restart
> > of adjacent nodes isn't easy.  I think including some 
> further extensions for
> > nodes which can retrieve some state from the data plane would be
> > appropriate.
> 
> Retrieving state from the data plane only answers half of the 
> problem. However, it is
> certainly important to audit the recovered control plane 
> information against the known
> data plane state.
> 

Indeed.  My point was that if you can't retrieve even the outgoing signaling
interface from your data plane following a "nodal fault", you haven't got
much hope of reconstructing protocol state in between two nodes which
restarted at the same time (without some serious protocol enhancement
anyway).  Hence the suggestion of additional extensions to recover from
adjacent restarts for nodes which can retrieve the outgoing signaling
interface.

> With regard to adjacent node failures and restarts, I believe 
> there are actually
> sufficient capabilities here. Perhaps the authors would like 
> to include text to clarify
> the procedures.
> 

If this is the case, then no problem.  I agree that some text clarifying
that in the draft would be very helpful.

> >  - The back compatibility with RFC 3473 restart looks 
> risky.  Draft Aruns
> > mandates that restarted nodes don't send Path Refreshes 
> until either the
> > recovery period expires or a RecoveryPath is received from 
> downstream.  In
> > the case that the downstream node only supports RFC 3473 
> restart (and so
> > doesn't send RecoveryPaths), it may well timeout Path state 
> at the same time
> > as or very soon after the recovery period expires.  Hence a 
> dangerous timing
> > window is created.
> 
> You have something here.
> However, section 9.5.3 of RFC3473 does not say that the 
> neighbor MUST discard state that
> is not restored in the recovery time interval. Presumably it 
> would simply recommence
> waiting for state refresh and so would time out after a 3.5 
> refresh intervals from the end
> of the recovery interval.
> 

That would be sensible behavior, yes.  My concern (as I'm sure you realize)
is that it won't happen like that in all cases in the real world.

> Some compromise may be introduced here by noting that 3473 
> says that Path state SHOULD be
> restored within 1/2 of the recovery time. So we could follow 
> this logic and use the first
> half of the time interval for the RecoveryPath message and 
> the second half for backwards
> compatible recovery.
> 
> On the other hand, I would prefer that this new capability 
> (support for RecoveryPath
> message) was signaled in the Restart_Capabilities object so 
> that the restarting node can
> know whether to expect to receive a RecoveryPath or not.
> 
> > As a potential solution to both problems I'd suggest that a 
> restarting node
> > receiving a Path message with a recovery label should 
> always forward it
> > immediately as well as it can, and include both a recovery 
> label and (for
> > back compatibility) a suggested label.  Similarly, it should forward
> > RecoveryPath messages immediately as well as it can.  I'd 
> be happy to
> > discuss any of this further.
> 
> This sounds very dangerous.
> "As well as it can" may include path computation which may 
> pick a path other than the one
> previously in use. Hence the new Path message will be sent to 
> a new neighbor. This
> disaster is no better than the problem we are trying to solve.
> 

Fine.  I had in mind that a node should only forward a Path message before
receiving a RecoveryPath if it was sure that it could send it (as per
RFC3473) to the right place and without a dangerous ERO.  In any case, I
prefer the idea of being able to request RecoveryPath messages and it sounds
like that will make recovery possible in more situations.

> Cheers,
> Adrian
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 21:08:17 +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: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Date: Mon, 8 Mar 2004 15:06:48 -0600
Message-ID: <[e-mail]>
Thread-Topic: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Thread-Index: AcQDdZM0cBW8Rcl/TCOJjinu3Ogt+wB20+PA
From: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>

Yes, should be brought under the wing of the WG.

Jerry

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Adrian Farrel
Sent: Saturday, March 06, 2004 7:21 AM
To: [e-mail]
Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?

In Seoul we ran out of time before we could discuss this draft.

However, the draft is pretty stable, and it is the opinion of the =
authors that this should be brought under the wing of the WG.

Can you please send your opinions to the list or to the chairs direct.

Silence (as usual) will be interpreted as you saying nothing.

http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-0=
1.txt

Thanks,
Adrian





Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 17:52:52 +0000
From: "Thomas D. Nadeau" <[e-mail]>
To: "'Ronald Bonica'" <[e-mail]>, <[e-mail]>
Subject: RE: GTTP and LSP PING
Date: Mon, 8 Mar 2004 12:50:59 -0500
Message-ID: <008101c40535$edfe7b60$805aa8c0@tnadeauvmware>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

] -----Original Message-----
] From: [e-mail] 
] [mailto:[e-mail]] On Behalf Of Ronald Bonica
] Sent: Saturday, March 06, 2004 12:43 PM
] To: [e-mail]
] Subject: GTTP and LSP PING
] 
] 
] Folks,
] 
] At IETF 59, an issue regarding the relationship of GTTP to 
] LSP PING was raised and redirected toward the list. I am 
] posting this message in order to initiate discussion.
] 
] One might argue that GTTP should invoke LSP PING when tracing 
] though an MPLS LSP. (In fact, previous versions of the GTTP 
] draft stated that GTTP would invoke LSP PING.) I'm not sure 
] that this is a good idea.

	Can you ellaborate why? 

] GTTP has a requirement to trace through multiple levels of 
] heterogenous tunnels. For example, GTTP might be required to 
] discover IP over MPLS over IP. If GTTP were to invoke LSP 
] PING to discover LSP details, I fear that it would miss the 
] IP tunnel at the bottom of the stack.

	That is an issue, as LSP ping/trace doesn't
work for IP as far as I understand. One idea is that it 
may be possible that LSP ping/trace could invoke IP trace/ping 
recursively.

	--Tom



] This assumption could be wrong. Comments?
] 
] ----------------
] Ronald P. Bonica
] ----------------
] Sometimes the easiest way to 
] start a dialog is to start talking.






Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 16:42:54 +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: Opinion sought on drafts being adopted by CCAMP
Date: Mon, 8 Mar 2004 10:41:44 -0600
Message-ID: <[e-mail]>
Thread-Topic: Opinion sought on drafts being adopted by CCAMP
Thread-Index: AcQFKOUnMo4M1/pLQ52bKBacL1LgKQAA0xQQ
From: "Alanqar, Wesam I [NTK]" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>

Yes to all.

-Wesam
Adrian Farrel wrote:

>All,
>
>At the CCAMP meeting today we discussed making several drafts working=20
>group items. Can you please express your opinion (yes/no) on whether=20
>each of the following drafts is ready to become a CCAMP working group=20
>draft.
>
>Feel free to express yes with reservations. If you have reservations or

>objections, please express them on the list. if you need anonymity for=20
>your comments then please filter them through the chairs.
>
>Silence will be taken as meaning nothing, so please say what you think.
>
>GMPLS Signaling Procedure For Egress Control=20
>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-0
>1.txt
>
>Generic Tunnel Tracing Protocol (GTTP) Specification=20
>http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
>
>RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery=20
>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e
>-signaling-03.txt
>
>GMPLS Based Segment Recovery=20
>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-re
>covery-00.txt
>
>Thank you,
>Adrian
>
>
>
> =20
>






Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 16:27:22 +0000
Message-ID: <[e-mail]>
From: Yanhe Fan <[e-mail]>
To: Adrian Farrel <[e-mail]>
Cc: [e-mail]
Subject: RE: Opinion sought on drafts being adopted by CCAMP
Date: Mon, 8 Mar 2004 11:28:24 -0500 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Yes to all.

Yanhe

At 06:46 AM 3/4/2004 -0500, Adrian Farrel wrote:

>All,
>
>At the CCAMP meeting today we discussed making several drafts working 
>group items. Can you
>please express your opinion (yes/no) on whether each of the following 
>drafts is ready to
>become a CCAMP working group draft.
>
>Feel free to express yes with reservations. If you have reservations or 
>objections, please
>express them on the list. if you need anonymity for your comments then 
>please filter them
>through the chairs.
>
>Silence will be taken as meaning nothing, so please say what you think.
>
>GMPLS Signaling Procedure For Egress Control
><http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.t
xt>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.
txt 
>
>
>Generic Tunnel Tracing Protocol (GTTP) Specification
><http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt>http://ww
w.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt 
>
>
>RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
><http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-si
gnaling-03.txt>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-re
covery-e2e-signaling-03.txt 
>
>
>GMPLS Based Segment Recovery
><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recov
ery-00.txt>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segm
ent-recovery-00.txt 
>
>
>Thank you,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 16:16:46 +0000
Message-ID: <[e-mail]>
Date: Mon, 08 Mar 2004 17:14:35 +0100
From: [e-mail]
Reply-To: [e-mail]
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: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

yes to all.

Adrian Farrel wrote:

>All,
>
>At the CCAMP meeting today we discussed making several drafts working group items. Can you
>please express your opinion (yes/no) on whether each of the following drafts is ready to
>become a CCAMP working group draft.
>
>Feel free to express yes with reservations. If you have reservations or objections, please
>express them on the list. if you need anonymity for your comments then please filter them
>through the chairs.
>
>Silence will be taken as meaning nothing, so please say what you think.
>
>GMPLS Signaling Procedure For Egress Control
>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
>
>Generic Tunnel Tracing Protocol (GTTP) Specification
>http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
>
>RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
>
>GMPLS Based Segment Recovery
>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt
>
>Thank you,
>Adrian
>
>
>
>  
>





Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 15:53: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: Opinion sought on drafts being adopted by CCAMP
Date: Mon, 8 Mar 2004 09:52:34 -0600
Message-ID: <[e-mail]>
Thread-Topic: Opinion sought on drafts being adopted by CCAMP
Thread-Index: AcQB3uiipOwRftp0QwaLUmynPQxvyADRkirg
From: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>

Yes to all.

Jerry

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Adrian Farrel
Sent: Thursday, March 04, 2004 6:46 AM
To: [e-mail]
Subject: Opinion sought on drafts being adopted by CCAMP

All,

At the CCAMP meeting today we discussed making several drafts working =
group items. Can you please express your opinion (yes/no) on whether =
each of the following drafts is ready to become a CCAMP working group =
draft.

Feel free to express yes with reservations. If you have reservations or =
objections, please express them on the list. if you need anonymity for =
your comments then please filter them through the chairs.

Silence will be taken as meaning nothing, so please say what you think.

GMPLS Signaling Procedure For Egress Control
http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.=
txt

Generic Tunnel Tracing Protocol (GTTP) Specification
http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-s=
ignaling-03.txt

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-reco=
very-00.txt

Thank you,
Adrian



Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 15:49:02 +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: Opinion sought on drafts being adopted by CCAMP
Date: Mon, 8 Mar 2004 09:46:56 -0600
Message-ID: <[e-mail]>
Thread-Topic: Opinion sought on drafts being adopted by CCAMP
Thread-Index: AcQB3ut369jhUYmTS5ibcDsnO/8+OQDRaPRg
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Yes to all-

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Adrian Farrel
Sent: Thursday, March 04, 2004 6:46 AM
To: [e-mail]
Subject: Opinion sought on drafts being adopted by CCAMP


All,

At the CCAMP meeting today we discussed making several drafts working =
group items. Can you
please express your opinion (yes/no) on whether each of the following =
drafts is ready to
become a CCAMP working group draft.

Feel free to express yes with reservations. If you have reservations or =
objections, please
express them on the list. if you need anonymity for your comments then =
please filter them
through the chairs.

Silence will be taken as meaning nothing, so please say what you think.

GMPLS Signaling Procedure For Egress Control
http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.=
txt

Generic Tunnel Tracing Protocol (GTTP) Specification
http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-s=
ignaling-03.txt

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-reco=
very-00.txt

Thank you,
Adrian





Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 15:48:46 +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: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Date: Mon, 8 Mar 2004 09:45:30 -0600
Message-ID: <[e-mail]>
Thread-Topic: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Thread-Index: AcQDdZMJHPP2BDECQbGjX0SGL5JpzQBrrnLA
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Yes-

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Adrian Farrel
Sent: Saturday, March 06, 2004 7:21 AM
To: [e-mail]
Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?


In Seoul we ran out of time before we could discuss this draft.

However, the draft is pretty stable, and it is the opinion of the =
authors that this should
be brought under the wing of the WG.

Can you please send your opinions to the list or to the chairs direct.

Silence (as usual) will be interpreted as you saying nothing.

http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-0=
1.txt

Thanks,
Adrian





Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 10:33:16 +0000
From: "zafar ali" <[e-mail]>
To: "'zafar ali'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Rahul Aggarwal'" <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: RE: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
Date: Mon, 8 Mar 2004 05:30:03 -0500
Organization: Cisco Systems
Message-ID: <003001c404f8$5323eb80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Lou, Rahul, et al,

As mentioned in the CCAMP WG, we are in the process of publishing a
modified version of the ID based on earlier comments from Dimitri, et
al. As I saw Lou and Rahul at the microphone for questions, which we
were not able to address due to time constraints, we would like to
request for your  comments at the list.  

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of zafar ali
>Sent: Friday, February 06, 2004 3:25 PM
>To: [e-mail]
>Cc: [e-mail]
>Subject: RE: comments on 
>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>
>
>Hi Dimitri, 
>
>Thanks for your comments and feedback. I have in-lined some 
>new comments. 
>
>As I mentioned in my earlier email that we will take care of 
>these comments in the next version of the document. 
>
>Thanks again for your feedback. 
>
>Regards... Zafar
>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of 
>>[e-mail]
>>Sent: Friday, February 06, 2004 11:17 AM
>>To: zafar ali
>>Cc: [e-mail]
>>Subject: Re: comments on 
>>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>>
>>
>>hi, some comments on this document that would imho
>>beneficiate from the community
>>
>
>Thanks, 
>
>>>>   Another scenario which introduces the need for node-id
>>based Hellos
>>>>   is when nodes support unnumbered TE links. Specifically, 
>when all 
>>>>TE
>>>>   links between neighbor nodes are unnumbered, it is
>>implied that the
>>>>   nodes will use node-id based Hellos for detecting node
>>>>failures. This
>>>>   draft also clarifies the use of node-id based Hellos 
>when all or a
>>>>   sub-set of TE links are unnumbered.
>>>>
>>>>DP: the key point is "is the router id used to identify the te link 
>>>>the same as the one used for the hello's ?"
>>>  
>>> Yes, the same router-id/ node-id is used.
>>
>>ok, that's what i wanted to know and i would propose to include the 
>>above sentence in this i-d
>>
>
>Agreed, we will. 
>
>>>>   When link level failure detection is performed by some 
>means other
>>>>   than RSVP Hellos (e.g., [BFD]), the use of node-id based 
>Hellos is
>>>>   also optimal for detection of nodal failures.
>>>>
>>>>DP: pin point that this is a particular case, it's not a nodal 
>>>>failure but a RSVP-TE signaling adjacency failure, RSVP-TE 
>signaling 
>>>>controller failure,
>>> 
>>> Agreed! this is more precise statement.
>>
>>ok, thanks
>>
>>>>note that if this session is
>>>>maintained and is used as the IP channel for all messages then
>>>>it MAY also be used as "nodal failure"
>>>>
>>>>   An implementation may initiate a node-id based Hello 
>session when 
>>>>it
>>>>   starts sharing RSVP states with the neighbor or at an
>>earlier time.
>>>>
>>>>DP: i don't understand what you mean here
>>>>
>>> What we meant here is that an application may not run RSVP Hello
>>> session all the time. It may initiate one when it has an 
>application 
>>> (e.g., when for GR when it start sharing states with the neighbor.
>>
>>this is an interesting statement to be considered in the
>>scope of this document
>
>No, these details are implementation specific. The related 
>para was included in the ID as a reference (to avoid confusion 
>on how node-id's can be obtained.). Nonetheless, as you would 
>agree that this is implementation specific detail, and hence 
>is outside the scope of the ID.  
>
>>
>>>>   Similarly, an implementation may use the IGP topology to 
>determine
>>>>   the remote node-id which matches an interface address(es) used in
>>>>   RSVP signaling. These aspects are considered to be a local
>>>>   implementation decision.
>>>>
>>>>DP: how is this possible since you're using the router_id being the 
>>>>router_address advertized as top level te link 1 in ospf_te
>>>>
>>>  
>>> In Inter-area and inter-AS case, this information is assumed to come
>>> via configuration. Is this what you meant here?
>>
>>the above sentence introduces an issue once the interface
>>is in failure state, i would provide more details here wrt
>>to real expectations behind the above paragraph either it
>>is implementation specific w/o impact on neighbors or it
>>has and then would suggest some details on the last part.
>>
>
>This is also an implementation specific detail.  
>
>>>>   When a node receives a Hello packet where the destination IP 
>>>>address
>>>>   is its local node-id as advertised in the IGP-TE
>>topology, the node
>>>>   MUST use its node-id in replying to the Hello message. In other
>>>>   words, nodes must ensure that the node-ids used in RSVP Hello
>>>>   messages are those derived/contained in the IGP-TE topology.
>>>>   Furthermore, a node can only run one node-id based RSVP
>>>>Hello session
>>>>   with its neighbor.
>>>>
>>>>DP: well here in fact you have a real issue because, a may have 
>>>>several node_id's on a node, so what you want to say is "one per 
>>>>node_id pair"
>>> 
>>> Yes, in the cases when router is participating multiple topologies
>>> (OSPF & ISIS). But AFAIK router can only advertsie ONLY one 
>>address in
>>> a given IGP instance.
>>> 
>>> We need to make statement clear for multiple IGP instances case. Is
>>> this is what you meant?
>>
>>exactly
>
>This is a good point. New text will be updated based on your comment. 
>
>>
>>>>   If all interfaces between a pair of nodes are unnumbered, the 
>>>>optimal
>>>>   way to use RSVP to detect nodal failure is to run node-id based
>>>>   Hellos. Similarly, when link level failure detection is
>>>>performed by
>>>>   some means other than RSVP Hellos, use of node-id based Hellos is
>>>>   also optimal in detecting nodal failures. Therefore, if all
>>>>   interfaces between a pair of nodes are unnumbered or when 
>>>>link level
>>>>   failure detection is performed by some means other than 
>>>>RSVP Hellos,
>>>>   a node MUST run node-id based Hellos for node failure detection.
>>>>
>>>>DP: this is not true, i can run LMP, but a MUST for the signaling 
>>>>adj. maintenance
>>>>
>>>  
>>> Yes, we can clarify it in the next version.
>>
>>thanks,
>>--
>>Papadimitriou Dimitri
>>E-mail : [e-mail]
>>E-mail : [e-mail]
>>Webpage: http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : [phone]
>>
>>
>
>=====================================================================
>Zafar Ali, Ph. D. 				  100 South Main St.
>#200,
>Technical Leader, 				  Ann Arbor, MI 48104,
>USA.
>Cisco Systems.					  [phone].
>=====================================================================
>
>




Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2004 01:38:55 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Lou Berger" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Date: Sun, 7 Mar 2004 17:37:45 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Lou,

While the document describes well _what_ it is doing, I think it is
not clear on why this needs to be done, why it is important
(motivation), what requirements it is satisfying, and how they relate to
the current WG charter.
(Note this does not mean that the problem may not be important or should
not be in the charter.)

Also, in response to your explanation below, it is not really clear
that alarm reporting is a component of path setup. Seems to me that
the two are decoupled.
And, the "determing the actual route and other  properties" phrase
mentioned in the CCAMP WG charter I thought is aimed at addressing the
issue of tunnel tracing
(and determing LSP properties therefrom), rather than reporting alarms
at specific nodes along the path of an LSP.

With regard to your question, here is some additional feedback
on the draft:

-- The following phrase is actually unclear, as I explain below.

> also:
>
>     The communication of alarms within GMPLS does not imply any
>     modification in behavior of processing of alarms, or for the
>     communication of alarms outside of GMPLS.

If there is no modification in the behavior of alarm processing, then
presumably there is already a way to monitor and process them, so how
(and with what) does this communication help?
(I have seen the few phrases in the document in Section 1, along the
lines of "there may be a desire to retain an LSP, particularly in
optical transport networks, and communicate
alarm information," but these do not say why.)

-- The technique described in this draft relies on existing
techniques for monitoring and correlating alarms, and appears to
focus on the communication of this information along an LSP
path.
(While it may be argued that the latter is a "monitoring"
function, I am not sure how strong an argument that is, since
the monitoring (or most of it) has presumably happened before this
communication begins.)

-- Also, are there interactions/race conditions between this alarm
communication with other mechanisms conveying problems along an LSP?
Some discussion in the doc. would be valuable.

-- The document mentions briefly that the LSP state must
be retained for the communicated alarm information to be useful.

I think this is an important point, and worth expanding on in the doc.
I don't think there is any discussion right now of how one might
ensure that state has not been torn down by the time the alarm
information is correlated and ready to be communicated upstream
and downstream.

-- And, can the document provide some examples of the types of alarms
it is talking about/referring to? I think this will help a reader
understand better the why behind this approach.

-- Finally, I wasn't sure if the issue of enumeration dicussed
with Tom Petch and Bert in Nov. was solved. (I saw that the draft
refers to GR833 for Error String enumerations and to the ALARM-MIB
for the Error Codes field.)

So these are my thoughts and feedback to the authors and WG.
It may be good to hear from some other WG participants who have also
read the document.

-Vishal


> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Sunday, March 07, 2004 5:41 AM
> To: Vishal Sharma
> Cc: Adrian Farrel; [e-mail]
> Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>
>
> Vishal,
>
> As to fit&charter:  This work extends the path setup portion of common
> control plane protocol defined by the WG, namely GMPLS-RSVP.
> Additionally
> this work matches the work item, note asterisks "Define a
> protocol that can
> determine the actual route and **other properties** of paths set up by
> CCAMP signaling protocols..."  You might also want to check out Hiro
> Ishimatsu's comment  from last November on this topic on the list.
>
> As to the other issues:  In addition to Dimitri's references, the
> document
> already states:
>
>     Some operators may consider alarm information as sensitive.  To
>     support environments where this is the case, implementations SHOULD
>     allow the user to disable the generation of ALARM_SPEC objects.
>
> also:
>
>     The communication of alarms within GMPLS does not imply any
>     modification in behavior of processing of alarms, or for the
>     communication of alarms outside of GMPLS.
>
> What additional clarifications do you think are need in the text?
>
> Lou
>
> At 03:45 PM 3/6/2004 -0500, Vishal Sharma wrote:
>
> >Folks,
> >
> >It would be useful for the draft to state how it fits into the CCAMP
> >WG, and how it relates to the charter.
> >
> >One of my concerns is that exposing alarm information is something
> >that the providers may _not_ want. Moreover, there are already likely
> >to be other methods by which a provider coordinates alarm information
> >through their network (and layers), without having it be communicated
> >explicitly via signaling.
> >
> >Some clarification on these points would be useful. Until such time,
> >I would prefer to hold off on it being brought under the wing of the WG.
> >
> >-Vishal
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > [<mailto:[e-mail]>mailto:[e-mail]]On
> > > Behalf Of Adrian Farrel
> > > Sent: Saturday, March 06, 2004 4:21 AM
> > > To: [e-mail]
> > > Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> > >
> > >
> > > In Seoul we ran out of time before we could discuss this draft.
> > >
> > > However, the draft is pretty stable, and it is the opinion of the
> > > authors that this should
> > > be brought under the wing of the WG.
> > >
> > > Can you please send your opinions to the list or to the chairs direct.
> > >
> > > Silence (as usual) will be interpreted as you saying nothing.
> > >
> > >
> >
> <http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alar
> m>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
> >
> > > -spec-01.txt
> > >
> > > Thanks,
> > > Adrian
> > >




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 23:49:43 +0000
Date: Sun, 07 Mar 2004 18:48:32 -0500
From: Ronald Bonica <[e-mail]>
Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
To: 'Adrian Farrel' <[e-mail]>
Cc: [e-mail]
Message-id: <003001c4049e$b566e5e0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable

yes

>=20
> At 07:20 AM 3/6/2004 -0500, Adrian Farrel wrote:
>=20
> >In Seoul we ran out of time before we could discuss this draft.
> >
> >However, the draft is pretty stable, and it is the opinion of the=20
> >authors
> >that this should
> >be brought under the wing of the WG.
> >
> >Can you please send your opinions to the list or to the=20
> chairs direct.
> >
> >Silence (as usual) will be interpreted as you saying nothing.
> >
> ><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls
-alarm-spe
>c-01.txt>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-al=
arm
-spec-01.txt
>
>
>Thanks,
>Adrian





Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 23:49:27 +0000
Date: Sun, 07 Mar 2004 18:48:02 -0500
From: Ronald Bonica <[e-mail]>
Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
To: 'Adrian Farrel' <[e-mail]>
Cc: [e-mail]
Message-id: <002f01c4049e$ac532310$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable

yes

>=20
> At 07:20 AM 3/6/2004 -0500, Adrian Farrel wrote:
>=20
> >In Seoul we ran out of time before we could discuss this draft.
> >
> >However, the draft is pretty stable, and it is the opinion of the=20
> >authors
> >that this should
> >be brought under the wing of the WG.
> >
> >Can you please send your opinions to the list or to the=20
> chairs direct.
> >
> >Silence (as usual) will be interpreted as you saying nothing.
> >
> ><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls
-alarm-spe
>c-01.txt>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-al=
arm
-spec-01.txt
>
>
>Thanks,
>Adrian





Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 21:42:07 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Greg Bernstein" <[e-mail]>, "Eric Mannie" <[e-mail]>
Cc: <[e-mail]>, "Alexey Zinin" <[e-mail]>, "Bert Wijnen" <[e-mail]>
Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Sun, 7 Mar 2004 13:41:10 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian,

I am still very confused about what the debate is about at this point.
In any case, I would like to defer to my co-authors on this matter.

As for the enhancements/edits, I think we already stated that we
could do those.

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Sunday, March 07, 2004 3:24 AM
> To: Vishal Sharma; Greg Bernstein; Eric Mannie
> Cc: [e-mail]; Alexey Zinin; Bert Wijnen
> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> Thanks for your thoughts Vishal.
>
> The debate occurs now.
>
> Are the current authors willing and able to make the changes
> requested by the AD?
>
> Thanks,
> Adrian
> ----- Original Message -----
> From: "Vishal Sharma" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
> <[e-mail]>;
> "Eric Mannie" <[e-mail]>
> Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>; "Bert Wijnen"
> <[e-mail]>
> Sent: Sunday, March 07, 2004 12:48 AM
> Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> > Adrian,
> >
> > Thanks for the clarification. Our (the authors) understanding is
> > that the draft had passed (quite a while back, in May 2002
> > actually, after we had addressed the very last round of comments from
> > Kireeti), all of the processes in the WG needed to advance it to
> > informational RFC.
> >
> > Its purpose is really to provide an overall view and framework for
> > SDH/SONET control using an IP/MPLS control plane.
> >
> > So it would be useful for us to know exactly where the debate occurred,
> > since we were not aware of it.
> > (As far as the WG is concerned,  the draft was approved such a while
> > back that it has been a completed item for over one-and-a-half years.)
> >
> > At the last discussion on it in Sept. 2003, we were told that the only
> > reason it had got delayed was because it somehow missed being
> sent to the
> > ADs on time.
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]On
> > > Behalf Of Adrian Farrel
> > > Sent: Saturday, March 06, 2004 3:11 PM
> > > To: Vishal Sharma; Greg Bernstein; Eric Mannie
> > > Cc: [e-mail]; Alexey Zinin
> > > Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> > >
> > >
> > > Vishal,
> > >
> > > The process is that the WG hands the draft off to the AD to take
> > > it to the IESG. At this
> > > point the AD performs a review before taking the draft to the
> > > IESG and this is what we are
> > > seeing the results of.
> > >
> > > Note that this particular draft has been under "AD watch" for a
> > > while. Alex may want to
> > > clarify the reason for this, but my understanding is that there
> > > was some debate as to
> > > whether the draft had served its purpose already (that is, as a
> > > design document for the
> > > other drafts on SONET/SDH) or whether it should continue and
> > > become an RFC. This review is
> > > the next step towards becoming an RFC.
> > >
> > > Cheers,
> > > Adrian
> > >
> > > ----- Original Message -----
> > > From: "Vishal Sharma" <[e-mail]>
> > > To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
> > > <[e-mail]>;
> > > "Eric Mannie" <[e-mail]>
> > > Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>
> > > Sent: Saturday, March 06, 2004 8:41 PM
> > > Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> > >
> > >
> > > > Adrian et al,
> > > >
> > > > We will work on the document and make the appropriate modifications
> > > > to incorporate the comments.
> > > >
> > > > BTW, Alex could you please clarify whether this is an IESG review
> > > > or some other review?
> > > >
> > > > Our understanding after the last communication with Kireeti on this
> > > > subject, sometime
> > > > in July last year, was that this draft (after having passed several
> > > > last calls), was being sent to the IESG for completing the process
> > > > of advancing to informational RFC.
> > > >
> > > > Thanks,
> > > > -Vishal
> > > >
> > > > > -----Original Message-----
> > > > > From: Adrian Farrel [mailto:[e-mail]]
> > > > > Sent: Saturday, March 06, 2004 4:16 AM
> > > > > To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
> > > > > Cc: [e-mail]
> > > > > Subject: Re: AD-review comments on
> draft-ietf-ccamp-sdhsonet-control
> > > > >
> > > > >
> > > > > Greg, Eric, Vishal,
> > > > > Are you willing and able to pick this draft up again and make the
> > > > > changes from Alex?
> > > > >
> > > > > Thanks,
> > > > > Adrian
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Alex Zinin" <[e-mail]>
> > > > > To: <[e-mail]>
> > > > > Cc: <[e-mail]>
> > > > > Sent: Thursday, March 04, 2004 12:48 PM
> > > > > Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> > > > >
> > > > >
> > > > > > Folks-
> > > > > >
> > > > > >  Please find below comments from the RTG area directorate
> > > that I would
> > > > > >  like the WG to consider.
> > > > > >
> > > > > >  Thank you.
> > > > > >
> > > > > > --
> > > > > > Alex Zinin
> > > > > >
> > > > > > Technical:
> > > > > > ----------
> > > > > >
> > > > > > Section 3.2:
> > > > > >
> > > > > > 1. Figure 1 misses the STM-0 branch
> > > > > >
> > > > > > Section 3.4.3:
> > > > > >
> > > > > > 2. In comparison table, PNNI word appears for the first
> time in this
> > > > > >     document, any specific reason to mention PNNI in a
> > > GMPLS context ?
> > > > > >
> > > > > > Section 3.5
> > > > > >
> > > > > > 3. "New simplified encapsulations could reduce this
> > > overhead to as low
> > > > > >     as 3%, but the gain is not huge compared to SDH and SONET,
> > > > > which have
> > > > > >     other benefits as well.)" any reference available
> for these new
> > > > > >     simplified encapsulation(s) ?
> > > > > >
> > > > > > 4. "Any encapsulation of IP over WDM should at least
> provide error
> > > > > >     monitoring capabilities (to detect signal
> degradation), error
> > > > > >     correction capabilities, such as FEC (Forward Error
> > > Correction) that
> > > > > >     are particularly needed for ultra long haul
> > > transmission, sufficient
> > > > > >     timing information, to allow robust synchronization
> (that is, to
> > > > > >     detect the beginning of a packet), and capacity to transport
> > > > > >     signaling, routing and management messages, in order to
> > > control the
> > > > > >     optical switches."
> > > > > >
> > > > > >     The first part refers to data plane capabilities,
> however the
> > > > > >     requirement: the "encapsulation of IP over WDM"
> should deliver
> > > > > >     the capacity to transport IP based control plane
> information -
> > > > > >     why is this the case ? an out of band network would
> also do the
> > > > > >     job and this statement makes thus the implicit
> assumption that
> > > > > >     data and control plane topology is congruent
> > > > > >
> > > > > > Section 6:
> > > > > >
> > > > > > 5. "Due to the increase in information transferred in
> the routing
> > > > > >     protocol, it may be useful to separate the relatively static
> > > > > >     parameters concerning a link from those that may be
> subject to
> > > > > >     frequent changes. The current GMPLS routing extensions
> > > [12],[13],
> > > > > >     [14] do not make such a separation, however."
> > > > > >
> > > > > >    it may be thus worth asking the question was the
> dissemination
> > > > > >    of these quasi-static "link capabilities" using the
> same rules
> > > > > >    as for any other TE LSA Type 1 sub-TLV the right approach ?
> > > > > >
> > > > > > Section 6.1:
> > > > > >
> > > > > > 6. what does the following sentence brings in the scope of
> > > this control
> > > > > >     plane framework (and this is even not necessarily true
> > > when vcat is
> > > > > >     provided over different line cards):
> > > > > >
> > > > > >     "Note that this inverse multiplexing process can be
> > > significantly
> > > > > >     easier to implement with SONET/SDH signals rather
> than packets."
> > > > > >
> > > > > > Section 6.3:
> > > > > >
> > > > > > 7. "However, if only standard concatenation is supported
> > > then reporting
> > > > > >     gets trickier since there are constraints on where the
> > > STS-1s can be
> > > > > >     placed. SDH has still more options and constraints,
> > > hence it is not
> > > > > >     yet clear which is the best way to advertise
> bandwidth resource
> > > > > >     availability/usage in SONET/SDH. At present, the
> GMPLS routing
> > > > > >     protocol extensions define minimum and maximum values
> > > for available
> > > > > >     bandwidth, which allows a remote node to make some
> > > deductions about
> > > > > >     the amount of capacity available at a remote link and
> > > the types of
> > > > > >     signals it can accommodate. However, due to the
> > > multiplexed nature
> > > > > >     of the signals, the authors are of the opinion that
> reporting of
> > > > > >     bandwidth particular to signal types rather than as a single
> > > > > >     aggregate bit rate is probably very desirable."
> > > > > >
> > > > > >     -> the authors do not explain from which perspective
> > > and the reasons
> > > > > >     this particular bw accounting report is desirable
> > > (sections 2.4.3 &
> > > > > >     2.4.8 of GMPLS routing explains how these values are
> > > used to take
> > > > > >     into account the multiplexing capability of a SONET/SDH
> > > interface),
> > > > > >     there is no real determination of the missing
> > > information at remote
> > > > > >     nodes for the establishment of an LSP with a certain
> > > amount of bw
> > > > > >     (note that it is not an issue of flexible vs standard
> > > concatenation
> > > > > >     issue but a control plane issue)
> > > > > >
> > > > > > Section 7.3:
> > > > > >
> > > > > > 8. "This information is specified in three parts [17],
> each of which
> > > > > >     refers to a different network layer."
> > > > > >
> > > > > > The description of the signaling elements shall mention the
> > > following:
> > > > > > (section 7.3 refers to [17] but the latter does not
> > > correspond to the
> > > > > > description given in this section)
> > > > > >
> > > > > >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
> > > > > >      which contains three parts: LSP Encoding Type, Switching
> > > > > Type, G-PID
> > > > > >
> > > > > >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
> > > > > SENDER_TSPEC/FLOWSPEC
> > > > > >      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT,
> > > > > Transparency,
> > > > > >      Profile
> > > > > >
> > > > > >   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
> > > > > >
> > > > > >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object
> (as [RFC3473])
> > > > > >
> > > > > > ----
> > > > > >
> > > > > >
> > > > > > Editorial:
> > > > > > ----------
> > > > > >
> > > > > > Section 3:
> > > > > >
> > > > > > 1. Sometimes this document refers to GMPLS other to MPLS and
> > > > > >     sometimes as above as "extending IP technology"
> > > > > >
> > > > > > Section 3.1
> > > > > >
> > > > > > 2. "When a packet reaches a core packet LSR, this LSR uses
> > > the label as
> > > > > >     an index into a forwarding table to determine the next
> > > hop and the
> > > > > >     corresponding outgoing label (and, possibly, the QoS
> > > treatment to be
> > > > > >     given to the packet), writes the new label into the
> packet, and
> > > > > >     forwards the packet to the next hop. "
> > > > > >
> > > > > > -> replace "core packet LSR" by "packet LSR"
> > > > > >
> > > > > > Section 3.2:
> > > > > >
> > > > > > 3. "SDH and SONET are two TDM standards widely used by
> operators to
> > > > > >     transport and multiplex different tributary signals
> over optical
> > > > > >     links, thus creating a multiplexing structure,
> which we call the
> > > > > >     SDH/SONET multiplex. SDH, which was developed by the
> > > ETSI and later
> > > > > >     standardized by the ITU-T [4], is now used worldwide,
> > > while SONET,
> > > > > >     which was standardized by the ANSI [5], is mainly used
> > > in the US.
> > > > > >     However, these two standards have several similarities,
> > > and to some
> > > > > >     extent SONET can be viewed as a subset of SDH.
> Internetworking
> > > > > >     between the two is possible using gateways.
> > > > > >
> > > > > >     Should be rather as "ITU-T SDH (G.707) includes both
> > > the European
> > > > > >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy
> > > (T1.105)." [...]
> > > > > >     "The ETSI SDH and SONET standards regarding frame
> structures and
> > > > > >     higher order multiplexing are the same. There are
> some regional
> > > > > >     differences on the terminology, on the use of some
> > > overhead bytes,
> > > > > >     and lower order multiplexing. Interworking between
> the two lower
> > > > > >     order hierarchies is possible using gateways."
> > > > > >
> > > > > > Section 3.2
> > > > > >
> > > > > > 4. "In addition, a pointer (in the form of the H1, H2
> and H3 bytes)
> > > > > >     indicates the beginning of the VC/SPE in the payload of
> > > the overall
> > > > > >     STM/SDH frame."
> > > > > >
> > > > > > -> replace "STM/SDH frame" by "STM/STS frame"
> > > > > >
> > > > > > Section 4.1
> > > > > >
> > > > > > 5. "The SONET case is a bit difficult to explain since,
> > > unlike in SDH,
> > > > > >     SPEs in SONET do not have individual names." they are
> > > > > simply referred
> > > > > >     to as VT-N SPE
> > > > > >
> > > > > > Section 6:
> > > > > >
> > > > > > 6. Since this document distinguishes between "optical
> > > networks", TDM,
> > > > > >     and WDM it would advisable to avoid the "optical TDM"
> > > as mentioned
> > > > > >     in the below sentence (it has another meaning than MSn/RSn
> > > > > switching)
> > > > > >
> > > > > > Section 6.1:
> > > > > >
> > > > > > 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE
> > > > > >
> > > > > >  > Section 6.1:
> > > > > >
> > > > > > 8. "Standard and flexible concatenations are network
> services, while
> > > > > >     virtual concatenation is a SONET/SDH end-system
> service recently
> > > > > >     approved by the committee T1 of ANSI and ITU-T." remove
> > > "recently
> > > > > >     approved by the committee T1 of ANSI and ITU-T." and
> > > add the corr.
> > > > > >     reference.
> > > > > >
> > > > > > 9. "In one example of virtual concatenation, two end
> > > systems supporting
> > > > > >     this feature could essentially "inverse multiplex" two
> > > STS-1s into a
> > > > > >     virtual STS-2c for the efficient transport of 100 Mbps
> > > > > Ethernet traffic."
> > > > > >
> > > > > > -> STS-1-2v instead of "virtual STS-2c"
> > > > > >
> > > > > > 10. "Section layer: Preserves all section overhead,
> > > Basically does not
> > > > > >      touch any of the SONET/SDH bits."
> > > > > >
> > > > > > -> replace last part by "Basically does not modify or terminate
> > > > > >     any of the SONET/SDH overhead bits"
> > > > > >
> > > > > >     left column of the table misses the SDH overhead equivalent
> > > > > >
> > > > > > 11. Multiplexing of (?) in the following sentence "To perform
> > > > > >      multiplexing, a SONET network element should be line
> > > terminating."
> > > > > >
> > > > > > Section 6.2:
> > > > > >
> > > > > > 12. In the following "Standardized SONET line level protection
> > > > > techniques
> > > > > >      include: Linear 1+1 and linear 1:N automatic
> > > protection switching
> > > > > >      (APS) and both two-fiber and four-fiber bi-directional
> > > > > line switched
> > > > > >      rings (BLSRs). At the path layer, SONET offers
> > > uni-directional path
> > > > > >      switched ring protection." the same applies to SDH (to
> > > be adapted
> > > > > >      using the corr. terminology)
> > > > > >
> > > > > > Section 7:
> > > > > >
> > > > > > 13. "This VC-4 LSP can, in fact, be established between two non-
> > > > > >      adjacent internal nodes in an SDH network, and later
> > > > > >      advertised by a routing protocol as a new (virtual) link
> > > > > >      called a Forwarding Adjacency (FA)." -> add
> MPLS-HIERARCHY as
> > > > > >      reference
> > > > > >
> > > > > > 14. The following paragraph
> > > > > >      "For instance, the payload of an SDH STM-1 frame
> does not fully
> > > > > >       contain a complete unit of user data. In fact, the
> > > user data is
> > > > > >       contained in a virtual container (VC) that is allowed to
> > > > > float over
> > > > > >       two contiguous frames for synchronization purposes. A
> > > > > pointer in the
> > > > > >       Section Overhead (SOH) indicates the beginning of the
> > > VC in the
> > > > > >       payload." mixes SDH with SONET - pointers in SDH
> in H1/H2/H3
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 21:39:15 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: RE: WG doc. status/charter: [Was: draft-berger-ccamp-gmpls-alarm-spec to WG status?]
Date: Sun, 7 Mar 2004 13:37:16 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dimitri,

Thanks for the response.

Although the issue of what it takes for a document to become
a WG document was not really reaised in my original email, it
is good to have had some explanations about it.

With regards to the charter, as I already mentioned in my
original email, it is important for the WG to be clear on
what current charter item each specific document/work is trying to
address or solve, if any.
I think the Chairs have repeatedly made this clear over the
past several months, and I see value in that.

Also, the process of adding any work to the charter is a broader
undertaking. From the statement of the Chairs and ADs at Seoul, this
is something the WG is planning to undertake at some point, once
our current plate is cleared. And, it is a rather formal process
requiring approval from the ADs etc., so it is not a matter of
just adding an item "more explicitly" in the charter.

Whether or not this needs to be added to the charter should be addressed
closer to when the charter is up for revision, hopefully in a couple
of months.

-Vishal


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of [e-mail]
> Sent: Saturday, March 06, 2004 9:46 PM
> To: Vishal Sharma
> Cc: Adrian Farrel; [e-mail]
> Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>
>
> vishal, well, this is why the wg expects as much
> opinion/voices as possible
>
> this said, would you be more specific about yours
> (i.e. when you are questioning the use/applicability
> of this method) such that the authors can address
> it
>
> thanks,
> - dimitri.
>
> ps: concerning the charter fitting imho either it
> is considered as part of the cp mechanisms the wg
> is expected to deliver (i.e. this could have been
> part of RFC 3473) or it is the right time to add it
> more explicitly in the charter (if so desired)
>
> Vishal Sharma wrote:
>
> > Dmitri et al,
> >
> > Actually, I think this is better worded as
> >
> >  "... WG i-d status does not mean RFC status, it means it is
> >  a topic that [is in the charter] _and_ on which the WG is
> >  intersted to actively work on, starting from a reasonable
> >  basis towards an acceptable and interoperable solution
> >  [for the industry]."
> >
> > since the industry at large, and not just the WG, is the user of
> > any solution emerging from an IETF WG.
> >
> > -Vishal
> >
> >
> >>-----Original Message-----
> >>From: Vishal Sharma [mailto:[e-mail]]
> >>Sent: Saturday, March 06, 2004 5:38 PM
> >>To: [e-mail]
> >>Cc: Adrian Farrel; [e-mail]
> >>Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> >>
> >>
> >>Dmitri et al,
> >>
> >>An important phrase missing from the definition
> >>below is "in the charter" (also emphasized in Adrian's recent
> >>clarifiction in another email). Thus,
> >>
> >>"... WG i-d status does not mean RFC status, it means it is
> >>a topic that [is in the charter] _and_ on which the WG is
> >>intersted to actively work on, starting from a reasonable
> >>basis towards an acceptable and interoperable solution
> >>for the WG."
> >>
> >>-Vishal
> >>
> >>
> >>>-----Original Message-----
> >>>From: [e-mail]
> >>>[mailto:[e-mail]]
> >>>Sent: Saturday, March 06, 2004 4:11 PM
> >>>To: Vishal Sharma
> >>>Cc: Adrian Farrel; [e-mail]
> >>>Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> >>>
> >>>
> >>>all, i don't know where the end of the sentence has gone
> >>>but read the following "wg i-d status doesn't mean rfc
> >>>status, it means this is a topic on which the working
> >>>group is interested to actively work on starting from a
> >>>reasonable basis towards an acceptable and interoperable
> >>>solution for the wg."
> >>>
> >>>note that all the words "reasonable" and "acceptable"
> >>>are imho to be gauged on a case by case basis depending
> >>>on the topic itself
> >>>
> >>>thanks,
> >>>- dimitri.
> >>>
> >>>[e-mail] wrote:
> >>>
> >>>
> >>>>hi vishal,
> >>>>
> >>>>
> >>>>>It would be useful for the draft to state how it fits into the CCAMP
> >>>>>WG, and how it relates to the charter.
> >>>>>
> >>>>>One of my concerns is that exposing alarm information is something
> >>>>>that the providers may _not_ want.
> >>>>
> >>>>
> >>>>for your information, the document explicitly mentions
> >>>>
> >>>>"[...] The support of this functionality is optional.
> >>>>
> >>>>The communication of alarms within GMPLS does not imply any
> >>>>modification in behavior of processing of alarms, or for the
> >>>>communication of alarms outside of GMPLS."
> >>>>
> >>>>i think this concern has been addressed but you may want to
> >>>>be a bit more specific on *your* expectation(s) so that the
> >>>>authors may complete this section
> >>>>
> >>>>
> >>>>>Moreover, there are already likely
> >>>>>to be other methods by which a provider coordinates alarm information
> >>>>>through their network (and layers), without having it be
> >>
> >>communicated
> >>
> >>>>>explicitly via signaling.
> >>>>
> >>>>
> >>>>i don't think this document puts this under questioning
> >>>>- see also above
> >>>>
> >>>>
> >>>>>Some clarification on these points would be useful. Until such time,
> >>>>>I would prefer to hold off on it being brought under the wing
> >>>
> >>>of the WG.
> >>>
> >>>>
> >>>>i think there is a more broader issue here, wg i-d status
> >>>>doesn't mean rfc status, it means this is a topic on which
> >>>>the working group is interested to actively work on
> >>>>
> >>>>thanks,
> >>>>- dimitri.
> >>>>
> >>>>
> >>>>>-Vishal
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: [e-mail] [mailto:[e-mail]]On
> >>>>>>Behalf Of Adrian Farrel
> >>>>>>Sent: Saturday, March 06, 2004 4:21 AM
> >>>>>>To: [e-mail]
> >>>>>>Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> >>>>>>
> >>>>>>
> >>>>>>In Seoul we ran out of time before we could discuss this draft.
> >>>>>>
> >>>>>>However, the draft is pretty stable, and it is the opinion of the
> >>>>>>authors that this should
> >>>>>>be brought under the wing of the WG.
> >>>>>>
> >>>>>>Can you please send your opinions to the list or to the
> >>
> >>chairs direct.
> >>
> >>>>>>Silence (as usual) will be interpreted as you saying nothing.
> >>>>>>
> >>>>>>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
> >>>>>>-spec-01.txt
> >>>>>>
> >>>>>>Thanks,
> >>>>>>Adrian
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >
> >
>




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 13:42:45 +0000
Message-Id: <6.0.3.0.2.20040307081904.040708a0@mo-ex1>
Date: Sun, 07 Mar 2004 08:40:50 -0500
To: "Vishal Sharma" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Vishal,

As to fit&charter:  This work extends the path setup portion of common 
control plane protocol defined by the WG, namely GMPLS-RSVP.  Additionally 
this work matches the work item, note asterisks "Define a protocol that can 
determine the actual route and **other properties** of paths set up by 
CCAMP signaling protocols..."  You might also want to check out Hiro 
Ishimatsu's comment  from last November on this topic on the list.

As to the other issues:  In addition to Dimitri's references, the document 
already states:

    Some operators may consider alarm information as sensitive.  To
    support environments where this is the case, implementations SHOULD
    allow the user to disable the generation of ALARM_SPEC objects.

also:

    The communication of alarms within GMPLS does not imply any
    modification in behavior of processing of alarms, or for the
    communication of alarms outside of GMPLS.

What additional clarifications do you think are need in the text?

Lou

At 03:45 PM 3/6/2004 -0500, Vishal Sharma wrote:

>Folks,
>
>It would be useful for the draft to state how it fits into the CCAMP
>WG, and how it relates to the charter.
>
>One of my concerns is that exposing alarm information is something
>that the providers may _not_ want. Moreover, there are already likely
>to be other methods by which a provider coordinates alarm information
>through their network (and layers), without having it be communicated
>explicitly via signaling.
>
>Some clarification on these points would be useful. Until such time,
>I would prefer to hold off on it being brought under the wing of the WG.
>
>-Vishal
>
> > -----Original Message-----
> > From: [e-mail] 
> [<mailto:[e-mail]>mailto:[e-mail]]On
> > Behalf Of Adrian Farrel
> > Sent: Saturday, March 06, 2004 4:21 AM
> > To: [e-mail]
> > Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> >
> >
> > In Seoul we ran out of time before we could discuss this draft.
> >
> > However, the draft is pretty stable, and it is the opinion of the
> > authors that this should
> > be brought under the wing of the WG.
> >
> > Can you please send your opinions to the list or to the chairs direct.
> >
> > Silence (as usual) will be interpreted as you saying nothing.
> >
> > 
> <http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm 
>
> > -spec-01.txt
> >
> > Thanks,
> > Adrian
> >




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 12:47:16 +0000
Message-Id: <6.0.3.0.2.20040307074358.04080350@mo-ex1>
Date: Sun, 07 Mar 2004 07:44:19 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yes on all.

At 06:46 AM 3/4/2004 -0500, Adrian Farrel wrote:

>All,
>
>At the CCAMP meeting today we discussed making several drafts working 
>group items. Can you
>please express your opinion (yes/no) on whether each of the following 
>drafts is ready to
>become a CCAMP working group draft.
>
>Feel free to express yes with reservations. If you have reservations or 
>objections, please
>express them on the list. if you need anonymity for your comments then 
>please filter them
>through the chairs.
>
>Silence will be taken as meaning nothing, so please say what you think.
>
>GMPLS Signaling Procedure For Egress Control
><http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt 
>
>
>Generic Tunnel Tracing Protocol (GTTP) Specification
><http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt>http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt 
>
>
>RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
><http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt 
>
>
>GMPLS Based Segment Recovery
><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt 
>
>
>Thank you,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 12:47:00 +0000
Message-Id: <6.0.3.0.2.20040307074425.04067b70@mo-ex1>
Date: Sun, 07 Mar 2004 07:44:51 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

no surprise here, IMO yes.

At 07:20 AM 3/6/2004 -0500, Adrian Farrel wrote:

>In Seoul we ran out of time before we could discuss this draft.
>
>However, the draft is pretty stable, and it is the opinion of the authors 
>that this should
>be brought under the wing of the WG.
>
>Can you please send your opinions to the list or to the chairs direct.
>
>Silence (as usual) will be interpreted as you saying nothing.
>
><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt 
>
>
>Thanks,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 11:25:40 +0000
Message-ID: <011001c40436$bdb3d180$0800050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Vishal Sharma" <[e-mail]>, "Greg Bernstein" <[e-mail]>, "Eric Mannie" <[e-mail]>
Cc: <[e-mail]>, "Alexey Zinin" <[e-mail]>, "Bert Wijnen" <[e-mail]>
Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Sun, 7 Mar 2004 11:24:20 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks for your thoughts Vishal.

The debate occurs now.

Are the current authors willing and able to make the changes requested by the AD?

Thanks,
Adrian
----- Original Message ----- 
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein" <[e-mail]>;
"Eric Mannie" <[e-mail]>
Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>; "Bert Wijnen"
<[e-mail]>
Sent: Sunday, March 07, 2004 12:48 AM
Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control


> Adrian,
>
> Thanks for the clarification. Our (the authors) understanding is
> that the draft had passed (quite a while back, in May 2002
> actually, after we had addressed the very last round of comments from
> Kireeti), all of the processes in the WG needed to advance it to
> informational RFC.
>
> Its purpose is really to provide an overall view and framework for
> SDH/SONET control using an IP/MPLS control plane.
>
> So it would be useful for us to know exactly where the debate occurred,
> since we were not aware of it.
> (As far as the WG is concerned,  the draft was approved such a while
> back that it has been a completed item for over one-and-a-half years.)
>
> At the last discussion on it in Sept. 2003, we were told that the only
> reason it had got delayed was because it somehow missed being sent to the
> ADs on time.
>
> -Vishal
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Adrian Farrel
> > Sent: Saturday, March 06, 2004 3:11 PM
> > To: Vishal Sharma; Greg Bernstein; Eric Mannie
> > Cc: [e-mail]; Alexey Zinin
> > Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> >
> >
> > Vishal,
> >
> > The process is that the WG hands the draft off to the AD to take
> > it to the IESG. At this
> > point the AD performs a review before taking the draft to the
> > IESG and this is what we are
> > seeing the results of.
> >
> > Note that this particular draft has been under "AD watch" for a
> > while. Alex may want to
> > clarify the reason for this, but my understanding is that there
> > was some debate as to
> > whether the draft had served its purpose already (that is, as a
> > design document for the
> > other drafts on SONET/SDH) or whether it should continue and
> > become an RFC. This review is
> > the next step towards becoming an RFC.
> >
> > Cheers,
> > Adrian
> >
> > ----- Original Message -----
> > From: "Vishal Sharma" <[e-mail]>
> > To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
> > <[e-mail]>;
> > "Eric Mannie" <[e-mail]>
> > Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>
> > Sent: Saturday, March 06, 2004 8:41 PM
> > Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> >
> >
> > > Adrian et al,
> > >
> > > We will work on the document and make the appropriate modifications
> > > to incorporate the comments.
> > >
> > > BTW, Alex could you please clarify whether this is an IESG review
> > > or some other review?
> > >
> > > Our understanding after the last communication with Kireeti on this
> > > subject, sometime
> > > in July last year, was that this draft (after having passed several
> > > last calls), was being sent to the IESG for completing the process
> > > of advancing to informational RFC.
> > >
> > > Thanks,
> > > -Vishal
> > >
> > > > -----Original Message-----
> > > > From: Adrian Farrel [mailto:[e-mail]]
> > > > Sent: Saturday, March 06, 2004 4:16 AM
> > > > To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
> > > > Cc: [e-mail]
> > > > Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> > > >
> > > >
> > > > Greg, Eric, Vishal,
> > > > Are you willing and able to pick this draft up again and make the
> > > > changes from Alex?
> > > >
> > > > Thanks,
> > > > Adrian
> > > >
> > > > ----- Original Message -----
> > > > From: "Alex Zinin" <[e-mail]>
> > > > To: <[e-mail]>
> > > > Cc: <[e-mail]>
> > > > Sent: Thursday, March 04, 2004 12:48 PM
> > > > Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> > > >
> > > >
> > > > > Folks-
> > > > >
> > > > >  Please find below comments from the RTG area directorate
> > that I would
> > > > >  like the WG to consider.
> > > > >
> > > > >  Thank you.
> > > > >
> > > > > --
> > > > > Alex Zinin
> > > > >
> > > > > Technical:
> > > > > ----------
> > > > >
> > > > > Section 3.2:
> > > > >
> > > > > 1. Figure 1 misses the STM-0 branch
> > > > >
> > > > > Section 3.4.3:
> > > > >
> > > > > 2. In comparison table, PNNI word appears for the first time in this
> > > > >     document, any specific reason to mention PNNI in a
> > GMPLS context ?
> > > > >
> > > > > Section 3.5
> > > > >
> > > > > 3. "New simplified encapsulations could reduce this
> > overhead to as low
> > > > >     as 3%, but the gain is not huge compared to SDH and SONET,
> > > > which have
> > > > >     other benefits as well.)" any reference available for these new
> > > > >     simplified encapsulation(s) ?
> > > > >
> > > > > 4. "Any encapsulation of IP over WDM should at least provide error
> > > > >     monitoring capabilities (to detect signal degradation), error
> > > > >     correction capabilities, such as FEC (Forward Error
> > Correction) that
> > > > >     are particularly needed for ultra long haul
> > transmission, sufficient
> > > > >     timing information, to allow robust synchronization (that is, to
> > > > >     detect the beginning of a packet), and capacity to transport
> > > > >     signaling, routing and management messages, in order to
> > control the
> > > > >     optical switches."
> > > > >
> > > > >     The first part refers to data plane capabilities, however the
> > > > >     requirement: the "encapsulation of IP over WDM" should deliver
> > > > >     the capacity to transport IP based control plane information -
> > > > >     why is this the case ? an out of band network would also do the
> > > > >     job and this statement makes thus the implicit assumption that
> > > > >     data and control plane topology is congruent
> > > > >
> > > > > Section 6:
> > > > >
> > > > > 5. "Due to the increase in information transferred in the routing
> > > > >     protocol, it may be useful to separate the relatively static
> > > > >     parameters concerning a link from those that may be subject to
> > > > >     frequent changes. The current GMPLS routing extensions
> > [12],[13],
> > > > >     [14] do not make such a separation, however."
> > > > >
> > > > >    it may be thus worth asking the question was the dissemination
> > > > >    of these quasi-static "link capabilities" using the same rules
> > > > >    as for any other TE LSA Type 1 sub-TLV the right approach ?
> > > > >
> > > > > Section 6.1:
> > > > >
> > > > > 6. what does the following sentence brings in the scope of
> > this control
> > > > >     plane framework (and this is even not necessarily true
> > when vcat is
> > > > >     provided over different line cards):
> > > > >
> > > > >     "Note that this inverse multiplexing process can be
> > significantly
> > > > >     easier to implement with SONET/SDH signals rather than packets."
> > > > >
> > > > > Section 6.3:
> > > > >
> > > > > 7. "However, if only standard concatenation is supported
> > then reporting
> > > > >     gets trickier since there are constraints on where the
> > STS-1s can be
> > > > >     placed. SDH has still more options and constraints,
> > hence it is not
> > > > >     yet clear which is the best way to advertise bandwidth resource
> > > > >     availability/usage in SONET/SDH. At present, the GMPLS routing
> > > > >     protocol extensions define minimum and maximum values
> > for available
> > > > >     bandwidth, which allows a remote node to make some
> > deductions about
> > > > >     the amount of capacity available at a remote link and
> > the types of
> > > > >     signals it can accommodate. However, due to the
> > multiplexed nature
> > > > >     of the signals, the authors are of the opinion that reporting of
> > > > >     bandwidth particular to signal types rather than as a single
> > > > >     aggregate bit rate is probably very desirable."
> > > > >
> > > > >     -> the authors do not explain from which perspective
> > and the reasons
> > > > >     this particular bw accounting report is desirable
> > (sections 2.4.3 &
> > > > >     2.4.8 of GMPLS routing explains how these values are
> > used to take
> > > > >     into account the multiplexing capability of a SONET/SDH
> > interface),
> > > > >     there is no real determination of the missing
> > information at remote
> > > > >     nodes for the establishment of an LSP with a certain
> > amount of bw
> > > > >     (note that it is not an issue of flexible vs standard
> > concatenation
> > > > >     issue but a control plane issue)
> > > > >
> > > > > Section 7.3:
> > > > >
> > > > > 8. "This information is specified in three parts [17], each of which
> > > > >     refers to a different network layer."
> > > > >
> > > > > The description of the signaling elements shall mention the
> > following:
> > > > > (section 7.3 refers to [17] but the latter does not
> > correspond to the
> > > > > description given in this section)
> > > > >
> > > > >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
> > > > >      which contains three parts: LSP Encoding Type, Switching
> > > > Type, G-PID
> > > > >
> > > > >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
> > > > SENDER_TSPEC/FLOWSPEC
> > > > >      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT,
> > > > Transparency,
> > > > >      Profile
> > > > >
> > > > >   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
> > > > >
> > > > >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473])
> > > > >
> > > > > ----
> > > > >
> > > > >
> > > > > Editorial:
> > > > > ----------
> > > > >
> > > > > Section 3:
> > > > >
> > > > > 1. Sometimes this document refers to GMPLS other to MPLS and
> > > > >     sometimes as above as "extending IP technology"
> > > > >
> > > > > Section 3.1
> > > > >
> > > > > 2. "When a packet reaches a core packet LSR, this LSR uses
> > the label as
> > > > >     an index into a forwarding table to determine the next
> > hop and the
> > > > >     corresponding outgoing label (and, possibly, the QoS
> > treatment to be
> > > > >     given to the packet), writes the new label into the packet, and
> > > > >     forwards the packet to the next hop. "
> > > > >
> > > > > -> replace "core packet LSR" by "packet LSR"
> > > > >
> > > > > Section 3.2:
> > > > >
> > > > > 3. "SDH and SONET are two TDM standards widely used by operators to
> > > > >     transport and multiplex different tributary signals over optical
> > > > >     links, thus creating a multiplexing structure, which we call the
> > > > >     SDH/SONET multiplex. SDH, which was developed by the
> > ETSI and later
> > > > >     standardized by the ITU-T [4], is now used worldwide,
> > while SONET,
> > > > >     which was standardized by the ANSI [5], is mainly used
> > in the US.
> > > > >     However, these two standards have several similarities,
> > and to some
> > > > >     extent SONET can be viewed as a subset of SDH. Internetworking
> > > > >     between the two is possible using gateways.
> > > > >
> > > > >     Should be rather as "ITU-T SDH (G.707) includes both
> > the European
> > > > >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy
> > (T1.105)." [...]
> > > > >     "The ETSI SDH and SONET standards regarding frame structures and
> > > > >     higher order multiplexing are the same. There are some regional
> > > > >     differences on the terminology, on the use of some
> > overhead bytes,
> > > > >     and lower order multiplexing. Interworking between the two lower
> > > > >     order hierarchies is possible using gateways."
> > > > >
> > > > > Section 3.2
> > > > >
> > > > > 4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes)
> > > > >     indicates the beginning of the VC/SPE in the payload of
> > the overall
> > > > >     STM/SDH frame."
> > > > >
> > > > > -> replace "STM/SDH frame" by "STM/STS frame"
> > > > >
> > > > > Section 4.1
> > > > >
> > > > > 5. "The SONET case is a bit difficult to explain since,
> > unlike in SDH,
> > > > >     SPEs in SONET do not have individual names." they are
> > > > simply referred
> > > > >     to as VT-N SPE
> > > > >
> > > > > Section 6:
> > > > >
> > > > > 6. Since this document distinguishes between "optical
> > networks", TDM,
> > > > >     and WDM it would advisable to avoid the "optical TDM"
> > as mentioned
> > > > >     in the below sentence (it has another meaning than MSn/RSn
> > > > switching)
> > > > >
> > > > > Section 6.1:
> > > > >
> > > > > 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE
> > > > >
> > > > >  > Section 6.1:
> > > > >
> > > > > 8. "Standard and flexible concatenations are network services, while
> > > > >     virtual concatenation is a SONET/SDH end-system service recently
> > > > >     approved by the committee T1 of ANSI and ITU-T." remove
> > "recently
> > > > >     approved by the committee T1 of ANSI and ITU-T." and
> > add the corr.
> > > > >     reference.
> > > > >
> > > > > 9. "In one example of virtual concatenation, two end
> > systems supporting
> > > > >     this feature could essentially "inverse multiplex" two
> > STS-1s into a
> > > > >     virtual STS-2c for the efficient transport of 100 Mbps
> > > > Ethernet traffic."
> > > > >
> > > > > -> STS-1-2v instead of "virtual STS-2c"
> > > > >
> > > > > 10. "Section layer: Preserves all section overhead,
> > Basically does not
> > > > >      touch any of the SONET/SDH bits."
> > > > >
> > > > > -> replace last part by "Basically does not modify or terminate
> > > > >     any of the SONET/SDH overhead bits"
> > > > >
> > > > >     left column of the table misses the SDH overhead equivalent
> > > > >
> > > > > 11. Multiplexing of (?) in the following sentence "To perform
> > > > >      multiplexing, a SONET network element should be line
> > terminating."
> > > > >
> > > > > Section 6.2:
> > > > >
> > > > > 12. In the following "Standardized SONET line level protection
> > > > techniques
> > > > >      include: Linear 1+1 and linear 1:N automatic
> > protection switching
> > > > >      (APS) and both two-fiber and four-fiber bi-directional
> > > > line switched
> > > > >      rings (BLSRs). At the path layer, SONET offers
> > uni-directional path
> > > > >      switched ring protection." the same applies to SDH (to
> > be adapted
> > > > >      using the corr. terminology)
> > > > >
> > > > > Section 7:
> > > > >
> > > > > 13. "This VC-4 LSP can, in fact, be established between two non-
> > > > >      adjacent internal nodes in an SDH network, and later
> > > > >      advertised by a routing protocol as a new (virtual) link
> > > > >      called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as
> > > > >      reference
> > > > >
> > > > > 14. The following paragraph
> > > > >      "For instance, the payload of an SDH STM-1 frame does not fully
> > > > >       contain a complete unit of user data. In fact, the
> > user data is
> > > > >       contained in a virtual container (VC) that is allowed to
> > > > float over
> > > > >       two contiguous frames for synchronization purposes. A
> > > > pointer in the
> > > > >       Section Overhead (SOH) indicates the beginning of the
> > VC in the
> > > > >       payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 07:13:27 +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: Opinion sought on drafts being adopted by CCAMP
Date: Sat, 6 Mar 2004 23:11:11 -0800
Message-ID: <[e-mail]>
Thread-Topic: Opinion sought on drafts being adopted by CCAMP
Thread-Index: AcQB3/+IJLzIyDX3Q6a3yCBNZX7JGgCMfwKQ
From: "Jonathan Lang" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

=20
Adrian,
  Opinions on drafts being adopted by CCAMP WG:

>=20
> Generic Tunnel Tracing Protocol (GTTP) Specification=20
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
Yes

>=20
> RSVP-TE Extensions in support of End-to-End GMPLS-based=20
> Recovery=20
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-rec
> overy-e2e-signaling-03.txt
Yes

>=20
> GMPLS Based Segment Recovery
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-s
> egment-recovery-00.txt
Yes

Thanks,
Jonathan

>=20
> Thank you,
> Adrian
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 05:46:48 +0000
Message-ID: <[e-mail]>
Date: Sun, 07 Mar 2004 06:46:07 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Vishal Sharma <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

vishal, well, this is why the wg expects as much
opinion/voices as possible

this said, would you be more specific about yours
(i.e. when you are questioning the use/applicability
of this method) such that the authors can address
it

thanks,
- dimitri.

ps: concerning the charter fitting imho either it
is considered as part of the cp mechanisms the wg
is expected to deliver (i.e. this could have been
part of RFC 3473) or it is the right time to add it
more explicitly in the charter (if so desired)

Vishal Sharma wrote:

> Dmitri et al,
> 
> Actually, I think this is better worded as
> 
>  "... WG i-d status does not mean RFC status, it means it is
>  a topic that [is in the charter] _and_ on which the WG is
>  intersted to actively work on, starting from a reasonable
>  basis towards an acceptable and interoperable solution
>  [for the industry]."
> 
> since the industry at large, and not just the WG, is the user of
> any solution emerging from an IETF WG.
> 
> -Vishal
> 
> 
>>-----Original Message-----
>>From: Vishal Sharma [mailto:[e-mail]]
>>Sent: Saturday, March 06, 2004 5:38 PM
>>To: [e-mail]
>>Cc: Adrian Farrel; [e-mail]
>>Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>>
>>
>>Dmitri et al,
>>
>>An important phrase missing from the definition
>>below is "in the charter" (also emphasized in Adrian's recent
>>clarifiction in another email). Thus,
>>
>>"... WG i-d status does not mean RFC status, it means it is
>>a topic that [is in the charter] _and_ on which the WG is
>>intersted to actively work on, starting from a reasonable
>>basis towards an acceptable and interoperable solution
>>for the WG."
>>
>>-Vishal
>>
>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]]
>>>Sent: Saturday, March 06, 2004 4:11 PM
>>>To: Vishal Sharma
>>>Cc: Adrian Farrel; [e-mail]
>>>Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>>>
>>>
>>>all, i don't know where the end of the sentence has gone
>>>but read the following "wg i-d status doesn't mean rfc
>>>status, it means this is a topic on which the working
>>>group is interested to actively work on starting from a
>>>reasonable basis towards an acceptable and interoperable
>>>solution for the wg."
>>>
>>>note that all the words "reasonable" and "acceptable"
>>>are imho to be gauged on a case by case basis depending
>>>on the topic itself
>>>
>>>thanks,
>>>- dimitri.
>>>
>>>[e-mail] wrote:
>>>
>>>
>>>>hi vishal,
>>>>
>>>>
>>>>>It would be useful for the draft to state how it fits into the CCAMP
>>>>>WG, and how it relates to the charter.
>>>>>
>>>>>One of my concerns is that exposing alarm information is something
>>>>>that the providers may _not_ want.
>>>>
>>>>
>>>>for your information, the document explicitly mentions
>>>>
>>>>"[...] The support of this functionality is optional.
>>>>
>>>>The communication of alarms within GMPLS does not imply any
>>>>modification in behavior of processing of alarms, or for the
>>>>communication of alarms outside of GMPLS."
>>>>
>>>>i think this concern has been addressed but you may want to
>>>>be a bit more specific on *your* expectation(s) so that the
>>>>authors may complete this section
>>>>
>>>>
>>>>>Moreover, there are already likely
>>>>>to be other methods by which a provider coordinates alarm information
>>>>>through their network (and layers), without having it be
>>
>>communicated
>>
>>>>>explicitly via signaling.
>>>>
>>>>
>>>>i don't think this document puts this under questioning
>>>>- see also above
>>>>
>>>>
>>>>>Some clarification on these points would be useful. Until such time,
>>>>>I would prefer to hold off on it being brought under the wing
>>>
>>>of the WG.
>>>
>>>>
>>>>i think there is a more broader issue here, wg i-d status
>>>>doesn't mean rfc status, it means this is a topic on which
>>>>the working group is interested to actively work on
>>>>
>>>>thanks,
>>>>- dimitri.
>>>>
>>>>
>>>>>-Vishal
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail] [mailto:[e-mail]]On
>>>>>>Behalf Of Adrian Farrel
>>>>>>Sent: Saturday, March 06, 2004 4:21 AM
>>>>>>To: [e-mail]
>>>>>>Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>>>>>>
>>>>>>
>>>>>>In Seoul we ran out of time before we could discuss this draft.
>>>>>>
>>>>>>However, the draft is pretty stable, and it is the opinion of the
>>>>>>authors that this should
>>>>>>be brought under the wing of the WG.
>>>>>>
>>>>>>Can you please send your opinions to the list or to the
>>
>>chairs direct.
>>
>>>>>>Silence (as usual) will be interpreted as you saying nothing.
>>>>>>
>>>>>>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
>>>>>>-spec-01.txt
>>>>>>
>>>>>>Thanks,
>>>>>>Adrian
>>>>>>
>>>>>
>>>>>
>>>>
> 
> 




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 01:41:21 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Date: Sat, 6 Mar 2004 17:40:16 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dmitri et al,

Actually, I think this is better worded as

 "... WG i-d status does not mean RFC status, it means it is
 a topic that [is in the charter] _and_ on which the WG is
 intersted to actively work on, starting from a reasonable
 basis towards an acceptable and interoperable solution
 [for the industry]."

since the industry at large, and not just the WG, is the user of
any solution emerging from an IETF WG.

-Vishal

> -----Original Message-----
> From: Vishal Sharma [mailto:[e-mail]]
> Sent: Saturday, March 06, 2004 5:38 PM
> To: [e-mail]
> Cc: Adrian Farrel; [e-mail]
> Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>
>
> Dmitri et al,
>
> An important phrase missing from the definition
> below is "in the charter" (also emphasized in Adrian's recent
> clarifiction in another email). Thus,
>
> "... WG i-d status does not mean RFC status, it means it is
> a topic that [is in the charter] _and_ on which the WG is
> intersted to actively work on, starting from a reasonable
> basis towards an acceptable and interoperable solution
> for the WG."
>
> -Vishal
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > Sent: Saturday, March 06, 2004 4:11 PM
> > To: Vishal Sharma
> > Cc: Adrian Farrel; [e-mail]
> > Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> >
> >
> > all, i don't know where the end of the sentence has gone
> > but read the following "wg i-d status doesn't mean rfc
> > status, it means this is a topic on which the working
> > group is interested to actively work on starting from a
> > reasonable basis towards an acceptable and interoperable
> > solution for the wg."
> >
> > note that all the words "reasonable" and "acceptable"
> > are imho to be gauged on a case by case basis depending
> > on the topic itself
> >
> > thanks,
> > - dimitri.
> >
> > [e-mail] wrote:
> >
> > > hi vishal,
> > >
> > >> It would be useful for the draft to state how it fits into the CCAMP
> > >> WG, and how it relates to the charter.
> > >>
> > >> One of my concerns is that exposing alarm information is something
> > >> that the providers may _not_ want.
> > >
> > >
> > > for your information, the document explicitly mentions
> > >
> > > "[...] The support of this functionality is optional.
> > >
> > > The communication of alarms within GMPLS does not imply any
> > > modification in behavior of processing of alarms, or for the
> > > communication of alarms outside of GMPLS."
> > >
> > > i think this concern has been addressed but you may want to
> > > be a bit more specific on *your* expectation(s) so that the
> > > authors may complete this section
> > >
> > >> Moreover, there are already likely
> > >> to be other methods by which a provider coordinates alarm information
> > >> through their network (and layers), without having it be
> communicated
> > >> explicitly via signaling.
> > >
> > >
> > > i don't think this document puts this under questioning
> > > - see also above
> > >
> > >> Some clarification on these points would be useful. Until such time,
> > >> I would prefer to hold off on it being brought under the wing
> > of the WG.
> > >
> > >
> > > i think there is a more broader issue here, wg i-d status
> > > doesn't mean rfc status, it means this is a topic on which
> > > the working group is interested to actively work on
> > >
> > > thanks,
> > > - dimitri.
> > >
> > >> -Vishal
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: [e-mail] [mailto:[e-mail]]On
> > >>> Behalf Of Adrian Farrel
> > >>> Sent: Saturday, March 06, 2004 4:21 AM
> > >>> To: [e-mail]
> > >>> Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> > >>>
> > >>>
> > >>> In Seoul we ran out of time before we could discuss this draft.
> > >>>
> > >>> However, the draft is pretty stable, and it is the opinion of the
> > >>> authors that this should
> > >>> be brought under the wing of the WG.
> > >>>
> > >>> Can you please send your opinions to the list or to the
> chairs direct.
> > >>>
> > >>> Silence (as usual) will be interpreted as you saying nothing.
> > >>>
> > >>> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
> > >>> -spec-01.txt
> > >>>
> > >>> Thanks,
> > >>> Adrian
> > >>>
> > >>
> > >>
> > >
> > >




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 01:39:44 +0000
From: "Vishal Sharma" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Date: Sat, 6 Mar 2004 17:38:06 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dmitri et al,

An important phrase missing from the definition
below is "in the charter" (also emphasized in Adrian's recent
clarifiction in another email). Thus,

"... WG i-d status does not mean RFC status, it means it is
a topic that [is in the charter] _and_ on which the WG is
intersted to actively work on, starting from a reasonable
basis towards an acceptable and interoperable solution
for the WG."

-Vishal

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Saturday, March 06, 2004 4:11 PM
> To: Vishal Sharma
> Cc: Adrian Farrel; [e-mail]
> Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>
>
> all, i don't know where the end of the sentence has gone
> but read the following "wg i-d status doesn't mean rfc
> status, it means this is a topic on which the working
> group is interested to actively work on starting from a
> reasonable basis towards an acceptable and interoperable
> solution for the wg."
>
> note that all the words "reasonable" and "acceptable"
> are imho to be gauged on a case by case basis depending
> on the topic itself
>
> thanks,
> - dimitri.
>
> [e-mail] wrote:
>
> > hi vishal,
> >
> >> It would be useful for the draft to state how it fits into the CCAMP
> >> WG, and how it relates to the charter.
> >>
> >> One of my concerns is that exposing alarm information is something
> >> that the providers may _not_ want.
> >
> >
> > for your information, the document explicitly mentions
> >
> > "[...] The support of this functionality is optional.
> >
> > The communication of alarms within GMPLS does not imply any
> > modification in behavior of processing of alarms, or for the
> > communication of alarms outside of GMPLS."
> >
> > i think this concern has been addressed but you may want to
> > be a bit more specific on *your* expectation(s) so that the
> > authors may complete this section
> >
> >> Moreover, there are already likely
> >> to be other methods by which a provider coordinates alarm information
> >> through their network (and layers), without having it be communicated
> >> explicitly via signaling.
> >
> >
> > i don't think this document puts this under questioning
> > - see also above
> >
> >> Some clarification on these points would be useful. Until such time,
> >> I would prefer to hold off on it being brought under the wing
> of the WG.
> >
> >
> > i think there is a more broader issue here, wg i-d status
> > doesn't mean rfc status, it means this is a topic on which
> > the working group is interested to actively work on
> >
> > thanks,
> > - dimitri.
> >
> >> -Vishal
> >>
> >>
> >>> -----Original Message-----
> >>> From: [e-mail] [mailto:[e-mail]]On
> >>> Behalf Of Adrian Farrel
> >>> Sent: Saturday, March 06, 2004 4:21 AM
> >>> To: [e-mail]
> >>> Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> >>>
> >>>
> >>> In Seoul we ran out of time before we could discuss this draft.
> >>>
> >>> However, the draft is pretty stable, and it is the opinion of the
> >>> authors that this should
> >>> be brought under the wing of the WG.
> >>>
> >>> Can you please send your opinions to the list or to the chairs direct.
> >>>
> >>> Silence (as usual) will be interpreted as you saying nothing.
> >>>
> >>> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
> >>> -spec-01.txt
> >>>
> >>> Thanks,
> >>> Adrian
> >>>
> >>
> >>
> >
> >




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 00:50:19 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Greg Bernstein" <[e-mail]>, "Eric Mannie" <[e-mail]>
Cc: <[e-mail]>, "Alexey Zinin" <[e-mail]>, "Bert Wijnen" <[e-mail]>
Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Sat, 6 Mar 2004 16:48:23 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian,

Thanks for the clarification. Our (the authors) understanding is
that the draft had passed (quite a while back, in May 2002
actually, after we had addressed the very last round of comments from
Kireeti), all of the processes in the WG needed to advance it to
informational RFC.

Its purpose is really to provide an overall view and framework for
SDH/SONET control using an IP/MPLS control plane.

So it would be useful for us to know exactly where the debate occurred,
since we were not aware of it.
(As far as the WG is concerned,  the draft was approved such a while
back that it has been a completed item for over one-and-a-half years.)

At the last discussion on it in Sept. 2003, we were told that the only
reason it had got delayed was because it somehow missed being sent to the
ADs on time.

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Saturday, March 06, 2004 3:11 PM
> To: Vishal Sharma; Greg Bernstein; Eric Mannie
> Cc: [e-mail]; Alexey Zinin
> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> Vishal,
>
> The process is that the WG hands the draft off to the AD to take
> it to the IESG. At this
> point the AD performs a review before taking the draft to the
> IESG and this is what we are
> seeing the results of.
>
> Note that this particular draft has been under "AD watch" for a
> while. Alex may want to
> clarify the reason for this, but my understanding is that there
> was some debate as to
> whether the draft had served its purpose already (that is, as a
> design document for the
> other drafts on SONET/SDH) or whether it should continue and
> become an RFC. This review is
> the next step towards becoming an RFC.
>
> Cheers,
> Adrian
>
> ----- Original Message -----
> From: "Vishal Sharma" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein"
> <[e-mail]>;
> "Eric Mannie" <[e-mail]>
> Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>
> Sent: Saturday, March 06, 2004 8:41 PM
> Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> > Adrian et al,
> >
> > We will work on the document and make the appropriate modifications
> > to incorporate the comments.
> >
> > BTW, Alex could you please clarify whether this is an IESG review
> > or some other review?
> >
> > Our understanding after the last communication with Kireeti on this
> > subject, sometime
> > in July last year, was that this draft (after having passed several
> > last calls), was being sent to the IESG for completing the process
> > of advancing to informational RFC.
> >
> > Thanks,
> > -Vishal
> >
> > > -----Original Message-----
> > > From: Adrian Farrel [mailto:[e-mail]]
> > > Sent: Saturday, March 06, 2004 4:16 AM
> > > To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
> > > Cc: [e-mail]
> > > Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> > >
> > >
> > > Greg, Eric, Vishal,
> > > Are you willing and able to pick this draft up again and make the
> > > changes from Alex?
> > >
> > > Thanks,
> > > Adrian
> > >
> > > ----- Original Message -----
> > > From: "Alex Zinin" <[e-mail]>
> > > To: <[e-mail]>
> > > Cc: <[e-mail]>
> > > Sent: Thursday, March 04, 2004 12:48 PM
> > > Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> > >
> > >
> > > > Folks-
> > > >
> > > >  Please find below comments from the RTG area directorate
> that I would
> > > >  like the WG to consider.
> > > >
> > > >  Thank you.
> > > >
> > > > --
> > > > Alex Zinin
> > > >
> > > > Technical:
> > > > ----------
> > > >
> > > > Section 3.2:
> > > >
> > > > 1. Figure 1 misses the STM-0 branch
> > > >
> > > > Section 3.4.3:
> > > >
> > > > 2. In comparison table, PNNI word appears for the first time in this
> > > >     document, any specific reason to mention PNNI in a
> GMPLS context ?
> > > >
> > > > Section 3.5
> > > >
> > > > 3. "New simplified encapsulations could reduce this
> overhead to as low
> > > >     as 3%, but the gain is not huge compared to SDH and SONET,
> > > which have
> > > >     other benefits as well.)" any reference available for these new
> > > >     simplified encapsulation(s) ?
> > > >
> > > > 4. "Any encapsulation of IP over WDM should at least provide error
> > > >     monitoring capabilities (to detect signal degradation), error
> > > >     correction capabilities, such as FEC (Forward Error
> Correction) that
> > > >     are particularly needed for ultra long haul
> transmission, sufficient
> > > >     timing information, to allow robust synchronization (that is, to
> > > >     detect the beginning of a packet), and capacity to transport
> > > >     signaling, routing and management messages, in order to
> control the
> > > >     optical switches."
> > > >
> > > >     The first part refers to data plane capabilities, however the
> > > >     requirement: the "encapsulation of IP over WDM" should deliver
> > > >     the capacity to transport IP based control plane information -
> > > >     why is this the case ? an out of band network would also do the
> > > >     job and this statement makes thus the implicit assumption that
> > > >     data and control plane topology is congruent
> > > >
> > > > Section 6:
> > > >
> > > > 5. "Due to the increase in information transferred in the routing
> > > >     protocol, it may be useful to separate the relatively static
> > > >     parameters concerning a link from those that may be subject to
> > > >     frequent changes. The current GMPLS routing extensions
> [12],[13],
> > > >     [14] do not make such a separation, however."
> > > >
> > > >    it may be thus worth asking the question was the dissemination
> > > >    of these quasi-static "link capabilities" using the same rules
> > > >    as for any other TE LSA Type 1 sub-TLV the right approach ?
> > > >
> > > > Section 6.1:
> > > >
> > > > 6. what does the following sentence brings in the scope of
> this control
> > > >     plane framework (and this is even not necessarily true
> when vcat is
> > > >     provided over different line cards):
> > > >
> > > >     "Note that this inverse multiplexing process can be
> significantly
> > > >     easier to implement with SONET/SDH signals rather than packets."
> > > >
> > > > Section 6.3:
> > > >
> > > > 7. "However, if only standard concatenation is supported
> then reporting
> > > >     gets trickier since there are constraints on where the
> STS-1s can be
> > > >     placed. SDH has still more options and constraints,
> hence it is not
> > > >     yet clear which is the best way to advertise bandwidth resource
> > > >     availability/usage in SONET/SDH. At present, the GMPLS routing
> > > >     protocol extensions define minimum and maximum values
> for available
> > > >     bandwidth, which allows a remote node to make some
> deductions about
> > > >     the amount of capacity available at a remote link and
> the types of
> > > >     signals it can accommodate. However, due to the
> multiplexed nature
> > > >     of the signals, the authors are of the opinion that reporting of
> > > >     bandwidth particular to signal types rather than as a single
> > > >     aggregate bit rate is probably very desirable."
> > > >
> > > >     -> the authors do not explain from which perspective
> and the reasons
> > > >     this particular bw accounting report is desirable
> (sections 2.4.3 &
> > > >     2.4.8 of GMPLS routing explains how these values are
> used to take
> > > >     into account the multiplexing capability of a SONET/SDH
> interface),
> > > >     there is no real determination of the missing
> information at remote
> > > >     nodes for the establishment of an LSP with a certain
> amount of bw
> > > >     (note that it is not an issue of flexible vs standard
> concatenation
> > > >     issue but a control plane issue)
> > > >
> > > > Section 7.3:
> > > >
> > > > 8. "This information is specified in three parts [17], each of which
> > > >     refers to a different network layer."
> > > >
> > > > The description of the signaling elements shall mention the
> following:
> > > > (section 7.3 refers to [17] but the latter does not
> correspond to the
> > > > description given in this section)
> > > >
> > > >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
> > > >      which contains three parts: LSP Encoding Type, Switching
> > > Type, G-PID
> > > >
> > > >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
> > > SENDER_TSPEC/FLOWSPEC
> > > >      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT,
> > > Transparency,
> > > >      Profile
> > > >
> > > >   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
> > > >
> > > >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473])
> > > >
> > > > ----
> > > >
> > > >
> > > > Editorial:
> > > > ----------
> > > >
> > > > Section 3:
> > > >
> > > > 1. Sometimes this document refers to GMPLS other to MPLS and
> > > >     sometimes as above as "extending IP technology"
> > > >
> > > > Section 3.1
> > > >
> > > > 2. "When a packet reaches a core packet LSR, this LSR uses
> the label as
> > > >     an index into a forwarding table to determine the next
> hop and the
> > > >     corresponding outgoing label (and, possibly, the QoS
> treatment to be
> > > >     given to the packet), writes the new label into the packet, and
> > > >     forwards the packet to the next hop. "
> > > >
> > > > -> replace "core packet LSR" by "packet LSR"
> > > >
> > > > Section 3.2:
> > > >
> > > > 3. "SDH and SONET are two TDM standards widely used by operators to
> > > >     transport and multiplex different tributary signals over optical
> > > >     links, thus creating a multiplexing structure, which we call the
> > > >     SDH/SONET multiplex. SDH, which was developed by the
> ETSI and later
> > > >     standardized by the ITU-T [4], is now used worldwide,
> while SONET,
> > > >     which was standardized by the ANSI [5], is mainly used
> in the US.
> > > >     However, these two standards have several similarities,
> and to some
> > > >     extent SONET can be viewed as a subset of SDH. Internetworking
> > > >     between the two is possible using gateways.
> > > >
> > > >     Should be rather as "ITU-T SDH (G.707) includes both
> the European
> > > >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy
> (T1.105)." [...]
> > > >     "The ETSI SDH and SONET standards regarding frame structures and
> > > >     higher order multiplexing are the same. There are some regional
> > > >     differences on the terminology, on the use of some
> overhead bytes,
> > > >     and lower order multiplexing. Interworking between the two lower
> > > >     order hierarchies is possible using gateways."
> > > >
> > > > Section 3.2
> > > >
> > > > 4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes)
> > > >     indicates the beginning of the VC/SPE in the payload of
> the overall
> > > >     STM/SDH frame."
> > > >
> > > > -> replace "STM/SDH frame" by "STM/STS frame"
> > > >
> > > > Section 4.1
> > > >
> > > > 5. "The SONET case is a bit difficult to explain since,
> unlike in SDH,
> > > >     SPEs in SONET do not have individual names." they are
> > > simply referred
> > > >     to as VT-N SPE
> > > >
> > > > Section 6:
> > > >
> > > > 6. Since this document distinguishes between "optical
> networks", TDM,
> > > >     and WDM it would advisable to avoid the "optical TDM"
> as mentioned
> > > >     in the below sentence (it has another meaning than MSn/RSn
> > > switching)
> > > >
> > > > Section 6.1:
> > > >
> > > > 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE
> > > >
> > > >  > Section 6.1:
> > > >
> > > > 8. "Standard and flexible concatenations are network services, while
> > > >     virtual concatenation is a SONET/SDH end-system service recently
> > > >     approved by the committee T1 of ANSI and ITU-T." remove
> "recently
> > > >     approved by the committee T1 of ANSI and ITU-T." and
> add the corr.
> > > >     reference.
> > > >
> > > > 9. "In one example of virtual concatenation, two end
> systems supporting
> > > >     this feature could essentially "inverse multiplex" two
> STS-1s into a
> > > >     virtual STS-2c for the efficient transport of 100 Mbps
> > > Ethernet traffic."
> > > >
> > > > -> STS-1-2v instead of "virtual STS-2c"
> > > >
> > > > 10. "Section layer: Preserves all section overhead,
> Basically does not
> > > >      touch any of the SONET/SDH bits."
> > > >
> > > > -> replace last part by "Basically does not modify or terminate
> > > >     any of the SONET/SDH overhead bits"
> > > >
> > > >     left column of the table misses the SDH overhead equivalent
> > > >
> > > > 11. Multiplexing of (?) in the following sentence "To perform
> > > >      multiplexing, a SONET network element should be line
> terminating."
> > > >
> > > > Section 6.2:
> > > >
> > > > 12. In the following "Standardized SONET line level protection
> > > techniques
> > > >      include: Linear 1+1 and linear 1:N automatic
> protection switching
> > > >      (APS) and both two-fiber and four-fiber bi-directional
> > > line switched
> > > >      rings (BLSRs). At the path layer, SONET offers
> uni-directional path
> > > >      switched ring protection." the same applies to SDH (to
> be adapted
> > > >      using the corr. terminology)
> > > >
> > > > Section 7:
> > > >
> > > > 13. "This VC-4 LSP can, in fact, be established between two non-
> > > >      adjacent internal nodes in an SDH network, and later
> > > >      advertised by a routing protocol as a new (virtual) link
> > > >      called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as
> > > >      reference
> > > >
> > > > 14. The following paragraph
> > > >      "For instance, the payload of an SDH STM-1 frame does not fully
> > > >       contain a complete unit of user data. In fact, the
> user data is
> > > >       contained in a virtual container (VC) that is allowed to
> > > float over
> > > >       two contiguous frames for synchronization purposes. A
> > > pointer in the
> > > >       Section Overhead (SOH) indicates the beginning of the
> VC in the
> > > >       payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
>




Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2004 00:10:17 +0000
Message-ID: <[e-mail]>
Date: Sun, 07 Mar 2004 01:10:36 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Vishal Sharma <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

all, i don't know where the end of the sentence has gone
but read the following "wg i-d status doesn't mean rfc
status, it means this is a topic on which the working
group is interested to actively work on starting from a
reasonable basis towards an acceptable and interoperable
solution for the wg."

note that all the words "reasonable" and "acceptable"
are imho to be gauged on a case by case basis depending
on the topic itself

thanks,
- dimitri.

[e-mail] wrote:

> hi vishal,
> 
>> It would be useful for the draft to state how it fits into the CCAMP
>> WG, and how it relates to the charter.
>>
>> One of my concerns is that exposing alarm information is something
>> that the providers may _not_ want. 
> 
> 
> for your information, the document explicitly mentions
> 
> "[...] The support of this functionality is optional.
> 
> The communication of alarms within GMPLS does not imply any
> modification in behavior of processing of alarms, or for the
> communication of alarms outside of GMPLS."
> 
> i think this concern has been addressed but you may want to
> be a bit more specific on *your* expectation(s) so that the
> authors may complete this section
> 
>> Moreover, there are already likely
>> to be other methods by which a provider coordinates alarm information
>> through their network (and layers), without having it be communicated 
>> explicitly via signaling.
> 
> 
> i don't think this document puts this under questioning
> - see also above
> 
>> Some clarification on these points would be useful. Until such time,
>> I would prefer to hold off on it being brought under the wing of the WG.
> 
> 
> i think there is a more broader issue here, wg i-d status
> doesn't mean rfc status, it means this is a topic on which
> the working group is interested to actively work on
> 
> thanks,
> - dimitri.
> 
>> -Vishal
>>
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]On
>>> Behalf Of Adrian Farrel
>>> Sent: Saturday, March 06, 2004 4:21 AM
>>> To: [e-mail]
>>> Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>>>
>>>
>>> In Seoul we ran out of time before we could discuss this draft.
>>>
>>> However, the draft is pretty stable, and it is the opinion of the 
>>> authors that this should
>>> be brought under the wing of the WG.
>>>
>>> Can you please send your opinions to the list or to the chairs direct.
>>>
>>> Silence (as usual) will be interpreted as you saying nothing.
>>>
>>> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
>>> -spec-01.txt
>>>
>>> Thanks,
>>> Adrian
>>>
>>
>>
> 
> 




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 23:52:40 +0000
Date: Sat, 6 Mar 2004 15:51:18 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Ronald Bonica <[e-mail]>
cc: [e-mail]
Subject: Re: GTTP and LSP PING
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 6 Mar 2004, Ronald Bonica wrote:

> At IETF 59, an issue regarding the relationship of GTTP to LSP PING was
> raised and redirected toward the list. I am posting this message in order to
> initiate discussion.
>
> One might argue that GTTP should invoke LSP PING when tracing though an MPLS
> LSP. (In fact, previous versions of the GTTP draft stated that GTTP would
> invoke LSP PING.) I'm not sure that this is a good idea.

LSP ping traces through the data plane, which is not always possible
with GTTP.  One thing to consider is to reuse some of the formats and
objects from LSP ping.

> GTTP has a requirement to trace through multiple levels of heterogenous
> tunnels. For example, GTTP might be required to discover IP over MPLS over
> IP. If GTTP were to invoke LSP PING to discover LSP details, I fear that it
> would miss the IP tunnel at the bottom of the stack.
>
> This assumption could be wrong. Comments?

LSP ping uses TTL for tracing.  TTL-hiding tunnels present a problem.
Also, at present, LSP ping doesn't address IP tunnels, although it
could (and this has been suggested).

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 23:29:52 +0000
Message-ID: <[e-mail]>
Date: Sun, 07 Mar 2004 00:30:11 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Vishal Sharma <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi vishal,

> It would be useful for the draft to state how it fits into the CCAMP
> WG, and how it relates to the charter.
>
> One of my concerns is that exposing alarm information is something
> that the providers may _not_ want. 

for your information, the document explicitly mentions

"[...] The support of this functionality is optional.

The communication of alarms within GMPLS does not imply any
modification in behavior of processing of alarms, or for the
communication of alarms outside of GMPLS."

i think this concern has been addressed but you may want to
be a bit more specific on *your* expectation(s) so that the
authors may complete this section

> Moreover, there are already likely
> to be other methods by which a provider coordinates alarm information
> through their network (and layers), without having it be communicated 
> explicitly via signaling.

i don't think this document puts this under questioning
- see also above

> Some clarification on these points would be useful. Until such time,
> I would prefer to hold off on it being brought under the wing of the WG.

i think there is a more broader issue here, wg i-d status
doesn't mean rfc status, it means this is a topic on which
the working group is interested to actively work on

thanks,
- dimitri.

> -Vishal
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]On
>>Behalf Of Adrian Farrel
>>Sent: Saturday, March 06, 2004 4:21 AM
>>To: [e-mail]
>>Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>>
>>
>>In Seoul we ran out of time before we could discuss this draft.
>>
>>However, the draft is pretty stable, and it is the opinion of the 
>>authors that this should
>>be brought under the wing of the WG.
>>
>>Can you please send your opinions to the list or to the chairs direct.
>>
>>Silence (as usual) will be interpreted as you saying nothing.
>>
>>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
>>-spec-01.txt
>>
>>Thanks,
>>Adrian
>>
> 
> 




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 23:21:09 +0000
Message-ID: <003401c403d1$93d7d420$0800050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Vishal Sharma" <[e-mail]>, <[e-mail]>
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Date: Sat, 6 Mar 2004 23:17:32 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks Vishal,

If you have issues or concerns about these drafts I'd appreciate it if you would raise
them on the list.
draft-lang-ccamp-gmpls-recovery-e2e-signaling is over 18 months old, so no-one can claim
unseemly haste!

Please note that adoption as a WG draft means
- the draft addresses a WG charter item
- the direction of the draft is approximately right
- the WG feels that this is something they want to work on

It does not mean that this draft is perfect and ready to become an RFC tomorrow.

Thanks,
Adrian

> Opinions in-line. (Some of the drafts need more discussion and socializing
> on the list, before we can determine whether they are ready to be
> made CCAMP WG documents.)
>
> > RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
> >
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
>
> No.
>
> GMPLS Based Segment Recovery
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt
>
> No.




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 23:13:48 +0000
Message-ID: <002501c403d0$6ff98180$0800050a@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Vishal Sharma" <[e-mail]>, "Greg Bernstein" <[e-mail]>, "Eric Mannie" <[e-mail]>
Cc: <[e-mail]>, "Alexey Zinin" <[e-mail]>
Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Sat, 6 Mar 2004 23:11:24 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Vishal,

The process is that the WG hands the draft off to the AD to take it to the IESG. At this
point the AD performs a review before taking the draft to the IESG and this is what we are
seeing the results of.

Note that this particular draft has been under "AD watch" for a while. Alex may want to
clarify the reason for this, but my understanding is that there was some debate as to
whether the draft had served its purpose already (that is, as a design document for the
other drafts on SONET/SDH) or whether it should continue and become an RFC. This review is
the next step towards becoming an RFC.

Cheers,
Adrian

----- Original Message ----- 
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; "Greg Bernstein" <[e-mail]>;
"Eric Mannie" <[e-mail]>
Cc: <[e-mail]>; "Alexey Zinin" <[e-mail]>
Sent: Saturday, March 06, 2004 8:41 PM
Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control


> Adrian et al,
>
> We will work on the document and make the appropriate modifications
> to incorporate the comments.
>
> BTW, Alex could you please clarify whether this is an IESG review
> or some other review?
>
> Our understanding after the last communication with Kireeti on this
> subject, sometime
> in July last year, was that this draft (after having passed several
> last calls), was being sent to the IESG for completing the process
> of advancing to informational RFC.
>
> Thanks,
> -Vishal
>
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[e-mail]]
> > Sent: Saturday, March 06, 2004 4:16 AM
> > To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
> > Cc: [e-mail]
> > Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> >
> >
> > Greg, Eric, Vishal,
> > Are you willing and able to pick this draft up again and make the
> > changes from Alex?
> >
> > Thanks,
> > Adrian
> >
> > ----- Original Message -----
> > From: "Alex Zinin" <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Thursday, March 04, 2004 12:48 PM
> > Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
> >
> >
> > > Folks-
> > >
> > >  Please find below comments from the RTG area directorate that I would
> > >  like the WG to consider.
> > >
> > >  Thank you.
> > >
> > > --
> > > Alex Zinin
> > >
> > > Technical:
> > > ----------
> > >
> > > Section 3.2:
> > >
> > > 1. Figure 1 misses the STM-0 branch
> > >
> > > Section 3.4.3:
> > >
> > > 2. In comparison table, PNNI word appears for the first time in this
> > >     document, any specific reason to mention PNNI in a GMPLS context ?
> > >
> > > Section 3.5
> > >
> > > 3. "New simplified encapsulations could reduce this overhead to as low
> > >     as 3%, but the gain is not huge compared to SDH and SONET,
> > which have
> > >     other benefits as well.)" any reference available for these new
> > >     simplified encapsulation(s) ?
> > >
> > > 4. "Any encapsulation of IP over WDM should at least provide error
> > >     monitoring capabilities (to detect signal degradation), error
> > >     correction capabilities, such as FEC (Forward Error Correction) that
> > >     are particularly needed for ultra long haul transmission, sufficient
> > >     timing information, to allow robust synchronization (that is, to
> > >     detect the beginning of a packet), and capacity to transport
> > >     signaling, routing and management messages, in order to control the
> > >     optical switches."
> > >
> > >     The first part refers to data plane capabilities, however the
> > >     requirement: the "encapsulation of IP over WDM" should deliver
> > >     the capacity to transport IP based control plane information -
> > >     why is this the case ? an out of band network would also do the
> > >     job and this statement makes thus the implicit assumption that
> > >     data and control plane topology is congruent
> > >
> > > Section 6:
> > >
> > > 5. "Due to the increase in information transferred in the routing
> > >     protocol, it may be useful to separate the relatively static
> > >     parameters concerning a link from those that may be subject to
> > >     frequent changes. The current GMPLS routing extensions [12],[13],
> > >     [14] do not make such a separation, however."
> > >
> > >    it may be thus worth asking the question was the dissemination
> > >    of these quasi-static "link capabilities" using the same rules
> > >    as for any other TE LSA Type 1 sub-TLV the right approach ?
> > >
> > > Section 6.1:
> > >
> > > 6. what does the following sentence brings in the scope of this control
> > >     plane framework (and this is even not necessarily true when vcat is
> > >     provided over different line cards):
> > >
> > >     "Note that this inverse multiplexing process can be significantly
> > >     easier to implement with SONET/SDH signals rather than packets."
> > >
> > > Section 6.3:
> > >
> > > 7. "However, if only standard concatenation is supported then reporting
> > >     gets trickier since there are constraints on where the STS-1s can be
> > >     placed. SDH has still more options and constraints, hence it is not
> > >     yet clear which is the best way to advertise bandwidth resource
> > >     availability/usage in SONET/SDH. At present, the GMPLS routing
> > >     protocol extensions define minimum and maximum values for available
> > >     bandwidth, which allows a remote node to make some deductions about
> > >     the amount of capacity available at a remote link and the types of
> > >     signals it can accommodate. However, due to the multiplexed nature
> > >     of the signals, the authors are of the opinion that reporting of
> > >     bandwidth particular to signal types rather than as a single
> > >     aggregate bit rate is probably very desirable."
> > >
> > >     -> the authors do not explain from which perspective and the reasons
> > >     this particular bw accounting report is desirable (sections 2.4.3 &
> > >     2.4.8 of GMPLS routing explains how these values are used to take
> > >     into account the multiplexing capability of a SONET/SDH interface),
> > >     there is no real determination of the missing information at remote
> > >     nodes for the establishment of an LSP with a certain amount of bw
> > >     (note that it is not an issue of flexible vs standard concatenation
> > >     issue but a control plane issue)
> > >
> > > Section 7.3:
> > >
> > > 8. "This information is specified in three parts [17], each of which
> > >     refers to a different network layer."
> > >
> > > The description of the signaling elements shall mention the following:
> > > (section 7.3 refers to [17] but the latter does not correspond to the
> > > description given in this section)
> > >
> > >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
> > >      which contains three parts: LSP Encoding Type, Switching
> > Type, G-PID
> > >
> > >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
> > SENDER_TSPEC/FLOWSPEC
> > >      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT,
> > Transparency,
> > >      Profile
> > >
> > >   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
> > >
> > >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473])
> > >
> > > ----
> > >
> > >
> > > Editorial:
> > > ----------
> > >
> > > Section 3:
> > >
> > > 1. Sometimes this document refers to GMPLS other to MPLS and
> > >     sometimes as above as "extending IP technology"
> > >
> > > Section 3.1
> > >
> > > 2. "When a packet reaches a core packet LSR, this LSR uses the label as
> > >     an index into a forwarding table to determine the next hop and the
> > >     corresponding outgoing label (and, possibly, the QoS treatment to be
> > >     given to the packet), writes the new label into the packet, and
> > >     forwards the packet to the next hop. "
> > >
> > > -> replace "core packet LSR" by "packet LSR"
> > >
> > > Section 3.2:
> > >
> > > 3. "SDH and SONET are two TDM standards widely used by operators to
> > >     transport and multiplex different tributary signals over optical
> > >     links, thus creating a multiplexing structure, which we call the
> > >     SDH/SONET multiplex. SDH, which was developed by the ETSI and later
> > >     standardized by the ITU-T [4], is now used worldwide, while SONET,
> > >     which was standardized by the ANSI [5], is mainly used in the US.
> > >     However, these two standards have several similarities, and to some
> > >     extent SONET can be viewed as a subset of SDH. Internetworking
> > >     between the two is possible using gateways.
> > >
> > >     Should be rather as "ITU-T SDH (G.707) includes both the European
> > >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy (T1.105)." [...]
> > >     "The ETSI SDH and SONET standards regarding frame structures and
> > >     higher order multiplexing are the same. There are some regional
> > >     differences on the terminology, on the use of some overhead bytes,
> > >     and lower order multiplexing. Interworking between the two lower
> > >     order hierarchies is possible using gateways."
> > >
> > > Section 3.2
> > >
> > > 4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes)
> > >     indicates the beginning of the VC/SPE in the payload of the overall
> > >     STM/SDH frame."
> > >
> > > -> replace "STM/SDH frame" by "STM/STS frame"
> > >
> > > Section 4.1
> > >
> > > 5. "The SONET case is a bit difficult to explain since, unlike in SDH,
> > >     SPEs in SONET do not have individual names." they are
> > simply referred
> > >     to as VT-N SPE
> > >
> > > Section 6:
> > >
> > > 6. Since this document distinguishes between "optical networks", TDM,
> > >     and WDM it would advisable to avoid the "optical TDM" as mentioned
> > >     in the below sentence (it has another meaning than MSn/RSn
> > switching)
> > >
> > > Section 6.1:
> > >
> > > 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE
> > >
> > >  > Section 6.1:
> > >
> > > 8. "Standard and flexible concatenations are network services, while
> > >     virtual concatenation is a SONET/SDH end-system service recently
> > >     approved by the committee T1 of ANSI and ITU-T." remove "recently
> > >     approved by the committee T1 of ANSI and ITU-T." and add the corr.
> > >     reference.
> > >
> > > 9. "In one example of virtual concatenation, two end systems supporting
> > >     this feature could essentially "inverse multiplex" two STS-1s into a
> > >     virtual STS-2c for the efficient transport of 100 Mbps
> > Ethernet traffic."
> > >
> > > -> STS-1-2v instead of "virtual STS-2c"
> > >
> > > 10. "Section layer: Preserves all section overhead, Basically does not
> > >      touch any of the SONET/SDH bits."
> > >
> > > -> replace last part by "Basically does not modify or terminate
> > >     any of the SONET/SDH overhead bits"
> > >
> > >     left column of the table misses the SDH overhead equivalent
> > >
> > > 11. Multiplexing of (?) in the following sentence "To perform
> > >      multiplexing, a SONET network element should be line terminating."
> > >
> > > Section 6.2:
> > >
> > > 12. In the following "Standardized SONET line level protection
> > techniques
> > >      include: Linear 1+1 and linear 1:N automatic protection switching
> > >      (APS) and both two-fiber and four-fiber bi-directional
> > line switched
> > >      rings (BLSRs). At the path layer, SONET offers uni-directional path
> > >      switched ring protection." the same applies to SDH (to be adapted
> > >      using the corr. terminology)
> > >
> > > Section 7:
> > >
> > > 13. "This VC-4 LSP can, in fact, be established between two non-
> > >      adjacent internal nodes in an SDH network, and later
> > >      advertised by a routing protocol as a new (virtual) link
> > >      called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as
> > >      reference
> > >
> > > 14. The following paragraph
> > >      "For instance, the payload of an SDH STM-1 frame does not fully
> > >       contain a complete unit of user data. In fact, the user data is
> > >       contained in a virtual container (VC) that is allowed to
> > float over
> > >       two contiguous frames for synchronization purposes. A
> > pointer in the
> > >       Section Overhead (SOH) indicates the beginning of the VC in the
> > >       payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3
> > >
> > >
> > >
> > >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 20:47:02 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Date: Sat, 6 Mar 2004 12:45:44 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Folks,

It would be useful for the draft to state how it fits into the CCAMP
WG, and how it relates to the charter.

One of my concerns is that exposing alarm information is something
that the providers may _not_ want. Moreover, there are already likely
to be other methods by which a provider coordinates alarm information
through their network (and layers), without having it be communicated 
explicitly via signaling.

Some clarification on these points would be useful. Until such time,
I would prefer to hold off on it being brought under the wing of the WG.

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Saturday, March 06, 2004 4:21 AM
> To: [e-mail]
> Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> 
> 
> In Seoul we ran out of time before we could discuss this draft.
> 
> However, the draft is pretty stable, and it is the opinion of the 
> authors that this should
> be brought under the wing of the WG.
> 
> Can you please send your opinions to the list or to the chairs direct.
> 
> Silence (as usual) will be interpreted as you saying nothing.
> 
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
> -spec-01.txt
> 
> Thanks,
> Adrian
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 20:44:15 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: RE: Opinion sought on drafts being adopted by CCAMP
Date: Sat, 6 Mar 2004 12:42:00 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian,

Opinions in-line. (Some of the drafts need more discussion and socializing
on the list, before we can determine whether they are ready to be
made CCAMP WG documents.)

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, March 04, 2004 3:46 AM
> To: [e-mail]
> Subject: Opinion sought on drafts being adopted by CCAMP
>
>
> All,
>
> At the CCAMP meeting today we discussed making several drafts
> working group items. Can you
> please express your opinion (yes/no) on whether each of the
> following drafts is ready to
> become a CCAMP working group draft.
>
> Feel free to express yes with reservations. If you have
> reservations or objections, please
> express them on the list. if you need anonymity for your comments
> then please filter them
> through the chairs.
>
> Silence will be taken as meaning nothing, so please say what you think.
>
> GMPLS Signaling Procedure For Egress Control
> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-cont
> rol-01.txt

Yes.

> Generic Tunnel Tracing Protocol (GTTP) Specification
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

Yes.
> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sign
aling-03.txt

No.

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recover
y-00.txt

No.






Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 20:43:59 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Greg Bernstein" <[e-mail]>, "Eric Mannie" <[e-mail]>
Cc: <[e-mail]>, "Alexey Zinin" <[e-mail]>
Subject: RE: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Sat, 6 Mar 2004 12:41:59 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Adrian et al,

We will work on the document and make the appropriate modifications
to incorporate the comments.

BTW, Alex could you please clarify whether this is an IESG review
or some other review?

Our understanding after the last communication with Kireeti on this
subject, sometime
in July last year, was that this draft (after having passed several
last calls), was being sent to the IESG for completing the process
of advancing to informational RFC.

Thanks,
-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Saturday, March 06, 2004 4:16 AM
> To: [e-mail]; Eric Mannie; Vishal Sharma (E-mail 2)
> Cc: [e-mail]
> Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> Greg, Eric, Vishal,
> Are you willing and able to pick this draft up again and make the
> changes from Alex?
>
> Thanks,
> Adrian
>
> ----- Original Message -----
> From: "Alex Zinin" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, March 04, 2004 12:48 PM
> Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
>
>
> > Folks-
> >
> >  Please find below comments from the RTG area directorate that I would
> >  like the WG to consider.
> >
> >  Thank you.
> >
> > --
> > Alex Zinin
> >
> > Technical:
> > ----------
> >
> > Section 3.2:
> >
> > 1. Figure 1 misses the STM-0 branch
> >
> > Section 3.4.3:
> >
> > 2. In comparison table, PNNI word appears for the first time in this
> >     document, any specific reason to mention PNNI in a GMPLS context ?
> >
> > Section 3.5
> >
> > 3. "New simplified encapsulations could reduce this overhead to as low
> >     as 3%, but the gain is not huge compared to SDH and SONET,
> which have
> >     other benefits as well.)" any reference available for these new
> >     simplified encapsulation(s) ?
> >
> > 4. "Any encapsulation of IP over WDM should at least provide error
> >     monitoring capabilities (to detect signal degradation), error
> >     correction capabilities, such as FEC (Forward Error Correction) that
> >     are particularly needed for ultra long haul transmission, sufficient
> >     timing information, to allow robust synchronization (that is, to
> >     detect the beginning of a packet), and capacity to transport
> >     signaling, routing and management messages, in order to control the
> >     optical switches."
> >
> >     The first part refers to data plane capabilities, however the
> >     requirement: the "encapsulation of IP over WDM" should deliver
> >     the capacity to transport IP based control plane information -
> >     why is this the case ? an out of band network would also do the
> >     job and this statement makes thus the implicit assumption that
> >     data and control plane topology is congruent
> >
> > Section 6:
> >
> > 5. "Due to the increase in information transferred in the routing
> >     protocol, it may be useful to separate the relatively static
> >     parameters concerning a link from those that may be subject to
> >     frequent changes. The current GMPLS routing extensions [12],[13],
> >     [14] do not make such a separation, however."
> >
> >    it may be thus worth asking the question was the dissemination
> >    of these quasi-static "link capabilities" using the same rules
> >    as for any other TE LSA Type 1 sub-TLV the right approach ?
> >
> > Section 6.1:
> >
> > 6. what does the following sentence brings in the scope of this control
> >     plane framework (and this is even not necessarily true when vcat is
> >     provided over different line cards):
> >
> >     "Note that this inverse multiplexing process can be significantly
> >     easier to implement with SONET/SDH signals rather than packets."
> >
> > Section 6.3:
> >
> > 7. "However, if only standard concatenation is supported then reporting
> >     gets trickier since there are constraints on where the STS-1s can be
> >     placed. SDH has still more options and constraints, hence it is not
> >     yet clear which is the best way to advertise bandwidth resource
> >     availability/usage in SONET/SDH. At present, the GMPLS routing
> >     protocol extensions define minimum and maximum values for available
> >     bandwidth, which allows a remote node to make some deductions about
> >     the amount of capacity available at a remote link and the types of
> >     signals it can accommodate. However, due to the multiplexed nature
> >     of the signals, the authors are of the opinion that reporting of
> >     bandwidth particular to signal types rather than as a single
> >     aggregate bit rate is probably very desirable."
> >
> >     -> the authors do not explain from which perspective and the reasons
> >     this particular bw accounting report is desirable (sections 2.4.3 &
> >     2.4.8 of GMPLS routing explains how these values are used to take
> >     into account the multiplexing capability of a SONET/SDH interface),
> >     there is no real determination of the missing information at remote
> >     nodes for the establishment of an LSP with a certain amount of bw
> >     (note that it is not an issue of flexible vs standard concatenation
> >     issue but a control plane issue)
> >
> > Section 7.3:
> >
> > 8. "This information is specified in three parts [17], each of which
> >     refers to a different network layer."
> >
> > The description of the signaling elements shall mention the following:
> > (section 7.3 refers to [17] but the latter does not correspond to the
> > description given in this section)
> >
> >   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
> >      which contains three parts: LSP Encoding Type, Switching
> Type, G-PID
> >
> >   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as
> SENDER_TSPEC/FLOWSPEC
> >      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT,
> Transparency,
> >      Profile
> >
> >   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
> >
> >   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473])
> >
> > ----
> >
> >
> > Editorial:
> > ----------
> >
> > Section 3:
> >
> > 1. Sometimes this document refers to GMPLS other to MPLS and
> >     sometimes as above as "extending IP technology"
> >
> > Section 3.1
> >
> > 2. "When a packet reaches a core packet LSR, this LSR uses the label as
> >     an index into a forwarding table to determine the next hop and the
> >     corresponding outgoing label (and, possibly, the QoS treatment to be
> >     given to the packet), writes the new label into the packet, and
> >     forwards the packet to the next hop. "
> >
> > -> replace "core packet LSR" by "packet LSR"
> >
> > Section 3.2:
> >
> > 3. "SDH and SONET are two TDM standards widely used by operators to
> >     transport and multiplex different tributary signals over optical
> >     links, thus creating a multiplexing structure, which we call the
> >     SDH/SONET multiplex. SDH, which was developed by the ETSI and later
> >     standardized by the ITU-T [4], is now used worldwide, while SONET,
> >     which was standardized by the ANSI [5], is mainly used in the US.
> >     However, these two standards have several similarities, and to some
> >     extent SONET can be viewed as a subset of SDH. Internetworking
> >     between the two is possible using gateways.
> >
> >     Should be rather as "ITU-T SDH (G.707) includes both the European
> >     ETSI SDH hierarchy and the USA ANSI SONET hierarchy (T1.105)." [...]
> >     "The ETSI SDH and SONET standards regarding frame structures and
> >     higher order multiplexing are the same. There are some regional
> >     differences on the terminology, on the use of some overhead bytes,
> >     and lower order multiplexing. Interworking between the two lower
> >     order hierarchies is possible using gateways."
> >
> > Section 3.2
> >
> > 4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes)
> >     indicates the beginning of the VC/SPE in the payload of the overall
> >     STM/SDH frame."
> >
> > -> replace "STM/SDH frame" by "STM/STS frame"
> >
> > Section 4.1
> >
> > 5. "The SONET case is a bit difficult to explain since, unlike in SDH,
> >     SPEs in SONET do not have individual names." they are
> simply referred
> >     to as VT-N SPE
> >
> > Section 6:
> >
> > 6. Since this document distinguishes between "optical networks", TDM,
> >     and WDM it would advisable to avoid the "optical TDM" as mentioned
> >     in the below sentence (it has another meaning than MSn/RSn
> switching)
> >
> > Section 6.1:
> >
> > 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE
> >
> >  > Section 6.1:
> >
> > 8. "Standard and flexible concatenations are network services, while
> >     virtual concatenation is a SONET/SDH end-system service recently
> >     approved by the committee T1 of ANSI and ITU-T." remove "recently
> >     approved by the committee T1 of ANSI and ITU-T." and add the corr.
> >     reference.
> >
> > 9. "In one example of virtual concatenation, two end systems supporting
> >     this feature could essentially "inverse multiplex" two STS-1s into a
> >     virtual STS-2c for the efficient transport of 100 Mbps
> Ethernet traffic."
> >
> > -> STS-1-2v instead of "virtual STS-2c"
> >
> > 10. "Section layer: Preserves all section overhead, Basically does not
> >      touch any of the SONET/SDH bits."
> >
> > -> replace last part by "Basically does not modify or terminate
> >     any of the SONET/SDH overhead bits"
> >
> >     left column of the table misses the SDH overhead equivalent
> >
> > 11. Multiplexing of (?) in the following sentence "To perform
> >      multiplexing, a SONET network element should be line terminating."
> >
> > Section 6.2:
> >
> > 12. In the following "Standardized SONET line level protection
> techniques
> >      include: Linear 1+1 and linear 1:N automatic protection switching
> >      (APS) and both two-fiber and four-fiber bi-directional
> line switched
> >      rings (BLSRs). At the path layer, SONET offers uni-directional path
> >      switched ring protection." the same applies to SDH (to be adapted
> >      using the corr. terminology)
> >
> > Section 7:
> >
> > 13. "This VC-4 LSP can, in fact, be established between two non-
> >      adjacent internal nodes in an SDH network, and later
> >      advertised by a routing protocol as a new (virtual) link
> >      called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as
> >      reference
> >
> > 14. The following paragraph
> >      "For instance, the payload of an SDH STM-1 frame does not fully
> >       contain a complete unit of user data. In fact, the user data is
> >       contained in a virtual container (VC) that is allowed to
> float over
> >       two contiguous frames for synchronization purposes. A
> pointer in the
> >       Section Overhead (SOH) indicates the beginning of the VC in the
> >       payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3
> >
> >
> >
> >




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 17:47:51 +0000
Date: Sat, 06 Mar 2004 12:43:27 -0500
From: Ronald Bonica <[e-mail]>
Subject: GTTP and LSP PING
To: [e-mail]
Message-id: <008301c403a2$b23d17b0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable

Folks,

At IETF 59, an issue regarding the relationship of GTTP to LSP PING was
raised and redirected toward the list. I am posting this message in =
order to
initiate discussion.

One might argue that GTTP should invoke LSP PING when tracing though an =
MPLS
LSP. (In fact, previous versions of the GTTP draft stated that GTTP =
would
invoke LSP PING.) I'm not sure that this is a good idea.

GTTP has a requirement to trace through multiple levels of heterogenous
tunnels. For example, GTTP might be required to discover IP over MPLS =
over
IP. If GTTP were to invoke LSP PING to discover LSP details, I fear that =
it
would miss the IP tunnel at the bottom of the stack.

This assumption could be wrong. Comments?

----------------
Ronald P. Bonica
----------------
Sometimes the easiest way to=20
start a dialog is to start talking.





Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 15:40:06 +0000
Message-Id: <[e-mail]>
Date: Sat, 06 Mar 2004 10:38:09 -0500
To: "Adrian Farrel" <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:20 PM 3/6/2004 +0000, Adrian Farrel wrote:
>In Seoul we ran out of time before we could discuss this draft.
>
>However, the draft is pretty stable, and it is the opinion of the authors 
>that this should
>be brought under the wing of the WG.
>
>Can you please send your opinions to the list or to the chairs direct.
>
>Silence (as usual) will be interpreted as you saying nothing.
>
>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt

yes

JP.

>Thanks,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 14:36:51 +0000
Message-ID: <[e-mail]>
Date: Sat, 06 Mar 2004 15:36:33 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi adrian, see in-line:

Adrian Farrel wrote:

> In Seoul we ran out of time before we could discuss this draft.
> 
> However, the draft is pretty stable, and it is the opinion of the authors that this should
> be brought under the wing of the WG.
> 
> Can you please send your opinions to the list or to the chairs direct.
> 
> Silence (as usual) will be interpreted as you saying nothing.
> 
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt

yes.

> Thanks,
> Adrian
> 
> 




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 14:35:44 +0000
Message-ID: <[e-mail]>
Date: Sat, 06 Mar 2004 15:35:07 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi adrian, see in-line:

Adrian Farrel wrote:
> All,
> 
> At the CCAMP meeting today we discussed making several drafts working group items. Can you
> please express your opinion (yes/no) on whether each of the following drafts is ready to
> become a CCAMP working group draft.
> 
> Feel free to express yes with reservations. If you have reservations or objections, please
> express them on the list. if you need anonymity for your comments then please filter them
> through the chairs.
> 
> Silence will be taken as meaning nothing, so please say what you think.
> 
> GMPLS Signaling Procedure For Egress Control
> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt

yes

> Generic Tunnel Tracing Protocol (GTTP) Specification
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

yes

> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt

yes

> GMPLS Based Segment Recovery
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt

yes

> Thank you,
> Adrian
> 
> 




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 14:16:01 +0000
Message-ID: <[e-mail]>
Date: Sat, 06 Mar 2004 09:12:52 -0500
From: Reshad Rahman <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: Nic Neate <[e-mail]>, [e-mail], Movaz Networks - Louis Berger <[e-mail]>, [e-mail], [e-mail]
Subject: Re: draft-aruns-ccamp-rsvp-restart-ext-00
Content-Type: multipart/alternative; boundary="------------050504000706060309040209"

This is a multi-part message in MIME format.
--------------050504000706060309040209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

Comments inline.

Adrian Farrel wrote:

>Hi Nic,
>
>  
>
>>I've just read your draft-aruns-ccamp-rsvp-restart-ext-00 and it looks good.
>>In particular, we've been looking at using Restart for Fast Reroute LSPs for
>>some time and this draft provides everything that is needed (like recovering
>>the FAST_REROUTE, DETOUR, SENDER_TEMPLATE and ERO
>>objects from the downstream node when they are not available from upstream).
>>    
>>
>
>Good. This concern was also raised in Seoul, and I am pleased to hear that the draft
>addresses these requirements.
>
>  
>
>>However, I have a couple of concerns (not related to Fast Reroute).
>>
>> - Your draft doesn't tackle, and won't work for, simultaneous restart of
>>adjacent nodes.  This is a problem that is tackled by
>>draft-rahman-ccamp-rsvp-restart-extensions, so merging the two drafts in
>>some way may be the best way to resolve that.  I realize that the Aruns
>>draft aims to make Restart possible for nodes which cannot retrieve state
>>from the data plane, and in that case recovering from simultaneous restart
>>of adjacent nodes isn't easy.  I think including some further extensions for
>>nodes which can retrieve some state from the data plane would be
>>appropriate.
>>    
>>
>
>Retrieving state from the data plane only answers half of the problem. However, it is
>certainly important to audit the recovered control plane information against the known
>data plane state.
>
>With regard to adjacent node failures and restarts, I believe there are actually
>sufficient capabilities here. Perhaps the authors would like to include text to clarify
>the procedures.
>
>  
>
>> - The back compatibility with RFC 3473 restart looks risky.  Draft Aruns
>>mandates that restarted nodes don't send Path Refreshes until either the
>>recovery period expires or a RecoveryPath is received from downstream.  In
>>the case that the downstream node only supports RFC 3473 restart (and so
>>doesn't send RecoveryPaths), it may well timeout Path state at the same time
>>as or very soon after the recovery period expires.  Hence a dangerous timing
>>window is created.
>>    
>>
>
>You have something here.
>However, section 9.5.3 of RFC3473 does not say that the neighbor MUST discard state that
>is not restored in the recovery time interval. Presumably it would simply recommence
>waiting for state refresh and so would time out after a 3.5 refresh intervals from the end
>of the recovery interval.
>
>Some compromise may be introduced here by noting that 3473 says that Path state SHOULD be
>restored within 1/2 of the recovery time. So we could follow this logic and use the first
>half of the time interval for the RecoveryPath message and the second half for backwards
>compatible recovery.
>
>On the other hand, I would prefer that this new capability (support for RecoveryPath
>message) was signaled in the Restart_Capabilities object so that the restarting node can
>know whether to expect to receive a RecoveryPath or not.
>
It's a good idea for the restarting node to know whether it  should 
expect RecoveryPath messages. There doesn't seem to be any room in the 
Restart_Cap object for this info, so looks like we'd need an extension.

I would also like to see a mechanism where each node could indicate on a 
per-LSP basis (e.g. at setup time) whether it would want the 
RecoveryPath message for that LSP after it restarts.

Regards,
Reshad.

>
>  
>
>>As a potential solution to both problems I'd suggest that a restarting node
>>receiving a Path message with a recovery label should always forward it
>>immediately as well as it can, and include both a recovery label and (for
>>back compatibility) a suggested label.  Similarly, it should forward
>>RecoveryPath messages immediately as well as it can.  I'd be happy to
>>discuss any of this further.
>>    
>>
>
>This sounds very dangerous.
>"As well as it can" may include path computation which may pick a path other than the one
>previously in use. Hence the new Path message will be sent to a new neighbor. This
>disaster is no better than the problem we are trying to solve.
>
>Cheers,
>Adrian
>
>
>  
>

--------------050504000706060309040209
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi all,<br>
<br>
Comments inline.<br>
<br>
Adrian Farrel wrote:<br>
<blockquote type="cite" cite="mid024001c40379$2fb0d260$ece325da@Puppy">
  <pre wrap="">Hi Nic,

  </pre>
  <blockquote type="cite">
    <pre wrap="">I've just read your draft-aruns-ccamp-rsvp-restart-ext-00 and it looks good.
In particular, we've been looking at using Restart for Fast Reroute LSPs for
some time and this draft provides everything that is needed (like recovering
the FAST_REROUTE, DETOUR, SENDER_TEMPLATE and ERO
objects from the downstream node when they are not available from upstream).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Good. This concern was also raised in Seoul, and I am pleased to hear that the draft
addresses these requirements.

  </pre>
  <blockquote type="cite">
    <pre wrap="">However, I have a couple of concerns (not related to Fast Reroute).

 - Your draft doesn't tackle, and won't work for, simultaneous restart of
adjacent nodes.  This is a problem that is tackled by
draft-rahman-ccamp-rsvp-restart-extensions, so merging the two drafts in
some way may be the best way to resolve that.  I realize that the Aruns
draft aims to make Restart possible for nodes which cannot retrieve state
from the data plane, and in that case recovering from simultaneous restart
of adjacent nodes isn't easy.  I think including some further extensions for
nodes which can retrieve some state from the data plane would be
appropriate.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Retrieving state from the data plane only answers half of the problem. However, it is
certainly important to audit the recovered control plane information against the known
data plane state.

With regard to adjacent node failures and restarts, I believe there are actually
sufficient capabilities here. Perhaps the authors would like to include text to clarify
the procedures.

  </pre>
  <blockquote type="cite">
    <pre wrap=""> - The back compatibility with RFC 3473 restart looks risky.  Draft Aruns
mandates that restarted nodes don't send Path Refreshes until either the
recovery period expires or a RecoveryPath is received from downstream.  In
the case that the downstream node only supports RFC 3473 restart (and so
doesn't send RecoveryPaths), it may well timeout Path state at the same time
as or very soon after the recovery period expires.  Hence a dangerous timing
window is created.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You have something here.
However, section 9.5.3 of RFC3473 does not say that the neighbor MUST discard state that
is not restored in the recovery time interval. Presumably it would simply recommence
waiting for state refresh and so would time out after a 3.5 refresh intervals from the end
of the recovery interval.

Some compromise may be introduced here by noting that 3473 says that Path state SHOULD be
restored within 1/2 of the recovery time. So we could follow this logic and use the first
half of the time interval for the RecoveryPath message and the second half for backwards
compatible recovery.

On the other hand, I would prefer that this new capability (support for RecoveryPath
message) was signaled in the Restart_Capabilities object so that the restarting node can
know whether to expect to receive a RecoveryPath or not.</pre>
</blockquote>
It's a good idea for the restarting node to know whether it&nbsp; should
expect RecoveryPath messages. There doesn't seem to be any room in the
Restart_Cap object for this info, so looks like we'd need an extension.
<br>
<br>
I would also like to see a mechanism where each node could indicate on
a per-LSP basis (e.g. at setup time) whether it would want the
RecoveryPath message for that LSP after it restarts. <br>
<br>
Regards,<br>
Reshad.<br>
<blockquote type="cite" cite="mid024001c40379$2fb0d260$ece325da@Puppy">
  <pre wrap="">

  </pre>
  <blockquote type="cite">
    <pre wrap="">As a potential solution to both problems I'd suggest that a restarting node
receiving a Path message with a recovery label should always forward it
immediately as well as it can, and include both a recovery label and (for
back compatibility) a suggested label.  Similarly, it should forward
RecoveryPath messages immediately as well as it can.  I'd be happy to
discuss any of this further.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This sounds very dangerous.
"As well as it can" may include path computation which may pick a path other than the one
previously in use. Hence the new Path message will be sent to a new neighbor. This
disaster is no better than the problem we are trying to solve.

Cheers,
Adrian


  </pre>
</blockquote>
</body>
</html>

--------------050504000706060309040209--




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 12:48:07 +0000
Message-ID: <024001c40379$2fb0d260$ece325da@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Nic Neate" <[e-mail]>, <[e-mail]>, "Movaz Networks - Louis Berger" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: draft-aruns-ccamp-rsvp-restart-ext-00
Date: Sat, 6 Mar 2004 12:47:17 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Nic,

> I've just read your draft-aruns-ccamp-rsvp-restart-ext-00 and it looks good.
> In particular, we've been looking at using Restart for Fast Reroute LSPs for
> some time and this draft provides everything that is needed (like recovering
> the FAST_REROUTE, DETOUR, SENDER_TEMPLATE and ERO
> objects from the downstream node when they are not available from upstream).

Good. This concern was also raised in Seoul, and I am pleased to hear that the draft
addresses these requirements.

> However, I have a couple of concerns (not related to Fast Reroute).
>
>  - Your draft doesn't tackle, and won't work for, simultaneous restart of
> adjacent nodes.  This is a problem that is tackled by
> draft-rahman-ccamp-rsvp-restart-extensions, so merging the two drafts in
> some way may be the best way to resolve that.  I realize that the Aruns
> draft aims to make Restart possible for nodes which cannot retrieve state
> from the data plane, and in that case recovering from simultaneous restart
> of adjacent nodes isn't easy.  I think including some further extensions for
> nodes which can retrieve some state from the data plane would be
> appropriate.

Retrieving state from the data plane only answers half of the problem. However, it is
certainly important to audit the recovered control plane information against the known
data plane state.

With regard to adjacent node failures and restarts, I believe there are actually
sufficient capabilities here. Perhaps the authors would like to include text to clarify
the procedures.

>  - The back compatibility with RFC 3473 restart looks risky.  Draft Aruns
> mandates that restarted nodes don't send Path Refreshes until either the
> recovery period expires or a RecoveryPath is received from downstream.  In
> the case that the downstream node only supports RFC 3473 restart (and so
> doesn't send RecoveryPaths), it may well timeout Path state at the same time
> as or very soon after the recovery period expires.  Hence a dangerous timing
> window is created.

You have something here.
However, section 9.5.3 of RFC3473 does not say that the neighbor MUST discard state that
is not restored in the recovery time interval. Presumably it would simply recommence
waiting for state refresh and so would time out after a 3.5 refresh intervals from the end
of the recovery interval.

Some compromise may be introduced here by noting that 3473 says that Path state SHOULD be
restored within 1/2 of the recovery time. So we could follow this logic and use the first
half of the time interval for the RecoveryPath message and the second half for backwards
compatible recovery.

On the other hand, I would prefer that this new capability (support for RecoveryPath
message) was signaled in the Restart_Capabilities object so that the restarting node can
know whether to expect to receive a RecoveryPath or not.

> As a potential solution to both problems I'd suggest that a restarting node
> receiving a Path message with a recovery label should always forward it
> immediately as well as it can, and include both a recovery label and (for
> back compatibility) a suggested label.  Similarly, it should forward
> RecoveryPath messages immediately as well as it can.  I'd be happy to
> discuss any of this further.

This sounds very dangerous.
"As well as it can" may include path computation which may pick a path other than the one
previously in use. Hence the new Path message will be sent to a new neighbor. This
disaster is no better than the problem we are trying to solve.

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 12:21:23 +0000
Message-ID: <022501c40375$1aef3dc0$ece325da@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Eric Mannie" <[e-mail]>, "Vishal Sharma (E-mail 2)" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: AD-review comments on draft-ietf-ccamp-sdhsonet-control
Date: Sat, 6 Mar 2004 12:16:08 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Greg, Eric, Vishal,
Are you willing and able to pick this draft up again and make the changes from Alex?

Thanks,
Adrian

----- Original Message ----- 
From: "Alex Zinin" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, March 04, 2004 12:48 PM
Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control


> Folks-
> 
>  Please find below comments from the RTG area directorate that I would
>  like the WG to consider.
> 
>  Thank you.
> 
> -- 
> Alex Zinin
> 
> Technical:
> ----------
> 
> Section 3.2:
> 
> 1. Figure 1 misses the STM-0 branch
> 
> Section 3.4.3:
> 
> 2. In comparison table, PNNI word appears for the first time in this
>     document, any specific reason to mention PNNI in a GMPLS context ?
> 
> Section 3.5
> 
> 3. "New simplified encapsulations could reduce this overhead to as low
>     as 3%, but the gain is not huge compared to SDH and SONET, which have
>     other benefits as well.)" any reference available for these new
>     simplified encapsulation(s) ?
> 
> 4. "Any encapsulation of IP over WDM should at least provide error
>     monitoring capabilities (to detect signal degradation), error
>     correction capabilities, such as FEC (Forward Error Correction) that
>     are particularly needed for ultra long haul transmission, sufficient
>     timing information, to allow robust synchronization (that is, to
>     detect the beginning of a packet), and capacity to transport
>     signaling, routing and management messages, in order to control the
>     optical switches."
> 
>     The first part refers to data plane capabilities, however the
>     requirement: the "encapsulation of IP over WDM" should deliver
>     the capacity to transport IP based control plane information -
>     why is this the case ? an out of band network would also do the
>     job and this statement makes thus the implicit assumption that
>     data and control plane topology is congruent
> 
> Section 6:
> 
> 5. "Due to the increase in information transferred in the routing
>     protocol, it may be useful to separate the relatively static
>     parameters concerning a link from those that may be subject to
>     frequent changes. The current GMPLS routing extensions [12],[13],
>     [14] do not make such a separation, however."
> 
>    it may be thus worth asking the question was the dissemination
>    of these quasi-static "link capabilities" using the same rules
>    as for any other TE LSA Type 1 sub-TLV the right approach ?
> 
> Section 6.1:
> 
> 6. what does the following sentence brings in the scope of this control
>     plane framework (and this is even not necessarily true when vcat is
>     provided over different line cards):
> 
>     "Note that this inverse multiplexing process can be significantly
>     easier to implement with SONET/SDH signals rather than packets."
> 
> Section 6.3:
> 
> 7. "However, if only standard concatenation is supported then reporting
>     gets trickier since there are constraints on where the STS-1s can be
>     placed. SDH has still more options and constraints, hence it is not
>     yet clear which is the best way to advertise bandwidth resource
>     availability/usage in SONET/SDH. At present, the GMPLS routing
>     protocol extensions define minimum and maximum values for available
>     bandwidth, which allows a remote node to make some deductions about
>     the amount of capacity available at a remote link and the types of
>     signals it can accommodate. However, due to the multiplexed nature
>     of the signals, the authors are of the opinion that reporting of
>     bandwidth particular to signal types rather than as a single
>     aggregate bit rate is probably very desirable."
> 
>     -> the authors do not explain from which perspective and the reasons
>     this particular bw accounting report is desirable (sections 2.4.3 &
>     2.4.8 of GMPLS routing explains how these values are used to take
>     into account the multiplexing capability of a SONET/SDH interface),
>     there is no real determination of the missing information at remote
>     nodes for the establishment of an LSP with a certain amount of bw
>     (note that it is not an issue of flexible vs standard concatenation
>     issue but a control plane issue)
> 
> Section 7.3:
> 
> 8. "This information is specified in three parts [17], each of which
>     refers to a different network layer."
> 
> The description of the signaling elements shall mention the following:
> (section 7.3 refers to [17] but the latter does not correspond to the
> description given in this section)
> 
>   1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
>      which contains three parts: LSP Encoding Type, Switching Type, G-PID
> 
>   2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as SENDER_TSPEC/FLOWSPEC
>      which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT, Transparency,
>      Profile
> 
>   3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])
> 
>   4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473])
> 
> ----
> 
> 
> Editorial:
> ----------
> 
> Section 3:
> 
> 1. Sometimes this document refers to GMPLS other to MPLS and
>     sometimes as above as "extending IP technology"
> 
> Section 3.1
> 
> 2. "When a packet reaches a core packet LSR, this LSR uses the label as
>     an index into a forwarding table to determine the next hop and the
>     corresponding outgoing label (and, possibly, the QoS treatment to be
>     given to the packet), writes the new label into the packet, and
>     forwards the packet to the next hop. "
> 
> -> replace "core packet LSR" by "packet LSR"
> 
> Section 3.2:
> 
> 3. "SDH and SONET are two TDM standards widely used by operators to
>     transport and multiplex different tributary signals over optical
>     links, thus creating a multiplexing structure, which we call the
>     SDH/SONET multiplex. SDH, which was developed by the ETSI and later
>     standardized by the ITU-T [4], is now used worldwide, while SONET,
>     which was standardized by the ANSI [5], is mainly used in the US.
>     However, these two standards have several similarities, and to some
>     extent SONET can be viewed as a subset of SDH. Internetworking
>     between the two is possible using gateways.
> 
>     Should be rather as "ITU-T SDH (G.707) includes both the European
>     ETSI SDH hierarchy and the USA ANSI SONET hierarchy (T1.105)." [...]
>     "The ETSI SDH and SONET standards regarding frame structures and
>     higher order multiplexing are the same. There are some regional
>     differences on the terminology, on the use of some overhead bytes,
>     and lower order multiplexing. Interworking between the two lower
>     order hierarchies is possible using gateways."
> 
> Section 3.2
> 
> 4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes)
>     indicates the beginning of the VC/SPE in the payload of the overall
>     STM/SDH frame."
> 
> -> replace "STM/SDH frame" by "STM/STS frame"
> 
> Section 4.1
> 
> 5. "The SONET case is a bit difficult to explain since, unlike in SDH,
>     SPEs in SONET do not have individual names." they are simply referred
>     to as VT-N SPE
> 
> Section 6:
> 
> 6. Since this document distinguishes between "optical networks", TDM,
>     and WDM it would advisable to avoid the "optical TDM" as mentioned
>     in the below sentence (it has another meaning than MSn/RSn switching)
> 
> Section 6.1:
> 
> 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE
> 
>  > Section 6.1:
> 
> 8. "Standard and flexible concatenations are network services, while
>     virtual concatenation is a SONET/SDH end-system service recently
>     approved by the committee T1 of ANSI and ITU-T." remove "recently
>     approved by the committee T1 of ANSI and ITU-T." and add the corr.
>     reference.
> 
> 9. "In one example of virtual concatenation, two end systems supporting
>     this feature could essentially "inverse multiplex" two STS-1s into a
>     virtual STS-2c for the efficient transport of 100 Mbps Ethernet traffic."
> 
> -> STS-1-2v instead of "virtual STS-2c"
> 
> 10. "Section layer: Preserves all section overhead, Basically does not
>      touch any of the SONET/SDH bits."
> 
> -> replace last part by "Basically does not modify or terminate
>     any of the SONET/SDH overhead bits"
> 
>     left column of the table misses the SDH overhead equivalent
> 
> 11. Multiplexing of (?) in the following sentence "To perform
>      multiplexing, a SONET network element should be line terminating."
> 
> Section 6.2:
> 
> 12. In the following "Standardized SONET line level protection techniques
>      include: Linear 1+1 and linear 1:N automatic protection switching
>      (APS) and both two-fiber and four-fiber bi-directional line switched
>      rings (BLSRs). At the path layer, SONET offers uni-directional path
>      switched ring protection." the same applies to SDH (to be adapted
>      using the corr. terminology)
> 
> Section 7:
> 
> 13. "This VC-4 LSP can, in fact, be established between two non-
>      adjacent internal nodes in an SDH network, and later
>      advertised by a routing protocol as a new (virtual) link
>      called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as
>      reference
> 
> 14. The following paragraph
>      "For instance, the payload of an SDH STM-1 frame does not fully
>       contain a complete unit of user data. In fact, the user data is
>       contained in a virtual container (VC) that is allowed to float over
>       two contiguous frames for synchronization purposes. A pointer in the
>       Section Overhead (SOH) indicates the beginning of the VC in the
>       payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 12:21:10 +0000
Message-ID: <022701c40375$74fd49b0$ece325da@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
Date: Sat, 6 Mar 2004 12:20:45 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

In Seoul we ran out of time before we could discuss this draft.

However, the draft is pretty stable, and it is the opinion of the authors that this should
be brought under the wing of the WG.

Can you please send your opinions to the list or to the chairs direct.

Silence (as usual) will be interpreted as you saying nothing.

http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 06 Mar 2004 12:20:59 +0000
Message-ID: <022601c40375$1b092e60$ece325da@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lou Berger" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Date: Sat, 6 Mar 2004 12:17:16 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Lou,
It falls into a slightly different category as it was not presented because we ran out of
time.
Hence a separate thread to follow.
Adrian
----- Original Message ----- 
From: "Lou Berger" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, March 04, 2004 2:13 PM
Subject: Re: Opinion sought on drafts being adopted by CCAMP


> Adrian,
>          I believe the alarm spec document also fell into this category, no?
> http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt
>
> Much thanks,
> Lou
>
> At 06:46 AM 3/4/2004 -0500, Adrian Farrel wrote:
>
> >All,
> >
> >At the CCAMP meeting today we discussed making several drafts working
> >group items. Can you
> >please express your opinion (yes/no) on whether each of the following
> >drafts is ready to
> >become a CCAMP working group draft.
> >
> >Feel free to express yes with reservations. If you have reservations or
> >objections, please
> >express them on the list. if you need anonymity for your comments then
> >please filter them
> >through the chairs.
> >
> >Silence will be taken as meaning nothing, so please say what you think.
> >
> >GMPLS Signaling Procedure For Egress Control
>
><http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt>http://www.
ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt
> >
> >
> >Generic Tunnel Tracing Protocol (GTTP) Specification
>
><http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt>http://www.ietf.org/int
ernet-drafts/draft-bonica-tunproto-05.txt
> >
> >
> >RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>
><http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt
> >
> >
> >GMPLS Based Segment Recovery
>
><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt>htt
p://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt
> >
> >
> >Thank you,
> >Adrian
>
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 04 Mar 2004 19:30:15 +0000
Message-Id: <[e-mail]>
Date: Thu, 04 Mar 2004 14:28:35 -0500
To: Dimitri Papadimitriou <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: thoughts on draft-vasseur-ccamp-inter-area-as-te-00.txt
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Dimitri,

At 04:24 PM 3/2/2004 +0000, Dimitri Papadimitriou wrote:
>hi jp,
>
>see in-line:
> >
> > Hi Dimitri,
> >
> > At 02:45 AM 3/2/2004 +0000, Dimitri Papadimitriou wrote:
> > >hi arthi, jp, all,
> > >
> > >reading draft-vasseur-ccamp-inter-area-as-te-00.txt
> > >the following came into my mind, why is there a need
> > >to signal the "signaling method": contiguous versus
> > >stitching vs nesting ?
> > >
> > >the reason provided in the document about "control"
> > >is unclear, is the sensitivity of the carried traffic
> > >dependent of the signaling method ?
> > >
> > >"For the sake of illustration, a Head-end LSR, may
> > >desire to prevent stitching or nesting for a traffic
> > >sensitive inter-area/AS TE LSPs that require a path
> > >control on the head-end LSR."
> > >
> > >it seems for me that "signaling the signaling method"
> > >introduces here in addition to the protocol issue(s),
> > >policy issues:
> > >
> > >"Ox01: Contiguous LSP [...]
> > >
> > >When set, this indicates that a boundary LSR MUST
> > >not perform any stitching or nesting on the TE LSP
> > >and the TE LSP MUST be routed as any other TE LSP
> > >(it must be contiguous end to end). [...]
> > >
> > >A mid-point LSR not supporting contiguous TE LSP
> > >MUST send a Path Error message upstream with error
> > >sub-code=17 Contiguous LSP type not supported."
> >
> > because when crossing multiple ASes this allows the head-end signalling a
> > contiguous LSP to make sure that it will not be stitched in some 
> downstream
> > domain hence keeping some strict control about the reoptimization. This 
> has
> > to be done on a per-LSP basis, since the same head-end may not impose any
> > such requirement for other inter-area/AS LSPs.
>
>not sure i understand that what you want to achieve requires
>the method that you are proposing here: in the hypothetical
>case of multi-as/area reoptimization, what you say is "i want
>to keep head-end control for the re-optimization of a multi-
>area/asn LSP"
>
>so here, why don't you use a flag saying "head end control
>of re-optimization" meaning we define a method such that the
>head-end decides its willingness to keep control of the re-
>optimization occurrence and upon notification could decide
>about when this has to be committed and this *independently*
>of the LSP provisioning method for this LSP
>
>in the meanwhile this would allow to be more efficient about
>the way each ingress boundary LSR decides about the method to
>deliver the incoming request constraints
>
>so, in brief define a method that would avoid constraining the
>provisioning method from the head-end as/area perspective to
>its downstream as/area for an hypothetical re-optmization that
>is in any case under the control of the local domain, and this
>in particular the local as)

Well, no, the intention here is really to offer to the head-end the ability 
to specify (just as any other LSP attributes) the signalling method that 
must be used in other downstream area/AS (note that this is clearly a SP 
requirement). Indeed, the reoptimization is just one component but there 
are also other aspects related to the signalling method in use. Hence, the 
aim of this bit is indeed to specify the signalling type of the 
inter-area/AS TE LSP.

thanks for your comments


>ps: unfortunately you're not attending this ietf meeting so
>that we can't discuss this important issue during the ccamp
>face-to-face meeting

JP.

>thanks,
>- dimitri.
> > Thanks
> >
> > JP.
> >
> > >thanks,
> > >- dimitri.
> >
> >
> >




Envelope-to: [e-mail]
Delivery-date: Thu, 04 Mar 2004 14:14:18 +0000
Message-Id: <6.0.3.0.2.20040304091146.055383a8@mo-ex1>
Date: Thu, 04 Mar 2004 09:13:21 -0500
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Opinion sought on drafts being adopted by CCAMP
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Adrian,
         I believe the alarm spec document also fell into this category, no?
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm-spec-01.txt

Much thanks,
Lou

At 06:46 AM 3/4/2004 -0500, Adrian Farrel wrote:

>All,
>
>At the CCAMP meeting today we discussed making several drafts working 
>group items. Can you
>please express your opinion (yes/no) on whether each of the following 
>drafts is ready to
>become a CCAMP working group draft.
>
>Feel free to express yes with reservations. If you have reservations or 
>objections, please
>express them on the list. if you need anonymity for your comments then 
>please filter them
>through the chairs.
>
>Silence will be taken as meaning nothing, so please say what you think.
>
>GMPLS Signaling Procedure For Egress Control
><http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt>http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt 
>
>
>Generic Tunnel Tracing Protocol (GTTP) Specification
><http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt>http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt 
>
>
>RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
><http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt 
>
>
>GMPLS Based Segment Recovery
><http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt 
>
>
>Thank you,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 04 Mar 2004 12:50:28 +0000
Date: Thu, 4 Mar 2004 21:48:45 +0900
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks-

 Please find below comments from the RTG area directorate that I would
 like the WG to consider.

 Thank you.

-- 
Alex Zinin

Technical:
----------

Section 3.2:

1. Figure 1 misses the STM-0 branch

Section 3.4.3:

2. In comparison table, PNNI word appears for the first time in this
    document, any specific reason to mention PNNI in a GMPLS context ?

Section 3.5

3. "New simplified encapsulations could reduce this overhead to as low
    as 3%, but the gain is not huge compared to SDH and SONET, which have
    other benefits as well.)" any reference available for these new
    simplified encapsulation(s) ?

4. "Any encapsulation of IP over WDM should at least provide error
    monitoring capabilities (to detect signal degradation), error
    correction capabilities, such as FEC (Forward Error Correction) that
    are particularly needed for ultra long haul transmission, sufficient
    timing information, to allow robust synchronization (that is, to
    detect the beginning of a packet), and capacity to transport
    signaling, routing and management messages, in order to control the
    optical switches."

    The first part refers to data plane capabilities, however the
    requirement: the "encapsulation of IP over WDM" should deliver
    the capacity to transport IP based control plane information -
    why is this the case ? an out of band network would also do the
    job and this statement makes thus the implicit assumption that
    data and control plane topology is congruent

Section 6:

5. "Due to the increase in information transferred in the routing
    protocol, it may be useful to separate the relatively static
    parameters concerning a link from those that may be subject to
    frequent changes. The current GMPLS routing extensions [12],[13],
    [14] do not make such a separation, however."

   it may be thus worth asking the question was the dissemination
   of these quasi-static "link capabilities" using the same rules
   as for any other TE LSA Type 1 sub-TLV the right approach ?

Section 6.1:

6. what does the following sentence brings in the scope of this control
    plane framework (and this is even not necessarily true when vcat is
    provided over different line cards):

    "Note that this inverse multiplexing process can be significantly
    easier to implement with SONET/SDH signals rather than packets."

Section 6.3:

7. "However, if only standard concatenation is supported then reporting
    gets trickier since there are constraints on where the STS-1s can be
    placed. SDH has still more options and constraints, hence it is not
    yet clear which is the best way to advertise bandwidth resource
    availability/usage in SONET/SDH. At present, the GMPLS routing
    protocol extensions define minimum and maximum values for available
    bandwidth, which allows a remote node to make some deductions about
    the amount of capacity available at a remote link and the types of
    signals it can accommodate. However, due to the multiplexed nature
    of the signals, the authors are of the opinion that reporting of
    bandwidth particular to signal types rather than as a single
    aggregate bit rate is probably very desirable."

    -> the authors do not explain from which perspective and the reasons
    this particular bw accounting report is desirable (sections 2.4.3 &
    2.4.8 of GMPLS routing explains how these values are used to take
    into account the multiplexing capability of a SONET/SDH interface),
    there is no real determination of the missing information at remote
    nodes for the establishment of an LSP with a certain amount of bw
    (note that it is not an issue of flexible vs standard concatenation
    issue but a control plane issue)

Section 7.3:

8. "This information is specified in three parts [17], each of which
    refers to a different network layer."

The description of the signaling elements shall mention the following:
(section 7.3 refers to [17] but the latter does not correspond to the
description given in this section)

  1. GENERALIZED_LABEL REQUEST (as [RFC3471/3])
     which contains three parts: LSP Encoding Type, Switching Type, G-PID

  2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as SENDER_TSPEC/FLOWSPEC
     which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT, Transparency,
     Profile

  3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3])

  4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473])

----


Editorial:
----------

Section 3:

1. Sometimes this document refers to GMPLS other to MPLS and
    sometimes as above as "extending IP technology"

Section 3.1

2. "When a packet reaches a core packet LSR, this LSR uses the label as
    an index into a forwarding table to determine the next hop and the
    corresponding outgoing label (and, possibly, the QoS treatment to be
    given to the packet), writes the new label into the packet, and
    forwards the packet to the next hop. "

-> replace "core packet LSR" by "packet LSR"

Section 3.2:

3. "SDH and SONET are two TDM standards widely used by operators to
    transport and multiplex different tributary signals over optical
    links, thus creating a multiplexing structure, which we call the
    SDH/SONET multiplex. SDH, which was developed by the ETSI and later
    standardized by the ITU-T [4], is now used worldwide, while SONET,
    which was standardized by the ANSI [5], is mainly used in the US.
    However, these two standards have several similarities, and to some
    extent SONET can be viewed as a subset of SDH. Internetworking
    between the two is possible using gateways.

    Should be rather as "ITU-T SDH (G.707) includes both the European
    ETSI SDH hierarchy and the USA ANSI SONET hierarchy (T1.105)." [...]
    "The ETSI SDH and SONET standards regarding frame structures and
    higher order multiplexing are the same. There are some regional
    differences on the terminology, on the use of some overhead bytes,
    and lower order multiplexing. Interworking between the two lower
    order hierarchies is possible using gateways."

Section 3.2

4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes)
    indicates the beginning of the VC/SPE in the payload of the overall
    STM/SDH frame."

-> replace "STM/SDH frame" by "STM/STS frame"

Section 4.1

5. "The SONET case is a bit difficult to explain since, unlike in SDH,
    SPEs in SONET do not have individual names." they are simply referred
    to as VT-N SPE

Section 6:

6. Since this document distinguishes between "optical networks", TDM,
    and WDM it would advisable to avoid the "optical TDM" as mentioned
    in the below sentence (it has another meaning than MSn/RSn switching)

Section 6.1:

7. Table 2, misses the equivalence between VC-4 and STS-3c SPE

 > Section 6.1:

8. "Standard and flexible concatenations are network services, while
    virtual concatenation is a SONET/SDH end-system service recently
    approved by the committee T1 of ANSI and ITU-T." remove "recently
    approved by the committee T1 of ANSI and ITU-T." and add the corr.
    reference.

9. "In one example of virtual concatenation, two end systems supporting
    this feature could essentially "inverse multiplex" two STS-1s into a
    virtual STS-2c for the efficient transport of 100 Mbps Ethernet traffic."

-> STS-1-2v instead of "virtual STS-2c"

10. "Section layer: Preserves all section overhead, Basically does not
     touch any of the SONET/SDH bits."

-> replace last part by "Basically does not modify or terminate
    any of the SONET/SDH overhead bits"

    left column of the table misses the SDH overhead equivalent

11. Multiplexing of (?) in the following sentence "To perform
     multiplexing, a SONET network element should be line terminating."

Section 6.2:

12. In the following "Standardized SONET line level protection techniques
     include: Linear 1+1 and linear 1:N automatic protection switching
     (APS) and both two-fiber and four-fiber bi-directional line switched
     rings (BLSRs). At the path layer, SONET offers uni-directional path
     switched ring protection." the same applies to SDH (to be adapted
     using the corr. terminology)

Section 7:

13. "This VC-4 LSP can, in fact, be established between two non-
     adjacent internal nodes in an SDH network, and later
     advertised by a routing protocol as a new (virtual) link
     called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as
     reference

14. The following paragraph
     "For instance, the payload of an SDH STM-1 frame does not fully
      contain a complete unit of user data. In fact, the user data is
      contained in a virtual container (VC) that is allowed to float over
      two contiguous frames for synchronization purposes. A pointer in the
      Section Overhead (SOH) indicates the beginning of the VC in the
      payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3




Envelope-to: [e-mail]
Delivery-date: Thu, 04 Mar 2004 11:49:43 +0000
Message-ID: <00c701c401de$af6a8e20$ece325da@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Opinion sought on drafts being adopted by CCAMP
Date: Thu, 4 Mar 2004 11:46:04 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

At the CCAMP meeting today we discussed making several drafts working group items. Can you
please express your opinion (yes/no) on whether each of the following drafts is ready to
become a CCAMP working group draft.

Feel free to express yes with reservations. If you have reservations or objections, please
express them on the list. if you need anonymity for your comments then please filter them
through the chairs.

Silence will be taken as meaning nothing, so please say what you think.

GMPLS Signaling Procedure For Egress Control
http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt

Generic Tunnel Tracing Protocol (GTTP) Specification
http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt

RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt

Thank you,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 04 Mar 2004 11:24:59 +0000
Message-ID: <00b901c401db$2ae84ff0$ece325da@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Last call on Protection and Restoration Design Team drafts
Date: Thu, 4 Mar 2004 11:23:38 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

As discussed in the CCAMP meeting today, the Protection and Restoration Design Team drafts
have been around and stable for a long time.

The terminology draft (draft-ietf-ccamp-gmpls-recovery-terminology-03.txt) is marked as
standards track, but clearly does not require an implementation.

The Functional Analysis draft (draft-ietf-ccamp-gmpls-recovery-functional-01.txt) is
neither marked as informational nor standards track - perhaps the editors would like to
fix this as a last call comment. Nevertheless, this is clearly not aimed at having an
implementation.

The Recovery Analysis draft (draft-ietf-ccamp-gmpls-recovery-analysis-02.txt) is
informational and does not need an implementation.


This email begins a working group last call on
draft-ietf-ccamp-gmpls-recovery-terminology-03.txt,
draft-ietf-ccamp-gmpls-recovery-functional-01.txt and
draft-ietf-ccamp-gmpls-recovery-analysis-02.txt

The last call will end on Friday 26th March at 12 noon GMT.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt

Comments to the list or to the chairs direct.
Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 04 Mar 2004 11:18:35 +0000
Message-ID: <00af01c401da$44171c00$ece325da@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Last call on draft-ietf-ccamp-gmpls-overlay-03.txt 
Date: Thu, 4 Mar 2004 08:38:22 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

As discussed in the CCAMP meeting today, draft-ietf-ccamp-gmpls-overlay-03.txt has been
updated with a few minor changes and is now ready for working group last call.

Several vendors have indicated that they support this function.

This email begins a working group last call on draft-ietf-ccamp-gmpls-overlay-03.txt
The last call will end on Friday 26th March at 12 noon GMT.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt

Comments to the list or to the chairs direct.
Thanks,
Adrian



Envelope-to: [e-mail]
Delivery-date: Thu, 04 Mar 2004 11:18:26 +0000
Message-ID: <00b001c401da$4472d090$ece325da@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Last call on draft-ietf-ccamp-gmpls-g709-06.txt
Date: Thu, 4 Mar 2004 08:39:28 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

As discussed in the CCAMP meeting today, draft-ietf-ccamp-gmpls-g709-06.txt has been
stable for a long time. We now have several vendors with implementations or plans to
implement, and several providers asking for the function.

This email begins a working group last call on draft-ietf-ccamp-gmpls-g709-06.txt
The last call will end on Friday 26th March at 12 noon GMT.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-06.txt

Comments to the list or to the chairs direct.
Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 04 Mar 2004 03:45:12 +0000
Message-ID: <00de01c4019a$e6176220$[e-mail]>
From: "Martin Dubuc" <[e-mail]>
To: "Ccamp-wg \(E-mail\)" <[e-mail]>
Cc: "Bert Wijnen" <[e-mail]>
Subject: draft-ietf-ccamp-lmp-mib-08.txt
Date: Wed, 3 Mar 2004 22:43:46 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01C40170.FCE44600"

This is a multi-part message in MIME format.

------=_NextPart_000_00DB_01C40170.FCE44600
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have just submitted version 08 of LMP MIB Internet Draft. This new =
version addresses Bert's comments. At end of this message are Bert's =
comments and my response on how the MIB has changed to address these =
comments.

Additional changes are:
- I have addressed point 20 in message below by adding a DEFVAL to all =
storage type objects, with nonVolatile(3) value.
- I have also updated the example section (lmpVerifyTransportMechanism) =
following Bert's suggestion (point 24).
- I have added a IANA Considerations section.
- I have updated the Intellectual Property and Copyright sections to =
comply to RFC 3667.

Martin

----- Original Message -----
From: "Wijnen, Bert (Bert)" <[e-mail]>
To: "Martin Dubuc" <[e-mail]>; "Wijnen, Bert (Bert)"
<[e-mail]>
Cc: "Adrian Farrel (E-mail)" <[e-mail]>; "Kireeti Kompella
(E-mail)" <[e-mail]>; "Alex Zinin (E-mail)" <[e-mail]>
Sent: Wednesday, December 31, 2003 1:43 PM
Subject: MIB DOctor review of prelimenary/preview
draft-ietf-ccamp-lmp-mib-08.txt


> Martin,
>
> My comments on the rev 8 that you did send me today:
>
> 1. I see
>      lmpNbrRetransmitDelta OBJECT-TYPE
>        SYNTAX        Unsigned32
>        MAX-ACCESS    read-create
>        STATUS        current
>        DESCRIPTION
>          "This object governs the speed with which the sender =
increases
>           the retransmission interval."
>     What does the value represent, i.e. what is "speed?
>     WHat are the UNITS of speed? May want to add a UNITS clause
>

[Martin] This object represents the exponential backoff or ratio of two
successful retransmission intervals. There is no real unit here. It is a
constant used in calculating the retransmission interval. Description of =
how
exponential backoff works is explained shortly in section 10.1 of LMP =
draft
and in RFC 2914. A reference to the draft is already included in the
lmpNbrRetransmitDelta object specification. I have added a bit more text =
to
explain this in the description clause and have pointed to section of =
LMP
draft and RFC 2914.


> 2. lmpNbrRowStatus
>    need to state which objects/columns MUST have a valid value before
>    row can be made active.
>

[Martin] Have followed advice given in point 7 below.

> 3. I would rename
>      lmpRemoteCcId                      Unsigned32,
>      lmpRemoteCcAddressType             InetAddressType,
>      lmpRemoteCcIpAddr                  InetAddress,
>    into
>      lmpCcRemoteId                      Unsigned32,
>      lmpCcRemoteAddressType             InetAddressType,
>      lmpCcRemoteIpAddr                  InetAddress,
>    so that it is easier to see that they are n the CC table, like
>    all the other objects in that table
>

[Martin] Done.

> 4. Description clause of lmpRemoteCcIpAddr has:
>         configuration. For point-to-point configuration, the
>         remote control channel address can be of type unknown
>         and this object set the zero length string.
>    Might be easier to read this way:
>         configuration. For point-to-point configuration, the
>         remote control channel address can be of type unknown
>         in which case this object must be the zero length string.

[Martin] Done.

> 5.lmpCcAuthentication OBJECT-TYPE
>    SYNTAX        TruthValue
>    MAX-ACCESS    read-create
>    STATUS        current
>    DESCRIPTION
>        "This object indicates whether the control channel should use
>         authentication."
>    So what if it is a true value, can someone decide not to use
>    authentication? Or would it be better o state "MUST use =
authentication"
??
>

[Martin] MUST use. I have changed text.

> 6. lmpCcOperStatus has in DESCRIPTION clasue:
>        "The actual operational status of this control channel
>         interface."
>    I thought it is not always an "interface"? Should the word =
"interface"
>    just be removed as with teh AdminStatus DESCRIPTION?
>

[Martin] Right. Done.

> 7. lmpCcRowStatus
>    pls describe which objects/columns must have appropriate/valid and
>    consistent values before row can be activated. Could be something =
aka:
>      "all read-create objects in a row must have valid and consistent
>       values before the row can be activated."
>    if that is indeed the case. Some values of course can be set from =
the
>    DEFVAL or other defaults as you describe in the specific objects.
>
>    There are more RowStatus objects in the MIB that have similar =
cocern
>    I will not repeat

[Martin] This is indeed the case. I changed all RowStatus accordingly.

>
> 8 Performance table.
>   - Formally, I think every Counter32 object needs to specify which =
timer
>     functions as the discontinuity timer. I see it is in the =
DESRIPTION
>     clause of the ...Entry. I can live with that. Let us see if anyone
barks.
>   - Formally all descriptors of a counter32 object need to express
plurality.
>     Not sure they all do. I can live with it though.
>
> 9.   lmpTeLinkEntry OBJECT-TYPE
>        SYNTAX        LmpTeLinkEntry
>        MAX-ACCESS    not-accessible
>        STATUS        current
>        DESCRIPTION
>          "An entry in this table exists for each ifEntry with an
>           ifType of teLink(200), i.e. for every TE link. An ifEntry
>           with an ifIndex must exist before the corresponding
>           teLinkEntry is created. If a TE link entry in the ifTable is
>    do you mean teLinkEntry or lmpTeLinkEntry ??
>    I think I would s/a TE link entry in the ifTable/
>                      an entry in the ifTable with ifType of =
teLink(200)/
>           destroyed, then so is the corresponding entry in the
>           teLinkTable. The administrative status value is controlled
>    do you mean teLinkTable or lmpTeLinkTable ??
>           from the ifEntry. Setting the administrative status to
>           testing prompts LMP to start link verification on the TE =
link.
>    TE link, or LMP TE link ??
>           Information about the TE link that is not LMP specific is =
also
>           contained in teLinkTable [TELINK-MIB]."
>    so that is duplicated info? If so, pls say so and say that agent is
>    required to keep data in sync.
>        INDEX         { ifIndex }
>
>    As you can see I worry a lot here about being very explicit and =
clear.
>    All these tables and types and names/descriptors that look alike =
for
>    a new implementor can be very confusing!
>    Pls do check for this confusing-text and/or possible ambuguity for =
all
>    objects in this table and in the lmpLinkVerificationTable
>
>    It would be good to aad something to the lmpTeLinkTable DESCRIPTION
clause
>    explaining the rleation ships between this table, teLinkTable and
>    ifTable. Even if there is no relation, it is confusing enough to
>    then state that explicitly.
>

[Martin] Good point. References should be to lmpTeLinkEntry and
lmpTeLinkTable in text. Actually, there is no duplication between the =
two
tables (teLinkTable and lmpTeLinkTable). I have removed the word "also"
because this might suggest some sort of duplication, which does not =
exist. I
have added some text to describe relationship between lmpTeLinkTable and
teLinkTable in the lmpTeLinkTable.

> 10.Would it be btetr to rename lmpTeLinkNbrNodeId to
lmpTeLinkNbrRemoteNodeId ?
>

[Martin] Yes. Changed.

> 11. lmpLinkVerificationInterval
>     add a UNITS clause
>

[Martin] Done.

> 12.lmpVerifyAllLinks OBJECT-TYPE
>    SYNTAX        INTEGER { verifyAllLinks(1), verifyNewLinks(2) }
>    I think I (personally) would use a TruthValue (personal taste)
>

[Martin] OK. Changed.

> 13.lmpVerifyTransmissionRate and lmpVerifyWavelength
>    add UNITS clause. Any reasonable DEFVALs possible?
>    Any usefull DEFVALs for other columns in this table?
>    In general, DEFVALs may make it much easier to do rowCreation.
>

[Martin] I have added UNITS clause. There are unfortunately no default
values in this MIB. This stems mostly from the vast array of =
transmission
gear that can implement this MIB.

> 14. No RowStatus for the read-create lmpLinkVerificationTable ??
>

[Martin] No, because this table is extension of lmpTeLinkTable.

> 15. IN DESCRIPTION clause of lmpDataLinkEntry
>     I see a citation:
>         used to get information in the componentLinkTable
>         [TELINK-MIB]."
>     When the MIB module gets extracted from the RFC, then the citation
>     becomes a dangling ptr. Better to use "RFC xxx" or mention the
>     exact MIB MODULE name directly instead of as a citation.
>
>     Pls make sure that other citations do not occur in the MIB module.
>     By the way, a citation in a comment line is fine (-- =
[some-citation])
>

[Martin] Done.

> 16. Your naming convention/consistency for lmpDataLinkTable is MUCH =
better
>     than for the earlier tables!
>
> 17. lmpDataLinkPerfTable
>     What is/are the discontinuityTimer object(s)??
>     Probably: lmpDataLinkDiscontinuityTime but you do not say so in =
ENtry
>     DESCRIPTION clause

[Martin] Have added text in Entry description clause.

> 18. lmpNotificationMaxRate
>     I think I would put all of the comment lines about the =
notifications
>     into teh DESCRIPTION clause of this object. Personal taste maybe.
>     But realize that some NMS systems use the DESCRIPTION clauses as
>     online help for operators.
>

[Martin] I moved comments in DESCRIPTION clause.

> 19. For lmpTeLinkPropertyMismatch
>         only the first time a mismatch is detected. Otherwise, for a
>         given TE link, this notification can occur no more than once
>         per verification interval."
>     Can you add the objectName for that verification interval.
>     Helps peopel to quickly find it.
>     Same for lmpDataLinkPropertyMismatch and some other notifications
>

[Martin] Done.

> 20. For all StorageType objects,. is there not a suitable DEFVAL,
>     probably nonVolatile !!??
>
> 21. WHen I see:
>        DESCRIPTION
>           "Collection of objects needed for LMP interface
>            configuration."
>        ::=3D { lmpGroups 2 }
>
>       lmpCcIsInterfaceGroup OBJECT-GROUP
>          OBJECTS { lmpCcIsIf }
>          STATUS  current
>          DESCRIPTION
>           "Objects needed to implement control channels that are
>            interfaces."
>         ::=3D { lmpGroups 3 }
>
>     I wonder... are those objects "needed"? People can configure
>     manually, no? Or via CLI??
>     I would maybe word it different (personal taste, so I will
>     not block on this):
>
>           "Collection of objects that represent then LMP interface
>            configuration."
>
>     and:
>
>           "Objects representing control channels that are
>            interfaces."
>    or:
>           "Objects which can be used to configure control channels
>            that are interfaces."
>
>     or some such.
>

[Martin] Yes, this makes it a bit clearer.

> 22. lmpNotificationGroup
>        DESCRIPTION
>           "Set of notifications implemented in this module.
>            None is mandatory."
>     remove the "None is mandatory". That is what you state in the
>     MODULE-COMPLIANCE. Here you only group the set of notifications
>     together, so they can be used in one or more compliance statements
>     where a statement is made about being mandatory, conditional or
>     optional.
>     I'd also change "implemented" into "defined".
>     The MIB Module only defines them, an agent implements them.
>

[Martin] OK.

> 23. I see:
>      1.3.6.1.2.1.10.xx.1.10.1.9  lmpCcAuthentication  [LMP-MIB]:
columnar-object-type
>      1.3.6.1.2.1.10.xx.1.10.1.12  lmpCcHelloInterval  [LMP-MIB]:
columnar-object-type
>
>     why is there a gap between 9 and 12??
>     If there is no good reason, then pls don't
>     If there is a reason, pls explain it in comments in the MIB

[Martin] There is no reason. Have removed gap.

> 24. I wonder why
>       lmpVerifyTransportMechanism =3D 1, -- j016OverheadBytes
>       lmpVerifyAllLinks           =3D verifyAllLinks(1)
>     instead of:
>       lmpVerifyTransportMechanism =3D j016OverheadBytes(1)
>       lmpVerifyAllLinks           =3D verifyAllLinks(1)
>     is that not more consistent?
>
[Martin] Not really. lmpVerifyTransportMechanism is actually a bitfield, =
so
I have shown the integer value that corresponds to the least significant =
bit
(bit 0) only being set. Maybe there is a better way to express =
bitfields.
Any suggestions?

> 25. you have in Sect 8.1 (and also the sect before that a TBD)
>    ifType        The value that is allocated for LMP is TBD.
>                  This number will be assigned by the IANA.
>
>     So where is that request to IANA made to assign an ifType for LMP?
>     You better get that added, so they know where to look for it.
>     ANd if it is in this document, then add an IANA Considerations
>     section. Might be good anyway to point out all the TBDs that they
>     need to look at. It will just speed up the process at a later =
stage.
>

[Martin] I have requested an ifType for LMP a few months ago. I haven't
heard from IANA yet. What should I do?

> admininstrative
> - I'd update the dates to 2004 (copyright, REVISION, LAST-UPDATED etc)
>

[Martin] Done.

> I did not check all the non-MIB text in detail. FOr example I did not
check
> your examples in detail... did I not do so a few months back? If not, =
I
may
> want to still do that.
>

[Martin] I am not sure if you have checked the examples in the past. But =
it
may be worth checking them again anyway because the MIB has changed =
since
the initial review.

> Anyway... it is now 7:40pm on Dec 31st for me. So I go and have my =
wine
and
> fun and won't be back till Jan 2nd.
>

[Martin] Thanks for your effort reviewing the MIB. I will post the new
version shortly.

> Thanks,
> Bert
> p.s. Have a great 2004!
>
> > -----Original Message-----
> > From: Martin Dubuc [mailto:[e-mail]]
> > Sent: woensdag 31 december 2003 14:52
> > To: Wijnen, Bert (Bert)
> > Subject: Re: lmp mib status?
> >
> >
> > Bert,
> >
> > Here is 08.
> >
> > Martin
> >
> > ----- Original Message -----
> > From: "Wijnen, Bert (Bert)" <[e-mail]>
> > To: "'Martin Dubuc'" <[e-mail]>; "'Wijnen,
> > Bert (Bert)'"
> > <[e-mail]>
> > Sent: Tuesday, December 30, 2003 11:56 AM
> > Subject: RE: lmp mib status?
> >
> >
> > > Martin, did you say you have a rev 8 ready to submit?
> > > If so, why do you not send that one to me, so I can
> > > check the latest you have?
> > >
> > > Thanks,
> > > Bert
> > >
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert)
> > > > Sent: zondag 14 december 2003 23:47
> > > > To: Martin Dubuc; Wijnen, Bert (Bert)
> > > > Subject: RE: lmp mib status?
> > > >
> > > >
> > > > Sorry to have to report that my plate keeps pretty overloaded.
> > > > It may take another week or so.
> > > >
> > > > Thanks,
> > > > Bert
> > > >
> > > > > -----Original Message-----
> > > > > From: Martin Dubuc [mailto:[e-mail]]
> > > > > Sent: zondag 14 december 2003 19:52
> > > > > To: Wijnen, Bert (Bert)
> > > > > Subject: Re: lmp mib status?
> > > > >
> > > > >
> > > > > Bert,
> > > > >
> > > > > Do you have an idea when you will be able to review LMP MIB?
> > > > >
> > > > > Martin
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Wijnen, Bert (Bert)" <[e-mail]>
> > > > > To: <[e-mail]>; <[e-mail]>
> > > > > Cc: <[e-mail]>
> > > > > Sent: Tuesday, December 02, 2003 8:05 PM
> > > > > Subject: RE: lmp mib status?
> > > > >
> > > > >
> > > > > > I have to appologize, but there is just to much on my agenda
> > > > > > this week to get to it. SO either go ahead and post the new =
ID
> > > > > > or wait till next week.
> > > > > >
> > > > > > Thanks,
> > > > > > Bert
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail]
> > > > > [mailto:[e-mail]]
> > > > > > > Sent: donderdag 27 november 2003 1:50
> > > > > > > To: [e-mail]
> > > > > > > Cc: [e-mail]
> > > > > > > Subject: Re: lmp mib status?
> > > > > > >
> > > > > > >
> > > > > > > Tom,
> > > > > > >
> > > > > > > I was just about to submit a new version with minor =
changes,
> > > > > > > but Bert asked that I hold off until he reviews the MIB =
once
> > > > > > > more. I am waiting for his comment to submit an updated
> > > > > > > version that would also address anything he would
> > raise. Bert
> > > > > > > mentioned that he did not have time to review until after
> > > > > > > IETF. Hopefully he will get back to me soon so that we can
> > > > > > > progress to the next level.
> > > > > > >
> > > > > > > Martin
> > > > > > >
> > > > > > > >
> > > > > > > > From: "Thomas D. Nadeau" <[e-mail]>
> > > > > > > > Date: 2003/11/24 Mon PM 12:04:39 EST
> > > > > > > > To: "'Martin Dubuc'" <[e-mail]>
> > > > > > > > Subject: lmp mib status?
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > What is the status of the LMP MIB?
> > > > > > > > I thought we had a last call in CCAMP that
> > > > > > > > is finished. Has the MIB been updated now?
> > > > > > > >
> > > > > > > > --Tom
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > 1
> > > > > > >
> > > > >
> > > >
> >

------=_NextPart_000_00DB_01C40170.FCE44600
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4926.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#fffbf0>
<DIV><FONT size=3D2>I have just submitted version 08 of LMP MIB Internet =
Draft.=20
This new version addresses Bert's comments.&nbsp;At end of this message =
are=20
Bert's comments and my response on how the MIB has changed to address =
these=20
comments.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Additional changes are:</FONT></DIV>
<DIV><FONT size=3D2>-&nbsp;I have addressed point 20 in message below by =
adding a=20
DEFVAL to all storage type objects, with nonVolatile(3) =
value.</FONT></DIV>
<DIV><FONT size=3D2>- I have also updated the example section=20
(lmpVerifyTransportMechanism) following&nbsp;Bert's suggestion (point=20
24).</FONT></DIV>
<DIV><FONT size=3D2>- I have added a IANA Considerations =
section.</FONT></DIV>
<DIV><FONT size=3D2>- I have updated the Intellectual Property&nbsp;and =
Copyright=20
sections to comply to RFC 3667.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Martin</FONT></DIV>
<DIV><FONT size=3D2></FONT><BR>----- Original Message -----<BR>From: =
"Wijnen, Bert=20
(Bert)" &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>To: =
"Martin=20
Dubuc" &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</=
A>&gt;;=20
"Wijnen, Bert (Bert)"<BR>&lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>Cc: =
"Adrian=20
Farrel (E-mail)" &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;; =
"Kireeti=20
Kompella<BR>(E-mail)" &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;; "Alex =
Zinin=20
(E-mail)" &lt;<A =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>Sent:=20
Wednesday, December 31, 2003 1:43 PM<BR>Subject: MIB DOctor review of=20
prelimenary/preview<BR>draft-ietf-ccamp-lmp-mib-08.txt<BR><BR><BR>&gt;=20
Martin,<BR>&gt;<BR>&gt; My comments on the rev 8 that you did send me=20
today:<BR>&gt;<BR>&gt; 1. I see<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpNbrRetransmitDelta=20
OBJECT-TYPE<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Unsigned32<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
read-create<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
current<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 "This=20
object governs the speed with which the sender=20
increases<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
the retransmission interval."<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; What does =
the=20
value represent, i.e. what is "speed?<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
WHat are=20
the UNITS of speed? May want to add a UNITS =
clause<BR>&gt;<BR><BR>[Martin] This=20
object represents the exponential backoff or ratio of two<BR>successful=20
retransmission intervals. There is no real unit here. It is =
a<BR>constant used=20
in calculating the retransmission interval. Description of =
how<BR>exponential=20
backoff works is explained shortly in section 10.1 of LMP draft<BR>and =
in RFC=20
2914. A reference to the draft is already included in=20
the<BR>lmpNbrRetransmitDelta object specification. I have added a bit =
more text=20
to<BR>explain this in the description clause and have pointed to section =
of=20
LMP<BR>draft and RFC 2914.<BR><BR><BR>&gt; 2.=20
lmpNbrRowStatus<BR>&gt;&nbsp;&nbsp;&nbsp; need to state which =
objects/columns=20
MUST have a valid value before<BR>&gt;&nbsp;&nbsp;&nbsp; row can be made =

active.<BR>&gt;<BR><BR>[Martin] Have followed advice given in point 7=20
below.<BR><BR>&gt; 3. I would =
rename<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpRemoteCcId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Unsigned32,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpRemoteCcAddressType&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
InetAddressType,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpRemoteCcIpAddr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
InetAddress,<BR>&gt;&nbsp;&nbsp;&nbsp;=20
into<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpCcRemoteId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Unsigned32,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpCcRemoteAddressType&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
InetAddressType,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpCcRemoteIpAddr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
InetAddress,<BR>&gt;&nbsp;&nbsp;&nbsp; so that it is easier to see that =
they are=20
n the CC table, like<BR>&gt;&nbsp;&nbsp;&nbsp; all the other objects in =
that=20
table<BR>&gt;<BR><BR>[Martin] Done.<BR><BR>&gt; 4. Description clause of =

lmpRemoteCcIpAddr =
has:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
configuration. For point-to-point configuration,=20
the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; remote =
control=20
channel address can be of type=20
unknown<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and this =
object=20
set the zero length string.<BR>&gt;&nbsp;&nbsp;&nbsp; Might be easier to =
read=20
this way:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
configuration.=20
For point-to-point configuration,=20
the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; remote =
control=20
channel address can be of type=20
unknown<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in which =
case=20
this object must be the zero length string.<BR><BR>[Martin] =
Done.<BR><BR>&gt;=20
5.lmpCcAuthentication OBJECT-TYPE<BR>&gt;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
TruthValue<BR>&gt;&nbsp;&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
read-create<BR>&gt;&nbsp;&nbsp;&nbsp;=20
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
current<BR>&gt;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "This =
object=20
indicates whether the control channel should=20
use<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
authentication."<BR>&gt;&nbsp;&nbsp;&nbsp; So what if it is a true =
value, can=20
someone decide not to use<BR>&gt;&nbsp;&nbsp;&nbsp; authentication? Or =
would it=20
be better o state "MUST use =
authentication"<BR>??<BR>&gt;<BR><BR>[Martin] MUST=20
use. I have changed text.<BR><BR>&gt; 6. lmpCcOperStatus has in =
DESCRIPTION=20
clasue:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "The actual=20
operational status of this control=20
channel<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
interface."<BR>&gt;&nbsp;&nbsp;&nbsp; I thought it is not always an =
"interface"?=20
Should the word "interface"<BR>&gt;&nbsp;&nbsp;&nbsp; just be removed as =
with=20
teh AdminStatus DESCRIPTION?<BR>&gt;<BR><BR>[Martin] Right. =
Done.<BR><BR>&gt; 7.=20
lmpCcRowStatus<BR>&gt;&nbsp;&nbsp;&nbsp; pls describe which =
objects/columns must=20
have appropriate/valid and<BR>&gt;&nbsp;&nbsp;&nbsp; consistent values =
before=20
row can be activated. Could be something=20
aka:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "all read-create objects in a =
row=20
must have valid and =
consistent<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
values before the row can be activated."<BR>&gt;&nbsp;&nbsp;&nbsp; if =
that is=20
indeed the case. Some values of course can be set from=20
the<BR>&gt;&nbsp;&nbsp;&nbsp; DEFVAL or other defaults as you describe =
in the=20
specific objects.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp; There are more =
RowStatus=20
objects in the MIB that have similar cocern<BR>&gt;&nbsp;&nbsp;&nbsp; I =
will not=20
repeat<BR><BR>[Martin] This is indeed the case. I changed all RowStatus=20
accordingly.<BR><BR>&gt;<BR>&gt; 8 Performance =
table.<BR>&gt;&nbsp;&nbsp; -=20
Formally, I think every Counter32 object needs to specify which=20
timer<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; functions as the discontinuity =
timer. I=20
see it is in the DESRIPTION<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; clause of =
the=20
...Entry. I can live with that. Let us see if=20
anyone<BR>barks.<BR>&gt;&nbsp;&nbsp; - Formally all descriptors of a =
counter32=20
object need to express<BR>plurality.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Not =
sure=20
they all do. I can live with it though.<BR>&gt;<BR>&gt; 9.&nbsp;&nbsp;=20
lmpTeLinkEntry =
OBJECT-TYPE<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
LmpTeLinkEntry<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
not-accessible<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
current<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 "An=20
entry in this table exists for each ifEntry with=20
an<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ifType of=20
teLink(200), i.e. for every TE link. An=20
ifEntry<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; with=20
an ifIndex must exist before the=20
corresponding<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
teLinkEntry is created. If a TE link entry in the ifTable=20
is<BR>&gt;&nbsp;&nbsp;&nbsp; do you mean teLinkEntry or lmpTeLinkEntry=20
??<BR>&gt;&nbsp;&nbsp;&nbsp; I think I would s/a TE link entry in the=20
ifTable/<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
an entry in the ifTable with ifType of=20
teLink(200)/<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
destroyed, then so is the corresponding entry in=20
the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
teLinkTable. The administrative status value is=20
controlled<BR>&gt;&nbsp;&nbsp;&nbsp; do you mean teLinkTable or =
lmpTeLinkTable=20
??<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
from the=20
ifEntry. Setting the administrative status=20
to<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
testing=20
prompts LMP to start link verification on the TE =
link.<BR>&gt;&nbsp;&nbsp;&nbsp;=20
TE link, or LMP TE link=20
??<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Information about the TE link that is not LMP specific is=20
also<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

contained in teLinkTable [TELINK-MIB]."<BR>&gt;&nbsp;&nbsp;&nbsp; so =
that is=20
duplicated info? If so, pls say so and say that agent=20
is<BR>&gt;&nbsp;&nbsp;&nbsp; required to keep data in=20
sync.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
INDEX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { ifIndex=20
}<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp; As you can see I worry a lot here =
about=20
being very explicit and clear.<BR>&gt;&nbsp;&nbsp;&nbsp; All these =
tables and=20
types and names/descriptors that look alike =
for<BR>&gt;&nbsp;&nbsp;&nbsp; a new=20
implementor can be very confusing!<BR>&gt;&nbsp;&nbsp;&nbsp; Pls do =
check for=20
this confusing-text and/or possible ambuguity for =
all<BR>&gt;&nbsp;&nbsp;&nbsp;=20
objects in this table and in the=20
lmpLinkVerificationTable<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp; It would be =
good to=20
aad something to the lmpTeLinkTable=20
DESCRIPTION<BR>clause<BR>&gt;&nbsp;&nbsp;&nbsp; explaining the rleation =
ships=20
between this table, teLinkTable and<BR>&gt;&nbsp;&nbsp;&nbsp; ifTable. =
Even if=20
there is no relation, it is confusing enough =
to<BR>&gt;&nbsp;&nbsp;&nbsp; then=20
state that explicitly.<BR>&gt;<BR><BR>[Martin] Good point. References =
should be=20
to lmpTeLinkEntry and<BR>lmpTeLinkTable in text. Actually, there is no=20
duplication between the two<BR>tables (teLinkTable and lmpTeLinkTable). =
I have=20
removed the word "also"<BR>because this might suggest some sort of =
duplication,=20
which does not exist. I<BR>have added some text to describe relationship =
between=20
lmpTeLinkTable and<BR>teLinkTable in the lmpTeLinkTable.<BR><BR>&gt; =
10.Would it=20
be btetr to rename lmpTeLinkNbrNodeId to<BR>lmpTeLinkNbrRemoteNodeId=20
?<BR>&gt;<BR><BR>[Martin] Yes. Changed.<BR><BR>&gt; 11.=20
lmpLinkVerificationInterval<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; add a UNITS=20
clause<BR>&gt;<BR><BR>[Martin] Done.<BR><BR>&gt; 12.lmpVerifyAllLinks=20
OBJECT-TYPE<BR>&gt;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER { =
verifyAllLinks(1),=20
verifyNewLinks(2) }<BR>&gt;&nbsp;&nbsp;&nbsp; I think I (personally) =
would use a=20
TruthValue (personal taste)<BR>&gt;<BR><BR>[Martin] OK. =
Changed.<BR><BR>&gt;=20
13.lmpVerifyTransmissionRate and =
lmpVerifyWavelength<BR>&gt;&nbsp;&nbsp;&nbsp;=20
add UNITS clause. Any reasonable DEFVALs =
possible?<BR>&gt;&nbsp;&nbsp;&nbsp; Any=20
usefull DEFVALs for other columns in this =
table?<BR>&gt;&nbsp;&nbsp;&nbsp; In=20
general, DEFVALs may make it much easier to do=20
rowCreation.<BR>&gt;<BR><BR>[Martin] I have added UNITS clause. There =
are=20
unfortunately no default<BR>values in this MIB. This stems mostly from =
the vast=20
array of transmission<BR>gear that can implement this MIB.<BR><BR>&gt; =
14. No=20
RowStatus for the read-create lmpLinkVerificationTable=20
??<BR>&gt;<BR><BR>[Martin] No, because this table is extension of=20
lmpTeLinkTable.<BR><BR>&gt; 15. IN DESCRIPTION clause of=20
lmpDataLinkEntry<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I see a=20
citation:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used =
to get=20
information in the=20
componentLinkTable<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
[TELINK-MIB]."<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; When the MIB module gets=20
extracted from the RFC, then the =
citation<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
becomes a dangling ptr. Better to use "RFC xxx" or mention=20
the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; exact MIB MODULE name directly =
instead of as=20
a citation.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Pls make sure that =
other=20
citations do not occur in the MIB =
module.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; By the=20
way, a citation in a comment line is fine (--=20
[some-citation])<BR>&gt;<BR><BR>[Martin] Done.<BR><BR>&gt; 16. Your =
naming=20
convention/consistency for lmpDataLinkTable is MUCH=20
better<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; than for the earlier=20
tables!<BR>&gt;<BR>&gt; 17. =
lmpDataLinkPerfTable<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
What is/are the discontinuityTimer =
object(s)??<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
Probably: lmpDataLinkDiscontinuityTime but you do not say so in=20
ENtry<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; DESCRIPTION clause<BR><BR>[Martin] =
Have=20
added text in Entry description clause.<BR><BR>&gt; 18.=20
lmpNotificationMaxRate<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I think I would =
put all=20
of the comment lines about the =
notifications<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
into teh DESCRIPTION clause of this object. Personal taste=20
maybe.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; But realize that some NMS systems =
use the=20
DESCRIPTION clauses as<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; online help for=20
operators.<BR>&gt;<BR><BR>[Martin] I moved comments in DESCRIPTION=20
clause.<BR><BR>&gt; 19. For=20
lmpTeLinkPropertyMismatch<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
only the first time a mismatch is detected. Otherwise, for=20
a<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; given TE link, =
this=20
notification can occur no more than=20
once<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; per =
verification=20
interval."<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Can you add the objectName =
for that=20
verification interval.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Helps peopel to =
quickly=20
find it.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Same for =
lmpDataLinkPropertyMismatch=20
and some other notifications<BR>&gt;<BR><BR>[Martin] Done.<BR><BR>&gt; =
20. For=20
all StorageType objects,. is there not a suitable=20
DEFVAL,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; probably nonVolatile=20
!!??<BR>&gt;<BR>&gt; 21. WHen I=20
see:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
"Collection of objects needed for LMP=20
interface<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
configuration."<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D =
{=20
lmpGroups 2 }<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpCcIsInterfaceGroup=20
OBJECT-GROUP<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
OBJECTS { lmpCcIsIf=20
}<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
STATUS&nbsp;=20
current<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
"Objects needed to implement control channels that=20
are<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
interfaces."<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
::=3D {=20
lmpGroups 3 }<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I wonder... are =
those=20
objects "needed"? People can configure<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
manually,=20
no? Or via CLI??<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I would maybe word it =
different=20
(personal taste, so I will<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; not block on=20
this):<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
"Collection of objects that represent then LMP=20
interface<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
configuration."<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
and:<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
"Objects representing control channels that=20
are<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
interfaces."<BR>&gt;&nbsp;&nbsp;&nbsp;=20
or:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
"Objects=20
which can be used to configure control=20
channels<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
that are interfaces."<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; or some=20
such.<BR>&gt;<BR><BR>[Martin] Yes, this makes it a bit =
clearer.<BR><BR>&gt; 22.=20
lmpNotificationGroup<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DESCRIPTION<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
"Set of notifications implemented in this=20
module.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
None is mandatory."<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; remove the "None is=20
mandatory". That is what you state in =
the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
MODULE-COMPLIANCE. Here you only group the set of=20
notifications<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; together, so they can be =
used in=20
one or more compliance statements<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; where =
a=20
statement is made about being mandatory, conditional=20
or<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
optional.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I'd=20
also change "implemented" into =
"defined".<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The=20
MIB Module only defines them, an agent implements =
them.<BR>&gt;<BR><BR>[Martin]=20
OK.<BR><BR>&gt; 23. I see:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1.3.6.1.2.1.10.xx.1.10.1.9&nbsp; lmpCcAuthentication&nbsp;=20
[LMP-MIB]:<BR>columnar-object-type<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

1.3.6.1.2.1.10.xx.1.10.1.12&nbsp; lmpCcHelloInterval&nbsp;=20
[LMP-MIB]:<BR>columnar-object-type<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp=
; why=20
is there a gap between 9 and 12??<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; If =
there is no=20
good reason, then pls don't<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; If there is =
a=20
reason, pls explain it in comments in the MIB<BR><BR>[Martin] There is =
no=20
reason. Have removed gap.<BR><BR>&gt; 24. I wonder=20
why<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
lmpVerifyTransportMechanism =3D 1,=20
-- j016OverheadBytes<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpVerifyAllLinks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; =3D=20
verifyAllLinks(1)<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; instead=20
of:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
lmpVerifyTransportMechanism =3D=20
j016OverheadBytes(1)<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
lmpVerifyAllLinks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; =3D=20
verifyAllLinks(1)<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; is that not more=20
consistent?<BR>&gt;<BR>[Martin] Not really. lmpVerifyTransportMechanism =
is=20
actually a bitfield, so<BR>I have shown the integer value that =
corresponds to=20
the least significant bit<BR>(bit 0) only being set. Maybe there is a =
better way=20
to express bitfields.<BR>Any suggestions?<BR><BR>&gt; 25. you have in =
Sect 8.1=20
(and also the sect before that a TBD)<BR>&gt;&nbsp;&nbsp;&nbsp;=20
ifType&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The value that is =
allocated for=20
LMP is=20
TBD.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
This number will be assigned by the=20
IANA.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; So where is that request =
to IANA=20
made to assign an ifType for LMP?<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; You =
better get=20
that added, so they know where to look for =
it.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
ANd if it is in this document, then add an IANA=20
Considerations<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; section. Might be good =
anyway to=20
point out all the TBDs that they<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; need to =
look=20
at. It will just speed up the process at a later =
stage.<BR>&gt;<BR><BR>[Martin]=20
I have requested an ifType for LMP a few months ago. I haven't<BR>heard =
from=20
IANA yet. What should I do?<BR><BR>&gt; admininstrative<BR>&gt; - I'd =
update the=20
dates to 2004 (copyright, REVISION, LAST-UPDATED =
etc)<BR>&gt;<BR><BR>[Martin]=20
Done.<BR><BR>&gt; I did not check all the non-MIB text in detail. FOr =
example I=20
did not<BR>check<BR>&gt; your examples in detail... did I not do so a =
few months=20
back? If not, I<BR>may<BR>&gt; want to still do =
that.<BR>&gt;<BR><BR>[Martin] I=20
am not sure if you have checked the examples in the past. But it<BR>may =
be worth=20
checking them again anyway because the MIB has changed since<BR>the =
initial=20
review.<BR><BR>&gt; Anyway... it is now 7:40pm on Dec 31st for me. So I =
go and=20
have my wine<BR>and<BR>&gt; fun and won't be back till Jan=20
2nd.<BR>&gt;<BR><BR>[Martin] Thanks for your effort reviewing the MIB. I =
will=20
post the new<BR>version shortly.<BR><BR>&gt; Thanks,<BR>&gt; =
Bert<BR>&gt; p.s.=20
Have a great 2004!<BR>&gt;<BR>&gt; &gt; -----Original =
Message-----<BR>&gt; &gt;=20
From: Martin Dubuc [mailto:[e-mail]]<BR>&gt; &gt; =
Sent:=20
woensdag 31 december 2003 14:52<BR>&gt; &gt; To: Wijnen, Bert =
(Bert)<BR>&gt;=20
&gt; Subject: Re: lmp mib status?<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; =

Bert,<BR>&gt; &gt;<BR>&gt; &gt; Here is 08.<BR>&gt; &gt;<BR>&gt; &gt;=20
Martin<BR>&gt; &gt;<BR>&gt; &gt; ----- Original Message -----<BR>&gt; =
&gt; From:=20
"Wijnen, Bert (Bert)" &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>&gt; =
&gt; To:=20
"'Martin Dubuc'" &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</=
A>&gt;;=20
"'Wijnen,<BR>&gt; &gt; Bert (Bert)'"<BR>&gt; &gt; &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>&gt; =
&gt; Sent:=20
Tuesday, December 30, 2003 11:56 AM<BR>&gt; &gt; Subject: RE: lmp mib=20
status?<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; &gt; Martin, did you say =
you have=20
a rev 8 ready to submit?<BR>&gt; &gt; &gt; If so, why do you not send =
that one=20
to me, so I can<BR>&gt; &gt; &gt; check the latest you have?<BR>&gt; =
&gt;=20
&gt;<BR>&gt; &gt; &gt; Thanks,<BR>&gt; &gt; &gt; Bert<BR>&gt; &gt; =
&gt;<BR>&gt;=20
&gt; &gt; &gt; -----Original Message-----<BR>&gt; &gt; &gt; &gt; From: =
Wijnen,=20
Bert (Bert)<BR>&gt; &gt; &gt; &gt; Sent: zondag 14 december 2003 =
23:47<BR>&gt;=20
&gt; &gt; &gt; To: Martin Dubuc; Wijnen, Bert (Bert)<BR>&gt; &gt; &gt; =
&gt;=20
Subject: RE: lmp mib status?<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; Sorry to have to report that my plate keeps =
pretty=20
overloaded.<BR>&gt; &gt; &gt; &gt; It may take another week or =
so.<BR>&gt; &gt;=20
&gt; &gt;<BR>&gt; &gt; &gt; &gt; Thanks,<BR>&gt; &gt; &gt; &gt; =
Bert<BR>&gt;=20
&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; -----Original =
Message-----<BR>&gt;=20
&gt; &gt; &gt; &gt; From: Martin Dubuc=20
[mailto:[e-mail]]<BR>&gt; &gt; &gt; &gt; &gt; Sent: =
zondag 14=20
december 2003 19:52<BR>&gt; &gt; &gt; &gt; &gt; To: Wijnen, Bert =
(Bert)<BR>&gt;=20
&gt; &gt; &gt; &gt; Subject: Re: lmp mib status?<BR>&gt; &gt; &gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; =
Bert,<BR>&gt; &gt;=20
&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; Do you have an idea when you =
will be=20
able to review LMP MIB?<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; =
&gt; &gt;=20
Martin<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; ----- =
Original=20
Message -----<BR>&gt; &gt; &gt; &gt; &gt; From: "Wijnen, Bert (Bert)" =
&lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>&gt; =
&gt; &gt;=20
&gt; &gt; To: &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</=
A>&gt;;=20
&lt;<A =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>&gt; &gt; =

&gt; &gt; &gt; Cc: &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>&gt; =
&gt; &gt;=20
&gt; &gt; Sent: Tuesday, December 02, 2003 8:05 PM<BR>&gt; &gt; &gt; =
&gt; &gt;=20
Subject: RE: lmp mib status?<BR>&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; =
&gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; &gt; &gt; I have to appologize, but there is =
just to=20
much on my agenda<BR>&gt; &gt; &gt; &gt; &gt; &gt; this week to get to =
it. SO=20
either go ahead and post the new ID<BR>&gt; &gt; &gt; &gt; &gt; &gt; or =
wait=20
till next week.<BR>&gt; &gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; =
&gt;=20
&gt; Thanks,<BR>&gt; &gt; &gt; &gt; &gt; &gt; Bert<BR>&gt; &gt; &gt; =
&gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; -----Original =
Message-----<BR>&gt;=20
&gt; &gt; &gt; &gt; &gt; &gt; From: <A=20
href=3D"mailto:[e-mail]">[e-mail]</=
A><BR>&gt;=20
&gt; &gt; &gt; &gt; [mailto:[e-mail]]<BR>&gt; &gt; =
&gt; &gt;=20
&gt; &gt; &gt; Sent: donderdag 27 november 2003 1:50<BR>&gt; &gt; &gt; =
&gt; &gt;=20
&gt; &gt; To: <A =
href=3D"mailto:[e-mail]">[e-mail]</A><BR>&gt;=20
&gt; &gt; &gt; &gt; &gt; &gt; Cc: <A=20
href=3D"mailto:[e-mail]">[e-mail]</A><BR>&gt; &gt; =
&gt; &gt;=20
&gt; &gt; &gt; Subject: Re: lmp mib status?<BR>&gt; &gt; &gt; &gt; &gt; =
&gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; =
&gt; &gt;=20
Tom,<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; =
&gt; &gt;=20
I was just about to submit a new version with minor changes,<BR>&gt; =
&gt; &gt;=20
&gt; &gt; &gt; &gt; but Bert asked that I hold off until he reviews the =
MIB=20
once<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; more. I am waiting for his =
comment to=20
submit an updated<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; version that =
would also=20
address anything he would<BR>&gt; &gt; raise. Bert<BR>&gt; &gt; &gt; =
&gt; &gt;=20
&gt; &gt; mentioned that he did not have time to review until =
after<BR>&gt; &gt;=20
&gt; &gt; &gt; &gt; &gt; IETF. Hopefully he will get back to me soon so =
that we=20
can<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; progress to the next =
level.<BR>&gt;=20
&gt; &gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt;=20
Martin<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; =
&gt;=20
&gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; From: "Thomas D. =
Nadeau"=20
&lt;<A =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>&gt; &gt; =

&gt; &gt; &gt; &gt; &gt; &gt; Date: 2003/11/24 Mon PM 12:04:39 =
EST<BR>&gt; &gt;=20
&gt; &gt; &gt; &gt; &gt; &gt; To: "'Martin Dubuc'" &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</=
A>&gt;<BR>&gt;=20
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Subject: lmp mib status?<BR>&gt; &gt; =
&gt;=20
&gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt;<BR>&gt; &gt;=20
&gt; &gt; &gt; &gt; &gt; &gt; Hi,<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; What is the status of =
the LMP=20
MIB?<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I thought we had a last =
call in=20
CCAMP that<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; is finished. Has =
the MIB=20
been updated now?<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<BR>&gt; =
&gt; &gt;=20
&gt; &gt; &gt; &gt; &gt; --Tom<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; =
&gt; &gt;=20
&gt; &gt;<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; =
&gt; &gt;=20
&gt; 1<BR>&gt; &gt; &gt; &gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; =
&gt;<BR>&gt;=20
&gt; &gt; &gt;<BR>&gt; &gt;<BR></DIV></BODY></HTML>

------=_NextPart_000_00DB_01C40170.FCE44600--




Envelope-to: [e-mail]
Delivery-date: Wed, 03 Mar 2004 16:37:08 +0000
Message-ID: <[e-mail]>
From: Nic Neate <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Movaz Networks - Louis Berger <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: draft-aruns-ccamp-rsvp-restart-ext-00
Date: Wed, 3 Mar 2004 16:33:34 -0000 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I've just read your draft-aruns-ccamp-rsvp-restart-ext-00 and it looks good.
In particular, we've been looking at using Restart for Fast Reroute LSPs for
some time and this draft provides everything that is needed (like recovering
the FAST_REROUTE, DETOUR, SENDER_TEMPLATE and ERO objects from the
downstream node when they are not available from upstream).

However, I have a couple of concerns (not related to Fast Reroute).

 - Your draft doesn't tackle, and won't work for, simultaneous restart of
adjacent nodes.  This is a problem that is tackled by
draft-rahman-ccamp-rsvp-restart-extensions, so merging the two drafts in
some way may be the best way to resolve that.  I realize that the Aruns
draft aims to make Restart possible for nodes which cannot retrieve state
from the data plane, and in that case recovering from simultaneous restart
of adjacent nodes isn't easy.  I think including some further extensions for
nodes which can retrieve some state from the data plane would be
appropriate.

 - The back compatibility with RFC 3473 restart looks risky.  Draft Aruns
mandates that restarted nodes don't send Path Refreshes until either the
recovery period expires or a RecoveryPath is received from downstream.  In
the case that the downstream node only supports RFC 3473 restart (and so
doesn't send RecoveryPaths), it may well timeout Path state at the same time
as or very soon after the recovery period expires.  Hence a dangerous timing
window is created.

As a potential solution to both problems I'd suggest that a restarting node
receiving a Path message with a recovery label should always forward it
immediately as well as it can, and include both a recovery label and (for
back compatibility) a suggested label.  Similarly, it should forward
RecoveryPath messages immediately as well as it can.  I'd be happy to
discuss any of this further.

Thanks,

Nic



Envelope-to: [e-mail]
Delivery-date: Wed, 03 Mar 2004 01:25:19 +0000
Message-ID: <01c501c400be$479156b0$ece325da@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Liaison statement from ITU-T SG 13 to IETF Routing Area (CCAMP) on Information on L1 VPN related work in SG 13
Date: Wed, 3 Mar 2004 01:24:03 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Please be aware of this liaison from ITU-T SG13.

This liaison ties in with the recent draft draft-takeda-l1vpn-framework-00.txt

The liaison statements will appear on the IETF liaison pages. Until then, you can find
them at www.olddog.co.uk/incoming.htm

Cheers,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Tuesday, February 24, 2004 1:02 PM
Subject: Liaison statement from ITU-T SG 13 to IETF Routing Area (CCAMP) on Information on
L1 VPN related work in SG 13


>
> Please find enclosed a liaison statement (COM13-LS23 and its attachments)
> from ITU-T SG 13 meeting (Geneva, 3-12 February 2004) addressed to the IETF
> Routing Area (CCAMP) on Information on L1 VPN related work in SG 13.
>
> Best regards
>
>
> Georges Sebek
> ITU-T SG 13 Secretariat
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2004 18:18:01 +0000
To: [e-mail]
Cc: [e-mail]
Subject: Re: [Re] Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 2 Mar 2004 19:17:09 +0100
Content-Type: text/plain; charset="us-ascii"

Young,

The management associated with the LCAS functionality is just a 
small part of the total management of a VCAT Termination Point. 
I believe that we should not tackle just a small piece of it
(LCAS), but take the whole on our plate.

Some considerations for you (and the other readers):

Let me start with a short intro before tackling the VCAT TP case.
I differentiate between 
- SubNetwork Connections (SNC) ("east-west") and 
- Network Connections (NC) ("north-south").

Subnetwork connections (SNC) in SDH/SONET - these days without 
any real deployment of TCM - are more or less pure bearer plane
connections without any dedicated connection monitoring.

SNCs in OTN in the future will be with ODUk TCM, and will be a 
combination of bearer plance connectivity and (nested) connection
monitoring (service provider (SP), network operators (NO1, NO2, 
NO3)) of which the latter requires configuration (via GMPLS) of the 
Termination Points providing the connection monitoring.

Network connections (NC) in SDH/SONET/OTN will always be a 
combination of bearer plane connectivity and connection 
monitoring (the trail end points) and thus requires configuration
of the Termination POints providing the connection monitoring.

Non-VCAT/LCAS example:
======================
A DS3 call request results as such in a STS-1/VC-3 Network Connection
request plus configuration of the two STS-1/VC-3 termination points
(expected trace ID, error thresholds, payload type, ...).

The STS-1/VC-3 termination points will be part of two STS-1/VC-3 Access 
Groups with say N and M members. The DS3 call translates as such
in a STS-1/VC-3 connection request between AG1 (N members) and AG2 
(M members). 

Like the LRM (link resource manager) there is an Access group Resource
Manager (ARM) for each AG. The connection request will result that 
ARM1 will select one STS-1/VC-3 termination point from AG1
and ARM2 will select one STS-1/VC-3 termination point from AG2 to be
the endpoints of the STS-1/VC-3 network connection. 

Once selected, the ARMs have to exchange termination point information,
including transmitted TTIs (=> becoming expected TTIs at other end), 
payload type, etc.

VCAT/LCAS example:
==================
With this model in mind, we can now have a look at the VCAT cases.
For VCAT we have to distinguish two cases:
1) shared set of K VC-n termination functions flexibily connected
   to L client ports (e.g. Ethernet), each with XMT=M 
   (or M1, M2, .., Ml); K <= M1 + M2 + .. + Ml.
2) dedicated set of M VC-n termination function per client port; 
   with L client ports there are L groups of M VC-n termination
   functions.

Ad 1) In this case the K VC-n termination functions belong to one
      Access Group with K SNPs and L APs, and the ARM will be 
      responsible to select a VC-n termination point (SNP) when a 
      VC-n network connection request is received. The ARM 
      furthermore has to configure the AG such that the selected
      SNP is connected to the appropriate AP. Furthermore, it has
      to configure the VC-n termination point with expected TTI, 
      LCAS: XPT, etc.
      Note - the AP may be fixed and part of the connection request;
      i.e. it may represent a physical interface port to the customer.
      But in case the VCAT port is connected to a bridge fabric
      (case of EVPLAN), then the ARM may initially also have to
      choose the AP (and thus bridge fabric port).

Ad 2) In this case there is an inner set of L Access Groups that each
      have M VC-n termination functions (and SNPs) and one AP. Those
      inner AGs are part of an outer AG that holds now these L
      inner AGs each representing a VCAT port. The ARM for this
      outer AG is responsible to select one of the L inner AGs
      when a new VC-n-Xv network connection is to be setup; e.g.
      when the VCAT port is a bridge fabric port. When the VCAT
      port is connected to e.g. a physical Ethernet interface,
      the AP may well be fixed and part of the connection request.
      In either case, the ARMs have to exchange configuration
      information including transmitted/expected TTI, LCAS: XPT, etc.

When there is a connection to be created between two physical ethernet
interfaces, the physical ports are fixed (cable connections) and the
VCAT information (e.g. value of XMT in port A and port Z) is known.
The min(XMT_A, XMT_Z) becomes a parameter of this connection and
is an upper limit of the bandwidth of the e.g. EPL.

When there is a connection to be created between e.g. two EoSDH
bridge ports (on request of the ETH topology manager), the request
may leave the choice of the AP to the ARMs (case of all ports are
equal). In this case the ARMs have to make such selection and
present this to the bridge to indicate the port that will be used for
this new (topo)link.


Now we can address the extension of an existing VCAT connection.
In this case there is a VCAT conneciton with XMT_A=a, XMT_Z=z and
XPT=p (p < a, p < z). 
[XMT is max number of VC-ns in the VCAT group, XPT is provisioned
number of VC-ns in the VCAT group]
A request to increase bandwidth result in an increase of p; 
e.g. p:=p+1 (add one VC-n).
The call controller will issue a VC-n network connection request 
for the VCAT connection between AP_A and AP_Z. ARM_A and ARM_Z will
be requested by their local connection controllers to provide a
SNP (VC-n term point) associated with AP_A [AP_Z] as endpoints
of the VC-n nework connection to be setup. With the handing over
of the specific SNP, the ARMs should also hand over the associated
configuration information of the termination point (including
transmittedTTI, LCAS: XPT=p+1, etc). This configuration information
is to be exchanged with the far end ARM to have both endpoint 
correctly configured.

Once this additional VC-n netowrk connection is created, the VC-n
termintion functions at both AGs are configured and can verify
if the connection setup is correctly performed; if not, there will
be a dTIM (trace mismatch) condition. This is sufficient for the
case 2 VCAT architecture (dedicated set of VC-n termination points
per port). For the case 1 VCAT architecture (shared set of K VC-n term
points for L ports), the AG may misconfigure the VC-n term point - AP
relationship. In this case the GID will be able to identify the
configuration problem.

So, it is a matter of defining the appropriate AGs and ARMs and to 
have ARMs (ARM_A, ARM_Z) exchange configuration information via GMPLS. 
For VCAT ARMs this includes the VCAT and LCAS configurations.

Regards,
Maarten







[e-mail]
29-02-2004 10:12

 
        To:     Maarten VISSERS/DE/ALCATEL@ALCATEL
        cc:     [e-mail]
        Subject:        [Re] Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt


Hi, 
Thank you for your detailed explanation. 
For your example of the call request for EPL of 10 M that I think is a 
uni-directional case, 
if a GMPLS signaling protocol is used, maybe two LSPs will be established 
with only uni-diretional connections 
because their paths are different each other. The case is not my hope. 
My intention is not to simplify the LCAS operation itself, but to simplify 
the initiation processes invoked by EMS/NMS systems. 
As indicated in G.7042, the operation of LCAS is uni-directional. This 
means that in order to bi-directionally add or remove members the 
procedure has to be repeated in the opposite direction.
If the two uni-directional(downstream and upstream) connections for a call 
request have the same route, 
EMS/NMS systems should invoke two times of the LCAS operations towards 
ingress and egress nodes. 
I want to reduce into only one time using a GMPLS signaling protocol. 
Thanks, 
Young. 





Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2004 16:25:25 +0000
Subject: Re: thoughts on draft-vasseur-ccamp-inter-area-as-te-00.txt
To: [e-mail] (Jean Philippe Vasseur)
Date: Tue, 2 Mar 2004 16:24:44 +0000 (GMT)
Cc: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Dimitri Papadimitriou <[e-mail]>

hi jp,

see in-line:
> 
> Hi Dimitri,
> 
> At 02:45 AM 3/2/2004 +0000, Dimitri Papadimitriou wrote:
> >hi arthi, jp, all,
> >
> >reading draft-vasseur-ccamp-inter-area-as-te-00.txt
> >the following came into my mind, why is there a need
> >to signal the "signaling method": contiguous versus
> >stitching vs nesting ?
> >
> >the reason provided in the document about "control"
> >is unclear, is the sensitivity of the carried traffic
> >dependent of the signaling method ?
> >
> >"For the sake of illustration, a Head-end LSR, may
> >desire to prevent stitching or nesting for a traffic
> >sensitive inter-area/AS TE LSPs that require a path
> >control on the head-end LSR."
> >
> >it seems for me that "signaling the signaling method"
> >introduces here in addition to the protocol issue(s),
> >policy issues:
> >
> >"Ox01: Contiguous LSP [...]
> >
> >When set, this indicates that a boundary LSR MUST
> >not perform any stitching or nesting on the TE LSP
> >and the TE LSP MUST be routed as any other TE LSP
> >(it must be contiguous end to end). [...]
> >
> >A mid-point LSR not supporting contiguous TE LSP
> >MUST send a Path Error message upstream with error
> >sub-code=17 Contiguous LSP type not supported."
> 
> because when crossing multiple ASes this allows the head-end signalling a 
> contiguous LSP to make sure that it will not be stitched in some downstream 
> domain hence keeping some strict control about the reoptimization. This has 
> to be done on a per-LSP basis, since the same head-end may not impose any 
> such requirement for other inter-area/AS LSPs.

not sure i understand that what you want to achieve requires
the method that you are proposing here: in the hypothetical
case of multi-as/area reoptimization, what you say is "i want
to keep head-end control for the re-optimization of a multi-
area/asn LSP"

so here, why don't you use a flag saying "head end control 
of re-optimization" meaning we define a method such that the
head-end decides its willingness to keep control of the re-
optimization occurrence and upon notification could decide 
about when this has to be committed and this *independently* 
of the LSP provisioning method for this LSP 

in the meanwhile this would allow to be more efficient about
the way each ingress boundary LSR decides about the method to 
deliver the incoming request constraints 

so, in brief define a method that would avoid constraining the 
provisioning method from the head-end as/area perspective to 
its downstream as/area for an hypothetical re-optmization that 
is in any case under the control of the local domain, and this
in particular the local as)

ps: unfortunately you're not attending this ietf meeting so 
that we can't discuss this important issue during the ccamp 
face-to-face meeting

thanks,
- dimitri.
> Thanks
> 
> JP.
> 
> >thanks,
> >- dimitri.
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2004 16:01:28 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Brungard, Deborah A, ALABS'" <[e-mail]>
Cc: <[e-mail]>
Subject: Coordination in FNP [was RE: draft-rabbat-fault-notification-protocol-04.txt]
Date: Tue, 2 Mar 2004 07:59:29 -0800
Message-ID: <000401c4006f$598f7440$ea2a10ac@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Deborah,

Thanks for your interest in FNP. My text inline about your comments.

> -----Original Message-----

[parts deleted]

>=20
> The fatal negative with the FNP approach is that the use of the =
protection
> path is not coordinated - no handshake between the two ends (and
> intermediate nodes) for use of the protection path. "All nodes =
notified of
> the failure will activate the recovery path by performing the required
> hardware reconfiguration". And the ingress node starts sending user
> traffic after an elapsed time window. This uncoordinated use of the
> protection path guarantees user traffic will be misconnected -
> unacceptable for an operator.
>=20
[Richard] I want to reemphasize that the FNP method is not a "free for =
all"
kind of notification. Rather it's a very accurate selection of =
notification
paths and times that will ensure propagation of the notification =
information
to the right nodes in the right amount of time.  The key to coordination =
in
FNP is the precise selection of restoration paths for any single or =
multiple
faults.

The extent to which one meets the timing bounds is determined by the
criteria used to pick the restoration paths. For example, if a carrier =
plans
for all single faults, then that carrier will recover from that within =
the
prescribed time bounds. I would refer you to the end of section 6 for =
the
working of the scheme.

> The key requirement in the P&R DT work was that misconnections are not
> allowed, and is why the DT's approach uses coordinated signaling to =
notify
> all nodes along the path. The DT's approach is referred in this draft =
as
> incurring "lengthy delay" vs. FNP.

[Richard] The draft is not referring to the DT's approach, which is not
concerned with the problem of time-bounded notification.

You can go to version -00 of the draft dating back to June 2002 and read =
our
comparison of two solutions for time-bounded notification: a theoretical
signaling-based solution vs. FNP.  Therefore, the signaling approach
referred to in this draft is a theoretical solution for the problem we
describe and is therefore not the DT's approach.

In our I-D, "lengthy delay" in section 1, para 4, refers to path-based =
vs.
link-based restoration, sorry for the confusion. It's a general =
observation
about different protection techniques.=20

> Another draft for your attention is =
draft-rabbat-optical-recovery-reqs.
> Requirement 8 states "A recovery scheme SHOULD make sure that recovery
> actions correctly move traffic from failed paths to their respective
> recovery paths, such that the recovery actions do not result in =
long-term
> misconnections". This requirement needs to be reworded to "SHALL" and
> "long-term misconnections" to "any misconnections".
>=20
[Richard] Misconnections are a fact of life in any carrier network.  =
Every
carrier requires the ability to detect and remediate for misconnections.
Misconnections can happen for a variety of reasons. For example, the
following issues unrelated to P&R in general may lead to misconnections

1- Bugs in the control plane which result in the control plane not
initiating the right cross-connect in the data plane: this could occur =
at
path setup phase as well as during restoration, no matter what technique =
one
uses for notification and coordination.
2- Bugs in the data plane such as a corrupted cross-connect table, =
notably
in the case of swapped entries
3- Incorrect or failed operation of the squelching function

That is why the requirement mentions long-term misconnections. We've =
been
trying to find the appropriate wording. Would you agree with replacing
"long-term" with "persistent" misconnections?

As far as FNP is concerned, the only time at which misconnections are =
even
likely is when you have at least two faults which are very close =
together in
time, for example less than 100-200 ms apart. Even in that case, one can
only get misconnections if the backup paths of the faults share the same
resources, for example a common link, *and* the following situation =
occurs:
a node that receives the 1st notification message initiates a
cross-connection, then gets a new message that asks it to cross-connect
otherwise, but doesn't have enough time to squelch the traffic.  If that
happens, the trace function, which is available to detect all kinds of =
other
misconnections, will also be used here and traffic will not be delivered =
to
its unintended recipients.=20

If you have thought of other scenarios, perhaps we can discuss them with =
a
specific example/figure.

> Deborah
>=20
Thanks,
Richard

[parts deleted]




Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2004 14:24:39 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'George Newsome'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
Date: Tue, 2 Mar 2004 06:21:50 -0800
Message-ID: <000301c40061$b50a8610$ea2a10ac@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi George,

My explanations below and in a second email.  I will address your =
question
about path computation solutions in a separate email.

First, it's good that we've resolved questions 1 and 4. Progress is =
being
made. Let's discuss the remaining points.

> Hi Richard,
>=20
> Thanks for your reply - a couple of points inline (with some=20
> snipping...)
>=20
>=20
> Richard Rabbat wrote:
>=20
> > Hi George,
> >
> > You've probably had time to review Vishal's explanations by now.
> Comments to
> > the items you raised inline.
> >
> >
> >>-----Original Message-----
> >>..........
>=20
> >
> >>2) This draft seems to address the relatively simple problem of=20
> >>setting up the restoration path. It seems to completely ignore the=20
> >>much harder problem of allocating resources to the shared=20
> >>restoration path, and of actually locating the fault in an optical=20
> >>network to a single span in a time that is useful to restoration.


> > [Richard] If I understand the comment correctly, you are referring=20
> > to the problem of path computation, which is a solved problem with=20
> > many proposals in the literature. It is also orthogonal to the=20
> > notification problem.
> >
> [George] Pre computation of shared restoration paths is a distributed=20
> computaion problem. Its hard to see this being done without a new=20
> protocol or significant modifications to existing protocols. I am not=20
> aware of a plethora of solutions to this particular problem.

[Richard] This will be addressed in the 2nd email.

> > The fault localization problem is also different from the objective=20
> > of
> this
> > draft. Localization of the fault has to occur and the fault=20
> > information transmitted to a notification mechanism. The=20
> > localization problem itself takes a certain amount of time as you=20
> > mentioned.  Feedback from our
> hardware
> > experts says that it's doable in the range of a few milliseconds.

> [George] I think you are confusing detecting a fault with locating the =

> fault. The first is fast and easy, while the second is somewhat more=20
> interesting. To be most efficient with restoration resources, you=20
> really need to know where a fault is to a single link. Wether this can =

> be done quickly is very technology dependent.

[Richard] True. The applicability statement of FNP discusses the
technologies we are focusing on initially.  For this particular topic, =
our
interest lies in O-E-O switches where detection then localization of the
fault happen on a span basis. Section 4.2 of
draft-rabbat-fnp-applicability-00.txt is reproduced here for your =
reference:
--
   FNP is designed to work in networks with OEO nodes. Its applicability =
to

   networks with OOO nodes (that is, fully transparent all-optical =
networks)

   depends on the monitoring capabilities of the OOO systems deployed, =
and=20
   is for further study.

   For a network with OEO nodes, the fault detection and correlation =
(which=20
   happens before FNP is activated, and is outside the scope of this=20
   document) occurs at the node closest to the fault. Once the detection =

   procedure has determined that a bonafide fault has occurred, it =
activates

   FNP for fault notification
--

> >>It makes no mention of the
> >>inaccuracies in network planning databases, which make one wonder=20
> >>whether precomputation of restoration paths will actually lead to=20
> >>faster restoration times.
> >
> >
> > [Richard] Restoration path computation relies on some amount of=20
> > accuracy no
> > matter when it is done, whether before or after the fault. Since one =

> > is using the same database in both cases, precomputation will lead=20
> > to
> faster
> > restoration time.
> >
> [George] Actually the database used for precomputation of restoration=20
> is the planning database, which knows about diversity, and is=20
> frequently incorrect (at least according to the operators I spoke with =

> quite a while ago while I was a strong proponent of pre computed=20
> restoration). It is not the routing database, which has accurate=20
> topology but no knowledge of diversity.

[Richard] Thanks for clarifying your comment. We understand that this is =
a
problem across any kind of restoration mechanism.  An elegant way of =
getting
the data into the routing database is through the use of SRLG.  The =
issue of
SRLG assignment is interesting but a separate discussion.

> >>Finally, it seems to presuppose that a network
> >>operator would make such a facilities database available to route=20
> >>computation at all. The suggestion in sect 6.2 that the physical=20
> >>length of the fibers be available for route computation is very=20
> >>unlikely in any network I have ever worked on.

> > [Richard] In the past, with no need for such information it may have
> been
> > irrelevant to provide it. For time-bounded shared-mesh recovery,=20
> > this information will be needed. It will afford the operator the
> sophistication
> > and bandwidth savings that shared-mesh provides.
> >
> [George] Restoration has been implemented in several technology=20
> generations without the need for this degree of detail. Operators tend =

> to know how they run the network and are very reticent to make this=20
> sort of change. I think you are being overly optimistic.
>=20
[Richard] Shared mesh restoration has not been deployed in the past, =
agreed.
Some carriers though from our discussions have expressed renewed =
interest in
shared mesh. I'm not sure that would be considered overly optimistic, =
just
discussions with customers.

> >>3) .................
> >
> >
> >>An
> >>additional assumption seems to be that there is only one fault in=20
> >>the network, and all bets are off if that is not true. There seem to =

> >>be problems with both these assumptions. It seems to me that there=20
> >>are no mechanisms for truncating the PDU that is being sent, so=20
> >>there is a finite chance that a significant extra delay is incurred. =

> >>Perhaps more serious is the assumption that all bets are off if=20
> >>there are multiple faults in the network. In general, multiple=20
> >>faults are those that lead to service outage. Two faults that do not =

> >>interact, in that they do not contend for the same network=20
> >>resources, will be coupled by the flooding.
> >
> >
> > [Richard] Multiple faults that do not interact could be coupled if=20
> > they occur in a time interval which is smaller than the delay of the =

> > flooding message across the network diameter. Even in a large=20
> > network, this
> implies
> > faults must occur closer than a few 100 ms apart.
> >
> > In any case, please note that all bets are not off when it comes to=20
> > FNP conducting the notification.  FNP will achieve the notification
> > irrespective of the number of faults.  In the case of multiple =
faults,=20
> > the timing bound may not be guaranteed, if the common case one =
designs=20
> > for by using FNP is for a single fault. There is no restriction in =
the=20
> > protocol itself not to work with the assumption of multiple faults.  =

> > Moreover, multiple faults may occur in less than 1% of the fault =
cases
> > according to a major US carrier we talked to.
> > SONET and other transport technologies only guarantee hard timing=20
> > bounds in the case of single failures. Our approach affords us a =
better=20
> > recovery procedure with proper planning.
> >
> >
> >>In addition, unsupressed restoration requests, which occur  when the =

> >>fault cannot be rapidly located to a single span, will also generate =

> >>restoration messages.
> >
> >
> > [Richard] Please refer to earlier answer about localization
> >
> [George] The all bets are off refered to the statement that=20
> restoration times are no longer ensured when there are multiple=20
> faults. This actually oocurs when a large fiber cable is cut and every =

> system on that cable issues alarms. As the cable usually supports in=20
> dependent line systems, correlation across these systems is rarely, if =

> ever, done. The result is a storm of restoration requests. If your=20
> reference operator suggested otherwise, I suspect that a different=20
> question was being inadvertently answered.

[Richard] I took your wording "faults that do not interact" as =
independent
faults.  The carrier response referred to independent fiber cuts.=20
But your example describes correlated faults. In the case of multiple =
faults
such as the one you describe, a correlated fault, we don't ensure the
restoration time unless we've computed restoration paths with those =
faults
in mind.

Compare this for a moment with a theoretical signaling-based solution =
for
time-bounded fault notification.  That solution will initiate recovery =
per
failed LSP.  In your example of a cable full of fibers, carrying =
multiple
wavelengths each, each wavelength in turn carrying a plethora of TDM
channels, one can quickly identify the scalability advantages of FNP =
over a
signaling-based approach.=20
On another note, if you're interested in methods and techniques for =
merging
FNP notification messages, we could discuss that.=20

> >>5) Until the effect of network database inaccuracies on the=20
> >>effectiveness of  precomputed restoration is better understood, the=20
> >>problem of allocating  resources in shared mesh networks is solved,=20
> >>and it is certain that all faults will be located to the correct=20
> >>span in a time useful to restoration, it seems to be premature to be =

> >>proposing a solution to the final piece of the problem.
> >>
> >
> > [Richard] I believe we've answered each individual point in that
> sentence in
> > the previous paragraphs. Given that, none are a stumbling block to=20
> > the solution.
> >
> [George] I suppose it depends on what you consider a stumbling block!
>=20
[Richard] The localization problem and the database inaccuracy problem =
are
common across all restoration methods and schemes and in my mind, that =
is
not reason enough to hold back work on these methods. The path =
computation
problem is addressed in the companion email. I hope this email clarifies =
the
remaining questions that you raised.

> Thanks for your thoughts - I also look forward to your reply to =
Deborah.
>=20
[Richard] Deborah's email is a different thread that discusses other =
issues
and I will address those in a subsequent email once I get a bit of time.

> Regards
>=20
> 	George
>=20

Best,
Richard.




Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2004 03:22:36 +0000
Message-Id: <[e-mail]>
Date: Mon, 01 Mar 2004 22:21:38 -0500
To: Dimitri Papadimitriou <[e-mail]>
From: Jean Philippe Vasseur <[e-mail]>
Subject: Re: thoughts on draft-vasseur-ccamp-inter-area-as-te-00.txt
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Dimitri,

At 02:45 AM 3/2/2004 +0000, Dimitri Papadimitriou wrote:
>hi arthi, jp, all,
>
>reading draft-vasseur-ccamp-inter-area-as-te-00.txt
>the following came into my mind, why is there a need
>to signal the "signaling method": contiguous versus
>stitching vs nesting ?
>
>the reason provided in the document about "control"
>is unclear, is the sensitivity of the carried traffic
>dependent of the signaling method ?
>
>"For the sake of illustration, a Head-end LSR, may
>desire to prevent stitching or nesting for a traffic
>sensitive inter-area/AS TE LSPs that require a path
>control on the head-end LSR."
>
>it seems for me that "signaling the signaling method"
>introduces here in addition to the protocol issue(s),
>policy issues:
>
>"Ox01: Contiguous LSP [...]
>
>When set, this indicates that a boundary LSR MUST
>not perform any stitching or nesting on the TE LSP
>and the TE LSP MUST be routed as any other TE LSP
>(it must be contiguous end to end). [...]
>
>A mid-point LSR not supporting contiguous TE LSP
>MUST send a Path Error message upstream with error
>sub-code=17 Contiguous LSP type not supported."

because when crossing multiple ASes this allows the head-end signalling a 
contiguous LSP to make sure that it will not be stitched in some downstream 
domain hence keeping some strict control about the reoptimization. This has 
to be done on a per-LSP basis, since the same head-end may not impose any 
such requirement for other inter-area/AS LSPs.

Thanks

JP.

>thanks,
>- dimitri.




Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2004 02:46:05 +0000
Subject: thoughts on draft-vasseur-ccamp-inter-area-as-te-00.txt
To: [e-mail], [e-mail], [e-mail]
Date: Tue, 2 Mar 2004 02:45:34 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Dimitri Papadimitriou <[e-mail]>

hi arthi, jp, all,

reading draft-vasseur-ccamp-inter-area-as-te-00.txt
the following came into my mind, why is there a need
to signal the "signaling method": contiguous versus
stitching vs nesting ? 

the reason provided in the document about "control" 
is unclear, is the sensitivity of the carried traffic
dependent of the signaling method ? 

"For the sake of illustration, a Head-end LSR, may 
desire to prevent stitching or nesting for a traffic 
sensitive inter-area/AS TE LSPs that require a path 
control on the head-end LSR."  

it seems for me that "signaling the signaling method" 
introduces here in addition to the protocol issue(s),  
policy issues:

"Ox01: Contiguous LSP [...]

When set, this indicates that a boundary LSR MUST 
not perform any stitching or nesting on the TE LSP 
and the TE LSP MUST be routed as any other TE LSP 
(it must be contiguous end to end). [...]

A mid-point LSR not supporting contiguous TE LSP 
MUST send a Path Error message upstream with error 
sub-code=17 Contiguous LSP type not supported."

thanks,
- dimitri.



Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2004 02:12:44 +0000
Message-ID: <00f901c3fffb$a4723c50$f71e10ac@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Slides for CCAMP
Date: Tue, 2 Mar 2004 02:11:08 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks to those who have already sent these.

Others, please don't forget to send them to me by the end of today (Tuesday).

Thanks,
Adrian



Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2004 02:12:36 +0000
Message-ID: <[e-mail]>
Date: Mon, 01 Mar 2004 21:11:53 -0500
From: George Newsome <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Richard Rabbat <[e-mail]>
CC: [e-mail],  [e-mail],  Deborah Brungard <[e-mail]>
Subject: Re: draft-rabbat-fault-notification-protocol-04.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Richard,

Thanks for your reply - a couple of points inline (with some snipping...)


Richard Rabbat wrote:

> Hi George,
> 
> You've probably had time to review Vishal's explanations by now. Comments to
> the items you raised inline. 
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>Of George Newsome
>>Sent: Tuesday, February 24, 2004 5:41 PM
>>To: [e-mail]
>>Subject: Re: draft-rabbat-fault-notification-protocol-04.txt
>>..........

> 
>>2) This draft seems to address the relatively simple problem of setting
>>up the restoration path. It seems to completely ignore the much harder
>>problem of allocating resources to the shared restoration path, and of
>>actually locating the fault in an optical network to a single span in a
>>time that is useful to restoration. 
> 
> 
> [Richard] If I understand the comment correctly, you are referring to the
> problem of path computation, which is a solved problem with many proposals
> in the literature. It is also orthogonal to the notification problem.
> 
[George] Pre computation of shared restoration paths is a distributed 
computaion problem. Its hard to see this being done without a new 
protocol or significant modifications to existing protocols. I am not 
aware of a plethora of solutions to this particular problem.

> The fault localization problem is also different from the objective of this
> draft. Localization of the fault has to occur and the fault information
> transmitted to a notification mechanism. The localization problem itself
> takes a certain amount of time as you mentioned.  Feedback from our hardware
> experts says that it's doable in the range of a few milliseconds.
> 
[George] I think you are confusing detecting a fault with locating the 
fault. The first is fast and easy, while the second is somewhat more 
interesting. To be most efficient with restoration resources, you really 
need to know where a fault is to a single link. Wether this can be done 
quickly is very technology dependent.

> 
>>It makes no mention of the
>>inaccuracies in network planning databases, which make one wonder
>>whether precomputation of restoration paths will actually lead to faster
>>restoration times. 
> 
> 
> [Richard] Restoration path computation relies on some amount of accuracy no
> matter when it is done, whether before or after the fault. Since one is
> using the same database in both cases, precomputation will lead to faster
> restoration time.
> 
[George] Actually the database used for precomputation of restoration is 
the planning database, which knows about diversity, and is frequently 
incorrect (at least according to the operators I spoke with quite a 
while ago while I was a strong proponent of pre computed restoration). 
It is not the routing database, which has accurate topology but no 
knowledge of diversity.

> 
>>Finally, it seems to presuppose that a network
>>operator would make such a facilities database available to route
>>computation at all. The suggestion in sect 6.2 that the physical length
>>of the fibers be available for route computation is very unlikely in any
>>network I have ever worked on.
> 
> 
> [Richard] In the past, with no need for such information it may have been
> irrelevant to provide it. For time-bounded shared-mesh recovery, this
> information will be needed. It will afford the operator the sophistication
> and bandwidth savings that shared-mesh provides.
> 
[George] Restoration has been implemented in several technology 
generations without the need for this degree of detail. Operators tend 
to know how they run the network and are very reticent to make this sort 
of change. I think you are being overly optimistic.

> 
>>3) .................
> 
> 
>>An
>>additional assumption seems to be that there is only one fault in the
>>network, and all bets are off if that is not true. There seem to be
>>problems with both these assumptions. It seems to me that there are no
>>mechanisms for truncating the PDU that is being sent, so there is a
>>finite chance that a significant extra delay is incurred. Perhaps more
>>serious is the assumption that all bets are off if there are multiple
>>faults in the network. In general, multiple faults are those that lead
>>to service outage. Two faults that do not interact, in that they do not
>>contend for the same network resources, will be coupled by the flooding.
> 
> 
> [Richard] Multiple faults that do not interact could be coupled if they
> occur in a time interval which is smaller than the delay of the flooding
> message across the network diameter. Even in a large network, this implies
> faults must occur closer than a few 100 ms apart. 
> 
> In any case, please note that all bets are not off when it comes to FNP
> conducting the notification.  FNP will achieve the notification irrespective
> of the number of faults.  In the case of multiple faults, the timing bound
> may not be guaranteed, if the common case one designs for by using FNP is
> for a single fault. There is no restriction in the protocol itself not to
> work with the assumption of multiple faults.  Moreover, multiple faults may
> occur in less than 1% of the fault cases according to a major US carrier we
> talked to.
> SONET and other transport technologies only guarantee hard timing bounds in
> the case of single failures. Our approach affords us a better recovery
> procedure with proper planning.
> 
> 
>>In addition, unsupressed restoration requests, which occur  when the
>>fault cannot be rapidly located to a single span, will also generate
>>restoration messages. 
> 
> 
> [Richard] Please refer to earlier answer about localization
> 
[George] The all bets are off refered to the statement that restoration 
times are no longer ensured when there are multiple faults. This 
actually oocurs when a large fiber cable is cut and every system on that 
cable issues alarms. As the cable usually supports in dependent line 
systems, correlation across these systems is rarely, if ever, done. The 
result is a storm of restoration requests. If your reference operator 
suggested otherwise, I suspect that a different question was being 
inadvertently answered.

> 
> 
>>5) Until the effect of network database inaccuracies on the
>>effectiveness of  precomputed restoration is better understood, the
>>problem of allocating  resources in shared mesh networks is solved, and
>>it is certain that all faults will be located to the correct span in a
>>time useful to restoration, it seems to be premature to be proposing a
>>solution to the final piece of the problem.
>>
> 
> [Richard] I believe we've answered each individual point in that sentence in
> the previous paragraphs. Given that, none are a stumbling block to the
> solution.
>
[George] I suppose it depends on what you consider a stumbling block!

Thanks for your thoughts - I also look forward to your reply to Deborah.

Regards

	George





Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2004 15:31:35 +0000
Message-ID: <[e-mail]>
Date: Mon, 01 Mar 2004 10:30:15 -0500
From: Reshad Rahman <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
MIME-Version: 1.0
To: [e-mail], Adrian Farrel <[e-mail]>
CC: "'Anca Zamfir'" <[e-mail]>, [e-mail], Lou Berger <[e-mail]>, [e-mail], [e-mail]
Subject: Re: RSVP Graceful Restart Extensions
Content-Type: multipart/alternative; boundary="------------000002090400060601090306"

--------------000002090400060601090306
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

The problems which the 2 drafts address are very similar, but 
draft-aruns addresses a wider issue (full state recovery instead of just 
ERO). The solutions proposed are also very similar: draft-rrahman, which 
was initially presented in the MPLS WG at IETF58, has a new recovery ERO 
object whereas draft-aruns has a new recovery Path msg.

We are interested in merging the drafts.

In our opinion, draft-aruns has the following potential issues which 
should be addressed:
- Downstream neighbour of restarting node sends RecoveryPath for *each* 
LSP associated with the restarting node for which it has sent a Resv 
message. With lots of LSPs this could be wasteful since the restarting 
node may need the RecoveryPath for only a small subset of LSPs. One way 
to avoid this is e.g. to define a new hop-by-hop "recovery" object (or 
flag) in the Path msg where each node indicates to its downstream nbor 
whether it would want the RecoveryPath message for that LSP if it restarts.
- There is no mention of "pacing" RecoveryPath messages. For large 
number of LSPs this could be an issue. There should be a mechanism 
similar to section 9.5.3. of RFC3473.

Regards,
Reshad.

Arun Satyanarayana wrote:

>Adrian,
>
>The following is the problem space as we see it (this includes GMPLS):
>
>  - Recovery of *full* signaling state on ingress nodes after a restart.
>
>  - Recovery of *full* signaling state transit nodes after a restart. (Egress
>    is already covered by existing mechanisms.)
>
>  - Full signaling state includes: dynamically computed objects such as
>    ERO/RRO; HOP when forwarding state is not saved across a restart; and any
>    other objects including transparently processed objects.
>
>  - Perform all such recovery without perturbing the signaling state on any of
>    the other nodes participating in the LSP.
>
>  - Maintaining backwards compatibility:
>    - Notably with existing hello mechanisms as defined in rfc3209 and
>      rfc3473.
>
>
>The following parts of the problem space are being addressed in
>draft-aruns-ccamp-rsvp-restart-ext-00.txt:
>
>  - Address single node restarts under all conditions including when the
>    restarting node is the ingress, and, when the ingress does not save full
>    or partial forwarding state across the restart. Note that this does not
>    require any signaling state beyond interface configuration to be restored
>    after a restart. Also covered is the case where the restarting node
>    dynamically adds/computes/changes any objects in the received Path
>    message.
>
>  - Achieve recovery without perturbing the signaling state on the remaining
>    participating nodes of the LSP.
>
>  - Fully backwards compatible with existing implementations.
>
>
>We see the following limitations with the alternate solution in
>draft-rahman-rsvp-restart-extensions-00.txt:
>
>  - Ingress node restarts are not addressed (or, require some signaling state
>    saved across the restart).
>
>  - There could be backward compatibility issues with the change to the Hello
>    message contents (Restart Caps object contents, specifically).
>
>  - The change to Hellos, is to address adjaceny node restarts, which is in
>    itself limited to two adjacent nodes. Beyond this, the solution is the
>    same as in rfc3473. The following example explains the situation (as
>    applicable to draft-rahman-rsvp-restart-extensions-00.txt):
>
>           R1-------R2-------R3-------R4
>
>    An LSP spans across R1-R2-R3-R4. If R2, R3 and R4 restart simultaneously,
>    without locally saved signaling state on at least R3 (i.e., R3 is able to
>    recover mandatory signaling state on its own) the following happens: R1
>    sends a Path with Recovery Label to R2. R2 may at best recover the
>    outgoing interface information from the forwarding state. R2 then sends a
>    Path with a minimal Recovery ERO (eg: incoming interface on R2, R4 as
>    loose). R3 does the same. Effectively, this is the same behaviour as
>    defined in RFC3473 (with clarification regarding contents of the
>    transmitted [Recovery] ERO).
>
>    (Please see section 9.5.2, paragraph 4 "When a node receives a Path
>    message during the Recovery Period, ..." which covers the adjacent node
>    restart case, when a Path message could be received by the downstream
>    restarting node without a Recovery Label).
>
>Thanks,
>_arun_
>============================================================
>On Sat, 21 Feb 2004, Adrian Farrel wrote:
>
>  
>
>>Date: Sat, 21 Feb 2004 22:13:31 -0000
>>From: Adrian Farrel <[e-mail]>
>>To: [e-mail], 'Anca Zamfir' <[e-mail]>, [e-mail],
>>     [e-mail], Lou Berger <[e-mail]>,
>>     [e-mail]
>>Cc: [e-mail]
>>Subject: RSVP Graceful Restart Extensions
>>
>>Hi all,
>>
>>draft-rahman-ccamp-rsvp-restart-extensions-00.txt and
>>draft-aruns-ccamp-rsvp-restart-ext-00.txt appear to me to address a similar problem space.
>>
>>I would appreciate your views on how the problem (rather than the solution differs).
>>
>>If the overlap between the problems is significant, can you tell me whether is likelihood
>>of persuading you to merge the drafts or whether the solutions are so radically different
>>that the WG must select one solution or the other.
>>
>>Thanks,
>>Adrian
>>    
>>
>
>  
>


--------------000002090400060601090306
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Hi all,<br>
<br>
The problems which the 2 drafts address are very similar, but draft-aruns
addresses a wider issue (full state recovery instead of just ERO). The solutions
proposed are also very similar: draft-rrahman, which was initially presented
in the MPLS WG at IETF58, has a new recovery ERO object whereas draft-aruns
has a new recovery Path msg.<br>
<br>
We are interested in merging the drafts.<br>
<br>
In our opinion, draft-aruns has the following potential issues which should
be addressed:<br>
 - Downstream neighbour of restarting node sends RecoveryPath for *each* LSP
associated with the restarting node for which it has sent a Resv message.
With lots of LSPs this could be wasteful since the restarting node may need
the RecoveryPath for only a small subset of LSPs. One way to avoid this is
e.g. to define a new hop-by-hop "recovery" object (or flag) in the Path msg
where each node indicates to its downstream nbor whether it would want the
RecoveryPath message for that LSP if it restarts.<br>
 - There is no mention of "pacing" RecoveryPath messages. For large number
of LSPs this could be an issue. There should be a mechanism similar to section
9.5.3. of RFC3473.<br>
<br>
Regards,<br>
Reshad.<br>
<br>
Arun Satyanarayana wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">Adrian,

The following is the problem space as we see it (this includes GMPLS):

  - Recovery of *full* signaling state on ingress nodes after a restart.

  - Recovery of *full* signaling state transit nodes after a restart. (Egress
    is already covered by existing mechanisms.)

  - Full signaling state includes: dynamically computed objects such as
    ERO/RRO; HOP when forwarding state is not saved across a restart; and any
    other objects including transparently processed objects.

  - Perform all such recovery without perturbing the signaling state on any of
    the other nodes participating in the LSP.

  - Maintaining backwards compatibility:
    - Notably with existing hello mechanisms as defined in rfc3209 and
      rfc3473.


The following parts of the problem space are being addressed in
draft-aruns-ccamp-rsvp-restart-ext-00.txt:

  - Address single node restarts under all conditions including when the
    restarting node is the ingress, and, when the ingress does not save full
    or partial forwarding state across the restart. Note that this does not
    require any signaling state beyond interface configuration to be restored
    after a restart. Also covered is the case where the restarting node
    dynamically adds/computes/changes any objects in the received Path
    message.

  - Achieve recovery without perturbing the signaling state on the remaining
    participating nodes of the LSP.

  - Fully backwards compatible with existing implementations.


We see the following limitations with the alternate solution in
draft-rahman-rsvp-restart-extensions-00.txt:

  - Ingress node restarts are not addressed (or, require some signaling state
    saved across the restart).

  - There could be backward compatibility issues with the change to the Hello
    message contents (Restart Caps object contents, specifically).

  - The change to Hellos, is to address adjaceny node restarts, which is in
    itself limited to two adjacent nodes. Beyond this, the solution is the
    same as in rfc3473. The following example explains the situation (as
    applicable to draft-rahman-rsvp-restart-extensions-00.txt):

           R1-------R2-------R3-------R4

    An LSP spans across R1-R2-R3-R4. If R2, R3 and R4 restart simultaneously,
    without locally saved signaling state on at least R3 (i.e., R3 is able to
    recover mandatory signaling state on its own) the following happens: R1
    sends a Path with Recovery Label to R2. R2 may at best recover the
    outgoing interface information from the forwarding state. R2 then sends a
    Path with a minimal Recovery ERO (eg: incoming interface on R2, R4 as
    loose). R3 does the same. Effectively, this is the same behaviour as
    defined in RFC3473 (with clarification regarding contents of the
    transmitted [Recovery] ERO).

    (Please see section 9.5.2, paragraph 4 "When a node receives a Path
    message during the Recovery Period, ..." which covers the adjacent node
    restart case, when a Path message could be received by the downstream
    restarting node without a Recovery Label).

Thanks,
_arun_
============================================================
On Sat, 21 Feb 2004, Adrian Farrel wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Date: Sat, 21 Feb 2004 22:13:31 -0000
From: Adrian Farrel <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
To: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>, 'Anca Zamfir' <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>, <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>,
     <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>, Lou Berger <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>,
     <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Subject: RSVP Graceful Restart Extensions

Hi all,

draft-rahman-ccamp-rsvp-restart-extensions-00.txt and
draft-aruns-ccamp-rsvp-restart-ext-00.txt appear to me to address a similar problem space.

I would appreciate your views on how the problem (rather than the solution differs).

If the overlap between the problems is significant, can you tell me whether is likelihood
of persuading you to merge the drafts or whether the solutions are so radically different
that the WG must select one solution or the other.

Thanks,
Adrian
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
</body>
</html>

--------------000002090400060601090306--




Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2004 11:06:34 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'George Newsome'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
Date: Mon, 1 Mar 2004 03:01:27 -0800
Message-ID: <000001c3ff7c$8d222a80$ea2a10ac@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi George,

You've probably had time to review Vishal's explanations by now. =
Comments to
the items you raised inline.=20

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On =
Behalf
> Of George Newsome
> Sent: Tuesday, February 24, 2004 5:41 PM
> To: [e-mail]
> Subject: Re: draft-rabbat-fault-notification-protocol-04.txt
>=20
> All,
>=20
> My attention was drawn to
> draft-rabbat-fault-notification-protocol-04.txt, which provokes the
> following comments.
>=20
> 1) There seems to be some notion that the time taken to restore is a
> crucial element of high availability, yet overall availability is
> controlled by unprotected elements failure rate and by mean time to
> repair, rather than by switching time. (A 1 second switch is less
> 1/10000 of the generally accepted MTTR of 4 hrs)
>=20
[Richard] High availability refers in the draft to the service =
availability.
In that respect, restoration is critical to ensure service recovery.

> 2) This draft seems to address the relatively simple problem of =
setting
> up the restoration path. It seems to completely ignore the much harder
> problem of allocating resources to the shared restoration path, and of
> actually locating the fault in an optical network to a single span in =
a
> time that is useful to restoration.=20

[Richard] If I understand the comment correctly, you are referring to =
the
problem of path computation, which is a solved problem with many =
proposals
in the literature. It is also orthogonal to the notification problem.

The fault localization problem is also different from the objective of =
this
draft. Localization of the fault has to occur and the fault information
transmitted to a notification mechanism. The localization problem itself
takes a certain amount of time as you mentioned.  Feedback from our =
hardware
experts says that it's doable in the range of a few milliseconds.

>It makes no mention of the
> inaccuracies in network planning databases, which make one wonder
> whether precomputation of restoration paths will actually lead to =
faster
> restoration times.=20

[Richard] Restoration path computation relies on some amount of accuracy =
no
matter when it is done, whether before or after the fault. Since one is
using the same database in both cases, precomputation will lead to =
faster
restoration time.

> Finally, it seems to presuppose that a network
> operator would make such a facilities database available to route
> computation at all. The suggestion in sect 6.2 that the physical =
length
> of the fibers be available for route computation is very unlikely in =
any
> network I have ever worked on.

[Richard] In the past, with no need for such information it may have =
been
irrelevant to provide it. For time-bounded shared-mesh recovery, this
information will be needed. It will afford the operator the =
sophistication
and bandwidth savings that shared-mesh provides.

>=20
> 3) One must wonder whether a flooding approach is actually best =
anyway.
> The assumption seems to be that a flooding protocol PDU can be forced
> onto the front of the send queue, thereby incurring minimum delay.=20

[Richard] We know from implementations of our and competing boxes that =
this
can be done. It is not central to the proposal but speeds up the
restoration. Please refer to Appendix A.2 for a computation of the =
queuing
delays.

> An
> additional assumption seems to be that there is only one fault in the
> network, and all bets are off if that is not true. There seem to be
> problems with both these assumptions. It seems to me that there are no
> mechanisms for truncating the PDU that is being sent, so there is a
> finite chance that a significant extra delay is incurred. Perhaps more
> serious is the assumption that all bets are off if there are multiple
> faults in the network. In general, multiple faults are those that lead
> to service outage. Two faults that do not interact, in that they do =
not
> contend for the same network resources, will be coupled by the =
flooding.

[Richard] Multiple faults that do not interact could be coupled if they
occur in a time interval which is smaller than the delay of the flooding
message across the network diameter. Even in a large network, this =
implies
faults must occur closer than a few 100 ms apart.=20

In any case, please note that all bets are not off when it comes to FNP
conducting the notification.  FNP will achieve the notification =
irrespective
of the number of faults.  In the case of multiple faults, the timing =
bound
may not be guaranteed, if the common case one designs for by using FNP =
is
for a single fault. There is no restriction in the protocol itself not =
to
work with the assumption of multiple faults.  Moreover, multiple faults =
may
occur in less than 1% of the fault cases according to a major US carrier =
we
talked to.
SONET and other transport technologies only guarantee hard timing bounds =
in
the case of single failures. Our approach affords us a better recovery
procedure with proper planning.

> In addition, unsupressed restoration requests, which occur  when the
> fault cannot be rapidly located to a single span, will also generate
> restoration messages.=20

[Richard] Please refer to earlier answer about localization

> It also seems to me that routing changes may well
> start to be flooded at the same time scale as restoration activity is
> taking place. There is no mention of possible interactions with this.

[Richard] This is because the draft is implementation-agnostic. Not =
having
chosen the mode of flooding, we do not discuss interactions between =
routing
and this flooding mechanism. If routing is used for flooding, the
interaction is a non-issue.

> 4) Assuming that this problem is worth solving, and that a flooding
> protocol is the best solution, is it a good idea to generate  yet
> another protocol that floods, and is LMP the vehicle of choice to =
embed
> yet another protocol? It seems to me that restoration has a strong
> interaction with routing change announcment, so it seems to me to make
> more sense to use those mechanisms rather than invent new ones.

[Richard] LMP was a proof-of-concept experiment as Vishal has mentioned.
Please refer to
draft-many-perf-flooding-based-fault-notification-experimental-00.  =
We've
been considering implementing FNP at the transport layer using a routing
protocol.

> 5) Until the effect of network database inaccuracies on the
> effectiveness of  precomputed restoration is better understood, the
> problem of allocating  resources in shared mesh networks is solved, =
and
> it is certain that all faults will be located to the correct span in a
> time useful to restoration, it seems to be premature to be proposing a
> solution to the final piece of the problem.
>=20
[Richard] I believe we've answered each individual point in that =
sentence in
the previous paragraphs. Given that, none are a stumbling block to the
solution.
>=20
> Regards
>=20
> 	George
>=20

Thanks a lot for the comments.=20
Richard.






Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2004 00:16:49 +0000
From: "Adrian Farrel" <[e-mail]>
To: [e-mail]
Subject: Incoming liaisons from ITU-T SG15 Q14
Date: Mon, 01 Mar 2004 00:15:29 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

We have received several liaisons form ITU-T Study Group 15 Question 14 on 
ASON signaling and routing. 

These will be published on the IETF's site in due course. Until then, you 
can find them at http://www.olddog.co.uk/incoming.htm 

Please read and digest before the meeting on Thursday. 

Thanks,
Adrian