Non-member submission from [David Ward <[e-mail]>]

["Adrian Farrel" <[e-mail]>]

> Adrian -
>
> There is certainly no reason to *require OSPF to use the same mechanism as
> IS-IS to prevent looping of advertisements. If the OSPF folks are 
> convinced
> this works (seems like it should) I don't have any objection. As for the
> pragmatics of having multiple solutions, I don't quite get it but that is
> another conversation.
>
> My only quibble is the use of the term "level 2 area", which indicates it
> was written by on OSPF person! It should of course say "level 2 domain".
> Tsk, tsk.
>
> -DWard
>
>
> On 4/24/07 12:21 PM, "Adrian Farrel" <[e-mail]> wrote:
>
>> Hi,
>>
>> CCAMP asked us a specific question with regard to loop prevention in OSPF
>> ASON Routing and why we had chosen not to use the mechanisms provided for
>> loop prevention in IS-IS for IP and MPLS-TE.
>>
>> Here is a draft response. (Thanks to Deborah, Dimitri, Acee, and Abhay 
>> for
>> help in preparing it.)
>>
>> Please let me have your comments by Saturday 5th April.
>>
>> Thanks,
>> Adrian
>>
>>  ===
>>
>> To: ITU-T Q14/15
>> From: IETF CCAMP Working Group
>> Cc: Stephen Trowbridge, Kam Lam, Dave Ward, Ross Callon, Acee
>> Lindem, Rohit Dube, CCAMP Working Group, OSPF Working Group
>> Subject: Loop Prevention Mechanisms in OSPF for ASON Networks
>> For Action
>>
>> The CCAMP Working Group thanks you for your liaison "Liaison
>> Statement to CCAMP responding to ccamp liaison of 21 February 2007"
>> generated at your Darmstadt interim meeting and dated March 2007.
>>
>> This liaison continues an exchange about the loop prevention
>> mechanisms introduced to in draft-ietf-ccamp-gmpls-ason-routing-
>> ospf-03.txt "OSPFv2 Routing Protocols Extensions for ASON Routing".
>> In your liaison "Response to IETF CCAMP WG LS (TD314/3) on
>> "Notification of work in the IETF CCAMP working group"" dated
>> November 2006 you said:
>>
>>     As discussed within Section 6 on routing information dissemination,
>>     and per the ASON link state routing requirements in G.7715.1, it
>>     is essential to avoid feedback loops that may arise when both
>>     upward and downward communication interfaces contain endpoint
>>     reachability information.  Thus, we fully agree that providing
>>     associated import/export rules is an essential element of OSPF
>>     routing protocol design.  In reviewing Sections 6.1 - 6.5 of the
>>     draft, we observed that several new mechanisms are being
>>     proposed to address this important problem.  It was observed
>>     that RFC 2966, which has already considered and addressed
>>     such issues, appears to contain an applicable, relatively simple
>>     solution mechanism (within Section 3.1) that is not specific to the
>>     IS-IS protocol.  Given RFC 2966 offers a solution that has been
>>     proven and implemented by multiple vendors, yielding the potential
>>     opportunity for reuse, we wondered whether you had identified
>>     any drawbacks in pursuing such an approach.
>>
>>     Please provide us with your thoughts on the usage of this alternative
>>     method.
>>
>> In our response liaison "Response to your liaison on current ASON
>> work in CCAMP" dated 21st February 2007 we replied:
>>
>>      We are glad that you agree with our assessment that it
>>      is an essential element of OSPF routing protocol design
>>      to provide import/export rules to prevent feedback
>>      loops.
>>
>>      RFC2966 presents a solution to this problem specific to
>>      the ISIS protocol, although, as you say, this mechanism
>>      could be adapted to other protocols.
>>
>>      But other mechanisms also exist, and the ultimate
>>      solution that we choose must be agreed not by the ISIS
>>      community, but by the OSPF community. In this case, the
>>      choice was made after careful evaluation in cooperation
>>      with IETF's OSPF Working Group.
>>
>>      Please let us know whether you have any technical
>>      issues with the approach we have chosen, and if so,
>>      what the issues are.
>>
>> In your most recent liaison, you say:
>>
>>     On the selection of a loop prevention mechanism the liaison
>>     statement indicates that  "the choice was made after careful
>>     evaluation in cooperation with IETF's OSPF Working Group."
>>     We would appreciate further details of these considerations to
>>     allow us to fully understand the thought going into this decision
>>     and evaluate any impacts on the transport network.
>>
>> We are happy to provide a summary of the decision.
>>
>> RFC 2966 is titled "Domain-wide Prefix Distribution with Two-Level
>> IS-IS", and the Abstract reads:
>>
>>     This document describes extensions to the Intermediate System to
>>     Intermediate System (IS-IS) protocol to support optimal routing
>>     within a two-level domain.  The IS-IS protocol is specified in ISO
>>     10589, with extensions for supporting IPv4 (Internet Protocol)
>>     specified in RFC 1195 [2].
>>
>>     This document extends the semantics presented in RFC 1195 so that a
>>     routing domain running with both level 1 and level 2 Intermediate
>>     Systems (IS) [routers] can distribute IP prefixes between level 1 and
>>     level 2 and vice versa.  This distribution requires certain
>>     restrictions to insure that persistent forwarding loops do not  form.
>>     The goal of this domain-wide prefix distribution is to increase the
>>     granularity of the routing information within the domain.
>>
>> The problem that RFC 2966 addresses is for a two level domain. The
>> problem is that, because of the way IS-IS is defined to exchange IP
>> prefixes between levels, it is possible that a routing loop could
>> be formed. The issue arises when an IS-IS layer 1 area is dual
>> homed to the IS-IS layer 2 area and the prefixes advertised from
>> one layer into the other at one L1L2 router (Ra) are re-advertised
>> back into the originating IS-IS layer at another L1L2 router (Rb)
>> making it appear that the shortest path to a prefix from Rb is
>> through Ra. The fix in RFC 2966 uses the up/down bit to make sure
>> that advertisements do not continually circulate between layers.
>> RFC 3784 "Intermediate System to Intermediate System (IS-IS)
>> Extensions for Traffic Engineering (TE)" defines traffic
>> engineering information distribution mechanisms using IS-IS. This
>> work is further extended by RFC 4205 "Intermediate System to
>> Intermediate System (IS-IS) Extensions in Support of Generalized
>> Multi-Protocol Label Switching (GMPLS)". RFC 3784 allows the
>> extended reachability TLV to be exchanged between IS-IS layers.
>> This means that TE information can be exchanged between IS-IS
>> layers, and the up/down bit is necessary to stop the advertisements
>> circulating for ever.
>>
>> But, it is important to note that since the TE information is used
>> to build a topology representation in the Traffic Engineering
>> Database, there is no risk of data looping. Contrast this with the
>> problem addressed in RFC 2966 where shortest path first
>> computations provided per IS-IS layer might cause data looping.
>> Thus, the only problem addressed by the use of the up/down bit in
>> RFC 3784 is that of endlessly circulating information.
>>
>> Now, OSPF addresses the original looping problem in a different
>> way. It restricts the advertisement of prefixes between areas by
>> using different LSA types and flooding scopes. Thus, information
>> leaked from Area 0 into some other subtended area is never leaked
>> back into Area 0.
>>
>> Further in OSPF-TE, there is no danger of endlessly looping
>> information between Area 0 and the subtended areas because RFC 3630
>> "Traffic Engineering (TE) Extensions to OSPF Version 2" instructs
>> us to use the type 10 opaque LSA for distributing TE information.
>> And, as defined in RFC 2370 "The OSPF Opaque LSA Option" a type 10
>> opaque LSA is not distributed outside the area in which it was
>> generated.
>>
>> The problem that must be addressed in draft-dimitri-ccamp-gmpls-
>> ason-routing-ospf is caused because of a deliberate change in
>> information leakage processing. That is, in the ASON network,
>> selected upward and downward redistribution of TE information is
>> allowed. Thus, OSPF-TE is opened up to the possibility of
>> information distribution looping (although still not of looping of
>> computed data paths).
>>
>> As section 6.3 of draft-dimitri-ccamp-gmpls-ason-routing-
>> ospf-03.txt says:
>>
>>    When more than one RC are bound to adjacent levels of the hierarchy,
>>    configured and selected to redistribute upward and downward the
>>    routing information, a specific mechanism is required to avoid
>>    looping/re-introduction of routing information back to the upper
>>    level. This specific case occurs e.g. when the RC advertising
>>    routing information downward the hierarchy is not the one
>>    advertising routing upward the hierarchy (or vice-versa).
>>
>>    When these conditions are met, it is necessary to have a means by
>>    which an RC receiving an Opaque TE LSA imported/exported
>>    downward by an RC associated with the same area, suppresses the
>>    import/export back of the content of this LSA upward into the
>>    (same) upper level.
>>
>> Clearly it is necessary to add some indication of the origin of the
>> data into the advertisement. The mechanism proposed in draft-
>> dimitri-ccamp-gmpls-ason-routing-ospf-03.txt is to add the Area ID
>> of the OSPF area containing the originating RC. This provides more
>> information than the simple up/down bit of RFC 2966 and allows an
>> easy distinction to be made between advertising information
>> received from a lower layer area down into a different lower layer
>> area, and back into the same lower layer area.
>>
>> We hope this clarifies the similarities and differences with RFC
>> 2966, and hope that you will ask if you have further specific
>> questions. As before, we encourage you to examine the resulting
>> functionality and to provide us with technical arguments if you
>> believe the function is inappropriate for a transport network, or
>> if you see any specific issues with the proposed approach.
>>
>> Best regards,
>> Adrian Farrel and Deborah Brungard
>> IETF CCAMP Working Group Co-Chairs
>
>
>
>
>