Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 30 Jun 2003 10:44:17 +0000 Date: Mon, 30 Jun 2003 03:40:48 -0700 (PDT) From: Kireeti Kompella To: Jonathan Sadler cc: iesg@ietf.org, "" , "" Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Message-ID: <20030630033022.C32724@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jun 2003 14:38:16 +0000 Message-ID: <3EFC5640.A32C78C5@se.bel.alcatel.be> Date: Fri, 27 Jun 2003 16:35:44 +0200 From: Steffen Brockmann Organization: Alcatel MIME-Version: 1.0 To: George Swallow CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-gmpls-overlay-01 Content-Type: multipart/mixed; boundary="------------33ECE98309DB04B646B35351" 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:brockmas@se.bel.alcatel.be org;quoted-printable:
System
 =3BArchitecture
fn:Steffen Brockmann end:vcard --------------33ECE98309DB04B646B35351-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 27 Jun 2003 08:24:37 +0000 Message-ID: From: "Gudipalli, Sugadeesh" To: "'jplang@ieee.org'" Cc: "'ccamp@ops.ietf.org'" Subject: Question regarding Interface Switching Type sub object in LMP Date: Fri, 27 Jun 2003 04:24:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: ccamp-data@psg.com Delivery-date: Thu, 26 Jun 2003 19:26:39 +0000 Message-ID: <03df01c33c18$b8ef5480$681810ac@movaz.com> From: "Adrian Farrel" To: "Kireeti Kompella" Cc: 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" To: "Adrian Farrel" Cc: 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jun 2003 19:15:24 +0000 Date: Thu, 26 Jun 2003 12:12:23 -0700 (PDT) From: Kireeti Kompella To: Adrian Farrel cc: ccamp@ops.ietf.org Subject: Re: Time slots for CCAMP 57 Message-ID: <20030626115806.S18468@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jun 2003 10:19:59 +0000 Message-ID: <3EFAC862.6030807@alcatel.be> Date: Thu, 26 Jun 2003 12:18:10 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Yoshihiko SUEMURA Cc: Adrian Farrel , ccamp@ops.ietf.org, Jonathan Lang , Yakov Rekhter , adrian@olddog.co.uk Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed 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, > Dimitri.Papadimitriou@alcatel.be 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 : dimitri.papadimitriou@alcatel.be >>Private: http://www.rc.bel.alcatel.be/~papadimd/index.html >>E-mail : dpapadimitriou@psg.com >>Public : http://psg.com/~dpapadimitriou/ >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>Phone : +32 3 240-8491 >> >> > > > > ----------------------------------------------------------------- > Yoshihiko SUEMURA > > Networking Research Laboratories, > NEC Corporation > E-mail: y-suemura@bp.jp.nec.com > Phone: +81 44 856 8109, FAX: +81 44 856 8071 > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 26 Jun 2003 08:59:50 +0000 Date: Thu, 26 Jun 2003 17:57:05 +0900 From: Yoshihiko SUEMURA To: Dimitri.Papadimitriou@alcatel.be, Adrian Farrel Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt Cc: ccamp@ops.ietf.org, Jonathan Lang , Yakov Rekhter , adrian@olddog.co.uk Message-Id: <20030626171644.3FE5.Y-SUEMURA@bp.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dimitri, I have a question. Please see inline. On Wed, 25 Jun 2003 18:10:42 +0200, Dimitri.Papadimitriou@alcatel.be 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 : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > > ----------------------------------------------------------------- Yoshihiko SUEMURA Networking Research Laboratories, NEC Corporation E-mail: y-suemura@bp.jp.nec.com Phone: +81 44 856 8109, FAX: +81 44 856 8071 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jun 2003 19:43:57 +0000 Message-Id: <4.3.2.7.2.20030625083435.00b220d0@pilgrim.cisco.com> Date: Wed, 25 Jun 2003 08:54:41 -0400 To: brockmas@se.bel.alcatel.be From: George Swallow Subject: draft-ietf-ccamp-gmpls-overlay-01 Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jun 2003 16:12:10 +0000 Message-ID: <3EF9C982.6070509@alcatel.be> Date: Wed, 25 Jun 2003 18:10:42 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org, Jonathan Lang , Yakov Rekhter , adrian@olddog.co.uk Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed 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 : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jun 2003 15:50:10 +0000 Message-ID: <027901c33b31$2e6827c0$681810ac@movaz.com> From: "Adrian Farrel" To: Cc: "Jonathan Lang" , "Yakov Rekhter" , "Dimitri Papadimitriou" , 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 25 Jun 2003 13:10:44 +0000 thread-index: AcM7Gn9tOQrjijuZQemt9fhJ3fulvQ== Reply-To: Content-Class: urn:content-classes:message From: "Genadi Velev" To: Subject: extensions in GMPLS signalling for L2SC interfaces Date: Wed, 25 Jun 2003 15:05:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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:velev@panasonic.de WWW: http://www.pel.panasonic.de -------------------------------------------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 Jun 2003 18:02:14 +0000 From: "Richard Rabbat" To: "'Kireeti Kompella'" , "'Ronald Bonica'" Cc: Subject: Re: Time slots for CCAMP 57 Date: Tue, 24 Jun 2003 10:59:09 -0700 Message-ID: <002001c33a7a$500100d0$f83ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 Jun 2003 12:56:15 +0000 From: "Jonathan Lang" To: Cc: Subject: RE: LMP Link Verification Clarification requested Date: Tue, 24 Jun 2003 05:55:00 -0700 Message-ID: <003001c33a4f$d285d740$800101df@rinconnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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:rbradfor@cisco.com] > Sent: Tuesday, June 24, 2003 5:37 AM > To: Jonathan Lang > Cc: ccamp@ops.ietf.org > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 Jun 2003 12:39:38 +0000 Message-Id: <4.3.2.7.2.20030624074629.019217e8@pilgrim.cisco.com> Date: Tue, 24 Jun 2003 08:37:22 -0400 To: "Jonathan Lang" From: "Bradford, Richard" Subject: LMP Link Verification Clarification requested Cc: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_236468463==_.ALT" --=====================_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" 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 Jun 2003 10:50:36 +0000 Message-Id: <200306241049.GAA10614@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-23142250.I-D@ietf.org> 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: <2003-6-23142250.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 24 Jun 2003 10:39:26 +0000 Message-Id: <200306241036.GAA10081@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org, te-wg@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-23142125.I-D@ietf.org> 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: <2003-6-23142125.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 23 Jun 2003 19:04:30 +0000 Message-ID: <009b01c339ba$283b2190$681810ac@movaz.com> From: "Adrian Farrel" To: "Kireeti Kompella" , 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: ccamp-data@psg.com Delivery-date: Mon, 23 Jun 2003 19:04:01 +0000 Message-ID: <009801c339b9$e4e14f50$681810ac@movaz.com> From: "Adrian Farrel" To: , 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: To: Cc: ; 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: > mailserv@ietf.org. > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 23 Jun 2003 12:50:04 +0000 Message-ID: <3EF6F73D.7050505@cs.uni-goettingen.de> Date: Mon, 23 Jun 2003 14:49:01 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 MIME-Version: 1.0 To: Kireeti Kompella , Ron Bonica CC: ccamp@ops.ietf.org, Rene Soltwisch Subject: Re: Time slots for CCAMP 57 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 23 Jun 2003 05:20:22 +0000 Reply-To: From: "Vishal Sharma" To: "Ruiquan jing" , Subject: RE: Flooding using LMP extensions Date: Sun, 22 Jun 2003 22:15:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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:jingrq@ctbri.com.cn] > Sent: Sunday, June 22, 2003 8:10 PM > To: v.sharma@ieee.org; ccamp@ops.ietf.org > 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: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Vishal Sharma > Sent: Saturday, June 21, 2003 4:57 AM > To: Ong, Lyndon; rick king; Roberto Albanese; ccamp@ops.ietf.org > 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:LyOng@Ciena.com] > > Sent: Friday, June 20, 2003 11:05 AM > > To: 'v.sharma@ieee.org'; rick king; Roberto Albanese; ccamp@ops.ietf.org > > 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:v.sharma@ieee.org] > > Sent: Thursday, June 19, 2003 6:28 PM > > To: rick king; Roberto Albanese; ccamp@ops.ietf.org > > 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 > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jun 2003 20:59:06 +0000 Reply-To: From: "Vishal Sharma" To: "Ong, Lyndon" , "rick king" , "Roberto Albanese" , Subject: RE: Flooding using LMP extensions Date: Fri, 20 Jun 2003 13:56:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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:LyOng@Ciena.com] > Sent: Friday, June 20, 2003 11:05 AM > To: 'v.sharma@ieee.org'; rick king; Roberto Albanese; ccamp@ops.ietf.org > 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:v.sharma@ieee.org] > Sent: Thursday, June 19, 2003 6:28 PM > To: rick king; Roberto Albanese; ccamp@ops.ietf.org > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jun 2003 18:28:19 +0000 Message-Id: <200306201827.OAA23028@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-20140326.I-D@ietf.org> 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: <2003-6-20140326.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jun 2003 18:03:47 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A2501E4@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: "'v.sharma@ieee.org'" , rick king , Roberto Albanese , ccamp@ops.ietf.org Subject: RE: Flooding using LMP extensions Date: Fri, 20 Jun 2003 11:05:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:v.sharma@ieee.org] Sent: Thursday, June 19, 2003 6:28 PM To: rick king; Roberto Albanese; ccamp@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jun 2003 01:30:48 +0000 Reply-To: From: "Vishal Sharma" To: "rick king" , "Roberto Albanese" , Subject: RE: Flooding using LMP extensions Date: Thu, 19 Jun 2003 18:27:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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:ruiquan.jing@ties.itu.ch] > Sent: Thursday, June 19, 2003 6:02 PM > To: v.sharma@ieee.org; Roberto Albanese; ccamp@ops.ietf.org > 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:v.sharma@ieee.org] > Sent: Friday, June 20, 2003 1:55 AM > To: rick king; Roberto Albanese; ccamp@ops.ietf.org > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of rick king > > Sent: Thursday, June 19, 2003 2:13 AM > > To: v.sharma@ieee.org; Roberto Albanese; ccamp@ops.ietf.org > > 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: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Vishal Sharma > > Sent: Thursday, June 19, 2003 1:36 PM > > To: Roberto Albanese; ccamp@ops.ietf.org > > 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: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org]On Behalf Of > > Roberto Albanese > > Sent: Tuesday, June 17, 2003 10:50 AM > > To: ccamp@ops.ietf.org > > 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 > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 20 Jun 2003 01:07:03 +0000 From: "rick king" To: , "Roberto Albanese" , Subject: RE: Flooding using LMP extensions Date: Fri, 20 Jun 2003 09:02:14 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 VmlzaGFsLA0KDQpJIGRvbid0IHRoaW5rIFJDIGFuZCBSREIgb25seSBjb25jZXJuIGFib3V0IGEg bm9kZSBvciBhIHNtYWxsIGNvbGxlY3Rpb24gb2Ygbm9kZXMuIA0KRm9sbG93aW5ncyBhcmUgZnJv bSBJVFUtVCBHLjc3MTUgIHNlY3Rpb24gNS4yOg0KLS0tLS0tLS0tLS0tLS0tLS0tDQoxLglSb3V0 aW5nIENvbnRyb2xsZXIgliBUaGUgUkMgZnVuY3Rpb25zIGluY2x1ZGUgZXhjaGFuZ2luZyByb3V0 aW5nIGluZm9ybWF0aW9uIHdpdGggcGVlciBSQ3MgYW5kIHJlcGx5aW5nIHRvIGEgcm91dGUgcXVl cnkgKHBhdGggc2VsZWN0aW9uKSBieSBvcGVyYXRpbmcgb24gdGhlIFJvdXRpbmcgSW5mb3JtYXRp b24gRGF0YWJhc2UuICBUaGUgUkMgaXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQuDQoNCjIuCVJvdXRp bmcgSW5mb3JtYXRpb24gRGF0YWJhc2UgKFJEQikgLSBUaGUgUkRCIGlzIGEgcmVwb3NpdG9yeSBm b3IgdGhlIGxvY2FsIHRvcG9sb2d5LCBuZXR3b3JrIHRvcG9sb2d5LCByZWFjaGFiaWxpdHksIGFu ZCBvdGhlciByb3V0aW5nIGluZm9ybWF0aW9uIHRoYXQgaXMgdXBkYXRlZCBhcyBwYXJ0IG9mIHRo ZSByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlIGFuZCBtYXkgYWRkaXRpb25hbGx5IGNvbnRh aW4gaW5mb3JtYXRpb24gdGhhdCBpcyBjb25maWd1cmVkLiAgVGhlIFJEQiBtYXkgY29udGFpbiBy b3V0aW5nIGluZm9ybWF0aW9uIGZvciBtb3JlIHRoYW4gb25lIHJvdXRpbmcgYXJlYS4gIFRoZSBS b3V0aW5nIENvbnRyb2xsZXIgaGFzIGFjY2VzcyB0byBhIHZpZXcgb2YgdGhlIFJEQi4gIEZpZ3Vy ZSAyIGlsbHVzdHJhdGVzIHRoaXMgYnkgc2hvd2luZyBhIGRvdHRlZCBsaW5lIGFyb3VuZCB0aGUg UkMgYW5kIHRoZSBSREIuICBUaGlzIGRvdHRlZCBsaW5lIHNpZ25pZmllcyB0aGUgUkMgKGFzIGRl c2NyaWJlZCBpbiBHLjgwODApIGFzIGVuY2Fwc3VsYXRpbmcgYSB2aWV3IG9mIHRoZSBSREIuIFRo ZSBSREIgaXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQuDQoNCjMuTGluayBSZXNvdXJjZSBNYW5hZ2Vy IJYgVGhlIExSTSBzdXBwbGllcyBhbGwgdGhlIHJlbGV2YW50IFNOUFAgbGluayBpbmZvcm1hdGlv biB0byB0aGUgUm91dGluZyBDb250cm9sbGVyLiBJdCBpbmZvcm1zIHRoZSBSQyBhYm91dCBhbnkg c3RhdGUgY2hhbmdlcyBvZiB0aGUgbGluayByZXNvdXJjZXMgaXQgY29udHJvbHMuIA0KDQpOb3Rl IC0gU2luY2UgdGhlIFJEQiBtYXkgY29udGFpbiByb3V0aW5nIGluZm9ybWF0aW9uIHBlcnRhaW5p bmcgdG8gbXVsdGlwbGUgUm91dGluZyBBcmVhcyAoYW5kIGhlbmNlIHBvc3NpYmx5IG11bHRpcGxl IGxheWVyIG5ldHdvcmtzKSwgdGhlIHJvdXRpbmcgY29udHJvbGxlcnMgYWNjZXNzaW5nIHRoZSBS REIgbWF5IHNoYXJlIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uLiAgVGhpcyBpcyBpbGx1c3RyYXRl ZCBpbiBGaWd1cmUgMyBieSBzaG93aW5nIHRoZSBvdmVybGFwIGJldHdlZW4gdGhlIGRvdHRlZCBs aW5lcy4NCi0tLS0tLS0tLS0tLS0tLS0tDQoNCnJpY2sNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFZpc2hhbCBTaGFybWEgW21haWx0bzp2LnNoYXJtYUBpZWVlLm9yZ10NClNl bnQ6IEZyaWRheSwgSnVuZSAyMCwgMjAwMyAxOjU1IEFNDQpUbzogcmljayBraW5nOyBSb2JlcnRv IEFsYmFuZXNlOyBjY2FtcEBvcHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBGbG9vZGluZyB1c2lu ZyBMTVAgZXh0ZW5zaW9ucyANCg0KDQpSaWNrLA0KDQpDYW4geW91IGJlIG1vcmUgc3BlY2lmaWMs IGFuZCBwb2ludCB0byB0aGUgZXhhY3QgSVRVIGRvY3VtZW50DQphbmQgc2VjdGlvbiBudW1iZXJz IHlvdSdyZSByZWZlcnJpbmcgdG8gYmVsb3cuDQoNCkluIGFueSBjYXNlLCBJIHRoaW5rIHdoYXQg eW91J3JlIHJlZmVycmluZyB0byBiZWxvdyBvY2N1cnMNCndpdGhpbiBhIG5vZGUgKG9yIGEgc21h bGwgY29sbGVjdGlvbiBvZiBub2RlcyksIHdoZXJlYXMgd2hhdCB3ZSdyZQ0KZGlzY3Vzc2luZw0K aXMgbmV0d29yay13aWRlIG5vdGlmaWNhdGlvbi4NCg0KT25lIG9mIHRoZSBJVFUgZXhwZXJ0cyBj YW4gcHJvYmFibHkgZW5saWdodGVuIHVzIGZ1cnRoZXIsIGFuZCBjb3JyZWN0DQptZSBpZiBJJ20g d3JvbmcuDQoNCi1WaXNoYWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5v cmddT24NCj4gQmVoYWxmIE9mIHJpY2sga2luZw0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAxOSwg MjAwMyAyOjEzIEFNDQo+IFRvOiB2LnNoYXJtYUBpZWVlLm9yZzsgUm9iZXJ0byBBbGJhbmVzZTsg Y2NhbXBAb3BzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBGbG9vZGluZyB1c2luZyBMTVAgZXh0 ZW5zaW9ucw0KPg0KPg0KPiBNeSB0d28gY2VudHM6DQo+DQo+IFdpdGggSVRVLVQgZ2xvc3Nhcnks IEkgdGhpbmsgTFJNKExpbmsgUmVzb3VyY2UgTWFuYWdlcikgd2lsbA0KPiBkZXRlY3QgdGhlIGxp bmsgZmF1bHQgLA0KPiBhbmQgdGhlbiBub3RpZmllcyB0aGUgUkMoUm91dGluZyBDb250cm9sKSB0 byB1cGRhdGUgdGhlIFJEQi4NCj4NCj4gcmljaw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNCj4gW21haWx0bzpvd25lci1j Y2FtcEBvcHMuaWV0Zi5vcmddT24gQmVoYWxmIE9mIFZpc2hhbCBTaGFybWENCj4gU2VudDogVGh1 cnNkYXksIEp1bmUgMTksIDIwMDMgMTozNiBQTQ0KPiBUbzogUm9iZXJ0byBBbGJhbmVzZTsgY2Nh bXBAb3BzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBGbG9vZGluZyB1c2luZyBMTVAgZXh0ZW5z aW9ucw0KPg0KPg0KPiBIaSBSb2JlcnRvIGFuZCBOaWNvbGEsDQo+DQo+IFRoYW5rcyB2ZXJ5IG11 Y2ggZm9yIHlvdXIgb2JzZXJ2YXRpb25zIGFuZCBmb3IgeW91ciBkZXRhaWxlZA0KPiBhbmFseXNp cyBvZiB0aGUgaXNzdWVzLg0KPg0KPiBJIGNlcnRhaW5seSBzaGFyZSB5b3VyIHZpZXcgdGhhdCBh IGZsb29kaW5nLWJhc2VkIHNvbHV0aW9uIHRvIGZhdWx0DQo+IG5vdGlmaWNhdGlvbiBjYW4gcHJl c2VudCBzZXZlcmFsIGFkdmFudGFnZXMsIGFuZCBpcyBvbmUgdGhhdCB3ZSBzaG91bGQNCj4gY29u c2lkZXIgYXMgYSBjYW5kaWRhdGUgKHRvZ2V0aGVyIHdpdGggdGhlIHNpZ25hbGluZy1iYXNlZCBz b2x1dGlvbnMNCj4gcHJvcG9zZWQNCj4gc28gZmFyKS4NCj4NCj4gMSkgSW4gdGhhdCByZWdhcmQs IGl0IHdvdWxkIGJlIG5pY2UgdG8gZ2V0IHlvdXIgaW5wdXRzIG9uIGRyYWZ0LXJhYmJhdDoNCj4g aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmFiYmF0LWZhdWx0LW5v dGlmaWNhdGlvDQo+IG4tcHJvdG9jb2wNCj4gLTAyLnR4dA0KPiBzaW5jZSB0aGUgbWVjaGFuaXNt cyBwcm9wb3NlZCB0aGVyZSBhcmUgdGVjaG5vbG9neSwgcHJvdG9jb2wsIGFuZCB0b3BvbG9neQ0K PiBhZ25vc3RpYy4NCj4gRG8geW91LCBmb3IgaW5zdGFuY2UsIGFncmVlIHdpdGggdGhlIGJhc2lj IHByb3Bvc2FsIGluIHRoZXJlPyBEbyB5b3UNCj4gaGF2ZSBhbnkgZmVlZGJhY2ssIGFkZGl0aW9u cywgb3Igc3VnZ2VzdGlvbnMsIGJhc2VkIG9uIHlvdXIgZXhwZXJpZW5jZSBvZg0KPiBidWlsZGlu ZyB5b3VyIE1QTFMgdGVzdGJlZD8NCj4NCj4gMikgT24gdGhhdCBub3RlLCBJIHdhcyB3b25kZXJp bmcgaWYgeW91J2QgYWxyZWFkeSBtYWRlIHRoZSBtb2RpZmljYXRpb25zDQo+IHRvIE9TUEYgdGhh dCB5b3UgZGlzY3Vzc2VkIGluIHlvdXIgZW1haWwsIGFuZCBpZiB5b3UgaGF2ZSBhbnkNCj4gcGVy Zm9ybWFuY2UgcmVzdWx0cyB5b3UgbWlnaHQgYmUgYWJsZSB0byBzaGFyZSB3aXRoIHRoZSBXRy4N Cj4gKFJpY2hhcmQgaW4gb25lIG9mIGhpcyBlYXJsaWVyIGVtYWlscywgSSBiZWxpZXZlLCBtZW50 aW9uZWQgdGhhdCBoZQ0KPiBoYXMgc29tZSBwcm90b3R5cGluZyByZXN1bHRzIG9uIExNUCBwZXJm b3JtYW5jZS4pDQo+DQo+IDMpIEZpbmFsbHksIGhlcmUgYXJlIHNvbWUgcG9pbnRzIHRoYXQgSSdk IGxpa2UgdG8gZGlzY3VzcyByZWxhdGVkIHRvDQo+IHRoZSBpc3N1ZXMgaGlnaGxpZ2h0ZWQgaW4g eW91ciBlbWFpbC4NCj4NCj4gIGkpIEkgd2FudGVkIHRvIGFkZCB0aGF0IG5vdCBvbmx5IGNvdWxk IGZsb29kaW5nIG1pbmltaXplIHJvdXRpbmcgZmFpbHVyZQ0KPiAgICAgcHJvYmFiaWxpdHkgKGFz IHlvdSd2ZSBvYnNlcnZlZCksIGl0IGNvdWxkIGFsc28gc3BlZWQgdXAgcmVjb3ZlcnkNCj4gICAg IGJ5IG5vdGlmeWluZyAoaW4gcGFyYWxsZWwpDQo+ICAgICB0aGUgbm9kZXMgb24gbXVsdGlwbGUg cmVjb3ZlcnkgcGF0aHMgYWZmZWN0ZWQgYnkgYSBnaXZlbg0KPiBmYXVsdC4gVGhpcyBjYW4NCj4g ICAgIHByb3ZlIHZlcnkgYWR2YW50YWdlb3VzIHdoZW4gYSBsaW5rIGNhcnJpZXMgYSBsYXJnZSBu dW1iZXIgb2YNCj4gICAgIHRyYW5zcG9ydCBjaXJjdWl0cyAoZS5nLiBsYW1iZGFzKSwgYW5kIHdo ZW4gdGhlIExTUHMgZG8gbm90IHNoYXJlIHRoZQ0KPiAgICAgc2FtZSBzLWQgcGFpcnMuDQo+DQo+ ICBpaSkgSW4gcmVnYXJkIHRvIHRoZSBhcmd1bWVudCBmb3IgdXNpbmcgT1NQRiB0byBvYnRhaW4g YSBzb2x1dGlvbiB0aGF0DQo+IHdvcmtzDQo+ICAgICAgYm90aCBmb3IgTVBMUyBhbmQgR01QTFMs IG15IHRob3VnaHQgaXMgdGhhdCB0aGlzIGlzIG5vdA0KPiBjcml0aWNhbCwgc2luY2UNCj4gICAg ICB0aGUgcmVjb3ZlcnkgbWV0aG9kcyAoZS5nLiBmYXN0IHJlcm91dGUpIGF0IHRoZSBNUExTIGxh eWVyDQo+IGFyZSBhbHJlYWR5DQo+ICAgICAgd2VsbC1kZWZpbmVkIGFuZCBhcmUgbm90IGNvbW1v biB3aXRoIHRoZSByZWNvdmVyeSBtZXRob2RzIHVzZWQgYXQgdGhlDQo+ICAgICAgdHJhbnNwb3J0 IGxheWVyLiBUaHVzLCB0aGVyZSBpcyBsZXNzIG9mIGEgbmVlZCB0byBoYXZlIGENCj4gc29sdXRp b24gdGhhdA0KPiAgICAgIHdvcmtzIGFjcm9zcyBsYXllcnMgb2YgdGhlIG5ldHdvcmsgdXNpbmcg TVBMUyBhbmQgR01QTFMsDQo+IHJlc3BlY3RpdmVseS4NCj4gICAgICBPbiB0aGUgY29udHJhcnks IHRoZSAiY29zdCIgb2YgdHJ5aW5nIHRvIGluY29ycG9yYXRlIHRoZSBmYXVsdA0KPiBub3RpZmlj YXRpb24NCj4gICAgICBmdW5jdGlvbmFsaXR5IGluIGEgcm91dGluZyBwcm90b2NvbCwgbGlrZSBP U1BGLCBhbiBiZSBoZWF2eSAoYXMgSQ0KPiBleHBsYWluIGJlbG93KS4NCj4NCj4gIGlpaSkgVGhp cyBpcyBiZWNhdXNlIG9uZSBoYXMgdG8gZGV2ZWxvcCBzb2x1dGlvbnMgZm9yIG11bHRpcGxlIHJv dXRpbmcNCj4gcHJvdG9jb2xzDQo+ICAgICAgKGFzIG5vdCBldmVyeW9uZSB3aWxsIHVzZSBPU1BG KS4gTW9yZSBpbXBvcnRhbnRseSwgYSBzZXJ2aWNlIHByb3ZpZGVyDQo+IG5vdA0KPiAgICAgICBu b3JtYWxseSBydW5uaW5nIGEgcm91dGluZyBwcm90b2NvbCBhdCB0aGUgdHJhbnNwb3J0IGxheWVy DQo+IChidXQgdXNpbmcNCj4gTE1QDQo+ICAgICAgIGFuZCBHTVBMUyBzaWduYWxpbmcpLCB3b3Vs ZCBiZSBmb3JjZWQgdG8gcnVuIGEgcm91dGluZyBwcm90b2NvbCBqdXN0DQo+IGZvcg0KPiAgICAg ICBlZmZpY2llbnQgZmF1bHQgbm90aWZpY2F0aW9uISBUaGF0IHNlZW1zIGxpa2UgYW4gdW5kdWUg YnVyZGVuLg0KPiAgICAgICBGdXJ0aGVybW9yZSwgdW5saWtlIExNUCwgT1NQRiByZXF1aXJlcyBt b3JlIGludm9sdmVkIHByb2Nlc3NpbmcsDQo+IG1ha2luZyBpdA0KPiAgICAgICBkaWZmaWN1bHQg dG8gZW5zdXJlIHRoYXQgdGhlIGZhaWx1cmUtcmVsYXRlZCBtZXNzYWdlcyBhcmUgYWx3YXlzDQo+ IHByb2Nlc3NlZA0KPiAgICAgICBhbmQgZGlzcGF0Y2hlZCBfYmVmb3JlXyBvdGhlciBPU1BGIG1l c3NhZ2VzLg0KPg0KPiAgICAgICBBbHNvLCBpcnJlc3BlY3RpdmUgb2Ygd2hldGhlciBhIHByb3Zp ZGVyIHJ1bnMgcm91dGluZywgaXQgaXMgbGlrZWx5DQo+IHRoYXQNCj4gICAgICAgYSBHTVBMUy1j b250cm9sIHBsYW5lIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIgd2lsbCBhdCBsZWFzdCBydW4gTE1Q LA0KPiB0aHVzDQo+ICAgICAgIG1ha2luZyBpdCBhIG5hdHVyYWwgY2hvaWNlIHRvIGV4dGVuZCBm b3IgZmxvb2RpbmctYmFzZWQgZmF1bHQNCj4gbm90aWZpY2F0aW9uLg0KPg0KPiAgICAgICBPZiBj b3Vyc2UsIEkgd2VsY29tZSBzZXJ2aWNlIHByb3ZpZGVyIGlucHV0cyBvbiB0aGlzIGlzc3VlLCBh bmQgdGhleQ0KPiAgICAgICBjYW4gY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcuIDotKQ0KPg0KPg0K PiAgaXYpIEFuZCBmaW5hbGx5LCBpdCBhcHBlYXJzIHRoYXQgeW91IGFyZSBpbnNlcnRpbmcgdGhl IHRpbWVyDQo+IGZ1bmN0aW9uYWxpdHkNCj4gYW5kDQo+ICAgICAgaW5pdGlhbCBkZXRlY3Rpb24g ZnVuY3Rpb25hbGl0eSBpbiBMTVAgYW55d2F5LCBzbyBpbiB0aGUNCj4gbGlnaHQgb2YgKGlpaSkN Cj4gYWJvdmUsDQo+ICAgICAgd291bGRuJ3QgaXQgYmUgZWFzaWVyIGp1c3QgdG8gZXh0ZW5kIExN UC4gKFdpdGggcmVnYXJkIHRvDQo+IHRoZSBhcmd1bWVudA0KPiBvZiBPU1BGDQo+ICAgICAgZmxv b2RpbmcgYmVpbmcgbWF0dXJlLCBwZXJoYXBzIHdlIGNhbiBsZWFybiBmcm9tIHRoZSBsZXNzb25z DQo+IHRoZXJlLCBhbmQNCj4gbm90DQo+ICAgICAgcmVwZWF0IHRoZSBzYW1lIG1pc3Rha2VzIHdo ZW4gb3BlcmF0aW5nIExNUC4gOi0pKS4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiAtVmlzaGFsDQo+ DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG93bmVyLWNjYW1wQG9w cy5pZXRmLm9yZw0KPiBbbWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZ11PbiBCZWhhbGYg T2YNCj4gUm9iZXJ0byBBbGJhbmVzZQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDE3LCAyMDAzIDEw OjUwIEFNDQo+IFRvOiBjY2FtcEBvcHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEZsb29kaW5n IHVzaW5nIExNUCBleHRlbnNpb25zDQo+DQo+DQo+IEhpIGFsbCwNCj4gd2UgYXJlIHdvcmtpbmcg dG8gYSBNUExTIHRlc3RiZWQgc3VwcG9ydGluZyBlbmQtdG8tZW5kDQo+IFByb3RlY3Rpb24tUmVz dG9yYXRpb24gbWVjaGFuaXNtcyBhbmQgd2UgZmFjZWQgdGhlIHByb2JsZW0gb2YNCj4gbGluay1m YWlsdXJlcyBub3RpZmljYXRpb24uDQo+IFdlIHNoYXJlIHRoZSBzY2FsYWJpbGl0eSBjb25jZXJu cyBvZiBSU1ZQLWxpa2UNCj4gc29sdXRpb25zIHJlcG9ydGVkIGluIHRoZSBSYWJiYXQncyBtYWls Lg0KPiBXZSBhcmUgaW4gZmF2b3VyIG9mIE9TUEYgZmxvb2RpbmctYmFzZWQgbWVjaGFuaXNtcyBm b3IgbGluay1mYWlsdXJlcw0KPiB1c2luZyBPcGFxdWUgYmVjYXVzZToNCj4NCj4gLSAgYXBwbGlj YWJsZSB0byBib3RoIE1QTFMtVEUgLSBHTVBMUy4NCj4NCj4gLSAgUHJvdmVkIE9TUEYgcHJvdG9j b2wgc3RhYmlsaXR5IGFuZCByb2J1c3RuZXNzIHdpdGggcmVzcGVjdCB0byB0aGUgTE1QDQo+IHNv bHV0aW9uLg0KPiAgICBPU1BGIGZsb29kaW5nIGluIGdlbmVyYWwgaXMgbWF0dXJlLCBpbnN0ZWFk IExNUCBoYXMgdG8gYmUgZXh0ZW5kZWQNCj4gICAgYW5kIGl0IGhhcyB0byBzdXBwb3J0IHNvbWUg T1NQRiBjYXBhYmlsaXRpZXMgd2UgYWxyZWFkeSBoYXZlLg0KPg0KPiAtICBSZWR1Y3Rpb24gb2Yg cm91dGluZyBmYWlsdXJlIHByb2JhYmlsaXR5IHJlc3BlY3QgdG8gdGhlIHVzZSBvZg0KPiBSU1ZQ IChzZWUNCj4gYmVsb3cpLg0KPiAgICAgICBJbiBkcmFmdC1rYXR6LXlldW5nLW9zcGYtdHJhZmZp Yy0wOSBpdCBpcyB3cml0dGVuIHRoYXQgaW4gYSBURQ0KPiBzY2VuYXJpbw0KPiAgICAgICB3ZSBj YW4gaGF2ZSBhIG1vZHVsZSBpbiB0aGUgZWRnZSBub2RlcyB0aGF0IHNlYXJjaGVzIGNvbnN0cmFp bmVkDQo+IHJvdXRlcw0KPiAgICAgICBiYXNlZCBvbiBPcGFxdWUgVEUgaW5mby4NCj4gICAgICAg V2UgY2FsbCBhICJyb3V0aW5nIGZhaWx1cmUiIHRoZSBjb21wdXRhdGlvbiBieSBlZGdlIG5vZGUg WCBvZiBhIHBhdGgNCj4gICAgICAgd2hpY2ggaW5jbHVkZXMgYSBmYWlsZWQgbGluayBGLg0KPiAg ICAgICBDbGVhcmx5LCByb3V0aW5nIGZhaWx1cmVzIGFyZSBhIGNvbnNlcXVlbmNlIG9mIGxhY2sg b2Ygbm90aWZpY2F0aW9uLA0KPiAgICAgICB0byBYLCBvZiB0aGUgZmFpbHVyZSBvZiBGLg0KPiAg ICAgICBXaXRoIFJTVlAgZmFpbHVyZSBub3RpZmljYXRpb24sIHRoaXMgY2FuIG9jY3VyOg0KPiAg ICAgICAtICBpbiBjYXNlIG9mIHNpbmdsZSBmYXVsdCwgd2hlbiB0aGVyZSBhcmUgbm8gTFNQcyBv cmlnaW5hdGVkIGZyb20gWA0KPiBjcm9zc2luZyBGOw0KPiAgICAgICAtICBpbiBjYXNlIG9mIGR1 YWwgZmF1bHRzIChpLmUuLCB0d28gbGlua3MgTDEgYW5kIEwyIGZhaWxzIGFsbW9zdA0KPiBzaW11 bHRhbmVvdXNseSksDQo+ICAgICAgICAgIGlmIGZyb20gWCB0aGVyZSBpcyBhIExTUCBjcm9zc2lu ZyBib3RoIEwxIGFuZCBMMjoNCj4NCj4gICBYLS0tbGluay0tLS0tbm9kZS0tLS0tLWxpbmsoTDEp LS0tLS0tbm9kZS0tLS0tLS1saW5rKEwyKS0tLS0tZWdyZXNzX25vZGUNCj4NCj4gICAgICAgdGhl IGZhaWx1cmUgb2YgTDEgY2FuIGhpZGUgdGhlIG5vdGlmaWNhdGlvbiBvZiBMMiBmYWlsdXJlcy4N Cj4NCj4gICAgICAgSXQgY2FuIGJlIHNlZW4gdGhhdCB3aXRoIE9TUEYgZmxvb2RpbmcsIHRoZXJl IGlzIHZpcnR1YWxseSBubw0KPiBwb3RlbnRpYWwNCj4gICAgICAgcm91dGluZyBmYWlsdXJlIGF0 IGFsbCwgYXMgQUxMIHRoZSBlZGdlIG5vZGVzIGFyZSBub3RpZmllZCBhbnkNCj4gZmFpbHVyZS4N Cj4NCj4gICAgICAgU28gaWYgd2UgaGF2ZSBhIGZsb29kaW5nLWJhc2VkIG5vdGlmaWNhdGlvbiwg YWxsIHRoZSBlZGdlIG5vZGVzIGluIGENCj4gbmV0d29yaw0KPiAgICAgICB3aWxsIGJlIGF3YXJl IGFib3V0IHRoZSBmYWlsdXJlLiBJbnN0ZWFkLCB3aXRoIFJTVlAsIHdlJ2xsIGhhdmUNCj4gICAg ICAgb25seSBzb21lIG5vZGVzIGF3YXJlIG9mIHRoZSBmYWlsdXJlISBTbyB3ZSBoYXZlIGFuIGlu Y3JlYXNpbmcgb2YNCj4gICAgICAgcm91dGluZyBmYWlsdXJlIHByb2JhYmlsaXR5IGFmdGVyIGEg bGluayBmYWlsdXJlLg0KPg0KPiBXZSBhZ3JlZSB0aGF0IGEgbWFqb3IgZHJhd2JhY2sgb2YgdGhl IE9TUEYtZmxvb2Rpbmcgc29sdXRpb24gaXMNCj4gdGhlIG5lZWQgb2YNCj4gcmV2aXNpdGluZw0K PiB0aGUgdGltZXJzLCBhcyBwb2ludGVkIG91dCBpbiB0aGUgUmFiYmF0J3MgbWFpbDoiRmxvb2Rp bmcgdXNpbmcgTE1QDQo+IGV4dGVuc2lvbnMiLg0KPiBJbiBmYWN0IHdlIGNhbid0IHdhaXQgZm9y IGEgbWF4IHBlcmlvZCBvZiBNaW5MU0ludGVydmFsIHNlY29uZHMNCj4gdG8gbm90aWZ5IGENCj4g ZmFpbHVyZS4uLg0KPiBTbyB3ZSBoYXZlIHRvIG1vZGlmeSBzb21ldGhpbmcuDQo+DQo+IEFtb25n IHRoZSBwb3NzaWJsZSBzb2x1dGlvbnM6DQo+DQo+IDEpICBJbnRyb2R1Y3Rpb24gb2YgYSBuZXcg dGltZXIgaW4gT1NQRiBmb3IgYSBuZXcgc3ViLVRMVg0KPiAgICAgdXNlZCB0byBjYXJyeSB0aGUg aW5mbyBvZiBicm9rZW4gbGluay4NCj4gICAgIFRoZSBjdXJyZW50IHRpbWVyIG9mIE1pbkxTSW50 ZXJ2YWwgc2hvdWxkIG5vdCBjb25zaWRlcg0KPiAgICAgdGhpcyBuZXcgZmllbGQuDQo+DQo+IDIp ICBGb3JjZSB0aGUgZmxvb2Rpbmcgd2hlbiBhIGxpbmsgZmFpbHVyZSBzaWduYWwgYXJyaXZlcw0K PiAgICAgYW5kIHJlc2V0IHRoZSB0aW1lci4NCj4NCj4gV2UgdGhpbmsgdGhhdCB0aGUgMikgc29s dXRpb24gaGFzIG1vcmUgYWR2YW50YWdlcy4NCj4gVGhlIGN1cnJlbnQgYmVoYXZpb3Igb2YgdGhl IE9TUEYgcHJvdG9jb2wgaXMgKGNvbnNpZGVyaW5nIE9wYXF1ZQ0KPiBleHRlbnNpb25zKToNCj4N Cj4gICAgICAgIDwtLS0tLS0tLS0tLS0tLS0tTWluTFNJbnRlcnZhbC0tLS0tLS0tLS0tLS0+DQo+ DQo+ICAgICBCMSB8ICAgICAgICAgICAgIEIyIHwgICBCMyB8ICAgIEZBSUwuIHwNCj4gICAgICAg IHwgICAgICAgICAgICAgICAgfCAgICAgIHwgICAgICAgICAgfA0KPiAgICAgLS0tKy0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0+IHRpbWUNCj4g ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAg IEZMMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGTDINCj4NCj4gICAg V0hFUkU6DQo+DQo+IC0gIEZMMSBpcyBhIGZsb29kaW5nIG9mIEIxIGluZm9ybWF0aW9uLg0KPiAt ICBGTDIgaXMgYSBmbG9vZGluZyBvZiBCMyArIEZBSUwuIGluZm9ybWF0aW9uLg0KPiAtICBGQUlM LiBjb3VsZCBiZSBhIHNpZ25hbCBjb21pbmcgZnJvbSBhIGZhaWx1cmUgZGV0ZWN0aW9uIG1lY2hh bmlzbQ0KPiAgICAoaS5lLiBmcm9tIGxvd2VyIGxheWVyKS4NCj4gLSAgQjEsIEIyLCBCMywgRkFJ TC4gYXJlIGV4dGVybmFsIE9TUEYgT3BhcXVlIGlucHV0cy4NCj4gICAgTm90ZSB0aGF0IEIxLCBC MiwgQjMgY291bGQgYmUgQmFuZHdpZHRoIHVwZGF0ZXMgKGxpbmsgVExWcyB1cGRhdGVzKS4NCj4N Cj4gV2UgdGhvdWdodCB0byBzb2x2ZSBpbiB0aGlzIHdheToNCj4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0tLS0tTWluTFNJbnRlcnZhbC0tLS0tLS0tLT4N Cj4gICAgICAgPC0tLS0tLS0tLS0tLS1NaW5MU0ludGVydmFsLS0tLS0tPg0KPg0KPiAgICBCMSB8 ICAgICAgICBCMiB8ICAgQjMgfCAgIEZBSUwufA0KPiAgICAgICB8ICAgICAgICAgICB8ICAgICAg fCAgICAgICAgfA0KPg0KPiAtLS0rLS0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0+DQo+ICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 aW1lDQo+ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgRkwxICAg ICAgICAgICAgICAgICAgICAgICAgRkwyDQo+DQo+IEluIHRoaXMgY2FzZSB3ZSBmb3JjZSB0aGUg Zmxvb2RpbmcgKEZMMikgd2hlbiBhcnJpdmVzIGEgc2lnbmFsIG9mDQo+IGxpbmstZmFpbHVyZSAo RkFJTC4pIGFuZCB3ZSByZXNldCB0aGUgTWluTFNJbnRlcnZhbCB0aW1lciBzbyB0aGF0DQo+IGl0 IHJlc3RhcnRzIGZyb20gdGhlIGZhaWx1cmUgZXZlbnQuDQo+DQo+IFRvIGVuZm9yY2UgdGhlIHJv YnVzdG5lc3Mgb2YgdGhpcyBzb2x1dGlvbiwgYW5kIHRvIGF2b2lkDQo+IGNvbnRpbm91cyBmbG9v ZGluZw0KPiBvZg0KPiBmYWlsdXJlIG5vdGlmaWNhdGlvbnMgaW4gY2FzZSBvZiBpbnRlcmZhY2Ug ZmxhcHBpbmcsICB3ZSBoYXZlIHRvDQo+IGNvbnNpZGVyIGENCj4gdGltZXIgaW4gdGhlIG1vZHVs ZSAoZXh0ZXJuYWwgdG8gT1NQRikgdGhhdCBkZXRlY3RzIHRoZSBsaW5rLWZhaWx1cmVzIGFuZA0K PiB0cmlnZ2VycyB0aGUgZmxvb2Rpbmcgb2YgRkwyIE9wYXF1ZSBMU0EuDQo+DQo+IENvbnNpZGVy IHRoYXQgc29tZSBleHRlcm5hbCBtb2R1bGUgaXMgbmVlZGVkIHRvIHRyaWdnZXIgdGhlIE9TUEYg Zmxvb2RpbmcNCj4gb2YgZmFpbHVyZSBub3RpZmljYXRpb24sIGFzIHdlIGNhbiBub3QgcmVseSBv biB0aGUgSEVMTE8gcHJvY2VzcyBmb3IgaXRzDQo+IGxvbmcgZGV0ZWN0aW9uIGRlbGF5Lg0KPiBB IHBvc3NpYmlsaXR5IGlzIHRvIGxldCBMTVAgdG8gZGV0ZWN0IHRoZSBmYWlsdXJlIGFuZCB0cmln Z2VyIHRoZSBPU1BGDQo+IGZsb29kaW5nLg0KPg0KPiBJbiB0aGlzIGFwcHJvYWNoLCB0aGUgdGlt ZXIgdG8gYXZvaWQgaW50ZXJmYWNlLWZsYXBwaW5nIHNob3VsZCBiZSBpbmNsdWRlZA0KPiBpbiB0 aGUgTE1QIHRyaWdnZXIuDQo+IFRoaXMgc29sdXRpb24gaXMgY29uc2VydmF0aXZlIGluIHRoYXQg aXQgb25seSByZXF1aXJlcyBMTVAgZXh0ZW5zaW9ucw0KPiAodGltZXIgaW4gdGhlIHRyaWdnZXIp IGFuZCBqdXN0IGEgbWlub3IgbW9kaWZpY2F0aW9uIHRvIHRoZSBPU1BGIHByb2Nlc3MNCj4gKGku ZS4sIGFjY2VwdCBhIGZvcmNlLXRvLXNlbmQgYW5kICBNaW5MU0ludGVydmFsLXJlc2V0IHRyaWdn ZXIpLg0KPg0KPg0KPiBUaGFua3MgaW4gYWR2YW5jZSBmb3IgeW91ciBraW5kIG9ic2VydmF0aW9u cy4NCj4NCj4gUmVnYXJkcw0KPg0KPiBSb2JlcnRvIEFsYmFuZXNlLCBOaWNvbGEgQ2Fpb25lDQo+ IFVuaXZlcnNpdHkgb2YgUm9tZSAtIExhIFNhcGllbnphLCBJdGFseQ0KPg0KPg0KPg0KDQo= Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 19 Jun 2003 17:57:25 +0000 Reply-To: From: "Vishal Sharma" To: "rick king" , "Roberto Albanese" , Subject: RE: Flooding using LMP extensions Date: Thu, 19 Jun 2003 10:54:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of rick king > Sent: Thursday, June 19, 2003 2:13 AM > To: v.sharma@ieee.org; Roberto Albanese; ccamp@ops.ietf.org > 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: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Vishal Sharma > Sent: Thursday, June 19, 2003 1:36 PM > To: Roberto Albanese; ccamp@ops.ietf.org > 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: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On Behalf Of > Roberto Albanese > Sent: Tuesday, June 17, 2003 10:50 AM > To: ccamp@ops.ietf.org > 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 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 19 Jun 2003 09:14:54 +0000 From: "rick king" To: , "Roberto Albanese" , Subject: RE: Flooding using LMP extensions Date: Thu, 19 Jun 2003 17:12:48 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 TXkgdHdvIGNlbnRzOg0KDQpXaXRoIElUVS1UIGdsb3NzYXJ5LCBJIHRoaW5rIExSTShMaW5rIFJl c291cmNlIE1hbmFnZXIpIHdpbGwgZGV0ZWN0IHRoZSBsaW5rIGZhdWx0ICwNCmFuZCB0aGVuIG5v dGlmaWVzIHRoZSBSQyhSb3V0aW5nIENvbnRyb2wpIHRvIHVwZGF0ZSB0aGUgUkRCLg0KDQpyaWNr DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0 Zi5vcmcgW21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmddT24gQmVoYWxmIE9mIFZpc2hh bCBTaGFybWENClNlbnQ6IFRodXJzZGF5LCBKdW5lIDE5LCAyMDAzIDE6MzYgUE0NClRvOiBSb2Jl cnRvIEFsYmFuZXNlOyBjY2FtcEBvcHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBGbG9vZGluZyB1 c2luZyBMTVAgZXh0ZW5zaW9ucyANCg0KDQpIaSBSb2JlcnRvIGFuZCBOaWNvbGEsDQoNClRoYW5r cyB2ZXJ5IG11Y2ggZm9yIHlvdXIgb2JzZXJ2YXRpb25zIGFuZCBmb3IgeW91ciBkZXRhaWxlZA0K YW5hbHlzaXMgb2YgdGhlIGlzc3Vlcy4NCg0KSSBjZXJ0YWlubHkgc2hhcmUgeW91ciB2aWV3IHRo YXQgYSBmbG9vZGluZy1iYXNlZCBzb2x1dGlvbiB0byBmYXVsdA0Kbm90aWZpY2F0aW9uIGNhbiBw cmVzZW50IHNldmVyYWwgYWR2YW50YWdlcywgYW5kIGlzIG9uZSB0aGF0IHdlIHNob3VsZA0KY29u c2lkZXIgYXMgYSBjYW5kaWRhdGUgKHRvZ2V0aGVyIHdpdGggdGhlIHNpZ25hbGluZy1iYXNlZCBz b2x1dGlvbnMNCnByb3Bvc2VkDQpzbyBmYXIpLg0KDQoxKSBJbiB0aGF0IHJlZ2FyZCwgaXQgd291 bGQgYmUgbmljZSB0byBnZXQgeW91ciBpbnB1dHMgb24gZHJhZnQtcmFiYmF0Og0KaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmFiYmF0LWZhdWx0LW5vdGlmaWNhdGlv bi1wcm90b2NvbA0KLTAyLnR4dA0Kc2luY2UgdGhlIG1lY2hhbmlzbXMgcHJvcG9zZWQgdGhlcmUg YXJlIHRlY2hub2xvZ3ksIHByb3RvY29sLCBhbmQgdG9wb2xvZ3kNCmFnbm9zdGljLg0KRG8geW91 LCBmb3IgaW5zdGFuY2UsIGFncmVlIHdpdGggdGhlIGJhc2ljIHByb3Bvc2FsIGluIHRoZXJlPyBE byB5b3UNCmhhdmUgYW55IGZlZWRiYWNrLCBhZGRpdGlvbnMsIG9yIHN1Z2dlc3Rpb25zLCBiYXNl ZCBvbiB5b3VyIGV4cGVyaWVuY2Ugb2YNCmJ1aWxkaW5nIHlvdXIgTVBMUyB0ZXN0YmVkPw0KDQoy KSBPbiB0aGF0IG5vdGUsIEkgd2FzIHdvbmRlcmluZyBpZiB5b3UnZCBhbHJlYWR5IG1hZGUgdGhl IG1vZGlmaWNhdGlvbnMNCnRvIE9TUEYgdGhhdCB5b3UgZGlzY3Vzc2VkIGluIHlvdXIgZW1haWws IGFuZCBpZiB5b3UgaGF2ZSBhbnkNCnBlcmZvcm1hbmNlIHJlc3VsdHMgeW91IG1pZ2h0IGJlIGFi bGUgdG8gc2hhcmUgd2l0aCB0aGUgV0cuDQooUmljaGFyZCBpbiBvbmUgb2YgaGlzIGVhcmxpZXIg ZW1haWxzLCBJIGJlbGlldmUsIG1lbnRpb25lZCB0aGF0IGhlDQpoYXMgc29tZSBwcm90b3R5cGlu ZyByZXN1bHRzIG9uIExNUCBwZXJmb3JtYW5jZS4pDQoNCjMpIEZpbmFsbHksIGhlcmUgYXJlIHNv bWUgcG9pbnRzIHRoYXQgSSdkIGxpa2UgdG8gZGlzY3VzcyByZWxhdGVkIHRvDQp0aGUgaXNzdWVz IGhpZ2hsaWdodGVkIGluIHlvdXIgZW1haWwuDQoNCiBpKSBJIHdhbnRlZCB0byBhZGQgdGhhdCBu b3Qgb25seSBjb3VsZCBmbG9vZGluZyBtaW5pbWl6ZSByb3V0aW5nIGZhaWx1cmUNCiAgICBwcm9i YWJpbGl0eSAoYXMgeW91J3ZlIG9ic2VydmVkKSwgaXQgY291bGQgYWxzbyBzcGVlZCB1cCByZWNv dmVyeQ0KICAgIGJ5IG5vdGlmeWluZyAoaW4gcGFyYWxsZWwpDQogICAgdGhlIG5vZGVzIG9uIG11 bHRpcGxlIHJlY292ZXJ5IHBhdGhzIGFmZmVjdGVkIGJ5IGEgZ2l2ZW4gZmF1bHQuIFRoaXMgY2Fu DQogICAgcHJvdmUgdmVyeSBhZHZhbnRhZ2VvdXMgd2hlbiBhIGxpbmsgY2FycmllcyBhIGxhcmdl IG51bWJlciBvZg0KICAgIHRyYW5zcG9ydCBjaXJjdWl0cyAoZS5nLiBsYW1iZGFzKSwgYW5kIHdo ZW4gdGhlIExTUHMgZG8gbm90IHNoYXJlIHRoZQ0KICAgIHNhbWUgcy1kIHBhaXJzLg0KDQogaWkp IEluIHJlZ2FyZCB0byB0aGUgYXJndW1lbnQgZm9yIHVzaW5nIE9TUEYgdG8gb2J0YWluIGEgc29s dXRpb24gdGhhdA0Kd29ya3MNCiAgICAgYm90aCBmb3IgTVBMUyBhbmQgR01QTFMsIG15IHRob3Vn aHQgaXMgdGhhdCB0aGlzIGlzIG5vdCBjcml0aWNhbCwgc2luY2UNCiAgICAgdGhlIHJlY292ZXJ5 IG1ldGhvZHMgKGUuZy4gZmFzdCByZXJvdXRlKSBhdCB0aGUgTVBMUyBsYXllciBhcmUgYWxyZWFk eQ0KICAgICB3ZWxsLWRlZmluZWQgYW5kIGFyZSBub3QgY29tbW9uIHdpdGggdGhlIHJlY292ZXJ5 IG1ldGhvZHMgdXNlZCBhdCB0aGUNCiAgICAgdHJhbnNwb3J0IGxheWVyLiBUaHVzLCB0aGVyZSBp cyBsZXNzIG9mIGEgbmVlZCB0byBoYXZlIGEgc29sdXRpb24gdGhhdA0KICAgICB3b3JrcyBhY3Jv c3MgbGF5ZXJzIG9mIHRoZSBuZXR3b3JrIHVzaW5nIE1QTFMgYW5kIEdNUExTLCByZXNwZWN0aXZl bHkuDQogICAgIE9uIHRoZSBjb250cmFyeSwgdGhlICJjb3N0IiBvZiB0cnlpbmcgdG8gaW5jb3Jw b3JhdGUgdGhlIGZhdWx0DQpub3RpZmljYXRpb24NCiAgICAgZnVuY3Rpb25hbGl0eSBpbiBhIHJv dXRpbmcgcHJvdG9jb2wsIGxpa2UgT1NQRiwgYW4gYmUgaGVhdnkgKGFzIEkNCmV4cGxhaW4gYmVs b3cpLg0KDQogaWlpKSBUaGlzIGlzIGJlY2F1c2Ugb25lIGhhcyB0byBkZXZlbG9wIHNvbHV0aW9u cyBmb3IgbXVsdGlwbGUgcm91dGluZw0KcHJvdG9jb2xzDQogICAgIChhcyBub3QgZXZlcnlvbmUg d2lsbCB1c2UgT1NQRikuIE1vcmUgaW1wb3J0YW50bHksIGEgc2VydmljZSBwcm92aWRlcg0Kbm90 DQogICAgICBub3JtYWxseSBydW5uaW5nIGEgcm91dGluZyBwcm90b2NvbCBhdCB0aGUgdHJhbnNw b3J0IGxheWVyIChidXQgdXNpbmcNCkxNUA0KICAgICAgYW5kIEdNUExTIHNpZ25hbGluZyksIHdv dWxkIGJlIGZvcmNlZCB0byBydW4gYSByb3V0aW5nIHByb3RvY29sIGp1c3QNCmZvcg0KICAgICAg ZWZmaWNpZW50IGZhdWx0IG5vdGlmaWNhdGlvbiEgVGhhdCBzZWVtcyBsaWtlIGFuIHVuZHVlIGJ1 cmRlbi4NCiAgICAgIEZ1cnRoZXJtb3JlLCB1bmxpa2UgTE1QLCBPU1BGIHJlcXVpcmVzIG1vcmUg aW52b2x2ZWQgcHJvY2Vzc2luZywNCm1ha2luZyBpdA0KICAgICAgZGlmZmljdWx0IHRvIGVuc3Vy ZSB0aGF0IHRoZSBmYWlsdXJlLXJlbGF0ZWQgbWVzc2FnZXMgYXJlIGFsd2F5cw0KcHJvY2Vzc2Vk DQogICAgICBhbmQgZGlzcGF0Y2hlZCBfYmVmb3JlXyBvdGhlciBPU1BGIG1lc3NhZ2VzLg0KDQog ICAgICBBbHNvLCBpcnJlc3BlY3RpdmUgb2Ygd2hldGhlciBhIHByb3ZpZGVyIHJ1bnMgcm91dGlu ZywgaXQgaXMgbGlrZWx5DQp0aGF0DQogICAgICBhIEdNUExTLWNvbnRyb2wgcGxhbmUgYXQgdGhl IHRyYW5zcG9ydCBsYXllciB3aWxsIGF0IGxlYXN0IHJ1biBMTVAsDQp0aHVzDQogICAgICBtYWtp bmcgaXQgYSBuYXR1cmFsIGNob2ljZSB0byBleHRlbmQgZm9yIGZsb29kaW5nLWJhc2VkIGZhdWx0 DQpub3RpZmljYXRpb24uDQoNCiAgICAgIE9mIGNvdXJzZSwgSSB3ZWxjb21lIHNlcnZpY2UgcHJv dmlkZXIgaW5wdXRzIG9uIHRoaXMgaXNzdWUsIGFuZCB0aGV5DQogICAgICBjYW4gY29ycmVjdCBt ZSBpZiBJJ20gd3JvbmcuIDotKQ0KDQoNCiBpdikgQW5kIGZpbmFsbHksIGl0IGFwcGVhcnMgdGhh dCB5b3UgYXJlIGluc2VydGluZyB0aGUgdGltZXIgZnVuY3Rpb25hbGl0eQ0KYW5kDQogICAgIGlu aXRpYWwgZGV0ZWN0aW9uIGZ1bmN0aW9uYWxpdHkgaW4gTE1QIGFueXdheSwgc28gaW4gdGhlIGxp Z2h0IG9mIChpaWkpDQphYm92ZSwNCiAgICAgd291bGRuJ3QgaXQgYmUgZWFzaWVyIGp1c3QgdG8g ZXh0ZW5kIExNUC4gKFdpdGggcmVnYXJkIHRvIHRoZSBhcmd1bWVudA0Kb2YgT1NQRg0KICAgICBm bG9vZGluZyBiZWluZyBtYXR1cmUsIHBlcmhhcHMgd2UgY2FuIGxlYXJuIGZyb20gdGhlIGxlc3Nv bnMgdGhlcmUsIGFuZA0Kbm90DQogICAgIHJlcGVhdCB0aGUgc2FtZSBtaXN0YWtlcyB3aGVuIG9w ZXJhdGluZyBMTVAuIDotKSkuDQoNCkJlc3QgcmVnYXJkcywNCi1WaXNoYWwNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnIFttYWls dG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXU9uIEJlaGFsZiBPZg0KUm9iZXJ0byBBbGJhbmVz ZQ0KU2VudDogVHVlc2RheSwgSnVuZSAxNywgMjAwMyAxMDo1MCBBTQ0KVG86IGNjYW1wQG9wcy5p ZXRmLm9yZw0KU3ViamVjdDogUmU6IEZsb29kaW5nIHVzaW5nIExNUCBleHRlbnNpb25zDQoNCg0K SGkgYWxsLA0Kd2UgYXJlIHdvcmtpbmcgdG8gYSBNUExTIHRlc3RiZWQgc3VwcG9ydGluZyBlbmQt dG8tZW5kDQpQcm90ZWN0aW9uLVJlc3RvcmF0aW9uIG1lY2hhbmlzbXMgYW5kIHdlIGZhY2VkIHRo ZSBwcm9ibGVtIG9mDQpsaW5rLWZhaWx1cmVzIG5vdGlmaWNhdGlvbi4NCldlIHNoYXJlIHRoZSBz Y2FsYWJpbGl0eSBjb25jZXJucyBvZiBSU1ZQLWxpa2UNCnNvbHV0aW9ucyByZXBvcnRlZCBpbiB0 aGUgUmFiYmF0J3MgbWFpbC4NCldlIGFyZSBpbiBmYXZvdXIgb2YgT1NQRiBmbG9vZGluZy1iYXNl ZCBtZWNoYW5pc21zIGZvciBsaW5rLWZhaWx1cmVzDQp1c2luZyBPcGFxdWUgYmVjYXVzZToNCg0K LSAgYXBwbGljYWJsZSB0byBib3RoIE1QTFMtVEUgLSBHTVBMUy4NCg0KLSAgUHJvdmVkIE9TUEYg cHJvdG9jb2wgc3RhYmlsaXR5IGFuZCByb2J1c3RuZXNzIHdpdGggcmVzcGVjdCB0byB0aGUgTE1Q DQpzb2x1dGlvbi4NCiAgIE9TUEYgZmxvb2RpbmcgaW4gZ2VuZXJhbCBpcyBtYXR1cmUsIGluc3Rl YWQgTE1QIGhhcyB0byBiZSBleHRlbmRlZA0KICAgYW5kIGl0IGhhcyB0byBzdXBwb3J0IHNvbWUg T1NQRiBjYXBhYmlsaXRpZXMgd2UgYWxyZWFkeSBoYXZlLg0KDQotICBSZWR1Y3Rpb24gb2Ygcm91 dGluZyBmYWlsdXJlIHByb2JhYmlsaXR5IHJlc3BlY3QgdG8gdGhlIHVzZSBvZiBSU1ZQIChzZWUN CmJlbG93KS4NCiAgICAgIEluIGRyYWZ0LWthdHoteWV1bmctb3NwZi10cmFmZmljLTA5IGl0IGlz IHdyaXR0ZW4gdGhhdCBpbiBhIFRFDQpzY2VuYXJpbw0KICAgICAgd2UgY2FuIGhhdmUgYSBtb2R1 bGUgaW4gdGhlIGVkZ2Ugbm9kZXMgdGhhdCBzZWFyY2hlcyBjb25zdHJhaW5lZA0Kcm91dGVzDQog ICAgICBiYXNlZCBvbiBPcGFxdWUgVEUgaW5mby4NCiAgICAgIFdlIGNhbGwgYSAicm91dGluZyBm YWlsdXJlIiB0aGUgY29tcHV0YXRpb24gYnkgZWRnZSBub2RlIFggb2YgYSBwYXRoDQogICAgICB3 aGljaCBpbmNsdWRlcyBhIGZhaWxlZCBsaW5rIEYuDQogICAgICBDbGVhcmx5LCByb3V0aW5nIGZh aWx1cmVzIGFyZSBhIGNvbnNlcXVlbmNlIG9mIGxhY2sgb2Ygbm90aWZpY2F0aW9uLA0KICAgICAg dG8gWCwgb2YgdGhlIGZhaWx1cmUgb2YgRi4NCiAgICAgIFdpdGggUlNWUCBmYWlsdXJlIG5vdGlm aWNhdGlvbiwgdGhpcyBjYW4gb2NjdXI6DQogICAgICAtICBpbiBjYXNlIG9mIHNpbmdsZSBmYXVs dCwgd2hlbiB0aGVyZSBhcmUgbm8gTFNQcyBvcmlnaW5hdGVkIGZyb20gWA0KY3Jvc3NpbmcgRjsN CiAgICAgIC0gIGluIGNhc2Ugb2YgZHVhbCBmYXVsdHMgKGkuZS4sIHR3byBsaW5rcyBMMSBhbmQg TDIgZmFpbHMgYWxtb3N0DQpzaW11bHRhbmVvdXNseSksDQogICAgICAgICBpZiBmcm9tIFggdGhl cmUgaXMgYSBMU1AgY3Jvc3NpbmcgYm90aCBMMSBhbmQgTDI6DQoNCiAgWC0tLWxpbmstLS0tLW5v ZGUtLS0tLS1saW5rKEwxKS0tLS0tLW5vZGUtLS0tLS0tbGluayhMMiktLS0tLWVncmVzc19ub2Rl DQoNCiAgICAgIHRoZSBmYWlsdXJlIG9mIEwxIGNhbiBoaWRlIHRoZSBub3RpZmljYXRpb24gb2Yg TDIgZmFpbHVyZXMuDQoNCiAgICAgIEl0IGNhbiBiZSBzZWVuIHRoYXQgd2l0aCBPU1BGIGZsb29k aW5nLCB0aGVyZSBpcyB2aXJ0dWFsbHkgbm8NCnBvdGVudGlhbA0KICAgICAgcm91dGluZyBmYWls dXJlIGF0IGFsbCwgYXMgQUxMIHRoZSBlZGdlIG5vZGVzIGFyZSBub3RpZmllZCBhbnkNCmZhaWx1 cmUuDQoNCiAgICAgIFNvIGlmIHdlIGhhdmUgYSBmbG9vZGluZy1iYXNlZCBub3RpZmljYXRpb24s IGFsbCB0aGUgZWRnZSBub2RlcyBpbiBhDQpuZXR3b3JrDQogICAgICB3aWxsIGJlIGF3YXJlIGFi b3V0IHRoZSBmYWlsdXJlLiBJbnN0ZWFkLCB3aXRoIFJTVlAsIHdlJ2xsIGhhdmUNCiAgICAgIG9u bHkgc29tZSBub2RlcyBhd2FyZSBvZiB0aGUgZmFpbHVyZSEgU28gd2UgaGF2ZSBhbiBpbmNyZWFz aW5nIG9mDQogICAgICByb3V0aW5nIGZhaWx1cmUgcHJvYmFiaWxpdHkgYWZ0ZXIgYSBsaW5rIGZh aWx1cmUuDQoNCldlIGFncmVlIHRoYXQgYSBtYWpvciBkcmF3YmFjayBvZiB0aGUgT1NQRi1mbG9v ZGluZyBzb2x1dGlvbiBpcyB0aGUgbmVlZCBvZg0KcmV2aXNpdGluZw0KdGhlIHRpbWVycywgYXMg cG9pbnRlZCBvdXQgaW4gdGhlIFJhYmJhdCdzIG1haWw6IkZsb29kaW5nIHVzaW5nIExNUA0KZXh0 ZW5zaW9ucyIuDQpJbiBmYWN0IHdlIGNhbid0IHdhaXQgZm9yIGEgbWF4IHBlcmlvZCBvZiBNaW5M U0ludGVydmFsIHNlY29uZHMgdG8gbm90aWZ5IGENCmZhaWx1cmUuLi4NClNvIHdlIGhhdmUgdG8g bW9kaWZ5IHNvbWV0aGluZy4NCg0KQW1vbmcgdGhlIHBvc3NpYmxlIHNvbHV0aW9uczoNCg0KMSkg IEludHJvZHVjdGlvbiBvZiBhIG5ldyB0aW1lciBpbiBPU1BGIGZvciBhIG5ldyBzdWItVExWDQog ICAgdXNlZCB0byBjYXJyeSB0aGUgaW5mbyBvZiBicm9rZW4gbGluay4NCiAgICBUaGUgY3VycmVu dCB0aW1lciBvZiBNaW5MU0ludGVydmFsIHNob3VsZCBub3QgY29uc2lkZXINCiAgICB0aGlzIG5l dyBmaWVsZC4NCg0KMikgIEZvcmNlIHRoZSBmbG9vZGluZyB3aGVuIGEgbGluayBmYWlsdXJlIHNp Z25hbCBhcnJpdmVzDQogICAgYW5kIHJlc2V0IHRoZSB0aW1lci4NCg0KV2UgdGhpbmsgdGhhdCB0 aGUgMikgc29sdXRpb24gaGFzIG1vcmUgYWR2YW50YWdlcy4NClRoZSBjdXJyZW50IGJlaGF2aW9y IG9mIHRoZSBPU1BGIHByb3RvY29sIGlzIChjb25zaWRlcmluZyBPcGFxdWUNCmV4dGVuc2lvbnMp Og0KDQogICAgICAgPC0tLS0tLS0tLS0tLS0tLS1NaW5MU0ludGVydmFsLS0tLS0tLS0tLS0tLT4N Cg0KICAgIEIxIHwgICAgICAgICAgICAgQjIgfCAgIEIzIHwgICAgRkFJTC4gfA0KICAgICAgIHwg ICAgICAgICAgICAgICAgfCAgICAgIHwgICAgICAgICAgfA0KICAgIC0tLSstLS0tLS0tLS0tLS0t LS0tKy0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tPiB0aW1lDQogICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICBGTDEgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRkwyDQoNCiAgIFdIRVJFOg0KDQotICBG TDEgaXMgYSBmbG9vZGluZyBvZiBCMSBpbmZvcm1hdGlvbi4NCi0gIEZMMiBpcyBhIGZsb29kaW5n IG9mIEIzICsgRkFJTC4gaW5mb3JtYXRpb24uDQotICBGQUlMLiBjb3VsZCBiZSBhIHNpZ25hbCBj b21pbmcgZnJvbSBhIGZhaWx1cmUgZGV0ZWN0aW9uIG1lY2hhbmlzbQ0KICAgKGkuZS4gZnJvbSBs b3dlciBsYXllcikuDQotICBCMSwgQjIsIEIzLCBGQUlMLiBhcmUgZXh0ZXJuYWwgT1NQRiBPcGFx dWUgaW5wdXRzLg0KICAgTm90ZSB0aGF0IEIxLCBCMiwgQjMgY291bGQgYmUgQmFuZHdpZHRoIHVw ZGF0ZXMgKGxpbmsgVExWcyB1cGRhdGVzKS4NCg0KV2UgdGhvdWdodCB0byBzb2x2ZSBpbiB0aGlz IHdheToNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0tLS0t TWluTFNJbnRlcnZhbC0tLS0tLS0tLT4NCiAgICAgIDwtLS0tLS0tLS0tLS0tTWluTFNJbnRlcnZh bC0tLS0tLT4NCg0KICAgQjEgfCAgICAgICAgQjIgfCAgIEIzIHwgICBGQUlMLnwNCiAgICAgIHwg ICAgICAgICAgIHwgICAgICB8ICAgICAgICB8DQogICAtLS0rLS0tLS0tLS0tLS0rLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotPg0KICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHRpbWUNCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg IEZMMSAgICAgICAgICAgICAgICAgICAgICAgIEZMMg0KDQpJbiB0aGlzIGNhc2Ugd2UgZm9yY2Ug dGhlIGZsb29kaW5nIChGTDIpIHdoZW4gYXJyaXZlcyBhIHNpZ25hbCBvZg0KbGluay1mYWlsdXJl IChGQUlMLikgYW5kIHdlIHJlc2V0IHRoZSBNaW5MU0ludGVydmFsIHRpbWVyIHNvIHRoYXQNCml0 IHJlc3RhcnRzIGZyb20gdGhlIGZhaWx1cmUgZXZlbnQuDQoNClRvIGVuZm9yY2UgdGhlIHJvYnVz dG5lc3Mgb2YgdGhpcyBzb2x1dGlvbiwgYW5kIHRvIGF2b2lkIGNvbnRpbm91cyBmbG9vZGluZw0K b2YNCmZhaWx1cmUgbm90aWZpY2F0aW9ucyBpbiBjYXNlIG9mIGludGVyZmFjZSBmbGFwcGluZywg IHdlIGhhdmUgdG8gY29uc2lkZXIgYQ0KdGltZXIgaW4gdGhlIG1vZHVsZSAoZXh0ZXJuYWwgdG8g T1NQRikgdGhhdCBkZXRlY3RzIHRoZSBsaW5rLWZhaWx1cmVzIGFuZA0KdHJpZ2dlcnMgdGhlIGZs b29kaW5nIG9mIEZMMiBPcGFxdWUgTFNBLg0KDQpDb25zaWRlciB0aGF0IHNvbWUgZXh0ZXJuYWwg bW9kdWxlIGlzIG5lZWRlZCB0byB0cmlnZ2VyIHRoZSBPU1BGIGZsb29kaW5nDQpvZiBmYWlsdXJl IG5vdGlmaWNhdGlvbiwgYXMgd2UgY2FuIG5vdCByZWx5IG9uIHRoZSBIRUxMTyBwcm9jZXNzIGZv ciBpdHMNCmxvbmcgZGV0ZWN0aW9uIGRlbGF5Lg0KQSBwb3NzaWJpbGl0eSBpcyB0byBsZXQgTE1Q IHRvIGRldGVjdCB0aGUgZmFpbHVyZSBhbmQgdHJpZ2dlciB0aGUgT1NQRg0KZmxvb2RpbmcuDQoN CkluIHRoaXMgYXBwcm9hY2gsIHRoZSB0aW1lciB0byBhdm9pZCBpbnRlcmZhY2UtZmxhcHBpbmcg c2hvdWxkIGJlIGluY2x1ZGVkDQppbiB0aGUgTE1QIHRyaWdnZXIuDQpUaGlzIHNvbHV0aW9uIGlz IGNvbnNlcnZhdGl2ZSBpbiB0aGF0IGl0IG9ubHkgcmVxdWlyZXMgTE1QIGV4dGVuc2lvbnMNCih0 aW1lciBpbiB0aGUgdHJpZ2dlcikgYW5kIGp1c3QgYSBtaW5vciBtb2RpZmljYXRpb24gdG8gdGhl IE9TUEYgcHJvY2Vzcw0KKGkuZS4sIGFjY2VwdCBhIGZvcmNlLXRvLXNlbmQgYW5kICBNaW5MU0lu dGVydmFsLXJlc2V0IHRyaWdnZXIpLg0KDQoNClRoYW5rcyBpbiBhZHZhbmNlIGZvciB5b3VyIGtp bmQgb2JzZXJ2YXRpb25zLg0KDQpSZWdhcmRzDQoNClJvYmVydG8gQWxiYW5lc2UsIE5pY29sYSBD YWlvbmUNClVuaXZlcnNpdHkgb2YgUm9tZSAtIExhIFNhcGllbnphLCBJdGFseQ0KDQoNCg== Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 19 Jun 2003 05:38:46 +0000 Reply-To: From: "Vishal Sharma" To: "Roberto Albanese" , Subject: RE: Flooding using LMP extensions Date: Wed, 18 Jun 2003 22:36:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Roberto Albanese Sent: Tuesday, June 17, 2003 10:50 AM To: ccamp@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 18 Jun 2003 21:57:54 +0000 From: "Richard Rabbat" To: "'Roberto Albanese'" , Subject: RE: Flooding using LMP extensions Date: Wed, 18 Jun 2003 14:55:15 -0700 Message-ID: <001601c335e4$4d697b80$3b3ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C335A9.A10AA380" 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

Hi Roberto and Nicola, =

 

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.

 

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

 

Thanks.

 

 

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

 

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

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

 

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

> using Opaque = because:

> 

> -  applicable to both = MPLS-TE - GMPLS.

 

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.

 

 

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

> 

 

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

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

 

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

> (see below).

 

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

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

 

>     &n= bsp; In draft-katz-yeung-ospf-traffic-09 it is written that in a TE =

> scenario

>     &n= bsp; we can have a module in the edge nodes that searches = constrained

>  &= nbsp;    routes based on Opaque TE info.

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

>     &n= bsp; which includes a failed link F.

>     &n= bsp; Clearly, routing failures are a consequence of lack of = notification,

>     &n= bsp; to X, of the failure of F.

>     &n= bsp; With RSVP failure notification, this can occur:

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

> crossing F;

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

> = simultaneously),

>     &n= bsp;    if from X there is a LSP crossing both L1 and L2:

> 

>   = X---link-----node------link(L1)------node-------link(L2)-----egress_node<= /span>

 

>     &n= bsp; the failure of L1 can hide the notification of L2 = failures.

 

>     &n= bsp; It can be seen that with OSPF flooding, there is virtually = no

>  = potential

>     &n= bsp; routing failure at all, as ALL the edge nodes are notified any =

> failure.

 

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

Thanks for the = example.

 

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

 

> network

>     &n= bsp; will be aware about the failure. Instead, with RSVP, we'll = have

>     &n= bsp; only some nodes aware of the failure! So we have an increasing = of

>     &n= bsp; 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):

>  =

>  &= nbsp;     <----------------MinLSInterval------------->

>  =

>  &= nbsp;  B1 = |            = B2 |   B3 |    FAIL. |

>     &n= bsp;  |  =             &= nbsp; |      |          = |

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

>     &n= bsp;  |            =             &= nbsp;           &n= bsp;     |

>     &n= bsp;  |            =             &= nbsp;           &n= bsp;     |

>      FL1           &nbs= p;            = ;                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:

 

>     &n= bsp;           &nb= sp;           &nbs= p;     <-------------MinLSInterval--------->

>     &n= bsp; <-------------MinLSInterval------>

> 

>    B1 |        B2 |   B3 = |   FAIL.|

>     &n= bsp; |           |      = |        |

>

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

>     &n= bsp; |            =             &= nbsp;  |            =                   &= nbsp;    time

>     &n= bsp; |            =             &= nbsp;  |

>      FL1           &nbs= p;            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.

 

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. 

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

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.

 

 

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

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

> to consider atimer 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).

>

 

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

have to run OSPF just to achieve = this functionality?

 

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.

 

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.

 

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

 

Best,

Richard

 

>

> Thanks in advance for your = kind observations.

> 

> Regards

> 

> Roberto Albanese, Nicola = Caione

> University of = Rome - La = Sapienza, = Italy

 

------=_NextPart_000_0017_01C335A9.A10AA380-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 Jun 2003 17:55:38 +0000 Message-ID: <004e01c334f8$eea91ce0$91256497@coritel> From: "Roberto Albanese" To: Subject: Re: Flooding using LMP extensions Date: Tue, 17 Jun 2003 19:50:19 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C33509.AEB0B560" 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
Hi all,
we are working to a = MPLS testbed=20 supporting end-to-end
Protection-Restoration mechanisms and we faced = the=20 problem of
link-failures notification.
We share the scalability = concerns=20 of RSVP-like
solutions reported in the Rabbat's mail.
We are in = favour of=20 OSPF flooding-based mechanisms for link-failures 
using Opaque=20 because:
 
-  applicable to both = MPLS-TE -=20 GMPLS.
 
-  Proved OSPF protocol = stability and=20 robustness with respect to the LMP solution.
   OSPF = flooding in=20 general is mature, instead LMP has to be extended
   and it = has to=20 support some OSPF capabilities we already have.
 
-  Reduction of routing = failure=20 probability respect to the use of RSVP (see=20 below).
      In = draft-katz-yeung-ospf-traffic-09 it=20 is written that in a TE scenario
      we = can have a=20 module in the edge nodes that searches constrained=20 routes
      based on Opaque TE=20 info.
      We call a "routing failure" the=20 computation by edge node X of a path
      = which=20 includes a failed link F.
      Clearly, = routing=20 failures are a consequence of lack of=20 notification,
      to X, of the failure of=20 F.
      With RSVP failure notification, = this can=20 occur:
      -  in case of single = fault, when=20 there are no LSPs originated from X crossing=20 F;
      -  in case of dual faults = (i.e., two=20 links L1 and L2 fails almost=20 simultaneously),
         if = from X=20 there is a LSP crossing both L1 and L2:
 
 =20 X---link-----node------link(L1)------node-------link(L2)-----egress_node<= /FONT>
 
      = the failure=20 of L1 can hide the notification of L2 failures.
 
      = It can be=20 seen that with OSPF flooding, there is virtually no=20 potential
      routing failure at all, as = ALL the=20 edge nodes are notified any failure.
 
      = So if we=20 have a flooding-based notification, all the edge nodes in a=20 network
      will be aware about the = failure.=20 Instead, with RSVP, we'll have
      only = some nodes=20 aware of the failure! So we have an increasing=20 of
      routing failure probability after a = link=20 failure.
 
We agree that a major drawback = of the=20 OSPF-flooding solution is the need of revisiting
the timers, as = pointed out=20 in the Rabbat's mail:"Flooding using LMP extensions".
In fact we = can't wait=20 for a max period of MinLSInterval seconds to notify a failure...
So = we have=20 to modify something.
 
Among the possible = solutions:
 
1)  Introduction of a new = timer in=20 OSPF for a new sub-TLV
    used to carry the info of = broken=20 link.
    The current timer of MinLSInterval should = not=20 consider
    this new field.
 
2)  Force the flooding = when a link=20 failure signal arrives
    and reset the = timer.
 
We think that the 2) solution = has more=20 advantages.
The current behavior of the OSPF protocol is (considering = Opaque=20 extensions):
 
      =20 <----------------MinLSInterval------------->
 
    B1=20 |            = B2=20 |   B3 |    FAIL.=20 |
      =20 |            =    =20 |     =20 |          = |
   =20 ---+----------------+------+----------+-------+------------>=20 time
      =20 |            =             &= nbsp;           &n= bsp;    =20 |
      =20 |            =             &= nbsp;           &n= bsp;    =20 |
    =20 FL1           &nbs= p;            = ;            =    =20 FL2
 
   = WHERE:
 
-  FL1 is a flooding of B1 = information.
-  FL2 is a flooding of B3 + FAIL. = information.
- =20 FAIL. could be a signal coming from a failure detection=20 mechanism
   (i.e. from lower layer).
-  B1, B2, = B3, FAIL.=20 are external OSPF Opaque inputs.
   Note that B1, B2, B3 = could be=20 Bandwidth updates (link TLVs updates).
 
We thought to solve in this=20 way:
 
          &nbs= p;            = ;          =20 <-------------MinLSInterval--------->
    &n= bsp;=20 <-------------MinLSInterval------>
 
   B1=20 |        B2 |   B3 = |  =20 FAIL.|
     =20 |          =20 |      = |       =20 |
  =20 ---+-----------+------+--------+-----------------------------------------= ->
     =20 |            =             &= nbsp; =20 |            =             &= nbsp;         =20 time
     =20 |            =             &= nbsp; =20 |
    =20 FL1           &nbs= p;           =20 FL2
 
In this case we force the = flooding (FL2)=20 when arrives a signal of
link-failure (FAIL.) and we reset the = MinLSInterval=20 timer so that
it restarts from the failure event.
 
To enforce the robustness of = this solution,=20 and to avoid continous flooding of
failure notifications in case of=20 interface flapping,  we have to consider a
timer in the module = (external=20 to OSPF) that detects the link-failures and
triggers the flooding of = FL2=20 Opaque LSA.
 
Consider that some external = module is=20 needed to trigger the OSPF flooding
of failure notification, as we = can not=20 rely on the HELLO process for its long detection delay.
A possibility = is to=20 let LMP to detect the failure and trigger the OSPF = flooding.
 
In this approach, the timer to = avoid=20 interface-flapping should be included in the LMP trigger.
This = solution is=20 conservative in that it only requires LMP extensions
(timer in the = trigger)=20 and just a minor modification to the OSPF process
(i.e., accept a=20 force-to-send and  MinLSInterval-reset trigger).
 

Thanks in advance for your kind observations.
 
Regards
 
Roberto Albanese, Nicola Caione
University of Rome - La = Sapienza,=20 Italy
------=_NextPart_000_004B_01C33509.AEB0B560-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 Jun 2003 13:04:11 +0000 Message-ID: <3EEF1172.5030908@alcatel.be> Date: Tue, 17 Jun 2003 15:02:42 +0200 From: Dimitri.Papadimitriou@alcatel.be Reply-To: dpapadimitriou@psg.com User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Diego Caviglia CC: ccamp@ops.ietf.org Subject: Re: A question regarding draft-ietf-ccamp-gmpls-sonet-sdh-08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed 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 -owner@ops.ietf.org 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 : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 Jun 2003 12:50:19 +0000 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Sensitivity: Subject: A question regarding draft-ietf-ccamp-gmpls-sonet-sdh-08 To: ccamp@ops.ietf.org From: "Diego Caviglia" 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 -owner@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 17 Jun 2003 11:57:58 +0000 Message-Id: <200306171156.HAA08200@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mpls@uu.net, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075212.I-D@ietf.org> 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: <2003-6-17075212.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 16 Jun 2003 22:26:07 +0000 Message-ID: <089701c33455$eab28b60$681810ac@movaz.com> From: "Adrian Farrel" To: 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: To: Cc: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 16 Jun 2003 11:56:41 +0000 Message-Id: <200306161155.HAA08926@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-16080703.I-D@ietf.org> 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: <2003-6-16080703.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 15 Jun 2003 21:56:47 +0000 Subject: Re: Time slots for CCAMP 57 To: ccamp@ops.ietf.org Date: Sun, 15 Jun 2003 21:54:07 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou all, sorry for the reposting but the last url was not accessible: ccamp'ers, as discussed during the last meeting, see also: 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): -> PS for July'03: update submitted (except nits and edito's nothing is expected to change from this stable document) -> Info for June'03: update submitted based on the last meeting discussion (scope of the whole effort is now accuratelly delimited) -> PS for April'03: update expected b/f last call -> 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. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 15 Jun 2003 14:43:12 +0000 Subject: Time slots for CCAMP 57 To: ccamp@ops.ietf.org Date: Sun, 15 Jun 2003 14:39:48 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Dimitri Papadimitriou ccamp'ers, as discussed during the last meeting, see also: 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): -> PS for July'03: update submitted (except nits and edito's nothing is expected to change from this stable document) -> Info for June'03: update submitted based on the last meeting discussion (scope of the whole effort is now accuratelly delimited) -> PS for April'03: update expected b/f last call -> 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 13 Jun 2003 21:40:40 +0000 From: "Richard Rabbat" To: Subject: Flooding using LMP extensions Date: Fri, 13 Jun 2003 14:39:42 -0700 Message-ID: <001501c331f4$4caa5b40$ee3ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 13 Jun 2003 21:40:04 +0000 From: "Richard Rabbat" To: Subject: Fault Notification Protocol & Recovery Requirements Date: Fri, 13 Jun 2003 14:36:24 -0700 Message-ID: <001401c331f3$e3ebc800$ee3ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 12 Jun 2003 11:20:13 +0000 Message-Id: <200306121118.HAA03399@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-11134528.I-D@ietf.org> 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: <2003-6-11134528.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 11 Jun 2003 18:09:52 +0000 Message-ID: <20030611180819.33607.qmail@web80507.mail.yahoo.com> Date: Wed, 11 Jun 2003 11:08:19 -0700 (PDT) From: Greg Bernstein Subject: ASON routing requirements document? To: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 11 Jun 2003 15:59:05 +0000 Message-Id: <4.3.2.7.2.20030611115537.0a0a0968@paris.cisco.com> Date: Wed, 11 Jun 2003 11:57:29 -0400 To: "Adrian Farrel" From: Jean Philippe Vasseur Subject: Re: Route Exclusion Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: ccamp-data@psg.com Delivery-date: Wed, 11 Jun 2003 14:40:50 +0000 Message-ID: <034d01c33027$21daefc0$681810ac@movaz.com> From: "Adrian Farrel" To: "Jean Philippe Vasseur" Cc: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 11 Jun 2003 09:57:47 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501CD041F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Len Nieman , ccamp@ops.ietf.org Cc: mpls@UU.NET Subject: RE: LMP-MIB Module Compile Test Date: Wed, 11 Jun 2003 11:56:43 +0200 MIME-Version: 1.0 Content-Type: text/plain Inline > -----Original Message----- > From: Len Nieman [mailto:Len.Nieman@mci.com] > Sent: woensdag 11 juni 2003 0:23 > To: ccamp@ops.ietf.org > Cc: mpls@UU.NET > 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 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 11 Jun 2003 01:08:54 +0000 Message-Id: <3.0.1.32.20030610210802.0073f4d0@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jun 2003 21:08:02 -0400 To: Len Nieman ,ccamp@ops.ietf.org From: jcucchiara@mindspring.com Subject: Re: LMP-MIB Module Compile Test Cc: mpls@UU.NET [ 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 -owner@ops.ietf.org 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, mibs@ops.ietf.org. To subscribe, send email to mibs-request@ops.ietf.org 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 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 11 Jun 2003 00:59:22 +0000 From: "zafar ali" To: "'Kireeti Kompella'" , Cc: "'Anca Zamfir'" , , Subject: RE: Time slots for CCAMP 57 Date: Tue, 10 Jun 2003 20:58:01 -0400 Organization: Cisco Systems Message-ID: <011001c32fb4$830a3990$91053918@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org >[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella >Sent: Saturday, May 31, 2003 1:40 AM >To: ccamp@ops.ietf.org >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. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 10 Jun 2003 23:05:56 +0000 Message-Id: <4.3.2.7.2.20030610190136.0a73e670@paris.cisco.com> Date: Tue, 10 Jun 2003 19:04:48 -0400 To: "Adrian Farrel" From: Jean Philippe Vasseur Subject: Re: Route Exclusion Cc: , , , "Ron Bonica" , "'Kireeti Kompella'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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" >To: "Adrian Farrel" ; "'Kireeti Kompella'" >; >Cc: ; >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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Adrian Farrel > > > Sent: Tuesday, May 27, 2003 3:57 PM > > > To: 'Kireeti Kompella'; Ron Bonica; ccamp@ops.ietf.org > > > Cc: stefaan.de_cnodder@alcatel.be; Cheng-Yin.Lee@alcatel.com; 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: ccamp-data@psg.com Delivery-date: Tue, 10 Jun 2003 22:26:01 +0000 Date: Tue, 10 Jun 2003 18:23 -0400 (EDT) From: Len Nieman Subject: LMP-MIB Module Compile Test To: ccamp@ops.ietf.org Cc: mpls@UU.NET Message-id: <0HGA00165E8W93@pmismtp04.wcomnet.com> 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: ccamp-data@psg.com Delivery-date: Tue, 10 Jun 2003 19:17:53 +0000 Message-ID: <024801c32f84$c9a0c110$681810ac@movaz.com> From: "Adrian Farrel" To: Cc: , , "Ron Bonica" , "'Kireeti Kompella'" 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" To: "Adrian Farrel" ; "'Kireeti Kompella'" ; Cc: ; 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Adrian Farrel > > Sent: Tuesday, May 27, 2003 3:57 PM > > To: 'Kireeti Kompella'; Ron Bonica; ccamp@ops.ietf.org > > Cc: stefaan.de_cnodder@alcatel.be; Cheng-Yin.Lee@alcatel.com; 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: ccamp-data@psg.com Delivery-date: Tue, 10 Jun 2003 11:59:52 +0000 Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC08A75F3F@cms1> From: yhwkim@etri.re.kr To: ccamp@ops.ietf.org, jplang@ieee.org Subject: Question of Dynamic Configuration of Label Using LMP Date: Tue, 10 Jun 2003 20:57:32 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F47.7945D8F0" 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. : yhwkim@etri.re.kr ****************************************** ------_=_NextPart_001_01C32F47.7945D8F0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Question of Dynamic Configuration of Label Using LMP

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. : yhwkim@etri.re.kr
******************************************

------_=_NextPart_001_01C32F47.7945D8F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 10 Jun 2003 11:52:41 +0000 Message-Id: <200306101149.HAA21215@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-9150607.I-D@ietf.org> 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: <2003-6-9150607.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 07 Jun 2003 23:12:16 +0000 Date: Sat, 07 Jun 2003 19:10:02 -0400 From: Ron Bonica Subject: RE: draft-ietf-ccamp-tracereq To: Kireeti Kompella , Xiaoming Fu Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Kireeti Kompella > Sent: Friday, June 06, 2003 6:00 PM > To: Xiaoming Fu > Cc: Ron Bonica; ccamp@ops.ietf.org > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jun 2003 22:38:47 +0000 Date: Fri, 6 Jun 2003 15:38:26 -0700 (PDT) From: Kireeti Kompella To: Stephen Shew cc: ccamp@ops.ietf.org, Stephen Trowbridge , "Wijnen, Bert" , "" , "Ronald P. Bonica" Subject: RE: ASON RSVP-TE extensions Message-ID: <20030606153502.I14888@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jun 2003 22:35:24 +0000 Date: Fri, 6 Jun 2003 15:34:46 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-tracereq Message-ID: <20030606150019.B14888@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jun 2003 22:02:50 +0000 Date: Fri, 6 Jun 2003 15:00:15 -0700 (PDT) From: Kireeti Kompella To: Xiaoming Fu cc: Ron Bonica , "" Subject: Re: draft-ietf-ccamp-tracereq Message-ID: <20030606145649.F14888@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jun 2003 08:52:08 +0000 Message-ID: <3EE053ED.3060008@cs.uni-goettingen.de> Date: Fri, 06 Jun 2003 10:42:21 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 MIME-Version: 1.0 To: Ron Bonica CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-tracereq Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Xiaoming Fu >>Sent: Wednesday, June 04, 2003 6:12 AM >>To: Ron Bonica >>Cc: ccamp@ops.ietf.org >>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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>>>Behalf Of Xiaoming Fu >>>>Sent: Friday, May 30, 2003 7:20 PM >>>>To: Ron Bonica >>>>Cc: ccamp@ops.ietf.org >>>>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 >>>> >>>> >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 06 Jun 2003 02:46:57 +0000 Date: Thu, 05 Jun 2003 22:42:02 -0400 From: Ron Bonica Subject: RE: draft-ietf-ccamp-tracereq To: Xiaoming Fu Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Xiaoming Fu > Sent: Wednesday, June 04, 2003 6:12 AM > To: Ron Bonica > Cc: ccamp@ops.ietf.org > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > >>Behalf Of Xiaoming Fu > >>Sent: Friday, May 30, 2003 7:20 PM > >>To: Ron Bonica > >>Cc: ccamp@ops.ietf.org > >>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 > >> > >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 05 Jun 2003 19:32:32 +0000 Reply-To: From: "Vishal Sharma" To: "CCAMP" Cc: "Tom Nadeau" , "Monique J. Morrow" Subject: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue Call for Papers Date: Thu, 5 Jun 2003 12:30:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: mmorrow@cisco.com Tom Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824, USA. Email: tnadeau@cisco.com Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA. Email: v.sharma@ieee.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 05 Jun 2003 14:27:48 +0000 From: "hnaser" To: Cc: Subject: Failure rate Date: Thu, 5 Jun 2003 10:24:16 -0400 Message-ID: <000701c32b6e$25419dc0$dc5a7a89@STE4066> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C32B4C.9E2FFDC0" 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: hnaser@site.uottawa.ca =20 =20 =20 ------=_NextPart_000_0008_01C32B4C.9E2FFDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greeting,

 

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.

 

Thank you.  

 

Hassan Naser, Ph.D.

University of Ottawa
School of Information Technology and Engineering (SITE)
800 King Edward Avenue
Ottawa, Ontario, = Canada, K1N 6N5
Tel: (613) 562-5800 ext. 2123
Fax: (613) 562-5664
Email: hnaser@site.uottawa.ca

 

 

------=_NextPart_000_0008_01C32B4C.9E2FFDC0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 04 Jun 2003 16:26:52 +0000 Message-ID: <3EDE1D64.93BD6C9@lucent.com> Date: Wed, 04 Jun 2003 10:25:08 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Stephen Shew CC: "'Kireeti Kompella'" , ccamp@ops.ietf.org, "Wijnen, Bert" , zinin@psg.com, "Ronald P. Bonica" Subject: Re: ASON RSVP-TE extensions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:kireeti@juniper.net] > Sent: Friday, May 30, 2003 18:46 > To: ccamp@ops.ietf.org > Cc: Stephen Trowbridge; Wijnen, Bert; zinin@psg.com; 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. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 04 Jun 2003 15:47:49 +0000 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E604343E7C@zcard0ke.ca.nortel.com> From: "Stephen Shew" To: "'Kireeti Kompella'" , ccamp@ops.ietf.org Cc: Stephen Trowbridge , "Wijnen, Bert" , zinin@psg.com, "Ronald P. Bonica" Subject: RE: ASON RSVP-TE extensions Date: Wed, 4 Jun 2003 11:44:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32AB0.2A888D8E" 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:kireeti@juniper.net] Sent: Friday, May 30, 2003 18:46 To: ccamp@ops.ietf.org Cc: Stephen Trowbridge; Wijnen, Bert; zinin@psg.com; 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 RE: ASON RSVP-TE extensions

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:kireeti@juniper.net] =
Sent: Friday, May 30, 2003 18:46
To: ccamp@ops.ietf.org
Cc: Stephen Trowbridge; Wijnen, Bert; zinin@psg.com; = 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 04 Jun 2003 13:19:12 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Wavelength encoding: question on lmp-mib Date: Wed, 4 Jun 2003 09:17:56 -0400 Message-ID: <83040F98B407E6428FEC18AC720F5D73200F11@exchange.tropicnetworks.com> Thread-Topic: Wavelength encoding: question on lmp-mib Thread-Index: AcMo/Dwhqz0BO2Z0TnCC6rgE9E9tQgBnK/nw From: "Udo Neustadter" To: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 04 Jun 2003 10:14:40 +0000 Message-ID: <3EDDC5EA.5080205@cs.uni-goettingen.de> Date: Wed, 04 Jun 2003 12:11:54 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 MIME-Version: 1.0 To: Ron Bonica CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-tracereq Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >>Behalf Of Xiaoming Fu >>Sent: Friday, May 30, 2003 7:20 PM >>To: Ron Bonica >>Cc: ccamp@ops.ietf.org >>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 >> >> Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jun 2003 14:42:06 +0000 Message-ID: From: "Hamid Ould-Brahim" To: Ron Bonica , ccamp@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt Date: Tue, 3 Jun 2003 10:16:38 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C329DA.BE4122D8" 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:hbrahim@nortelnetworks.com] Sent: Tuesday, June 03, 2003 9:38 AM To: Ron Bonica; ccamp@ops.ietf.org 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: owner-ccamp@ops.ietf.org [ mailto:owner-ccamp@ops.ietf.org ]On > > Behalf Of Internet-Drafts@ietf.org > > Sent: Tuesday, June 03, 2003 7:46 AM > > To: IETF-Announce: > > Cc: ccamp@ops.ietf.org > > 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: > > mailserv@ietf.org. > > 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 RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt
Okay.
 
Hamid.
 
That=20 is exactly the intent of requirements 7 and 8.
 
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 X over = any Y=20 as well as any Y over any X. It should also support multiple levels = of nesting=20 (X over Y over Z).
 
       &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;          =20    Ron
 
-----Original Message-----
From: Hamid = Ould-Brahim=20 [mailto:hbrahim@nortelnetworks.com]
Sent: Tuesday, June = 03, 2003=20 9:38 AM
To: Ron Bonica; = ccamp@ops.ietf.org
Subject: RE:=20 I-D ACTION:draft-ietf-ccamp-tracereq-04.txt

Ron,

This is a good document. I just have one=20 clarification/comment:

in the draft:

"7) Support the following tunneling technologies: = GRE, MPLS,=20 IPSEC,
      = GMPLS,=20 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=20 IP
tunnels are carrying MPLS-in-IP or = MPLS-in-GRE=20 encapsulation.

Should that be explicitly mentioned (since it has = implication
on the type)?.

Hamid.

>
> Pleae review = this version.=20 It is the most recent.
> =
>          = ;            = ;          =20 Ron
>
> = >=20 -----Original Message-----
> > = From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org= ]On=20
> > Behalf Of = Internet-Drafts@ietf.org=20
> > Sent: Tuesday, June 03, 2003 7:46 = AM=20
> > To: IETF-Announce:
>=20 > Cc: ccamp@ops.ietf.org
> > = Subject: I-D=20 ACTION:draft-ietf-ccamp-tracereq-04.txt
> >=20
> >
> = > A New=20 Internet-Draft is available from the on-line
>=20 > Internet-Drafts directories.
> = > This=20 draft is a work item of the Common Control and Measurement =
> > Plane Working Group of the IETF. =
> >
> > =    =20 Title           : = Tracing=20 Requirements for Generic Tunnels
> = >=20     Author(s)       : = R.=20 Bonica, K. Kompella, D. Meyer
> >=20     = Filename        :=20 draft-ietf-ccamp-tracereq-04.txt
> = >=20     Pages  =20         : 9
>=20 >     Date   =20         : 2003-6-2 =
> >    
> > This=20 document specifies requirements for a generic route-tracing =
> > application.  It also specifies = requirements for a=20 protocol
> that will
>=20 > support that application. Network operators will use the = generic=20
> > route-tracing application to verify = proper=20 operation of the IP
> > forwarding = plane. They=20 will also use the application to discover
> >=20 details regarding tunnels that support IP forwarding. =
> > The generic route-tracing application, specified = herein,=20 supports a
> > superset of the = functionality=20 that 'traceroute' currently offers.
> = > Like=20 traceroute, the generic route-tracing application can = discover=20
> > the forwarding path between two = interfaces that=20 are contained by an
> > IP network. = Unlike=20 traceroute, this application can reveal details
>=20 > regarding tunnels that support the IP forwarding path. =
> >
> > A URL for = this=20 Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.= txt=20
> >
> > To = remove=20 yourself from the IETF Announcement list, send a
> message to
> >=20 ietf-announce-request with the word unsubscribe in the body of=20
> > the message.
>=20 >
> > Internet-Drafts are also = available by=20 anonymous FTP. Login with
> > the=20 username
> > "anonymous" and a = password of=20 your e-mail address. After logging in,
> >=20 type "cd internet-drafts" and then
> = >=20     "get draft-ietf-ccamp-tracereq-04.txt". =
> >
> > A list of = Internet-Drafts=20 directories can be found in
> > http://www.ietf.org/shadow.html= =20
> > or ftp://ftp.ietf.org/ie= tf/1shadow-sites.txt=20
> >
> >=20
> > Internet-Drafts can also be = obtained by=20 e-mail.
> >
> >=20 Send a message to:
> > =    =20 mailserv@ietf.org.
> > In the body=20 type:
> >     "FILE=20 /internet-drafts/draft-ietf-ccamp-tracereq-04.txt". =
> >    
> >=20 NOTE:       The mail server at = ietf.org can=20 return the document in
> > =    =20 MIME-encoded form by using the "mpack" utility.  To use = this=20
> >     feature, insert the = command=20 "ENCODING mime" before the "FILE"
> = >=20     command.  To decode the response(s), you = will need=20 "munpack" or
> >     = a=20 MIME-compliant mail reader.  Different MIME-compliant =
> mail readers
> >=20     exhibit different behavior, especially when = dealing=20 with
> >     = "multipart" MIME=20 messages (i.e. documents which have been split
>=20 >     up into multiple messages), so check your = local=20 documentation on
> > =     how to=20 manipulate these messages.
> >=20            =20
> >    =20        
> >=20 Below is the data which will enable a MIME compliant mail = reader=20
> > implementation to automatically = retrieve the=20 ASCII version of the
> >=20 Internet-Draft.
> > =
>

------_=_NextPart_001_01C329DA.BE4122D8-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jun 2003 14:07:26 +0000 Date: Tue, 03 Jun 2003 10:03:43 -0400 From: Ron Bonica Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt To: Hamid Ould-Brahim , ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CcVaiTxxars4sYmiILz+Kw)" 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:hbrahim@nortelnetworks.com] Sent: Tuesday, June 03, 2003 9:38 AM To: Ron Bonica; ccamp@ops.ietf.org 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Internet-Drafts@ietf.org > > Sent: Tuesday, June 03, 2003 7:46 AM > > To: IETF-Announce: > > Cc: ccamp@ops.ietf.org > > 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: > > mailserv@ietf.org. > > 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 RE: I-D = ACTION:draft-ietf-ccamp-tracereq-04.txt
Hamid,
 
That=20 is exactly the intent of requirements 7 and 8.
 
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 X over = any Y as=20 well as any Y over any X. It should also support multiple levels of = nesting (X=20 over Y over Z).
 
       &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         =20    Ron
 
-----Original Message-----
From: Hamid Ould-Brahim=20 [mailto:hbrahim@nortelnetworks.com]
Sent: Tuesday, June 03, = 2003=20 9:38 AM
To: Ron Bonica; = ccamp@ops.ietf.org
Subject: RE:=20 I-D ACTION:draft-ietf-ccamp-tracereq-04.txt

Ron,

This is a good document. I just have one=20 clarification/comment:

in the draft:

"7) Support the following tunneling technologies: = GRE, MPLS,=20 IPSEC,
      GMPLS, = IP-in-IP,=20 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=20 IP
tunnels are carrying MPLS-in-IP or = MPLS-in-GRE=20 encapsulation.

Should that be explicitly mentioned (since it has=20 implication
on the type)?.

Hamid.

>
> Pleae review = this version.=20 It is the most recent.
>
>          =             &= nbsp;         =20 Ron
>
> > = -----Original Message-----
> > From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org<= /A>]On=20
> > Behalf Of Internet-Drafts@ietf.org =
> > Sent: Tuesday, June 03, 2003 7:46 AM =
> > To: IETF-Announce:
> = > Cc:=20 ccamp@ops.ietf.org
> > Subject: I-D=20 ACTION:draft-ietf-ccamp-tracereq-04.txt
> = >=20
> >
> = > A New=20 Internet-Draft is available from the on-line
> >=20 Internet-Drafts directories.
> > This = draft is a=20 work item of the Common Control and Measurement
>=20 > Plane Working Group of the IETF.
> = >=20
> >     = Title  =20         : Tracing Requirements for = Generic=20 Tunnels
> >    =20 Author(s)       : R. Bonica, K. = Kompella, D.=20 Meyer
> >    =20 Filename        :=20 draft-ietf-ccamp-tracereq-04.txt
> >=20     Pages  =20         : 9
>=20 >     Date   =20         : 2003-6-2
> >    
> = > This=20 document specifies requirements for a generic route-tracing =
> > application.  It also specifies requirements = for a=20 protocol
> that will
>=20 > support that application. Network operators will use the = generic=20
> > route-tracing application to verify = proper=20 operation of the IP
> > forwarding = plane. They=20 will also use the application to discover
> >=20 details regarding tunnels that support IP forwarding.
> > The generic route-tracing application, specified = herein,=20 supports a
> > superset of the = functionality=20 that 'traceroute' currently offers.
> = > Like=20 traceroute, the generic route-tracing application can discover=20
> > the forwarding path between two = interfaces that are=20 contained by an
> > IP network. Unlike = traceroute, this application can reveal details
>=20 > regarding tunnels that support the IP forwarding path. =
> >
> > A URL for this=20 Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-tracereq-04.txt= =20
> >
> > To = remove=20 yourself from the IETF Announcement list, send a
>=20 message to
> > ietf-announce-request = with the=20 word unsubscribe in the body of
> > = the=20 message.
> >
> >=20 Internet-Drafts are also available by anonymous FTP. Login with=20
> > the username
>=20 > "anonymous" and a password of your e-mail address. After logging=20 in,
> > type "cd internet-drafts" and=20 then
> >     "get=20 draft-ietf-ccamp-tracereq-04.txt".
> > =
> > A list of Internet-Drafts = directories can be=20 found in
> > http://www.ietf.org/shadow.html<= /A>=20
> > or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt=20
> >
> > =
> > Internet-Drafts can also be obtained by = e-mail.=20
> >
> > Send = a message=20 to:
> >    =20 mailserv@ietf.org.
> > In the body = type:=20
> >     "FILE=20 /internet-drafts/draft-ietf-ccamp-tracereq-04.txt".
> >    
> = >=20 NOTE:       The mail server at ietf.org = can=20 return the document in
> > =    =20 MIME-encoded form by using the "mpack" utility.  To use = this=20
> >     feature, insert the = command=20 "ENCODING mime" before the "FILE"
> >=20     command.  To decode the response(s), you will = need=20 "munpack" or
> >     a=20 MIME-compliant mail reader.  Different MIME-compliant =
> mail readers
> > =    =20 exhibit different behavior, especially when dealing with =
> >     "multipart" MIME messages (i.e. = documents=20 which have been split
> > =     up=20 into multiple messages), so check your local documentation on =
> >     how to manipulate these = messages.=20
> >    =20        
> >=20             =
> > Below is the data which will enable a MIME = compliant mail=20 reader
> > implementation to = automatically=20 retrieve the ASCII version of the
> >=20 Internet-Draft.
> >
>=20

--Boundary_(ID_CcVaiTxxars4sYmiILz+Kw)-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jun 2003 13:38:34 +0000 Message-ID: From: "Hamid Ould-Brahim" To: Ron Bonica , ccamp@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt Date: Tue, 3 Jun 2003 09:37:33 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C329D5.494C6B86" 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Internet-Drafts@ietf.org > > Sent: Tuesday, June 03, 2003 7:46 AM > > To: IETF-Announce: > > Cc: ccamp@ops.ietf.org > > 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: > > mailserv@ietf.org. > > 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 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org= ]On
> > Behalf Of Internet-Drafts@ietf.org
> > Sent: Tuesday, June 03, 2003 7:46 = AM
> > To: IETF-Announce:
> > Cc: ccamp@ops.ietf.org
> > 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-t= racereq-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:
> >     = mailserv@ietf.org.
> > 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jun 2003 12:56:47 +0000 Date: Tue, 03 Jun 2003 08:52:46 -0400 From: Ron Bonica Subject: FW: I-D ACTION:draft-ietf-ccamp-tracereq-04.txt To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_8kcYjPjn+uJkzpVgRacxgg)" 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, June 03, 2003 7:46 AM > To: IETF-Announce: > Cc: ccamp@ops.ietf.org > 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: > mailserv@ietf.org. > 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: <2003-6-2145357.I-D@ietf.org> 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: <2003-6-2145357.I-D@ietf.org> --Boundary_(ID_8kcYjPjn+uJkzpVgRacxgg)-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jun 2003 11:51:29 +0000 Message-Id: <200306031146.HAA27217@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-2145339.I-D@ietf.org> 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: <2003-6-2145339.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 03 Jun 2003 11:51:21 +0000 Message-Id: <200306031146.HAA27232@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-2145357.I-D@ietf.org> 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: <2003-6-2145357.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jun 2003 14:15:14 +0000 Message-ID: <002001c32911$297f7e70$681810ac@movaz.com> From: "Adrian Farrel" To: "Kireeti Kompella" Cc: 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jun 2003 13:01:16 +0000 Date: Mon, 02 Jun 2003 09:00:24 -0400 From: Ron Bonica Subject: FW: I-D ACTION:draft-ietf-ccamp-tracereq-03.txt To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, June 02, 2003 7:29 AM > To: IETF-Announce: > Cc: ccamp@ops.ietf.org > 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: > mailserv@ietf.org. > 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. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jun 2003 11:31:04 +0000 Message-Id: <200306021128.HAA01624@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-30152027.I-D@ietf.org> 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: <2003-5-30152027.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 02 Jun 2003 11:30:57 +0000 Message-Id: <200306021128.HAA01608@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-30152017.I-D@ietf.org> 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: <2003-5-30152017.I-D@ietf.org> --OtherAccess-- --NextPart--