Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard
From: Kireeti Kompella <[email-masked]>
To: Jonathan Sadler <[email-masked]>
Cc: [email-masked], "" <[email-masked]>, "" <[email-masked]>
Date: Mon, 30 Jun 2003 03:40:48 -0700 (PDT)

Hi Jonathan,

On Sun, 23 Feb 2003, Jonathan Sadler wrote:

> Please consider the following comments on these drafts:
>     draft-ietf-ccamp-gmpls-routing-05.txt
>     draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
> Many of the comments are based on implementation experience.  These comments are
> marked with a (*).
>
> Jonathan Sadler
>
> ==========
>
> 1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the operations for
> Packet Switch Capable (PSC) are defined.  Reference is made to Minimum LSP bandwidth
> for SDH encoding.  None of the examples in section 5 of
> draft-ietf-ccamp-gmpls-routing-05.txt show how this field should filled.

Is the suggestion that Min LSP bw be removed for PSC?

> 2. The mechanism for showing relationships between server and client layers is not
> generalized*.  Specifically:

I've incorporated most of Stephen Shew's text on layer relations
almost as is.  Most of the specific comments you have should really
be addressed (IMO) to a document on routing for SONET/SDH (such as
draft-mannie-ccamp-gmpls-sonet-sdh-isis[ospf]-00.txt).  Please review
the new text, and let us know if there are issues to be addressed by
*this* document.

> 3. Layer specific attributes are not supported*.  Specifically:
>  - It is not possible to have a link with different costs at
>    different layers (ex. VC-11, VC-4, VC4-4c).
...
>  - Many attributes discussed actually refer to a specific layer*.
...
>  - Combining layer specific attributes with layer relationships can
>    provide a more efficient encoding mechanism than requiring
>    separate link announcements per layer*.
...
> 4. The "TDM" Interface Switching Capability presumably includes
>    layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and
>    G.709.  The interaction with these layers needs to be defined.
...
> 5. In many cases, 8 levels of priority are not necessary*.  A more
>    compact encoding that has a bitfield stating the priority levels
>    being announced would reduce the size of the announcement.

Do you have specific text that you think falls under the realm of
the overall functional spec (as opposed to layer-specific docs)?

Thanks,
Kireeti.

Delivery-date: Fri, 27 Jun 2003 14:38:16 +0000
Date: Fri, 27 Jun 2003 16:35:44 +0200
From: Steffen Brockmann <[email-masked]>
Organization: Alcatel
To: George Swallow <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ccamp-gmpls-overlay-01

This is a multi-part message in MIME format.
--------------33ECE98309DB04B646B35351
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

George,

> >In section 2, the draft states:
> >'When forming a SENDER_TEMPLATE the ingress edge-node includes either
> >its Node-ID or the address of one of its numbered TE links.  In the
> >latter case the connection will only be made over this interface.'
> >
> >That suggests to use the SENDER_TEMPLATE to restrict the choice of data
> >channel.
>
> One certainly can't disallow use of the interface address as it is
> permitted in RSVP.

Certainly not.
I was just wondering about the sentence 'In the latter case the connection will
only be made over this interface.'
That reads like:
If the SENDER_TEMPLATE includes the address of one of ingress edge node's
numbered TE links, the ingress core node MUST refuse the connection on any other
interface.

Where does such strict semantics of the SENDER_TEMPLATE come from?
Unless my recollection deceives me (which is certainly possible), the conclusion
in the early days of RFC3471/73 was that it was the IF_ID RSVP_HOP object's job
to identify the TE/data links, rather than the SENDER_TEMPLATE's job.

> >That however is exactly what according to RFC3471 the TLVs of the IF_ID
> >RSVP_HOP objects are meant for.
> >Instead of the SENDER_TEMPLATE object, shouldn't TLV type 1 be used?
>
> You are correct in that the HOP object narrows what is in the sender
> template.  Further if the Sender template has been used to specify an
> interface, then the hop object must specify a facility within that
> interface (note that the interface could be bundled.)  I can add text to
> this effect if you think that would make the
> draft clearer.

...would certainly help, thanks.

> >There is also a philosophical question that comes with it:
> >The SENDER_TEMPLATE is meant to have end-to-end significance, whereas
> >the selection of the data channel is of local significance.
>
> Yes.  The point of using the interface in the sender template is precisely to
> communicate to the far end the interface for this LSP.  Thus if the far end
> wants to setup a diverse path, it knows to use a different interface.

I can see your point.
However assuming that most SONET (or lower layer) TE links will be unnumbered,
won't it be better to have a solution that works with unnumbered TE links as
well, e.g. mandating core nodes to at least forward the one RRO subobject they
received from ingress edge nodes?

- Steffen

--------------33ECE98309DB04B646B35351
Content-Type: text/x-vcard; charset=us-ascii;
 name="brockmas.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Steffen Brockmann
Content-Disposition: attachment;
 filename="brockmas.vcf"

begin:vcard 
n:Brockmann;Steffen
tel;work:+32-3-240-8615
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[email-masked]
org;quoted-printable:<table WIDTH=3D"100%" ><tr><td><center><a href=3D"http://www.alcatel.com"><img SRC=3D"http://www.cid.alcatel.com/graphics/logo_tag.gif" HSPACE=3D3 BORDER=3D0></a></center></td><td><center><font size=3D+1>System<br>&nbsp=3BArchitecture</font></center></td></tr></table>
fn:Steffen Brockmann
end:vcard

--------------33ECE98309DB04B646B35351--

Delivery-date: Fri, 27 Jun 2003 08:24:37 +0000
From: "Gudipalli, Sugadeesh" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Question regarding Interface Switching Type sub object in LMP
Date: Fri, 27 Jun 2003 04:24:10 -0400

Hello Jonathan and all,

               Since the value of the Interface Switching Type suboject can
be different at the two
ends of a Data link i.e there is no correlation between them. What is the
use of having this sub object
 in the (link property correlation) Link Summary message, since we can't
validate the value of this
 sub object at the other end.

Regards
Sugadeesh

Envelope-to: [email-masked]
Delivery-date: Thu, 26 Jun 2003 19:26:39 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Time slots for CCAMP 57
Date: Thu, 26 Jun 2003 15:25:37 -0400

Yeah.
We've already done 7.
Got close to 6.
Will do 1 if you think it will help :-)

A

PS.
I was really hoping for...
3 : to submit or refer for consideration, judgment, decision, or action;
----- Original Message -----
From: "Kireeti Kompella" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 26, 2003 3:12 PM
Subject: Re: Time slots for CCAMP 57

> Hi Adrian,
>
> On Mon, 23 Jun 2003, Adrian Farrel wrote:
>
> > I would like a timeslot for a discussion of
draft-iwata-mpls-crankback-06.txt
> >
> > This draft addresses some of the requirements from the ASON world and so
falls
> > within the CCAMP remit.
>
> re.mit' (v tr.)
>    1.  To transmit (money) in payment.
> ...
>    6.  To desist from; give up.
>    7.  To put off; postpone.
>
> re.mit' (n.)
>    1.  The act of remitting, especially the referral of a case to another
court
>    2.  A matter remitted for further consideration.
>
> The things you learn in CCAMP ...  I assume that you mean something like
> the last?
>
> If so, we will consider your case in the CCAMP high court.
>
> Kireeti.

Delivery-date: Thu, 26 Jun 2003 19:15:24 +0000
Date: Thu, 26 Jun 2003 12:12:23 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: [email-masked]
Subject: Re: Time slots for CCAMP 57

Hi Adrian,

On Mon, 23 Jun 2003, Adrian Farrel wrote:

> I would like a timeslot for a discussion of draft-iwata-mpls-crankback-06.txt
>
> This draft addresses some of the requirements from the ASON world and so falls
> within the CCAMP remit.

re.mit' (v tr.)
   1.  To transmit (money) in payment.
...
   6.  To desist from; give up.
   7.  To put off; postpone.

re.mit' (n.)
   1.  The act of remitting, especially the referral of a case to another
	court.
   2.  A matter remitted for further consideration.

The things you learn in CCAMP ...  I assume that you mean something like
the last?

If so, we will consider your case in the CCAMP high court.

Kireeti.

Delivery-date: Thu, 26 Jun 2003 10:19:59 +0000
Date: Thu, 26 Jun 2003 12:18:10 +0200
From: [email-masked]
To: Yoshihiko SUEMURA <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked], Jonathan Lang <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt

hi yoshihiko,

see in-line...

Yoshihiko SUEMURA wrote:
> Dimitri,
> 
> I have a question. Please see inline.
> 
> On Wed, 25 Jun 2003 18:10:42 +0200,
> [email-masked] wrote:
> 
> 
>>hi adrian,
>>
>>thanks for these comments... see in-line
>>
>>Adrian Farrel wrote:
>>
>>>Hi,
>>>
>>>I've been re-reading this draft.
>>>
>>>a. Could you make a text clarifiaction around 'primary' and 'secondary'?
>>>    The concepts you cover are useful, but there is some overlap in
>>>    terminology since "primary" is ususally used in protection as a
>>>    synonym for "working" as "secondary" is a synonym for "backup" or
>>>    "protection". I think a text clarification should address my concern.
>>
>>we will address this in the next release, please let us know
>>if have any specific text to be considered
> 
> 
> Does a protecting LSP become a working LSP after a switchover?
> 
> In 10.3, the draft says;
> 
>    "Activation of a secondary LSP is done using a Path
>    refresh message with the S bit set to 0 in the PROTECTION object. At
>    this point, the link and node resources must to be allocated for the
>    LSP that becomes a primary working LSP (ready to carry normal
>    traffic)".
>    
> There is no description about P bit, but the last sentence implies that
> the former protecting LSP become a new working LSP (P bit also set to 0).
> If so, the end nodes must manage information of "which LSP was the
> INITIAL working", so that they can perform reversion after the initial
> working LSP is repaired (I think reversion is mandatory in shared mesh
> restoration).

yes, you're right in shared mesh this is the case.

> If it is not the case (the initial working LSP is still a "working" LSP
> even after a switchover), the end nodes don't have to manage which is
> the initial working LSP. Instead, the end nodes must manage which LSP is
> in use now.
> 
> I think both are possible. So, this is just requesting clarification.

yes, thanks for the pointer clarification is needed
(suggestion be to remove the the word "working" here)
consistently with the reversion mechanism described
in section 12.

thanks,
- dimitri.

> Thank you,
> 
> Yoshihiko
> 
> 
>>>b. Can you add some explanation of why the PPRO is added and how
>>>    it is used. (Hint: each time I read this section I ask the same
>>>    question and have to have it patiently explained by the authors!)
>>>
>>>    Something to cover...
>>>    - Why is the secondary path interested in the primary paths it is
>>>       protecting?
>>>    - How does this knowledge enable it to share resources?
>>>    Answer, it enables a secondary LSP to share resources WITH
>>>    ANOTHER secondary LSP if the protected primary paths are diverse.
>>
>>we will add text on the why, also more details on processing of
>>this object would be appropriate (thus the how) i think a dedicated
>>"processing rules" section would address your comment
>>
>>
>>>c. Need to explicitly state that the use of the "Associated LSP Id"
>>>    field limits the protection schemes supported to 1:1 and 1+1.
>>>    That is no 1:n or m:n support is covered in this draft.
>>
>>yes it is true that the current end-to-end scope does not cover
>>m:n protection (here, 1:n/n:1 could be covered but has not been
>>considered since so far in the protocol extensions due to the
>>operational feedback if things changes we will adapt the text)
>>
>>thanks,
>>- dimitri.
>>
>>
>>>Cheers,
>>>Adrian
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>-- 
>>Papadimitriou Dimitri
>>E-mail : [email-masked]
>>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
>>E-mail : [email-masked]
>>Public : http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : +32 3 240-8491
>>
>>
> 
> 
> 
> -----------------------------------------------------------------
> Yoshihiko SUEMURA 
> 
> Networking Research Laboratories, 
> NEC Corporation
> E-mail: [email-masked]
> Phone: +81 44 856 8109, FAX: +81 44 856 8071
> 

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

Delivery-date: Thu, 26 Jun 2003 08:59:50 +0000
Date: Thu, 26 Jun 2003 17:57:05 +0900
From: Yoshihiko SUEMURA <[email-masked]>
To: [email-masked], Adrian Farrel <[email-masked]>
Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
Cc: [email-masked], Jonathan Lang <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]

Dimitri,

I have a question. Please see inline.

On Wed, 25 Jun 2003 18:10:42 +0200,
[email-masked] wrote:

> hi adrian,
> 
> thanks for these comments... see in-line
> 
> Adrian Farrel wrote:
> > Hi,
> > 
> > I've been re-reading this draft.
> > 
> > a. Could you make a text clarifiaction around 'primary' and 'secondary'?
> >     The concepts you cover are useful, but there is some overlap in
> >     terminology since "primary" is ususally used in protection as a
> >     synonym for "working" as "secondary" is a synonym for "backup" or
> >     "protection". I think a text clarification should address my concern.
> 
> we will address this in the next release, please let us know
> if have any specific text to be considered

Does a protecting LSP become a working LSP after a switchover?

In 10.3, the draft says;

   "Activation of a secondary LSP is done using a Path
   refresh message with the S bit set to 0 in the PROTECTION object. At
   this point, the link and node resources must to be allocated for the
   LSP that becomes a primary working LSP (ready to carry normal
   traffic)".
   
There is no description about P bit, but the last sentence implies that
the former protecting LSP become a new working LSP (P bit also set to 0).
If so, the end nodes must manage information of "which LSP was the
INITIAL working", so that they can perform reversion after the initial
working LSP is repaired (I think reversion is mandatory in shared mesh
restoration).

If it is not the case (the initial working LSP is still a "working" LSP
even after a switchover), the end nodes don't have to manage which is
the initial working LSP. Instead, the end nodes must manage which LSP is
in use now.

I think both are possible. So, this is just requesting clarification.

Thank you,

Yoshihiko

> 
> > b. Can you add some explanation of why the PPRO is added and how
> >     it is used. (Hint: each time I read this section I ask the same
> >     question and have to have it patiently explained by the authors!)
> > 
> >     Something to cover...
> >     - Why is the secondary path interested in the primary paths it is
> >        protecting?
> >     - How does this knowledge enable it to share resources?
> >     Answer, it enables a secondary LSP to share resources WITH
> >     ANOTHER secondary LSP if the protected primary paths are diverse.
> 
> we will add text on the why, also more details on processing of
> this object would be appropriate (thus the how) i think a dedicated
> "processing rules" section would address your comment
> 
> > c. Need to explicitly state that the use of the "Associated LSP Id"
> >     field limits the protection schemes supported to 1:1 and 1+1.
> >     That is no 1:n or m:n support is covered in this draft.
> 
> yes it is true that the current end-to-end scope does not cover
> m:n protection (here, 1:n/n:1 could be covered but has not been
> considered since so far in the protocol extensions due to the
> operational feedback if things changes we will adapt the text)
> 
> thanks,
> - dimitri.
> 
> > Cheers,
> > Adrian
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
> 
> 

-----------------------------------------------------------------
Yoshihiko SUEMURA 

Networking Research Laboratories, 
NEC Corporation
E-mail: [email-masked]
Phone: +81 44 856 8109, FAX: +81 44 856 8071

Delivery-date: Wed, 25 Jun 2003 19:43:57 +0000
Date: Wed, 25 Jun 2003 08:54:41 -0400
To: [email-masked]
From: George Swallow <[email-masked]>
Subject: draft-ietf-ccamp-gmpls-overlay-01
Cc: [email-masked]

Steffen -

>I have a doubt on draft-ietf-ccamp-gmpls-overlay-01:
>
>In section 2, the draft states:
>'When forming a SENDER_TEMPLATE the ingress edge-node includes either
>its Node-ID or the address of one of its numbered TE links.  In the
>latter case the connection will only be made over this interface.'
>
>That suggests to use the SENDER_TEMPLATE to restrict the choice of data
>channel.

One certainly can't disallow use of the interface address as it is 
permitted in RSVP.

>That however is exactly what according to RFC3471 the TLVs of the IF_ID
>RSVP_HOP objects are meant for.
>Instead of the SENDER_TEMPLATE object, shouldn't TLV type 1 be used?

You are correct in that the HOP object narrows what is in the sender 
template.  Further if the Sender template has been used to specify an 
interface, then the hop object must specify a facility within that 
interface (note that the interface could be bundled.)  I can add text to 
this effect if you think that would make the
draft clearer.

>There is also a philosophical question that comes with it:
>The SENDER_TEMPLATE is meant to have end-to-end significance, whereas
>the selection of the data channel is of local significance.

Yes.  The point of using the interface in the sender template is precisely to
communicate to the far end the interface for this LSP.  Thus if the far end
wants to setup a diverse path, it knows to use a different interface.

>There is another inaccuracy in section 3.3, I believe:
>'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.'
>
>It is just an editorial detail, but the first subobject of the ERO sent
>by the ingress edge node must point to the ingress core node. Else the
>ERO check at the ingress core node will fail, according to RFC3209,
>section 4.3.4.1:

Fixed.

>'1) The node receiving the RSVP message MUST first evaluate the first
>subobject.  If the node is not part of the abstract node described by
>the first subobject, it has received the message in error and SHOULD
>return a "Bad initial subobject" error.  If there is no first subobject,
>the message is also in error and the system SHOULD return a "Bad
>EXPLICIT_ROUTE object" error.'

...George

Delivery-date: Wed, 25 Jun 2003 16:12:10 +0000
Date: Wed, 25 Jun 2003 18:10:42 +0200
From: [email-masked]
To: Adrian Farrel <[email-masked]>
Cc: [email-masked], Jonathan Lang <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt

hi adrian,

thanks for these comments... see in-line

Adrian Farrel wrote:
> Hi,
> 
> I've been re-reading this draft.
> 
> a. Could you make a text clarifiaction around 'primary' and 'secondary'?
>     The concepts you cover are useful, but there is some overlap in
>     terminology since "primary" is ususally used in protection as a
>     synonym for "working" as "secondary" is a synonym for "backup" or
>     "protection". I think a text clarification should address my concern.

we will address this in the next release, please let us know
if have any specific text to be considered

> b. Can you add some explanation of why the PPRO is added and how
>     it is used. (Hint: each time I read this section I ask the same
>     question and have to have it patiently explained by the authors!)
> 
>     Something to cover...
>     - Why is the secondary path interested in the primary paths it is
>        protecting?
>     - How does this knowledge enable it to share resources?
>     Answer, it enables a secondary LSP to share resources WITH
>     ANOTHER secondary LSP if the protected primary paths are diverse.

we will add text on the why, also more details on processing of
this object would be appropriate (thus the how) i think a dedicated
"processing rules" section would address your comment

> c. Need to explicitly state that the use of the "Associated LSP Id"
>     field limits the protection schemes supported to 1:1 and 1+1.
>     That is no 1:n or m:n support is covered in this draft.

yes it is true that the current end-to-end scope does not cover
m:n protection (here, 1:n/n:1 could be covered but has not been
considered since so far in the protocol extensions due to the
operational feedback if things changes we will adapt the text)

thanks,
- dimitri.

> Cheers,
> Adrian
> 
> 
> 
> 
> 
> 

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

Envelope-to: [email-masked]
Delivery-date: Wed, 25 Jun 2003 15:50:10 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Jonathan Lang" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>
Subject: draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt
Date: Wed, 25 Jun 2003 11:48:11 -0400

Hi,

I've been re-reading this draft.

a. Could you make a text clarifiaction around 'primary' and 'secondary'?
    The concepts you cover are useful, but there is some overlap in
    terminology since "primary" is ususally used in protection as a
    synonym for "working" as "secondary" is a synonym for "backup" or
    "protection". I think a text clarification should address my concern.

b. Can you add some explanation of why the PPRO is added and how
    it is used. (Hint: each time I read this section I ask the same
    question and have to have it patiently explained by the authors!)

    Something to cover...
    - Why is the secondary path interested in the primary paths it is
       protecting?
    - How does this knowledge enable it to share resources?
    Answer, it enables a secondary LSP to share resources WITH
    ANOTHER secondary LSP if the protected primary paths are diverse.

c. Need to explicitly state that the use of the "Associated LSP Id"
    field limits the protection schemes supported to 1:1 and 1+1.
    That is no 1:n or m:n support is covered in this draft.

Cheers,
Adrian

Delivery-date: Wed, 25 Jun 2003 13:10:44 +0000
Reply-To: <[email-masked]>
Content-Class: urn:content-classes:message
From: "Genadi Velev" <[email-masked]>
To: <[email-masked]>
Subject: extensions in GMPLS signalling for L2SC interfaces 
Date: Wed, 25 Jun 2003 15:05:50 +0200

Hi all,

I'd like to ask the CCAMP community, if anybody works on the development of
GMPLS protocols for signalling of L2 information (i.e. ATM/FR/Ethernet). In
the GMPLS architecture is written that GMPLS LSRs include Layer-2 Switch
Capable (L2SC) interfaces as well. However, a lot of work has been done
previously in MPLS WG standardising the MPLS over ATM and FR switches.

The reason why I'm asking is that we proposed an extension in LDP/CR-LDP for
signalling of VLAN tags. Since this extension is needed for a specific
mechanism only, it would be difficult to convince the community to agree on
the proposed changes. Therefore, if folks know about other L2 technologies
needing extensions of GMPLS signalling protocols, we'd be happy to work
together with them to achieve a common solution.

The history:
shortly before the 56th IETF meeting a draft was posted in MPLS WG regarding
a setup of LSP using VLAN tags over Ethernet networks
(draft-kawakami-mpls-lsp-vlan-00.txt). Since this VLAN-LSP method requires
extension of the signalling protocols (LDP, CR-LDP), it was suggested by
some folks to discuss the problem in CCAMP WG.

Currently:
we have submitted a new draft to the IETF. Until the draft editor posts the
new version, you can find it at:
www.pel.panasonic.de/ietf/docs/draft-kawakami-vlan-lsp-signalling-00.txt
This draft is a new version of draft-kawakami-mpls-lsp-vlan-00.txt. Several
changes were done, as the most essential ones are the employment and
extensions of RSVP-TE for explicitly routed path (instead of CR-LDP).

I'd welcome any feedback on these issues, and see what is the people's
thinking.

Thanks,
Genadi

--------------------------------------------
Genadi Velev
MCOM Group - Mobile Multimedia Team
Panasonic European Laboratories GmbH

addr:   Monzastr. 4c, 63225 Langen, Germany
phone:  +49 (0)6103 766 1193
fax:    +49 (0)6103 766 166
e-mail: mailto:[email-masked]
WWW:    http://www.pel.panasonic.de
--------------------------------------------

Delivery-date: Tue, 24 Jun 2003 18:02:14 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, "'Ronald Bonica'" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Time slots for CCAMP 57
Date: Tue, 24 Jun 2003 10:59:09 -0700

Hi Kireeti, Ron,

I would like to request a 10 minute slot to discuss updates that we made =
to:
- draft-rabbat-optical-recovery-reqs-00.txt (previously
draft-czezowski-optical-recovery-reqs-01.txt)
- draft-rabbat-fault-notification-protocol-03.txt
- draft-soumiya-lmp-fault-notification-ext-01.txt (update will be =
available
by cutoff date)

We have incorporated many comments from the mailing list and from =
private
emails and would like to encourage the remaining CCAMP people to
read/comment on the i-d's.=20

Thanks,
Richard.

Kireeti Kompella wrote:
> Hi,
>=20
> Please submit your requests for time slots for the CCAMP meeting at=20
> the 57th IETF to Ron and me.
>=20
> Note that to get a time slot, you MUST have submitted a draft by the=20
> draft deadline (June 30, 9:00AM ET).  Furthermore, these time slots=20
> are for discussing and resolving issues raised on the mailing list, or =

> for first time drafts, a *very* brief overview of the idea, why it's=20
> relevant, and how it fits into the CCAMP charter.  No presentations!
>=20
> If you request a time slot, please follow up and start an email=20
> discussion on the CCAMP list.
>=20
> Thanks,
> Kireeti.

Delivery-date: Tue, 24 Jun 2003 12:56:15 +0000
From: "Jonathan Lang" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: LMP Link Verification Clarification requested
Date: Tue, 24 Jun 2003 05:55:00 -0700

Richard,
  The first interpretation is correct.  I.e., this refers to the full
SONET/SDH interface, regardless of the Transport Mechanism.

Thanks,
Jonathan

> -----Original Message-----
> From: Bradford, Richard [mailto:[email-masked]] 
> Sent: Tuesday, June 24, 2003 5:37 AM
> To: Jonathan Lang
> Cc: [email-masked]
> Subject: LMP Link Verification Clarification requested
> 
> 
> The LMP Link Verification BEGIN_VERIFY class allows for the 
> Verify Transport Mechanism to carry a mask of allowed 
> transports. The TransmissionRate field contains:
>         "This is the transmission rate of the data link over 
> which the Test messages will be transmitted"
> 
> It appears there may be multiple interpretations of this 
> statement. One interpretation is that this refers to the same 
> data link used throughout the rest of the specification (i.e. 
> an OC3 = ~155M/8 bytes per second). An alternate 
> interpretation would be that this refers to the transmission 
> rate of the test messages themselves (i.e. DCCS = 192K/8
> bytes/sec)
> 
> Which interpretation is correct?
> 
> If the latter (i.e. the transmission rate of the test 
> messages), then the following questions need to be addressed:
> 
> The first question I have is how multiple Transport 
> Mechanisms can be advertised with one TransmissionRate.
> 
> Let's say that an OC3 interface is capable of verifying over 
> J0-16, DCCS, and Payload. J0-16 could be interpreted as 16 
> bytes/sec. DCCS could be 192K/8 bytes/sec. Payload could be 
> ~155M/8 bytes/sec.
> 
> The second question involves ambiguity when DCCS is 
> specified. The DCCS data rate of 192K/8 is the same for OC3, 
> OC12, OC48, etc. Knowing the DCCS data rate does not provide 
> useful information for interface termination. The source 
> device might be sending SDCC over OC12, while the receiver 
> might choose to terminate at OC48.
> 
> One possible solution to this problem rests on the 
> interpretation of "transmission rate of the data link". If 
> the TransmissionRate refers to the full SONET/SDH interface 
> regardless of the Transport Mechanism, then both of the above 
> problems are resolved. 
> 

Delivery-date: Tue, 24 Jun 2003 12:39:38 +0000
Date: Tue, 24 Jun 2003 08:37:22 -0400
To: "Jonathan Lang" <[email-masked]>
From: "Bradford, Richard" <[email-masked]>
Subject: LMP Link Verification Clarification requested
Cc: <[email-masked]>

--=====================_236468463==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

The LMP Link Verification BEGIN_VERIFY class allows for the Verify 
Transport Mechanism to carry a mask of allowed transports. The 
TransmissionRate field contains:
         "This is the transmission rate of the data link over which the 
Test messages will be transmitted"

It appears there may be multiple interpretations of this statement. One 
interpretation is that this refers to the same data link used throughout 
the rest of the specification (i.e. an OC3 = ~155M/8 bytes per second). An 
alternate interpretation would be that this refers to the transmission rate 
of the test messages themselves (i.e. DCCS = 192K/8 bytes/sec)

Which interpretation is correct?

If the latter (i.e. the transmission rate of the test messages), then the 
following questions need to be addressed:

The first question I have is how multiple Transport Mechanisms can be 
advertised with one TransmissionRate.

Let's say that an OC3 interface is capable of verifying over J0-16, DCCS, 
and Payload.
J0-16 could be interpreted as 16 bytes/sec.
DCCS could be 192K/8 bytes/sec.
Payload could be ~155M/8 bytes/sec.

The second question involves ambiguity when DCCS is specified. The DCCS 
data rate of 192K/8 is the same for OC3, OC12, OC48, etc. Knowing the DCCS 
data rate does not provide useful information for interface termination. 
The source device might be sending SDCC over OC12, while the receiver might 
choose to terminate at OC48.

One possible solution to this problem rests on the interpretation of 
"transmission rate of the data link". If the TransmissionRate refers to the 
full SONET/SDH interface regardless of the Transport Mechanism, then both 
of the above problems are resolved.

--=====================_236468463==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>The LMP Link Verification BEGIN_VERIFY class allows for the
Verify Transport Mechanism to carry a mask of allowed transports. The
TransmissionRate field contains:<br>
</font><font face="Times New Roman, Times" size=2><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&quot;This
is the transmission rate of the data link over which the Test messages
will be transmitted&quot;<br>
<br>
It appears there may be multiple interpretations of this statement. One
interpretation is that this refers to the same data link used throughout
the rest of the specification (i.e. an OC3 = ~155M/8 bytes per second).
An alternate interpretation would be that this refers to the transmission
rate of the test messages themselves (i.e. DCCS = 192K/8 bytes/sec)<br>
<br>
Which interpretation is correct?<br>
<br>
If the latter (i.e. the transmission rate of the test messages), then the
following questions need to be addressed:<br>
<br>
The first question I have is how multiple Transport Mechanisms can be
advertised with one TransmissionRate.<br>
<br>
Let's say that an OC3 interface is capable of verifying over J0-16, DCCS,
and Payload.<br>
J0-16 could be interpreted as 16 bytes/sec.<br>
DCCS could be 192K/8 bytes/sec.<br>
Payload could be ~155M/8 bytes/sec.<br>
<br>
The second question involves ambiguity when DCCS is specified. The DCCS
data rate of 192K/8 is the same for OC3, OC12, OC48, etc. Knowing the
DCCS data rate does not provide useful information for interface
termination. The source device might be sending SDCC over OC12, while the
receiver might choose to terminate at OC48.<br>
<br>
One possible solution to this problem rests on the interpretation of
&quot;transmission rate of the data link&quot;. If the TransmissionRate
refers to the full SONET/SDH interface regardless of the Transport
Mechanism, then both of the above problems are resolved. <br>
<br>
</font><br>

<font face="Courier, Courier"></font></html>

--=====================_236468463==_.ALT--

Delivery-date: Tue, 24 Jun 2003 10:50:36 +0000
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-rabbat-optical-recovery-reqs-00.txt
Date: Tue, 24 Jun 2003 06:49:57 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Optical Network Failure Recovery Requirements
	Author(s)	: R. Rabbat et al.
	Filename	: draft-rabbat-optical-recovery-reqs-00.txt
	Pages		: 10
	Date		: 2003-6-23
	
This draft presents requirements for control plane-based recovery in 
optical networks.  We focus on data-plane failure recovery in optical 
networks that use a GMPLS-based control plane, but use different 
transport plane technologies.  Our goal is to gather and 
systematically lay out these requirements in one document to serve as 
a coherent basis for work on protocol and solution development. We 
begin with a brief overview and consideration of the requirements, 
and then list the requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rabbat-optical-recovery-reqs-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-rabbat-optical-recovery-reqs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-rabbat-optical-recovery-reqs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-rabbat-optical-recovery-reqs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rabbat-optical-recovery-reqs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 24 Jun 2003 10:39:26 +0000
To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ayyangar-inter-region-te-00.txt
Date: Tue, 24 Jun 2003 06:36:44 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Inter-region MPLS Traffic Engineering
	Author(s)	: A. Ayyangar, J. Vasseur
	Filename	: draft-ayyangar-inter-region-te-00.txt
	Pages		: 20
	Date		: 2003-6-23
	
This draft proposes mechanisms for the establishment and maintenance of
MPLS Traffic Engineering (TE) Label Switched Paths (LSP) that traverse
multiple regions, where a region could be an IGP Area or an Autonomous
System or a GMPLS overlay network. This document also outlines different
mechanisms that an operator could employ within his region to facilitate
the setup of these inter-region TE LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ayyangar-inter-region-te-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-ayyangar-inter-region-te-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ayyangar-inter-region-te-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ayyangar-inter-region-te-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ayyangar-inter-region-te-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Mon, 23 Jun 2003 19:04:30 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: Re: Time slots for CCAMP 57
Date: Mon, 23 Jun 2003 15:03:39 -0400

Hi,

I would like a timeslot for a discussion of draft-iwata-mpls-crankback-06.txt

This draft addresses some of the requirements from the ASON world and so falls
within the CCAMP remit.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Mon, 23 Jun 2003 19:04:01 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-iwata-mpls-crankback-06.txt
Date: Mon, 23 Jun 2003 15:01:46 -0400

Hi,

This poor old draft is still looking for a home.
It looks increasingly that the interest is in CCAMP since
- that is where the ASON work is going on
- the draft now uses protocol extensions from RFC3471/3

In summary, we have moved crankback over to use the IF_ID Error Spec rather than
special new objects.

The draft as currently structured provides a problem statement and a solution.
We would welcome opinions about either half (or both).

Adrian

----- Original Message -----
From: <[email-masked]>
To: <IETF-Announce: ;>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 17, 2003 7:56 AM
Subject: I-D ACTION:draft-iwata-mpls-crankback-06.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Crankback Signaling Extensions for MPLS Signaling
> Author(s) : A. Farrel, A. Iwata et al.
> Filename : draft-iwata-mpls-crankback-06.txt
> Pages : 30
> Date : 2003-6-16
>
> Recently, several routing protocol extensions for
> advertising resource information in addition to topology
> information have been proposed for use in distributed
> constraint-based routing.  In such a distributed routing
> environment, however, the information used to compute a
> constraint-based path may be out of date.  This means
> that LSP setup requests may be blocked by links or nodes
> without sufficient resources.
> This draft specifies crankback routing extensions for use
> in Multi-Protocol Label Switching (MPLS) signaling using
> RSVP-TE as defined in 'RSVP-TE: Extensions to RSVP for
> LSP Tunnels', RFC3209, so that the LSP setup request can
> be retried on an alternate path that detours around the
> blocked link or node upon a setup failure.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-06.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-iwata-mpls-crankback-06.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-iwata-mpls-crankback-06.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.
>

Delivery-date: Mon, 23 Jun 2003 12:50:04 +0000
Date: Mon, 23 Jun 2003 14:49:01 +0200
From: Xiaoming Fu <[email-masked]>
To: Kireeti Kompella <[email-masked]>, Ron Bonica <[email-masked]>
CC: [email-masked], Rene Soltwisch <[email-masked]>
Subject: Re: Time slots for CCAMP 57

Kireeti, Ron,

Can you please allocate a 5-10 min. time slot for the following draft:

http://user.informatik.uni-goettingen.de/~fu/paper/draft-fu-ccamp-traceroute-00.txt
http://user.informatik.uni-goettingen.de/~fu/paper/draft-fu-ccamp-traceroute-00.pdf

This draft identifies some (transport) issues for generic traceroute for 
tunnels (tunneltrace): (1) it is possible that some IP hops do not 
support the tunneltrace, (2) for each tunnel wishing to be traced, at 
least the two end points should support the tunneltrace, (3) tracing 
message should be able to bypass firewalls and NATs. One possible 
solution, based on the CASP signaling protocol (stateless mode), is 
proposed to support generic routetracing over tunnels.

Suggestion and comments from the working group are very appreciated.

Thanks,
Xiaoming & Rene

Kireeti Kompella wrote:
> Hi,
> 
> Please submit your requests for time slots for the CCAMP meeting
> at the 57th IETF to Ron and me.
> 
> Note that to get a time slot, you MUST have submitted a draft by
> the draft deadline (June 30, 9:00AM ET).  Furthermore, these time
> slots are for discussing and resolving issues raised on the mailing
> list, or for first time drafts, a *very* brief overview of the idea,
> why it's relevant, and how it fits into the CCAMP charter.  No
> presentations!
> 
> If you request a time slot, please follow up and start an email
> discussion on the CCAMP list.
> 
> Thanks,
> Kireeti.

Delivery-date: Mon, 23 Jun 2003 05:20:22 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Ruiquan jing" <[email-masked]>, <[email-masked]>
Subject: RE: Flooding using LMP extensions 
Date: Sun, 22 Jun 2003 22:15:15 -0700

Hi Rick,

Actually, the answer to your question is "No, you're not."

The protection paths are computed (usually) assuming a single
fault in the network. That is, the protection path computation algorithm
assumes a certain fault in the network, and then computes backup
paths for working paths affected by this fault. (It repeats
this process for all single faults.)

If the particular fault actually does occur, the working paths
affected by the fault can be switched, by the recovery entity,
to their respective protection paths.

If dynamic path computation is performed upon the occurrence
of a fault, then too, the computation algorithm at a recovery
entity can compute backup paths once it learns (via fault
notification) of the fault (i.e, of the nature and location
of the fault).

The convergence of the routing algorithm is only helpful for _every_
network node to (eventually) update its routing database, and figure
out the new topology.

BTW, when flooding-based notification is used, every network node would, in
fact, know
of the fault, but this would be via the signaling function of the control
plane,
and would not necessarily lead to the updating of its routing table (which
would
be updated when the routing engine at a node learnt of the fault through the
routing protocol updates).

-Vishal

> -----Original Message-----
> From: Ruiquan jing [mailto:[email-masked]]
> Sent: Sunday, June 22, 2003 8:10 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Flooding using LMP extensions
>
>
> Hi Vishal,
>
> I agree with you that G.7715 is about ASON routing.
> As for restoration, I think you still need the routing table to compute
> the restoration paths. And this could only began after the routing table
> is converged.
> Am I right?
>
> Thanks!
>
> rick
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Vishal Sharma
> Sent: Saturday, June 21, 2003 4:57 AM
> To: Ong, Lyndon; rick king; Roberto Albanese; [email-masked]
> Subject: RE: Flooding using LMP extensions
>
>
> Hi Lyndon,
>
> Thanks a lot for your observations, and for the clarification
> on the meaning of an "SNPP link."
>
> Some comments in-line.
>
> -Vishal
>
> > -----Original Message-----
> > From: Ong, Lyndon [mailto:[email-masked]]
> > Sent: Friday, June 20, 2003 11:05 AM
> > To: [email-masked]'; rick king; Roberto Albanese; [email-masked]
> > Subject: RE: Flooding using LMP extensions
> >
> >
> > Hi Vishal,
> >
> > I haven't been following this discussion closely, but
> > I think you are right in distinguishing routing from
> > signaling as functions in the control plane.  Some of
> > the confusion may be in the term SNPP link, in ITU
> > terminology this is a representation of connectivity
> > between different subnetworks for routing purposes,
> > so for example it may include multiple link connections
> > that share the same characteristics.
>
> Great, thanks.
> I do think that Rick has been referring to ITU specs. dealing
> with the routing functions of the control plane, whereas
> the focus in the "Flooding using LMP extensions" email thread
> is really on signaling functions of the control plane.
>
> > Knowing the state of an SNPP link would not tell you the
> > state of individual connections using the SNPP link,
> > which would be a signaling function.
>
> Appreciate the explanation. This is actually an important
> distinction, which underscores the importance of having a signaling
> function in the control plane, especially for P&R.
>
> -Vishal
>
>
> > -----Original Message-----
> > From: Vishal Sharma [mailto:[email-masked]]
> > Sent: Thursday, June 19, 2003 6:28 PM
> > To: rick king; Roberto Albanese; [email-masked]
> > Subject: RE: Flooding using LMP extensions
> >
> >
> > Rick,
> >
> > Thanks for the pointer. I now have a better idea of what you
> > were referring to earlier.
> >
> > Actually, there is no conflict between the discussion we're currently
> > having and the ITU description. (One (the ITU description below)
> > refers to, what I would call, "routing related" updates in the control
> > plane, while the other (the discussion we're having) refers to,
> > what I would call, "sigaling related" updates in the control plane.)
> >
> > Except that in the rabbat-draft, the so called "signaling" (or,
> > more accurately, fault notification) is achieved via flooding.
> >
> > The ITU description you've provided below refers to _routing related_
> > activity in the control plane. (That is, if a link state changes, the
> > control plane -- RC, RDB, etc. -- have to learn about it and make the
> > required
> > updates.)
> > In fact, this is what will happen in an IP-controlled transport
> > network also. The routing information and related databases _will_,
> > eventually, be updated. (And, at that time, one may
> > more optimally route those circuits that have been switched to recovery
> > paths in the meantime.)
> >
> > We, however, are talking about recovery here. This includes steps that
> > have to occur _in the interim_ to ensure that traffic flow is not
> > disrupted (or disrupted as little as possible). So there has to
> > be a way to inform the affected nodes of the failure for them to
> > take action.
> > _This_ is what we've been discussing on this thread.
> >
> > I don't think the ITU documentation is implying at all
> > that the routing-related updates be the means of fault
> > notification.
> >
> > -Vishal
> >
>
>

Delivery-date: Fri, 20 Jun 2003 20:59:06 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, "rick king" <[email-masked]>, "Roberto Albanese" <[email-masked]>, <[email-masked]>
Subject: RE: Flooding using LMP extensions 
Date: Fri, 20 Jun 2003 13:56:56 -0700

Hi Lyndon,

Thanks a lot for your observations, and for the clarification
on the meaning of an "SNPP link."

Some comments in-line.

-Vishal

> -----Original Message-----
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Friday, June 20, 2003 11:05 AM
> To: [email-masked]'; rick king; Roberto Albanese; [email-masked]
> Subject: RE: Flooding using LMP extensions 
> 
> 
> Hi Vishal,
> 
> I haven't been following this discussion closely, but
> I think you are right in distinguishing routing from
> signaling as functions in the control plane.  Some of
> the confusion may be in the term SNPP link, in ITU
> terminology this is a representation of connectivity
> between different subnetworks for routing purposes,
> so for example it may include multiple link connections 
> that share the same characteristics.

Great, thanks.
I do think that Rick has been referring to ITU specs. dealing
with the routing functions of the control plane, whereas
the focus in the "Flooding using LMP extensions" email thread
is really on signaling functions of the control plane.

> Knowing the state of an SNPP link would not tell you the
> state of individual connections using the SNPP link,
> which would be a signaling function.

Appreciate the explanation. This is actually an important
distinction, which underscores the importance of having a signaling
function in the control plane, especially for P&R.

-Vishal

> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Thursday, June 19, 2003 6:28 PM
> To: rick king; Roberto Albanese; [email-masked]
> Subject: RE: Flooding using LMP extensions 
> 
> 
> Rick,
> 
> Thanks for the pointer. I now have a better idea of what you
> were referring to earlier.
> 
> Actually, there is no conflict between the discussion we're currently
> having and the ITU description. (One (the ITU description below)
> refers to, what I would call, "routing related" updates in the control
> plane, while the other (the discussion we're having) refers to,
> what I would call, "sigaling related" updates in the control plane.)
> 
> Except that in the rabbat-draft, the so called "signaling" (or,
> more accurately, fault notification) is achieved via flooding.
> 
> The ITU description you've provided below refers to _routing related_
> activity in the control plane. (That is, if a link state changes, the
> control plane -- RC, RDB, etc. -- have to learn about it and make the
> required
> updates.)
> In fact, this is what will happen in an IP-controlled transport
> network also. The routing information and related databases _will_,
> eventually, be updated. (And, at that time, one may
> more optimally route those circuits that have been switched to recovery
> paths in the meantime.)
> 
> We, however, are talking about recovery here. This includes steps that
> have to occur _in the interim_ to ensure that traffic flow is not
> disrupted (or disrupted as little as possible). So there has to
> be a way to inform the affected nodes of the failure for them to
> take action.
> _This_ is what we've been discussing on this thread.
> 
> I don't think the ITU documentation is implying at all
> that the routing-related updates be the means of fault
> notification.
> 
> -Vishal
> 

Delivery-date: Fri, 20 Jun 2003 18:28:19 +0000
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-rabbat-fault-notification-protocol-03.txt
Date: Fri, 20 Jun 2003 14:27:31 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Fault Notification Protocol for GMPLS-Based Recovery
	Author(s)	: R. Rabbat et al.
	Filename	: draft-rabbat-fault-notification-protocol-03.txt
	Pages		: 17
	Date		: 2003-6-20
	
This draft presents a fault notification protocol that is 
implementation-agnostic to be used in a GMPLS-based failure recovery 
scheme.  The protocol achieves bounded recovery path activation times 
in the event of single resource failures. This is done by allowing 
for the computation of constrained recovery paths that take into 
account the physical capabilities of the nodes as well as the delay 
characteristics of the control plane.  We propose using a flooding 
protocol for fault notification to allow for per-failure notification 
and to speed up the recovery process, and justify choices made for 
the notification method and for the extensions required to current 
protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rabbat-fault-notification-protocol-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-rabbat-fault-notification-protocol-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-rabbat-fault-notification-protocol-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rabbat-fault-notification-protocol-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 20 Jun 2003 18:03:47 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, rick king <[email-masked]>, Roberto Albanese <[email-masked]>,  [email-masked]
Subject: RE: Flooding using LMP extensions 
Date: Fri, 20 Jun 2003 11:05:05 -0700

Hi Vishal,

I haven't been following this discussion closely, but
I think you are right in distinguishing routing from
signaling as functions in the control plane.  Some of
the confusion may be in the term SNPP link, in ITU
terminology this is a representation of connectivity
between different subnetworks for routing purposes,
so for example it may include multiple link connections 
that share the same characteristics.

Knowing the state of an SNPP link would not tell you the
state of individual connections using the SNPP link,
which would be a signaling function.

Cheers,

Lyndon

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Thursday, June 19, 2003 6:28 PM
To: rick king; Roberto Albanese; [email-masked]
Subject: RE: Flooding using LMP extensions 

Rick,

Thanks for the pointer. I now have a better idea of what you
were referring to earlier.

Actually, there is no conflict between the discussion we're currently
having and the ITU description. (One (the ITU description below)
refers to, what I would call, "routing related" updates in the control
plane, while the other (the discussion we're having) refers to,
what I would call, "sigaling related" updates in the control plane.)

Except that in the rabbat-draft, the so called "signaling" (or,
more accurately, fault notification) is achieved via flooding.

The ITU description you've provided below refers to _routing related_
activity in the control plane. (That is, if a link state changes, the
control plane -- RC, RDB, etc. -- have to learn about it and make the
required
updates.)
In fact, this is what will happen in an IP-controlled transport
network also. The routing information and related databases _will_,
eventually, be updated. (And, at that time, one may
more optimally route those circuits that have been switched to recovery
paths in the meantime.)

We, however, are talking about recovery here. This includes steps that
have to occur _in the interim_ to ensure that traffic flow is not
disrupted (or disrupted as little as possible). So there has to
be a way to inform the affected nodes of the failure for them to
take action.
_This_ is what we've been discussing on this thread.

I don't think the ITU documentation is implying at all
that the routing-related updates be the means of fault
notification.

-Vishal

Delivery-date: Fri, 20 Jun 2003 01:30:48 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "rick king" <[email-masked]>, "Roberto Albanese" <[email-masked]>, <[email-masked]>
Subject: RE: Flooding using LMP extensions 
Date: Thu, 19 Jun 2003 18:27:50 -0700

Rick,

Thanks for the pointer. I now have a better idea of what you
were referring to earlier.

Actually, there is no conflict between the discussion we're currently
having and the ITU description. (One (the ITU description below)
refers to, what I would call, "routing related" updates in the control
plane, while the other (the discussion we're having) refers to,
what I would call, "sigaling related" updates in the control plane.)

Except that in the rabbat-draft, the so called "signaling" (or,
more accurately, fault notification) is achieved via flooding.

The ITU description you've provided below refers to _routing related_
activity in the control plane. (That is, if a link state changes, the
control plane -- RC, RDB, etc. -- have to learn about it and make the
required
updates.)
In fact, this is what will happen in an IP-controlled transport
network also. The routing information and related databases _will_,
eventually, be updated. (And, at that time, one may
more optimally route those circuits that have been switched to recovery
paths in the meantime.)

We, however, are talking about recovery here. This includes steps that
have to occur _in the interim_ to ensure that traffic flow is not
disrupted (or disrupted as little as possible). So there has to
be a way to inform the affected nodes of the failure for them to
take action.
_This_ is what we've been discussing on this thread.

I don't think the ITU documentation is implying at all
that the routing-related updates be the means of fault
notification.

-Vishal

> -----Original Message-----
> From: rick king [mailto:[email-masked]]
> Sent: Thursday, June 19, 2003 6:02 PM
> To: [email-masked]; Roberto Albanese; [email-masked]
> Subject: RE: Flooding using LMP extensions
>
>
> Vishal,
>
> I don't think RC and RDB only concern about a node or a small
> collection of nodes.
> Followings are from ITU-T G.7715  section 5.2:
> ------------------
> 1.	Routing Controller – The RC functions include exchanging
> routing information with peer RCs and replying to a route query
> (path selection) by operating on the Routing Information
> Database.  The RC is protocol independent.
>
> 2.	Routing Information Database (RDB) - The RDB is a
> repository for the local topology, network topology,
> reachability, and other routing information that is updated as
> part of the routing information exchange and may additionally
> contain information that is configured.  The RDB may contain
> routing information for more than one routing area.  The Routing
> Controller has access to a view of the RDB.  Figure 2 illustrates
> this by showing a dotted line around the RC and the RDB.  This
> dotted line signifies the RC (as described in G.8080) as
> encapsulating a view of the RDB. The RDB is protocol independent.
>
> 3.Link Resource Manager – The LRM supplies all the relevant SNPP
> link information to the Routing Controller. It informs the RC
> about any state changes of the link resources it controls.
>
> Note - Since the RDB may contain routing information pertaining
> to multiple Routing Areas (and hence possibly multiple layer
> networks), the routing controllers accessing the RDB may share
> the routing information.  This is illustrated in Figure 3 by
> showing the overlap between the dotted lines.
> -----------------
>
> rick
>
> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Friday, June 20, 2003 1:55 AM
> To: rick king; Roberto Albanese; [email-masked]
> Subject: RE: Flooding using LMP extensions
>
>
> Rick,
>
> Can you be more specific, and point to the exact ITU document
> and section numbers you're referring to below.
>
> In any case, I think what you're referring to below occurs
> within a node (or a small collection of nodes), whereas what we're
> discussing
> is network-wide notification.
>
> One of the ITU experts can probably enlighten us further, and correct
> me if I'm wrong.
>
> -Vishal
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of rick king
> > Sent: Thursday, June 19, 2003 2:13 AM
> > To: [email-masked]; Roberto Albanese; [email-masked]
> > Subject: RE: Flooding using LMP extensions
> >
> >
> > My two cents:
> >
> > With ITU-T glossary, I think LRM(Link Resource Manager) will
> > detect the link fault ,
> > and then notifies the RC(Routing Control) to update the RDB.
> >
> > rick
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Vishal Sharma
> > Sent: Thursday, June 19, 2003 1:36 PM
> > To: Roberto Albanese; [email-masked]
> > Subject: RE: Flooding using LMP extensions
> >
> >
> > Hi Roberto and Nicola,
> >
> > Thanks very much for your observations and for your detailed
> > analysis of the issues.
> >
> > I certainly share your view that a flooding-based solution to fault
> > notification can present several advantages, and is one that we should
> > consider as a candidate (together with the signaling-based solutions
> > proposed
> > so far).
> >
> > 1) In that regard, it would be nice to get your inputs on draft-rabbat:
> > http://www.ietf.org/internet-drafts/draft-rabbat-fault-notificatio
> > n-protocol
> > -02.txt
> > since the mechanisms proposed there are technology, protocol,
> and topology
> > agnostic.
> > Do you, for instance, agree with the basic proposal in there? Do you
> > have any feedback, additions, or suggestions, based on your
> experience of
> > building your MPLS testbed?
> >
> > 2) On that note, I was wondering if you'd already made the modifications
> > to OSPF that you discussed in your email, and if you have any
> > performance results you might be able to share with the WG.
> > (Richard in one of his earlier emails, I believe, mentioned that he
> > has some prototyping results on LMP performance.)
> >
> > 3) Finally, here are some points that I'd like to discuss related to
> > the issues highlighted in your email.
> >
> >  i) I wanted to add that not only could flooding minimize
> routing failure
> >     probability (as you've observed), it could also speed up recovery
> >     by notifying (in parallel)
> >     the nodes on multiple recovery paths affected by a given
> > fault. This can
> >     prove very advantageous when a link carries a large number of
> >     transport circuits (e.g. lambdas), and when the LSPs do not
> share the
> >     same s-d pairs.
> >
> >  ii) In regard to the argument for using OSPF to obtain a solution that
> > works
> >      both for MPLS and GMPLS, my thought is that this is not
> > critical, since
> >      the recovery methods (e.g. fast reroute) at the MPLS layer
> > are already
> >      well-defined and are not common with the recovery methods
> used at the
> >      transport layer. Thus, there is less of a need to have a
> > solution that
> >      works across layers of the network using MPLS and GMPLS,
> > respectively.
> >      On the contrary, the "cost" of trying to incorporate the fault
> > notification
> >      functionality in a routing protocol, like OSPF, an be heavy (as I
> > explain below).
> >
> >  iii) This is because one has to develop solutions for multiple routing
> > protocols
> >      (as not everyone will use OSPF). More importantly, a
> service provider
> > not
> >       normally running a routing protocol at the transport layer
> > (but using
> > LMP
> >       and GMPLS signaling), would be forced to run a routing
> protocol just
> > for
> >       efficient fault notification! That seems like an undue burden.
> >       Furthermore, unlike LMP, OSPF requires more involved processing,
> > making it
> >       difficult to ensure that the failure-related messages are always
> > processed
> >       and dispatched _before_ other OSPF messages.
> >
> >       Also, irrespective of whether a provider runs routing, it
> is likely
> > that
> >       a GMPLS-control plane at the transport layer will at
> least run LMP,
> > thus
> >       making it a natural choice to extend for flooding-based fault
> > notification.
> >
> >       Of course, I welcome service provider inputs on this
> issue, and they
> >       can correct me if I'm wrong. :-)
> >
> >
> >  iv) And finally, it appears that you are inserting the timer
> > functionality
> > and
> >      initial detection functionality in LMP anyway, so in the
> > light of (iii)
> > above,
> >      wouldn't it be easier just to extend LMP. (With regard to
> > the argument
> > of OSPF
> >      flooding being mature, perhaps we can learn from the lessons
> > there, and
> > not
> >      repeat the same mistakes when operating LMP. :-)).
> >
> > Best regards,
> > -Vishal
> >
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > Roberto Albanese
> > Sent: Tuesday, June 17, 2003 10:50 AM
> > To: [email-masked]
> > Subject: Re: Flooding using LMP extensions
> >
> >
> > Hi all,
> > we are working to a MPLS testbed supporting end-to-end
> > Protection-Restoration mechanisms and we faced the problem of
> > link-failures notification.
> > We share the scalability concerns of RSVP-like
> > solutions reported in the Rabbat's mail.
> > We are in favour of OSPF flooding-based mechanisms for link-failures
> > using Opaque because:
> >
> > -  applicable to both MPLS-TE - GMPLS.
> >
> > -  Proved OSPF protocol stability and robustness with respect to the LMP
> > solution.
> >    OSPF flooding in general is mature, instead LMP has to be extended
> >    and it has to support some OSPF capabilities we already have.
> >
> > -  Reduction of routing failure probability respect to the use of
> > RSVP (see
> > below).
> >       In draft-katz-yeung-ospf-traffic-09 it is written that in a TE
> > scenario
> >       we can have a module in the edge nodes that searches constrained
> > routes
> >       based on Opaque TE info.
> >       We call a "routing failure" the computation by edge node
> X of a path
> >       which includes a failed link F.
> >       Clearly, routing failures are a consequence of lack of
> notification,
> >       to X, of the failure of F.
> >       With RSVP failure notification, this can occur:
> >       -  in case of single fault, when there are no LSPs
> originated from X
> > crossing F;
> >       -  in case of dual faults (i.e., two links L1 and L2 fails almost
> > simultaneously),
> >          if from X there is a LSP crossing both L1 and L2:
> >
> >
> X---link-----node------link(L1)------node-------link(L2)-----egress_node
> >
> >       the failure of L1 can hide the notification of L2 failures.
> >
> >       It can be seen that with OSPF flooding, there is virtually no
> > potential
> >       routing failure at all, as ALL the edge nodes are notified any
> > failure.
> >
> >       So if we have a flooding-based notification, all the edge
> nodes in a
> > network
> >       will be aware about the failure. Instead, with RSVP, we'll have
> >       only some nodes aware of the failure! So we have an increasing of
> >       routing failure probability after a link failure.
> >
> > We agree that a major drawback of the OSPF-flooding solution is
> > the need of
> > revisiting
> > the timers, as pointed out in the Rabbat's mail:"Flooding using LMP
> > extensions".
> > In fact we can't wait for a max period of MinLSInterval seconds
> > to notify a
> > failure...
> > So we have to modify something.
> >
> > Among the possible solutions:
> >
> > 1)  Introduction of a new timer in OSPF for a new sub-TLV
> >     used to carry the info of broken link.
> >     The current timer of MinLSInterval should not consider
> >     this new field.
> >
> > 2)  Force the flooding when a link failure signal arrives
> >     and reset the timer.
> >
> > We think that the 2) solution has more advantages.
> > The current behavior of the OSPF protocol is (considering Opaque
> > extensions):
> >
> >        <----------------MinLSInterval------------->
> >
> >     B1 |             B2 |   B3 |    FAIL. |
> >        |                |      |          |
> >     ---+----------------+------+----------+-------+------------> time
> >        |                                          |
> >        |                                          |
> >      FL1                                        FL2
> >
> >    WHERE:
> >
> > -  FL1 is a flooding of B1 information.
> > -  FL2 is a flooding of B3 + FAIL. information.
> > -  FAIL. could be a signal coming from a failure detection mechanism
> >    (i.e. from lower layer).
> > -  B1, B2, B3, FAIL. are external OSPF Opaque inputs.
> >    Note that B1, B2, B3 could be Bandwidth updates (link TLVs updates).
> >
> > We thought to solve in this way:
> >
> >                                   <-------------MinLSInterval--------->
> >       <-------------MinLSInterval------>
> >
> >    B1 |        B2 |   B3 |   FAIL.|
> >       |           |      |        |
> >
> >
> ---+-----------+------+--------+-----------------------------------------
> > ->
> >       |                           |
>       time
> >       |                           |
> >      FL1                        FL2
> >
> > In this case we force the flooding (FL2) when arrives a signal of
> > link-failure (FAIL.) and we reset the MinLSInterval timer so that
> > it restarts from the failure event.
> >
> > To enforce the robustness of this solution, and to avoid
> > continous flooding
> > of
> > failure notifications in case of interface flapping,  we have to
> > consider a
> > timer in the module (external to OSPF) that detects the
> link-failures and
> > triggers the flooding of FL2 Opaque LSA.
> >
> > Consider that some external module is needed to trigger the
> OSPF flooding
> > of failure notification, as we can not rely on the HELLO process for its
> > long detection delay.
> > A possibility is to let LMP to detect the failure and trigger the OSPF
> > flooding.
> >
> > In this approach, the timer to avoid interface-flapping should
> be included
> > in the LMP trigger.
> > This solution is conservative in that it only requires LMP extensions
> > (timer in the trigger) and just a minor modification to the OSPF process
> > (i.e., accept a force-to-send and  MinLSInterval-reset trigger).
> >
> >
> > Thanks in advance for your kind observations.
> >
> > Regards
> >
> > Roberto Albanese, Nicola Caione
> > University of Rome - La Sapienza, Italy
> >
> >
> >
>
>

Delivery-date: Fri, 20 Jun 2003 01:07:03 +0000
From: "rick king" <[email-masked]>
To: <[email-masked]>, "Roberto Albanese" <[email-masked]>, <[email-masked]>
Subject: RE: Flooding using LMP extensions 
Date: Fri, 20 Jun 2003 09:02:14 +0800

Delivery-date: Thu, 19 Jun 2003 17:57:25 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "rick king" <[email-masked]>, "Roberto Albanese" <[email-masked]>, <[email-masked]>
Subject: RE: Flooding using LMP extensions 
Date: Thu, 19 Jun 2003 10:54:58 -0700

Rick,

Can you be more specific, and point to the exact ITU document
and section numbers you're referring to below.

In any case, I think what you're referring to below occurs
within a node (or a small collection of nodes), whereas what we're
discussing
is network-wide notification.

One of the ITU experts can probably enlighten us further, and correct
me if I'm wrong.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of rick king
> Sent: Thursday, June 19, 2003 2:13 AM
> To: [email-masked]; Roberto Albanese; [email-masked]
> Subject: RE: Flooding using LMP extensions
>
>
> My two cents:
>
> With ITU-T glossary, I think LRM(Link Resource Manager) will
> detect the link fault ,
> and then notifies the RC(Routing Control) to update the RDB.
>
> rick
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Vishal Sharma
> Sent: Thursday, June 19, 2003 1:36 PM
> To: Roberto Albanese; [email-masked]
> Subject: RE: Flooding using LMP extensions
>
>
> Hi Roberto and Nicola,
>
> Thanks very much for your observations and for your detailed
> analysis of the issues.
>
> I certainly share your view that a flooding-based solution to fault
> notification can present several advantages, and is one that we should
> consider as a candidate (together with the signaling-based solutions
> proposed
> so far).
>
> 1) In that regard, it would be nice to get your inputs on draft-rabbat:
> http://www.ietf.org/internet-drafts/draft-rabbat-fault-notificatio
> n-protocol
> -02.txt
> since the mechanisms proposed there are technology, protocol, and topology
> agnostic.
> Do you, for instance, agree with the basic proposal in there? Do you
> have any feedback, additions, or suggestions, based on your experience of
> building your MPLS testbed?
>
> 2) On that note, I was wondering if you'd already made the modifications
> to OSPF that you discussed in your email, and if you have any
> performance results you might be able to share with the WG.
> (Richard in one of his earlier emails, I believe, mentioned that he
> has some prototyping results on LMP performance.)
>
> 3) Finally, here are some points that I'd like to discuss related to
> the issues highlighted in your email.
>
>  i) I wanted to add that not only could flooding minimize routing failure
>     probability (as you've observed), it could also speed up recovery
>     by notifying (in parallel)
>     the nodes on multiple recovery paths affected by a given
> fault. This can
>     prove very advantageous when a link carries a large number of
>     transport circuits (e.g. lambdas), and when the LSPs do not share the
>     same s-d pairs.
>
>  ii) In regard to the argument for using OSPF to obtain a solution that
> works
>      both for MPLS and GMPLS, my thought is that this is not
> critical, since
>      the recovery methods (e.g. fast reroute) at the MPLS layer
> are already
>      well-defined and are not common with the recovery methods used at the
>      transport layer. Thus, there is less of a need to have a
> solution that
>      works across layers of the network using MPLS and GMPLS,
> respectively.
>      On the contrary, the "cost" of trying to incorporate the fault
> notification
>      functionality in a routing protocol, like OSPF, an be heavy (as I
> explain below).
>
>  iii) This is because one has to develop solutions for multiple routing
> protocols
>      (as not everyone will use OSPF). More importantly, a service provider
> not
>       normally running a routing protocol at the transport layer
> (but using
> LMP
>       and GMPLS signaling), would be forced to run a routing protocol just
> for
>       efficient fault notification! That seems like an undue burden.
>       Furthermore, unlike LMP, OSPF requires more involved processing,
> making it
>       difficult to ensure that the failure-related messages are always
> processed
>       and dispatched _before_ other OSPF messages.
>
>       Also, irrespective of whether a provider runs routing, it is likely
> that
>       a GMPLS-control plane at the transport layer will at least run LMP,
> thus
>       making it a natural choice to extend for flooding-based fault
> notification.
>
>       Of course, I welcome service provider inputs on this issue, and they
>       can correct me if I'm wrong. :-)
>
>
>  iv) And finally, it appears that you are inserting the timer
> functionality
> and
>      initial detection functionality in LMP anyway, so in the
> light of (iii)
> above,
>      wouldn't it be easier just to extend LMP. (With regard to
> the argument
> of OSPF
>      flooding being mature, perhaps we can learn from the lessons
> there, and
> not
>      repeat the same mistakes when operating LMP. :-)).
>
> Best regards,
> -Vishal
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Roberto Albanese
> Sent: Tuesday, June 17, 2003 10:50 AM
> To: [email-masked]
> Subject: Re: Flooding using LMP extensions
>
>
> Hi all,
> we are working to a MPLS testbed supporting end-to-end
> Protection-Restoration mechanisms and we faced the problem of
> link-failures notification.
> We share the scalability concerns of RSVP-like
> solutions reported in the Rabbat's mail.
> We are in favour of OSPF flooding-based mechanisms for link-failures
> using Opaque because:
>
> -  applicable to both MPLS-TE - GMPLS.
>
> -  Proved OSPF protocol stability and robustness with respect to the LMP
> solution.
>    OSPF flooding in general is mature, instead LMP has to be extended
>    and it has to support some OSPF capabilities we already have.
>
> -  Reduction of routing failure probability respect to the use of
> RSVP (see
> below).
>       In draft-katz-yeung-ospf-traffic-09 it is written that in a TE
> scenario
>       we can have a module in the edge nodes that searches constrained
> routes
>       based on Opaque TE info.
>       We call a "routing failure" the computation by edge node X of a path
>       which includes a failed link F.
>       Clearly, routing failures are a consequence of lack of notification,
>       to X, of the failure of F.
>       With RSVP failure notification, this can occur:
>       -  in case of single fault, when there are no LSPs originated from X
> crossing F;
>       -  in case of dual faults (i.e., two links L1 and L2 fails almost
> simultaneously),
>          if from X there is a LSP crossing both L1 and L2:
>
>   X---link-----node------link(L1)------node-------link(L2)-----egress_node
>
>       the failure of L1 can hide the notification of L2 failures.
>
>       It can be seen that with OSPF flooding, there is virtually no
> potential
>       routing failure at all, as ALL the edge nodes are notified any
> failure.
>
>       So if we have a flooding-based notification, all the edge nodes in a
> network
>       will be aware about the failure. Instead, with RSVP, we'll have
>       only some nodes aware of the failure! So we have an increasing of
>       routing failure probability after a link failure.
>
> We agree that a major drawback of the OSPF-flooding solution is
> the need of
> revisiting
> the timers, as pointed out in the Rabbat's mail:"Flooding using LMP
> extensions".
> In fact we can't wait for a max period of MinLSInterval seconds
> to notify a
> failure...
> So we have to modify something.
>
> Among the possible solutions:
>
> 1)  Introduction of a new timer in OSPF for a new sub-TLV
>     used to carry the info of broken link.
>     The current timer of MinLSInterval should not consider
>     this new field.
>
> 2)  Force the flooding when a link failure signal arrives
>     and reset the timer.
>
> We think that the 2) solution has more advantages.
> The current behavior of the OSPF protocol is (considering Opaque
> extensions):
>
>        <----------------MinLSInterval------------->
>
>     B1 |             B2 |   B3 |    FAIL. |
>        |                |      |          |
>     ---+----------------+------+----------+-------+------------> time
>        |                                          |
>        |                                          |
>      FL1                                        FL2
>
>    WHERE:
>
> -  FL1 is a flooding of B1 information.
> -  FL2 is a flooding of B3 + FAIL. information.
> -  FAIL. could be a signal coming from a failure detection mechanism
>    (i.e. from lower layer).
> -  B1, B2, B3, FAIL. are external OSPF Opaque inputs.
>    Note that B1, B2, B3 could be Bandwidth updates (link TLVs updates).
>
> We thought to solve in this way:
>
>                                   <-------------MinLSInterval--------->
>       <-------------MinLSInterval------>
>
>    B1 |        B2 |   B3 |   FAIL.|
>       |           |      |        |
>
> ---+-----------+------+--------+-----------------------------------------
> ->
>       |                           |                                   time
>       |                           |
>      FL1                        FL2
>
> In this case we force the flooding (FL2) when arrives a signal of
> link-failure (FAIL.) and we reset the MinLSInterval timer so that
> it restarts from the failure event.
>
> To enforce the robustness of this solution, and to avoid
> continous flooding
> of
> failure notifications in case of interface flapping,  we have to
> consider a
> timer in the module (external to OSPF) that detects the link-failures and
> triggers the flooding of FL2 Opaque LSA.
>
> Consider that some external module is needed to trigger the OSPF flooding
> of failure notification, as we can not rely on the HELLO process for its
> long detection delay.
> A possibility is to let LMP to detect the failure and trigger the OSPF
> flooding.
>
> In this approach, the timer to avoid interface-flapping should be included
> in the LMP trigger.
> This solution is conservative in that it only requires LMP extensions
> (timer in the trigger) and just a minor modification to the OSPF process
> (i.e., accept a force-to-send and  MinLSInterval-reset trigger).
>
>
> Thanks in advance for your kind observations.
>
> Regards
>
> Roberto Albanese, Nicola Caione
> University of Rome - La Sapienza, Italy
>
>
>

Delivery-date: Thu, 19 Jun 2003 09:14:54 +0000
From: "rick king" <[email-masked]>
To: <[email-masked]>, "Roberto Albanese" <[email-masked]>, <[email-masked]>
Subject: RE: Flooding using LMP extensions 
Date: Thu, 19 Jun 2003 17:12:48 +0800

Delivery-date: Thu, 19 Jun 2003 05:38:46 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Roberto Albanese" <[email-masked]>, <[email-masked]>
Subject: RE: Flooding using LMP extensions 
Date: Wed, 18 Jun 2003 22:36:20 -0700

Hi Roberto and Nicola,

Thanks very much for your observations and for your detailed
analysis of the issues.

I certainly share your view that a flooding-based solution to fault
notification can present several advantages, and is one that we should
consider as a candidate (together with the signaling-based solutions
proposed
so far).

1) In that regard, it would be nice to get your inputs on draft-rabbat:
http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol
-02.txt
since the mechanisms proposed there are technology, protocol, and topology
agnostic.
Do you, for instance, agree with the basic proposal in there? Do you
have any feedback, additions, or suggestions, based on your experience of
building your MPLS testbed?

2) On that note, I was wondering if you'd already made the modifications
to OSPF that you discussed in your email, and if you have any
performance results you might be able to share with the WG.
(Richard in one of his earlier emails, I believe, mentioned that he
has some prototyping results on LMP performance.)

3) Finally, here are some points that I'd like to discuss related to
the issues highlighted in your email.

 i) I wanted to add that not only could flooding minimize routing failure
    probability (as you've observed), it could also speed up recovery
    by notifying (in parallel)
    the nodes on multiple recovery paths affected by a given fault. This can
    prove very advantageous when a link carries a large number of
    transport circuits (e.g. lambdas), and when the LSPs do not share the
    same s-d pairs.

 ii) In regard to the argument for using OSPF to obtain a solution that
works
     both for MPLS and GMPLS, my thought is that this is not critical, since
     the recovery methods (e.g. fast reroute) at the MPLS layer are already
     well-defined and are not common with the recovery methods used at the
     transport layer. Thus, there is less of a need to have a solution that
     works across layers of the network using MPLS and GMPLS, respectively.
     On the contrary, the "cost" of trying to incorporate the fault
notification
     functionality in a routing protocol, like OSPF, an be heavy (as I
explain below).

 iii) This is because one has to develop solutions for multiple routing
protocols
     (as not everyone will use OSPF). More importantly, a service provider
not
      normally running a routing protocol at the transport layer (but using
LMP
      and GMPLS signaling), would be forced to run a routing protocol just
for
      efficient fault notification! That seems like an undue burden.
      Furthermore, unlike LMP, OSPF requires more involved processing,
making it
      difficult to ensure that the failure-related messages are always
processed
      and dispatched _before_ other OSPF messages.

      Also, irrespective of whether a provider runs routing, it is likely
that
      a GMPLS-control plane at the transport layer will at least run LMP,
thus
      making it a natural choice to extend for flooding-based fault
notification.

      Of course, I welcome service provider inputs on this issue, and they
      can correct me if I'm wrong. :-)

 iv) And finally, it appears that you are inserting the timer functionality
and
     initial detection functionality in LMP anyway, so in the light of (iii)
above,
     wouldn't it be easier just to extend LMP. (With regard to the argument
of OSPF
     flooding being mature, perhaps we can learn from the lessons there, and
not
     repeat the same mistakes when operating LMP. :-)).

Best regards,
-Vishal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Roberto Albanese
Sent: Tuesday, June 17, 2003 10:50 AM
To: [email-masked]
Subject: Re: Flooding using LMP extensions

Hi all,
we are working to a MPLS testbed supporting end-to-end
Protection-Restoration mechanisms and we faced the problem of
link-failures notification.
We share the scalability concerns of RSVP-like
solutions reported in the Rabbat's mail.
We are in favour of OSPF flooding-based mechanisms for link-failures
using Opaque because:

-  applicable to both MPLS-TE - GMPLS.

-  Proved OSPF protocol stability and robustness with respect to the LMP
solution.
   OSPF flooding in general is mature, instead LMP has to be extended
   and it has to support some OSPF capabilities we already have.

-  Reduction of routing failure probability respect to the use of RSVP (see
below).
      In draft-katz-yeung-ospf-traffic-09 it is written that in a TE
scenario
      we can have a module in the edge nodes that searches constrained
routes
      based on Opaque TE info.
      We call a "routing failure" the computation by edge node X of a path
      which includes a failed link F.
      Clearly, routing failures are a consequence of lack of notification,
      to X, of the failure of F.
      With RSVP failure notification, this can occur:
      -  in case of single fault, when there are no LSPs originated from X
crossing F;
      -  in case of dual faults (i.e., two links L1 and L2 fails almost
simultaneously),
         if from X there is a LSP crossing both L1 and L2:

  X---link-----node------link(L1)------node-------link(L2)-----egress_node

      the failure of L1 can hide the notification of L2 failures.

      It can be seen that with OSPF flooding, there is virtually no
potential
      routing failure at all, as ALL the edge nodes are notified any
failure.

      So if we have a flooding-based notification, all the edge nodes in a
network
      will be aware about the failure. Instead, with RSVP, we'll have
      only some nodes aware of the failure! So we have an increasing of
      routing failure probability after a link failure.

We agree that a major drawback of the OSPF-flooding solution is the need of
revisiting
the timers, as pointed out in the Rabbat's mail:"Flooding using LMP
extensions".
In fact we can't wait for a max period of MinLSInterval seconds to notify a
failure...
So we have to modify something.

Among the possible solutions:

1)  Introduction of a new timer in OSPF for a new sub-TLV
    used to carry the info of broken link.
    The current timer of MinLSInterval should not consider
    this new field.

2)  Force the flooding when a link failure signal arrives
    and reset the timer.

We think that the 2) solution has more advantages.
The current behavior of the OSPF protocol is (considering Opaque
extensions):

       <----------------MinLSInterval------------->

    B1 |             B2 |   B3 |    FAIL. |
       |                |      |          |
    ---+----------------+------+----------+-------+------------> time
       |                                          |
       |                                          |
     FL1                                        FL2

   WHERE:

-  FL1 is a flooding of B1 information.
-  FL2 is a flooding of B3 + FAIL. information.
-  FAIL. could be a signal coming from a failure detection mechanism
   (i.e. from lower layer).
-  B1, B2, B3, FAIL. are external OSPF Opaque inputs.
   Note that B1, B2, B3 could be Bandwidth updates (link TLVs updates).

We thought to solve in this way:

                                  <-------------MinLSInterval--------->
      <-------------MinLSInterval------>

   B1 |        B2 |   B3 |   FAIL.|
      |           |      |        |
   ---+-----------+------+--------+-----------------------------------------
->
      |                           |                                   time
      |                           |
     FL1                        FL2

In this case we force the flooding (FL2) when arrives a signal of
link-failure (FAIL.) and we reset the MinLSInterval timer so that
it restarts from the failure event.

To enforce the robustness of this solution, and to avoid continous flooding
of
failure notifications in case of interface flapping,  we have to consider a
timer in the module (external to OSPF) that detects the link-failures and
triggers the flooding of FL2 Opaque LSA.

Consider that some external module is needed to trigger the OSPF flooding
of failure notification, as we can not rely on the HELLO process for its
long detection delay.
A possibility is to let LMP to detect the failure and trigger the OSPF
flooding.

In this approach, the timer to avoid interface-flapping should be included
in the LMP trigger.
This solution is conservative in that it only requires LMP extensions
(timer in the trigger) and just a minor modification to the OSPF process
(i.e., accept a force-to-send and  MinLSInterval-reset trigger).

Thanks in advance for your kind observations.

Regards

Roberto Albanese, Nicola Caione
University of Rome - La Sapienza, Italy

Delivery-date: Wed, 18 Jun 2003 21:57:54 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Roberto Albanese'" <[email-masked]>, <[email-masked]>
Subject: RE: Flooding using LMP extensions 
Date: Wed, 18 Jun 2003 14:55:15 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C335A9.A10AA380
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Roberto and Nicola,=20

=20

Since the Fault Notification Protocol
(draft-rabbat-fault-notification-protocol) is implementation-agnostic, =
do
you agree with it or have any comments that we can add to it? Thanks in
advance.

=20

w/r to the comments and questions that you sent, please see in-lined
comments below.

=20

Thanks.

=20

=20

> Hi all,

> we are working to a MPLS testbed supporting end-to-end

> Protection-Restoration mechanisms and we faced the problem of

> link-failures notification.

> We share the scalability concerns of RSVP-like

> solutions reported in the Rabbat's mail.

=20

Thanks for the support. We do believe that flooding is a more scalable

approach and is a way (if not the way) to go.

=20

> We are in favour of OSPF flooding-based mechanisms for link-failures =20

> using Opaque because:

> =20

> -  applicable to both MPLS-TE - GMPLS.

=20

While it is true that OSPF may be applicable to both MPLS

and GMPLS,  I'm not sure that the MPLS community would want to replace =
or

include another option besides Fast Reroute.

=20

=20

> -  Proved OSPF protocol stability and robustness with respect to the =
LMP=20

> solution.

>    OSPF flooding in general is mature, instead LMP has to be extended

>    and it has to support some OSPF capabilities we already have.

> =20

=20

I agree that OSPF flooding is more mature; the changes that you are

proposing to OSPF are substantial, so, they may reduce stability.

=20

> -  Reduction of routing failure probability respect to the use of RSVP =

> (see below).

=20

We agree with this point. Since it applies to any flooding-based

solution, it does apply to our LMP solution as well. Good point.

=20

>       In draft-katz-yeung-ospf-traffic-09 it is written that in a TE=20

> scenario

>       we can have a module in the edge nodes that searches constrained

>       routes based on Opaque TE info.

>       We call a "routing failure" the computation by edge node X of a =
path

>       which includes a failed link F.

>       Clearly, routing failures are a consequence of lack of =
notification,

>       to X, of the failure of F.

>       With RSVP failure notification, this can occur:

>       -  in case of single fault, when there are no LSPs originated =
from X

> crossing F;

>       -  in case of dual faults (i.e., two links L1 and L2 fails =
almost=20

> simultaneously),

>          if from X there is a LSP crossing both L1 and L2:

> =20

>   =
X---link-----node------link(L1)------node-------link(L2)-----egress_node

=20

>       the failure of L1 can hide the notification of L2 failures.

=20

>       It can be seen that with OSPF flooding, there is virtually no

>  potential

>       routing failure at all, as ALL the edge nodes are notified any=20

> failure.

=20

Again agreed that this shows the advantage of flooding vs. signaling.

Thanks for the example.

=20

>       So if we have a flooding-based notification, all the edge nodes =
in a

=20

> network

>       will be aware about the failure. Instead, with RSVP, we'll have

>       only some nodes aware of the failure! So we have an increasing =
of

>       routing failure probability after a link failure.

=20

> We agree that a major drawback of the OSPF-flooding solution is the =
need=20

> of revisiting the timers, as pointed out in the Rabbat's =
mail:"Flooding=20

> using LMP extensions".

> In fact we can't wait for a max period of MinLSInterval seconds to =
notify

> a failure...

> So we have to modify something.

> =20

> Among the possible solutions:

> =20

> 1)  Introduction of a new timer in OSPF for a new sub-TLV

>     used to carry the info of broken link.

>     The current timer of MinLSInterval should not consider

>     this new field.

> =20

> 2)  Force the flooding when a link failure signal arrives

>     and reset the timer.

> =20

> We think that the 2) solution has more advantages.

> The current behavior of the OSPF protocol is (considering Opaque=20

> extensions):

> =20

>        <----------------MinLSInterval------------->

> =20

>     B1 |             B2 |   B3 |    FAIL. |

>        |                |      |          |

>     ---+----------------+------+----------+-------+------------> time

>        |                                          |

>        |                                          |

>      FL1                                        FL2

> =20

>    WHERE:

> =20

> -  FL1 is a flooding of B1 information.

> -  FL2 is a flooding of B3 + FAIL. information.

> -  FAIL. could be a signal coming from a failure detection mechanism

>    (i.e. from lower layer).

> -  B1, B2, B3, FAIL. are external OSPF Opaque inputs.

>    Note that B1, B2, B3 could be Bandwidth updates (link TLVs =
updates).

> =20

> We thought to solve in this way:

=20

>                                   =
<-------------MinLSInterval--------->

>       <-------------MinLSInterval------>

> =20

>    B1 |        B2 |   B3 |   FAIL.|

>       |           |      |        |

>

---+-----------+------+--------+-----------------------------------------=
->

>       |                           |                                   =
time

>       |                           |

>      FL1                        FL2

> =20

> In this case we force the flooding (FL2) when arrives a signal of

> link-failure (FAIL.) and we reset the MinLSInterval timer so that

> it restarts from the failure event.

=20

I think this makes sense when using OSPF Opaque LSA's. One issue is the =
need

to make sure that when you get all these flooding messages, you process =
the

failure-related messages first, then go on to looking at B1, B2, B3. =20

This makes it quite cumbersome to create the Opaque LSA and=20

requires that one enforce that the node process FAIL before the Bi's.

This isn't particularly easy to ensure, especially when using

different platforms.

=20

=20

> To enforce the robustness of this solution, and to avoid continous=20

> flooding of failure notifications in case of interface flapping,  we =
have=20

> to consider atimer in the module (external to OSPF) that detects the=20

> link-failures and triggers the flooding of FL2 Opaque LSA.

>=20

> Consider that some external module is needed to trigger the OSPF =
flooding=20

> of failure notification, as we can not rely on the HELLO process for =
its=20

> long detection delay.

> A possibility is to let LMP to detect the failure and trigger the OSPF =

> flooding.

>=20

> In this approach, the timer to avoid interface-flapping should be =
included

> in the LMP trigger.

> This solution is conservative in that it only requires LMP extensions

> (timer in the trigger) and just a minor modification to the OSPF =
process

> (i.e., accept a force-to-send and  MinLSInterval-reset trigger).

>

=20

There remains the concern of finding a similar solution for IS/IS, thus

duplicating the work in order to allow its use.

In addition, you could be in a situation where a routing protocol

is not run at all, and routes are all predetermined, so one would=20

have to run OSPF just to achieve this functionality?=20

=20

Note, however, that in a GMPLS-based transport network, it is expected

that LMP would be running anyway (for the several other functions it

performs), so that was our first choice.

Furthermore, even after modifications, we believe the LMP-based solution

is lightweight compared to burdening OSPF with this functionality.

=20

But to go back to the main point, it sounds like the Opaque LSA that you =
are

proposing is in the end very similar to our LMP approach.

=20

What is the feeling of the rest of the CCAMP community members at large?

=20

Best,

Richard

=20

>

> Thanks in advance for your kind observations.

> =20

> Regards

> =20

> Roberto Albanese, Nicola Caione

> University of Rome - La Sapienza, Italy

=20

------=_NextPart_000_0017_01C335A9.A10AA380
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">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* 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:purple;
	text-decoration:underline;}
span.EmailStyle17
	{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 bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Roberto and Nicola, =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Since the Fault Notification =
Protocol (draft-rabbat-fault-notification-protocol)
is implementation-agnostic, do you agree with it or have any comments =
that we
can add to it? Thanks in advance.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>w/r to the comments and questions =
that you
sent, please see in-lined comments below.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; Hi all,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; we are working to a MPLS =
testbed
supporting end-to-end</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; Protection-Restoration =
mechanisms and
we faced the problem of</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; link-failures =
notification.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; We share the scalability =
concerns of
RSVP-like</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; solutions reported in the =
Rabbat's
mail.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for the support. We do =
believe that
flooding is a more scalable</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>approach and is a way (if not the =
way) to
go.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; We are in favour of OSPF
flooding-based mechanisms for link-failures&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; using Opaque =
because:</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; -&nbsp; applicable to both =
MPLS-TE -
GMPLS.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>While it is true that OSPF may be
applicable to both MPLS</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>and GMPLS,&nbsp; I'm not sure that =
the
MPLS community would want to replace or</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>include another option besides Fast
Reroute.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; -&nbsp; Proved OSPF protocol
stability and robustness with respect to the LMP </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; solution.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp; OSPF =
flooding in
general is mature, instead LMP has to be extended</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp; and it has =
to
support some OSPF capabilities we already have.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree that OSPF flooding is more =
mature;
the changes that you are</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>proposing to OSPF are substantial, =
so,
they may reduce stability.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; -&nbsp; Reduction of routing =
failure
probability respect to the use of RSVP </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; (see below).</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>We agree with this point. Since it =
applies
to any flooding-based</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>solution, it does apply to our LMP
solution as well. Good point.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
In draft-katz-yeung-ospf-traffic-09 it is written that in a TE =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; scenario</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; we
can have a module in the edge nodes that searches =
constrained</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DFR
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
routes based on Opaque TE info.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
We call a &quot;routing failure&quot; the computation by edge node X of =
a path</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; which
includes a failed link F.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
Clearly, routing failures are a consequence of lack of =
notification,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; to
X, of the failure of F.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
With RSVP failure notification, this can occur:</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; -&nbsp;
in case of single fault, when there are no LSPs originated from =
X</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; crossing F;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; -&nbsp;
in case of dual faults (i.e., two links L1 and L2 fails almost =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; =
simultaneously),</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;
if from X there is a LSP crossing both L1 and L2:</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp; =
X---link-----node------link(L1)------node-------link(L2)-----egress_node<=
/span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; the
failure of L1 can hide the notification of L2 =
failures.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
It can be seen that with OSPF flooding, there is virtually =
no</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; =
potential</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
routing failure at all, as ALL the edge nodes are notified any =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; failure.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Again agreed that this shows the =
advantage
of flooding vs. signaling.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for the =
example.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
So if we have a flooding-based notification, all the edge nodes in =
a</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; network</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
will be aware about the failure. Instead, with RSVP, we'll =
have</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; only
some nodes aware of the failure! So we have an increasing =
of</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
routing failure probability after a link failure.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; We agree that a major drawback =
of the
OSPF-flooding solution is the need </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; of revisiting the timers, as =
pointed
out in the Rabbat's mail:&quot;Flooding </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; using LMP =
extensions&quot;.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; In fact we can't wait for a =
max
period of MinLSInterval seconds to notify</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; a failure...</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; So we have to modify =
something.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; Among the possible =
solutions:</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; 1)&nbsp; Introduction of a new =
timer
in OSPF for a new sub-TLV</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; used =
to carry
the info of broken link.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The =
current
timer of MinLSInterval should not consider</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; this =
new
field.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; 2)&nbsp; Force the flooding =
when a
link failure signal arrives</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; and =
reset the
timer.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; We think that the 2) solution =
has
more advantages.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; The current behavior of the =
OSPF
protocol is (considering Opaque </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DFR
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&gt; =
extensions):</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DFR
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DFR
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;----------------MinLSInterval-------------&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DFR
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DFR
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&=
nbsp;&nbsp;
B1 =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 B2
|&nbsp;&nbsp; B3 |&nbsp;&nbsp;&nbsp; FAIL. </span></font><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>|</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&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; =
|</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
---+----------------+------+----------+-------+------------&gt; =
time</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&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;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&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;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FL1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&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;FL2</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp; =
WHERE:</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; -&nbsp; FL1 is a flooding of =
B1
information.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; -&nbsp; FL2 is a flooding of =
B3 +
FAIL. information.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; -&nbsp; FAIL. could be a =
signal
coming from a failure detection mechanism</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp; (i.e. from =
lower
layer).</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; -&nbsp; B1, B2, B3, FAIL. are =
external
OSPF Opaque inputs.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp; Note that =
B1, B2,
B3 could be Bandwidth updates (link TLVs updates).</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; We thought to solve in this =
way:</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;-------------MinLSInterval---------&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
&lt;-------------MinLSInterval------&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp; B1
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2 |&nbsp;&nbsp; B3 =
|&nbsp;&nbsp;
FAIL.|</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>---+-----------+------+--------+----=
--------------------------------------&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
|&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;time</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;
|&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;
|</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FL1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FL2</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; In this case we force the =
flooding
(FL2) when arrives a signal of</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; link-failure (FAIL.) and we =
reset the
MinLSInterval timer so that</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; it restarts from the failure =
event.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I think this makes sense when using =
OSPF
Opaque LSA's. One issue is the need</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>to make sure that when you get all =
these
flooding messages, you process the</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>failure-related messages first, =
then go on
to looking at B1, B2, B3.&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>This makes it quite cumbersome to =
create
the Opaque LSA and </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>requires that one enforce that the =
node
process FAIL before the Bi's.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>This isn't particularly easy to =
ensure,
especially when using</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>different =
platforms.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; To enforce the robustness of =
this
solution, and to avoid continous </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; flooding of failure =
notifications in
case of interface flapping,&nbsp; we have </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; to consider atimer in the =
module
(external to OSPF) that detects the </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; link-failures and triggers the
flooding of FL2 Opaque LSA.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; Consider that some external =
module is
needed to trigger the OSPF flooding </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; of failure notification, as we =
can
not rely on the HELLO process for its </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; long detection =
delay.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; A possibility is to let LMP to =
detect
the failure and trigger the OSPF </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; flooding.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; In this approach, the timer to =
avoid
interface-flapping should be included</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; in the LMP =
trigger.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; This solution is conservative =
in that
it only requires LMP extensions</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; (timer in the trigger) and =
just a
minor modification to the OSPF process</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; (i.e., accept a force-to-send =
and&nbsp;
MinLSInterval-reset trigger).</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There remains the concern of =
finding a
similar solution for IS/IS, thus</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>duplicating the work in order to =
allow its
use.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In addition, you could be in a =
situation
where a routing protocol</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>is not run at all, and routes are =
all
predetermined, so one would </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>have to run OSPF just to achieve =
this
functionality? </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Note, however, that in a =
GMPLS-based
transport network, it is expected</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>that LMP would be running anyway =
(for the
several other functions it</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>performs), so that was our first =
choice.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Furthermore, even after =
modifications, we
believe the LMP-based solution</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>is lightweight compared to =
burdening OSPF
with this functionality.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>But to go back to the main point, =
it
sounds like the Opaque LSA that you are</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>proposing is in the end very =
similar to
our LMP approach.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>What is the feeling of the rest of =
the
CCAMP community members at large?</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Best,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Richard</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; Thanks in advance for your =
kind
observations.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; Regards</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt;&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; </span></font><font size=3D2
 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
 color:navy'>Roberto Albanese</span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>, Nicola =
Caione</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; </span></font><font size=3D2
  color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>University</span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
 style=3D'font-size:10.0pt;font-family:Arial;color:navy'> of =
</span></font><font
  size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Rome</span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'> - La =
</span></font><font
  size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Sapienza</span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
 style=3D'font-size:10.0pt;font-family:Arial;color:navy'>, =
</span></font><font
  size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Italy</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0017_01C335A9.A10AA380--

Delivery-date: Tue, 17 Jun 2003 17:55:38 +0000
From: "Roberto Albanese" <[email-masked]>
To: <[email-masked]>
Subject: Re: Flooding using LMP extensions 
Date: Tue, 17 Jun 2003 19:50:19 +0200

This is a multi-part message in MIME format.

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

Hi all,
we are working to a MPLS testbed supporting end-to-end
Protection-Restoration mechanisms and we faced the problem of
link-failures notification.
We share the scalability concerns of RSVP-like
solutions reported in the Rabbat's mail.
We are in favour of OSPF flooding-based mechanisms for link-failures =20
using Opaque because:

-  applicable to both MPLS-TE - GMPLS.

-  Proved OSPF protocol stability and robustness with respect to the LMP =
solution.
   OSPF flooding in general is mature, instead LMP has to be extended
   and it has to support some OSPF capabilities we already have.

-  Reduction of routing failure probability respect to the use of RSVP =
(see below).
      In draft-katz-yeung-ospf-traffic-09 it is written that in a TE =
scenario
      we can have a module in the edge nodes that searches constrained =
routes
      based on Opaque TE info.
      We call a "routing failure" the computation by edge node X of a =
path
      which includes a failed link F.
      Clearly, routing failures are a consequence of lack of =
notification,
      to X, of the failure of F.
      With RSVP failure notification, this can occur:
      -  in case of single fault, when there are no LSPs originated from =
X crossing F;
      -  in case of dual faults (i.e., two links L1 and L2 fails almost =
simultaneously),
         if from X there is a LSP crossing both L1 and L2:

  =
X---link-----node------link(L1)------node-------link(L2)-----egress_node

      the failure of L1 can hide the notification of L2 failures.

      It can be seen that with OSPF flooding, there is virtually no =
potential
      routing failure at all, as ALL the edge nodes are notified any =
failure.

      So if we have a flooding-based notification, all the edge nodes in =
a network
      will be aware about the failure. Instead, with RSVP, we'll have
      only some nodes aware of the failure! So we have an increasing of
      routing failure probability after a link failure.

We agree that a major drawback of the OSPF-flooding solution is the need =
of revisiting
the timers, as pointed out in the Rabbat's mail:"Flooding using LMP =
extensions".
In fact we can't wait for a max period of MinLSInterval seconds to =
notify a failure...
So we have to modify something.

Among the possible solutions:

1)  Introduction of a new timer in OSPF for a new sub-TLV
    used to carry the info of broken link.
    The current timer of MinLSInterval should not consider
    this new field.

2)  Force the flooding when a link failure signal arrives
    and reset the timer.

We think that the 2) solution has more advantages.
The current behavior of the OSPF protocol is (considering Opaque =
extensions):

       <----------------MinLSInterval------------->

    B1 |             B2 |   B3 |    FAIL. |
       |                |      |          |
    ---+----------------+------+----------+-------+------------> time
       |                                          |
       |                                          |
     FL1                                        FL2

   WHERE:

-  FL1 is a flooding of B1 information.
-  FL2 is a flooding of B3 + FAIL. information.
-  FAIL. could be a signal coming from a failure detection mechanism
   (i.e. from lower layer).
-  B1, B2, B3, FAIL. are external OSPF Opaque inputs.
   Note that B1, B2, B3 could be Bandwidth updates (link TLVs updates).

We thought to solve in this way:

                                  <-------------MinLSInterval--------->
      <-------------MinLSInterval------>

   B1 |        B2 |   B3 |   FAIL.|
      |           |      |        |
   =
---+-----------+------+--------+-----------------------------------------=
->
      |                           |                                   =
time
      |                           |
     FL1                        FL2

In this case we force the flooding (FL2) when arrives a signal of
link-failure (FAIL.) and we reset the MinLSInterval timer so that
it restarts from the failure event.

To enforce the robustness of this solution, and to avoid continous =
flooding of=20
failure notifications in case of interface flapping,  we have to =
consider a
timer in the module (external to OSPF) that detects the link-failures =
and=20
triggers the flooding of FL2 Opaque LSA.

Consider that some external module is needed to trigger the OSPF =
flooding=20
of failure notification, as we can not rely on the HELLO process for its =
long detection delay.
A possibility is to let LMP to detect the failure and trigger the OSPF =
flooding.

In this approach, the timer to avoid interface-flapping should be =
included in the LMP trigger.
This solution is conservative in that it only requires LMP extensions
(timer in the trigger) and just a minor modification to the OSPF process
(i.e., accept a force-to-send and  MinLSInterval-reset trigger).

Thanks in advance for your kind observations.

Regards

Roberto Albanese, Nicola Caione
University of Rome - La Sapienza, Italy

------=_NextPart_000_004B_01C33509.AEB0B560
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.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2>Hi all,<BR>we are working to a =
MPLS testbed=20
supporting end-to-end<BR>Protection-Restoration mechanisms and we faced =
the=20
problem of<BR>link-failures notification.<BR>We share the scalability =
concerns=20
of RSVP-like<BR>solutions reported in the Rabbat's mail.<BR>We are in =
favour of=20
OSPF flooding-based mechanisms for link-failures&nbsp; <BR>using Opaque=20
because:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>-&nbsp; applicable to both =
MPLS-TE -=20
GMPLS.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>-&nbsp; Proved OSPF protocol =
stability and=20
robustness with respect to the LMP solution.<BR>&nbsp;&nbsp; OSPF =
flooding in=20
general is mature, instead LMP has to be extended<BR>&nbsp;&nbsp; and it =
has to=20
support some OSPF capabilities we already have.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>-&nbsp; Reduction of routing =
failure=20
probability respect to the use of RSVP (see=20
below).<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In =
draft-katz-yeung-ospf-traffic-09 it=20
is written that in a TE scenario<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we =
can have a=20
module in the edge nodes that searches constrained=20
routes<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; based on Opaque TE=20
info.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We call a "routing failure" the=20
computation by edge node X of a path<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
which=20
includes a failed link F.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Clearly, =
routing=20
failures are a consequence of lack of=20
notification,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to X, of the failure of=20
F.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; With RSVP failure notification, =
this can=20
occur:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp; in case of single =
fault, when=20
there are no LSPs originated from X crossing=20
F;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp; in case of dual faults =
(i.e., two=20
links L1 and L2 fails almost=20
simultaneously),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if =
from X=20
there is a LSP crossing both L1 and L2:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;=20
X---link-----node------link(L1)------node-------link(L2)-----egress_node<=
/FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
the failure=20
of L1 can hide the notification of L2 failures.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
It can be=20
seen that with OSPF flooding, there is virtually no=20
potential<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; routing failure at all, as =
ALL the=20
edge nodes are notified any failure.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
So if we=20
have a flooding-based notification, all the edge nodes in a=20
network<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will be aware about the =
failure.=20
Instead, with RSVP, we'll have<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; only =
some nodes=20
aware of the failure! So we have an increasing=20
of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; routing failure probability after a =
link=20
failure.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>We agree that a major drawback =
of the=20
OSPF-flooding solution is the need of revisiting<BR>the timers, as =
pointed out=20
in the Rabbat's mail:"Flooding using LMP extensions".<BR>In fact we =
can't wait=20
for a max period of MinLSInterval seconds to notify a failure...<BR>So =
we have=20
to modify something.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Among the possible =
solutions:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>1)&nbsp; Introduction of a new =
timer in=20
OSPF for a new sub-TLV<BR>&nbsp;&nbsp;&nbsp; used to carry the info of =
broken=20
link.<BR>&nbsp;&nbsp;&nbsp; The current timer of MinLSInterval should =
not=20
consider<BR>&nbsp;&nbsp;&nbsp; this new field.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>2)&nbsp; Force the flooding =
when a link=20
failure signal arrives<BR>&nbsp;&nbsp;&nbsp; and reset the =
timer.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>We think that the 2) solution =
has more=20
advantages.<BR>The current behavior of the OSPF protocol is (considering =
Opaque=20
extensions):</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;----------------MinLSInterval-------------&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp; B1=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 B2=20
|&nbsp;&nbsp; B3 |&nbsp;&nbsp;&nbsp; FAIL.=20
|<BR>&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;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|<BR>&nbsp;&nbsp;&nbsp;=20
---+----------------+------+----------+-------+------------&gt;=20
time<BR>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
FL1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&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;=20
FL2</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; =
WHERE:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>-&nbsp; FL1 is a flooding of B1 =

information.<BR>-&nbsp; FL2 is a flooding of B3 + FAIL. =
information.<BR>-&nbsp;=20
FAIL. could be a signal coming from a failure detection=20
mechanism<BR>&nbsp;&nbsp; (i.e. from lower layer).<BR>-&nbsp; B1, B2, =
B3, FAIL.=20
are external OSPF Opaque inputs.<BR>&nbsp;&nbsp; Note that B1, B2, B3 =
could be=20
Bandwidth updates (link TLVs updates).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>We thought to solve in this=20
way:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;-------------MinLSInterval---------&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
&lt;-------------MinLSInterval------&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; B1=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B2 |&nbsp;&nbsp; B3 =
|&nbsp;&nbsp;=20
FAIL.|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&nbsp;&nbsp;=20
---+-----------+------+--------+-----------------------------------------=
-&gt;<BR>&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
time<BR>&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;&nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
FL1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
FL2</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>In this case we force the =
flooding (FL2)=20
when arrives a signal of<BR>link-failure (FAIL.) and we reset the =
MinLSInterval=20
timer so that<BR>it restarts from the failure event.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>To enforce the robustness of =
this solution,=20
and to avoid continous flooding of <BR>failure notifications in case of=20
interface flapping,&nbsp; we have to consider a<BR>timer in the module =
(external=20
to OSPF) that detects the link-failures and <BR>triggers the flooding of =
FL2=20
Opaque LSA.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Consider that some external =
module is=20
needed to trigger the OSPF flooding <BR>of failure notification, as we =
can not=20
rely on the HELLO process for its long detection delay.<BR>A possibility =
is to=20
let LMP to detect the failure and trigger the OSPF =
flooding.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>In this approach, the timer to =
avoid=20
interface-flapping should be included in the LMP trigger.<BR>This =
solution is=20
conservative in that it only requires LMP extensions<BR>(timer in the =
trigger)=20
and just a minor modification to the OSPF process<BR>(i.e., accept a=20
force-to-send and&nbsp; MinLSInterval-reset trigger).</FONT></DIV>
<DIV>&nbsp;</DIV><FONT face=3D"Courier New" size=3D2>
<DIV><BR>Thanks in advance for your kind observations.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards</DIV>
<DIV>&nbsp;</DIV>
<DIV>Roberto Albanese, Nicola Caione<BR>University of Rome - La =
Sapienza,=20
Italy</FONT></DIV></BODY></HTML>

------=_NextPart_000_004B_01C33509.AEB0B560--

Delivery-date: Tue, 17 Jun 2003 13:04:11 +0000
Date: Tue, 17 Jun 2003 15:02:42 +0200
From: [email-masked]
Reply-To: [email-masked]
To: Diego Caviglia <[email-masked]>
CC: [email-masked]
Subject: Re: A question regarding draft-ietf-ccamp-gmpls-sonet-sdh-08

hi diego,

see in-line

Diego Caviglia wrote:
> [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>[email-masked] and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
> 
> Hi All,,
>                         could you please clarify a doubt I have about
> virtual concatenation?

see the sentence above: "In case of signal concatenation or multiplication,
a list of labels can appear in the Label field of a Generalized Label."

and since per RFC3471, Section 4.1 "An Upstream Label has the same format as
the generalized label, see Section 3.2." i think this should respond to
your second question

cw in vienna,
- dimitri.

> Quoted from the draft:
> "
> ...
>    In case of virtual concatenation, the explicit ordered list of all
>    labels in the concatenation is given. Each label indicates the
>    first time-slot occupied by a component of the virtually
>    concatenated signal. The order of the labels must reflect the
>    order of the payloads to concatenate (not the physical order of
>    time-slots). The above representation limits virtual concatenation
>    to remain within a single (component) link; it imposes as such a
>    restriction compared to the ANSI [T1.105]/ITU-T [G.707]
>    recommendations.
> ..
> "
> 
> My doubt is about where I have to put the labes.  In the Upstream Label object?
> If yes have I to use a single object header with the appropriate lenght or have I to use n objects?
> 
> Thanks in advance for your reply.
> 
> Best regards.
> 
> Diego
> 
> 
> 
> ------------------------------------------
> Diego Caviglia
> Marconi - Optical Networks
> ASTN/GMPLS - System Design Manager
> Via A. Negrone 1/A
> 16153 Genoa - Italy
> Phone: +390106003736
> 
> 
> 
> 
> 

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

Delivery-date: Tue, 17 Jun 2003 12:50:19 +0000
Sensitivity: 
Subject: A question regarding draft-ietf-ccamp-gmpls-sonet-sdh-08
To: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Tue, 17 Jun 2003 10:21:46 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi All,,
                        could you please clarify a doubt I have about
virtual concatenation?

Quoted from the draft:
"
...
   In case of virtual concatenation, the explicit ordered list of all
   labels in the concatenation is given. Each label indicates the
   first time-slot occupied by a component of the virtually
   concatenated signal. The order of the labels must reflect the
   order of the payloads to concatenate (not the physical order of
   time-slots). The above representation limits virtual concatenation
   to remain within a single (component) link; it imposes as such a
   restriction compared to the ANSI [T1.105]/ITU-T [G.707]
   recommendations.
..
"

My doubt is about where I have to put the labes.  In the Upstream Label object?
If yes have I to use a single object header with the appropriate lenght or have I to use n objects?

Thanks in advance for your reply.

Best regards.

Diego

------------------------------------------
Diego Caviglia
Marconi - Optical Networks
ASTN/GMPLS - System Design Manager
Via A. Negrone 1/A
16153 Genoa - Italy
Phone: +390106003736

Delivery-date: Tue, 17 Jun 2003 11:57:58 +0000
To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-crankback-06.txt
Date: Tue, 17 Jun 2003 07:56:03 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Crankback Signaling Extensions for MPLS Signaling
	Author(s)	: A. Farrel, A. Iwata et al.
	Filename	: draft-iwata-mpls-crankback-06.txt
	Pages		: 30
	Date		: 2003-6-16
	
Recently, several routing protocol extensions for
advertising resource information in addition to topology
information have been proposed for use in distributed
constraint-based routing.  In such a distributed routing
environment, however, the information used to compute a
constraint-based path may be out of date.  This means
that LSP setup requests may be blocked by links or nodes
without sufficient resources.
This draft specifies crankback routing extensions for use
in Multi-Protocol Label Switching (MPLS) signaling using
RSVP-TE as defined in 'RSVP-TE: Extensions to RSVP for
LSP Tunnels', RFC3209, so that the LSP setup request can
be retried on an alternate path that detours around the
blocked link or node upon a setup failure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-06.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-iwata-mpls-crankback-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-iwata-mpls-crankback-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-iwata-mpls-crankback-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-iwata-mpls-crankback-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Mon, 16 Jun 2003 22:26:07 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-00.txt
Date: Mon, 16 Jun 2003 18:23:30 -0400

Hi,

This version of the draft is unchanged from the previous
draft-lee-ccamp-rsvp-te-exclude-route except for fixes to references.

Thanks,
Adrian
----- Original Message -----
From: <[email-masked]>
To: <IETF-Announce: ;>
Cc: <[email-masked]>
Sent: Monday, June 16, 2003 7:55 AM
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-00.txt

> 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 : Exclude Routes - Extension to RSVP-TE
> Author(s) : A. Farrel et al.
> Filename : draft-ietf-ccamp-rsvp-te-exclude-route-00.txt

Delivery-date: Mon, 16 Jun 2003 11:56:41 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-00.txt
Date: Mon, 16 Jun 2003 07:55:19 -0400

--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		: Exclude Routes - Extension to RSVP-TE
	Author(s)	: A. Farrel et al.
	Filename	: draft-ietf-ccamp-rsvp-te-exclude-route-00.txt
	Pages		: 13
	Date		: 2003-6-13
	
The current RSVP-TE specification, 'RSVP-TE: Extensions to RSVP for
LSP Tunnels' (RFC 3209) and GMPLS extensions to RSVP-TE, 'Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions' (RFC 3473) allow
abstract nodes and resources to be explicitly included in a path
setup, but not to be explicitly excluded.
In some systems where precise explicit paths are not computed at the
head end it may be useful to specify and signal abstract nodes and
resources that are to be explicitly excluded from routes.  These
exclusions may apply to the whole of a path, or to parts of a path
between two abstract nodes specified in an explicit route.
Shared Risk Link Groups (SRLGs) allow the definition of resources or
groups of resources that share the same risk of failure.  The
knowledge of SRLGs may be used to compute diverse paths that can be
used for protection.  In systems where it is useful to signal
exclusions, it may be useful to signal SRLGs to indicate groups of
resources that should be excluded on the whole of a path or between
two abstract nodes specified in an explicit path.
This document specifies ways to communicate route exclusions during
path setup using RSVP-TE.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-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-ccamp-rsvp-te-exclude-route-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rsvp-te-exclude-route-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Sun, 15 Jun 2003 21:56:47 +0000
Subject: Re: Time slots for CCAMP 57
To: [email-masked]
Date: Sun, 15 Jun 2003 21:54:07 +0000 (GMT)
From: Dimitri Papadimitriou <[email-masked]>

all, sorry for the reposting but the last url was not
accessible:

ccamp'ers, as discussed during the last meeting, see also:
<http://www.ietf.org/proceedings/03mar/slides/ccamp-3/sld2.htm>

the following targets were expected (we have tried to submit
these i-d's well in advance in order to let enough time
to the ccamp community to read/comment them):

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-02.txt>
-> PS for July'03: update submitted (except nits and edito's
   nothing is expected to change from this stable document)

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-01.txt>
-> Info for June'03: update submitted based on the last
   meeting discussion (scope of the whole effort is now
   accuratelly delimited)

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-00.txt>
-> PS for April'03: update expected b/f last call

<http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt>
-> PS for July'03: update submitted, expectation here is
   to reach wg consensus in order to move forward (from
   this a call for consensus would be more than helpful
   in achieving expected deadlines) - a time slot of 5/10 
   minutes would be appreciated for discussing the last 
   protocol details -

any technical comment or feedback appreciated, 

thanks,
- dimitri.

Delivery-date: Sun, 15 Jun 2003 14:43:12 +0000
Subject: Time slots for CCAMP 57
To: [email-masked]
Date: Sun, 15 Jun 2003 14:39:48 +0000 (GMT)
From: Dimitri Papadimitriou <[email-masked]>

ccamp'ers, as discussed during the last meeting, see also:
<http://www.ietf.org/proceedings/03mar/slides/ccamp-3/sld2.htm>

the following targets were expected (we have tried to submit
these i-d's well in advance in order to let enough time
to the ccamp community to read/comment them):

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-02.txt>
-> PS for July'03: update submitted (except nits and edito's
   nothing is expected to change from this stable document)

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-01.txt>
-> Info for June'03: update submitted based on the last
   meeting discussion (scope of the whole effort is now
   accuratelly delimited)

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-00.txt>
-> PS for April'03: update expected b/f last call

<http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signalling-01.txt>
-> PS for July'03: update submitted, expectation here is
   to reach wg consensus in order to move forward (from
   this a call for consensus would be more than helpful
   in achieving expected deadlines) - a time slot of 5/10 
   minutes would be appreciated for discussing the last 
   protocol details -

any technical comment or feedback appreciated, 

thanks,
- dimitri.

Delivery-date: Fri, 13 Jun 2003 21:40:40 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Subject: Flooding using LMP extensions
Date: Fri, 13 Jun 2003 14:39:42 -0700

Follow-up email on flooding using LMP extensions

draft-soumiya-lmp-fault-notification-ext-00.txt:
This draft presents an LMP implementation of the above protocol, and =
ties in
with the P&R Design Team's analysis document, which *proposes the use of =
LMP
for failure reporting/fault notification* (Sec. 4.1, pp. 4).

i) The main discussion point was whether we should use LMP-WDM for =
flooding
fault notification messages.

ii) George you'd said that since LMP was a pt-to-pt protocol, using it =
for
fault notification via flooding would require changes to implementation
models.
I think this assumes that LMP may be implemented only at the line cards, =
and
its use in flooding would require communication, via the control plane,
between multiple LMP state machines.

To answer your question, however, if the proposal of the P&R team is
implemented, it would still be true that there would need to be
communication between the LMP state machines via the control plane, at =
least
those running at the downstream link on which a  failure notification is
received and the upstream link on which this notification must be =
forwarded
onward.
=20
But we don't necessarily see that as a problem.=20
Could you please share with us why you thought it to be so?

Since a lot of the discussion at the SF meeting focused on the
appropriateness of using LMP for flooding, I'd like to compare this to =
other
candidate solutions (as requested by Kireeti).=20
They are:
- Signaling extended for flooding messages
- Using OSPF Opaque LSA for the flooding
- Using LMP, as we've proposed

A. Signaling extended for flooding messages:
   -----------------------------------------
Advantage:
- Signaling may be used for end-to-end fault notification per the P&R =
draft

Disadvantage:
- Extending RSVP-TE to flood the network assumes setting up RSVP =
sessions
between pairs of adjacent nodes (control plane-level adjacency).=20
- Handshake process will be broken.
- For failures affecting LSPs between different s-d pairs, aggregating
failure info. in the Notify message wouldn't be possible, so the scheme
would reduce to one doing per-LSP notification, and lead to the =
possibility
of "notification storms" highlighted in the analysis document (Sec. 4.4, =
pp.
7).

B. OSPF opaque LSA:
   ----------------
Advantage:
-Flooding using OSPF, in general, is mature

Disadvantage:
- Timers in OSPF for Opaque LSA's will need to be brought to 0; this is =
an
unconventional implementation. One would need to maintain multiple =
timers to
account for other LSA's. =20
- Opaque LSA processing is quite heavy, since it was not built with time
urgency in mind.
- OSPF will need some tweaking to send out this LSA's ahead of other =
LSA's
that may be leaving the node
- Need also a solution for IS/IS
- Some networks may not run OSPF or IS/IS while transitioning to a =
G-MPLS
control plane, but they would run signaling for LSP setup/teardown.

C. LMP:
   ----
Advantage:

- LMP deals with Link Management: fault is naturally part of that =
management
- Lightweight implementation
- We have working code for the LMP implementation in our labs as a
proof-of-concept, where we achieve 50 ms protection using flooding =
(we'll be
happy to share details with those interested)

Disadvantage:
- LMP may be implemented at the line card as a pt-to-pt protocol; =
extending
it to allow flooding will require LMP state machines to exchange =
messages
through the control plane. (George)
- LMP extensions to allow flooding may lead to network =
overloading/meltdown
(raised by Alex)

I'd like to get feedback on these issues, and see what people think is =
best
in order to progress this draft in the WG.

Delivery-date: Fri, 13 Jun 2003 21:40:04 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Subject: Fault Notification Protocol & Recovery Requirements
Date: Fri, 13 Jun 2003 14:36:24 -0700

Hi all,

At the SF IETF, we had discussed updates to a set of drafts for P&R that =
we
believe are appropriate for advancement to CCAMP WG drafts.
=20
At the conclusion of the discussion at SF, Kireeti had encouraged us to =
move
this process forward on the mailing list, and help structure the
discussions, so we're keen to do so, and any feedback on the discussion
below is welcome.

The feedback at the SF meeting was very interesting, and several issues =
were
raised (cf. CCAMP meeting minutes=20
http://ops.ietf.org/lists/ccamp/ccamp.2003/msg00361.html).

i) Feedback from Alex was that OSPF flooding was a process that led to =
many
net meltdowns before people got it right. So we need to look carefully =
at
using flooding for fault notification.

ii) George had expressed the view that since LMP was considered a =
pt-to-pt
protocol, using it for fault notification via flooding would require =
changes
to implementation models.=20
This assumes, we think, that LMP may be implemented only at the line =
cards,
and its use in flooding would require communication, via the control =
plane,
between multiple LMP state machines

iii) Kireeti had stated that we should provide a better insight into the
requirements and the problem. The main discussion point was whether we
should use LMP-WDM for flooding fault notification messages. =20

We will address parts of (ii) and (iii) in a follow-up email.

I'd like to address and discuss the above in the context of the =
following
drafts:

1. draft-czezowski-optical-recovery-reqs-01.txt.
This draft presents the requirements for optical restoration, and was
produced upon a request (and rightly so) by Kireeti in the Yokohama =
meeting
(cf. IETF 53 Meeting minutes), asking us to provide the requirements =
that
motivated our fault notification work.

We believe this complements well the nice work done by the P&R Design =
team.
The team has provided terminology, functional specification, and =
analysis of
recovery schemes, while our draft attempts to make precise the =
requirements
(which haven't so far been gathered in one place).

We would like to underscore the importance of well-articulated =
requirements,
and are happy to work with others in the WG to do this. One option would =
be
for the WG to adopt this draft as a WG document, so that interested =
members
of the WG can collaborate to complete this work.

Ron, Kireeti, would it be possible to take a vote on this?

2. draft-rabbat-fault-notification-protocol-02.txt: =20
The draft addresses a problem highlighted in the P&R Design team's
terminology draft. Namely, that P&R under tight time constraints is a =
very
challenging problem.=20
Therefore, we present an implementation-independent protocol for fault
notification through flooding, which focuses on keeping to a time =
constraint
during the recovery.

To answer Alex's question, Alex, we have shown in an accompanying white
paper:
http://perth.mit.edu/~richard/wp-ietf-fault-notification.pdf)=20
that flooding has advantage of dealing with per-link (thus with multiple
simultaneous failures) as opposed to per-LSP (or per group of LSPs)
failures, and the advantage of reliability. Due to the former, the =
overhead
due to flooding can, in fact, be less than in point-to-point failure
signaling.=20

We would like this draft to be adopted as a WG doc. by the CCAMP WG to
further advance it.=20

Ron, Kireeti, is that a good course of action?

Richard.

Delivery-date: Thu, 12 Jun 2003 11:20:13 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-09.txt
Date: Thu, 12 Jun 2003 07:18:16 -0400

--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 (LMP)
	Author(s)	: J. Lang
	Filename	: draft-ietf-ccamp-lmp-09.txt
	Pages		: 77
	Date		: 2003-6-11
	
For scalability purposes, multiple data links can be combined to
form a single traffic engineering (TE) link.  Furthermore, the
management of TE links is not restricted to in-band messaging, but
instead can be done using out-of-band techniques.  This document
specifies a link management protocol (LMP) that runs between a pair
of nodes and is used to manage TE links.  Specifically, LMP will be
used to maintain control channel connectivity, verify the physical
connectivity of the data links, correlate the link property
information, suppress downstream alarms, and localize link failures
for protection/restoration purposes in multiple kinds of networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-09.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-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 11 Jun 2003 18:09:52 +0000
Date: Wed, 11 Jun 2003 11:08:19 -0700 (PDT)
From: Greg Bernstein <[email-masked]>
Subject: ASON routing requirements document?
To: [email-masked]

I saw in the slides for Kireeti's presentation at the
interim ITU-T meeting the idea of a ASON routing
requirements document at the IETF similar to what has
been done for signaling.
This sounds like a good idea and I be glad to
contribute, in fact we can probably quickly cut and
paste from some existing or previous documents with an
update for ITU-T terminology.
Sorry, not to comment for so long. Some ISP problems
seemed to have got me dropped from the list and an
extra heavy teaching load, in addition consulting,
made me think the group had gone quiet!

Greg B.

Grotto-Networking 

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Delivery-date: Wed, 11 Jun 2003 15:59:05 +0000
Date: Wed, 11 Jun 2003 11:57:29 -0400
To: "Adrian Farrel" <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Route Exclusion
Cc: <[email-masked]>

At 10:38 AM 6/11/2003 -0400, Adrian Farrel wrote:
> > >Route exclusions are useful when full path computation is not performed at
>the
> > >head of an LSP. This happens when
> > >- an external route server is used (see
> > >draft-vasseur-mpls-path-computation-rsvp-te)
> >
> > note that the PCS is always external ;-) Anyway, this gives me the
> > opportunity to mention something that I told you off-line: the draft
> > mentioned above does specify an EXCLUDE-ELEMENT object which has the same
> > objective as your draft. I'll remove it from the next revision and I agree
> > to support your draft.
>
>JP, thanks for your support.
>
>BTW, the PCS is *not* always external unless you use the definition that 
>says it
>is only a PCS if it is external :-)
>
>Consider
>i. LERs that offer path computation for LSPs that they initiate
>ii. PCS function that is offered on a box that is also an LER

well my only point was that PCS is just a function/capability regardless of 
whether the platform is a LSR, LER, Off-line UNIX box, ...

JP.

>Cheers,
>Adrian

Envelope-to: [email-masked]
Delivery-date: Wed, 11 Jun 2003 14:40:50 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jean Philippe Vasseur" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Route Exclusion
Date: Wed, 11 Jun 2003 10:38:32 -0400

> >Route exclusions are useful when full path computation is not performed at
the
> >head of an LSP. This happens when
> >- an external route server is used (see
> >draft-vasseur-mpls-path-computation-rsvp-te)
>
> note that the PCS is always external ;-) Anyway, this gives me the
> opportunity to mention something that I told you off-line: the draft
> mentioned above does specify an EXCLUDE-ELEMENT object which has the same
> objective as your draft. I'll remove it from the next revision and I agree
> to support your draft.

JP, thanks for your support.

BTW, the PCS is *not* always external unless you use the definition that says it
is only a PCS if it is external :-)

Consider
i. LERs that offer path computation for LSPs that they initiate
ii. PCS function that is offered on a box that is also an LER

Cheers,
Adrian

Delivery-date: Wed, 11 Jun 2003 09:57:47 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Len Nieman <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: LMP-MIB Module Compile Test
Date: Wed, 11 Jun 2003 11:56:43 +0200

Inline

> -----Original Message-----
> From: Len Nieman [mailto:[email-masked]]
> Sent: woensdag 11 juni 2003 0:23
> To: [email-masked]
> Cc: [email-masked]
> Subject: LMP-MIB Module Compile Test
> 
> 
> For anyone interested, I ran a test compile of the LMP-MIB module
> extracted from draft-ietf-ccamp-lmp-mib-06.txt.
> 
> For the TE-LINK-STD-MIB "IMPORT" I used the module extracted from
> draft-ietf-mpls-telink-mib-02.txt
> 
> The tests were run using the MG-Soft compiler, version 4.0, build 459.
> 
> There were only two minor problems due to "xxx" being used for values
> with assignments pending from IANA.
> 
> In the LMP-MIB module I had to manually change the "mib-2 
> xxx" to "mib-2
> 113" here:
> 
>    DESCRIPTION
>        "Initial version published as RFC xxxx (to be assigned by RFC
>         Editor)"
>    ::= { mib-2 xxx } -- To be assigned by IANA (experimental 113 can
>                      -- be used in the interim)
> 
> And in the TE-LINK-STD-MIB module I had to make a similar change of
> "transmission xxx" to "transmission 114" here:
> 
>  DESCRIPTION
>    "Initial version published as RFC xxxx (to be assigned by RFC
>     Editor)"
>  ::= { transmission xxx } -- To be assigned by IANA (experimental 114
>                           -- can be used in the interim)
> 
> With the "xxx"s out of the way, both modules compiled 
> completed with no errors or warnings.
> 
> After looking through a number of other drafts, I see this "xxx" place
> holder for numeric values is used quite a bit.
> 
Right... and that is what we WANT people to do!!

> It would be helpful, and cut down on the manual intervention needed to
> run compile tests, if a numeric value (999?) were specifically defined as
> "Pending assignment by IANA ("whatever ###" can be used in the interim)"
> for use in draft documents. Any thoughts on that?
> 
Has been discussed a number of times... apparently there is no consensus
on it... so we keep the manual tweaking that is needed.
Not fun, but not that bad either, is it?

Bert
> Len Nieman
> 
> 
> 

Delivery-date: Wed, 11 Jun 2003 01:08:54 +0000
Date: Tue, 10 Jun 2003 21:08:02 -0400
To: Len Nieman <[email-masked]>,[email-masked]
From: [email-masked]
Subject: Re: LMP-MIB Module Compile Test
Cc: [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi Len,

This issue is discussed from time to time on the "mibs"
email list and you may want to take
a look at those email archives, or post the question to that
list.

Here's more info about the "mibs" IETF email list:

"A special mailing list has been created for generic/common MIB related
discussions, [email-masked]. To subscribe, send email to
[email-masked] with the word subscribe in the body. The mailing
lists archives will be at ftp://ftp.psg.com/pub/lists/mibs* "

I agree with you that there are extra steps (as you point out)
to get the MIB to compile once it is abstracted from the draft.

On the other hand, there are potential pitfalls with putting
a sub-Id in the MIB draft.  One of the issues is that 
the MIB, even though a draft document, gets coded it up this temporary
sub-id  even when you have a BIG disclaimer comment 
around the sub-Id, so this is one of the reasons that 
the XXX appears.

   -Joan

At 06:23 PM 6/10/03 -0400, Len Nieman wrote:
>For anyone interested, I ran a test compile of the LMP-MIB module
>extracted from draft-ietf-ccamp-lmp-mib-06.txt.
>
>For the TE-LINK-STD-MIB "IMPORT" I used the module extracted from
>draft-ietf-mpls-telink-mib-02.txt
>
>The tests were run using the MG-Soft compiler, version 4.0, build 459.
>
>There were only two minor problems due to "xxx" being used for values
>with assignments pending from IANA.
>
>In the LMP-MIB module I had to manually change the "mib-2 xxx" to "mib-2
>113" here:
>
>   DESCRIPTION
>       "Initial version published as RFC xxxx (to be assigned by RFC
>        Editor)"
>   ::= { mib-2 xxx } -- To be assigned by IANA (experimental 113 can
>                     -- be used in the interim)
>
>And in the TE-LINK-STD-MIB module I had to make a similar change of
>"transmission xxx" to "transmission 114" here:
>
> DESCRIPTION
>   "Initial version published as RFC xxxx (to be assigned by RFC
>    Editor)"
> ::= { transmission xxx } -- To be assigned by IANA (experimental 114
>                          -- can be used in the interim)
>
>With the "xxx"s out of the way, both modules compiled completed with no
>errors or warnings.
>
>After looking through a number of other drafts, I see this "xxx" place
>holder for numeric values is used quite a bit.
>
>It would be helpful, and cut down on the manual intervention needed to
>run compile tests, if a numeric value (999?) were specifically defined as
>"Pending assignment by IANA ("whatever ###" can be used in the interim)"
>for use in draft documents. Any thoughts on that?
>
>Len Nieman
>
>
>

Delivery-date: Wed, 11 Jun 2003 00:59:22 +0000
From: "zafar ali" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Cc: "'Anca Zamfir'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Time slots for CCAMP 57
Date: Tue, 10 Jun 2003 20:58:01 -0400
Organization: Cisco Systems

Hi Kireeti and Ron, 

Can you please allocate a 5-10 min. time slot for the following draft, 

http://www.ietf.org/internet-drafts/draft-zamfir-explicit-resource-contr
ol-bundle-01.txt

This draft addresses the issue of component link identification for
explicit resource control and recording over TE bundled Links (please
see abstract in the following). 

Comments and input from everyone will be much appreciated, as usual.  

Thanks
 
Regards... Anca & Zafar. 

Revision History
----------------
 
Version 00 was posted on March 4, 2003, but we just missed the cut-off
time for the 56th IETF meeting in San Francisco. Since then we have made
some minor changes and posted version 01 on May 17th. 

Abstract: 
---------
    
   Explicit label/ resource control using the Label ERO and Label RRO 
   subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE 
   links are bundled, identification of label resource is not enough for

   the purpose of explicit resource control. Specifically, when link 
   bundling [GMPLS-BUNDLE] is used, resource identification requires 
   mechanisms to specify the component link identifier, along the TE 
   link identifier and Label. This draft defines the extensions to RSVP-
   TE [RFC2119, RFC3209] to specify component link identifiers for 
   explicit resource control and recording over GMPLS link bundles. 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Kireeti Kompella
>Sent: Saturday, May 31, 2003 1:40 AM
>To: [email-masked]
>Subject: Time slots for CCAMP 57
>
>
>Hi,
>
>Please submit your requests for time slots for the CCAMP 
>meeting at the 57th IETF to Ron and me.
>
>Note that to get a time slot, you MUST have submitted a draft 
>by the draft deadline (June 30, 9:00AM ET).  Furthermore, 
>these time slots are for discussing and resolving issues 
>raised on the mailing list, or for first time drafts, a *very* 
>brief overview of the idea, why it's relevant, and how it fits 
>into the CCAMP charter.  No presentations!
>
>If you request a time slot, please follow up and start an 
>email discussion on the CCAMP list.
>
>Thanks,
>Kireeti.
>
>

Delivery-date: Tue, 10 Jun 2003 23:05:56 +0000
Date: Tue, 10 Jun 2003 19:04:48 -0400
To: "Adrian Farrel" <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Route Exclusion
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Ron Bonica" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>

Hi Adrian,

At 03:16 PM 6/10/2003 -0400, Adrian Farrel wrote:
>All,
>
>Ron has asked me to post a summary of where this work fits into the WG and,
>unless there are objections within the next couple of days, to post the 
>existing
>draft
>(http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-02.tx
>t) without revisions, as a WG draft.
>
>This is a third last chance to object :-)
>
>The draft specifies ways to communicate route exclusions during path setup 
>using
>RSVP-TE.
>Route exclusions are useful when full path computation is not performed at the
>head of an LSP. This happens when
>- an external route server is used (see
>draft-vasseur-mpls-path-computation-rsvp-te)

note that the PCS is always external ;-) Anyway, this gives me the 
opportunity to mention something that I told you off-line: the draft 
mentioned above does specify an EXCLUDE-ELEMENT object which has the same 
objective as your draft. I'll remove it from the next revision and I agree 
to support your draft.

JP.

>- there are domains of computation (such as, but not limited to, areas and 
>ASs)
>- loose hops or non-specific abstract nodes are used.
>
>Route exclusion allows the LSP requester to communicate the requirement to 
>avoid
>nodes, links, resources or SRLGs. This may result from
>- user requests in the MPLS-TE-MIB (see draft-ietf-mpls-te-mib)
>- protection diversity requirements (see
>draft-ietf-ccamp-gmpls-recovery-analysis etc.)
>- crankback and local repair avoidance of errored or blocked resources (see
>draft-iwata-mpls-crankback)
>
>Applicability is to packet and non-packet networks. MPLS and GMPLS.
>
>Requirements also come from
>- the ITU-T's ASON architecture (see draft-ietf-ccamp-gmpls-ason-reqts)
>
>Value is present in single area/AS systems. The concept is also applicable to
>multi-area/multi-AS TE.
>
>With regard to the *existing* CCAMP charter, this work is covered by many 
>of the
>charter items, but best by:
>- Define signalling protocols and measurement protocols such that they
>   support multiple physical path and tunnel technologies
>- Abstract link and path properties needed for link and path
>   protection.
>   Define signalling mechanisms for path protection, diverse routing and
>   fast path restoration.  Ensure that multi-layer path protection and
>   restoration functions are achievable using the defined signalling and
>   measurement protocols, either separately or in combination.
>
>It is possible that the revised charter will include
>- multi-area/multi-AS
>- explicit recognition of the ASON requirements
>
>Further details can be found in the draft.
>The authors would be happy (sic) to answer any questions, preferably on the
>list.
>
>Adrian
>
>----- Original Message -----
>From: "Ron Bonica" <[email-masked]>
>To: "Adrian Farrel" <[email-masked]>; "'Kireeti Kompella'"
><[email-masked]>; <[email-masked]>
>Cc: <[email-masked]>; <[email-masked]>
>Sent: Thursday, May 29, 2003 11:06 AM
>Subject: RE: Route Exclusion
>
>
> > Folks,
> >
> > Are there any objections to adopting the route exclusion draft as a WG 
> item?
> > If so, please post them to the mailing list by June 5. If not, CCAMP will
> > adopt the draft as a WG item.
> >
> >                                                  Ron
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Adrian Farrel
> > > Sent: Tuesday, May 27, 2003 3:57 PM
> > > To: 'Kireeti Kompella'; Ron Bonica; [email-masked]
> > > Cc: [email-masked]; [email-masked]; Adrian
> > > Farrel
> > > Subject: Route Exclusion
> > >
> > >
> > > Kireeti, Ron,
> > >
> > > You may recall that at SF there was a surprisingly large number
> > > of people (30+)
> > > who had read this draft and expressed an interest. (In today's
> > > climate, it seems
> > > unusual if all of the authors have read a draft!)
> > >
> > > We (the authors) are also seeing a fair bit of interest expressed
> > > to us from
> > > people who need the function and want to go ahead and start
> > > implementing - they
> > > want to know what the future of the draft is. At the same time,
> > > the ASON work
> > > seems to be pulling in this requirement, and I shouldn't be surprised if
> > > multi-area/multi-domain/multi-AS decides it is a requirement, too.
> > >
> > > So the question for you is, what do we do with this draft?
> > >
> > > There appear to be three possibilies:
> > >
> > > 1. The draft becomes a WG draft in the near future, and continues
> > > to develop
> > > with input from the WG.
> > >
> > > 2. The authors continue to spend their efforts on the draft with
> > > no particular
> > > IETF target in sight and without the GMPLS community having any realistic
> > > expectation of the draft going anywhere. Other standards bodies,
> > > needing the
> > > function, develop their own alternatives and so on...
> > >
> > >  3. The authors bring the draft forward as an individual
> > > submission to the IESG.
> > >
> > >  Well, you can guess which I think is the best idea.
> > >
> > > What do you think?
> > >
> > > Cheers,
> > > Adrian
> > >
> > >
> > >
> >

Envelope-to: [email-masked]
Delivery-date: Tue, 10 Jun 2003 22:26:01 +0000
Date: Tue, 10 Jun 2003 18:23 -0400 (EDT)
From: Len Nieman <[email-masked]>
Subject: LMP-MIB Module Compile Test
To: [email-masked]
Cc: [email-masked]
Message-id: <[email-masked]>
Organization: MCI

For anyone interested, I ran a test compile of the LMP-MIB module
extracted from draft-ietf-ccamp-lmp-mib-06.txt.

For the TE-LINK-STD-MIB "IMPORT" I used the module extracted from
draft-ietf-mpls-telink-mib-02.txt

The tests were run using the MG-Soft compiler, version 4.0, build 459.

There were only two minor problems due to "xxx" being used for values
with assignments pending from IANA.

In the LMP-MIB module I had to manually change the "mib-2 xxx" to "mib-2
113" here:

   DESCRIPTION
       "Initial version published as RFC xxxx (to be assigned by RFC
        Editor)"
   ::= { mib-2 xxx } -- To be assigned by IANA (experimental 113 can
                     -- be used in the interim)

And in the TE-LINK-STD-MIB module I had to make a similar change of
"transmission xxx" to "transmission 114" here:

 DESCRIPTION
   "Initial version published as RFC xxxx (to be assigned by RFC
    Editor)"
 ::= { transmission xxx } -- To be assigned by IANA (experimental 114
                          -- can be used in the interim)

With the "xxx"s out of the way, both modules compiled completed with no
errors or warnings.

After looking through a number of other drafts, I see this "xxx" place
holder for numeric values is used quite a bit.

It would be helpful, and cut down on the manual intervention needed to
run compile tests, if a numeric value (999?) were specifically defined as
"Pending assignment by IANA ("whatever ###" can be used in the interim)"
for use in draft documents. Any thoughts on that?

Len Nieman

Envelope-to: [email-masked]
Delivery-date: Tue, 10 Jun 2003 19:17:53 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Ron Bonica" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: Route Exclusion
Date: Tue, 10 Jun 2003 15:16:25 -0400

All,

Ron has asked me to post a summary of where this work fits into the WG and,
unless there are objections within the next couple of days, to post the existing
draft
(http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-02.tx
t) without revisions, as a WG draft.

This is a third last chance to object :-)

The draft specifies ways to communicate route exclusions during path setup using
RSVP-TE.
Route exclusions are useful when full path computation is not performed at the
head of an LSP. This happens when
- an external route server is used (see
draft-vasseur-mpls-path-computation-rsvp-te)
- there are domains of computation (such as, but not limited to, areas and ASs)
- loose hops or non-specific abstract nodes are used.

Route exclusion allows the LSP requester to communicate the requirement to avoid
nodes, links, resources or SRLGs. This may result from
- user requests in the MPLS-TE-MIB (see draft-ietf-mpls-te-mib)
- protection diversity requirements (see
draft-ietf-ccamp-gmpls-recovery-analysis etc.)
- crankback and local repair avoidance of errored or blocked resources (see
draft-iwata-mpls-crankback)

Applicability is to packet and non-packet networks. MPLS and GMPLS.

Requirements also come from
- the ITU-T's ASON architecture (see draft-ietf-ccamp-gmpls-ason-reqts)

Value is present in single area/AS systems. The concept is also applicable to
multi-area/multi-AS TE.

With regard to the *existing* CCAMP charter, this work is covered by many of the
charter items, but best by:
- Define signalling protocols and measurement protocols such that they
  support multiple physical path and tunnel technologies
- Abstract link and path properties needed for link and path
  protection.
  Define signalling mechanisms for path protection, diverse routing and
  fast path restoration.  Ensure that multi-layer path protection and
  restoration functions are achievable using the defined signalling and
  measurement protocols, either separately or in combination.

It is possible that the revised charter will include
- multi-area/multi-AS
- explicit recognition of the ASON requirements

Further details can be found in the draft.
The authors would be happy (sic) to answer any questions, preferably on the
list.

Adrian

----- Original Message -----
From: "Ron Bonica" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "'Kireeti Kompella'"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, May 29, 2003 11:06 AM
Subject: RE: Route Exclusion

> Folks,
>
> Are there any objections to adopting the route exclusion draft as a WG item?
> If so, please post them to the mailing list by June 5. If not, CCAMP will
> adopt the draft as a WG item.
>
>                                                  Ron
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Adrian Farrel
> > Sent: Tuesday, May 27, 2003 3:57 PM
> > To: 'Kireeti Kompella'; Ron Bonica; [email-masked]
> > Cc: [email-masked]; [email-masked]; Adrian
> > Farrel
> > Subject: Route Exclusion
> >
> >
> > Kireeti, Ron,
> >
> > You may recall that at SF there was a surprisingly large number
> > of people (30+)
> > who had read this draft and expressed an interest. (In today's
> > climate, it seems
> > unusual if all of the authors have read a draft!)
> >
> > We (the authors) are also seeing a fair bit of interest expressed
> > to us from
> > people who need the function and want to go ahead and start
> > implementing - they
> > want to know what the future of the draft is. At the same time,
> > the ASON work
> > seems to be pulling in this requirement, and I shouldn't be surprised if
> > multi-area/multi-domain/multi-AS decides it is a requirement, too.
> >
> > So the question for you is, what do we do with this draft?
> >
> > There appear to be three possibilies:
> >
> > 1. The draft becomes a WG draft in the near future, and continues
> > to develop
> > with input from the WG.
> >
> > 2. The authors continue to spend their efforts on the draft with
> > no particular
> > IETF target in sight and without the GMPLS community having any realistic
> > expectation of the draft going anywhere. Other standards bodies,
> > needing the
> > function, develop their own alternatives and so on...
> >
> >  3. The authors bring the draft forward as an individual
> > submission to the IESG.
> >
> >  Well, you can guess which I think is the best idea.
> >
> > What do you think?
> >
> > Cheers,
> > Adrian
> >
> >
> >
>

Delivery-date: Tue, 10 Jun 2003 11:59:52 +0000
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Question of Dynamic Configuration of Label Using LMP
Date: Tue, 10 Jun 2003 20:57:32 +0900

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_01C32F47.7945D8F0
Content-Type: text/plain;
	charset="euc-kr"

Hi, LMP people

I have a question of how to dynamically configure label values between LMP
peers using LMP.

According to the section 3.2.1.1(Port and Wavelength Labels) of
rfc3471(GMPLS Signaling Functional Description), 
the document says that label values may be configured or dynamically
determined using a protocol such as LMP.

Here, I would like to apply the same concept into the case of SONET/SDH
labels as well.
This is because that the scope of label at least includes time-slots,
wavelengths, or space division multiplexed positions, as described in the
document.

However, 
I am not sure that there is an exact description for dynamic configuration
of label values in case of SONET/SDH labels in the LMP specification.
I think that the contents for dynamic configuration of the values is
located in the section 4, Link Property
Correlation of the LMP specification, draft-ietf-ccamp-lmp-08.txt.

I think that in case of the port and wavelength labels 
the correlation procedure and its formats could be applied as described in
the LMP specification.
However, in case of SONET/SDH labels, I have still no self-confidence in
understanding the description.
In SONET/SDH, labels may be time-slots between LMP peers, which have the
format of S/U/K/L/M 
as described in the section 3 of draft-ietf-ccamp-gmpls-sonet-sdh-
08.txt(GMPLS Extentions SONET and SDH Control).

I think that if the current description of the LMP specification is applied
to the SONET/SDH case,
the dynamic configuration of ports is possible, 
but the dynamic configuration of time-slots within a port is not possible
and is not required.
This is my understanding.

Could anyone of LMP people tell me the exact understanding for the dynamic
configuration of time-slots?

****************************************** 
Young Hwa Kim 
Senior Member, Network Technology Lab., ETRI 
Office No. : 82-42-860-5819 
Fax No. : 82-42-860-6104 
Email addr. : [email-masked] 
****************************************** 

------_=_NextPart_001_01C32F47.7945D8F0
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.2653.12">
<TITLE>Question of Dynamic Configuration of Label Using LMP</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I have a question of how to dynamically configure =
label values between LMP peers using LMP.</FONT>
</P>

<P><FONT SIZE=3D2>According to the section 3.2.1.1(Port and Wavelength =
Labels) of rfc3471(GMPLS Signaling Functional Description), </FONT>
<BR><FONT SIZE=3D2>the document says that label values may be =
configured or dynamically determined using a protocol such as =
LMP.</FONT>
</P>

<P><FONT SIZE=3D2>Here, I would like to apply the same concept into the =
case of SONET/SDH labels as well.</FONT>
<BR><FONT SIZE=3D2>This is because that the scope of label at least =
includes time-slots, wavelengths, or space division multiplexed =
positions, as described in the document.</FONT></P>

<P><FONT SIZE=3D2>However, </FONT>
<BR><FONT SIZE=3D2>I am not sure that there is an exact description for =
dynamic configuration of label values in case of SONET/SDH labels in =
the LMP specification.</FONT></P>

<P><FONT SIZE=3D2>I think that the contents for dynamic configuration =
of the values is located in the section 4, Link Property</FONT>
<BR><FONT SIZE=3D2>Correlation of the LMP specification, =
draft-ietf-ccamp-lmp-08.txt.</FONT>
</P>

<P><FONT SIZE=3D2>I think that in case of the port and wavelength =
labels </FONT>
<BR><FONT SIZE=3D2>the correlation procedure and its formats could be =
applied as described in the LMP specification.</FONT>
<BR><FONT SIZE=3D2>However, in case of SONET/SDH labels, I have still =
no self-confidence in understanding the description.</FONT>
<BR><FONT SIZE=3D2>In SONET/SDH, labels may be time-slots between LMP =
peers, which have the format of S/U/K/L/M </FONT>
<BR><FONT SIZE=3D2>as described in the section 3 of =
draft-ietf-ccamp-gmpls-sonet-sdh-08.txt(GMPLS Extentions SONET and SDH =
Control).</FONT>
</P>

<P><FONT SIZE=3D2>I think that if the current description of the LMP =
specification is applied to the SONET/SDH case,</FONT>
<BR><FONT SIZE=3D2>the dynamic configuration of ports is possible, =
</FONT>
<BR><FONT SIZE=3D2>but the dynamic configuration of time-slots within a =
port is not possible and is not required.</FONT>
<BR><FONT SIZE=3D2>This is my understanding.</FONT>
</P>

<P><FONT SIZE=3D2>Could anyone of LMP people tell me the exact =
understanding for the dynamic configuration of time-slots?</FONT>
</P>

<P><FONT SIZE=3D2>****************************************** </FONT>
<BR><FONT SIZE=3D2>Young Hwa Kim </FONT>
<BR><FONT SIZE=3D2>Senior Member, Network Technology Lab., ETRI </FONT>
<BR><FONT SIZE=3D2>Office No. : 82-42-860-5819 </FONT>
<BR><FONT SIZE=3D2>Fax No. : 82-42-860-6104 </FONT>
<BR><FONT SIZE=3D2>Email addr. : [email-masked] </FONT>
<BR><FONT SIZE=3D2>****************************************** </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C32F47.7945D8F0--

Delivery-date: Tue, 10 Jun 2003 11:52:41 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-tracereq-05.txt
Date: Tue, 10 Jun 2003 07:49:56 -0400

--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		: Tracing Requirements for Generic Tunnels
	Author(s)	: R. Bonica, K. Kompella, D. Meyer
	Filename	: draft-ietf-ccamp-tracereq-05.txt
	Pages		: 9
	Date		: 2003-6-9
	
This document specifies requirements for a generic route-tracing
application.  It also specifies requirements for a protocol that will
support that application. Network operators will use the generic
route-tracing application to verify proper operation of the IP
forwarding plane. They will also use the application to discover
details regarding tunnels that support IP forwarding.
The generic route-tracing application, specified herein, supports a
superset of the functionality that 'traceroute' currently offers.
Like traceroute, the generic route-tracing application can discover
the forwarding path between two interfaces that are contained by an
IP network. Unlike traceroute, this application can reveal details
regarding tunnels that support the IP forwarding path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-05.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-tracereq-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-tracereq-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-tracereq-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-tracereq-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Sat, 07 Jun 2003 23:12:16 +0000
Date: Sat, 07 Jun 2003 19:10:02 -0400
From: Ron Bonica <[email-masked]>
Subject: RE: draft-ietf-ccamp-tracereq
To: Kireeti Kompella <[email-masked]>, Xiaoming Fu <[email-masked]>
Cc: [email-masked]

Folks,

I have submitted a new version of the draft to address Xiaoming's comment.
Until the draft editor posts the new version, you can find it at
www.bonica.org/docs/draft-ietf-ccamp-tracereq-05.txt.

                                   Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Friday, June 06, 2003 6:00 PM
> To: Xiaoming Fu
> Cc: Ron Bonica; [email-masked]
> Subject: Re: draft-ietf-ccamp-tracereq
>
>
> Hi Xiaoming,
>
> > For example, TCP might be useful for passing some firewalls and possibly
>
> I don't believe that firewalls would come into the picture in most
> uses of tunnel trace -- it's not a replacement for traceroute, but
> more of a SP tool.
>
> That said, it might be worth mentioning (but not requiring) that
> TCP be a possible transport.
>
> Kireeti.
>

Delivery-date: Fri, 06 Jun 2003 22:38:47 +0000
Date: Fri, 6 Jun 2003 15:38:26 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Stephen Shew <[email-masked]>
cc: [email-masked], Stephen Trowbridge <[email-masked]>, "Wijnen, Bert" <[email-masked]>, "" <[email-masked]>, "Ronald P. Bonica" <[email-masked]>
Subject: RE: ASON RSVP-TE extensions

On Wed, 4 Jun 2003, Stephen Shew wrote:

> I'll attempt (with help from Peter Wery and Malcolm Betts) to explain what
> is meant by "consent".

Thanks, Stephen S and Steve T!

Kireeti.

Delivery-date: Fri, 06 Jun 2003 22:35:24 +0000
Date: Fri, 6 Jun 2003 15:34:46 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-ccamp-tracereq

It's sort of underway already, but just to make it official, this is
a WG Last Call announcement for the above document.  LC ends June 13,
and should be focussed on the changes from previous version.

Kireeti.

Delivery-date: Fri, 06 Jun 2003 22:02:50 +0000
Date: Fri, 6 Jun 2003 15:00:15 -0700 (PDT)
From: Kireeti Kompella <[email-masked]>
To: Xiaoming Fu <[email-masked]>
cc: Ron Bonica <[email-masked]>, "" <[email-masked]>
Subject: Re: draft-ietf-ccamp-tracereq

Hi Xiaoming,

> For example, TCP might be useful for passing some firewalls and possibly

I don't believe that firewalls would come into the picture in most
uses of tunnel trace -- it's not a replacement for traceroute, but
more of a SP tool.

That said, it might be worth mentioning (but not requiring) that
TCP be a possible transport.

Kireeti.

Delivery-date: Fri, 06 Jun 2003 08:52:08 +0000
Date: Fri, 06 Jun 2003 10:42:21 +0200
From: Xiaoming Fu <[email-masked]>
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ccamp-tracereq

Ron,

Ron Bonica wrote:
> Xiaoming,
> 
> I am not familiar with any traceroute implementations that use TCP. Could
> you point me at a reference?

Most are only used experimentally; you may find some in:
http://www.postel.org/pipermail/end2end-interest/2002-February/001820.html
http://honor.trusecure.com/pipermail/firewall-wizards/1998-December/004324.html
http://michael.toren.net/code/tcptraceroute/

> Why would TCP be preferable to UDP. Since you only expect one response to
> each probe, what value would TCP add?

For example, TCP might be useful for passing some firewalls and possibly
detecting them from the changes in the unreachable messages returned.
Furthermore, is it useful to introduce some kind of record-route object 
in the TCP/SCTP payload (using UDP may be also possible, but at least in 
some machines UDP messages are constrained by MTU) - which may be useful 
for logging topology, MTU, etc. - say, as shown in Option 1 or 2? I 
assume option 3 is the default way for traditional "traceroute" using 
ICMP/UDP/TCP.

      ----       ----     ----     ----
      |N1|  ---  |N2| --- |N3| --- |N4|
      ----       ----     ----     ----
      tcp ----> tcp
                 tcp ---> tcp
                           tcp ----> tcp
                               <----
                     <---
          <----
                  (option 1)

      ----       ----     ----     ----
      |N1|  ---  |N2| --- |N3| --- |N4|
      ----       ----     ----     ----
      tcp ----> tcp
                 tcp ---> tcp
                           tcp ----> tcp
          <-------------------------
                  (option 2)

      ----       ----     ----     ----
      |N1|  ---  |N2| --- |N3| --- |N4|
      ----       ----     ----     ----
      xxx <----> xxx
      xxx <-------------> xxx
      xxx <----------------------> xxx
                  (option 3)

BTW - text from http://michael.toren.net/code/tcptraceroute/:

"The more traditional traceroute(8) sends out either UDP or ICMP ECHO
packets with a TTL of one, and increments the TTL until the destination
has been reached. By printing the gateways that generate ICMP time
exceeded messages along the way, it is able to determine the path
packets are taking to reach the destination.

"The problem is that with the widespread use of firewalls on the modern
Internet, many of the packets that traceroute(8) sends out end up being
filtered, making it impossible to completely trace the path to the
destination. However, in many cases, these firewalls will permit inbound
TCP packets to specific ports that hosts sitting behind the firewall are
listening for connections on. By sending out TCP SYN packets instead of
UDP or ICMP ECHO packets, tcptraceroute is able to
  bypass the most
common firewall filters. "

Cheers,
Xiaoming
>                                                             Ron
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On
>>Behalf Of Xiaoming Fu
>>Sent: Wednesday, June 04, 2003 6:12 AM
>>To: Ron Bonica
>>Cc: [email-masked]
>>Subject: Re: draft-ietf-ccamp-tracereq
>>
>>
>>Ron,
>>
>>Thanks for your new version. One more issue:
>>
>>Current available transport mechanisms for traceroute include ICMP, UDP,
>>and TCP. UDP may relief DoS issues, but NAT/firewall might be another
>>issue (although we could have STUN). TCP has an issue of connection
>>setup latency, however it could be potentially considered (it may also
>>have a number of available ports?). To my knowledge, circulations from
>>one protocol to protocol are sometimes helpful, for example, SIP
>>initially used UDP, while TCP was recently proposed.
>>
>>Hence, I would suggest a "SHOULD" instead of "MUST" in Section 4.2.
>>
>>Cheers,
>>Xiaoming
>>
>>Ron Bonica wrote:
>>
>>>Xiaoming,
>>>
>>>Thanks for the thorough review. A new version of the draft is
>>
>>available at
>>
>>>http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-04.txt.
>>>
>>>                              Ron
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked] [mailto:[email-masked]]On
>>>>Behalf Of Xiaoming Fu

>>>>Sent: Friday, May 30, 2003 7:20 PM
>>>>To: Ron Bonica
>>>>Cc: [email-masked]
>>>>Subject: Re: draft-ietf-ccamp-tracereq
>>>>
>>>>
>>>>Ron,
>>>>
>>>>It is a nice document. I went it through and have a few comments:
>>>>
>>>>- Section 3, 9) - "forwarding plane failu res" ==> _failures_
>>>
>>>
>>>Oops....
>>>
>>>
>>>
>>>>- I didn't understand why the following paragraph appears twice - the
>>>>  same in Section 3, 13) and 14). I assume you're talking about control
>>>>  plane failure in 13).
>>>>      Justification: MTU information is sometimes useful in identifying
>>>>      the root cause of forwarding plane failures.
>>>
>>>
>>>You have a point. MTU information, in either direction, can be useful in
>>>debugging
>>>both control and forwarding plane failures. The paragraph should read as
>>>follows in
>>>both 3.13 and 3.14:
>>>
>>>Justification: MTU information is sometimes useful in identifying
>>>the root cause of forwarding and control plane failures.
>>>
>>>
>>>
>>>>- Again, Section 3, 14):
>>>>      14) When tracing through the forwarding plane, display the MTU
>>>>      associated with each hop in the reverse direction.
>>>>  Meanwhile, in Section 4.3:
>>>>      The protocol must be stateless. That is, nodes should not have to
>>>>      maintain state between successive traceroute messages.
>>>>  Are you assuming the probe and response messages are always
>>
>>hop-by-hop
>>
>>>>  addressed? Otherwise, the forwarding and reverse paths of
>>
>>transporting
>>
>>>>  the probe & response pair could differ, e.g., due to the Internet
>>>>  routing, or policies. And -
>>>>  Do we need a same transport path for them? If so, how a stateless
>>>>  traceroute protocol knows the reverse path to forward the response
>>>>  message?  Probably we could create a temporary state while handling a
>>>>  probe message, to include P_HOP & Interface information like in RSVP,
>>>>  although the state is used only once in this case.
>>>
>>>
>>>Requirements 13 and 14 are ambiguous. As a result, you have interpretted
>>>them
>>>in a manner that was not intended. They should be restated as follows:
>>>
>>>13) When tracing through the control plane, display the MTU
>>
>>associated with
>>
>>>interface
>>>that forwards datagrams through the traced path.
>>>
>>>14) When tracing through the forwarding plane, display the MTU
>>
>>associated
>>
>>>with each
>>>interface that receives datagtrams along the traced path.
>>>
>>>
>>>
>>>>- Section 4.1 - I don't understand the following sentense:
>>>>                             Many network forward datagrams
>>
>>that specify
>>
>>>>    IP options differently than they would forward datagrams
>>
>>that do not
>>
>>>>    specify IP options.
>>>>  Maybe they ==> them, but the implication of this sentense is still
>>>>  unclear to me.
>>>
>>>
>>>This paragraph should read as follows:
>>>
>>>Many networks forward datagrams that specify IP options differently than
>>>they would forward datagrams that do not specify IP options. Therefore,
>>>the introductions of IP options would cause the application to trace a
>>>forwarding path other than the path that its user intended to trace.
>>>
>>>
>>>
>>>>- Section 4.2 "IP was _disqualified_ in order to conserve protocol
>>>>   identifiers." - I'm not sure this is always valid. Anyway,
>>>>   using UDP would have also to request a port number from IANA; there
>>>>   is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP
>>>>   type. BTW, UDP may introduce a little (although minor)
>>>>   additional overhead.
>>>
>>>
>>>IANA is much more willing to assign UDP port numbers than protocol-IDs.
>>>This is because there are so many more UDP port numbers available.
>>>
>>>
>>>
>>>>- In general I would expect the document would not constrain too much
>>>>  on protocol details - the latter looks to me more of a protocol
>>>>  design issue, instead of an informational RFC on "requirement".
>>>
>>>
>>>In principle, I agree. Section 4 provides just enough protocol
>>
>>requirements
>>
>>>to keep protocol designers away from some known bad design
>>
>>approaches. For
>>
>>>example,
>>>years ago we tried returning MPLS information in ICMP
>>
>>datagrams. This wasn't
>>
>>>well received. So, the requirements document guides us around that bad
>>>approach.
>>>
>>>
>>>
>>>>- It looks better if an experimental traceroute protocol (RFC1393 -
>>>>  traceroute using an IP option) would be referenced and shortly
>>>>  introduced in Section 2 (e.g., MTU determination).
>>>
>>>
>>>I thought about referencing RFC 1393 but decided not to because
>>
>>it is not
>>
>>>widely known or implemented.
>>>
>>>                                             Ron
>>>
>>>
>>>
>>>>My 2 cents.
>>>>
>>>>Xiaoming
>>>>
>>>>Ron Bonica wrote:
>>>>
>>>>
>>>>>Folks,
>>>>>
>>>>>At the request of the IESG, I have updated
>>
>>draft-ietf-ccamp-tracereq and
>>
>>>>>sent a new copy to the draft editor. Until the draft editor
>>>>
>>>>posts it, a copy
>>>>
>>>>
>>>>>can be found at
>>>
>>>http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt.
>>>
>>>
>>>>Please take a look, as this draft will need to go through
>>
>>another WG last
>>
>>>>call.
>>>>
>>>>===========================================
>>>>Ronald P. Bonica       Ph: 703 886 1681
>>>>vBNS Engineering       page: 1 888 268 8021
>>>>Ashburn, Va.
>>>>===========================================
>>>>"We are not on Earth to guard a museum, but
>>>>to cultivate a flourishing garden of life."
>>>>               -- Angelo Giuseppe Roncalli
>>>>
>>>>
>>
>>
> 

Delivery-date: Fri, 06 Jun 2003 02:46:57 +0000
Date: Thu, 05 Jun 2003 22:42:02 -0400
From: Ron Bonica <[email-masked]>
Subject: RE: draft-ietf-ccamp-tracereq
To: Xiaoming Fu <[email-masked]>
Cc: [email-masked]

Xiaoming,

I am not familiar with any traceroute implementations that use TCP. Could
you point me at a reference?

Why would TCP be preferable to UDP. Since you only expect one response to
each probe, what value would TCP add?

                                                            Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Xiaoming Fu
> Sent: Wednesday, June 04, 2003 6:12 AM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: Re: draft-ietf-ccamp-tracereq
>
>
> Ron,
>
> Thanks for your new version. One more issue:
>
> Current available transport mechanisms for traceroute include ICMP, UDP,
> and TCP. UDP may relief DoS issues, but NAT/firewall might be another
> issue (although we could have STUN). TCP has an issue of connection
> setup latency, however it could be potentially considered (it may also
> have a number of available ports?). To my knowledge, circulations from
> one protocol to protocol are sometimes helpful, for example, SIP
> initially used UDP, while TCP was recently proposed.
>
> Hence, I would suggest a "SHOULD" instead of "MUST" in Section 4.2.
>
> Cheers,
> Xiaoming
>
> Ron Bonica wrote:
> > Xiaoming,
> >
> > Thanks for the thorough review. A new version of the draft is
> available at
> > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-04.txt.
> >
> >                               Ron
> >
> >
> >
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]]On
> >>Behalf Of Xiaoming Fu
> >>Sent: Friday, May 30, 2003 7:20 PM
> >>To: Ron Bonica
> >>Cc: [email-masked]
> >>Subject: Re: draft-ietf-ccamp-tracereq
> >>
> >>
> >>Ron,
> >>
> >>It is a nice document. I went it through and have a few comments:
> >>
> >>- Section 3, 9) - "forwarding plane failu res" ==> _failures_
> >
> >
> > Oops....
> >
> >
> >>- I didn't understand why the following paragraph appears twice - the
> >>   same in Section 3, 13) and 14). I assume you're talking about control
> >>   plane failure in 13).
> >>       Justification: MTU information is sometimes useful in identifying
> >>       the root cause of forwarding plane failures.
> >
> >
> > You have a point. MTU information, in either direction, can be useful in
> > debugging
> > both control and forwarding plane failures. The paragraph should read as
> > follows in
> > both 3.13 and 3.14:
> >
> > Justification: MTU information is sometimes useful in identifying
> > the root cause of forwarding and control plane failures.
> >
> >
> >>- Again, Section 3, 14):
> >>       14) When tracing through the forwarding plane, display the MTU
> >>       associated with each hop in the reverse direction.
> >>   Meanwhile, in Section 4.3:
> >>       The protocol must be stateless. That is, nodes should not have to
> >>       maintain state between successive traceroute messages.
> >>   Are you assuming the probe and response messages are always
> hop-by-hop
> >>   addressed? Otherwise, the forwarding and reverse paths of
> transporting
> >>   the probe & response pair could differ, e.g., due to the Internet
> >>   routing, or policies. And -
> >>   Do we need a same transport path for them? If so, how a stateless
> >>   traceroute protocol knows the reverse path to forward the response
> >>   message?  Probably we could create a temporary state while handling a
> >>   probe message, to include P_HOP & Interface information like in RSVP,
> >>   although the state is used only once in this case.
> >
> >
> > Requirements 13 and 14 are ambiguous. As a result, you have interpretted
> > them
> > in a manner that was not intended. They should be restated as follows:
> >
> > 13) When tracing through the control plane, display the MTU
> associated with
> > interface
> > that forwards datagrams through the traced path.
> >
> > 14) When tracing through the forwarding plane, display the MTU
> associated
> > with each
> > interface that receives datagtrams along the traced path.
> >
> >
> >>- Section 4.1 - I don't understand the following sentense:
> >>                              Many network forward datagrams
> that specify
> >>     IP options differently than they would forward datagrams
> that do not
> >>     specify IP options.
> >>   Maybe they ==> them, but the implication of this sentense is still
> >>   unclear to me.
> >
> >
> > This paragraph should read as follows:
> >
> > Many networks forward datagrams that specify IP options differently than
> > they would forward datagrams that do not specify IP options. Therefore,
> > the introductions of IP options would cause the application to trace a
> > forwarding path other than the path that its user intended to trace.
> >
> >
> >>- Section 4.2 "IP was _disqualified_ in order to conserve protocol
> >>    identifiers." - I'm not sure this is always valid. Anyway,
> >>    using UDP would have also to request a port number from IANA; there
> >>    is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP
> >>    type. BTW, UDP may introduce a little (although minor)
> >>    additional overhead.
> >
> >
> > IANA is much more willing to assign UDP port numbers than protocol-IDs.
> > This is because there are so many more UDP port numbers available.
> >
> >
> >>- In general I would expect the document would not constrain too much
> >>   on protocol details - the latter looks to me more of a protocol
> >>   design issue, instead of an informational RFC on "requirement".
> >
> >
> > In principle, I agree. Section 4 provides just enough protocol
> requirements
> > to keep protocol designers away from some known bad design
> approaches. For
> > example,
> > years ago we tried returning MPLS information in ICMP
> datagrams. This wasn't
> > well received. So, the requirements document guides us around that bad
> > approach.
> >
> >
> >>- It looks better if an experimental traceroute protocol (RFC1393 -
> >>   traceroute using an IP option) would be referenced and shortly
> >>   introduced in Section 2 (e.g., MTU determination).
> >
> >
> > I thought about referencing RFC 1393 but decided not to because
> it is not
> > widely known or implemented.
> >
> >                                              Ron
> >
> >
> >>My 2 cents.
> >>
> >>Xiaoming
> >>
> >>Ron Bonica wrote:
> >>
> >>>Folks,
> >>>
> >>>At the request of the IESG, I have updated
> draft-ietf-ccamp-tracereq and
> >>>sent a new copy to the draft editor. Until the draft editor
> >>
> >>posts it, a copy
> >>
> >>>can be found at
> >
> > http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt.
> >
> >>Please take a look, as this draft will need to go through
> another WG last
> >>call.
> >>
> >>===========================================
> >>Ronald P. Bonica       Ph: 703 886 1681
> >>vBNS Engineering       page: 1 888 268 8021
> >>Ashburn, Va.
> >>===========================================
> >>"We are not on Earth to guard a museum, but
> >>to cultivate a flourishing garden of life."
> >>                -- Angelo Giuseppe Roncalli
> >>
> >>
>
>

Delivery-date: Thu, 05 Jun 2003 19:32:32 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "CCAMP" <[email-masked]>
Cc: "Tom Nadeau" <[email-masked]>, "Monique J. Morrow" <[email-masked]>
Subject: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue Call for Papers
Date: Thu, 5 Jun 2003 12:30:22 -0700

Folks,

The IEEE Communications Magazine has just approved the publication of
a Feature Topic issue on "OAM-in MPLS-based Networks." The CFP is
attached below.

We invite those working in this area to consider sending in
their contributions. If you intend to submit a paper for this
special issue, please drop one of the Guest Editors a note, so that
we can plan the issue.

We look forward to your participation!

Thanks,
-Vishal

*************************************
Vishal Sharma
Metanoia, Inc.
http://www.metanoia-inc.com
*************************************

====================================================================
CALL FOR PAPERS
IEEE Communications Magazine

Feature Topic on "OAM in MPLS-Based Networks"
**********************************************

As carriers and service providers converge multiple services and
associated networks on to an MPLS-based infrastructure, OAM functionality
becomes pivotal for enabling them to provide service level agreement
(SLA) guarantees, service assurance, quality of service (QoS) assurance
and overall interworking service management.  The advent of new applications
of MPLS such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3
Virtual Private Networks (L3VPNs) also means the emergence of added OAM
requirements from operators deploying those networks. As a result, providers
today require more efficient means of monitoring network health,
performance, and robustness, and of quickly identifying and resolving
performance problems. This is leading to the emergence of improved or
novel tools and techniques, whose goal is to improve security and
billing/accounting, aid in verifying QoS commitments, and reduce
operating costs. Standards organizations such as the IETF and the
ITU have in the recent past done significant work in this area, and
this subject is also being investigated by the IEEE and the Metro
Ethernet Forum.

This feature topic issue of the IEEE Communications Magazine has
a dual focus: to highlight operator requirements and deployment
experiences with OAM in MPLS-based networks, and to present a
survey of the current engineering and research developments in
this area.

Thus, focused tutorial and survey contributions as well as
research papers are solicited on (but not limited to) the following:

* Operational consequences of inadequate OAM capabilities
* Service provider requirements for efficient OAM - current operational
  needs and future demands
* Deployment experiences with OAM over MPLS-based networks
* Overview or comparative analysis of different
  approaches/philosophies for OAM
* Standards activities
	o Emerging architectures
	o New mechanisms for OAM in development
         (e.g. IETF LSP ping, ITU-T Y.1711, virtual circuit
         connection verification (VCCV))
* Platform support for OAM
* OAM impact on edge services (such as metro Ethernet)
  using MPLS transport
* Interoperability issues, interworking with
  other technologies (e.g. ATM)
* Review of current research in the area - E.g. setting
  parameters for connectivity verification and their impact on
  LSP recovery, trade-offs between bandwidth usage by OAM traffic
  and efficiency of failure/anomaly detection, and results from testbed
  deployments or simulations

On-line CFP with submission instructions can be found at:
http://www.comsoc.org/pubs/commag/cfpcommag1004.htm

Submission

Articles should be tutorial in nature and should be written in
a style comprehensible to readers outside the specialty of the article.
Articles may be edited for clarity and grammatical accuracy, and
will be copyedited according to the Magazine's style. Mathematical
equations should not be used (in justified cases up to three simple
equations could be allowed, provided the consent of the Guest Editor;
more than three equations require permission from the Editor-in-Chief).
Articles should have no more than 4,500 words, no more than 6
tables/figures, and no more than 15 references. Guidelines for prospective
authors can be found on-line at:
http://www.comsoc.org/pubs/commag/sub_guidelines.html.
Please submit no later than November 30, 2003. Accepted papers will
also be included in Communications Interactive (CI), the online version
of Communications Magazine.

Schedule:

Manuscript Due:                November 30, 2003
Acceptance Notification:       February 28, 2004
Final Manuscript Due:          April 15, 2004
Publication Date:              October 2004

Guest Editors:

Monique J. Morrow
Cisco Systems, Inc.
Glatt-com
CH-8301 Glattzentrum
Switzerland

Email: [email-masked]

Tom Nadeau
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824, USA.

Email: [email-masked]

Vishal Sharma
Metanoia, Inc.
1600 Villa Street, Unit 352
Mountain View, CA 94041, USA.

Email: [email-masked]

About the IEEE Communications Magazine:

The IEEE Comm. Mag. is the official technical publication of
conferences such as Supercomm, and has the unique distinction of
being the most widely read IEEE journal, with its over 50,000 paid
subscribers representing key communications engineers and
technical managers in our industry. More information
on the IEEE Comm. Mag., may be found here:
www.comsoc.org/adv/pp/Adpp2003revisedweb.ppt

Delivery-date: Thu, 05 Jun 2003 14:27:48 +0000
From: "hnaser" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Failure rate
Date: Thu, 5 Jun 2003 10:24:16 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C32B4C.9E2FFDC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Greeting,

=20

I would like to receive your comments on the following questions. What =
is a
typical range for fiber failure rate? Is it safe to assume that it is =
around
500 FITS per mile (or 5e-7 failures/mile/hour)? Secondly, is it just the
fiber cut the main source for fiber failure? If you know any
document/paper/page that discusses the above you would kindly let me =
know.

=20

Thank you. =20

=20

Hassan Naser, Ph.D.

University of Ottawa
School of Information Technology and Engineering (SITE)
800 King Edward Avenue
Ottawa, Ontario, Canada, K1N 6N5=20
Tel: (613) 562-5800 ext. 2123
Fax: (613) 562-5664
Email: [email-masked] <mailto:hnaser@s>=20

=20

=20

------=_NextPart_000_0008_01C32B4C.9E2FFDC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

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

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:Arial;}
p.MsoTitle, li.MsoTitle, div.MsoTitle
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	font-size:16.0pt;
	font-family:Arial;
	font-weight:bold;}
p.MsoSubtitle, li.MsoSubtitle, div.MsoSubtitle
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	font-size:12.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.Title1, li.Title1, div.Title1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	font-size:20.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
p.Subtitle1, li.Subtitle1, div.Subtitle1
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	font-size:14.0pt;
	font-family:"Times New Roman";}
span.EmailStyle21
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Greeting,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I would like to receive your comments on the =
following questions.
What is a typical range for fiber failure rate? Is it safe to assume =
that it is
around 500 FITS per mile (or 5e-7 failures/mile/hour)? Secondly, is it =
just the
fiber cut the main source for fiber failure? If you know any
document/paper/page that discusses the above you would kindly let me =
know.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thank you. &nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hassan Naser, Ph.D.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
  font-family:Arial'>University</span></font><font size=3D2 =
face=3DArial><span
 style=3D'font-size:10.0pt;font-family:Arial'> of </span></font><font =
size=3D2
  face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Ottawa</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><br>
</span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
  Arial'>School</span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:
 10.0pt;font-family:Arial'> of </span></font><font size=3D2 =
face=3DArial><span
  =
style=3D'font-size:10.0pt;font-family:Arial'>Information</span></font><fo=
nt
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> Technology
and Engineering (SITE)<br>
</span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
  Arial'>800 King Edward Avenue</span></font><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><br>
</span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
  Arial'>Ottawa</span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:
 10.0pt;font-family:Arial'>, </span></font><font size=3D2 =
face=3DArial><span
  =
style=3D'font-size:10.0pt;font-family:Arial'>Ontario</span></font><font =
size=3D2
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>, =
</span></font><font
  size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Canada</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>, K1N 6N5 <br>
Tel: (613) 562-5800 ext. 2123<br>
Fax: (613) 562-5664<br>
Email: [email-masked]</span></font><a =
href=3D"mailto:hnaser@s"><br>
<br>
</a></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New =
Roman">&nbsp;</font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0008_01C32B4C.9E2FFDC0--

Delivery-date: Wed, 04 Jun 2003 16:26:52 +0000
Date: Wed, 04 Jun 2003 10:25:08 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Stephen Shew <[email-masked]>
CC: "'Kireeti Kompella'" <[email-masked]>, [email-masked], "Wijnen, Bert" <[email-masked]>, [email-masked], "Ronald P. Bonica" <[email-masked]>
Subject: Re: ASON RSVP-TE extensions

All,
Stephen has is right, but I'd like to add a little background.
"Alternative Approval Process" is a misleadling name for newcomers
who might ask "Alternative to what?"

Prior to this, we had a "Traditional Approval Process" (TAP) that
involved proposing the text at one full study group meeting, and
approving it at the next one, usually 8-10 months later. This
gave the member states (governments, the ones with the greater
power in ITU) the opportunity to decide on national positions before
approving documents.

While this was an appropriate procedure for documents with
regulatory or tarriff implications, it was a bit heavyweight for
a purely technical document where the member states would typically
not develop a national position. This motivated development of
the lighter weight "alternative" in A.8. But don't be fooled
by the word "alternative" that this is any kind of unusual
shortcut. This is now the way we NORMALLY approve technical
Recommendations in ITU-T.

The next point is that all of the A series Recommendations (which
document ITU-T procedures - kind of like ITU-T's RFC 2026) are
available for free download to anyone from the TSAG web site:
http://www.itu.int/ITU-T/tsag/index.asp
These are not "members only" or subscription download like many
other ITU-T documents. This is where you can find Recommendation
A.8 (describing AAP) among other procedure type documents.
Regards,
Steve

> Stephen Shew wrote:
> 
> I'll attempt (with help from Peter Wery and Malcolm Betts) to explain what is meant by "consent".  It is a state of a document which reflects agreement by all participants within a group.  Within
> the ITU-T there are Study Groups (14 of them).  Within a Study Group (SG) there are Working Parties (WPs), and each Working Party has rapporteur groups called "Questions".  Consent is agreement at
> the Study Group level that a Recommendation is complete. This causes the Director to initiate last call (across all SGs), if no substantive comments are received then the Recommendation is approved.
> 
> The term 'Consent' is used in the context of the ITU-T 'Alternate Approval Process' (AAP), described in Recommendation A.8.  The AAP is, for most Study Groups developing technical Recommendations,
> now the rule rather than the exception.
> 
> Consent can be reached at a stand-alone WP meeting or at a SG meeting (mostly the case in SG 15).  In this context consent means that the WP or SG is of the opinion that the draft Recommendation
> text is mature and should be submitted to the AAP, with the expectation that it will be approved without further comments.
> 
> Prior to consent by a stand-alone WP or a SG, the Rapporteur Group, and in case of consent at a SG, also the WP 'propose' the draft text for consent at the higher level (Rapp. Group --> WP; WP -->
> SG).  Actual formal consent is then given at the highest level meeting, either stand-alone WP or SG meeting, usually at the closing plenary session.
> 
> My experience with the consent process is quite positive.  Unlike other SDOs, there is no voting.  Anyone can object and block the consent process.  This motivates the group to resolve problems.  At
> the SG level, representation is by county and so consent by a Study Group reflects an international level of understanding.
> 
> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Friday, May 30, 2003 18:46
> To: [email-masked]
> Cc: Stephen Trowbridge; Wijnen, Bert; [email-masked]; Ronald P. Bonica; Kireeti Kompella
> Subject: ASON RSVP-TE extensions
> 
> Hi All,
> 
> We would like to send the following as a Liaison to the ITU-T from the CCAMP WG.
> 
> Please comment on the text.  Ideally, we would like to send this out before the interim meeting in Chicago, and discuss it there.
> 
> It would be helpful in this context to know what it means procedurally that a document "has been consented" in the ITU.
> 
> Kireeti.

Delivery-date: Wed, 04 Jun 2003 15:47:49 +0000
From: "Stephen Shew" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Cc: Stephen Trowbridge <[email-masked]>, "Wijnen, Bert" <[email-masked]>, [email-masked], "Ronald P. Bonica" <[email-masked]>
Subject: RE: ASON RSVP-TE extensions
Date: Wed, 4 Jun 2003 11:44:21 -0400 

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_01C32AB0.2A888D8E
Content-Type: text/plain

I'll attempt (with help from Peter Wery and Malcolm Betts) to explain what
is meant by "consent".  It is a state of a document which reflects agreement
by all participants within a group.  Within the ITU-T there are Study Groups
(14 of them).  Within a Study Group (SG) there are Working Parties (WPs),
and each Working Party has rapporteur groups called "Questions".  Consent is
agreement at the Study Group level that a Recommendation is complete. This
causes the Director to initiate last call (across all SGs), if no
substantive comments are received then the Recommendation is approved.

The term 'Consent' is used in the context of the ITU-T 'Alternate Approval
Process' (AAP), described in Recommendation A.8.  The AAP is, for most Study
Groups developing technical Recommendations, now the rule rather than the
exception.

Consent can be reached at a stand-alone WP meeting or at a SG meeting
(mostly the case in SG 15).  In this context consent means that the WP or SG
is of the opinion that the draft Recommendation text is mature and should be
submitted to the AAP, with the expectation that it will be approved without
further comments.

Prior to consent by a stand-alone WP or a SG, the Rapporteur Group, and in
case of consent at a SG, also the WP 'propose' the draft text for consent at
the higher level (Rapp. Group --> WP; WP --> SG).  Actual formal consent is
then given at the highest level meeting, either stand-alone WP or SG
meeting, usually at the closing plenary session.

My experience with the consent process is quite positive.  Unlike other
SDOs, there is no voting.  Anyone can object and block the consent process.
This motivates the group to resolve problems.  At the SG level,
representation is by county and so consent by a Study Group reflects an
international level of understanding.

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Friday, May 30, 2003 18:46
To: [email-masked]
Cc: Stephen Trowbridge; Wijnen, Bert; [email-masked]; Ronald P. Bonica;
Kireeti Kompella
Subject: ASON RSVP-TE extensions

Hi All,

We would like to send the following as a Liaison to the ITU-T from the CCAMP
WG.

Please comment on the text.  Ideally, we would like to send this out before
the interim meeting in Chicago, and discuss it there.

It would be helpful in this context to know what it means procedurally that
a document "has been consented" in the ITU.

Kireeti.

------_=_NextPart_001_01C32AB0.2A888D8E
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 RSVP-TE extensions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I'll attempt (with help from Peter Wery and Malcolm =
Betts) to explain what is meant by &quot;consent&quot;.&nbsp; It is a =
state of a document which reflects agreement by all participants within =
a group.&nbsp; Within the ITU-T there are Study Groups (14 of =
them).&nbsp; Within a Study Group (SG) there are Working Parties (WPs), =
and each Working Party has rapporteur groups called =
&quot;Questions&quot;.&nbsp; Consent is agreement at the Study Group =
level that a Recommendation is complete. This causes the Director to =
initiate last call (across all SGs), if no substantive comments are =
received then the Recommendation is approved.</FONT></P>

<P><FONT SIZE=3D2>The term 'Consent' is used in the context of the =
ITU-T 'Alternate Approval Process' (AAP), described in Recommendation =
A.8.&nbsp; The AAP is, for most Study Groups developing technical =
Recommendations, now the rule rather than the exception.</FONT></P>

<P><FONT SIZE=3D2>Consent can be reached at a stand-alone WP meeting or =
at a SG meeting (mostly the case in SG 15).&nbsp; In this context =
consent means that the WP or SG is of the opinion that the draft =
Recommendation text is mature and should be submitted to the AAP, with =
the expectation that it will be approved without further =
comments.</FONT></P>

<P><FONT SIZE=3D2>Prior to consent by a stand-alone WP or a SG, the =
Rapporteur Group, and in case of consent at a SG, also the WP 'propose' =
the draft text for consent at the higher level (Rapp. Group --&gt; WP; =
WP --&gt; SG).&nbsp; Actual formal consent is then given at the highest =
level meeting, either stand-alone WP or SG meeting, usually at the =
closing plenary session.</FONT></P>

<P><FONT SIZE=3D2>My experience with the consent process is quite =
positive.&nbsp; Unlike other SDOs, there is no voting.&nbsp; Anyone can =
object and block the consent process.&nbsp; This motivates the group to =
resolve problems.&nbsp; At the SG level, representation is by county =
and so consent by a Study Group reflects an international level of =
understanding.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kireeti Kompella [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 30, 2003 18:46</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: Stephen Trowbridge; Wijnen, Bert; [email-masked]; =
Ronald P. Bonica; Kireeti Kompella</FONT>
<BR><FONT SIZE=3D2>Subject: ASON RSVP-TE extensions</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>We would like to send the following as a Liaison to =
the ITU-T from the CCAMP WG.</FONT>
</P>

<P><FONT SIZE=3D2>Please comment on the text.&nbsp; Ideally, we would =
like to send this out before the interim meeting in Chicago, and =
discuss it there.</FONT></P>

<P><FONT SIZE=3D2>It would be helpful in this context to know what it =
means procedurally that a document &quot;has been consented&quot; in =
the ITU.</FONT>
</P>

<P><FONT SIZE=3D2>Kireeti.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C32AB0.2A888D8E--

Delivery-date: Wed, 04 Jun 2003 13:19:12 +0000
content-class: urn:content-classes:message
Subject: Wavelength encoding: question on lmp-mib
Date: Wed, 4 Jun 2003 09:17:56 -0400
From: "Udo Neustadter" <[email-masked]>
To: <[email-masked]>

The LMP draft and the lmp mib draft specify the use of "wavelength" in
various places. I could not find anywhere but in the lmpTeLinkWavelength
object a description of what exactly the "wavelength" field must
contain. The description below strikes me as the ITU grid DWDM 100 GHz
spacing and better does have wavelengths with overlapping manometer
values (wavelengths 1538.19 and 1538.98 both yield 1538, 1542.14 and
1542.94 both yield 1542, etc.).=20
Does that mean that this draft does not support ITU grid DWDM 100 GHz
spacing?
Or, should I change my interpretation of the text below?
Is there another place that defines the exact encoding of the wavelength
fields in LMP and GMPLS (TE LSAs and RSVP-TE objects)?=20

lmpTeLinkWavelength OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "This value corresponds to the wavelength at
        which the Test messages will be transmitted over and is
        measured in nanometers (nm). If each data-bearing link
        corresponds to a separate wavelength, than this value should
        be set to 0."
   REFERENCE
       "Link Management Protocol, RFC xxx"
       -- RFC Editor to fill in RFC number that will be assigned to
       -- [LMP]
   ::=3D { lmpLinkVerificationEntry 6 }

Regards,
Udo

Delivery-date: Wed, 04 Jun 2003 10:14:40 +0000
Date: Wed, 04 Jun 2003 12:11:54 +0200
From: Xiaoming Fu <[email-masked]>
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ccamp-tracereq

Ron,

Thanks for your new version. One more issue:

Current available transport mechanisms for traceroute include ICMP, UDP, 
and TCP. UDP may relief DoS issues, but NAT/firewall might be another 
issue (although we could have STUN). TCP has an issue of connection 
setup latency, however it could be potentially considered (it may also 
have a number of available ports?). To my knowledge, circulations from 
one protocol to protocol are sometimes helpful, for example, SIP 
initially used UDP, while TCP was recently proposed.

Hence, I would suggest a "SHOULD" instead of "MUST" in Section 4.2.

Cheers,
Xiaoming

Ron Bonica wrote:
> Xiaoming,
> 
> Thanks for the thorough review. A new version of the draft is available at
> http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-04.txt.
> 
>                               Ron
> 
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On
>>Behalf Of Xiaoming Fu
>>Sent: Friday, May 30, 2003 7:20 PM
>>To: Ron Bonica
>>Cc: [email-masked]
>>Subject: Re: draft-ietf-ccamp-tracereq
>>
>>
>>Ron,
>>
>>It is a nice document. I went it through and have a few comments:
>>
>>- Section 3, 9) - "forwarding plane failu res" ==> _failures_
> 
> 
> Oops....
> 
> 
>>- I didn't understand why the following paragraph appears twice - the
>>   same in Section 3, 13) and 14). I assume you're talking about control
>>   plane failure in 13).
>>       Justification: MTU information is sometimes useful in identifying
>>       the root cause of forwarding plane failures.
> 
> 
> You have a point. MTU information, in either direction, can be useful in
> debugging
> both control and forwarding plane failures. The paragraph should read as
> follows in
> both 3.13 and 3.14:
> 
> Justification: MTU information is sometimes useful in identifying
> the root cause of forwarding and control plane failures.
> 
> 
>>- Again, Section 3, 14):
>>       14) When tracing through the forwarding plane, display the MTU
>>       associated with each hop in the reverse direction.
>>   Meanwhile, in Section 4.3:
>>       The protocol must be stateless. That is, nodes should not have to
>>       maintain state between successive traceroute messages.
>>   Are you assuming the probe and response messages are always hop-by-hop
>>   addressed? Otherwise, the forwarding and reverse paths of transporting
>>   the probe & response pair could differ, e.g., due to the Internet
>>   routing, or policies. And -
>>   Do we need a same transport path for them? If so, how a stateless
>>   traceroute protocol knows the reverse path to forward the response
>>   message?  Probably we could create a temporary state while handling a
>>   probe message, to include P_HOP & Interface information like in RSVP,
>>   although the state is used only once in this case.
> 
> 
> Requirements 13 and 14 are ambiguous. As a result, you have interpretted
> them
> in a manner that was not intended. They should be restated as follows:
> 
> 13) When tracing through the control plane, display the MTU associated with
> interface
> that forwards datagrams through the traced path.
> 
> 14) When tracing through the forwarding plane, display the MTU associated
> with each
> interface that receives datagtrams along the traced path.
> 
> 
>>- Section 4.1 - I don't understand the following sentense:
>>                              Many network forward datagrams that specify
>>     IP options differently than they would forward datagrams that do not
>>     specify IP options.
>>   Maybe they ==> them, but the implication of this sentense is still
>>   unclear to me.
> 
> 
> This paragraph should read as follows:
> 
> Many networks forward datagrams that specify IP options differently than
> they would forward datagrams that do not specify IP options. Therefore,
> the introductions of IP options would cause the application to trace a
> forwarding path other than the path that its user intended to trace.
> 
> 
>>- Section 4.2 "IP was _disqualified_ in order to conserve protocol
>>    identifiers." - I'm not sure this is always valid. Anyway,
>>    using UDP would have also to request a port number from IANA; there
>>    is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP
>>    type. BTW, UDP may introduce a little (although minor)
>>    additional overhead.
> 
> 
> IANA is much more willing to assign UDP port numbers than protocol-IDs.
> This is because there are so many more UDP port numbers available.
> 
> 
>>- In general I would expect the document would not constrain too much
>>   on protocol details - the latter looks to me more of a protocol
>>   design issue, instead of an informational RFC on "requirement".
> 
> 
> In principle, I agree. Section 4 provides just enough protocol requirements
> to keep protocol designers away from some known bad design approaches. For
> example,
> years ago we tried returning MPLS information in ICMP datagrams. This wasn't
> well received. So, the requirements document guides us around that bad
> approach.
> 
> 
>>- It looks better if an experimental traceroute protocol (RFC1393 -
>>   traceroute using an IP option) would be referenced and shortly
>>   introduced in Section 2 (e.g., MTU determination).
> 
> 
> I thought about referencing RFC 1393 but decided not to because it is not
> widely known or implemented.
> 
>                                              Ron
> 
> 
>>My 2 cents.
>>
>>Xiaoming
>>
>>Ron Bonica wrote:
>>
>>>Folks,
>>>
>>>At the request of the IESG, I have updated draft-ietf-ccamp-tracereq and
>>>sent a new copy to the draft editor. Until the draft editor
>>
>>posts it, a copy
>>
>>>can be found at
> 
> http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt.
> 
>>Please take a look, as this draft will need to go through another WG last
>>call.
>>
>>===========================================
>>Ronald P. Bonica       Ph: 703 886 1681
>>vBNS Engineering       page: 1 888 268 8021
>>Ashburn, Va.
>>===========================================
>>"We are not on Earth to guard a museum, but
>>to cultivate a flourishing garden of life."
>>                -- Angelo Giuseppe Roncalli
>>
>>

Delivery-date: Tue, 03 Jun 2003 14:42:06 +0000
From: "Hamid Ould-Brahim" <[email-masked]>
To: Ron Bonica <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt
Date: Tue, 3 Jun 2003 10:16:38 -0400 

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

Okay.
 
Hamid.

That is exactly the intent of requirements 7 and 8. 
 
Requirement 7 says that you can trace through type of tunnel (e.g., GRE,
MPLS). Requirement 8 says that you can trace through heterogeneous, nested
tunnels. This should include any X over any Y as well as any Y over any X.
It should also support multiple levels of nesting (X over Y over Z).

Ron

-----Original Message-----
From: Hamid Ould-Brahim [mailto:[email-masked]]
Sent: Tuesday, June 03, 2003 9:38 AM
To: Ron Bonica; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt

Ron, 

This is a good document. I just have one clarification/comment: 

in the draft: 

"7) Support the following tunneling technologies: GRE, MPLS, IPSEC, 
      GMPLS, IP-in-IP, L2TP. Be easily extensible to support new tunnel 
      technologies." 

and req. 8 on heterogeneous tunnels. 

I assume the tracing doesn't preclude the case where the IP 
tunnels are carrying MPLS-in-IP or MPLS-in-GRE encapsulation. 

Should that be explicitly mentioned (since it has implication 
on the type)?. 

Hamid. 

> 
> Pleae review this version. It is the most recent. 
> 
>                                 Ron 
> 
> > -----Original Message----- 
> > From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On 
> > Behalf Of [email-masked] 
> > Sent: Tuesday, June 03, 2003 7:46 AM 
> > To: IETF-Announce: 
> > Cc: [email-masked] 
> > Subject: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt 
> > 
> > 
> > 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           : Tracing Requirements for Generic Tunnels 
> >     Author(s)       : R. Bonica, K. Kompella, D. Meyer 
> >     Filename        : draft-ietf-ccamp-tracereq-04.txt 
> >     Pages           : 9 
> >     Date            : 2003-6-2 
> >     
> > This document specifies requirements for a generic route-tracing 
> > application.  It also specifies requirements for a protocol 
> that will 
> > support that application. Network operators will use the generic 
> > route-tracing application to verify proper operation of the IP 
> > forwarding plane. They will also use the application to discover 
> > details regarding tunnels that support IP forwarding. 
> > The generic route-tracing application, specified herein, supports a 
> > superset of the functionality that 'traceroute' currently offers. 
> > Like traceroute, the generic route-tracing application can discover 
> > the forwarding path between two interfaces that are contained by an 
> > IP network. Unlike traceroute, this application can reveal details 
> > regarding tunnels that support the IP forwarding path. 
> > 
> > A URL for this Internet-Draft is: 
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.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-tracereq-04.txt". 
> > 
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>  
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail. 
> > 
> > Send a message to: 
> >     [email-masked]. 
> > In the body type: 
> >     "FILE /internet-drafts/draft-ietf-ccamp-tracereq-04.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_001_01C329DA.BE4122D8
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>RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt</TITLE>

<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D130021514-03062003><FONT face=3D"Courier New"=20
size=3D2>Okay.</FONT></SPAN></DIV>
<DIV><SPAN class=3D130021514-03062003><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D130021514-03062003><FONT face=3D"Courier New"=20
size=3D2>Hamid.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D965474913-03062003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D965474913-03062003>That=20
  is exactly the intent of requirements 7 and 8. </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D965474913-03062003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D965474913-03062003>Requirement 7 says that you can trace =
through type of=20
  tunnel (e.g., GRE, MPLS). Requirement 8 says that you can trace =
through=20
  heterogeneous, nested tunnels. This should include any&nbsp;X over =
any&nbsp;Y=20
  as well as any Y over any X. It should also support multiple levels =
of nesting=20
  (X over Y over Z).</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D965474913-03062003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  =
class=3D965474913-03062003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&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; Ron</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D965474913-03062003></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Hamid =
Ould-Brahim=20
    [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, June =
03, 2003=20
    9:38 AM<BR><B>To:</B> Ron Bonica; =
[email-masked]<BR><B>Subject:</B> RE:=20
    I-D ACTION:draft-ietf-ccamp-tracereq-04.txt<BR><BR></FONT></DIV>
    <P><FONT size=3D2>Ron,</FONT> </P>
    <P><FONT size=3D2>This is a good document. I just have one=20
    clarification/comment:</FONT> </P>
    <P><FONT size=3D2>in the draft: </FONT></P>
    <P><FONT size=3D2>"7) Support the following tunneling technologies: =
GRE, MPLS,=20
    IPSEC,</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
GMPLS,=20
    IP-in-IP, L2TP. Be easily extensible to support new tunnel</FONT> =
<BR><FONT=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; technologies."</FONT> </P>
    <P><FONT size=3D2>and req. 8 on heterogeneous tunnels.</FONT> </P>
    <P><FONT size=3D2>I assume the tracing doesn't preclude the case =
where the=20
    IP</FONT> <BR><FONT size=3D2>tunnels are carrying MPLS-in-IP or =
MPLS-in-GRE=20
    encapsulation.</FONT> </P>
    <P><FONT size=3D2>Should that be explicitly mentioned (since it has =

    implication</FONT> <BR><FONT size=3D2>on the type)?.</FONT> </P>
    <P><FONT size=3D2>Hamid.</FONT> </P>
    <P><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Pleae review =
this version.=20
    It is the most recent.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    =
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;=20
    Ron</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
&gt;=20
    -----Original Message-----</FONT> <BR><FONT size=3D2>&gt; &gt; =
From:=20
    [email-masked] [<A=20
    =
href=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]On</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; Behalf Of =
[email-masked]</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; Sent: Tuesday, June 03, 2003 7:46 =
AM</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; To: IETF-Announce:</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; Cc: [email-masked]</FONT> <BR><FONT size=3D2>&gt; &gt; =
Subject: I-D=20
    ACTION:draft-ietf-ccamp-tracereq-04.txt</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
    </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; =
&gt; A New=20
    Internet-Draft is available from the on-line </FONT><BR><FONT =
size=3D2>&gt;=20
    &gt; Internet-Drafts directories.</FONT> <BR><FONT size=3D2>&gt; =
&gt; This=20
    draft is a work item of the Common Control and Measurement =
</FONT><BR><FONT=20
    size=3D2>&gt; &gt; Plane Working Group of the IETF.</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
&nbsp;&nbsp;&nbsp;=20
    Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Tracing=20
    Requirements for Generic Tunnels</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
    &nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
R.=20
    Bonica, K. Kompella, D. Meyer</FONT> <BR><FONT size=3D2>&gt; &gt;=20
    &nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :=20
    draft-ietf-ccamp-tracereq-04.txt</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
    &nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 9</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; &nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2003-6-2</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; </FONT><BR><FONT =
size=3D2>&gt; &gt; This=20
    document specifies requirements for a generic route-tracing</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; application.&nbsp; It also specifies =
requirements for a=20
    protocol </FONT><BR><FONT size=3D2>&gt; that will</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; support that application. Network operators will use the =
generic</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; route-tracing application to verify =
proper=20
    operation of the IP</FONT> <BR><FONT size=3D2>&gt; &gt; forwarding =
plane. They=20
    will also use the application to discover</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
    details regarding tunnels that support IP forwarding.</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; The generic route-tracing application, specified =
herein,=20
    supports a</FONT> <BR><FONT size=3D2>&gt; &gt; superset of the =
functionality=20
    that 'traceroute' currently offers.</FONT> <BR><FONT size=3D2>&gt; =
&gt; Like=20
    traceroute, the generic route-tracing application can =
discover</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; the forwarding path between two =
interfaces that=20
    are contained by an</FONT> <BR><FONT size=3D2>&gt; &gt; IP network. =
Unlike=20
    traceroute, this application can reveal details</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; regarding tunnels that support the IP forwarding path.</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; A URL for =
this=20
    Internet-Draft is:</FONT> <BR><FONT size=3D2>&gt; &gt; <A =
target=3D_blank=20
    =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04=
.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.=
txt</A></FONT>=20
    <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; To =
remove=20
    yourself from the IETF Announcement list, send a </FONT><BR><FONT=20
    size=3D2>&gt; message to </FONT><BR><FONT size=3D2>&gt; &gt;=20
    ietf-announce-request with the word unsubscribe in the body of=20
    </FONT><BR><FONT size=3D2>&gt; &gt; the message.</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Internet-Drafts are also =
available by=20
    anonymous FTP. Login with </FONT><BR><FONT size=3D2>&gt; &gt; the=20
    username</FONT> <BR><FONT size=3D2>&gt; &gt; "anonymous" and a =
password of=20
    your e-mail address. After logging in,</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
    type "cd internet-drafts" and then</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
    &nbsp;&nbsp;&nbsp; "get draft-ietf-ccamp-tracereq-04.txt".</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; A list of =
Internet-Drafts=20
    directories can be found in</FONT> <BR><FONT size=3D2>&gt; &gt; <A=20
    target=3D_blank=20
    =
href=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html=
</A>=20
    </FONT><BR><FONT size=3D2>&gt; &gt; or <A target=3D_blank=20
    =
href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ie=
tf/1shadow-sites.txt</A></FONT>=20
    <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt;=20
    </FONT><BR><FONT size=3D2>&gt; &gt; Internet-Drafts can also be =
obtained by=20
    e-mail.</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
    Send a message to:</FONT> <BR><FONT size=3D2>&gt; &gt; =
&nbsp;&nbsp;&nbsp;=20
    [email-masked].</FONT> <BR><FONT size=3D2>&gt; &gt; In the body=20
    type:</FONT> <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; "FILE=20
    /internet-drafts/draft-ietf-ccamp-tracereq-04.txt".</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
    NOTE:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The mail server at =
ietf.org can=20
    return the document in</FONT> <BR><FONT size=3D2>&gt; &gt; =
&nbsp;&nbsp;&nbsp;=20
    MIME-encoded form by using the "mpack" utility.&nbsp; To use =
this</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; feature, insert the =
command=20
    "ENCODING mime" before the "FILE"</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
    &nbsp;&nbsp;&nbsp; command.&nbsp; To decode the response(s), you =
will need=20
    "munpack" or</FONT> <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
a=20
    MIME-compliant mail reader.&nbsp; Different MIME-compliant =
</FONT><BR><FONT=20
    size=3D2>&gt; mail readers</FONT> <BR><FONT size=3D2>&gt; &gt;=20
    &nbsp;&nbsp;&nbsp; exhibit different behavior, especially when =
dealing=20
    with</FONT> <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
"multipart" MIME=20
    messages (i.e. documents which have been split</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; &nbsp;&nbsp;&nbsp; up into multiple messages), so check your =
local=20
    documentation on</FONT> <BR><FONT size=3D2>&gt; &gt; =
&nbsp;&nbsp;&nbsp; how to=20
    manipulate these messages.</FONT> <BR><FONT size=3D2>&gt; &gt;=20
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    </FONT><BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp;=20
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
    Below is the data which will enable a MIME compliant mail =
reader</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; implementation to automatically =
retrieve the=20
    ASCII version of the</FONT> <BR><FONT size=3D2>&gt; &gt;=20
    Internet-Draft.</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C329DA.BE4122D8--

Delivery-date: Tue, 03 Jun 2003 14:07:26 +0000
Date: Tue, 03 Jun 2003 10:03:43 -0400
From: Ron Bonica <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt
To: Hamid Ould-Brahim <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_CcVaiTxxars4sYmiILz+Kw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txtHamid,

That is exactly the intent of requirements 7 and 8.

Requirement 7 says that you can trace through type of tunnel (e.g., GRE,
MPLS). Requirement 8 says that you can trace through heterogeneous, nested
tunnels. This should include any X over any Y as well as any Y over any X.
It should also support multiple levels of nesting (X over Y over Z).

Ron

  -----Original Message-----
  From: Hamid Ould-Brahim [mailto:[email-masked]]
  Sent: Tuesday, June 03, 2003 9:38 AM
  To: Ron Bonica; [email-masked]
  Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt

  Ron,

  This is a good document. I just have one clarification/comment:

  in the draft:

  "7) Support the following tunneling technologies: GRE, MPLS, IPSEC,
        GMPLS, IP-in-IP, L2TP. Be easily extensible to support new tunnel
        technologies."

  and req. 8 on heterogeneous tunnels.

  I assume the tracing doesn't preclude the case where the IP
  tunnels are carrying MPLS-in-IP or MPLS-in-GRE encapsulation.

  Should that be explicitly mentioned (since it has implication
  on the type)?.

  Hamid.

  >
  > Pleae review this version. It is the most recent.
  >
  >                                 Ron
  >
  > > -----Original Message-----
  > > From: [email-masked] [mailto:[email-masked]]On
  > > Behalf Of [email-masked]
  > > Sent: Tuesday, June 03, 2003 7:46 AM
  > > To: IETF-Announce:
  > > Cc: [email-masked]
  > > Subject: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt
  > >
  > >
  > > 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           : Tracing Requirements for Generic Tunnels
  > >     Author(s)       : R. Bonica, K. Kompella, D. Meyer
  > >     Filename        : draft-ietf-ccamp-tracereq-04.txt
  > >     Pages           : 9
  > >     Date            : 2003-6-2
  > >
  > > This document specifies requirements for a generic route-tracing
  > > application.  It also specifies requirements for a protocol
  > that will
  > > support that application. Network operators will use the generic
  > > route-tracing application to verify proper operation of the IP
  > > forwarding plane. They will also use the application to discover
  > > details regarding tunnels that support IP forwarding.
  > > The generic route-tracing application, specified herein, supports a
  > > superset of the functionality that 'traceroute' currently offers.
  > > Like traceroute, the generic route-tracing application can discover
  > > the forwarding path between two interfaces that are contained by an
  > > IP network. Unlike traceroute, this application can reveal details
  > > regarding tunnels that support the IP forwarding path.
  > >
  > > A URL for this Internet-Draft is:
  > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.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-tracereq-04.txt".
  > >
  > > A list of Internet-Drafts directories can be found in
  > > http://www.ietf.org/shadow.html
  > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
  > >
  > >
  > > Internet-Drafts can also be obtained by e-mail.
  > >
  > > Send a message to:
  > >     [email-masked].
  > > In the body type:
  > >     "FILE /internet-drafts/draft-ietf-ccamp-tracereq-04.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.
  > >
  >

--Boundary_(ID_CcVaiTxxars4sYmiILz+Kw)
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><TITLE>RE: I-D =
ACTION:draft-ietf-ccamp-tracereq-04.txt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D965474913-03062003>Hamid,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D965474913-03062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D965474913-03062003>That=20
is exactly the intent of requirements 7 and 8. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D965474913-03062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D965474913-03062003>Requirement 7 says that you can trace through =
type of=20
tunnel (e.g., GRE, MPLS). Requirement 8 says that you can trace through=20
heterogeneous, nested tunnels. This should include any&nbsp;X over =
any&nbsp;Y as=20
well as any Y over any X. It should also support multiple levels of =
nesting (X=20
over Y over Z).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D965474913-03062003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D965474913-03062003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&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;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp; Ron</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D965474913-03062003></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Hamid Ould-Brahim=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, June 03, =
2003=20
  9:38 AM<BR><B>To:</B> Ron Bonica; =
[email-masked]<BR><B>Subject:</B> RE:=20
  I-D ACTION:draft-ietf-ccamp-tracereq-04.txt<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Ron,</FONT> </P>
  <P><FONT size=3D2>This is a good document. I just have one=20
  clarification/comment:</FONT> </P>
  <P><FONT size=3D2>in the draft: </FONT></P>
  <P><FONT size=3D2>"7) Support the following tunneling technologies: =
GRE, MPLS,=20
  IPSEC,</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GMPLS, =
IP-in-IP,=20
  L2TP. Be easily extensible to support new tunnel</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; technologies."</FONT> </P>
  <P><FONT size=3D2>and req. 8 on heterogeneous tunnels.</FONT> </P>
  <P><FONT size=3D2>I assume the tracing doesn't preclude the case where =
the=20
  IP</FONT> <BR><FONT size=3D2>tunnels are carrying MPLS-in-IP or =
MPLS-in-GRE=20
  encapsulation.</FONT> </P>
  <P><FONT size=3D2>Should that be explicitly mentioned (since it has=20
  implication</FONT> <BR><FONT size=3D2>on the type)?.</FONT> </P>
  <P><FONT size=3D2>Hamid.</FONT> </P>
  <P><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Pleae review =
this version.=20
  It is the most recent.</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;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Ron</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; =

  -----Original Message-----</FONT> <BR><FONT size=3D2>&gt; &gt; From:=20
  [email-masked] [<A=20
  =
href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>]On</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; Behalf Of [email-masked]</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Sent: Tuesday, June 03, 2003 7:46 AM</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; To: IETF-Announce:</FONT> <BR><FONT size=3D2>&gt; =
&gt; Cc:=20
  [email-masked]</FONT> <BR><FONT size=3D2>&gt; &gt; Subject: I-D=20
  ACTION:draft-ietf-ccamp-tracereq-04.txt</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; =
&gt; A New=20
  Internet-Draft is available from the on-line </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  Internet-Drafts directories.</FONT> <BR><FONT size=3D2>&gt; &gt; This =
draft is a=20
  work item of the Common Control and Measurement </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt; Plane Working Group of the IETF.</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Tracing Requirements for =
Generic=20
  Tunnels</FONT> <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp;=20
  Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : R. Bonica, K. =
Kompella, D.=20
  Meyer</FONT> <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp;=20
  Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :=20
  draft-ietf-ccamp-tracereq-04.txt</FONT> <BR><FONT size=3D2>&gt; &gt;=20
  &nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 9</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2003-6-2</FONT> <BR><FONT =

  size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; </FONT><BR><FONT size=3D2>&gt; =
&gt; This=20
  document specifies requirements for a generic route-tracing</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; application.&nbsp; It also specifies requirements =
for a=20
  protocol </FONT><BR><FONT size=3D2>&gt; that will</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; support that application. Network operators will use the =
generic</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; route-tracing application to verify =
proper=20
  operation of the IP</FONT> <BR><FONT size=3D2>&gt; &gt; forwarding =
plane. They=20
  will also use the application to discover</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  details regarding tunnels that support IP forwarding.</FONT> <BR><FONT =

  size=3D2>&gt; &gt; The generic route-tracing application, specified =
herein,=20
  supports a</FONT> <BR><FONT size=3D2>&gt; &gt; superset of the =
functionality=20
  that 'traceroute' currently offers.</FONT> <BR><FONT size=3D2>&gt; =
&gt; Like=20
  traceroute, the generic route-tracing application can discover</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; the forwarding path between two =
interfaces that are=20
  contained by an</FONT> <BR><FONT size=3D2>&gt; &gt; IP network. Unlike =

  traceroute, this application can reveal details</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; regarding tunnels that support the IP forwarding path.</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; A URL for this=20
  Internet-Draft is:</FONT> <BR><FONT size=3D2>&gt; &gt; <A =
target=3D_blank=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.=
txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.txt=
</A></FONT>=20
  <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; To =
remove=20
  yourself from the IETF Announcement list, send a </FONT><BR><FONT =
size=3D2>&gt;=20
  message to </FONT><BR><FONT size=3D2>&gt; &gt; ietf-announce-request =
with the=20
  word unsubscribe in the body of </FONT><BR><FONT size=3D2>&gt; &gt; =
the=20
  message.</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  Internet-Drafts are also available by anonymous FTP. Login with=20
  </FONT><BR><FONT size=3D2>&gt; &gt; the username</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; "anonymous" and a password of your e-mail address. After logging=20
  in,</FONT> <BR><FONT size=3D2>&gt; &gt; type "cd internet-drafts" and=20
  then</FONT> <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; "get=20
  draft-ietf-ccamp-tracereq-04.txt".</FONT> <BR><FONT size=3D2>&gt; &gt; =

  </FONT><BR><FONT size=3D2>&gt; &gt; A list of Internet-Drafts =
directories can be=20
  found in</FONT> <BR><FONT size=3D2>&gt; &gt; <A target=3D_blank=20
  =
href=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html<=
/A>=20
  </FONT><BR><FONT size=3D2>&gt; &gt; or <A target=3D_blank=20
  =
href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt</A></FONT>=20
  <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; Internet-Drafts can also be obtained by =
e-mail.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Send =
a message=20
  to:</FONT> <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp;=20
  [email-masked].</FONT> <BR><FONT size=3D2>&gt; &gt; In the body =
type:</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; "FILE=20
  /internet-drafts/draft-ietf-ccamp-tracereq-04.txt".</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; </FONT><BR><FONT size=3D2>&gt; =
&gt;=20
  NOTE:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The mail server at ietf.org =
can=20
  return the document in</FONT> <BR><FONT size=3D2>&gt; &gt; =
&nbsp;&nbsp;&nbsp;=20
  MIME-encoded form by using the "mpack" utility.&nbsp; To use =
this</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; feature, insert the =
command=20
  "ENCODING mime" before the "FILE"</FONT> <BR><FONT size=3D2>&gt; &gt;=20
  &nbsp;&nbsp;&nbsp; command.&nbsp; To decode the response(s), you will =
need=20
  "munpack" or</FONT> <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; a=20
  MIME-compliant mail reader.&nbsp; Different MIME-compliant =
</FONT><BR><FONT=20
  size=3D2>&gt; mail readers</FONT> <BR><FONT size=3D2>&gt; &gt; =
&nbsp;&nbsp;&nbsp;=20
  exhibit different behavior, especially when dealing with</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; "multipart" MIME messages (i.e. =
documents=20
  which have been split</FONT> <BR><FONT size=3D2>&gt; &gt; =
&nbsp;&nbsp;&nbsp; up=20
  into multiple messages), so check your local documentation on</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; how to manipulate these =
messages.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; Below is the data which will enable a MIME =
compliant mail=20
  reader</FONT> <BR><FONT size=3D2>&gt; &gt; implementation to =
automatically=20
  retrieve the ASCII version of the</FONT> <BR><FONT size=3D2>&gt; &gt;=20
  Internet-Draft.</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT></P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_CcVaiTxxars4sYmiILz+Kw)--

Delivery-date: Tue, 03 Jun 2003 13:38:34 +0000
From: "Hamid Ould-Brahim" <[email-masked]>
To: Ron Bonica <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt
Date: Tue, 3 Jun 2003 09:37:33 -0400 

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_01C329D5.494C6B86
Content-Type: text/plain;
	charset="iso-8859-1"

Ron,

This is a good document. I just have one clarification/comment:

in the draft: 

"7) Support the following tunneling technologies: GRE, MPLS, IPSEC,
      GMPLS, IP-in-IP, L2TP. Be easily extensible to support new tunnel
      technologies."

and req. 8 on heterogeneous tunnels.

I assume the tracing doesn't preclude the case where the IP
tunnels are carrying MPLS-in-IP or MPLS-in-GRE encapsulation.

Should that be explicitly mentioned (since it has implication
on the type)?.

Hamid.

> 
> Pleae review this version. It is the most recent.
> 
>                                 Ron
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of [email-masked]
> > Sent: Tuesday, June 03, 2003 7:46 AM
> > To: IETF-Announce:
> > Cc: [email-masked]
> > Subject: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt
> > 
> > 
> > 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		: Tracing Requirements for Generic Tunnels
> > 	Author(s)	: R. Bonica, K. Kompella, D. Meyer
> > 	Filename	: draft-ietf-ccamp-tracereq-04.txt
> > 	Pages		: 9
> > 	Date		: 2003-6-2
> > 	
> > This document specifies requirements for a generic route-tracing
> > application.  It also specifies requirements for a protocol 
> that will
> > support that application. Network operators will use the generic
> > route-tracing application to verify proper operation of the IP
> > forwarding plane. They will also use the application to discover
> > details regarding tunnels that support IP forwarding.
> > The generic route-tracing application, specified herein, supports a
> > superset of the functionality that 'traceroute' currently offers.
> > Like traceroute, the generic route-tracing application can discover
> > the forwarding path between two interfaces that are contained by an
> > IP network. Unlike traceroute, this application can reveal details
> > regarding tunnels that support the IP forwarding path.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.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-tracereq-04.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-ccamp-tracereq-04.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_001_01C329D5.494C6B86
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>This is a good document. I just have one =
clarification/comment:</FONT>
</P>

<P><FONT SIZE=3D2>in the draft: </FONT>
</P>

<P><FONT SIZE=3D2>&quot;7) Support the following tunneling =
technologies: GRE, MPLS, IPSEC,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GMPLS, IP-in-IP, =
L2TP. Be easily extensible to support new tunnel</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
technologies.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>and req. 8 on heterogeneous tunnels.</FONT>
</P>

<P><FONT SIZE=3D2>I assume the tracing doesn't preclude the case where =
the IP</FONT>
<BR><FONT SIZE=3D2>tunnels are carrying MPLS-in-IP or MPLS-in-GRE =
encapsulation.</FONT>
</P>

<P><FONT SIZE=3D2>Should that be explicitly mentioned (since it has =
implication</FONT>
<BR><FONT SIZE=3D2>on the type)?.</FONT>
</P>

<P><FONT SIZE=3D2>Hamid.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Pleae review this version. It is the most =
recent.</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;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Ron</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]On</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Behalf Of [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, June 03, 2003 7:46 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: IETF-Announce:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: I-D =
ACTION:draft-ietf-ccamp-tracereq-04.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; A New Internet-Draft is available from the =
on-line </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Internet-Drafts directories.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This draft is a work item of the Common =
Control and Measurement </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Plane Working Group of the IETF.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Tracing Requirements for =
Generic Tunnels</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : R. Bonica, K. Kompella, =
D. Meyer</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-ietf-ccamp-tracereq-04.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 9</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2003-6-2</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This document specifies requirements for a =
generic route-tracing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; application.&nbsp; It also specifies =
requirements for a protocol </FONT>
<BR><FONT SIZE=3D2>&gt; that will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; support that application. Network =
operators will use the generic</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; route-tracing application to verify proper =
operation of the IP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; forwarding plane. They will also use the =
application to discover</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; details regarding tunnels that support IP =
forwarding.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The generic route-tracing application, =
specified herein, supports a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; superset of the functionality that =
'traceroute' currently offers.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Like traceroute, the generic route-tracing =
application can discover</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the forwarding path between two interfaces =
that are contained by an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IP network. Unlike traceroute, this =
application can reveal details</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; regarding tunnels that support the IP =
forwarding path.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-t=
racereq-04.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To remove yourself from the IETF =
Announcement list, send a </FONT>
<BR><FONT SIZE=3D2>&gt; message to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ietf-announce-request with the word =
unsubscribe in the body of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the message.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Internet-Drafts are also available by =
anonymous FTP. Login with </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the username</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;anonymous&quot; and a password of =
your e-mail address. After logging in,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; type &quot;cd internet-drafts&quot; and =
then</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; &quot;get =
draft-ietf-ccamp-tracereq-04.txt&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; A list of Internet-Drafts directories can =
be found in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Internet-Drafts can also be obtained by =
e-mail.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Send a message to:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
[email-masked].</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In the body type:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; &quot;FILE =
/internet-drafts/draft-ietf-ccamp-tracereq-04.txt&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; NOTE:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The mail server at ietf.org can return the document in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; MIME-encoded form by =
using the &quot;mpack&quot; utility.&nbsp; To use this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; feature, insert the =
command &quot;ENCODING mime&quot; before the &quot;FILE&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; command.&nbsp; To =
decode the response(s), you will need &quot;munpack&quot; or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; a MIME-compliant mail =
reader.&nbsp; Different MIME-compliant </FONT>
<BR><FONT SIZE=3D2>&gt; mail readers</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; exhibit different =
behavior, especially when dealing with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; &quot;multipart&quot; =
MIME messages (i.e. documents which have been split</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; up into multiple =
messages), so check your local documentation on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; how to manipulate these =
messages.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Below is the data which will enable a MIME =
compliant mail reader</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; implementation to automatically retrieve =
the ASCII version of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Internet-Draft.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C329D5.494C6B86--

Delivery-date: Tue, 03 Jun 2003 12:56:47 +0000
Date: Tue, 03 Jun 2003 08:52:46 -0400
From: Ron Bonica <[email-masked]>
Subject: FW: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt
To: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_8kcYjPjn+uJkzpVgRacxgg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit

Folks,

Pleae review this version. It is the most recent.

                                Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Tuesday, June 03, 2003 7:46 AM
> To: IETF-Announce:
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt
> 
> 
> 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		: Tracing Requirements for Generic Tunnels
> 	Author(s)	: R. Bonica, K. Kompella, D. Meyer
> 	Filename	: draft-ietf-ccamp-tracereq-04.txt
> 	Pages		: 9
> 	Date		: 2003-6-2
> 	
> This document specifies requirements for a generic route-tracing
> application.  It also specifies requirements for a protocol that will
> support that application. Network operators will use the generic
> route-tracing application to verify proper operation of the IP
> forwarding plane. They will also use the application to discover
> details regarding tunnels that support IP forwarding.
> The generic route-tracing application, specified herein, supports a
> superset of the functionality that 'traceroute' currently offers.
> Like traceroute, the generic route-tracing application can discover
> the forwarding path between two interfaces that are contained by an
> IP network. Unlike traceroute, this application can reveal details
> regarding tunnels that support the IP forwarding path.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.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-tracereq-04.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ccamp-tracereq-04.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.
> 

--Boundary_(ID_8kcYjPjn+uJkzpVgRacxgg)
Content-type: Message/External-body; name=ATT00018.dat
Content-transfer-encoding: 7bit
Content-disposition: attachment; filename=ATT00018.dat

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-tracereq-04.txt

--Boundary_(ID_8kcYjPjn+uJkzpVgRacxgg)
Content-type: Message/External-body; name=draft-ietf-ccamp-tracereq-04.txt
Content-transfer-encoding: 7bit
Content-disposition: attachment; filename=draft-ietf-ccamp-tracereq-04.txt

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

--Boundary_(ID_8kcYjPjn+uJkzpVgRacxgg)--

Delivery-date: Tue, 03 Jun 2003 11:51:29 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-reqts-00.txt
Date: Tue, 03 Jun 2003 07:46:25 -0400

--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		: Requirements for Generalized MPLS (GMPLS) Usage and 
                          Extensions for Automatically Switched Optical Network 
                          (ASON)
      	Author(s)	: D. Papadimitriou et al.
	Filename	: draft-ietf-ccamp-gmpls-ason-reqts-00.txt
	Pages		: 11
	Date		: 2003-6-2
	
The Generalized MPLS (GMPLS) suite of protocol has been defined to
control different switching technologies as well as different
applications. These include support for requesting TDM connections
including SONET/SDH and Optical Transport Networks (OTNs).
This document concentrates on the signaling aspects of the GMPLS
suite of protocols. It identifies the features to be covered by the
signalling protocol to support the capabilities of an Automatically
Switched Optical Network (ASON). This document provides a problem
statement and additional requirements on the GMPLS signaling
protocol to support the ASON functionality.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-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-ccamp-gmpls-ason-reqts-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-reqts-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-reqts-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 03 Jun 2003 11:51:21 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt
Date: Tue, 03 Jun 2003 07:46:29 -0400

--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		: Tracing Requirements for Generic Tunnels
	Author(s)	: R. Bonica, K. Kompella, D. Meyer
	Filename	: draft-ietf-ccamp-tracereq-04.txt
	Pages		: 9
	Date		: 2003-6-2
	
This document specifies requirements for a generic route-tracing
application.  It also specifies requirements for a protocol that will
support that application. Network operators will use the generic
route-tracing application to verify proper operation of the IP
forwarding plane. They will also use the application to discover
details regarding tunnels that support IP forwarding.
The generic route-tracing application, specified herein, supports a
superset of the functionality that 'traceroute' currently offers.
Like traceroute, the generic route-tracing application can discover
the forwarding path between two interfaces that are contained by an
IP network. Unlike traceroute, this application can reveal details
regarding tunnels that support the IP forwarding path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.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-tracereq-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-tracereq-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-tracereq-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-tracereq-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Mon, 02 Jun 2003 14:15:14 +0000
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ASON reqts - Moving on?
Date: Mon, 2 Jun 2003 10:13:38 -0400

Thanks Kireeti,

> | 5. Those who think that ITU-T didn't get the requirements right, so we
> |    need to look at everything from scratch.
>
> This is explicitly *not* the intent.  A requirement goes into this
> document iff:
>   (a) the ITU-T says, "Yes, that's a requirement for ASON signaling"; and
>   (b) CCAMP and the ITU-T agree that GMPLS doesn't meet it.
>
> Requirements that are already met MAY be documented, but it is not a
> goal to capture all ASON requirements.

I agree with your statement of non-goal.

I would like to err on the side of documenting requirements that are already
met. It is much clearer that way and opens up (and so puts to bed firmly) any
debate about whether GMPLS *does* already meet the requirements.

Cheers,
Adrian

Delivery-date: Mon, 02 Jun 2003 13:01:16 +0000
Date: Mon, 02 Jun 2003 09:00:24 -0400
From: Ron Bonica <[email-masked]>
Subject: FW: I-D ACTION:draft-ietf-ccamp-tracereq-03.txt
To: [email-masked]

Folks,

Please disregard this 03 version. I have posted an 04 version to address
Xiaoming Fu's comments. The draft editor should announce it soon.

                                     Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Monday, June 02, 2003 7:29 AM
> To: IETF-Announce:
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-ccamp-tracereq-03.txt
>
>
> 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		: Tracing Requirements for Generic Tunnels
> 	Author(s)	: R. Bonica, K. Kompella, D. Meyer
> 	Filename	: draft-ietf-ccamp-tracereq-03.txt
> 	Pages		: 9
> 	Date		: 2003-5-30
>
> This document specifies requirements for a generic route-tracing
> application.  It also specifies requirements for a protocol that will
> support that application. Network operators will use the generic
> route-tracing application to verify proper operation of the IP
> forwarding plane. They will also use the application to discover
> details regarding tunnels that support IP forwarding.
> The generic route-tracing application, specified herein, supports a
> superset of the functionality that 'traceroute' currently offers.
> Like traceroute, the generic route-tracing application can discover
> the forwarding path between two interfaces that are contained by an
> IP network. Unlike traceroute, this application can reveal details
> regarding tunnels that support the IP forwarding path.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-03.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of
> the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with
> the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-ccamp-tracereq-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ccamp-tracereq-03.txt".
>
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

Delivery-date: Mon, 02 Jun 2003 11:31:04 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-tracereq-03.txt
Date: Mon, 02 Jun 2003 07:28:43 -0400

--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		: Tracing Requirements for Generic Tunnels
	Author(s)	: R. Bonica, K. Kompella, D. Meyer
	Filename	: draft-ietf-ccamp-tracereq-03.txt
	Pages		: 9
	Date		: 2003-5-30
	
This document specifies requirements for a generic route-tracing
application.  It also specifies requirements for a protocol that will
support that application. Network operators will use the generic
route-tracing application to verify proper operation of the IP
forwarding plane. They will also use the application to discover
details regarding tunnels that support IP forwarding.
The generic route-tracing application, specified herein, supports a
superset of the functionality that 'traceroute' currently offers.
Like traceroute, the generic route-tracing application can discover
the forwarding path between two interfaces that are contained by an
IP network. Unlike traceroute, this application can reveal details
regarding tunnels that support the IP forwarding path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-tracereq-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-tracereq-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-tracereq-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-tracereq-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 02 Jun 2003 11:30:57 +0000
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-mib-06.txt
Date: Mon, 02 Jun 2003 07:28:38 -0400

--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 et al.
	Filename	: draft-ietf-ccamp-lmp-mib-06.txt
	Pages		: 77
	Date		: 2003-5-30
	
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-06.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-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lmp-mib-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-mib-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--