FW: IESG comments on draft-ietf-ipo-framework

Here's the IESG's comments on the IPO framework draft
(draft-ietf-ipo-framework-02.txt). 

If you have thoughts on the comments, please submit
them to the list.

In the meantime, the authors will compile a formal response
and update the draft appropriately. 

Cheers,
/Dan

-----Original Message-----
From: Scott Bradner [mailto:[email protected]]
Sent: Saturday, September 07, 2002 4:50 PM
To: [email protected]; [email protected]
Subject: IESG comments on draft-ietf-ipo-framework


the IESG has dicusssed the current version of draft-ietf-ipo-framework and
has these comments

Scott
----------------------------------------------------------
Bert:
- the ID has 6 authors which exceeds RFC Editor guidelines
- I wonder if this is a "framework" or rather a "overview of
  IPO Networking aspects".
- It talks a whole lot about all the layer 1 stuff. Is that
  a space where we feel comfortable publishing docs?
- It speaks even more about UNI, I-NNI and E-NNI, a space
  that we deliberately did not go into when we started   
  SUB-IP area, and a space that is basically being worked
  by the OIF. So should we be publishing docs in that space?
- I wonder if and how sect 6.2.2.1 relates to our recent discussion
  on the use of RPs (BGP in this case, 2547) in the area of VPN.
  There is more on the possible use of RPs in sect 7.7.2
- It talks about the use of LMP for neighbor/service discovery
  (sections 5.1 and 7.2), and I see some debate on that on the
  CCAMP mailing list as to wether that is good or bad.

----------------------------------------------------------
Thomas
   Under the unified service model, optical network services are
   obtained implicitly during end-to-end MPLS signaling. Specifically,
   an edge router can create a lightpath with specified attributes, or
   delete and modify lightpaths as it creates MPLS label-switched paths
   (LSPs). In this regard, the services obtained from the optical

reads like MPLS is assumed/required part of framework. Is this the
case?

   The notion of "forwarding adjacency" (FA) described in [3] is
   essential in propagating existing lightpath information to other
   routers. An FA is essentially a virtual link advertised into a link

   3. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE,"
      Internet Draft, Work in progress.

Is reference to this document normative? What is its status?

nits:

   may be expected that each sub-network will consist of a single
   vendor switches. In the future, as standardization efforts mature,

s/vendor/vendor's/ ??

   connectivity service offered by the optical network. For example,

missing rest of sentence.

   control planes over the UNI. As described in Section 6, the optical

this is section 6. Is the reference right? or say "in this section"?

   recommendation \xfb even choice \xfb within this framework document,


funny characters

        also be established specifying only which SRLGs to AVOID in a

AVOID (upper case)?

    2. The primary path and the back-up path are comptuted together in

spelling  

   setup would be to quickly pre-provisioned paths based on some

pre-provision

   (NMS) for static connection management is prevelant in legacy

prevalent

   well), or updrade the NMS software in order to introduce some degree

spell

----------------------------------------------------------
Steve
Section 3:
        The notion of a "trust domain" is very dangerous, even without
        the extension to multiple administrative domains.

(Nit on 4.1:  speaking of "*coherent* end-to-end provisioning" is
slightly ambiguous...)

(Serious nit:  what is PMD?)

The second paragraph of 10.1 is generic and should be deleted.
(And the notion that TCP sequence numbers can be trusted, in the
absence of stronger anti-replay mechanisms, is wrong.)

The document is missing some threat concepts:


        Even within a "trust domain",
        *any* subverted node can send control messages,
        since the control plane is IP -- it doesn't have to be a
        misbehaving optical element.

        Optical routing is strictly more dangerous than IP routing,
        since attacks on the former show up via traceroute and the
        like.  But optical elements are invisible (so to speak)
        to IP nodes.  Thus, the output of RPSEC should be considered
        in eventual protocols.

        Requests from client networks must be filtered against policy,
        to guard against excess resource consumption.  (There's some
        discussion of that, but not enough.)  There's another
        possible denial of service attack that might be worth thinking
        about:  could requests for improbable paths (i.e., paths for
        which the network wasn't heavily provisioned) consume all of
        the ports on internal OXCs?  If so, global co-ordination of
        service requests might be needed.

        I recall some document (I can't recall which) mentioned the
        need for confidentiality for SRLG information.