Subject: Chair review of draft-ietf-ccamp-lsp-stitching-04.txt

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 31 Jan 2007 23:02:44 -0000

Hi,

As promised, I have done a review of this I-D to help the authors prepare it 
for WG last call. In my opinion, the draft is in pretty good shape, but 
there are a few minor issues.

If the authors can submit a new version to address these comments, we can 
take the I-D forward.

Thanks,
Adrian

===

idnits generates the following comments
  * There are 96 instances of too long lines in the document, the longest
    one being 1 character in excess of 72.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 22 pages

===

The boilerplate will need to be updated for the new IETF Trust language.

===
Abstract.

First paragraph is a good introduction.
Second paragraph is fine and OK.
But the Abstract also needs to say what the document is about!
I suggest the addition of a new 2nd paragraph as follows...

    This document describes extensions to the existing GMPLS signaling
    protocol (RSVP-TE) to establish e2e LSPs from S-LSPs, and describes
    how the LSPs can be managed using the GMPLS signaling and routing
    protocols.

===

Acronyms

Acronyms need to be expanded on their first use in the body of the document 
regardless of whether they appear in the document title or in the Abstract.
I found...
LSP
GMPLS
P2MP
RRO

===

Introduction

The Introduction section is pretty lumpy. It seems to spend most of its time 
talking about hierarchical LSPs, and only defines stitching in the final 
paragraph.

I suggest some re-ordering and a little editing as follows:

New Section 1

    A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic
    Engineering (TE) Label Switched Path (LSP) is built from a set of
    different LSP segments (S-LSPs) that are connected together in the
    data plane in such a way that a single end-to-end LSP is realized in
    the data plane.  In this document, we define the concept of LSP
    stitching and detail the control plane mechanisms and procedures
    (routing and signaling) to accomplish this.  Where applicable,
    similarities and differences between LSP hierarchy [2] and LSP
    stitching are highlighted.  Signaling extensions required for LSP
    stitching are also described here.

    It may be possible to configure a GMPLS node to switch the traffic
    from an LSP for which it is the egress, to another LSP for which it
    is the ingress, without requiring any signaling or routing extensions
    whatsoever, and such that the operation is completely transparent to
    other nodes.  This results in LSP stitching in the data plane, but
    requires management intervention at the node where the stitching is
    performed.  With the mechanism described in this document, the node
    performing the stitching does not require configuration of the pair
    of S-LSPs to be stitched together.  Also, LSP stitching as defined
    here results in an end-to-end LSP both in the control and data
    planes.

Move the following paragraphs (unchanged) from Section 1 to the top of 
Section 2.

    LSP hierarchy ([2]) provides signaling and routing procedures so
    that:

    a.  A Hierarchical LSP (H-LSP) can be created.  Such an LSP created
        in one layer can appear as a data link to LSPs in higher layers.
        As such, one or more LSPs in a higher layer can traverse this
        H-LSP as a single hop; we call this "nesting".

    b.  An H-LSP may be managed and advertised (although this is not a
        requirement) as a Traffic Engineering (TE) link.  Advertising an
        H-LSP as a TE link allows other nodes in the TE domain in which
        it is advertised to use this H-LSP in path computation.  If the
        H-LSP TE link is advertised in the same instance of control plane
        (TE domain) in which the H-LSP was provisioned, it is then
        defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes
        can form a forwarding adjacency (FA) over this FA-LSP.  There is
        usually no routing adjacency between end points of an FA.  An
        H-LSP may also be advertised as a TE link in a different TE
        domain.  In this case, the end points of the H-LSP are required
        have a routing adjacency between them.

    c.  RSVP signaling for LSP setup can occur between nodes that do not
        have a routing adjacency.

===

Section 3.2

It might be useful to include a reference to RFC4726 to give some context 
for inter-domain uses of stitching.

===

Security considerations

I don't think we will get away with what is currently written :-(
The killer is:
    Mechanisms described in [6] should be
    re-examined and may need to be altered to define new security
    associations based on receiver's IP address instead of the sending
    and receiving interfaces.

I think that if you say that the re-examination is needed, you must do it. 
You need to satisfy yourself as to whether any changes (beyond those 
expressed in RFC4206) are needed.

My view is that you should be able to echo the text of RFC4206 without 
needing anything further. This is because the relationship between the 
end-points of the S-LSP is the same as that between the end points of the 
H-LSP in RFC4206. The precedent for remote signaling adjacencies has already 
been established, and you are not defining anything new.

===

IANA considerations

It would be helpful to name the sub-registries to help IANA get these 
allocations right.

In section 7.1 the registry is "RSVP TE Parameters" (not the registry quoted 
in section 7) and the sub-registry is "Attributes Flags"

In section 7.2 the registry is "Resource ReSerVation Protocol (RSVP) 
Parameters" and the sub-registry is "Error Codes and Globally-Defined Error 
Value Sub-Codes"

It is also helpful to supply the precise text you would like added to the 
registry.

For section 7.1:

                                       Path      Resv      RRO
Bit   Name                             message   message   sub-object 
Reference
----  -------------------------------  --------  --------  ----------  ---------
5     LSP stitching desired bit        Yes       No        Yes         [This 
doc]

For section 7.2:

  24  Routing Problem                             [RFC3209]

        23 = Stitching unsupported  [This doc]

=== 

Delivery-date: Wed, 31 Jan 2007 23:06:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, "'Jean Philippe Vasseur'" <[email-masked]>
Subject: Chair review of draft-ietf-ccamp-lsp-stitching-04.txt
Date: Wed, 31 Jan 2007 23:02:44 -0000
Organization: Old Dog Consulting

Hi,

As promised, I have done a review of this I-D to help the authors prepare it 
for WG last call. In my opinion, the draft is in pretty good shape, but 
there are a few minor issues.

If the authors can submit a new version to address these comments, we can 
take the I-D forward.

Thanks,
Adrian

===

idnits generates the following comments
  * There are 96 instances of too long lines in the document, the longest
    one being 1 character in excess of 72.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 22 pages

===

The boilerplate will need to be updated for the new IETF Trust language.

===
Abstract.

First paragraph is a good introduction.
Second paragraph is fine and OK.
But the Abstract also needs to say what the document is about!
I suggest the addition of a new 2nd paragraph as follows...

    This document describes extensions to the existing GMPLS signaling
    protocol (RSVP-TE) to establish e2e LSPs from S-LSPs, and describes
    how the LSPs can be managed using the GMPLS signaling and routing
    protocols.

===

Acronyms

Acronyms need to be expanded on their first use in the body of the document 
regardless of whether they appear in the document title or in the Abstract.
I found...
LSP
GMPLS
P2MP
RRO

===

Introduction

The Introduction section is pretty lumpy. It seems to spend most of its time 
talking about hierarchical LSPs, and only defines stitching in the final 
paragraph.

I suggest some re-ordering and a little editing as follows:

New Section 1

    A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic
    Engineering (TE) Label Switched Path (LSP) is built from a set of
    different LSP segments (S-LSPs) that are connected together in the
    data plane in such a way that a single end-to-end LSP is realized in
    the data plane.  In this document, we define the concept of LSP
    stitching and detail the control plane mechanisms and procedures
    (routing and signaling) to accomplish this.  Where applicable,
    similarities and differences between LSP hierarchy [2] and LSP
    stitching are highlighted.  Signaling extensions required for LSP
    stitching are also described here.

    It may be possible to configure a GMPLS node to switch the traffic
    from an LSP for which it is the egress, to another LSP for which it
    is the ingress, without requiring any signaling or routing extensions
    whatsoever, and such that the operation is completely transparent to
    other nodes.  This results in LSP stitching in the data plane, but
    requires management intervention at the node where the stitching is
    performed.  With the mechanism described in this document, the node
    performing the stitching does not require configuration of the pair
    of S-LSPs to be stitched together.  Also, LSP stitching as defined
    here results in an end-to-end LSP both in the control and data
    planes.

Move the following paragraphs (unchanged) from Section 1 to the top of 
Section 2.

    LSP hierarchy ([2]) provides signaling and routing procedures so
    that:

    a.  A Hierarchical LSP (H-LSP) can be created.  Such an LSP created
        in one layer can appear as a data link to LSPs in higher layers.
        As such, one or more LSPs in a higher layer can traverse this
        H-LSP as a single hop; we call this "nesting".

    b.  An H-LSP may be managed and advertised (although this is not a
        requirement) as a Traffic Engineering (TE) link.  Advertising an
        H-LSP as a TE link allows other nodes in the TE domain in which
        it is advertised to use this H-LSP in path computation.  If the
        H-LSP TE link is advertised in the same instance of control plane
        (TE domain) in which the H-LSP was provisioned, it is then
        defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes
        can form a forwarding adjacency (FA) over this FA-LSP.  There is
        usually no routing adjacency between end points of an FA.  An
        H-LSP may also be advertised as a TE link in a different TE
        domain.  In this case, the end points of the H-LSP are required
        have a routing adjacency between them.

    c.  RSVP signaling for LSP setup can occur between nodes that do not
        have a routing adjacency.

===

Section 3.2

It might be useful to include a reference to RFC4726 to give some context 
for inter-domain uses of stitching.

===

Security considerations

I don't think we will get away with what is currently written :-(
The killer is:
    Mechanisms described in [6] should be
    re-examined and may need to be altered to define new security
    associations based on receiver's IP address instead of the sending
    and receiving interfaces.

I think that if you say that the re-examination is needed, you must do it. 
You need to satisfy yourself as to whether any changes (beyond those 
expressed in RFC4206) are needed.

My view is that you should be able to echo the text of RFC4206 without 
needing anything further. This is because the relationship between the 
end-points of the S-LSP is the same as that between the end points of the 
H-LSP in RFC4206. The precedent for remote signaling adjacencies has already 
been established, and you are not defining anything new.

===

IANA considerations

It would be helpful to name the sub-registries to help IANA get these 
allocations right.

In section 7.1 the registry is "RSVP TE Parameters" (not the registry quoted 
in section 7) and the sub-registry is "Attributes Flags"

In section 7.2 the registry is "Resource ReSerVation Protocol (RSVP) 
Parameters" and the sub-registry is "Error Codes and Globally-Defined Error 
Value Sub-Codes"

It is also helpful to supply the precise text you would like added to the 
registry.

For section 7.1:

                                       Path      Resv      RRO
Bit   Name                             message   message   sub-object 
Reference
----  -------------------------------  --------  --------  ----------  ---------
5     LSP stitching desired bit        Yes       No        Yes         [This 
doc]

For section 7.2:

  24  Routing Problem                             [RFC3209]

        23 = Stitching unsupported  [This doc]

=== 

Delivery-date: Wed, 31 Jan 2007 03:40:11 +0000
Date: Wed, 31 Jan 2007 11:38:27 +0800
From: Zhang Renhai <[email-masked]>
Subject: A New Internet-Draft on Advertising of inter-AS TE links
To: [email-masked], [email-masked]

Hi, allWe have just submitted the following draft in which we describe some problemsin inter-AS TE scenarios and the corresponding OSPF extension is introduced.PCE environment is also considerd in this I-d so I'd also like pce working groupto pay attention to it.we'd highly appreciate your comments.Thanks a lot,Zhang Renhai & Mach A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: OSPF Extensions in Support of Inter-AS (G)MPLS TE 
	Author(s)	: M. Chen, R. Zhang
	Filename	: draft-chen-ccamp-ospf-interas-te-extension-00.txt
	Pages		: 9
	Date		: 2007-1-30
	
   This document describes extensions to the OSPF to support inter-AS 
   Traffic engineering (TE). It defines OSPF extensions for the flooding 
   of inter-AS links information which can be used to perform inter-AS 
   path computation. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-chen-ccamp-ospf-interas-te-extension-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 at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-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.
<ftp://ftp.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-00.txt> 
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

Delivery-date: Wed, 31 Jan 2007 01:32:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Non-member submission from [[email-masked] (Sam Hartman)]
Date: Wed, 31 Jan 2007 01:29:55 -0000
Organization: Old Dog Consulting

----- Original Message ----- 
From: "Sam Hartman" <[email-masked]>
To: "Ross Callon" <[email-masked]>
Cc: "Sandy Murphy" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 30, 2007 10:21 PM
Subject: Re: Security considerations with 
draft-ietf-ccamp-rsvp-restart-ext-07

> Ross, as I've said before I definitely think analyzing the impact of
> malicious software--especially at domain boundaries etc-- is an
> important part of what we do.
>
> let me give you some examples of  things that we don't care about:
>
> * Malicious software could choose a different preferred route for some 
> packet.
>
> * Malicious software could advertize a prefix permitted by
>  configuration and cause other routers to send traffic for that
>  prefix to the malicious router.
>
> * Malicious software could consume CPU or create a denial of service on 
> other routers.
>
> And some malicious attacks I think we care about:
>
> * Malicious software could subvert configuration on other routers.
>  For example I'd consider it a BGP protocol bug if I set up filters
>  to constrain what prefixes a BGP speaker was allowed to announce to
>  me and that speaker being malicious could get around my filters.
>
>
> * Where malicious software on one side of a customer domain could violate 
> that domain boundary.  For example, in a 2547-style VPN, where PE does the 
> VPN encapsulation, malicious CE should not be able to violate traffic 
> isolation.
>
> The reason the assertions being made about the RSVP restart mechanism
> don't seem to ring true to those of us in the security community is
> that local state is often more trusted than network state and that
> there is an inversion of trust direction.  I think we're going to be
> very uncomfortable letting this spec go forward without at leat
> understanding what the new attacks are created by this spec.  I'm
> particularly uncomfortable with potential interactions between the
> restart mechanism and future extensions to objects in the path
> message.
>
>
>
> 

Delivery-date: Wed, 31 Jan 2007 01:32:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Non-member submission from [[email-masked] (Sandy Murphy)]
Date: Wed, 31 Jan 2007 01:30:29 -0000
Organization: Old Dog Consulting

----- Original Message ----- 
From: "Sandy Murphy" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 30, 2007 10:08 PM
Subject: Re: Security considerations with 
draft-ietf-ccamp-rsvp-restart-ext-07

> >If the router is mis-configured, whether intentionally or not, it won't
>>be intentionally sending bad information to the peer router for the
>>simple reason that no vendor is going to implement the "please
>>send incorrect information" configuration option.
>
> There are plenty of ways to say, not about rsvp in particular but about
> configuration in general, "reset the configuration to send X rather
> than Y".  That is what misconfiguration is.
>
> Surely the number of times prefixes have been mis-originated in the
> Internet is enough to demonstrate that sending bad information to a
> peer happens everywhere and often?
>
> Furthermore, can we say that root access to a router would not permit
> download of not a full new operating system but a small piece of code,
> that will counter the effect of the real routing code?  I don't think so.
> Let me know if that's wrong.
>
>>I don't think that it is possible to design a protocol that *both*
>>(i) Deals with the hacker produced Byzantine software case; and
>>also (ii) Works well enough in a normal network that anyone would
>>ever use it.
>
> No one is asking for the design of a protocol robust against Byzantine
> behavior, that's hard.  People are being asked to analyze their protocol
> that they are expert in to see how much damage byzantine behavior could
> do.  If byzantine behavior turns out to be no big deal, you're done.
> If byzantine behavior tunrs out to wreak havoc on a global scale, well,
> then you need to worry about how to prevent misconfiguration or software
> faults or subversion through other means.
>
> Note: turns out ccamp is subscribers-only.  So the ccamp people haven't
> seen any messages I've sent.  I've just subscribed, so this message may
> get through.  I'll resend everything the ccamp list misses.
>
> --Sandy
>
>
> 

Delivery-date: Tue, 30 Jan 2007 21:19:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Non-member submission from [[email-masked] (Ross Callon)]
Date: Tue, 30 Jan 2007 21:18:43 -0000
Organization: Old Dog Consulting

----- Original Message ----- 
From: "Ross Callon" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, January 30, 2007 8:59 PM
Subject: Re: Security considerations with 
draft-ietf-ccamp-rsvp-restart-ext-07

> There are a couple of things that are bugging me about this
> conversation (although I must admit that I am looking at the
> end of it -- the beginning being either lost in a very large
> email queue or less likely perhaps not sent to me).
>
> There are many ways that a router could be compromised. One
> is that it is accidentally mis-configured by a well intended
> operator. Another is that it is intentionally mis-configured by a
> hacker. A third way is that a hacker actually downloads his own
> software to the router, so that it is doing whatever Byzantine wrong
> thing a very clever hacker can think of to do.
>
> If the router is mis-configured, whether intentionally or not, it won't
> be intentionally sending bad information to the peer router for the
> simple reason that no vendor is going to implement the "please
> send incorrect information" configuration option.
>
> If the router contains software that is really written by the hacker,
> then the network will not work. It would be trivial to write code that
> runs the right routing protocol, and then just drops packets, or
> forwards packets randomly, or works fine with unicast, but *both*
> forwards multicast properly and in addition forwards additional
> copies of the multicast packet into a loop, so that thousands of
> copies of the same packet are delivered, or forwards the packets
> properly, and also keeps copies, or inserts a "man in the middle",
> or whatever. (if you get to write the software, and want to cause
> problems, there are lots of ways to cause very severe problems).
>
> I don't think that it is possible to design a protocol that *both*
> (i) Deals with the hacker produced Byzantine software case; and
> also (ii) Works well enough in a normal network that anyone would
> ever use it. One example of this would be Radia Perlman's PhD
> thesis on Byzantine routing, which does handle the Byzantine
> software case, but by using a protocol that no one would ever
> deploy in a normal network.
>
> They my second concern: If we have to deal with every Byzantine
> software case in order to publish an IETF spec, then I think that we
> need to start attending ITU meetings because that is where people
> who actually want to build networks are going to go. (I am already
> aware of some cases of router vendors seriously considering taking
> specs to the ITU because getting them through the IETF is too
> onerous -- I don't think that this is a good thing).
>
> Now, if someone wants a statement in this document, or in any or
> all protocol specs, that says some form of: "If a vicious and clever
> hacker gets to re-write or significantly modify the software that runs
> on the routers, then this protocol will not work, and is subject to
> mis-behavior in ways that are difficult or impossible to fully predict"
> then I am okay with this, since the trust model that we are working
> under is one where the peer routers have software which is intending
> to do the right thing.
>
> Ross
>
> At 01:44 PM 1/29/2007 -0500, Sandy Murphy wrote:
>> > Adrian, you have reply-to set to you, so this is going to you only.  If
>> > that
>> > is not what you wanted and you want the other recipients to see the
>> > message,
>> > let me know and I will resend.
>>
>>Doesn't matter. Reply-all is always an acceptable option. Given that one 
>>of
>>your comments seems to be addressing other's not me, it might be good to
>>send it more widely.
>>
>> >>The email thread is presented in time order, oldest email first. I 
>> >>trust
>> >>that the originators of the emails will not feel that their 
>> >>conversations
>> >>are being put into the public domain egregiously.
>> >
>> > I managed to avoid insulting anyone in those messages, so I'm fine. 
>> > :-)
>> >
>> > My comments in line.  I hope I've managed to help indicate
>> > what you should do and why.
>>
>>Thanks.
>>
>> >> Thus there is a bidirectional full trust model between neighbors.
>> >>
>> >> Given that the trust model is full and bidirectional, this I-D cannot
>> >> modify the trust model.
>> >
>> > It should be said that a trust model is not only who you trust but
>> > what they are trusted to do.  So just saying that you trust the same
>> > people in either case is not sufficient; you must look at whether the
>> > actions are equivalent in each case.  Which, by the way, is what you
>> > address in the following, so you are on the right track.
>>
>>Clearly I need to read the security terminology RFC to get the difference
>>between trust (security) and allowed actions (policy). Can you point me at
>>it to save me having to search.
>>
>> >> Now, as I said, the damage you could do for any one LSP is subtly
>> >> different.
>> >> That is, during LSP setup, the maliscious LSR would have been limited 
>> >> to
>> >> doing damage as a recipient of a Path message and sender of a Resv. 
>> >> With
>> >> this I-D it is able to tell the upstream (restarting) LSR that the 
>> >> Path
>> >> message it sent previously was different from the one it actually 
>> >> sent.
>> >> What new damage could this do?
>> >>
>> >> It doesn't change any of the behavior at any downstream LSR because 
>> >> the
>> >> malicious LSR could already have lied in the Path message that it sent
>> >> downstream.
>> >>
>> >> It doesn't change anything at the malicious LSR because that LSR is
>> >> always
>> >> free to be malicious in its own way.
>> >>
>> >> It doesn't change anything upstream of the restarting LSR because the
>> >> restart information is not propagated further upstream.
>> >
>> > The fact that restart info does not propagate does not mean that
>> > changes in behavior do not propagate.  [Hm: could soft-state refresh
>> > behavior to upstreams be affected by something in the bogus PATH
>> > info?]
>>
>>No. It assuredly could not.
>>Of course, a bogus Resv could do that, but we already have to admit that 
>>the
>>Resv might be bogus.
>>Or rather, we discount the possiblity of anyone subverting the running 
>>code
>>on a router.
>>
>> >> All it can do is tell the restarting LSR that the LSP parameters have
>> >> changed. So what?
>> >
>> > Your "So what?" rhetorical question deserves an answer.  Surely there
>> > would be no need for a new protocol if the restarting LSR was not
>> > going to do *something* with the info it receives.
>>
>>Well, read the draft :-)  It is going to:
>>- Check the information against the data plane in order to
>>   discard obsolete data plane state. Issues are:
>>   - Old data plane state will be falsely retained
>>      This is such a small issue that it is not very important,
>>      besides, how did the neighbor guess the existence of
>>      the state?
>>   - Old data plane state will be deleted in error. This is
>>      important because it interupts traffic. But, the neighbor
>>      could have done that itself.
>>      There is a tiny thing here that the neighbor can possibly
>>      cause the restarting node to appear to be at fault, but
>>      we can assume that the restarting node would log such
>>      events (and might not even tear state without management
>>      intervention).
>>- Use the information to generate its next Path message that
>>    it sends back to the downstream neighbor.
>>    Note that the utility of this function is that when the
>>    downstream neighbor restarts, it can get a refresh from its
>>    upstream neighbor.
>>    The consequence of a lie here is just a reminder to the lier
>>    of what its lie was.
>>
>> > Bogus info about
>> > the Path is going to produce some behavior different from the
>> > legitimate info, or we'd have no need to be exchanging that info
>> > anyway.  Just on that basis, an answer to "So what?" of "Nothing"
>> > should be viewed with scepticism, unless accompanied by some
>> > reasoning.  [The draft specifically points out the ability to recover
>> > the Explicit Route Object, which sure doesn't sound benign to the
>> > uninitiated.]
>> >
>> > Unfortunately, it looks like determining the way the behavior could be
>> > different and how much harm that could do would be a matter of
>> > reviewing 3209 and 3473 and understanding the use of many RSVP
>> > objects, not only the ERO but also those mentioned in "Such Path state
>> > may include (but is not restricted to) the Protection object, the
>> > Admin Status object, the Session Attribute object, the Notify Request
>> > object, the Sender Tspec object" and who know what all else.  In other
>> > words, would best be done by someone who knew such stuff.
>>
>>I have to say that the request "justify yourself" is hugely frustrating. I
>>know it is difficult to do this type of cross-area review because it is 
>>not
>>possible to be an expert in the details of every protocol. And it is 
>>really
>>useful to have issues raised like: have you considered what would happen 
>>if
>>XYZ? But at some point, there has to be an acceptance that, yes, the
>>protocol experts have though about this and they are comfortable.
>>
>>If we have to document the fact that such a situation would be benign for
>>every possible setting of every field in every protocol object currently
>>defined we will clearly produce several tens of pages of I-D. If this is
>>what is required then I think that we might as well give up on the idea of
>>publishing specifications.
>>
>> >>     Based on a security review by Derek Atkins and comments from Sandy
>> >>     Murphy,
>> >>...
>> >> I think that you need to see the security review by Derek and comments
>> >> by Sandy.
>> >
>> > Please note that my comments were not about this draft, but about a
>> > suggestion by Adrian that byzantine behavior by legitimate
>> > participants did not need to be considered.  I did not say that I
>> > thought that there WAS a problem.  Indeed, I had not read the draft
>> > and so had little reason think that there was a problem.
>>
>>Let me give an example. An ftp implementation is per spec in all respects
>>except that whenever you send "get foo" it returns the contents of the 
>>file
>>bar. It seems to me that there is nothing that the peer ftp implementation
>>can do within the scope of ftp to rectify or even detect this. Only the
>>application of other features (such as file encryption and file tagging) 
>>can
>>help and this is outside the scope of ftp.
>>
>>So with RSVP-TE. An application can do lots of things to verify that its 
>>LSP
>>is correctly connected and passing the right data unmollested, but that is
>>the job of the application not of the protocol.
>>
>> >>If anyone can contribute to this debate to make suggestions on how we
>> >>could
>> >>resolve this issue then that would be most welcome.
>> >
>> > Recommendation: Find someone to answer the "So what" question.  Find
>> > someone to verify the "not propagated further upstream" assertion wrt
>> > behavior.  Have them write their conclusion down, especially the "why"
>> > parts.
>>
>>Frankly, no-one will do this (although I seem to be being partially 
>>dragged
>>into it through email exchanges with Sam :-). It would cost too much 
>>money.
>>
>>If that means that the I-D is blocked from publication then maybe some
>>people will laugh at the IETF. But I don't suppose it will change much: 
>>this
>>stuff is implemented, deployed, and through various interop tests.
>>
>>Adrian
>
>
>
> 

Delivery-date: Tue, 30 Jan 2007 21:19:04 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Non-member submission from [[email-masked] (Derek Atkins)]
Date: Tue, 30 Jan 2007 21:17:52 -0000
Organization: Old Dog Consulting

----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 30, 2007 3:40 PM
Subject: Re: Security considerations with 
draft-ietf-ccamp-rsvp-restart-ext-07

> [snip]
>> Let me give an example. An ftp implementation is per spec in all respects
>> except that whenever you send "get foo" it returns the contents of the 
>> file
>> bar. It seems to me that there is nothing that the peer ftp 
>> implementation
>> can do within the scope of ftp to rectify or even detect this. Only the
>> application of other features (such as file encryption and file tagging) 
>> can
>> help and this is outside the scope of ftp.
>>
>> So with RSVP-TE. An application can do lots of things to verify that its 
>> LSP
>> is correctly connected and passing the right data unmollested, but that 
>> is
>> the job of the application not of the protocol.
>
> Ahh, but in the RSVP restart case, it's more like an FTP
> implementation does a "put foo" and then later a "get foo" and expects
> the remote implementation to return the same "foo" that it put there
> originally.  You're trusting the remote implementation to give you the
> same file that you uploaded earlier but you're not doing any kind of
> verification that that's indeed the case.
>
> All I'm suggesting is that the originator of the data have some way to
> self-verify that the foo it got is the same foo it put.  This could be
> done by a simple "self-signature" or MAC, something where I have some
> long term secret key (e.g. an AES key) and then upload the MAC with
> the original data; then when I get it I can re-verify the MAC and see
> that yes, this IS the data I uploaded.
>
> -derek
>
> -- 
>       Derek Atkins                 617-623-3745
>       [email-masked]             www.ihtfp.com
>       Computer and Internet Security Consultant
>
>
> 

Delivery-date: Tue, 30 Jan 2007 21:19:00 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Non-member submission from [[email-masked] (Sandy Murphy)]
Date: Tue, 30 Jan 2007 21:16:16 -0000
Organization: Old Dog Consulting

From: "Sandy Murphy" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, January 29, 2007 6:44 PM
Subject: Re: Security considerations with 
draft-ietf-ccamp-rsvp-restart-ext-07

>> Adrian, you have reply-to set to you, so this is going to you only.  If
>> that is not what you wanted and you want the other recipients to see the
>> message, let me know and I will resend.
>
> Doesn't matter. Reply-all is always an acceptable option. Given that one 
> of
> your comments seems to be addressing other's not me, it might be good to
> send it more widely.
>
>>>The email thread is presented in time order, oldest email first. I trust
>>>that the originators of the emails will not feel that their conversations
>>>are being put into the public domain egregiously.
>>
>> I managed to avoid insulting anyone in those messages, so I'm fine.  :-)
>>
>> My comments in line.  I hope I've managed to help indicate
>> what you should do and why.
>
> Thanks.
>
>>> Thus there is a bidirectional full trust model between neighbors.
>>>
>>> Given that the trust model is full and bidirectional, this I-D cannot
>>> modify the trust model.
>>
>> It should be said that a trust model is not only who you trust but
>> what they are trusted to do.  So just saying that you trust the same
>> people in either case is not sufficient; you must look at whether the
>> actions are equivalent in each case.  Which, by the way, is what you
>> address in the following, so you are on the right track.
>
> Clearly I need to read the security terminology RFC to get the difference
> between trust (security) and allowed actions (policy). Can you point me at
> it to save me having to search.
>
>>> Now, as I said, the damage you could do for any one LSP is subtly
>>> different.
>>> That is, during LSP setup, the maliscious LSR would have been limited to
>>> doing damage as a recipient of a Path message and sender of a Resv. With
>>> this I-D it is able to tell the upstream (restarting) LSR that the Path
>>> message it sent previously was different from the one it actually sent.
>>> What new damage could this do?
>>>
>>> It doesn't change any of the behavior at any downstream LSR because the
>>> malicious LSR could already have lied in the Path message that it sent
>>> downstream.
>>>
>>> It doesn't change anything at the malicious LSR because that LSR is
>>> always
>>> free to be malicious in its own way.
>>>
>>> It doesn't change anything upstream of the restarting LSR because the
>>> restart information is not propagated further upstream.
>>
>> The fact that restart info does not propagate does not mean that
>> changes in behavior do not propagate.  [Hm: could soft-state refresh
>> behavior to upstreams be affected by something in the bogus PATH
>> info?]
>
> No. It assuredly could not.
> Of course, a bogus Resv could do that, but we already have to admit that 
> the
> Resv might be bogus.
> Or rather, we discount the possiblity of anyone subverting the running 
> code
> on a router.
>
>>> All it can do is tell the restarting LSR that the LSP parameters have
>>> changed. So what?
>>
>> Your "So what?" rhetorical question deserves an answer.  Surely there
>> would be no need for a new protocol if the restarting LSR was not
>> going to do *something* with the info it receives.
>
> Well, read the draft :-)  It is going to:
> - Check the information against the data plane in order to
>  discard obsolete data plane state. Issues are:
>  - Old data plane state will be falsely retained
>     This is such a small issue that it is not very important,
>     besides, how did the neighbor guess the existence of
>     the state?
>  - Old data plane state will be deleted in error. This is
>     important because it interupts traffic. But, the neighbor
>     could have done that itself.
>     There is a tiny thing here that the neighbor can possibly
>     cause the restarting node to appear to be at fault, but
>     we can assume that the restarting node would log such
>     events (and might not even tear state without management
>     intervention).
> - Use the information to generate its next Path message that
>   it sends back to the downstream neighbor.
>   Note that the utility of this function is that when the
>   downstream neighbor restarts, it can get a refresh from its
>   upstream neighbor.
>   The consequence of a lie here is just a reminder to the lier
>   of what its lie was.
>
>> Bogus info about
>> the Path is going to produce some behavior different from the
>> legitimate info, or we'd have no need to be exchanging that info
>> anyway.  Just on that basis, an answer to "So what?" of "Nothing"
>> should be viewed with scepticism, unless accompanied by some
>> reasoning.  [The draft specifically points out the ability to recover
>> the Explicit Route Object, which sure doesn't sound benign to the
>> uninitiated.]
>>
>> Unfortunately, it looks like determining the way the behavior could be
>> different and how much harm that could do would be a matter of
>> reviewing 3209 and 3473 and understanding the use of many RSVP
>> objects, not only the ERO but also those mentioned in "Such Path state
>> may include (but is not restricted to) the Protection object, the
>> Admin Status object, the Session Attribute object, the Notify Request
>> object, the Sender Tspec object" and who know what all else.  In other
>> words, would best be done by someone who knew such stuff.
>
> I have to say that the request "justify yourself" is hugely frustrating. I
> know it is difficult to do this type of cross-area review because it is 
> not
> possible to be an expert in the details of every protocol. And it is 
> really
> useful to have issues raised like: have you considered what would happen 
> if
> XYZ? But at some point, there has to be an acceptance that, yes, the
> protocol experts have though about this and they are comfortable.
>
> If we have to document the fact that such a situation would be benign for
> every possible setting of every field in every protocol object currently
> defined we will clearly produce several tens of pages of I-D. If this is
> what is required then I think that we might as well give up on the idea of
> publishing specifications.
>
>>>     Based on a security review by Derek Atkins and comments from Sandy
>>>     Murphy,
>>>...
>>> I think that you need to see the security review by Derek and comments
>>> by Sandy.
>>
>> Please note that my comments were not about this draft, but about a
>> suggestion by Adrian that byzantine behavior by legitimate
>> participants did not need to be considered.  I did not say that I
>> thought that there WAS a problem.  Indeed, I had not read the draft
>> and so had little reason think that there was a problem.
>
> Let me give an example. An ftp implementation is per spec in all respects
> except that whenever you send "get foo" it returns the contents of the 
> file
> bar. It seems to me that there is nothing that the peer ftp implementation
> can do within the scope of ftp to rectify or even detect this. Only the
> application of other features (such as file encryption and file tagging) 
> can
> help and this is outside the scope of ftp.
>
> So with RSVP-TE. An application can do lots of things to verify that its 
> LSP
> is correctly connected and passing the right data unmollested, but that is
> the job of the application not of the protocol.
>
>>>If anyone can contribute to this debate to make suggestions on how we
>>>could
>>>resolve this issue then that would be most welcome.
>>
>> Recommendation: Find someone to answer the "So what" question.  Find
>> someone to verify the "not propagated further upstream" assertion wrt
>> behavior.  Have them write their conclusion down, especially the "why"
>> parts.
>
> Frankly, no-one will do this (although I seem to be being partially 
> dragged
> into it through email exchanges with Sam :-). It would cost too much 
> money.
>
> If that means that the I-D is blocked from publication then maybe some
> people will laugh at the IETF. But I don't suppose it will change much: 
> this
> stuff is implemented, deployed, and through various interop tests.
>
> Adrian
>
>
>
>
> 

Delivery-date: Tue, 30 Jan 2007 21:18:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Non-member submission from [[email-masked] (Sandy Murphy)]   
Date: Tue, 30 Jan 2007 21:14:30 -0000
Organization: Old Dog Consulting

> To: [email-masked]
> Subject: Re: Security considerations with 
> draft-ietf-ccamp-rsvp-restart-ext-07
> Cc: [email-masked], [email-masked], [email-masked],
>   [email-masked], [email-masked], [email-masked]
> In-Reply-To: <044201c740e3$06b30d60$f4849ed9@your029b8cecfe>
> Message-Id: <[email-masked]>
> Date: Mon, 29 Jan 2007 13:25:15 -0500 (EST)
> From: [email-masked] (Sandy Murphy)
>
> (I replied to Adrian directly because he had reply-to set to himself only,
> but he assures me that a reply-all is OK.  So here is my reply.  Then I'll
> send his response.)
>
> --Sandy
>
>>The email thread is presented in time order, oldest email first. I trust
>>that the originators of the emails will not feel that their conversations
>>are being put into the public domain egregiously.
>
> I managed to avoid insulting anyone in those messages, so I'm fine.  :-)
>
> My comments in line.  I hope I've managed to help indicate what you should
> do and why.
>
>> Thus there is a bidirectional full trust model between neighbors.
>>
>> Given that the trust model is full and bidirectional, this I-D cannot
>> modify
>> the trust model.
>>
>
> It should be said that a trust model is not only who you trust but
> what they are trusted to do.  So just saying that you trust the same
> people in either case is not sufficient; you must look at whether the
> actions are equivalent in each case.  Which, by the way, is what you
> address in the following, so you are on the right track.
>
>>
>> Now, as I said, the damage you could do for any one LSP is subtly
>> different.
>> That is, during LSP setup, the maliscious LSR would have been limited to
>> doing damage as a recipient of a Path message and sender of a Resv. With
>> this I-D it is able to tell the upstream (restarting) LSR that the Path
>> message it sent previously was different from the one it actually sent.
>> What
>> new damage could this do?
>>
>> It doesn't change any of the behavior at any downstream LSR because the
>> malicious LSR could already have lied in the Path message that it sent
>> downstream.
>>
>> It doesn't change anything at the malicious LSR because that LSR is 
>> always
>> free to be malicious in its own way.
>>
>> It doesn't change anything upstream of the restarting LSR because the
>> restart information is not propagated further upstream.
>
> The fact that restart info does not propagate does not mean that
> changes in behavior do not propagate.  [Hm: could soft-state refresh
> behavior to upstreams be affected by something in the bogus PATH
> info?]
>
>>
>> All it can do is tell the restarting LSR that the LSP parameters have
>> changed. So what?
>
> Your "So what?" rhetorical question deserves an answer.  Surely there
> would be no need for a new protocol if the restarting LSR was not
> going to do *something* with the info it receives.  Bogus info about
> the Path is going to produce some behavior different from the
> legitimate info, or we'd have no need to be exchanging that info
> anyway.  Just on that basis, an answer to "So what?" of "Nothing"
> should be viewed with scepticism, unless accompanied by some
> reasoning.  [The draft specifically points out the ability to recover
> the Explicit Route Object, which sure doesn't sound benign to the
> uninitiated.]
>
> Unfortunately, it looks like determining the way the behavior could be
> different and how much harm that could do would be a matter of
> reviewing 3209 and 3473 and understanding the use of many RSVP
> objects, not only the ERO but also those mentioned in "Such Path state
> may include (but is not restricted to) the Protection object, the
> Admin Status object, the Session Attribute object, the Notify Request
> object, the Sender Tspec object" and who know what all else.  In other
> words, would best be done by someone who knew such stuff.
>
>>     Based on a security review by Derek Atkins and comments from Sandy
>>     Murphy,
>>...
>> I think that you need to see the security review by Derek and comments
>> by Sandy.
>
> Please note that my comments were not about this draft, but about a
> suggestion by Adrian that byzantine behavior by legitimate
> participants did not need to be considered.  I did not say that I
> thought that there WAS a problem.  Indeed, I had not read the draft
> and so had little reason think that there was a problem.
>
>>If anyone can contribute to this debate to make suggestions on how we 
>>could
>>resolve this issue then that would be most welcome.
>
> Recommendation: Find someone to answer the "So what" question.  Find
> someone to verify the "not propagated further upstream" assertion wrt
> behavior.  Have them write their conclusion down, especially the "why"
> parts.
>
> --Sandy

Delivery-date: Mon, 29 Jan 2007 20:52:21 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-08.txt 
Date: Mon, 29 Jan 2007 15:50:02 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Extensions to GMPLS RSVP Graceful Restart
	Author(s)	: A. Satyanarayana, R. Rahman
	Filename	: draft-ietf-ccamp-rsvp-restart-ext-08.txt
	Pages		: 24
	Date		: 2007-1-29
	
This document describes extensions to the RSVP Graceful Restart
   mechanisms defined in RFC 3473.  The extensions enable the recovery
   of RSVP signaling state based on the Path message last sent by the
   node being restarted.

   Previously defined Graceful Restart mechanisms, also called recovery
   from nodal faults, permit recovery of signaling state from adjacent
   nodes when the data plane has retained the associated forwarding
   state across a restart.  Those mechanisms do not fully support
   signaling state recovery on ingress nodes or recovery of all RSVP
   objects.

   The extensions defined in this document build on the RSVP Hello
   extensions defined in RFC 3209, and extensions for state recovery on
   nodal faults defined in RFC 3473.  Using these extensions the
   restarting node can recover all previously transmitted Path state
   including the Explicit Route Object and the downstream (outgoing)
   interface identifiers.  The extensions can also be used to recover
   signaling state after the restart of an ingress node.

   The extensions optionally support the use of Summary Refresh, defined
   in RFC 2961, to reduce the number of messages exchanged during the
   Recovery Phase when the restarting node has recovered signaling state
   locally for one or more LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-restart-ext-08.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-08.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Sat, 27 Jan 2007 07:04:07 +0000
Date: Sat, 27 Jan 2007 15:00:49 +0800
From: ZhangRenhai <[email-masked]>
Subject: Re: Advertising of inter-AS TE links
To: 'Adrian Farrel' <[email-masked]>, 'JP Vasseur' <[email-masked]>, 'Mach Chen' <[email-masked]>, 'Dimitri Papadimitriou' <[email-masked]>
Cc: [email-masked]

Hi, Adrian
I have submitted a draft last year in which the BGP extension to =
advertise
inter-as link connection information is described:
http://tools.ietf.org/wg/pce/draft-zhang-pce-locate-asbr-00.txt
I'm now drafting the problem statements and corresponding IGP(so far =
only
OSPF in the doc) extension, it's upcoming soon.

Regards,
Zhang Renhai

> Hi,
>=20
> Since this discussion is blossoming, it can have its own thread...
>=20
> I'd like to try to bring some focus.
>=20
> The motivation seems clear...
> When computing a path through one AS into another AS, the computation
point
> needs to know about TE links that connect to the next AS. This enables =
it
to
> select:
> - A TE link that connects to the next AS
> - A TE link that is suitable for the LSP.
>=20
> Other questions about reachability and TE connectivity across the next =
AS
> are out of scope and have been defined as problems that PCE is used to
> solve. This is an important point! We are not talking about =
distributing
> information to provide a graph to compute multi-AS TE paths. That is
(IMHO)
> out of scope and what PCE was invented to solve.
>=20
> I see two scenarios.
> 1. An ASBR has two links to the next AS.
> 2. An AS has two ASBRs to the next AS.
> In either case, the AS may have multiple ASBRs.
>=20
> The path computation point must determine:
> a. The set of ASBRs that connect to the next AS.
> b. Which ASBR to use.
> c. Which inter-AS link to use.
>=20
> Some cases are easy:
> - If the ERO already includes the ASBR address
>   no choice to be done
> - If the ASBR has multiple inter-AS links then
>   the choice can be a local matter (no
>   advertising required)
>=20
> But other cases require advertisement of the inter-AS link as a TE =
link
> with:
> - the normal TE information
> - an indication that this is an inter-AS link
> - the identity of the remote ASBR
> - the identity of the remote AS
>=20
> This information is needed through-out the local AS. That is, although =
all
> of the ASBRs may be interested for LSPs that entirely cross the local =
AS,
> and although a PCE could be a BGP speaker, the information is also =
needed
> for LSPs that are originated within the AS.
>=20
> Thus we must decide how paths for LSPs that exit the AS will be =
computed:
>=20
> - If we require computation by a PCE that
>   is (somewhat) centralised within the AS
>   we can use BGP to distribute the information
>   and require that the PCEs are BGP speakers.
>   (Note that the information is only needed
>   within the local AS, so we would limit its
>   flooding by BGP.)
>=20
> - If we require computation by any LSR in
>   the AS (i.e. PCE function is fully
>   distributed) then we require IGP flooding
>   of the information across the whole AS.
>=20
> In both cases the cost is not particularly high since the number of
inter-AS
> TE links will not be large.
>=20
> Thanks,
> Adrian
>=20
> ----- Original Message -----
> From: "ZhangRenhai" <[email-masked]>
> To: "'JP Vasseur'" <[email-masked]>; "'Mach Chen'" =
<[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, January 17, 2007 4:11 AM
> Subject: =B4=F0=B8=B4: Progressing the three inter-domain I-Ds
>=20
>=20
> >> > After reading these docs I also have the same concern with you
> >> > about inter-ASBR links flooding.
> >> > I think, in oder to perform  inter-AS path computation, =
inter-ASBR
> >> > links fooding is desired.
> >>
> >> As pointed out in the document, this is not a MUST, but an
optimization.
> >>
> >> > But
> >> > such kind of inter-ASBR link info should include more information
> >> > than "normal" TE links do,
> >> > e.g: the inter-ASBR links info SHOULD still include the peer AS
> >> > number and peer ASBR router id
> >> > besides those link info which has been specified in rfc3630 and
> >> > rfc3784.
> >>
> >> I don't think that the peer AS number info should be included in =
the
> >> IGP for sure. You should rely on BGP for that purpose.
> > [ZhangRenhai>] maybe BGP is not enough for some circumstance, take =
this
> > scenario for example:
> >
> >                     /  ASBR4
> > ASBR1--------ASBR2--
> >                    \  ASBR3
> > ------AS 1----------||-----AS 2----------
> >
> > ASBR2 in AS 1 would only advertise the optimal route received
respectively
> > from ASBR3 and ASBR4 (both are from AS 2) to ASBR1, ASBR1 also =
doesn't
> > have
> > the full knowledge of topology(such as which AS the ASBR2 is =
connected
to
> > and which router is in that AS)between the two AS. PCE would have =
the
> > similar problem when performing the brpc.
> > Another issue, when ASBR1 receives a path mesg from upstream domain
> > containing a loose ERO:AS number(say AS2), there should be a method =
for
it
> > to locate the asbr(say ASBR2) in the local domain connected to AS2.
> >
> > Regards,
> > Zhang Renhai
> >
> >>
> >> >
> >> > So I think there need a document to clarify and specify =
inter-ASBR
> >> > links flooding. we are considering to
> >> > write such a document. If someone interested in such work, we =
could
> >> > cooperate.
> >> JP.
>=20
>=20

Delivery-date: Fri, 26 Jan 2007 03:57:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "'Sam Hartman'" <[email-masked]>, "Derek Atkins" <[email-masked]>, "Sandy Murphy" <[email-masked]>
Subject: Security considerations with draft-ietf-ccamp-rsvp-restart-ext-07
Date: Fri, 26 Jan 2007 00:42:11 -0000
Organization: Old Dog Consulting

Hi,

As requested here is a summary of the email exchanges with regard to 
security issues in this I-D as raised in Security Directorate review and 
picked up on in IESG review by Sam Hartman.

The email thread is presented in time order, oldest email first. I trust 
that the originators of the emails will not feel that their conversations 
are being put into the public domain egregiously.

If anyone can contribute to this debate to make suggestions on how we could 
resolve this issue then that would be most welcome.

Thanks,
Adrian

====

From: "Derek Atkins" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, January 12, 2007 10:59 PM

>I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> I don't see any issues in this document beyond those already stated
> in the Security Considerations.
>
> My only question to the authors would be how does a recovering node
> verify that the data it gets from a peer node really came from the
> recovering node?  Right now it just seems to have to trust that the
> peer returns valid data.

===

From: "Adrian Farrel" <[email-masked]>
To: "Derek Atkins" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, January 13, 2007 11:39 AM

> Hi Derek,
>
> I think this is a good question so I am bringing it to the CCAMP list.
>
> The bottom line would appear to be:
> - The exchange between neighbors before restart was
>   secured by normal RSVP-TE means
> - The exchange after restart is secured by the same means.
> - This provides a degree of protection that the restarting
>   node is receiving information that it originally sent to
>   its neighbor.
>
> The obvious question is, should the restarting node have some (private) 
> way
> of authenticating that the information received on restart originated with
> it? This would presumably be some sort of cookie manufactured from a 
> mock-up
> of the restart message that the restarting node expects to receive and
> handed to the neighbor for use in the event of a restart.
>
> Seems like overkill to me, but I'd appreciate views from the WG.

===

From: "Derek Atkins" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 16, 2007 6:49 PM

> True, an attacker that sits between the peers shouldn't be able to
> inject messages because the endpoints are authenticated (and I
> presume that the transaction itself has integrity protection).
> You're correct that it is a question of the threat model, and that
> if you DO have a fully trusted set of peers then you don't have to
> worry about this attack.  But if that's the case I'd like to see
> a sentence or three in the Security Considerations section that
> explicitly states this threat model.  Then at least this attack
> would be clearly out of scope.  :)

===

From: "Adrian Farrel" <[email-masked]>
To: "Derek Atkins" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 16, 2007 7:36 PM

> OK
>
> We can write that sentence or three and close the issue.
>
> Thanks for engaging.

===

From: "Sandy Murphy" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, January 16, 2007 4:35 PM

>>This leaves us with only the mistake, and generally we don't make 
>>extensive
>>protocol changes to handle the potential for broken implementations.
>
> Yes, we will always have errors, in implementation, in configuration,
> in operation, we can't hope to protect against all of those, etc.
>
> However, it is prudent to spend some time analyzing how much damage to
> the protocol operation could result from a misconfigured or faulty
> participant.  This is important because there are also subverted
> and deliberately malicious participants to worry about.  You might be
> willing to live with the chance of a random one-in-a-billion error 
> bringing
> down your network, but subverted and malicious participants aren't random.

===

From: "Adrian Farrel" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>
Sent: Wednesday, January 17, 2007 12:16 AM

> Hi Sandy,
>
> Going off-list simply because it takes my emails a while to get approved 
> on
> the SecDir list.
>
> I agree with you completely. My question is now about how easy it is to
> subvert, for example, a router. Yes, it may be possible to hack a router 
> and
> induce odd configuration, but is it possible to subvert it? The nasty
> thought of someone writing their own version of IOS and downloading it 
> onto
> a router!
>
> This probably brings us to a wider concern than simply MPLS-TE. What 
> happens
> if any router running any routing protocol is subverted. Seems to me that 
> we
> don't have an answer to this question within the IETF.
>
> With one hat on I say: let's not hold up this I-D because of a much wider
> problem.
> With a different hat on I say: this is probably something that the SecDir
> and RtgDir might want to sit down and thrash out.

===

From: "Sandy Murphy" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 17, 2007 5:06 PM

>>I agree with you completely. My question is now about how easy it is to
>>subvert, for example, a router. Yes, it may be possible to hack a router
>>and induce odd configuration, but is it possible to subvert it?
>
> My definition of "subverted" includes hacking into a router and changing
> the configuration.  It is taken over and no longer obeying the
> instructions of its rightful owner, so I call it subverted.
>
>>This probably brings us to a wider concern than simply MPLS-TE. What
>>happens if any router running any routing protocol is subverted. Seems to
>>me that we don't have an answer to this question within the IETF.
>
> Yes, the whole Byzantine participants problem gets little attention -
> partly because it is really hard to address.
>
> A protocol robust against such failures can be much "heavier", but the
> approaches to adding Byzantine robustness are not generic - you don't
> just add a "Byzantine robustness" layer.
>
> But that is why I said that it would be prudent to analyze just how
> bad things can get if one participant (and for extra points, more than
> one participant) is faulty/misconfigured/subverted/malicious.
>
> Until we all get smarter about protocols, doing the worst cast scenario
> study at least lets you know where you have to apply administrative
> controls, monitoring and alarms, etc.

===

From: "Adrian Farrel" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>
Sent: Wednesday, January 17, 2007 8:00 PM

> OK, Thanks.
>
> I am going to feed this to the MPLS Security design team, and finger you
> (tee, hee, that will teach you ;-) as someone they can poll for a good
> discussion.

===

From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Brungard, Deborah A, ALABS" <[email-masked]>
Sent: Wednesday, January 17, 2007 9:14 PM
Subject: Re: New Version Notification - 
draft-ietf-ccamp-rsvp-restart-ext-07.txt

> Hi Ross,
>
> This new revisions handles some issues raised during SecDir review and
> copied to the CCAMP mailing list.
>
> The changes are:
> - Minor editorial clarification of the Abstract
> - Repagination
> - Insertion of a paragraph in Section 6
>   Note that the procedures assume a full trust model between RSVP
>   neighbors. That is, although the protocol exchanges before and after
>   restart can be secured, and although it is possible to authenticate
>   the identity of the neighbors, no mechanism is provided to verify
>   that the restart information is correctly mapped from the protocol
>   information exchanged before the restart. This is considered
>   acceptable because a similar trust model is required for normal
>   operation of the protocol.
> - Addition to the Acknowledgements section

===

From: "Sam Hartman" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 23, 2007 2:44 AM

>>>>>> "Sandy" == Sandy Murphy <[email-masked]> writes:
>
>    Sandy>    [email-masked], [email-masked], [email-masked],
>    Sandy> [email-masked], [email-masked]
>    >> This leaves us with only the mistake, and generally we don't
>    >> make extensive protocol changes to handle the potential for
>    >> broken implementations.
>
>    Sandy> Yes, we will always have errors, in implementation, in
>    Sandy> configuration, in operation, we can't hope to protect
>    Sandy> against all of those, etc.
>
>    Sandy> However, it is prudent to spend some time analyzing how
>    Sandy> much damage to the protocol operation could result from a
>
> I agree with Sandy here.  I think that analysis of what damage can be
> done by a malicious peer so that we can understand whether the
> proposed trust model is justified.

===

From: "Sam Hartman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 23, 2007 2:47 AM

> Discuss:
> Based on a security review by Derek Atkins and comments from Sandy
> Murphy, please help me understand why the trust model of this spec and
> normal operation of RSVP is the same. In particular, what damage can
> be done by a malicious peer sending back altered contents of path
> messages?  How could the same damage be done in the normal protocol?
>
> It may well be that writing text to cover these issues is too
> expensive.  If the authors would like to discuss with me offline that
> could work too.  Text is of course preferred if it is relatively easy
> to write because then the entire world can review our findings.

===

From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>; "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 23, 2007 10:49 AM

> Hi Sam,
>
> So the paragraph we included to help with Derek's comments is...
>
>   Note that the procedures assume a full trust model between RSVP
>   neighbors. That is, although the protocol exchanges before and after
>   restart can be secured, and although it is possible to authenticate
>   the identity of the neighbors, no mechanism is provided to verify
>   that the restart information is correctly mapped from the protocol
>   information exchanged before the restart. This is considered
>   acceptable because a similar trust model is required for normal
>   operation of the protocol.
>
> You can see this in the 07 revision.
>
> Simply put, the trust model between peers (once they are identified and
> authenticated) must be full for RSVP-TE. Otherwise there are many ways 
> that
> a malicious neighbor can really mess with its peer. For example, a 
> malicious
> upstream LSR could pretend that it had received an LSP setup request from
> somewhere further upstream and could send a Path message to its peer - 
> this
> could cause network resources to be squandered on all downstream LSRs.
>
> If you think about it, this hop-by-hop trust is necessary because 
> otherwise
> every network node must have a security relationship with every potential
> LSP ingress, and that cannot scale.
>
> Again, I would prefer not to use an RSVP-TE extensions draft to document
> normal RSVP-TE behavior, although I do understand that this behavior 
> *does*
> need to be documented. It is our hope that an effort recently started in 
> the
> MPLS working group to document MPLS security will cover all of these 
> bases,
> if somewhat belatedly.

===

From: "Sam Hartman" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 23, 2007 2:59 PM

>>>>>> "Adrian" == Adrian Farrel <[email-masked]> writes:
>
>    Adrian> Hi Sam, So the paragraph we included to help with Derek's
>    Adrian> comments is...
>
>    Adrian>   Note that the procedures assume a full trust model
>    Adrian> between RSVP neighbors. That is, although the protocol
>    Adrian> exchanges before and after restart can be secured, and
>    Adrian> although it is possible to authenticate the identity of
>    Adrian> the neighbors, no mechanism is provided to verify that the
>    Adrian> restart information is correctly mapped from the protocol
>    Adrian> information exchanged before the restart. This is
>    Adrian> considered acceptable because a similar trust model is
>    Adrian> required for normal operation of the protocol.
>
> This paragraph is the source of my discuss.
> It makes an assertion that the damage that could be caused by changing 
> state
> in a restart is the same as the damage that could be caused under normal
> operation.
> I'm asking you to validate that assertion so I can evaluate the document.
>
>    Adrian> You can see this in the 07 revision.
>
> Yes.
>
>    Adrian> Simply put, the trust model between peers (once they are
>    Adrian> identified and authenticated) must be full for
>    Adrian> RSVP-TE. Otherwise there are many ways that a malicious
>    Adrian> neighbor can really mess with its peer. For example, a
>    Adrian> malicious upstream LSR could pretend that it had received
>    Adrian> an LSP setup request from somewhere further upstream and
>    Adrian> could send a Path message to its peer - this could cause
>    Adrian> network resources to be squandered on all downstream LSRs.
>
> I agree that there needs to be some level of trust between peers in
> the current protocol.
>
>    Adrian> If you think about it, this hop-by-hop trust is necessary
>    Adrian> because otherwise every network node must have a security
>    Adrian> relationship with every potential LSP ingress, and that
>    Adrian> cannot scale.
>
> Mor like every network node must be able to have data origin
> authentication with every potential ingress, which is a much weaker
> statement.  But that's not a matter of discussion for today: we're not
> redesigning RSVP so we're not redesigning the hop-by-hop trust model.
> We're simply trying to validate that we have not changed it.
>
>    Adrian> Again, I would prefer not to use an RSVP-TE extensions
>    Adrian> draft to document normal RSVP-TE behavior, although I do
>    Adrian> understand that this behavior *does* need to be
>    Adrian> documented. It is our hope that an effort recently started
>    Adrian> in the MPLS working group to document MPLS security will
>    Adrian> cover all of these bases, if somewhat belatedly.
>
> As I said, my discuss can be resolved without text changes; I just
> need to be convinced of the answer to my question.  And again, I'm not
> asking you to document normal RSVP procedures only to show you have
> not changed them.

===

From: "Adrian Farrel" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 23, 2007 3:35 PM

> Hi Sam,
>
>>    Adrian>   Note that the procedures assume a full trust model
>>    Adrian> between RSVP neighbors. That is, although the protocol
>>    Adrian> exchanges before and after restart can be secured, and
>>    Adrian> although it is possible to authenticate the identity of
>>    Adrian> the neighbors, no mechanism is provided to verify that the
>>    Adrian> restart information is correctly mapped from the protocol
>>    Adrian> information exchanged before the restart. This is
>>    Adrian> considered acceptable because a similar trust model is
>>    Adrian> required for normal operation of the protocol.
>>
>> This paragraph is the source of my discuss.
>> It makes an assertion that the damage that could
>> be caused by changing state  in a restart is the same
>> as the damage that could be caused under normal
>> operation.
>
> No it doesn't.
> It says that the trust model is unchanged.
>
> In fact, the damage that could be done by a malicious router (not one with
> subverted configuration, but one with subverted software implementation) 
> is
> subtly different because of the different direction of the information
> exchange.
>
>> I'm asking you to validate that assertion so I can
>> evaluate the document.
>
> I can certainly validate the assertion made in the I-D.
>
> When an upstream neighbor sends a Path message, its downstream neighbor 
> acts
> on that message to establish state and cause downstream behavior that
> ultimately leads to resource allocations on the downstream negihbor and 
> the
> establishment of an LSP toward a specific destination. The downstream
> negihbor trusts that the upstream neighbor has passed it a genuine Path
> message for a real LSP.
>
> When an upstream neighbor sends a Path message to its downstream neighbor 
> it
> trusts that the downstream neighbor will not change the destination of the
> LSP, but will continue to forward the essential objects of the Path 
> message
> unchanged.
>
> When an upstream neighbor receives a Resv message from its downstream
> neighbor it trusts that message is a true reflection of the LSP that has
> been established downstream and contains accurate and true instructions on
> what the upstream neighbor should do.
>
> When a downstream neighbor sends a Resv message to its upstream neighbor 
> it
> trusts that the upstream negihbor will handle the message correctly and 
> will
> neither modify it gratuitously nor absorb it silently.
>
> And so on for all other RSVP-TE messages.
>
> Thus there is a bidirectional full trust model between neighbors.
>
> Given that the trust model is full and bidirectional, this I-D cannot 
> modify
> the trust model.
>
> Now, as I said, the damage you could do for any one LSP is subtly 
> different.
> That is, during LSP setup, the maliscious LSR would have been limited to
> doing damage as a recipient of a Path message and sender of a Resv. With
> this I-D it is able to tell the upstream (restarting) LSR that the Path
> message it sent previously was different from the one it actually sent. 
> What
> new damage could this do?
>
> It doesn't change any of the behavior at any downstream LSR because the
> malicious LSR could already have lied in the Path message that it sent
> downstream.
>
> It doesn't change anything at the malicious LSR because that LSR is always
> free to be malicious in its own way.
>
> It doesn't change anything upstream of the restarting LSR because the
> restart information is not propagated further upstream.
>
> All it can do is tell the restarting LSR that the LSP parameters have
> changed. So what?
>
> This might cause the LSP to be torn down with some kind of state mismatch
> between the existing data plane state (that survived the restart) and the
> control plane state reported from the malicious LSR. If the malicous LSR
> wanted to cause the LSP to be torn down, it could do it itself anyway (it 
> is
> on the path of the LSP). The state mismatch is likely to show up as a
> problem with restart so the malicious LSR will not be able to hide.
>
> So...
>
> Now change in trust model. No substantial change in the damage that can be
> done if the trust model is subverted.
>
>>    Adrian> Simply put, the trust model between peers (once they are
>>    Adrian> identified and authenticated) must be full for
>>    Adrian> RSVP-TE. Otherwise there are many ways that a malicious
>>    Adrian> neighbor can really mess with its peer. For example, a
>>    Adrian> malicious upstream LSR could pretend that it had received
>>    Adrian> an LSP setup request from somewhere further upstream and
>>    Adrian> could send a Path message to its peer - this could cause
>>    Adrian> network resources to be squandered on all downstream LSRs.
>>
>> I agree that there needs to be some level of trust between peers in
>> the current protocol.
>>
>>    Adrian> If you think about it, this hop-by-hop trust is necessary
>>    Adrian> because otherwise every network node must have a security
>>    Adrian> relationship with every potential LSP ingress, and that
>>    Adrian> cannot scale.
>>
>> More like every network node must be able to have data origin
>> authentication with every potential ingress, which is a much weaker
>> statement.
>
> Are you supposing that the signaling data cannot be modified hop-by-hop?
> Actually much of it can be changed, and some of it must be changed.
>
>> But that's not a matter of discussion for today: we're not
>> redesigning RSVP so we're not redesigning the hop-by-hop
>> trust model.
>> We're simply trying to validate that we have not changed it.
>
> Given that the trust model was full and bidirectional, the only direction
> for change would be to assume less trust. This I-D does not assume less
> trust.
>
>>    Adrian> Again, I would prefer not to use an RSVP-TE extensions
>>    Adrian> draft to document normal RSVP-TE behavior, although I do
>>    Adrian> understand that this behavior *does* need to be
>>    Adrian> documented. It is our hope that an effort recently started
>>    Adrian> in the MPLS working group to document MPLS security will
>>    Adrian> cover all of these bases, if somewhat belatedly.
>>
>> As I said, my discuss can be resolved without text changes; I just
>> need to be convinced of the answer to my question.  And again, I'm not
>> asking you to document normal RSVP procedures only to show you have
>> not changed them.
>
> Convinced yet?

===

From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 23, 2007 6:09 PM

> FYI, I am having an off-line discussion with Sam Hartman during IESG 
> review
> of this document (that has now advanced to 07) as he has raised a DISCUSS
> (you can see his issues in the I-D tracker).
>
> He is concerned that the extensions in this I-D change the trust model in
> RSVP-TE, and I am trying to convince him that there is already a
> bidirectional full trust model between neighbors without which basic 
> RSVP-TE
> signaling could not work. Thus (I say) this I-D does not change the 
> existing
> trust model although it reverses the flow of information for a specific 
> LSP.
>
> Further (I say) even a malicious LSR neighboring a restarting LSR could do
> very little more damage during restart than it could do during normal LSP
> processing.
>
> If anyone want to see the contents of this discussion, please shout.
>
> Adrian

===

From: "Ross Callon" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Thursday, January 25, 2007 8:44 PM

> The document "draft-ietf-ccamp-rsvp-restart-ext-07.txt" was discussed
> during the IESG telechat today. As you will see from the data tracker
> (let me know if you need a pointer to this), there are two DISCUSS
> votes that will need to be resolved in order for this document to
> progress.

[SNIP]

> The other DISCUSS by Sam Hartman states:
>
>     Based on a security review by Derek Atkins and comments from Sandy
>     Murphy, please help me understand why the trust model of this spec and
>     normal operation of RSVP is the same. In particular, what damage can
>     be done by a malicious peer sending back altered contents of path
>     messages? How could the same damage be done in the normal protocol?
>
>     It may well be that writing text to cover these issues is too
>     expensive. If the authors would like to discuss with me offline that
>     could work too. Text is of course preferred if it is relatively easy
>     to write because then the entire world can review our findings.
>
> I think that you need to see the security review by Derek and comments
> by Sandy. Also, resolving this is likely to require an email exchange with
> Sam. Let me know if you need any help resolving this.
>
> It was not clear whether Sam's discuss will result in significant 
> additional
> text for the document. If so, then you probably will want to add the other
> text as well and do a new version.
>
> Please let me know when you feel that you have these two issues
> resolved, or if you need additional help in resolving them.

Delivery-date: Wed, 24 Jan 2007 20:52:37 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-automesh-04.txt 
Date: Wed, 24 Jan 2007 15:50:02 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Routing extensions for discovery of 
                          Multiprotocol (MPLS) Label Switch Router 
                          (LSR) Traffic Engineering (TE) mesh membership
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-ccamp-automesh-04.txt
	Pages		: 16
	Date		: 2007-1-24
	
The set up of a full mesh of Multi-Protocol Label Switching (MPLS)
   Traffic Engineering (TE) Label Switched Paths (LSP) among a set of
   Label Switch Routers (LSR) is a common deployment scenario of MPLS
   Traffic Engineering either for bandwidth optimization, bandwidth
   guarantees or fast rerouting with MPLS Fast Reroute.  Such deployment
   may require the configuration of potentially a large number of TE
   LSPs (on the order of the square of the number LSRs).  This document
   specifies Interior Gateway Protocol (IGP) routing extensions for
   Intermediate System-to-Intermediate System (IS-IS) and Open Shortest
   Path First (OSPF) so as to provide an automatic discovery of the set
   of LSRs members of a mesh in order to automate the creation of such
   mesh of TE LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-automesh-04.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-automesh-04.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 23 Jan 2007 20:51:29 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt 
Date: Tue, 23 Jan 2007 15:50:02 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls
	Author(s)	: D. Papadimitriou, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt
	Pages		: 30
	Date		: 2007-1-23
	
In certain networking topologies, it may be advantageous to maintain
   associations between endpoints and key transit points to support an
   instance of a service. Such associations are known as Calls.

   A Call does not provide the actual connectivity for transmitting user
   traffic, but only builds a relationship by which subsequent
   Connections may be made. In Generalized MPLS (GMPLS) such Connections
   are known as Label Switched Paths (LSPs).

   This document specifies how GMPLS RSVP-TE signaling may be used and
   extended to support Calls. These mechanisms provide full and logical
   Call/Connection separation.

   The mechanisms proposed in this document are applicable to any
   environment (including multi-area), and for any type of interface:
   packet, layer-2, time-division multiplexed, lambda, or fiber
   switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rsvp-te-call-04.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 23 Jan 2007 19:28:15 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06
From: [email-masked]
Date: Tue, 23 Jan 2007 20:26:50 +0100

adrian - if this i-d has to be revisited wrt to the trust model
it implies there are a couple of other items that would fall in
to the same category

hence, the point is the following can we share that discussion
(i mean the off-line one) such as to assess the rationale and
arguments that led sam to this conclusion

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
23/01/2007 19:09
Please respond to "Adrian Farrel"
 
        To:     <[email-masked]>
        cc: 
        Subject:        Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06

FYI, I am having an off-line discussion with Sam Hartman during IESG 
review 
of this document (that has now advanced to 07) as he has raised a DISCUSS 
(you can see his issues in the I-D tracker).

He is concerned that the extensions in this I-D change the trust model in 
RSVP-TE, and I am trying to convince him that there is already a 
bidirectional full trust model between neighbors without which basic 
RSVP-TE 
signaling could not work. Thus (I say) this I-D does not change the 
existing 
trust model although it reverses the flow of information for a specific 
LSP.

Further (I say) even a malicious LSR neighboring a restarting LSR could do 

very little more damage during restart than it could do during normal LSP 
processing.

If anyone want to see the contents of this discussion, please shout.

Adrian

----- Original Message ----- 
From: "Sam Hartman" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 

<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 23, 2007 2:44 AM
Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06

>>>>>> "Sandy" == Sandy Murphy <[email-masked]> writes:
>
>    Sandy>    [email-masked], [email-masked], [email-masked],
>    Sandy> [email-masked], [email-masked]
>    >> This leaves us with only the mistake, and generally we don't
>    >> make extensive protocol changes to handle the potential for
>    >> broken implementations.
>
>    Sandy> Yes, we will always have errors, in implementation, in
>    Sandy> configuration, in operation, we can't hope to protect
>    Sandy> against all of those, etc.
>
>    Sandy> However, it is prudent to spend some time analyzing how
>    Sandy> much damage to the protocol operation could result from a
>
> I agree with Sandy here.  I think that analysis of what damage can be
> done by a malicious peer so that we can understand whether the
> proposed trust model is justified.
>
>
>
> 

Delivery-date: Tue, 23 Jan 2007 18:12:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06
Date: Tue, 23 Jan 2007 18:09:42 -0000
Organization: Old Dog Consulting

FYI, I am having an off-line discussion with Sam Hartman during IESG review 
of this document (that has now advanced to 07) as he has raised a DISCUSS 
(you can see his issues in the I-D tracker).

He is concerned that the extensions in this I-D change the trust model in 
RSVP-TE, and I am trying to convince him that there is already a 
bidirectional full trust model between neighbors without which basic RSVP-TE 
signaling could not work. Thus (I say) this I-D does not change the existing 
trust model although it reverses the flow of information for a specific LSP.

Further (I say) even a malicious LSR neighboring a restarting LSR could do 
very little more damage during restart than it could do during normal LSP 
processing.

If anyone want to see the contents of this discussion, please shout.

Adrian

----- Original Message ----- 
From: "Sam Hartman" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 23, 2007 2:44 AM
Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06

>>>>>> "Sandy" == Sandy Murphy <[email-masked]> writes:
>
>    Sandy>    [email-masked], [email-masked], [email-masked],
>    Sandy> [email-masked], [email-masked]
>    >> This leaves us with only the mistake, and generally we don't
>    >> make extensive protocol changes to handle the potential for
>    >> broken implementations.
>
>    Sandy> Yes, we will always have errors, in implementation, in
>    Sandy> configuration, in operation, we can't hope to protect
>    Sandy> against all of those, etc.
>
>    Sandy> However, it is prudent to spend some time analyzing how
>    Sandy> much damage to the protocol operation could result from a
>
> I agree with Sandy here.  I think that analysis of what damage can be
> done by a malicious peer so that we can understand whether the
> proposed trust model is justified.
>
>
>
> 

Delivery-date: Fri, 19 Jan 2007 22:39:27 +0000
Content-class: urn:content-classes:message
Subject: FW: Response liaison from ITU-T SG15 on CCAMP ASON work
Date: Fri, 19 Jan 2007 16:36:49 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>

Hi all,

This Liaison from ITU was unfortunately received just prior to our one
and only 2-day American holiday resulting in it's probable lost in the
queue. But we do have until Feb 12th to respond. Please send mail either
on the exploder or off to Adrian and me as we will be drafting a timely
response.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, November 21, 2006 5:57 AM
To: [email-masked]
Subject: Response liaison from ITU-T SG15 on CCAMP ASON work

Hi,

We have received a detailed response to our liaison on current
ASON-related=20
work within CCAMP.

The full liaison can be seen at http://www.olddog.co.uk/ccamp.htm

The bulk of the liaison is comments on=20
draft-ietf-ccamp-gmpls-ason-routing-ospf-02.txt and a discussion on the
use=20
of Calls and Connections in G.8080.

We are called on to respond by 12th February 2007.

Adrian=20

Delivery-date: Fri, 19 Jan 2007 16:38:04 +0000
Date: Fri, 19 Jan 2007 08:35:29 -0800
From: Greg Bernstein <[email-masked]>
To: Evelyne Roch <[email-masked]>
CC: Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: LCAS/VCAT

Hi Evelyne, sorry for the delay but Richard Rabbat had been taking the 
lead on this draft for most of last year.
See comments on your comments.

Regards

Greg B.

Evelyne Roch wrote:
> I read the draft and have the following comments:
>
> 1- The draft is missing support for creation and deletion of VCG with
> diversely routed signals without LCAS. This is because the procedure
> that is used to setup the components does not provide information about
> the VCAT layer, i.e. it is missing the total number of components that
> are part of the same VCG. 
Yes. Both ends need to agree on which components are to be used in the 
group at any given time. This requires extra signaling concerning
the structure of the VCAT group. There are a number of ways this could 
be done.
> In a liaison from ITU-T SG15, Q14/15
> https://datatracker.ietf.org/documents/LIAISON/file394.doc, the 2nd
> figure of Attachment 2 shows a multi-layer setup of an Ethernet call
> over VCAT/LCAS. Although the Ethernet layer is not relevant to the
> draft, it should be noted that a portion of the diagram includes an
> Aggregate NCC (Network Call Controller) that provides the missing
> functionality in the draft to provide the number of components that form
> the VCG. This is based on G.8080, in which the VCAT layer has its own
> controller. The functions performed by the Aggregate NCC are required
> whether or not LCAS is available. They allow both ends of the VCG to
> know the overall status of the VCG and the number of components it
> contains. It should also be noted that the call and connection states
> for each constituent must be kept separately from the state of the VCAT
> call.
>   
 From an implementation perspective an entity such as the mentioned 
Aggregate NCC that "manages the VCGs" is a given. I've got to manage the 
settings of that VCAT/LCAS chip at some point (and related logical 
entities).  Similarly for each cross connect involved.  I'm not up to 
date on all the call/connection state discussions so I won't comment (yet).
> 2- The draft is missing support for the creation of the various
> components in a separate phase than the creation of the VCAT group. In
> general, it should be possible to create, for example, several VC-4
> connections and to add them to a VCG at a later point to create, for
> example, a VC-4-4v. This can only be achieved if an Aggregate NCC
> exists.
>   
Here you are talking about (I think) a nifty application that we had in 
an earlier version of the draft. In this case, a number of pipes are set 
up between the endpoints far in advanced and could be shared between 
multiple VCAT groups. For example a number of GbE customers connect to 
an access box that supports VCAT on its line side and the pre-configured 
(setup) component signals would be allocated between the VCAT groups 
without additional signal setup and tear down across the network.  Is 
this of interest to folks? Is the saving of the call setup and tear down 
that significant?
> 3- I would prefer to use the call ID to correlate the diversely routed
> signals instead of the Association Object. In my opinion, the call id is
> a better choice because it is better aligned with the ASON architecture
> (G.8080).
>
> Regards,
> Evelyne Roch
> Metro Ethernet Networks, Nortel
> Phone: +1 613 763 6492 (esn 393-6492)
> e-mail: [email-masked]  
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Adrian Farrel
> Sent: Thursday, November 30, 2006 6:57 AM
> To: [email-masked]
> Subject: LCAS/VCAT
>
> Hi,
>
> In San Diego Richard presented the current status of
> draft-ietf-ccamp-gmpls-vcat-lcas-01.txt and suggested that the work is
> nearing completion.
>
> A quick show of hands indicated that very few had read the draft. This
> may be because it is a very narrow niche that only a few are interested
> in (i.e., all of the key people have read it), or may be because more
> people need to have a look.
>
> If you are interested in this work, could you please find some time
> relatively soon to have a look at the draft and send your comments to
> the list.
>
> If you have or are planning an implementation could you drop me a
> private
> (confidential!) email.
>
> Thanks,
> Adrian 
>
>
>
>
>
>
>   

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Thu, 18 Jan 2007 21:57:28 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-crankback-06.txt 
Date: Thu, 18 Jan 2007 21:55:50 -0000
Organization: Old Dog Consulting

Hi,

After a long hiatus I have got around to the IETF last call comments for 
this draft.

The changes are:

- New final paragraph in Section 4.1 to address comments raised
  by Ross.
- Rewrite of Section 9 (IANA) for clarity, but no change in content.
- Rewrite of Section 10 to handle comments from the SecDir review.

The changes to Section 10 are substantive, but I don't think they will cause 
anyone any issues.

Thanks,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 18, 2007 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-crankback-06.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 : Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
> Author(s) : A. Farrel, et al.
> Filename : draft-ietf-ccamp-crankback-06.txt
> Pages : 35
> Date : 2007-1-18
>
> In a distributed, constraint-based routing environment, the
>   information used to compute a path may be out of date. This means
>   that Multiprotocol Label Switching (MPLS) and Generalized MPLS
>   (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
>   requests may be blocked by links or nodes without sufficient
>   resources. Crankback is a scheme whereby setup failure information is
>   returned from the point of failure to allow new setup attempts to be
>   made avoiding the blocked resources. Crankback can also be applied to
>   LSP recovery to indicate the location of the failed link or node.
>
>   This document specifies crankback signaling extensions for use in
>   MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
>   RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in
>   "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
>   Functional Description", RFC3473. These extensions mean that the LSP
>   setup request can be retried on an alternate path that detours around
>   blocked links or nodes. This offers significant improvements in the
>   successful setup and recovery ratios for LSPs, especially in
>   situations where a large number of setup requests are triggered at
>   the same time.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-06.txt

Delivery-date: Thu, 18 Jan 2007 20:52:44 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-crankback-06.txt 
Date: Thu, 18 Jan 2007 15:50:01 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-crankback-06.txt
	Pages		: 35
	Date		: 2007-1-18
	
In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date. This means
   that Multiprotocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
   requests may be blocked by links or nodes without sufficient
   resources. Crankback is a scheme whereby setup failure information is
   returned from the point of failure to allow new setup attempts to be
   made avoiding the blocked resources. Crankback can also be applied to
   LSP recovery to indicate the location of the failed link or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
   RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in
   "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
   Functional Description", RFC3473. These extensions mean that the LSP
   setup request can be retried on an alternate path that detours around
   blocked links or nodes. This offers significant improvements in the
   successful setup and recovery ratios for LSPs, especially in
   situations where a large number of setup requests are triggered at
   the same time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-crankback-06.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-crankback-06.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 18 Jan 2007 04:24:30 +0000
Date: Thu, 18 Jan 2007 12:16:16 +0800
From: ZhangRenhai <[email-masked]>
Subject: =?gb2312?B?UmU6ILTwuLQ6IFByb2dyZXNzaW5nIHRoZSB0aHJlZSBpbnRlci1kb21haW4=?= =?gb2312?B?IEktRHM=?=
To: JP Vasseur <[email-masked]>
Cc: [email-masked], [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_9RNxoRGa7ySeo/SiTDJd1A)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi,

On Jan 16, 2007, at 11:11 PM, ZhangRenhai wrote:

After reading these docs I also have the same concern with you
about inter-ASBR links flooding.
I think, in oder to perform  inter-AS path computation, inter-ASBR
links fooding is desired.
As pointed out in the document, this is not a MUST, but an optimization. 
But
such kind of inter-ASBR link info should include more information
than "normal" TE links do,
e.g: the inter-ASBR links info SHOULD still include the peer AS
number and peer ASBR router id
besides those link info which has been specified in rfc3630 and
rfc3784.
I don't think that the peer AS number info should be included in the
IGP for sure. You should rely on BGP for that purpose.
[ZhangRenhai>] maybe BGP is not enough for some circumstance, take this 
scenario for example:

                     /  ASBR4
ASBR1--------ASBR2--
                    \  ASBR3
------AS 1----------||-----AS 2----------

ASBR2 in AS 1
In your example, both ASBR1 and ASBR2 are in AS1 ?[ZhangRenhai>]Yes. let me try to make the graph more clear.                     /  ASBR4
ASBR1--------ASBR2
                   \  ASBR3
|-----AS 1-----|        |-----AS 2----------

would only advertise the optimal route
 I guess that you're referring to the BGP route here.
[ZhangRenhai>]Yes, as you said above:"You should rely on BGP for that purpose". I think BGP would be suitable for PCE method if all ASBRs in a AS are connected to the PCE.  however, by per-domain, see below graph for example:                    /  ASBR4 [AS 3]
ASBR1--------ASBR2
                   \  ASBR3 [AS 2]
|-----AS 1-----|        
 if the ASBR3 and ASBR4 belong to different AS but send the same route to ASBR2, then ASBR2 would send only the optimal(through AS 2) one to ASBR1. When ASBR1 receives a path mesg with an ERO AS3, it will fail because ASBR1 has no this info.
received respectively
from ASBR3 and ASBR4 (both are from AS 2) to ASBR1, ASBR1 also doesn't have the full knowledge of topology(such as which AS the ASBR2 is connected to 
and which router is in that AS)between the two AS.

.... This is IP Inter-AS routing ... 
With the per-domain approach (inter-AS), 
BGP can of course be used, thus all necessary information for ASBR selection is available. 
[ZhangRenhai>]I'm not sure. 

PCE would have the
similar problem when performing the brpc.
Another issue, when ASBR1 receives a path mesg from upstream domain
containing a loose ERO:AS number(say AS2), there should be a method for it 
to locate the asbr(say ASBR2) in the local domain connected to AS2.

I don't see the scenario you're referring to ...[ZhangRenhai>]still the above graph, and the ero may be a sequence of AS number, for example, ...AS1, AS2... then the ASBR1 should know how to forword this path mesg to that domain, which ASBR in AS 1 should it forward, compute to. Zhang Renhai 
JP.

Regards,
Zhang Renhai

So I think there need a document to clarify and specify inter-ASBR
links flooding. we are considering to
write such a document. If someone interested in such work, we could
cooperate.

JP.

--Boundary_(ID_9RNxoRGa7ySeo/SiTDJd1A)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.3020" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff><PRE style="MARGIN: 0em">Hi,

On Jan 16, 2007, at 11:11 PM, ZhangRenhai wrote:

</PRE>
<BLOCKQUOTE 
style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid">
  <BLOCKQUOTE 
  style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid">
    <BLOCKQUOTE 
    style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid"><PRE style="MARGIN: 0em">After reading these docs I also have the same concern with you
about inter-ASBR links flooding.
I think, in oder to perform  inter-AS path computation, inter-ASBR
links fooding is desired.
</PRE></BLOCKQUOTE><PRE style="MARGIN: 0em"></PRE><TT>As pointed out in the document, this is 
    not a MUST, but an </TT><TT>optimization. </TT><PRE style="MARGIN: 0em"></PRE>
    <BLOCKQUOTE 
    style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid"><PRE style="MARGIN: 0em">But
such kind of inter-ASBR link info should include more information
than "normal" TE links do,
e.g: the inter-ASBR links info SHOULD still include the peer AS
number and peer ASBR router id
besides those link info which has been specified in rfc3630 and
rfc3784.
</PRE></BLOCKQUOTE><PRE style="MARGIN: 0em">I don't think that the peer AS number info should be included in the
IGP for sure. You should rely on BGP for that purpose.
</PRE></BLOCKQUOTE><TT>[ZhangRenhai&gt;] maybe BGP is not enough for some 
  circumstance, take </TT><TT>this </TT><PRE style="MARGIN: 0em">scenario for example:

                     /  ASBR4
ASBR1--------ASBR2--
                    \  ASBR3
------AS 1----------||-----AS 2----------

ASBR2 in AS 1
</PRE></BLOCKQUOTE><PRE style="MARGIN: 0em">In your example, both ASBR1 and ASBR2 are in AS1 ?</PRE><PRE style="MARGIN: 0em">[ZhangRenhai&gt;]Yes. let me try to make the graph more clear. </PRE><PRE style="MARGIN: 0em">&nbsp;</PRE><PRE style="MARGIN: 0em">                   /  ASBR4
ASBR1--------ASBR2
                   \  ASBR3
|-----AS 1-----|        |-----AS 2----------

</PRE>
<BLOCKQUOTE 
style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid"><PRE style="MARGIN: 0em">would only advertise the optimal route
</PRE></BLOCKQUOTE><PRE style="MARGIN: 0em">&nbsp;</PRE><PRE style="MARGIN: 0em">I guess that you're referring to the BGP route here.
</PRE><PRE style="MARGIN: 0em">[ZhangRenhai&gt;]Yes, as you said above:"You should rely on BGP for that purpose". I think BGP would be suitable for PCE method if all ASBRs in a AS are connected to the PCE. </PRE><PRE style="MARGIN: 0em">&nbsp;</PRE><PRE style="MARGIN: 0em">however, by per-domain, see below graph for example:</PRE><PRE style="MARGIN: 0em">&nbsp;</PRE><PRE style="MARGIN: 0em">                   /  ASBR4 [AS 3]
ASBR1--------ASBR2
                   \  ASBR3 [AS 2]
|-----AS 1-----|        
</PRE><PRE style="MARGIN: 0em"> if the ASBR3 and ASBR4 belong to different AS but send the same route to ASBR2, then ASBR2 would send only the optimal(through AS 2) one to ASBR1. When ASBR1 receives a path mesg with an ERO AS3, it will fail because ASBR1 has no this info.
</PRE>
<BLOCKQUOTE 
style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid"><PRE style="MARGIN: 0em">received respectively
</PRE><TT>from ASBR3 and ASBR4 (both are from AS 2) to ASBR1, ASBR1 also 
  </TT><TT>doesn't have </TT><TT>the full knowledge of topology(such as which AS 
  the ASBR2 is </TT><TT>connected to </TT><PRE style="MARGIN: 0em">and which router is in that AS)between the two AS.
</PRE></BLOCKQUOTE><PRE style="MARGIN: 0em"></PRE>
<DIV><TT></TT>&nbsp;</DIV>
<DIV><TT>.... This is IP Inter-AS routing ... </TT></DIV>
<DIV><TT>With the per-domain approach </TT><TT>(inter-AS), </TT></DIV>
<DIV><TT>BGP can of course be used, </TT><TT>thus all necessary information 
</TT><TT>for ASBR selection is available. </TT></DIV><FONT 
size=2>[ZhangRenhai&gt;]I'm not sure. </FONT>
<DIV><TT></TT>&nbsp;</DIV>
<DIV><TT></TT>&nbsp;</DIV><PRE style="MARGIN: 0em"></PRE>
<BLOCKQUOTE 
style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid"><PRE style="MARGIN: 0em">PCE would have the
similar problem when performing the brpc.
Another issue, when ASBR1 receives a path mesg from upstream domain
</PRE><TT>containing a loose ERO:AS number(say AS2), there should be a method 
  </TT><TT>for it </TT><PRE style="MARGIN: 0em">to locate the asbr(say ASBR2) in the local domain connected to AS2.

</PRE></BLOCKQUOTE><PRE style="MARGIN: 0em">I don't see the scenario you're referring to ...</PRE><PRE style="MARGIN: 0em"><FONT size=2>[ZhangRenhai&gt;]still the above graph, and the ero may be a sequence of AS number, for example, ...AS1, AS2... then the ASBR1 should know how to forword this path mesg to that domain, which ASBR in AS 1 should it forward, compute to.</FONT></PRE><PRE style="MARGIN: 0em"><FONT size=2></FONT>&nbsp;</PRE><PRE style="MARGIN: 0em"><FONT size=2>Zhang Renhai</FONT></PRE><PRE style="MARGIN: 0em"><FONT size=2></FONT>&nbsp;</PRE><PRE style="MARGIN: 0em"><FONT size=2></FONT>
JP.

</PRE>
<BLOCKQUOTE 
style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid"><PRE style="MARGIN: 0em">Regards,
Zhang Renhai

</PRE>
  <BLOCKQUOTE 
  style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid"><PRE style="MARGIN: 0em"></PRE>
    <BLOCKQUOTE 
    style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid"><PRE style="MARGIN: 0em">So I think there need a document to clarify and specify inter-ASBR
links flooding. we are considering to
write such a document. If someone interested in such work, we could
cooperate.

</PRE></BLOCKQUOTE><PRE style="MARGIN: 0em">JP.

</PRE>
    <BLOCKQUOTE 
    style="PADDING-LEFT: 0.85em; MARGIN: 0em; BORDER-LEFT: #5555ee 0.2em solid"><PRE style="MARGIN: 0em"></PRE></BLOCKQUOTE></BLOCKQUOTE><PRE style="MARGIN: 0em"></PRE></BLOCKQUOTE><PRE style="MARGIN: 0em"></PRE><!--X-Body-of-Message-End--><!--X-MsgBody-End--><!--X-Follow-Ups--></BODY></HTML>

--Boundary_(ID_9RNxoRGa7ySeo/SiTDJd1A)--

Delivery-date: Wed, 17 Jan 2007 21:41:30 +0000
To: Jaudelice Cavalcante de Oliveira <[email-masked]>
Cc: [email-masked], JP Vasseur <[email-masked]>, [email-masked], [email-masked], Ross Callon <[email-masked]>
Subject: Re: [mpls] Re: CCAMP Last call	on	draft-deoliveira-diff-te-preemption-06.txt
From: [email-masked]
Date: Wed, 17 Jan 2007 22:41:07 +0100

Hi -

let's then discuss the policy selection further - are these
not dependent on the objectives - rather than be selected / 
defined independently - ?

this question is fundamental to the understanding of the 
obtained results - i mean it may simply that with another
simple "policy" both would have result in the same outcome

i see here a potential discussion item for next f2f meeting -
do you agree ?

thanks,
- d. 

Jaudelice Cavalcante de Oliveira <[email-masked]>
15/01/2007 20:23
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], [email-masked], Ross Callon 
<[email-masked]>, [email-masked], JP Vasseur 
<[email-masked]>
        Subject:        Re: [mpls] Re: CCAMP Last call  on 
draft-deoliveira-diff-te-preemption-06.txt

Hi Dimitri,

On Jan 12, 2007, at 4:31 PM, [email-masked] 
wrote:

> hi -
>
> thanks for the reply - not sure you ever got the following response 
> back
>
> ----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 12/01/2007 
> 22:30
> -----
>         Dimitri PAPADIMITRIOU
>         07/01/2007 11:43
>                  To: Jaudelice Cavalcante de Oliveira
> <[email-masked]>
>
> Hi
>
> thanks for the answer - i am still looking at the reason
> why the PN selection process is driven by a uniform policy
> which looks like an arbitrary choice
>
> HBlock aims at minimizing the blocking probability
> PN aims at minimizing the system perturbation
>
> to have a fair analysis policy should be applied uniformly
> and non-uniformly to both cases
>

Both policies were applied in the same manner. The difference is in 
the selection of LSPs for preemption (largest or smallest). We chose 
to keep the policies simple.

I appreciate your feedback. I'd be happy to meet with you and discuss 
it further at the next IETF meeting as well.

Many thanks,

Jau.

> much thanks,
> - d.
>
> --
>
>
>
>
> Jaudelice Cavalcante de Oliveira <[email-masked]>
> 05/01/2007 00:11
>
>         To:     [email-masked]
>         cc:     [email-masked], JP Vasseur <[email-masked]>,
> [email-masked], Jaudelice Cavalcante de Oliveira
> <[email-masked]>, Ross Callon <[email-masked]>,
> [email-masked]
>         Subject:        [mpls] Re: CCAMP Last call on
> draft-deoliveira-diff-te-preemption-06.txt
>
>
> Hi Dimitri,
>
> Thank you for your comment.
>
> On Dec 18, 2006, at 3:47 AM, [email-masked]
> wrote:
>
>> adrian -
>>
>> in HBlock case the average wasted bw is a factor 10 smaller than
>> for any
>> other scheme (without significantly lowering the worst case, still an
>> order of 10)
>
> Indeed. This can be seen in table 2. In this case, selection of LSPs
> much larger than
> the required bandwidth did not occur often. The worst case value does
> not reflect the
> frequency with which a high bandwidth LSP was selected (which was
> very rarely in
> this case, therefore the low "wasted" bandwidth).
>
>> the only noticeable difference with PN is exactly that one (which is
>> induced by the possibility left to Hblock to have two selection
>> depending
>> on heavy vs normal loaded link) - hence it would be interesting to
>> know
>> the dependency on the min/max LSP bw and distribution (scenario
>> dependancy) and have a similar PN approach (non-uniform selection)
>
> Note that PN has the objective of preempting a small number of LSPs
> of the lowest
> priority (therefore ordering by decreasing bandwidth), while HBlock
> aims at minimizing
> the blocking probability, therefore selecting smaller LSPs which will
> be more likely to be
> rerouted once preempted. This is the main difference between the two
> policies: Given a set
> of LSPs with the same priority, PN picks the largest (in the interest
> of picking few) and HBlock
> picks smaller ones (even if more than one, in the interest of being
> able to reroute them easily).
>
> I hope this helps,
>
> Thanks,
>
> Jaudelice.
>
>>
>> thanks,
>> - d.
>>
>>
>>
>>
>>
>>
>> "Adrian Farrel" <[email-masked]>
>> Sent by: [email-masked]
>> 14/12/2006 18:02
>> Please respond to "Adrian Farrel"
>>
>>         To:     <[email-masked]>
>>         cc:     <[email-masked]>, "Ross Callon"
>> <[email-masked]>, "Brungard, Deborah A, ALABS"
>> <[email-masked]>,
>> <[email-masked]>
>>         Subject:        Re: CCAMP Last call on
>> draft-deoliveira-diff-te-preemption-06.txt
>>
>>
>> Hi,
>>
>> I have been explicitly asked to lengthen this last call so as to 
>> allow
>> time
>> for a review.
>>
>> Unusual, but not unreasonable.
>>
>> The last call is extended to noon on Sunday 17th December.
>>
>> Thanks,
>> Adrian
>> ----- Original Message -----
>> From: "Adrian Farrel" <[email-masked]>
>> To: <[email-masked]>
>> Cc: <[email-masked]>; "Ross Callon" <[email-masked]>;
>> "Brungard, Deborah A, ALABS" <[email-masked]>;
>> <[email-masked]>
>> Sent: Wednesday, November 29, 2006 11:06 AM
>> Subject: CCAMP Last call on draft-deoliveira-diff-te- 
>> preemption-06.txt
>>
>>
>>> Hi,
>>>
>>> This draft has been developed independently and has recently been
>> brought
>>> to the IESG for advancement as an individual submission to become an
>>> Informational RFC. I have done a first-level review and this latest
>>> revision includes updates to reflect my comments.
>>>
>>> Since the material here concerns preemption and the suggested 
>>> ways to
>>> operate an MPLS-TE or GMPLS network, we are running a quick last
>>> call on
>>
>>> the CCAMP mailing list to ensure that no-one has any objections.
>>>
>>> Please send your comments to the CCAMP list no later than noon 
>>> GMT on
>> 13th
>>> December 2006.
>>>
>>> Thanks,
>>> Adrian
>>> ----- Original Message -----
>>> From: <[email-masked]>
>>> To: <[email-masked]>
>>> Sent: Tuesday, November 28, 2006 8:50 PM
>>> Subject: I-D ACTION:draft-deoliveira-diff-te-preemption-06.txt
>>>
>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>
>>>>
>>>> Title : LSP Preemption Policies for MPLS Traffic Engineering
>>>> Author(s) : J. de Oliveira, et al.
>>>> Filename : draft-deoliveira-diff-te-preemption-06.txt
>>>> Pages : 19
>>>> Date : 2006-11-28
>>>>
>>>> When the establishment of a higher priority (Traffic Engineering
>>>>   Label Switched Path) TE LSP requires the preemption of a set of
>>>> lower
>>>>   priority TE LSPs, a node has to make a local decision to select
>>>> which
>>>>
>>>>   TE LSPs will be preempted.  The preempted LSPs are then
>>>> rerouted by
>>>>   their respective Head-end Label Switch Router (LSR).  This
>>>> document
>>>>   presents a flexible policy that can be used to achieve different
>>>>   objectives: preempt the lowest priority LSPs; preempt the minimum
>>>>   number of LSPs; preempt the set of TE LSPs that provide the
>>>> closest
>>>>   amount of bandwidth to the required bandwidth for the
>>>> preempting TE
>>>>   LSPs (to minimize bandwidth wastage); preempt the LSPs that
>>>> will have
>>>>   the maximum chance to get rerouted.  Simulation results are
>>>> given and
>>>>   a comparison among several different policies, with respect to
>>>>   preemption cascading, number of preempted LSPs, priority, wasted
>>>>   bandwidth and blocking probability is also included.
>>>>
>>>> A URL for this Internet-Draft is:
>>>>
>> http://www.ietf.org/internet-drafts/draft-deoliveira-diff-te-
>> preemption-06.txt
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

Delivery-date: Wed, 17 Jan 2007 21:36:29 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Re: New Version Notification - draft-ietf-ccamp-rsvp-restart-ext-07.txt 
Date: Wed, 17 Jan 2007 21:14:46 -0000
Organization: Old Dog Consulting

Hi Ross,

This new revisions handles some issues raised during SecDir review and 
copied to the CCAMP mailing list.

The changes are:
- Minor editorial clarification of the Abstract
- Repagination
- Insertion of a paragraph in Section 6
   Note that the procedures assume a full trust model between RSVP
   neighbors. That is, although the protocol exchanges before and after
   restart can be secured, and although it is possible to authenticate
   the identity of the neighbors, no mechanism is provided to verify
   that the restart information is correctly mapped from the protocol
   information exchanged before the restart. This is considered
   acceptable because a similar trust model is required for normal
   operation of the protocol.
- Addition to the Acknowledgements section

Thanks,
Adrian

----- Original Message ----- 
From: "ID Tracker" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 17, 2007 8:50 PM
Subject: New Version Notification - draft-ietf-ccamp-rsvp-restart-ext-07.txt

> New version (-07) has been submitted for 
> draft-ietf-ccamp-rsvp-restart-ext-07.txt.
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-07.txt
>
> IETF Secretariat.

Delivery-date: Wed, 17 Jan 2007 21:36:12 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Advertising of inter-AS TE links
From: [email-masked]
Date: Wed, 17 Jan 2007 22:35:02 +0100

Delivery-date: Wed, 17 Jan 2007 20:50:53 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-07.txt 
Date: Wed, 17 Jan 2007 15:50:01 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Extensions to GMPLS RSVP Graceful Restart
	Author(s)	: A. Satyanarayana, R. Rahman
	Filename	: draft-ietf-ccamp-rsvp-restart-ext-07.txt
	Pages		: 24
	Date		: 2007-1-17
	
This document describes extensions to the RSVP Graceful Restart
   mechanisms defined in RFC 3473.  The extensions enable the recovery
   of RSVP signaling state based on the Path message last sent by the
   node being restarted.

   Previously defined Graceful Restart mechanisms, also called recovery
   from nodal faults, permit recovery of signaling state from adjacent
   nodes when the data plane has retained the associated forwarding
   state across a restart.  Those mechanisms do not fully support
   signaling state recovery on ingress nodes or recovery of all RSVP
   objects.

   The extensions defined in this document build on the RSVP Hello
   extensions defined in RFC 3209, and extensions for state recovery on
   nodal faults defined in RFC 3473.  Using these extensions the
   restarting node can recover all previously transmitted Path state
   including the Explicit Route Object and the downstream (outgoing)
   interface identifiers.  The extensions can also be used to recover
   signaling state after the restart of an ingress node.

   The extensions optionally support the use of Summary Refresh, defined
   in RFC 2961, to reduce the number of messages exchanged during the
   Recovery Phase when the restarting node has recovered signaling state
   locally for one or more LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-restart-ext-07.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-07.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 17 Jan 2007 20:06:07 +0000
Content-class: urn:content-classes:message
Subject: March Meeting Reminders
Date: Wed, 17 Jan 2007 14:03:17 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>

CCAMP,

The agenda is posted. As we agreed at the last meeting, we will have two
sessions, they are scheduled for Monday morning and Tuesday afternoon:
https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=3D=

68

And don't forget to use the new Boilerplate on all draft submissions
(see mail below).

Deborah and Adrian

-----Original Message-----
From: IETF Secretariat [mailto:[email-masked]]=20
Sent: Monday, January 15, 2007 11:51 AM
To: IETF Announcement list
Cc: [email-masked]
Subject: Internet-Draft Boilerplate Reminder=20

This message is to remind you that as of February 1, 2007 the IETF
Secretariat will no longer accept Internet-Drafts with the old=20
(i.e. pre RFC 4748) boilerplate.  For your convenience, below is=20
the text of the message that was sent to the IETF Announcement=20
List by the IETF Chair on October 26, 2006 with Subject: Update to
Internet Draft and RFC Boilerplate.

The IETF Secretariat.
--------------------------------------------------------------
A small update to BCP 78 was recently approved by the IESG as RFC 4748,=20
to update the boilerplate (i.e., standard legal text) in RFCs and=20
Internet-Drafts to recognize the IETF Trust as a rights holder,=20
instead of ISOC.

The actual boilerplate changes are given below this message.

Starting as soon as reasonably possible, all authors of Internet-Drafts=20
are requested to use the new boilerplate. The RFC Editor will in any=20
case be inserting it in all RFCs issued from 2006-11-01. (The rights=20
held by ISOC in older RFCs will be administratively transferred to=20
the IETF Trust.)

The public ID Nits checker already accepts I-Ds with old or new
boilerplate. The Secretariat has started accepting I-Ds with old or=20
new boilerplate.

XML2RFC version 1.32 will generate the new boilerplate.
Users of I-D templates are requested to update them appropriately.

http://www.ietf.org/ID-Checklist.html and
http://www.ietf.org/ietf/1id-guidelines.html are being updated.

Starting December, the public ID Nits checker will issue warnings for
old
boilerplate.

Starting February 2007, the Secretariat will refuse the old boilerplate
in Internet-Drafts.

We are sorry for the inconvenience, but this change cannot be avoided.

    IETF Chair
    IETF Secretariat
    TOOLS Team

--------

Copyright Notice (required for all IETF Documents)

   (Normally placed at the end of the IETF Document.)

NOTE: by convention, the first line of the copyright statement is
usually
placed near the beginning of each document. This must also be updated.

OLD
      "Copyright (C) The Internet Society (year).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.

NEW
      "Copyright (C) The IETF Trust (year).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.

Disclaimer (required in all IETF Documents)

   (Normally placed at the end of the IETF Document after the copyright
   notice.)

OLD
      "This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
      PARTICULAR PURPOSE."

NEW
      "This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE=20
      IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
      WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
      FOR A PARTICULAR PURPOSE."

Exceptions

      In MIB modules, PIB modules and similar material commonly
      extracted from IETF Documents, except for material that is being
      placed under IANA maintenance, the following abbreviated notice
      shall be included in the body of the material that will be
      extracted in lieu of the notices otherwise required by Section 5:

OLD
         "Copyright (C) The Internet Society <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

NEW
         "Copyright (C) The IETF Trust <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

      When the MIB or PIB module is the initial version of a module that
      is to be maintained by the IANA, the following abbreviated notice
      shall be included:

OLD
         "Copyright (C) The Internet Society <year>.  The initial
         version of this MIB module was published in RFC XXXX; for full
         legal notices see the RFC itself.  Supplementary information
         may be available at:
         http://www.ietf.org/copyrights/ianamib.html."

NEW
         "Copyright (C) The IETF Trust <year>.  The initial
         version of this MIB module was published in RFC XXXX; for full
         legal notices see the RFC itself.  Supplementary information
         may be available at:
         http://www.ietf.org/copyrights/ianamib.html."

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

Delivery-date: Wed, 17 Jan 2007 12:15:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Advertising of inter-AS TE links
Date: Wed, 17 Jan 2007 12:15:07 -0000
Organization: Old Dog Consulting

Yes, Dimitri, I agree that the situation you describe is not solved by 
limited flooding of inter-AS TE links within only their adjacent ASes.

It is my view that this wider problem space has been delegate for resolution 
by PCE. That is, in order to fully resolve the problem by flooding of TE 
link information it would be necessary to also aggregate TE reachabilty 
across AS_2 and AS_3 in your example. Such aggregation is non-trivial given 
the number of TE parameters and the number of potential routes, and so we 
would have at least one of:
- excess information flooding
- excess aggregation processing
- valueless information flooding.
In the light of these options we (the Routing Area) decided to pursue PCE as 
a solution.

Adrian

----- Original Message ----- 
From: <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "'JP Vasseur'" <[email-masked]>; "'Mach Chen'" 
<[email-masked]>; <[email-masked]>; "ZhangRenhai" 
<[email-masked]>
Sent: Wednesday, January 17, 2007 11:26 AM
Subject: Re: Advertising of inter-AS TE links

> adrian
>
> agreed on the analysis - there is one additional case that
> needs to be addressed
>
> AS_1 is connected to AS_2 and AS_3 both connected to AS_4
>
> the ERO, includes AS_1 and AS_4, perfectly clear there is
> no intention to pass AS_2 - AS_4 and AS_3 - AS_4 TE link
> information to AS_1
>
> but what about AS_1 - AS_2 and AS_1 - AS_3 whose info. is
> defacto available
>
> the issue is one sentence, the initial linearization does
> not hold in the generic case of loose abstract AS's
>
> comments ?
>
> -d.
>
>
>
>
>
> "Adrian Farrel" <[email-masked]>
> Sent by: [email-masked]
> 17/01/2007 12:00
> Please respond to "Adrian Farrel"
>
>        To:     "ZhangRenhai" <[email-masked]>, "'JP Vasseur'"
> <[email-masked]>, "'Mach Chen'" <[email-masked]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     <[email-masked]>
>        Subject:        Advertising of inter-AS TE links
>
>
> Hi,
>
> Since this discussion is blossoming, it can have its own thread...
>
> I'd like to try to bring some focus.
>
> The motivation seems clear...
> When computing a path through one AS into another AS, the computation
> point
> needs to know about TE links that connect to the next AS. This enables it
> to
> select:
> - A TE link that connects to the next AS
> - A TE link that is suitable for the LSP.
>
> Other questions about reachability and TE connectivity across the next AS
> are out of scope and have been defined as problems that PCE is used to
> solve. This is an important point! We are not talking about distributing
> information to provide a graph to compute multi-AS TE paths. That is
> (IMHO)
> out of scope and what PCE was invented to solve.
>
> I see two scenarios.
> 1. An ASBR has two links to the next AS.
> 2. An AS has two ASBRs to the next AS.
> In either case, the AS may have multiple ASBRs.
>
> The path computation point must determine:
> a. The set of ASBRs that connect to the next AS.
> b. Which ASBR to use.
> c. Which inter-AS link to use.
>
> Some cases are easy:
> - If the ERO already includes the ASBR address
>  no choice to be done
> - If the ASBR has multiple inter-AS links then
>  the choice can be a local matter (no
>  advertising required)
>
> But other cases require advertisement of the inter-AS link as a TE link
> with:
> - the normal TE information
> - an indication that this is an inter-AS link
> - the identity of the remote ASBR
> - the identity of the remote AS
>
> This information is needed through-out the local AS. That is, although all
>
> of the ASBRs may be interested for LSPs that entirely cross the local AS,
> and although a PCE could be a BGP speaker, the information is also needed
> for LSPs that are originated within the AS.
>
> Thus we must decide how paths for LSPs that exit the AS will be computed:
>
> - If we require computation by a PCE that
>  is (somewhat) centralised within the AS
>  we can use BGP to distribute the information
>  and require that the PCEs are BGP speakers.
>  (Note that the information is only needed
>  within the local AS, so we would limit its
>  flooding by BGP.)
>
> - If we require computation by any LSR in
>  the AS (i.e. PCE function is fully
>  distributed) then we require IGP flooding
>  of the information across the whole AS.
>
> In both cases the cost is not particularly high since the number of
> inter-AS
> TE links will not be large.
>
> Thanks,
> Adrian
>
> ----- Original Message ----- 
> From: "ZhangRenhai" <[email-masked]>
> To: "'JP Vasseur'" <[email-masked]>; "'Mach Chen'" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, January 17, 2007 4:11 AM
> Subject: ´ð¸´: Progressing the three inter-domain I-Ds
>
>
>>> > After reading these docs I also have the same concern with you
>>> > about inter-ASBR links flooding.
>>> > I think, in oder to perform  inter-AS path computation, inter-ASBR
>>> > links fooding is desired.
>>>
>>> As pointed out in the document, this is not a MUST, but an
> optimization.
>>>
>>> > But
>>> > such kind of inter-ASBR link info should include more information
>>> > than "normal" TE links do,
>>> > e.g: the inter-ASBR links info SHOULD still include the peer AS
>>> > number and peer ASBR router id
>>> > besides those link info which has been specified in rfc3630 and
>>> > rfc3784.
>>>
>>> I don't think that the peer AS number info should be included in the
>>> IGP for sure. You should rely on BGP for that purpose.
>> [ZhangRenhai>] maybe BGP is not enough for some circumstance, take this
>> scenario for example:
>>
>>                     /  ASBR4
>> ASBR1--------ASBR2--
>>                    \  ASBR3
>> ------AS 1----------||-----AS 2----------
>>
>> ASBR2 in AS 1 would only advertise the optimal route received
> respectively
>> from ASBR3 and ASBR4 (both are from AS 2) to ASBR1, ASBR1 also doesn't
>> have
>> the full knowledge of topology(such as which AS the ASBR2 is connected
> to
>> and which router is in that AS)between the two AS. PCE would have the
>> similar problem when performing the brpc.
>> Another issue, when ASBR1 receives a path mesg from upstream domain
>> containing a loose ERO:AS number(say AS2), there should be a method for
> it
>> to locate the asbr(say ASBR2) in the local domain connected to AS2.
>>
>> Regards,
>> Zhang Renhai
>>
>>>
>>> >
>>> > So I think there need a document to clarify and specify inter-ASBR
>>> > links flooding. we are considering to
>>> > write such a document. If someone interested in such work, we could
>>> > cooperate.
>>> >
>>>
>>> JP.
>>>
>>> >
>>
>>
>>
>>
>>
>>
>
>
>
>
>
> 

Delivery-date: Wed, 17 Jan 2007 12:13:13 +0000
Cc: "'Mach Chen'" <[email-masked]>, [email-masked], [email-masked]
From: JP Vasseur <[email-masked]>
Subject: =?UTF-8?Q?Re:_=E7=AD=94=E5=A4=8D:_Progressing_the_three_inter-do?= =?UTF-8?Q?main_I-Ds?=
Date: Wed, 17 Jan 2007 07:12:13 -0500
To: ZhangRenhai <[email-masked]>

Hi,

On Jan 16, 2007, at 11:11 PM, ZhangRenhai wrote:

>>> After reading these docs I also have the same concern with you
>>> about inter-ASBR links flooding.
>>> I think, in oder to perform  inter-AS path computation, inter-ASBR
>>> links fooding is desired.
>>
>> As pointed out in the document, this is not a MUST, but an  
>> optimization.
>>
>>> But
>>> such kind of inter-ASBR link info should include more information
>>> than "normal" TE links do,
>>> e.g: the inter-ASBR links info SHOULD still include the peer AS
>>> number and peer ASBR router id
>>> besides those link info which has been specified in rfc3630 and
>>> rfc3784.
>>
>> I don't think that the peer AS number info should be included in the
>> IGP for sure. You should rely on BGP for that purpose.
> [ZhangRenhai>] maybe BGP is not enough for some circumstance, take  
> this
> scenario for example:
>
>                      /  ASBR4
> ASBR1--------ASBR2--
>                     \  ASBR3
> ------AS 1----------||-----AS 2----------
>
> ASBR2 in AS 1

In your example, both ASBR1 and ASBR2 are in AS1 ?

> would only advertise the optimal route

I guess that you're referring to the BGP route here.

> received respectively
> from ASBR3 and ASBR4 (both are from AS 2) to ASBR1, ASBR1 also  
> doesn't have
> the full knowledge of topology(such as which AS the ASBR2 is  
> connected to
> and which router is in that AS)between the two AS.

.... This is IP Inter-AS routing ... With the per-domain approach  
(inter-AS), BGP can of course be used, thus all necessary information  
for ASBR selection is available.

> PCE would have the
> similar problem when performing the brpc.
> Another issue, when ASBR1 receives a path mesg from upstream domain
> containing a loose ERO:AS number(say AS2), there should be a method  
> for it
> to locate the asbr(say ASBR2) in the local domain connected to AS2.
>

I don't see the scenario you're referring to ...

JP.

> Regards,
> Zhang Renhai
>
>>
>>>
>>> So I think there need a document to clarify and specify inter-ASBR
>>> links flooding. we are considering to
>>> write such a document. If someone interested in such work, we could
>>> cooperate.
>>>
>>
>> JP.
>>
>>>
>

Delivery-date: Wed, 17 Jan 2007 11:27:17 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], "'JP Vasseur'" <[email-masked]>, "'Mach Chen'" <[email-masked]>, [email-masked], "ZhangRenhai" <[email-masked]>
Subject: Re: Advertising of inter-AS TE links
From: [email-masked]
Date: Wed, 17 Jan 2007 12:26:41 +0100

Delivery-date: Wed, 17 Jan 2007 11:03:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "ZhangRenhai" <[email-masked]>, "'JP Vasseur'" <[email-masked]>, "'Mach Chen'" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Cc: <[email-masked]>
Subject: Advertising of inter-AS TE links
Date: Wed, 17 Jan 2007 11:00:53 -0000
Organization: Old Dog Consulting

Hi,

Since this discussion is blossoming, it can have its own thread...

I'd like to try to bring some focus.

The motivation seems clear...
When computing a path through one AS into another AS, the computation point 
needs to know about TE links that connect to the next AS. This enables it to 
select:
- A TE link that connects to the next AS
- A TE link that is suitable for the LSP.

Other questions about reachability and TE connectivity across the next AS 
are out of scope and have been defined as problems that PCE is used to 
solve. This is an important point! We are not talking about distributing 
information to provide a graph to compute multi-AS TE paths. That is (IMHO) 
out of scope and what PCE was invented to solve.

I see two scenarios.
1. An ASBR has two links to the next AS.
2. An AS has two ASBRs to the next AS.
In either case, the AS may have multiple ASBRs.

The path computation point must determine:
a. The set of ASBRs that connect to the next AS.
b. Which ASBR to use.
c. Which inter-AS link to use.

Some cases are easy:
- If the ERO already includes the ASBR address
  no choice to be done
- If the ASBR has multiple inter-AS links then
  the choice can be a local matter (no
  advertising required)

But other cases require advertisement of the inter-AS link as a TE link 
with:
- the normal TE information
- an indication that this is an inter-AS link
- the identity of the remote ASBR
- the identity of the remote AS

This information is needed through-out the local AS. That is, although all 
of the ASBRs may be interested for LSPs that entirely cross the local AS, 
and although a PCE could be a BGP speaker, the information is also needed 
for LSPs that are originated within the AS.

Thus we must decide how paths for LSPs that exit the AS will be computed:

- If we require computation by a PCE that
  is (somewhat) centralised within the AS
  we can use BGP to distribute the information
  and require that the PCEs are BGP speakers.
  (Note that the information is only needed
  within the local AS, so we would limit its
  flooding by BGP.)

- If we require computation by any LSR in
  the AS (i.e. PCE function is fully
  distributed) then we require IGP flooding
  of the information across the whole AS.

In both cases the cost is not particularly high since the number of inter-AS 
TE links will not be large.

Thanks,
Adrian

----- Original Message ----- 
From: "ZhangRenhai" <[email-masked]>
To: "'JP Vasseur'" <[email-masked]>; "'Mach Chen'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 17, 2007 4:11 AM
Subject: ´ð¸´: Progressing the three inter-domain I-Ds

>> > After reading these docs I also have the same concern with you
>> > about inter-ASBR links flooding.
>> > I think, in oder to perform  inter-AS path computation, inter-ASBR
>> > links fooding is desired.
>>
>> As pointed out in the document, this is not a MUST, but an optimization.
>>
>> > But
>> > such kind of inter-ASBR link info should include more information
>> > than "normal" TE links do,
>> > e.g: the inter-ASBR links info SHOULD still include the peer AS
>> > number and peer ASBR router id
>> > besides those link info which has been specified in rfc3630 and
>> > rfc3784.
>>
>> I don't think that the peer AS number info should be included in the
>> IGP for sure. You should rely on BGP for that purpose.
> [ZhangRenhai>] maybe BGP is not enough for some circumstance, take this
> scenario for example:
>
>                     /  ASBR4
> ASBR1--------ASBR2--
>                    \  ASBR3
> ------AS 1----------||-----AS 2----------
>
> ASBR2 in AS 1 would only advertise the optimal route received respectively
> from ASBR3 and ASBR4 (both are from AS 2) to ASBR1, ASBR1 also doesn't 
> have
> the full knowledge of topology(such as which AS the ASBR2 is connected to
> and which router is in that AS)between the two AS. PCE would have the
> similar problem when performing the brpc.
> Another issue, when ASBR1 receives a path mesg from upstream domain
> containing a loose ERO:AS number(say AS2), there should be a method for it
> to locate the asbr(say ASBR2) in the local domain connected to AS2.
>
> Regards,
> Zhang Renhai
>
>>
>> >
>> > So I think there need a document to clarify and specify inter-ASBR
>> > links flooding. we are considering to
>> > write such a document. If someone interested in such work, we could
>> > cooperate.
>> >
>>
>> JP.
>>
>> >
>
>
>
>
>
> 

Delivery-date: Wed, 17 Jan 2007 04:16:36 +0000
Date: Wed, 17 Jan 2007 12:11:19 +0800
From: ZhangRenhai <[email-masked]>
Subject: =?gb2312?B?tPC4tDogUHJvZ3Jlc3NpbmcgdGhlIHRocmVlIGludGVyLWRvbWFpbiBJLURz?=
To: 'JP Vasseur' <[email-masked]>, 'Mach Chen' <[email-masked]>
Cc: [email-masked], [email-masked]

> > After reading these docs I also have the same concern with you
> > about inter-ASBR links flooding.
> > I think, in oder to perform  inter-AS path computation, inter-ASBR
> > links fooding is desired.
> 
> As pointed out in the document, this is not a MUST, but an optimization.
> 
> > But
> > such kind of inter-ASBR link info should include more information
> > than "normal" TE links do,
> > e.g: the inter-ASBR links info SHOULD still include the peer AS
> > number and peer ASBR router id
> > besides those link info which has been specified in rfc3630 and
> > rfc3784.
> 
> I don't think that the peer AS number info should be included in the
> IGP for sure. You should rely on BGP for that purpose.
[ZhangRenhai>] maybe BGP is not enough for some circumstance, take this
scenario for example:
                    
                     /  ASBR4
ASBR1--------ASBR2--
                    \  ASBR3
------AS 1----------||-----AS 2----------

ASBR2 in AS 1 would only advertise the optimal route received respectively
from ASBR3 and ASBR4 (both are from AS 2) to ASBR1, ASBR1 also doesn't have
the full knowledge of topology(such as which AS the ASBR2 is connected to
and which router is in that AS)between the two AS. PCE would have the
similar problem when performing the brpc.
Another issue, when ASBR1 receives a path mesg from upstream domain
containing a loose ERO:AS number(say AS2), there should be a method for it
to locate the asbr(say ASBR2) in the local domain connected to AS2. 

Regards,
Zhang Renhai

>  
> >
> > So I think there need a document to clarify and specify inter-ASBR
> > links flooding. we are considering to
> > write such a document. If someone interested in such work, we could
> > cooperate.
> >
> 
> JP.
> 
> >

Delivery-date: Wed, 17 Jan 2007 00:45:48 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Progressing the three inter-domain I-Ds
From: [email-masked]
Date: Wed, 17 Jan 2007 01:45:11 +0100

hi adrian - see inline for a couple of clarifications

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
16/01/2007 15:11
Please respond to "Adrian Farrel"
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>
        Subject:        Re: Progressing the three inter-domain I-Ds

Hi Dimitri,

Thanks for your observations. We will fold them in with our review (unless 

the authors want to spin a new version first?)

You wrote:

> o) a couple of specific comments
>
>end of section 2:
>

Missing comment?

[dp] yes the following sentence

"the appropriate technique must be driven by the set of
   requirements for the paths attributes and the applicability to a
   particular technique with respect to the deployment scenario"

the beginning of the sentence is not recommending an approach, 
the "must" as indicated becomes authoritative, this sentence is
cyclic and reads 

"the appropriate technique must be driven by the applicability 
to a particular technique with respect to the deployment scenario"

is the term "path attribute" referring to any kind of LSP attr. ?
if yes please state so, if not please use the correct term ?

With regard to the discussion about advertising inter-AS TE links, you are 

right that this needs clarification. I also feel that this I-D is not the 
place to do it. *If* IGP advertisement of inter-AS TE links is supported, 
it 
will need documentation and this I-D can point to it.

[dp] i would agree that the reasoning throughout the draft is deductive
and the proposed method defined for MPLS-TE (how does this works for bi-
directional LSP for inst. when the inter-domain can be crossed by both
bi and unidirectional LSPs) is put in a path.comp context 

[dp] i mean here that beyond the specific per-domain operations the only
protocol addition is an OSPF one (i leave this question to whether needs
for a separate i-d is more appropriate, but the level of detail must be
the same in both cases, not because embedded in this i-d that accurate
description of processing shall be skipped)

Adrian 

Delivery-date: Wed, 17 Jan 2007 00:24:39 +0000
To: JP Vasseur <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Progressing the three inter-domain I-Ds
From: [email-masked]
Date: Wed, 17 Jan 2007 01:21:34 +0100

hi j-p - see inline:

JP Vasseur <[email-masked]>
Sent by: [email-masked]
16/01/2007 15:42
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, [email-masked], =

[email-masked]
        Subject:        Re: Progressing the three inter-domain I-Ds

Hi Dimitri,

On Jan 13, 2007, at 6:49 AM, [email-masked]=20
wrote:

> hi adrian
>
> o) a couple of generic comments on the third doc
>
> - the doc. states applicability to GMPLS but sometimes only ref.=20
> MPLS-TE
> signaling further on e.g. section 3.1
>
> " - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."
>
> and many others in section 4.
>

ok.

> - the are many comparison with PCE technique along the doc. - well=20
> that's
> fine but outside the scope of the document except if the purpose is to
> indicate how different techniques can be combined together and which
> interop issues may result from it
>

Because there are indeed two path computation techniques, it is=20
useful to keep these references in order to provide a fair=20
comparison. We could of course come up with a separate applicability=20
ID, but there are already quite a few related IDs, thus it is=20
preferable to keep the text here. I'll double check if there's any=20
redundancy though.

[dp] i don't think i found much statements clarifying potential
interop aspects - hence the question becomes rather simple=20

either there are prescriptive statements to be provided to ensure=20
interop and henceforth these are to be addressed in this document=20

or these are not prescriptive and hence an applicability document
would also do the job

otherwise there are no statements (interop is not resulting in any
specific behaviour) and then there is no need to perform any sort
of reference to the PCE technique

> o) a couple of specific comments
>
> end of section 2:
>
> section 3.1: "* The complete list of boundary LSRs along the path"
> -> list of domain identifier e.g. AS numbers also applies here ?
>
> last =A7 of section 3.1 is the most important one, signaling protocol=20
> are
> independent of the routing topology itself, i.e. not because a node is
> an ABR or an ASBR that comp. occurs but simply because he has no path
> to reach the next (loose) hop - an intermediate node should still=20
> maintain
> capacity to perform such operation
>
> section 3.3 "The path computation
>    technique described in this document applies to the case of a=20
> single
>    AS made of multiple IGP areas, multiples ASs made of a single IGP
>    areas or any combination of the above.  For the sake of simplicity,
>    each routing domain will be considered as single area in this
>    document. "
>
> -> not sure to understand the reasoning, at the end these examples=20
> must
> remain illustrative and not restrict applicability - all these=20
> tutorial
> like material should better go in an appendix -

Not sure why ?

[dp] e.g. the last sentence of the paragraph pointed here above shows
the issue - why this doc considers (from the examples it provides) and
or restricts routing domain (AS) composed by a single area ?

> section 3.1 "In any case,
>    no topology or resource information needs to be distributed between
>    domains (as mandated per [RFC4105] and [RFC4216]), which is=20
> critical
>    to preserve IGP/BGP scalability and confidentiality in the case=20
> of TE
>    LSPs spanning multiple routing domains."
>
> then Section 4
> "In terms of computation of an inter-AS TE LSP path, an interesting
>    optimization technique consists of allowing the ASBRs to flood=20
> the TE
>    information related to the inter-ASBR link(s) although no IGP TE is
>    enabled over those links (and so there is no IGP adjacency over the
>    inter-ASBR links).  ...
> "Thanks to such an optimization, the inter-ASBRs TE link information
>    corresponding to the links originated by the ASBR is made available
>    in the TED of other LSRs in the same domain that the ASBR=20
> belongs to."
>
> but after
> "Note that no topology
>    information is flooded and these links are not used in IGP SPF
>    computations.  Only the TE information for the outgoing links
>    directly connected to the ASBR is advertised."
>
> -> can one of the author clarify 1) is flooding involved or not ?

I'll be happy to clarify. The idea is to flood the TE info for the=20
Inter-AS link(s). Note that this does not contradict the requirements=20
of RFC4216:
(1) Confidentiality relates to the topology of another domain: the TE=20
information flooded in a domain is only augmented by Inter-AS links,=20
not to any link in another domain.
(2) Scalability: of course, flooding the TE info of a few Inter-AS=20
links will not compromise the scalability of the IGP.

> 2) what get's flooded and under which conditions 3) what is the
> scope of the flooding 4) how this mechanism positions against the
> requirements of 4105 and 4216

Did I clarify ? If so, I'll add a paragraph in the ID.

[dp] point 3, you flood the inter-AS information "inside the connected=20
AS" but what is the flooding scope ? - flooding of a link local info
inside the AS that is terminating that end of the link -

[dp] i think that the optimization provided here holds iff that info
is made available to the head-end area of that AS not only the tail-
end area

>
> o) a couple of edits
>
> section 1:
>
> ABR Router, ASBR Router - redundant R
>
> the most important def. is the "domain" def. which can be found in the
> frm doc but not recorded here this would clarify sentence like
>
> "The mechanisms proposed in this document are also applicable to MPLS
>  TE domains other than IGP areas and ASs."
>
> ref. H-LSP and S-LSP with the appropriate docs
>
> state that inter-domain recovery is going to be addressed in a set of
> specific docs

Thanks for the edits.

JP.

>
> hope this will help,
> - d.
>
>
>
>
> "Adrian Farrel" <[email-masked]>
> Sent by: [email-masked]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[email-masked]>
>         cc:
>         Subject:        Progressing the three inter-domain I-Ds
>
>
> Hi,
>
> We now have updated versions of the three inter-domain signaling I-Ds:
>
> - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
> - draft-ietf-ccamp-lsp-stitching-04.txt
> - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>
> Our plan is:
> 1. WG chairs do detailed review over the next couple of weeks
> 2. Editors apply necessary updates
> 3. We hold a WG last call for the three I-Ds together
>
> If you are interested in this work, I suggest that now might be a good
> time
> to remind yourself about the I-Ds, have a good read, and see if you=20
> can
> get
> any substantial comments in to coincide with the WG chairs' review.
>
> Thanks,
> Adrian
>
>
>
>

Delivery-date: Tue, 16 Jan 2007 19:40:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Derek Atkins" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06
Date: Tue, 16 Jan 2007 19:36:34 -0000
Organization: Old Dog Consulting

OK

We can write that sentence or three and close the issue.

Thanks for engaging.

Adrian
----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 16, 2007 6:49 PM
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06

> True, an attacker that sits between the peers shouldn't be able to
> inject messages because the endpoints are authenticated (and I
> presume that the transaction itself has integrity protection).
> You're correct that it is a question of the threat model, and that
> if you DO have a fully trusted set of peers then you don't have to
> worry about this attack.  But if that's the case I'd like to see
> a sentence or three in the Security Considerations section that
> explicitly states this threat model.  Then at least this attack
> would be clearly out of scope.  :)
>
> Thanks!
>
> -derek
>
> "Adrian Farrel" <[email-masked]> writes:
>
>> Hi Derek,
>>
>> Yes you have captured the exposure correctly.
>>
>> The question is: what is he trust model between neighbors? If the model 
>> is
>> high enough then the only way for a!=b is a mistake. If the trust model 
>> is
>> not high enough then a!=b could be malicious. If there is a security hole
>> *between* neighbors, b may be modified in transit such that a!=b.
>>
>> I think that in a cooperative singaling protocol we have to assume that
>> there is trust between neighbors once identities have been established.
>> RSVP-TE provides such identity confirmation and also secures the traffic
>> between neighbors.
>>
>> This leaves us with only the mistake, and generally we don't make 
>> extensive
>> protocol changes to handle the potential for broken implementations.
>>
>> Thanks,
>> Adrian
>>
>> ----- Original Message ----- 
>> From: "Derek Atkins" <[email-masked]>
>> To: "Adrian Farrel" <[email-masked]>
>> Cc: <[email-masked]>; <[email-masked]>;
>> <[email-masked]>; <[email-masked]>; <[email-masked]>;
>> <[email-masked]>; <[email-masked]>; 
>> <[email-masked]>;
>> <[email-masked]>; <[email-masked]>
>> Sent: Monday, January 15, 2007 2:56 PM
>> Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06
>>
>>
>>> Adrian,
>>>
>>> The fact that the exchange is secured only means that you've
>>> verified the endpoint, not the data.  For example, let's say
>>> that you and I are endpoints.  I send you "a" and then I restart.
>>> I ask for for my data, we secure the exchange (so I know that
>>> it's you I'm talking to), and then you send me "b".
>>>
>>> The RSVP-TE assures me that YOU sent me "b", but it doesn't
>>> assure me that "b" == "a", what I sent originally.
>>>
>>> Now, one way to solve this problem would be for the originating node
>>> to put their own MAC on their data with a private key known only to
>>> the originating node.  This way when you send me "b" it wouldn't
>>> have my own MAC on it (or the MAC would be invalid, or a timestamp
>>> would be too old).
>>>
>>> Maybe overkill, but if I'm trying to abuse resources I could use
>>> the restart method to backfill my requests.
>>>
>>> Thanks,
>>>
>>> -derek
>>>
>>> "Adrian Farrel" <[email-masked]> writes:
>>>
>>>> Hi Derek,
>>>>
>>>> I think this is a good question so I am bringing it to the CCAMP list.
>>>>
>>>> The bottom line would appear to be:
>>>> - The exchange between neighbors before restart was
>>>>   secured by normal RSVP-TE means
>>>> - The exchange after restart is secured by the same means.
>>>> - This provides a degree of protection that the restarting
>>>>   node is receiving information that it originally sent to
>>>>   its neighbor.
>>>>
>>>> The obvious question is, should the restarting node have some
>>>> (private) way
>>>> of authenticating that the information received on restart
>>>> originated with
>>>> it? This would presumably be some sort of cookie manufactured from
>>>> a mock-up
>>>> of the restart message that the restarting node expects to receive and
>>>> handed to the neighbor for use in the event of a restart.
>>>>
>>>> Seems like overkill to me, but I'd appreciate views from the WG.
>>>>
>>>> Adrian
>>>>
>>>> ----- Original Message ----- 
>>>> From: "Derek Atkins" <[email-masked]>
>>>> To: <[email-masked]>; <[email-masked]>
>>>> Cc: <[email-masked]>; <[email-masked]>;
>>>> <[email-masked]>; <[email-masked]>;
>>>> <[email-masked]>;
>>>> <[email-masked]>; <[email-masked]>
>>>> Sent: Friday, January 12, 2007 10:59 PM
>>>> Subject: draft-ietf-ccamp-rsvp-restart-ext-06
>>>>
>>>>
>>>>>I have reviewed this document as part of the security directorate's
>>>>> ongoing effort to review all IETF documents being processed by the
>>>>> IESG.  These comments were written primarily for the benefit of the
>>>>> security area directors.  Document editors and WG chairs should treat
>>>>> these comments just like any other last call comments.
>>>>>
>>>>> I don't see any issues in this document beyond those already stated
>>>>> in the Security Considerations.
>>>>>
>>>>> My only question to the authors would be how does a recovering node
>>>>> verify that the data it gets from a peer node really came from the
>>>>> recovering node?  Right now it just seems to have to trust that the
>>>>> peer returns valid data.
>>>>>
>>>>> -derek
>
> -- 
>       Derek Atkins                 617-623-3745
>       [email-masked]             www.ihtfp.com
>       Computer and Internet Security Consultant
>
>
> 

Delivery-date: Tue, 16 Jan 2007 14:54:14 +0000
Cc: Peng He <[email-masked]>, [email-masked], Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 09:53:37 -0500
To: Mach Chen <[email-masked]>

Hi Mach,

On Jan 15, 2007, at 11:16 PM, Mach Chen wrote:

> Hi Peng,
>
>> ----- Original Message -----
>> From: "Peng He" <[email-masked]>
>> To: "Mach Chen" <[email-masked]>
>> Cc: <[email-masked]>; "Adrian Farrel" =20
>> <[email-masked]>; <[email-masked]>; <owner-=20
>> [email-masked]>
>> Sent: Tuesday, January 16, 2007 11:17 AM
>> Subject: Re: Progressing the three inter-domain I-Ds
>
>
>> Hello Mach,
>
>> I understood that the path compute element(Head-end, ASBR, or PCE)
>> should  have the inter-ASBR links info to compute an optimal or
>> near-optimal inter-domain path.
>
>> You said "But I think the inter-ASBR link should have AS flooding
>> scope." What do you mean by "AS flooding scope"? Is it within an =20
>> AS or
>> among ASes? If within an AS, then that's the example shown in the
>> third document and mentioned in Dimitri's questions; if among ASes,
>> then how many ASes would be enough?
>
> I means it's just within an AS, and it's enough for those proposed
> path computation methods, e.g: Per-Domain, BRPC, etc.
>

So far, we're in sync, and this is what the ID points out. I'll =20
clarify this part to avoid confusion.

> If such inter-ASBR links are flooded among ASes, there would be =20
> scalabilty
> and confidentiality issues.

No (see my previous emails).

Thanks.

JP.

>
>> I just guess the contents of inter-AS link info to be flooded seems
>> easily to be decided (consider it as a special intra-AS TE link with
>> AS # attached), and might just need a simple document to define it;
>> the difficult thing is the flooding scope, which might be varied with
>> different path computing approaches or even the agreement among
>> operators.  Still seems to me hard to define a standard to rule it.
>> Or, leave every options open?
>
>
>
>> Regards,
>> Peng
>
> On 1/15/07, Mach Chen <[email-masked]> wrote:
>> Hi Peng,
>>
>> I means that no matter what kind of path computation methods(Per-=20
>> domain, BRPC, etc.) we adopt,
>> if we want to compute a path spaning mutiple ASes, the compute =20
>> element(Head-end, ASBR, or PCE)
>> SHOULD get the inter-ASBR links info.
>>
>> With respect to the flooding scope and specification of inter-ASBR =20=

>> links info,  we need more discussion.
>> But I think the inter-ASBR link should have AS flooding scope.
>>
>> ----- Original Message -----
>> From: "Peng He" <[email-masked]>
>> To: "Mach Chen" <[email-masked]>
>> Cc: <[email-masked]>; "Adrian Farrel" =20
>> <[email-masked]>; <[email-masked]>; <owner-=20
>> [email-masked]>
>> Sent: Monday, January 15, 2007 11:26 AM
>> Subject: Re: Progressing the three inter-domain I-Ds
>>
>>
>> Hello Mach,
>>
>> I am interested in such work. But I am not sure what you said "in =20
>> oder
>> to perform  inter-AS path computation, inter-ASBR links fooding is
>> desired", say, different computing methods might need different
>> information about the inter-AS links and various flood ranges, and if
>> not a general method is considered as default, it seems to me hard to
>> define what exact info should be flooded. Just my personal thoughts.
>>
>> Regards,
>> Peng
>>
>> On 1/14/07, Mach Chen <[email-masked]> wrote:
>>> Dimitri and all,
>>>
>>> After reading these docs I also have the same concern with you =20
>>> about inter-ASBR links flooding.
>>> I think, in oder to perform  inter-AS path computation, inter-=20
>>> ASBR links fooding is desired. But
>>> such kind of inter-ASBR link info should include more information =20=

>>> than "normal" TE links do,
>>> e.g: the inter-ASBR links info SHOULD still include the peer AS =20
>>> number and peer ASBR router id
>>> besides those link info which has been specified in rfc3630 and =20
>>> rfc3784.
>>>
>>> So I think there need a document to clarify and specify inter-=20
>>> ASBR links flooding. we are considering to
>>> write such a document. If someone interested in such work, we =20
>>> could cooperate.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Mach
>>>
>>> ----- Original Message -----
>>> From: <[email-masked]>
>>> To: "Adrian Farrel" <[email-masked]>
>>> Cc: <[email-masked]>; <[email-masked]>
>>> Sent: Saturday, January 13, 2007 7:49 PM
>>> Subject: Re: Progressing the three inter-domain I-Ds
>>>
>>>
>>> hi adrian
>>>
>>> o) a couple of generic comments on the third doc
>>>
>>> - the doc. states applicability to GMPLS but sometimes only ref. =20
>>> MPLS-TE
>>> signaling further on e.g. section 3.1
>>>
>>> " - The inter-domain TE LSPs are signaled using RSVP-TE =20
>>> ([RFC3209])."
>>>
>>> and many others in section 4.
>>>
>>> - the are many comparison with PCE technique along the doc. - =20
>>> well that's
>>> fine but outside the scope of the document except if the purpose =20
>>> is to
>>> indicate how different techniques can be combined together and which
>>> interop issues may result from it
>>>
>>> o) a couple of specific comments
>>>
>>> end of section 2:
>>>
>>> section 3.1: "* The complete list of boundary LSRs along the path"
>>> -> list of domain identifier e.g. AS numbers also applies here ?
>>>
>>> last =A7 of section 3.1 is the most important one, signaling =20
>>> protocol are
>>> independent of the routing topology itself, i.e. not because a =20
>>> node is
>>> an ABR or an ASBR that comp. occurs but simply because he has no =20
>>> path
>>> to reach the next (loose) hop - an intermediate node should still =20=

>>> maintain
>>> capacity to perform such operation
>>>
>>> section 3.3 "The path computation
>>>    technique described in this document applies to the case of a =20
>>> single
>>>    AS made of multiple IGP areas, multiples ASs made of a single IGP
>>>    areas or any combination of the above.  For the sake of =20
>>> simplicity,
>>>    each routing domain will be considered as single area in this
>>>    document. "
>>>
>>> -> not sure to understand the reasoning, at the end these =20
>>> examples must
>>> remain illustrative and not restrict applicability - all these =20
>>> tutorial
>>> like material should better go in an appendix -
>>>
>>> section 3.1 "In any case,
>>>    no topology or resource information needs to be distributed =20
>>> between
>>>    domains (as mandated per [RFC4105] and [RFC4216]), which is =20
>>> critical
>>>    to preserve IGP/BGP scalability and confidentiality in the =20
>>> case of TE
>>>    LSPs spanning multiple routing domains."
>>>
>>> then Section 4
>>> "In terms of computation of an inter-AS TE LSP path, an interesting
>>>    optimization technique consists of allowing the ASBRs to flood =20=

>>> the TE
>>>    information related to the inter-ASBR link(s) although no IGP =20
>>> TE is
>>>    enabled over those links (and so there is no IGP adjacency =20
>>> over the
>>>    inter-ASBR links).  ...
>>> "Thanks to such an optimization, the inter-ASBRs TE link information
>>>    corresponding to the links originated by the ASBR is made =20
>>> available
>>>    in the TED of other LSRs in the same domain that the ASBR =20
>>> belongs to."
>>>
>>> but after
>>> "Note that no topology
>>>    information is flooded and these links are not used in IGP SPF
>>>    computations.  Only the TE information for the outgoing links
>>>    directly connected to the ASBR is advertised."
>>>
>>> -> can one of the author clarify 1) is flooding involved or not ?
>>> 2) what get's flooded and under which conditions 3) what is the
>>> scope of the flooding 4) how this mechanism positions against the
>>> requirements of 4105 and 4216
>>>
>>>
>>> o) a couple of edits
>>>
>>> section 1:
>>>
>>> ABR Router, ASBR Router - redundant R
>>>
>>> the most important def. is the "domain" def. which can be found =20
>>> in the
>>> frm doc but not recorded here this would clarify sentence like
>>>
>>> "The mechanisms proposed in this document are also applicable to =20
>>> MPLS
>>>  TE domains other than IGP areas and ASs."
>>>
>>> ref. H-LSP and S-LSP with the appropriate docs
>>>
>>> state that inter-domain recovery is going to be addressed in a =20
>>> set of
>>> specific docs
>>>
>>> hope this will help,
>>> - d.
>>>
>>>
>>>
>>>
>>> "Adrian Farrel" <[email-masked]>
>>> Sent by: [email-masked]
>>> 09/01/2007 23:13
>>> Please respond to "Adrian Farrel"
>>>
>>>         To:     <[email-masked]>
>>>         cc:
>>>         Subject:        Progressing the three inter-domain I-Ds
>>>
>>>
>>> Hi,
>>>
>>> We now have updated versions of the three inter-domain signaling =20
>>> I-Ds:
>>>
>>> - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
>>> - draft-ietf-ccamp-lsp-stitching-04.txt
>>> - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>>>
>>> Our plan is:
>>> 1. WG chairs do detailed review over the next couple of weeks
>>> 2. Editors apply necessary updates
>>> 3. We hold a WG last call for the three I-Ds together
>>>
>>> If you are interested in this work, I suggest that now might be a =20=

>>> good
>>> time
>>> to remind yourself about the I-Ds, have a good read, and see if =20
>>> you can
>>> get
>>> any substantial comments in to coincide with the WG chairs' review.
>>>
>>> Thanks,
>>> Adrian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> Best regards,
>
> Mach
>

Delivery-date: Tue, 16 Jan 2007 14:50:54 +0000
Cc: [email-masked], Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 09:50:38 -0500
To: Mach Chen <[email-masked]>

Hi,

On Jan 14, 2007, at 9:41 PM, Mach Chen wrote:

> Dimitri and all,
>
> After reading these docs I also have the same concern with you =20
> about inter-ASBR links flooding.
> I think, in oder to perform  inter-AS path computation, inter-ASBR =20
> links fooding is desired.

As pointed out in the document, this is not a MUST, but an optimization.

> But
> such kind of inter-ASBR link info should include more information =20
> than "normal" TE links do,
> e.g: the inter-ASBR links info SHOULD still include the peer AS =20
> number and peer ASBR router id
> besides those link info which has been specified in rfc3630 and =20
> rfc3784.

I don't think that the peer AS number info should be included in the =20
IGP for sure. You should rely on BGP for that purpose.

>
> So I think there need a document to clarify and specify inter-ASBR =20
> links flooding. we are considering to
> write such a document. If someone interested in such work, we could =20=

> cooperate.

JP.

>
>
> Best regards,
>
> Mach
>
> ----- Original Message -----
> From: <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Saturday, January 13, 2007 7:49 PM
> Subject: Re: Progressing the three inter-domain I-Ds
>
>
> hi adrian
>
> o) a couple of generic comments on the third doc
>
> - the doc. states applicability to GMPLS but sometimes only ref. =20
> MPLS-TE
> signaling further on e.g. section 3.1
>
> " - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."
>
> and many others in section 4.
>
> - the are many comparison with PCE technique along the doc. - well =20
> that's
> fine but outside the scope of the document except if the purpose is to
> indicate how different techniques can be combined together and which
> interop issues may result from it
>
> o) a couple of specific comments
>
> end of section 2:
>
> section 3.1: "* The complete list of boundary LSRs along the path"
> -> list of domain identifier e.g. AS numbers also applies here ?
>
> last =A7 of section 3.1 is the most important one, signaling protocol =20=

> are
> independent of the routing topology itself, i.e. not because a node is
> an ABR or an ASBR that comp. occurs but simply because he has no path
> to reach the next (loose) hop - an intermediate node should still =20
> maintain
> capacity to perform such operation
>
> section 3.3 "The path computation
>    technique described in this document applies to the case of a =20
> single
>    AS made of multiple IGP areas, multiples ASs made of a single IGP
>    areas or any combination of the above.  For the sake of simplicity,
>    each routing domain will be considered as single area in this
>    document. "
>
> -> not sure to understand the reasoning, at the end these examples =20
> must
> remain illustrative and not restrict applicability - all these =20
> tutorial
> like material should better go in an appendix -
>
> section 3.1 "In any case,
>    no topology or resource information needs to be distributed between
>    domains (as mandated per [RFC4105] and [RFC4216]), which is =20
> critical
>    to preserve IGP/BGP scalability and confidentiality in the case =20
> of TE
>    LSPs spanning multiple routing domains."
>
> then Section 4
> "In terms of computation of an inter-AS TE LSP path, an interesting
>    optimization technique consists of allowing the ASBRs to flood =20
> the TE
>    information related to the inter-ASBR link(s) although no IGP TE is
>    enabled over those links (and so there is no IGP adjacency over the
>    inter-ASBR links).  ...
> "Thanks to such an optimization, the inter-ASBRs TE link information
>    corresponding to the links originated by the ASBR is made available
>    in the TED of other LSRs in the same domain that the ASBR =20
> belongs to."
>
> but after
> "Note that no topology
>    information is flooded and these links are not used in IGP SPF
>    computations.  Only the TE information for the outgoing links
>    directly connected to the ASBR is advertised."
>
> -> can one of the author clarify 1) is flooding involved or not ?
> 2) what get's flooded and under which conditions 3) what is the
> scope of the flooding 4) how this mechanism positions against the
> requirements of 4105 and 4216
>
>
> o) a couple of edits
>
> section 1:
>
> ABR Router, ASBR Router - redundant R
>
> the most important def. is the "domain" def. which can be found in the
> frm doc but not recorded here this would clarify sentence like
>
> "The mechanisms proposed in this document are also applicable to MPLS
>  TE domains other than IGP areas and ASs."
>
> ref. H-LSP and S-LSP with the appropriate docs
>
> state that inter-domain recovery is going to be addressed in a set of
> specific docs
>
> hope this will help,
> - d.
>
>
>
>
> "Adrian Farrel" <[email-masked]>
> Sent by: [email-masked]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[email-masked]>
>         cc:
>         Subject:        Progressing the three inter-domain I-Ds
>
>
> Hi,
>
> We now have updated versions of the three inter-domain signaling I-Ds:
>
> - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
> - draft-ietf-ccamp-lsp-stitching-04.txt
> - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>
> Our plan is:
> 1. WG chairs do detailed review over the next couple of weeks
> 2. Editors apply necessary updates
> 3. We hold a WG last call for the three I-Ds together
>
> If you are interested in this work, I suggest that now might be a good
> time
> to remind yourself about the I-Ds, have a good read, and see if you =20=

> can
> get
> any substantial comments in to coincide with the WG chairs' review.
>
> Thanks,
> Adrian
>
>
>
>
>
>

Delivery-date: Tue, 16 Jan 2007 14:48:42 +0000
Cc: "[email-masked]" <[email-masked]>, "Adrian Farrel" <[email-masked]>, [email-masked], [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 09:48:24 -0500
To: Peng He <[email-masked]>

Hi Peng,

On Jan 13, 2007, at 9:55 AM, Peng He wrote:

> Hi,
>
> Sill about the the third doc:
>
> 1. in the "3.1.  Common assumptions" part, it is assumed that
> "Boundary LSRs are assumed to be capable of performing local path
> computation ..." . So I guess that ABR or ASBR has the function (or
> part of) of PCE.
>
> 2. My understanding to Dimitri's questions:
> I believe there is flooding here but only within the domain that the
> ASBR belongs to.

Right.

> So now a domain includes non-ABSR LSRs and ABSR LSRs
> and the links among them, AND the inter-domain links originating (not
> terminating) from the ASBRS of this domain. Tthe flooding is among
> these LSRs, but not between domains. So, it is still can be considered
> as intra-domain flooding and it happens when the TE info changes I
> guess.
>

This is right.

Example:

<---- AS 1 --->                    <--- AS 2 ---->
                     ASBR1----ASBR2

ASBR1 advertises in AS1 the links that belongs to AS1 + the ASBR1-=20
ASBR2 links.
Same thing for ASBR2.

> 3. The purpose of the above is to "improve the chance of successful
> signaling along the next AS in case of resource  shortage ..." I
> understand this, I just want to mention that it seems only true in
> theory and the practical effect is not so good as expected. I
> simulated this years ago when we extended DCR into inter-domain case
> and just no encouraging results found.

It of course depends of the assumptions that you used in your =20
simulations (topology, TMs, ...) but flooding that piece of data can =20
only improve the success rate of course. To what extent ? That =20
depends of a few parameters. For example, if your Inter-ASBR are over-=20=

provisioned, that won't help since the cause of CAC rejection is not =20
likely to be because of insufficient bandwidth on your links but =20
there are certainly cases where this can happen, in which case this =20
will help.

Thanks.

JP.

>
> Regards,
> Peng
>
>
>> 2) what get's flooded and under which conditions 3) what is the
>> scope of the flooding 4) how this mechanism positions against the
>> requirements of 4105 and 4216
>
>
>
> On 1/13/07, [email-masked]
> <[email-masked]> wrote:
>> hi adrian
>>
>> o) a couple of generic comments on the third doc
>>
>> - the doc. states applicability to GMPLS but sometimes only ref. =20
>> MPLS-TE
>> signaling further on e.g. section 3.1
>>
>> " - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."
>>
>> and many others in section 4.
>>
>> - the are many comparison with PCE technique along the doc. - well =20=

>> that's
>> fine but outside the scope of the document except if the purpose =20
>> is to
>> indicate how different techniques can be combined together and which
>> interop issues may result from it
>>
>> o) a couple of specific comments
>>
>> end of section 2:
>>
>> section 3.1: "* The complete list of boundary LSRs along the path"
>> -> list of domain identifier e.g. AS numbers also applies here ?
>>
>> last =A7 of section 3.1 is the most important one, signaling =20
>> protocol are
>> independent of the routing topology itself, i.e. not because a =20
>> node is
>> an ABR or an ASBR that comp. occurs but simply because he has no path
>> to reach the next (loose) hop - an intermediate node should still =20
>> maintain
>> capacity to perform such operation
>>
>> section 3.3 "The path computation
>>    technique described in this document applies to the case of a =20
>> single
>>    AS made of multiple IGP areas, multiples ASs made of a single IGP
>>    areas or any combination of the above.  For the sake of =20
>> simplicity,
>>    each routing domain will be considered as single area in this
>>    document. "
>>
>> -> not sure to understand the reasoning, at the end these examples =20=

>> must
>> remain illustrative and not restrict applicability - all these =20
>> tutorial
>> like material should better go in an appendix -
>>
>> section 3.1 "In any case,
>>    no topology or resource information needs to be distributed =20
>> between
>>    domains (as mandated per [RFC4105] and [RFC4216]), which is =20
>> critical
>>    to preserve IGP/BGP scalability and confidentiality in the case =20=

>> of TE
>>    LSPs spanning multiple routing domains."
>>
>> then Section 4
>> "In terms of computation of an inter-AS TE LSP path, an interesting
>>    optimization technique consists of allowing the ASBRs to flood =20
>> the TE
>>    information related to the inter-ASBR link(s) although no IGP =20
>> TE is
>>    enabled over those links (and so there is no IGP adjacency over =20=

>> the
>>    inter-ASBR links).  ...
>> "Thanks to such an optimization, the inter-ASBRs TE link information
>>    corresponding to the links originated by the ASBR is made =20
>> available
>>    in the TED of other LSRs in the same domain that the ASBR =20
>> belongs to."
>>
>> but after
>> "Note that no topology
>>    information is flooded and these links are not used in IGP SPF
>>    computations.  Only the TE information for the outgoing links
>>    directly connected to the ASBR is advertised."
>>
>> -> can one of the author clarify 1) is flooding involved or not ?
>> 2) what get's flooded and under which conditions 3) what is the
>> scope of the flooding 4) how this mechanism positions against the
>> requirements of 4105 and 4216
>>
>>
>> o) a couple of edits
>>
>> section 1:
>>
>> ABR Router, ASBR Router - redundant R
>>
>> the most important def. is the "domain" def. which can be found in =20=

>> the
>> frm doc but not recorded here this would clarify sentence like
>>
>> "The mechanisms proposed in this document are also applicable to MPLS
>>  TE domains other than IGP areas and ASs."
>>
>> ref. H-LSP and S-LSP with the appropriate docs
>>
>> state that inter-domain recovery is going to be addressed in a set of
>> specific docs
>>
>> hope this will help,
>> - d.
>>
>>
>>
>>
>> "Adrian Farrel" <[email-masked]>
>> Sent by: [email-masked]
>> 09/01/2007 23:13
>> Please respond to "Adrian Farrel"
>>
>>         To:     <[email-masked]>
>>         cc:
>>         Subject:        Progressing the three inter-domain I-Ds
>>
>>
>> Hi,
>>
>> We now have updated versions of the three inter-domain signaling I-=20=

>> Ds:
>>
>> - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
>> - draft-ietf-ccamp-lsp-stitching-04.txt
>> - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>>
>> Our plan is:
>> 1. WG chairs do detailed review over the next couple of weeks
>> 2. Editors apply necessary updates
>> 3. We hold a WG last call for the three I-Ds together
>>
>> If you are interested in this work, I suggest that now might be a =20
>> good
>> time
>> to remind yourself about the I-Ds, have a good read, and see if =20
>> you can
>> get
>> any substantial comments in to coincide with the WG chairs' review.
>>
>> Thanks,
>> Adrian
>>
>>
>>
>>
>>
>>
>>

Delivery-date: Tue, 16 Jan 2007 14:43:36 +0000
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 09:42:57 -0500
To: [email-masked]

Hi Dimitri,

On Jan 13, 2007, at 6:49 AM, [email-masked] =20
wrote:

> hi adrian
>
> o) a couple of generic comments on the third doc
>
> - the doc. states applicability to GMPLS but sometimes only ref. =20
> MPLS-TE
> signaling further on e.g. section 3.1
>
> " - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."
>
> and many others in section 4.
>

ok.

> - the are many comparison with PCE technique along the doc. - well =20
> that's
> fine but outside the scope of the document except if the purpose is to
> indicate how different techniques can be combined together and which
> interop issues may result from it
>

Because there are indeed two path computation techniques, it is =20
useful to keep these references in order to provide a fair =20
comparison. We could of course come up with a separate applicability =20
ID, but there are already quite a few related IDs, thus it is =20
preferable to keep the text here. I'll double check if there's any =20
redundancy though.

> o) a couple of specific comments
>
> end of section 2:
>
> section 3.1: "* The complete list of boundary LSRs along the path"
> -> list of domain identifier e.g. AS numbers also applies here ?
>
> last =A7 of section 3.1 is the most important one, signaling protocol =20=

> are
> independent of the routing topology itself, i.e. not because a node is
> an ABR or an ASBR that comp. occurs but simply because he has no path
> to reach the next (loose) hop - an intermediate node should still =20
> maintain
> capacity to perform such operation
>
> section 3.3 "The path computation
>    technique described in this document applies to the case of a =20
> single
>    AS made of multiple IGP areas, multiples ASs made of a single IGP
>    areas or any combination of the above.  For the sake of simplicity,
>    each routing domain will be considered as single area in this
>    document. "
>
> -> not sure to understand the reasoning, at the end these examples =20
> must
> remain illustrative and not restrict applicability - all these =20
> tutorial
> like material should better go in an appendix -

Not sure why ?

>
> section 3.1 "In any case,
>    no topology or resource information needs to be distributed between
>    domains (as mandated per [RFC4105] and [RFC4216]), which is =20
> critical
>    to preserve IGP/BGP scalability and confidentiality in the case =20
> of TE
>    LSPs spanning multiple routing domains."
>
> then Section 4
> "In terms of computation of an inter-AS TE LSP path, an interesting
>    optimization technique consists of allowing the ASBRs to flood =20
> the TE
>    information related to the inter-ASBR link(s) although no IGP TE is
>    enabled over those links (and so there is no IGP adjacency over the
>    inter-ASBR links).  ...
> "Thanks to such an optimization, the inter-ASBRs TE link information
>    corresponding to the links originated by the ASBR is made available
>    in the TED of other LSRs in the same domain that the ASBR =20
> belongs to."
>
> but after
> "Note that no topology
>    information is flooded and these links are not used in IGP SPF
>    computations.  Only the TE information for the outgoing links
>    directly connected to the ASBR is advertised."
>
> -> can one of the author clarify 1) is flooding involved or not ?

I'll be happy to clarify. The idea is to flood the TE info for the =20
Inter-AS link(s). Note that this does not contradict the requirements =20=

of RFC4216:
(1) Confidentiality relates to the topology of another domain: the TE =20=

information flooded in a domain is only augmented by Inter-AS links, =20
not to any link in another domain.
(2) Scalability: of course, flooding the TE info of a few Inter-AS =20
links will not compromise the scalability of the IGP.

> 2) what get's flooded and under which conditions 3) what is the
> scope of the flooding 4) how this mechanism positions against the
> requirements of 4105 and 4216
>

Did I clarify ? If so, I'll add a paragraph in the ID.

>
> o) a couple of edits
>
> section 1:
>
> ABR Router, ASBR Router - redundant R
>
> the most important def. is the "domain" def. which can be found in the
> frm doc but not recorded here this would clarify sentence like
>
> "The mechanisms proposed in this document are also applicable to MPLS
>  TE domains other than IGP areas and ASs."
>
> ref. H-LSP and S-LSP with the appropriate docs
>
> state that inter-domain recovery is going to be addressed in a set of
> specific docs

Thanks for the edits.

JP.

>
> hope this will help,
> - d.
>
>
>
>
> "Adrian Farrel" <[email-masked]>
> Sent by: [email-masked]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[email-masked]>
>         cc:
>         Subject:        Progressing the three inter-domain I-Ds
>
>
> Hi,
>
> We now have updated versions of the three inter-domain signaling I-Ds:
>
> - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
> - draft-ietf-ccamp-lsp-stitching-04.txt
> - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>
> Our plan is:
> 1. WG chairs do detailed review over the next couple of weeks
> 2. Editors apply necessary updates
> 3. We hold a WG last call for the three I-Ds together
>
> If you are interested in this work, I suggest that now might be a good
> time
> to remind yourself about the I-Ds, have a good read, and see if you =20=

> can
> get
> any substantial comments in to coincide with the WG chairs' review.
>
> Thanks,
> Adrian
>
>
>
>

Delivery-date: Tue, 16 Jan 2007 14:32:32 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 14:11:33 -0000
Organization: Old Dog Consulting

Hi Dimitri,

Thanks for your observations. We will fold them in with our review (unless 
the authors want to spin a new version first?)

You wrote:

> o) a couple of specific comments
>
>end of section 2:
>

Missing comment?

With regard to the discussion about advertising inter-AS TE links, you are 
right that this needs clarification. I also feel that this I-D is not the 
place to do it. *If* IGP advertisement of inter-AS TE links is supported, it 
will need documentation and this I-D can point to it.

Adrian 

Delivery-date: Tue, 16 Jan 2007 14:32:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Derek Atkins" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06
Date: Tue, 16 Jan 2007 14:03:23 -0000
Organization: Old Dog Consulting

Hi Derek,

Yes you have captured the exposure correctly.

The question is: what is he trust model between neighbors? If the model is 
high enough then the only way for a!=b is a mistake. If the trust model is 
not high enough then a!=b could be malicious. If there is a security hole 
*between* neighbors, b may be modified in transit such that a!=b.

I think that in a cooperative singaling protocol we have to assume that 
there is trust between neighbors once identities have been established. 
RSVP-TE provides such identity confirmation and also secures the traffic 
between neighbors.

This leaves us with only the mistake, and generally we don't make extensive 
protocol changes to handle the potential for broken implementations.

Thanks,
Adrian

----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Monday, January 15, 2007 2:56 PM
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06

> Adrian,
>
> The fact that the exchange is secured only means that you've
> verified the endpoint, not the data.  For example, let's say
> that you and I are endpoints.  I send you "a" and then I restart.
> I ask for for my data, we secure the exchange (so I know that
> it's you I'm talking to), and then you send me "b".
>
> The RSVP-TE assures me that YOU sent me "b", but it doesn't
> assure me that "b" == "a", what I sent originally.
>
> Now, one way to solve this problem would be for the originating node
> to put their own MAC on their data with a private key known only to
> the originating node.  This way when you send me "b" it wouldn't
> have my own MAC on it (or the MAC would be invalid, or a timestamp
> would be too old).
>
> Maybe overkill, but if I'm trying to abuse resources I could use
> the restart method to backfill my requests.
>
> Thanks,
>
> -derek
>
> "Adrian Farrel" <[email-masked]> writes:
>
>> Hi Derek,
>>
>> I think this is a good question so I am bringing it to the CCAMP list.
>>
>> The bottom line would appear to be:
>> - The exchange between neighbors before restart was
>>   secured by normal RSVP-TE means
>> - The exchange after restart is secured by the same means.
>> - This provides a degree of protection that the restarting
>>   node is receiving information that it originally sent to
>>   its neighbor.
>>
>> The obvious question is, should the restarting node have some (private) 
>> way
>> of authenticating that the information received on restart originated 
>> with
>> it? This would presumably be some sort of cookie manufactured from a 
>> mock-up
>> of the restart message that the restarting node expects to receive and
>> handed to the neighbor for use in the event of a restart.
>>
>> Seems like overkill to me, but I'd appreciate views from the WG.
>>
>> Adrian
>>
>> ----- Original Message ----- 
>> From: "Derek Atkins" <[email-masked]>
>> To: <[email-masked]>; <[email-masked]>
>> Cc: <[email-masked]>; <[email-masked]>;
>> <[email-masked]>; <[email-masked]>; 
>> <[email-masked]>;
>> <[email-masked]>; <[email-masked]>
>> Sent: Friday, January 12, 2007 10:59 PM
>> Subject: draft-ietf-ccamp-rsvp-restart-ext-06
>>
>>
>>>I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all IETF documents being processed by the
>>> IESG.  These comments were written primarily for the benefit of the
>>> security area directors.  Document editors and WG chairs should treat
>>> these comments just like any other last call comments.
>>>
>>> I don't see any issues in this document beyond those already stated
>>> in the Security Considerations.
>>>
>>> My only question to the authors would be how does a recovering node
>>> verify that the data it gets from a peer node really came from the
>>> recovering node?  Right now it just seems to have to trust that the
>>> peer returns valid data.
>>>
>>> -derek
>>> -- 
>>>       Derek Atkins                 617-623-3745
>>>       [email-masked]             www.ihtfp.com
>>>       Computer and Internet Security Consultant
>>>
>>>
>>>
>>
>>
>>
>>
>
> -- 
>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>       Member, MIT Student Information Processing Board  (SIPB)
>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>       [email-masked]                        PGP key available
>
>
> 

Delivery-date: Tue, 16 Jan 2007 04:17:07 +0000
Date: Tue, 16 Jan 2007 12:16:12 +0800
From: Mach Chen <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
To: Peng He <[email-masked]>
Cc: [email-masked], Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

Delivery-date: Tue, 16 Jan 2007 03:20:13 +0000
Date: Mon, 15 Jan 2007 22:17:31 -0500
From: "Peng He" <[email-masked]>
To: "Mach Chen" <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
Cc: [email-masked],  "Adrian Farrel" <[email-masked]>, [email-masked],  [email-masked]

Hello Mach,

I understood that the path compute element(Head-end, ASBR, or PCE)
should  have the inter-ASBR links info to compute an optimal or
near-optimal inter-domain path.

You said "But I think the inter-ASBR link should have AS flooding
scope." What do you mean by "AS flooding scope"? Is it within an AS or
among ASes? If within an AS, then that's the example shown in the
third document and mentioned in Dimitri's questions; if among ASes,
then how many ASes would be enough?

I just guess the contents of inter-AS link info to be flooded seems
easily to be decided (consider it as a special intra-AS TE link with
AS # attached), and might just need a simple document to define it;
the difficult thing is the flooding scope, which might be varied with
different path computing approaches or even the agreement among
operators.  Still seems to me hard to define a standard to rule it.
Or, leave every options open?

Regards,
Peng

On 1/15/07, Mach Chen <[email-masked]> wrote:
> Hi Peng,
>
> I means that no matter what kind of path computation methods(Per-domain, =
BRPC, etc.) we adopt,
> if we want to compute a path spaning mutiple ASes, the compute element(He=
ad-end, ASBR, or PCE)
> SHOULD get the inter-ASBR links info.
>
> With respect to the flooding scope and specification of inter-ASBR links =
info,  we need more discussion.
> But I think the inter-ASBR link should have AS flooding scope.
>
> ----- Original Message -----
> From: "Peng He" <[email-masked]>
> To: "Mach Chen" <[email-masked]>
> Cc: <[email-masked]>; "Adrian Farrel" <adrian@ol=
ddog.co.uk>; <[email-masked]>; <[email-masked]>
> Sent: Monday, January 15, 2007 11:26 AM
> Subject: Re: Progressing the three inter-domain I-Ds
>
>
> Hello Mach,
>
> I am interested in such work. But I am not sure what you said "in oder
> to perform  inter-AS path computation, inter-ASBR links fooding is
> desired", say, different computing methods might need different
> information about the inter-AS links and various flood ranges, and if
> not a general method is considered as default, it seems to me hard to
> define what exact info should be flooded. Just my personal thoughts.
>
> Regards,
> Peng
>
> On 1/14/07, Mach Chen <[email-masked]> wrote:
> > Dimitri and all,
> >
> > After reading these docs I also have the same concern with you about in=
ter-ASBR links flooding.
> > I think, in oder to perform  inter-AS path computation, inter-ASBR link=
s fooding is desired. But
> > such kind of inter-ASBR link info should include more information than =
"normal" TE links do,
> > e.g: the inter-ASBR links info SHOULD still include the peer AS number =
and peer ASBR router id
> > besides those link info which has been specified in rfc3630 and rfc3784=
.
> >
> > So I think there need a document to clarify and specify inter-ASBR link=
s flooding. we are considering to
> > write such a document. If someone interested in such work, we could coo=
perate.
> >
> >
> >
> > Best regards,
> >
> > Mach
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: "Adrian Farrel" <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>
> > Sent: Saturday, January 13, 2007 7:49 PM
> > Subject: Re: Progressing the three inter-domain I-Ds
> >
> >
> > hi adrian
> >
> > o) a couple of generic comments on the third doc
> >
> > - the doc. states applicability to GMPLS but sometimes only ref. MPLS-T=
E
> > signaling further on e.g. section 3.1
> >
> > " - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."
> >
> > and many others in section 4.
> >
> > - the are many comparison with PCE technique along the doc. - well that=
's
> > fine but outside the scope of the document except if the purpose is to
> > indicate how different techniques can be combined together and which
> > interop issues may result from it
> >
> > o) a couple of specific comments
> >
> > end of section 2:
> >
> > section 3.1: "* The complete list of boundary LSRs along the path"
> > -> list of domain identifier e.g. AS numbers also applies here ?
> >
> > last =A7 of section 3.1 is the most important one, signaling protocol a=
re
> > independent of the routing topology itself, i.e. not because a node is
> > an ABR or an ASBR that comp. occurs but simply because he has no path
> > to reach the next (loose) hop - an intermediate node should still maint=
ain
> > capacity to perform such operation
> >
> > section 3.3 "The path computation
> >    technique described in this document applies to the case of a single
> >    AS made of multiple IGP areas, multiples ASs made of a single IGP
> >    areas or any combination of the above.  For the sake of simplicity,
> >    each routing domain will be considered as single area in this
> >    document. "
> >
> > -> not sure to understand the reasoning, at the end these examples must
> > remain illustrative and not restrict applicability - all these tutorial
> > like material should better go in an appendix -
> >
> > section 3.1 "In any case,
> >    no topology or resource information needs to be distributed between
> >    domains (as mandated per [RFC4105] and [RFC4216]), which is critical
> >    to preserve IGP/BGP scalability and confidentiality in the case of T=
E
> >    LSPs spanning multiple routing domains."
> >
> > then Section 4
> > "In terms of computation of an inter-AS TE LSP path, an interesting
> >    optimization technique consists of allowing the ASBRs to flood the T=
E
> >    information related to the inter-ASBR link(s) although no IGP TE is
> >    enabled over those links (and so there is no IGP adjacency over the
> >    inter-ASBR links).  ...
> > "Thanks to such an optimization, the inter-ASBRs TE link information
> >    corresponding to the links originated by the ASBR is made available
> >    in the TED of other LSRs in the same domain that the ASBR belongs to=
."
> >
> > but after
> > "Note that no topology
> >    information is flooded and these links are not used in IGP SPF
> >    computations.  Only the TE information for the outgoing links
> >    directly connected to the ASBR is advertised."
> >
> > -> can one of the author clarify 1) is flooding involved or not ?
> > 2) what get's flooded and under which conditions 3) what is the
> > scope of the flooding 4) how this mechanism positions against the
> > requirements of 4105 and 4216
> >
> >
> > o) a couple of edits
> >
> > section 1:
> >
> > ABR Router, ASBR Router - redundant R
> >
> > the most important def. is the "domain" def. which can be found in the
> > frm doc but not recorded here this would clarify sentence like
> >
> > "The mechanisms proposed in this document are also applicable to MPLS
> >  TE domains other than IGP areas and ASs."
> >
> > ref. H-LSP and S-LSP with the appropriate docs
> >
> > state that inter-domain recovery is going to be addressed in a set of
> > specific docs
> >
> > hope this will help,
> > - d.
> >
> >
> >
> >
> > "Adrian Farrel" <[email-masked]>
> > Sent by: [email-masked]
> > 09/01/2007 23:13
> > Please respond to "Adrian Farrel"
> >
> >         To:     <[email-masked]>
> >         cc:
> >         Subject:        Progressing the three inter-domain I-Ds
> >
> >
> > Hi,
> >
> > We now have updated versions of the three inter-domain signaling I-Ds:
> >
> > - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
> > - draft-ietf-ccamp-lsp-stitching-04.txt
> > - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
> >
> > Our plan is:
> > 1. WG chairs do detailed review over the next couple of weeks
> > 2. Editors apply necessary updates
> > 3. We hold a WG last call for the three I-Ds together
> >
> > If you are interested in this work, I suggest that now might be a good
> > time
> > to remind yourself about the I-Ds, have a good read, and see if you can
> > get
> > any substantial comments in to coincide with the WG chairs' review.
> >
> > Thanks,
> > Adrian
> >
> >
> >
> >
> >
> >
> >
>
>

Envelope-to: [email-masked]
Delivery-date: Mon, 15 Jan 2007 21:35:22 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, ccamp mailing list <[email-masked]>, ccamp chair <[email-masked]>
Subject: Protocol Action: 'RSVP-TE Extensions in support of  End-to-End Generalized Multi-Protocol Label Switching (GMPLS)  Recovery' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Mon, 15 Jan 2007 16:32:22 -0500

The IESG has approved the following document:

- 'RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol 
   Label Switching (GMPLS) Recovery '
   <draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt> as a Proposed Standard

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt

Technical Summary
 
   This document describes protocol specific procedures and extensions 
   for Generalized Multi-Protocol Label Switching (GMPLS) Resource 
   ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to 
   support end-to-end Label Switched Path (LSP) recovery that denotes 
   protection and restoration. A generic functional description of 
   GMPLS recovery can be found in a companion document, RFC 4426. 
 
Working Group Summary
 
   no dissent reported. Many vendors have implemented and many 
   networks have deployed some versions of this. 
 
Protocol Quality
 
   Ross Callon reviewed this for the IESG. There are multiple 
   interoperable implementations and deployment. 

Note to RFC Editor
 
   Note, this document and one other document 
   (draft-ietf-ccamp-gmpls-segment-recovery-03.txt) should be 
   progressed together. This document references the other document.
   Progressing together will ensure the RFC Ed can sort out details.

   Also, please see significant IANA note. 

IANA Note

   There are significant IANA considerations, which have been cleared 
   up by Adrian Farrel's email to the IANA on Thu, 14 Dec 2006 10:52:16.

   His explanation of IANA considerations are (cut and pasted from the 
   attachment to Adrian's email):

IANA requests for

[e2e]     draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt
[seg]     draft-ietf-ccamp-gmpls-segment-recovery-03.txt

All other references are provided for information and context.

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

Registry: RSVP
          Class Names, Class Numbers, and Class Types

  20  EXPLICIT_ROUTE                          [RFC3209]

        Class Types or C-Types:
          1   Type 1 Explicit Route           [RFC3209]

              Sub-object type
                1   IPv4 prefix               [RFC3209]
                2   IPv6 prefix               [RFC3209]
                3   Label                     [RFC3473]
                4   Unnumbered Interface ID   [RFC3477]
               32   Autonomous system number  [RFC3209]
               37   Reserved                  [seg]

  21  ROUTE_RECORD                            [RFC3209]
      (also known as RECORD_ROUTE)

      Class Types or C-Types:
          1   Type 1 Route Record             [RFC3209]

              Sub-object type
                1   IPv4 address              [RFC3209]
                2   IPv6 address              [RFC3209]
                3   Label                     [RFC3473]
                4   Unnumbered Interface ID   [RFC3477]
                5   RRO Attributes            [RFC4420]
               37   Reserved                  [seg]

  37  PROTECTION                              [RFC3473]

      Class Types or C-Types:
        1   Type 1 Protection                 [RFC3473]
        2   Type 2                            [e2e]

  38  PRIMARY PATH ROUTE                      [e2e]

      Class Types or C-Types:
        1   Type 1 Primary Path Route         [e2e]

 198  ALARM_SPEC                              [RFC4783]

      Class Types or C-Types:
        1   Type 1  RESERVED                  [RFC4783]
        2   Type 2  RESERVED                  [RFC4783]
        3   IPv4 IF_ID ALARM_SPEC             [RFC4783]
        4   IPv6 IF_ID ALARM_SPEC             [RFC4783]

 199  ASSOCIATION                             [e2e]

      Class Types or C-Types:
        1   Type 1 IPv4 Association           [e2e]
        2   Type 2 IPv6 Association           [e2e]

 200  SECONDARY_EXPLICIT_ROUTE                [seg]

      Same C-Type values as EXPLICIT_ROUTE object
      (C-Num 20) with the following additions:

        For Class 1, C-Type 1, the following additional
        Sub-object type is defined:

           Sub-object type
            37   Protection                   [seg]

 201  SECONDARY_RECORD_ROUTE                  [seg]

      Same C-Type values as EXPLICIT_ROUTE object
      (C-Num 20) with the following additions:

        For Class 1, C-Type 1, the following additional
        Sub-object type is defined:

           Sub-object type
            37   Protection                   [seg]

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

Registry: GMPLS Signaling Parameters
          Interface_ID Types

  Type  Length  Format      Description                 Reference
  ----  ------  ----------  --------------------------  ---------
   512       8  See below   REFERENCE_COUNT             [RFC4783]
   513       8  See below   SEVERITY                    [RFC4783]
   514       8  See below   GLOBAL_TIMESTAMP            [RFC4783]
   515       8  See below   LOCAL_TIMESTAMP             [RFC4783]
   516  varies  See below   ERROR_STRING                [RFC4783]

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

Registry: GMPLS Signaling Parameters
          Administrative Status Information Flags

  Value       Name                             Reference
  ----------- -------------------------------- ---------
  0x80000000  Reflect (R)                      [RFC3473][RFC3471]
  0x00000020  Lockout (L)                      [e2e]
  0x00000010  Inhibit Alarm Communication (I)  [RFC4783]
  0x00000004  Testing (T)                      [RFC3473][RFC3471]
  0x00000002  Administratively down (A)        [RFC3473][RFC3471]
  0x00000001  Deletion in progress (D)         [RFC3473][RFC3471]

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

Registry: RSVP
          Error Codes and Values

Error Code Meaning

  01 Admission Control Failure                [RFC2205]

      The sixteen bits of the Error Value field are
        ssur cccc cccc cccc
      as defined in [RFC2205]

        The following globally-defined sub-codes may appear in the low-
        order 12 bits when ssur = 0000:

        Sub-code  Meaning                         Reference
        --------  ------------------------------  ---------
               1  Delay bound cannot be met       [RFC2205]
               2  Requested bandwidth unavailable [RFC2205]
               3  MTU in flowspec larger than     [RFC2205]
                  interface MTU
               4  LSP Admission Failure           [e2e]
               5  Bad Association Type            [e2e]

  02 Policy Control Failure                   [RFC2205]

      This Error Code has the following globally-defined Error
      Value sub-codes:

        0 = Information reporting                 [RFC2750]
        1 = Warning                               [RFC2750]
        2 = Reason unknown                        [RFC2750]
        3 = Generic Policy Rejection              [RFC2750]
        4 = Quota or Accounting violation         [RFC2750]
        5 = Flow was preempted                    [RFC2750]
        6 = Previously installed policy expired   [RFC2750]
            (not refreshed)
        7 = Previous policy data was replaced &   [RFC2750]
            caused rejection
        8 = Policies could not be merged          [RFC2750]
            (multicast)
        9 = PDP down or non functioning           [RFC2750]
       10 = Third Party Server (e.g., Kerberos)   [RFC2750]
            unavailable
       11 = POLICY_DATA object has bad syntax     [RFC2750]
       12 = POLICY_DATA object failed Integrity   [RFC2750]
            Check
       13 = POLICY_ELEMENT object has bad syntax  [RFC2750]
       14 = Mandatory PE Missing (Empty PE is in  [RFC2750]
            the PD object)
       15 = PEP Out of resources to handle        [RFC2750]
            policies.
       16 = PDP encountered bad RSVP objects or   [RFC2750]
            syntax
       17 = Service type was rejected             [RFC2750]
       18 = Reservation Style was rejected        [RFC2750]
       19 = FlowSpec was rejected (too large)     [RFC2750]
       20 = Hard Pre-empted                       [e2e]

  24 Routing Problem                          [RFC3209]

      This Error Code has the following globally-defined Error
      Value sub-codes:

        1 = Bad EXPLICIT_ROUTE object         [RFC3209]
        : (snip)
       16 = Unknown Interface Index           [RFC3477]
       17 = Unsupported LSP Protection        [e2e]
       18 = PROTECTION object not applicable  [e2e]
       19 = Bad PRIMARY PATH_ROUTE object     [e2e]
       20 = PRIMARY PATH_ROUTE object not     [e2e]
            applicable
       21 = LSP Segment Protection Failed     [seg]

  25 Notify Error                             [RFC3209]

      This Error Code has the following globally-defined Error
      Value sub-codes:

        1 = RRO too large for MTU             [RFC3209]
        2 = RRO Notification                  [RFC3209]
        3 = Tunnel locally repaired           [RFC3209]
        4 = Control Channel Active State      [RFC3473]
        5 = Control Channel Degraded State    [RFC3473]
        6 = Preferable path exists            [RFC4736]
        7 = Local link maintenance required   [RFC4736]
        8 = Local node maintenance required   [RFC4736]
        9 = LSP Failure                       [e2e]
       10 = LSP Recovered                     [e2e]
       11 = LSP Locally Failed                [e2e]

  31 Alarms                                   [RFC4783]

      The Error Value sub-codes for this Error Code
      have values and meanings identical to the values
      and meanings defined in the IANAItuProbableCause
      Textual Convention of IANA-ITU-ALARM-TC-MIB
      in the Alarm MIB [RFC3877].

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

Registry: GMPLS Signaling Parameters
          Association Type
(This is a new registry)

   Assignment by IANA are subject to IETF expert review
   process i.e. IETF Standards Track RFC Action.

   Value   Type                 Reference
   -----   -----------------    ---------
       0   Reserved             [e2e]
       1   Recovery (R)         [e2e]
       2   Resource Sharing (R) [seg]

Envelope-to: [email-masked]
Delivery-date: Mon, 15 Jan 2007 21:35:15 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, ccamp mailing list <[email-masked]>, ccamp chair <[email-masked]>
Subject: Protocol Action: 'GMPLS Based Segment Recovery' to  Proposed Standard 
Message-Id: <[email-masked]>
Date: Mon, 15 Jan 2007 16:33:52 -0500

The IESG has approved the following document:

- 'GMPLS Based Segment Recovery '
   <draft-ietf-ccamp-gmpls-segment-recovery-03.txt> as a Proposed Standard

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-03.txt

Technical Summary
 
   This document describes protocol specific procedures for GMPLS
   (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
   ReserVation Protocol - Traffic Engineering) signaling extensions to
   support label switched path (LSP) segment protection and restoration.
   These extensions are intended to complement and be consistent with
   the Extensions for End-to-End GMPLS-based Recovery.  Implications and
   interactions with Fast Reroute are also addressed.  This document
   also updates the handling of Notify_Request objects.

Working Group Summary
 
  No dissent reported. Good WG consensus. 
 
Protocol Quality
 
  Ross Callon has reviewed this for the IESG. There are multiple 
  implementations and deployment. 

Note to RFC Editor
 
  Note, this document and one other document 
  (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt) should be   
  progressed together. This document references the other document. 
  Progressing together will ensure the RFC Ed can sort out details, 
  including cross-references between the two documents. 

  There is an IANA nit that will need to be fixed (see IANA note below).

  Also, the reference to draft-lang-ccamp-gmpls-recovery-e2e-signaling 
  should be corrected to draft-ietf-ccamp-gmpls-recovery-e2e-signaling 

IANA Note

  There is an IANA nit that will need to be fixed. In particular:
  sections 9.3 and 9.4 suggest the same value (198) for the
  SECONDARY_EXPLICIT_ROUTE and SECONDARY_RECORD_ROUTE objects.
  Also, I am told that this value has already (recently) been 
  assigned to an unrelated object. Thus, the IANA will need to 
  straighten this out. These and related IANA considerations have
  been cleared up by Adrian Farrel's email to the IANA on Thu, 14 
  Dec 2006 10:52:16.

  His explanation of IANA considerations are (cut and pasted from the 
  attachment to Adrian's email):

IANA requests for

[e2e]     draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt
[seg]     draft-ietf-ccamp-gmpls-segment-recovery-03.txt

All other references are provided for information and context.

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

Registry: RSVP
          Class Names, Class Numbers, and Class Types

  20  EXPLICIT_ROUTE                          [RFC3209]

        Class Types or C-Types:
          1   Type 1 Explicit Route           [RFC3209]

              Sub-object type
                1   IPv4 prefix               [RFC3209]
                2   IPv6 prefix               [RFC3209]
                3   Label                     [RFC3473]
                4   Unnumbered Interface ID   [RFC3477]
               32   Autonomous system number  [RFC3209]
               37   Reserved                  [seg]

  21  ROUTE_RECORD                            [RFC3209]
      (also known as RECORD_ROUTE)

      Class Types or C-Types:
          1   Type 1 Route Record             [RFC3209]

              Sub-object type
                1   IPv4 address              [RFC3209]
                2   IPv6 address              [RFC3209]
                3   Label                     [RFC3473]
                4   Unnumbered Interface ID   [RFC3477]
                5   RRO Attributes            [RFC4420]
               37   Reserved                  [seg]

  37  PROTECTION                              [RFC3473]

      Class Types or C-Types:
        1   Type 1 Protection                 [RFC3473]
        2   Type 2                            [e2e]

  38  PRIMARY PATH ROUTE                      [e2e]

      Class Types or C-Types:
        1   Type 1 Primary Path Route         [e2e]

 198  ALARM_SPEC                              [RFC4783]

      Class Types or C-Types:
        1   Type 1  RESERVED                  [RFC4783]
        2   Type 2  RESERVED                  [RFC4783]
        3   IPv4 IF_ID ALARM_SPEC             [RFC4783]
        4   IPv6 IF_ID ALARM_SPEC             [RFC4783]

 199  ASSOCIATION                             [e2e]

      Class Types or C-Types:
        1   Type 1 IPv4 Association           [e2e]
        2   Type 2 IPv6 Association           [e2e]

 200  SECONDARY_EXPLICIT_ROUTE                [seg]

      Same C-Type values as EXPLICIT_ROUTE object
      (C-Num 20) with the following additions:

        For Class 1, C-Type 1, the following additional
        Sub-object type is defined:

           Sub-object type
            37   Protection                   [seg]

 201  SECONDARY_RECORD_ROUTE                  [seg]

      Same C-Type values as EXPLICIT_ROUTE object
      (C-Num 20) with the following additions:

        For Class 1, C-Type 1, the following additional
        Sub-object type is defined:

           Sub-object type
            37   Protection                   [seg]

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

Registry: GMPLS Signaling Parameters
          Interface_ID Types

  Type  Length  Format      Description                 Reference
  ----  ------  ----------  --------------------------  ---------
   512       8  See below   REFERENCE_COUNT             [RFC4783]
   513       8  See below   SEVERITY                    [RFC4783]
   514       8  See below   GLOBAL_TIMESTAMP            [RFC4783]
   515       8  See below   LOCAL_TIMESTAMP             [RFC4783]
   516  varies  See below   ERROR_STRING                [RFC4783]

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

Registry: GMPLS Signaling Parameters
          Administrative Status Information Flags

  Value       Name                             Reference
  ----------- -------------------------------- ---------
  0x80000000  Reflect (R)                      [RFC3473][RFC3471]
  0x00000020  Lockout (L)                      [e2e]
  0x00000010  Inhibit Alarm Communication (I)  [RFC4783]
  0x00000004  Testing (T)                      [RFC3473][RFC3471]
  0x00000002  Administratively down (A)        [RFC3473][RFC3471]
  0x00000001  Deletion in progress (D)         [RFC3473][RFC3471]

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

Registry: RSVP
          Error Codes and Values

Error Code Meaning

  01 Admission Control Failure                [RFC2205]

      The sixteen bits of the Error Value field are
        ssur cccc cccc cccc
      as defined in [RFC2205]

        The following globally-defined sub-codes may appear in the low-
        order 12 bits when ssur = 0000:

        Sub-code  Meaning                         Reference
        --------  ------------------------------  ---------
               1  Delay bound cannot be met       [RFC2205]
               2  Requested bandwidth unavailable [RFC2205]
               3  MTU in flowspec larger than     [RFC2205]
                  interface MTU
               4  LSP Admission Failure           [e2e]
               5  Bad Association Type            [e2e]

  02 Policy Control Failure                   [RFC2205]

      This Error Code has the following globally-defined Error
      Value sub-codes:

        0 = Information reporting                 [RFC2750]
        1 = Warning                               [RFC2750]
        2 = Reason unknown                        [RFC2750]
        3 = Generic Policy Rejection              [RFC2750]
        4 = Quota or Accounting violation         [RFC2750]
        5 = Flow was preempted                    [RFC2750]
        6 = Previously installed policy expired   [RFC2750]
            (not refreshed)
        7 = Previous policy data was replaced &   [RFC2750]
            caused rejection
        8 = Policies could not be merged          [RFC2750]
            (multicast)
        9 = PDP down or non functioning           [RFC2750]
       10 = Third Party Server (e.g., Kerberos)   [RFC2750]
            unavailable
       11 = POLICY_DATA object has bad syntax     [RFC2750]
       12 = POLICY_DATA object failed Integrity   [RFC2750]
            Check
       13 = POLICY_ELEMENT object has bad syntax  [RFC2750]
       14 = Mandatory PE Missing (Empty PE is in  [RFC2750]
            the PD object)
       15 = PEP Out of resources to handle        [RFC2750]
            policies.
       16 = PDP encountered bad RSVP objects or   [RFC2750]
            syntax
       17 = Service type was rejected             [RFC2750]
       18 = Reservation Style was rejected        [RFC2750]
       19 = FlowSpec was rejected (too large)     [RFC2750]
       20 = Hard Pre-empted                       [e2e]

  24 Routing Problem                          [RFC3209]

      This Error Code has the following globally-defined Error
      Value sub-codes:

        1 = Bad EXPLICIT_ROUTE object         [RFC3209]
        : (snip)
       16 = Unknown Interface Index           [RFC3477]
       17 = Unsupported LSP Protection        [e2e]
       18 = PROTECTION object not applicable  [e2e]
       19 = Bad PRIMARY PATH_ROUTE object     [e2e]
       20 = PRIMARY PATH_ROUTE object not     [e2e]
            applicable
       21 = LSP Segment Protection Failed     [seg]

  25 Notify Error                             [RFC3209]

      This Error Code has the following globally-defined Error
      Value sub-codes:

        1 = RRO too large for MTU             [RFC3209]
        2 = RRO Notification                  [RFC3209]
        3 = Tunnel locally repaired           [RFC3209]
        4 = Control Channel Active State      [RFC3473]
        5 = Control Channel Degraded State    [RFC3473]
        6 = Preferable path exists            [RFC4736]
        7 = Local link maintenance required   [RFC4736]
        8 = Local node maintenance required   [RFC4736]
        9 = LSP Failure                       [e2e]
       10 = LSP Recovered                     [e2e]
       11 = LSP Locally Failed                [e2e]

  31 Alarms                                   [RFC4783]

      The Error Value sub-codes for this Error Code
      have values and meanings identical to the values
      and meanings defined in the IANAItuProbableCause
      Textual Convention of IANA-ITU-ALARM-TC-MIB
      in the Alarm MIB [RFC3877].

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

Registry: GMPLS Signaling Parameters
          Association Type
(This is a new registry)

   Assignment by IANA are subject to IETF expert review
   process i.e. IETF Standards Track RFC Action.

   Value   Type                 Reference
   -----   -----------------    ---------
       0   Reserved             [e2e]
       1   Recovery (R)         [e2e]
       2   Resource Sharing (R) [seg]

Delivery-date: Mon, 15 Jan 2007 05:04:43 +0000
Date: Mon, 15 Jan 2007 13:02:57 +0800
From: Mach Chen <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
To: Peng He <[email-masked]>
Cc: [email-masked], Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

Delivery-date: Mon, 15 Jan 2007 03:27:19 +0000
Date: Sun, 14 Jan 2007 22:26:27 -0500
From: "Peng He" <[email-masked]>
To: "Mach Chen" <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
Cc: [email-masked],  "Adrian Farrel" <[email-masked]>, [email-masked],  [email-masked]

Hello Mach,

I am interested in such work. But I am not sure what you said "in oder
to perform  inter-AS path computation, inter-ASBR links fooding is
desired", say, different computing methods might need different
information about the inter-AS links and various flood ranges, and if
not a general method is considered as default, it seems to me hard to
define what exact info should be flooded. Just my personal thoughts.

Regards,
Peng

On 1/14/07, Mach Chen <[email-masked]> wrote:
> Dimitri and all,
>
> After reading these docs I also have the same concern with you about inte=
r-ASBR links flooding.
> I think, in oder to perform  inter-AS path computation, inter-ASBR links =
fooding is desired. But
> such kind of inter-ASBR link info should include more information than "n=
ormal" TE links do,
> e.g: the inter-ASBR links info SHOULD still include the peer AS number an=
d peer ASBR router id
> besides those link info which has been specified in rfc3630 and rfc3784.
>
> So I think there need a document to clarify and specify inter-ASBR links =
flooding. we are considering to
> write such a document. If someone interested in such work, we could coope=
rate.
>
>
>
> Best regards,
>
> Mach
>
> ----- Original Message -----
> From: <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Saturday, January 13, 2007 7:49 PM
> Subject: Re: Progressing the three inter-domain I-Ds
>
>
> hi adrian
>
> o) a couple of generic comments on the third doc
>
> - the doc. states applicability to GMPLS but sometimes only ref. MPLS-TE
> signaling further on e.g. section 3.1
>
> " - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."
>
> and many others in section 4.
>
> - the are many comparison with PCE technique along the doc. - well that's
> fine but outside the scope of the document except if the purpose is to
> indicate how different techniques can be combined together and which
> interop issues may result from it
>
> o) a couple of specific comments
>
> end of section 2:
>
> section 3.1: "* The complete list of boundary LSRs along the path"
> -> list of domain identifier e.g. AS numbers also applies here ?
>
> last =A7 of section 3.1 is the most important one, signaling protocol are
> independent of the routing topology itself, i.e. not because a node is
> an ABR or an ASBR that comp. occurs but simply because he has no path
> to reach the next (loose) hop - an intermediate node should still maintai=
n
> capacity to perform such operation
>
> section 3.3 "The path computation
>    technique described in this document applies to the case of a single
>    AS made of multiple IGP areas, multiples ASs made of a single IGP
>    areas or any combination of the above.  For the sake of simplicity,
>    each routing domain will be considered as single area in this
>    document. "
>
> -> not sure to understand the reasoning, at the end these examples must
> remain illustrative and not restrict applicability - all these tutorial
> like material should better go in an appendix -
>
> section 3.1 "In any case,
>    no topology or resource information needs to be distributed between
>    domains (as mandated per [RFC4105] and [RFC4216]), which is critical
>    to preserve IGP/BGP scalability and confidentiality in the case of TE
>    LSPs spanning multiple routing domains."
>
> then Section 4
> "In terms of computation of an inter-AS TE LSP path, an interesting
>    optimization technique consists of allowing the ASBRs to flood the TE
>    information related to the inter-ASBR link(s) although no IGP TE is
>    enabled over those links (and so there is no IGP adjacency over the
>    inter-ASBR links).  ...
> "Thanks to such an optimization, the inter-ASBRs TE link information
>    corresponding to the links originated by the ASBR is made available
>    in the TED of other LSRs in the same domain that the ASBR belongs to."
>
> but after
> "Note that no topology
>    information is flooded and these links are not used in IGP SPF
>    computations.  Only the TE information for the outgoing links
>    directly connected to the ASBR is advertised."
>
> -> can one of the author clarify 1) is flooding involved or not ?
> 2) what get's flooded and under which conditions 3) what is the
> scope of the flooding 4) how this mechanism positions against the
> requirements of 4105 and 4216
>
>
> o) a couple of edits
>
> section 1:
>
> ABR Router, ASBR Router - redundant R
>
> the most important def. is the "domain" def. which can be found in the
> frm doc but not recorded here this would clarify sentence like
>
> "The mechanisms proposed in this document are also applicable to MPLS
>  TE domains other than IGP areas and ASs."
>
> ref. H-LSP and S-LSP with the appropriate docs
>
> state that inter-domain recovery is going to be addressed in a set of
> specific docs
>
> hope this will help,
> - d.
>
>
>
>
> "Adrian Farrel" <[email-masked]>
> Sent by: [email-masked]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[email-masked]>
>         cc:
>         Subject:        Progressing the three inter-domain I-Ds
>
>
> Hi,
>
> We now have updated versions of the three inter-domain signaling I-Ds:
>
> - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
> - draft-ietf-ccamp-lsp-stitching-04.txt
> - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>
> Our plan is:
> 1. WG chairs do detailed review over the next couple of weeks
> 2. Editors apply necessary updates
> 3. We hold a WG last call for the three I-Ds together
>
> If you are interested in this work, I suggest that now might be a good
> time
> to remind yourself about the I-Ds, have a good read, and see if you can
> get
> any substantial comments in to coincide with the WG chairs' review.
>
> Thanks,
> Adrian
>
>
>
>
>
>
>

Delivery-date: Mon, 15 Jan 2007 02:44:42 +0000
Date: Mon, 15 Jan 2007 10:41:20 +0800
From: Mach Chen <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
To: [email-masked], Adrian Farrel <[email-masked]>
Cc: [email-masked], [email-masked]

Delivery-date: Sat, 13 Jan 2007 14:58:37 +0000
Date: Sat, 13 Jan 2007 09:55:43 -0500
From: "Peng He" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Progressing the three inter-domain I-Ds
Cc: "Adrian Farrel" <[email-masked]>, [email-masked],  [email-masked]

Hi,

Sill about the the third doc:

1. in the "3.1.  Common assumptions" part, it is assumed that
"Boundary LSRs are assumed to be capable of performing local path
computation ..." . So I guess that ABR or ASBR has the function (or
part of) of PCE.

2. My understanding to Dimitri's questions:
I believe there is flooding here but only within the domain that the
ASBR belongs to. So now a domain includes non-ABSR LSRs and ABSR LSRs
and the links among them, AND the inter-domain links originating (not
terminating) from the ASBRS of this domain. Tthe flooding is among
these LSRs, but not between domains. So, it is still can be considered
as intra-domain flooding and it happens when the TE info changes I
guess.

3. The purpose of the above is to "improve the chance of successful
signaling along the next AS in case of resource  shortage ..." I
understand this, I just want to mention that it seems only true in
theory and the practical effect is not so good as expected. I
simulated this years ago when we extended DCR into inter-domain case
and just no encouraging results found.

Regards,
Peng

> 2) what get's flooded and under which conditions 3) what is the
> scope of the flooding 4) how this mechanism positions against the
> requirements of 4105 and 4216

On 1/13/07, [email-masked]
<[email-masked]> wrote:
> hi adrian
>
> o) a couple of generic comments on the third doc
>
> - the doc. states applicability to GMPLS but sometimes only ref. MPLS-TE
> signaling further on e.g. section 3.1
>
> " - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."
>
> and many others in section 4.
>
> - the are many comparison with PCE technique along the doc. - well that's
> fine but outside the scope of the document except if the purpose is to
> indicate how different techniques can be combined together and which
> interop issues may result from it
>
> o) a couple of specific comments
>
> end of section 2:
>
> section 3.1: "* The complete list of boundary LSRs along the path"
> -> list of domain identifier e.g. AS numbers also applies here ?
>
> last =A7 of section 3.1 is the most important one, signaling protocol are
> independent of the routing topology itself, i.e. not because a node is
> an ABR or an ASBR that comp. occurs but simply because he has no path
> to reach the next (loose) hop - an intermediate node should still maintai=
n
> capacity to perform such operation
>
> section 3.3 "The path computation
>    technique described in this document applies to the case of a single
>    AS made of multiple IGP areas, multiples ASs made of a single IGP
>    areas or any combination of the above.  For the sake of simplicity,
>    each routing domain will be considered as single area in this
>    document. "
>
> -> not sure to understand the reasoning, at the end these examples must
> remain illustrative and not restrict applicability - all these tutorial
> like material should better go in an appendix -
>
> section 3.1 "In any case,
>    no topology or resource information needs to be distributed between
>    domains (as mandated per [RFC4105] and [RFC4216]), which is critical
>    to preserve IGP/BGP scalability and confidentiality in the case of TE
>    LSPs spanning multiple routing domains."
>
> then Section 4
> "In terms of computation of an inter-AS TE LSP path, an interesting
>    optimization technique consists of allowing the ASBRs to flood the TE
>    information related to the inter-ASBR link(s) although no IGP TE is
>    enabled over those links (and so there is no IGP adjacency over the
>    inter-ASBR links).  ...
> "Thanks to such an optimization, the inter-ASBRs TE link information
>    corresponding to the links originated by the ASBR is made available
>    in the TED of other LSRs in the same domain that the ASBR belongs to."
>
> but after
> "Note that no topology
>    information is flooded and these links are not used in IGP SPF
>    computations.  Only the TE information for the outgoing links
>    directly connected to the ASBR is advertised."
>
> -> can one of the author clarify 1) is flooding involved or not ?
> 2) what get's flooded and under which conditions 3) what is the
> scope of the flooding 4) how this mechanism positions against the
> requirements of 4105 and 4216
>
>
> o) a couple of edits
>
> section 1:
>
> ABR Router, ASBR Router - redundant R
>
> the most important def. is the "domain" def. which can be found in the
> frm doc but not recorded here this would clarify sentence like
>
> "The mechanisms proposed in this document are also applicable to MPLS
>  TE domains other than IGP areas and ASs."
>
> ref. H-LSP and S-LSP with the appropriate docs
>
> state that inter-domain recovery is going to be addressed in a set of
> specific docs
>
> hope this will help,
> - d.
>
>
>
>
> "Adrian Farrel" <[email-masked]>
> Sent by: [email-masked]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[email-masked]>
>         cc:
>         Subject:        Progressing the three inter-domain I-Ds
>
>
> Hi,
>
> We now have updated versions of the three inter-domain signaling I-Ds:
>
> - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
> - draft-ietf-ccamp-lsp-stitching-04.txt
> - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>
> Our plan is:
> 1. WG chairs do detailed review over the next couple of weeks
> 2. Editors apply necessary updates
> 3. We hold a WG last call for the three I-Ds together
>
> If you are interested in this work, I suggest that now might be a good
> time
> to remind yourself about the I-Ds, have a good read, and see if you can
> get
> any substantial comments in to coincide with the WG chairs' review.
>
> Thanks,
> Adrian
>
>
>
>
>
>
>

Delivery-date: Sat, 13 Jan 2007 11:50:38 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Progressing the three inter-domain I-Ds
From: [email-masked]
Date: Sat, 13 Jan 2007 12:49:30 +0100

hi adrian

o) a couple of generic comments on the third doc

- the doc. states applicability to GMPLS but sometimes only ref. MPLS-TE
signaling further on e.g. section 3.1

" - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."

and many others in section 4.

- the are many comparison with PCE technique along the doc. - well that's=20
fine but outside the scope of the document except if the purpose is to=20
indicate how different techniques can be combined together and which=20
interop issues may result from it

o) a couple of specific comments=20

end of section 2:=20

section 3.1: "* The complete list of boundary LSRs along the path"
-> list of domain identifier e.g. AS numbers also applies here ?

last =A7 of section 3.1 is the most important one, signaling protocol are
independent of the routing topology itself, i.e. not because a node is
an ABR or an ASBR that comp. occurs but simply because he has no path=20
to reach the next (loose) hop - an intermediate node should still maintain
capacity to perform such operation

section 3.3 "The path computation
   technique described in this document applies to the case of a single
   AS made of multiple IGP areas, multiples ASs made of a single IGP
   areas or any combination of the above.  For the sake of simplicity,
   each routing domain will be considered as single area in this
   document. "

-> not sure to understand the reasoning, at the end these examples must
remain illustrative and not restrict applicability - all these tutorial
like material should better go in an appendix -

section 3.1 "In any case,
   no topology or resource information needs to be distributed between
   domains (as mandated per [RFC4105] and [RFC4216]), which is critical
   to preserve IGP/BGP scalability and confidentiality in the case of TE
   LSPs spanning multiple routing domains."

then Section 4
"In terms of computation of an inter-AS TE LSP path, an interesting
   optimization technique consists of allowing the ASBRs to flood the TE
   information related to the inter-ASBR link(s) although no IGP TE is
   enabled over those links (and so there is no IGP adjacency over the
   inter-ASBR links).  ...
"Thanks to such an optimization, the inter-ASBRs TE link information
   corresponding to the links originated by the ASBR is made available
   in the TED of other LSRs in the same domain that the ASBR belongs to."

but after
"Note that no topology
   information is flooded and these links are not used in IGP SPF
   computations.  Only the TE information for the outgoing links
   directly connected to the ASBR is advertised."

-> can one of the author clarify 1) is flooding involved or not ?
2) what get's flooded and under which conditions 3) what is the=20
scope of the flooding 4) how this mechanism positions against the
requirements of 4105 and 4216

o) a couple of edits
=20
section 1:

ABR Router, ASBR Router - redundant R

the most important def. is the "domain" def. which can be found in the
frm doc but not recorded here this would clarify sentence like

"The mechanisms proposed in this document are also applicable to MPLS
 TE domains other than IGP areas and ASs."

ref. H-LSP and S-LSP with the appropriate docs

state that inter-domain recovery is going to be addressed in a set of
specific docs

hope this will help,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
09/01/2007 23:13
Please respond to "Adrian Farrel"
=20
        To:     <[email-masked]>
        cc:=20
        Subject:        Progressing the three inter-domain I-Ds

Hi,

We now have updated versions of the three inter-domain signaling I-Ds:

- draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
- draft-ietf-ccamp-lsp-stitching-04.txt
- draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt

Our plan is:
1. WG chairs do detailed review over the next couple of weeks
2. Editors apply necessary updates
3. We hold a WG last call for the three I-Ds together

If you are interested in this work, I suggest that now might be a good=20
time=20
to remind yourself about the I-Ds, have a good read, and see if you can=20
get=20
any substantial comments in to coincide with the WG chairs' review.

Thanks,
Adrian=20

Delivery-date: Sat, 13 Jan 2007 11:43:03 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Derek Atkins" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06
Date: Sat, 13 Jan 2007 11:39:21 -0000
Organization: Old Dog Consulting

Hi Derek,

I think this is a good question so I am bringing it to the CCAMP list.

The bottom line would appear to be:
- The exchange between neighbors before restart was
   secured by normal RSVP-TE means
- The exchange after restart is secured by the same means.
- This provides a degree of protection that the restarting
   node is receiving information that it originally sent to
   its neighbor.

The obvious question is, should the restarting node have some (private) way 
of authenticating that the information received on restart originated with 
it? This would presumably be some sort of cookie manufactured from a mock-up 
of the restart message that the restarting node expects to receive and 
handed to the neighbor for use in the event of a restart.

Seems like overkill to me, but I'd appreciate views from the WG.

Adrian

----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Friday, January 12, 2007 10:59 PM
Subject: draft-ietf-ccamp-rsvp-restart-ext-06

>I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> I don't see any issues in this document beyond those already stated
> in the Security Considerations.
>
> My only question to the authors would be how does a recovering node
> verify that the data it gets from a peer node really came from the
> recovering node?  Right now it just seems to have to trust that the
> peer returns valid data.
>
> -derek
> -- 
>       Derek Atkins                 617-623-3745
>       [email-masked]             www.ihtfp.com
>       Computer and Internet Security Consultant
>
>
> 

Delivery-date: Fri, 12 Jan 2007 21:34:43 +0000
To: Jaudelice Cavalcante de Oliveira <[email-masked]>
Cc: [email-masked], Jaudelice Cavalcante de Oliveira <[email-masked]>, JP Vasseur <[email-masked]>, [email-masked], [email-masked], Ross Callon <[email-masked]>
Subject: Re: [mpls] Re: CCAMP Last call on	draft-deoliveira-diff-te-preemption-06.txt
From: [email-masked]
Date: Fri, 12 Jan 2007 22:31:37 +0100

hi - 

thanks for the reply - not sure you ever got the following response back

----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 12/01/2007 22:30 
-----
        Dimitri PAPADIMITRIOU
        07/01/2007 11:43 
                 To: Jaudelice Cavalcante de Oliveira 
<[email-masked]>

Hi 

thanks for the answer - i am still looking at the reason
why the PN selection process is driven by a uniform policy
which looks like an arbitrary choice

HBlock aims at minimizing the blocking probability
PN aims at minimizing the system perturbation

to have a fair analysis policy should be applied uniformly
and non-uniformly to both cases

much thanks,
- d. 

--

Jaudelice Cavalcante de Oliveira <[email-masked]>
05/01/2007 00:11
 
        To:     [email-masked]
        cc:     [email-masked], JP Vasseur <[email-masked]>, 
[email-masked], Jaudelice Cavalcante de Oliveira 
<[email-masked]>, Ross Callon <[email-masked]>, 
[email-masked]
        Subject:        [mpls] Re: CCAMP Last call on 
draft-deoliveira-diff-te-preemption-06.txt

Hi Dimitri,

Thank you for your comment.

On Dec 18, 2006, at 3:47 AM, [email-masked] 
wrote:

> adrian -
>
> in HBlock case the average wasted bw is a factor 10 smaller than 
> for any
> other scheme (without significantly lowering the worst case, still an
> order of 10)

Indeed. This can be seen in table 2. In this case, selection of LSPs 
much larger than
the required bandwidth did not occur often. The worst case value does 
not reflect the
frequency with which a high bandwidth LSP was selected (which was 
very rarely in
this case, therefore the low "wasted" bandwidth).

> the only noticeable difference with PN is exactly that one (which is
> induced by the possibility left to Hblock to have two selection 
> depending
> on heavy vs normal loaded link) - hence it would be interesting to 
> know
> the dependency on the min/max LSP bw and distribution (scenario
> dependancy) and have a similar PN approach (non-uniform selection)

Note that PN has the objective of preempting a small number of LSPs 
of the lowest
priority (therefore ordering by decreasing bandwidth), while HBlock 
aims at minimizing
the blocking probability, therefore selecting smaller LSPs which will 
be more likely to be
rerouted once preempted. This is the main difference between the two 
policies: Given a set
of LSPs with the same priority, PN picks the largest (in the interest 
of picking few) and HBlock
picks smaller ones (even if more than one, in the interest of being 
able to reroute them easily).

I hope this helps,

Thanks,

Jaudelice.

>
> thanks,
> - d.
>
>
>
>
>
>
> "Adrian Farrel" <[email-masked]>
> Sent by: [email-masked]
> 14/12/2006 18:02
> Please respond to "Adrian Farrel"
>
>         To:     <[email-masked]>
>         cc:     <[email-masked]>, "Ross Callon"
> <[email-masked]>, "Brungard, Deborah A, ALABS" 
> <[email-masked]>,
> <[email-masked]>
>         Subject:        Re: CCAMP Last call on
> draft-deoliveira-diff-te-preemption-06.txt
>
>
> Hi,
>
> I have been explicitly asked to lengthen this last call so as to allow
> time
> for a review.
>
> Unusual, but not unreasonable.
>
> The last call is extended to noon on Sunday 17th December.
>
> Thanks,
> Adrian
> ----- Original Message -----
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; "Ross Callon" <[email-masked]>;
> "Brungard, Deborah A, ALABS" <[email-masked]>; 
> <[email-masked]>
> Sent: Wednesday, November 29, 2006 11:06 AM
> Subject: CCAMP Last call on draft-deoliveira-diff-te-preemption-06.txt
>
>
>> Hi,
>>
>> This draft has been developed independently and has recently been
> brought
>> to the IESG for advancement as an individual submission to become an
>> Informational RFC. I have done a first-level review and this latest
>> revision includes updates to reflect my comments.
>>
>> Since the material here concerns preemption and the suggested ways to
>> operate an MPLS-TE or GMPLS network, we are running a quick last 
>> call on
>
>> the CCAMP mailing list to ensure that no-one has any objections.
>>
>> Please send your comments to the CCAMP list no later than noon GMT on
> 13th
>> December 2006.
>>
>> Thanks,
>> Adrian
>> ----- Original Message -----
>> From: <[email-masked]>
>> To: <[email-masked]>
>> Sent: Tuesday, November 28, 2006 8:50 PM
>> Subject: I-D ACTION:draft-deoliveira-diff-te-preemption-06.txt
>>
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> Title : LSP Preemption Policies for MPLS Traffic Engineering
>>> Author(s) : J. de Oliveira, et al.
>>> Filename : draft-deoliveira-diff-te-preemption-06.txt
>>> Pages : 19
>>> Date : 2006-11-28
>>>
>>> When the establishment of a higher priority (Traffic Engineering
>>>   Label Switched Path) TE LSP requires the preemption of a set of 
>>> lower
>>>   priority TE LSPs, a node has to make a local decision to select 
>>> which
>>>
>>>   TE LSPs will be preempted.  The preempted LSPs are then 
>>> rerouted by
>>>   their respective Head-end Label Switch Router (LSR).  This 
>>> document
>>>   presents a flexible policy that can be used to achieve different
>>>   objectives: preempt the lowest priority LSPs; preempt the minimum
>>>   number of LSPs; preempt the set of TE LSPs that provide the 
>>> closest
>>>   amount of bandwidth to the required bandwidth for the 
>>> preempting TE
>>>   LSPs (to minimize bandwidth wastage); preempt the LSPs that 
>>> will have
>>>   the maximum chance to get rerouted.  Simulation results are 
>>> given and
>>>   a comparison among several different policies, with respect to
>>>   preemption cascading, number of preempted LSPs, priority, wasted
>>>   bandwidth and blocking probability is also included.
>>>
>>> A URL for this Internet-Draft is:
>>>
> http://www.ietf.org/internet-drafts/draft-deoliveira-diff-te- 
> preemption-06.txt
>
>>
>>
>>
>>
>>
>>
>
>
>
>
>

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

Delivery-date: Tue, 09 Jan 2007 22:14:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Progressing the three inter-domain I-Ds
Date: Tue, 9 Jan 2007 22:13:10 -0000
Organization: Old Dog Consulting

Hi,

We now have updated versions of the three inter-domain signaling I-Ds:

- draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
- draft-ietf-ccamp-lsp-stitching-04.txt
- draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt

Our plan is:
1. WG chairs do detailed review over the next couple of weeks
2. Editors apply necessary updates
3. We hold a WG last call for the three I-Ds together

If you are interested in this work, I suggest that now might be a good time 
to remind yourself about the I-Ds, have a good read, and see if you can get 
any substantial comments in to coincide with the WG chairs' review.

Thanks,
Adrian 

Delivery-date: Tue, 09 Jan 2007 20:52:37 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-04.txt 
Date: Tue, 09 Jan 2007 15:50:02 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Inter domain MPLS and GMPLS Traffic Engineering - RSVP-TE extensions
	Author(s)	: A. Ayyangar, J. Vasseur
	Filename	: draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
	Pages		: 18
	Date		: 2007-1-9
	
This document describes procedures and protocol extensions for the
   use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE)
   signaling in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and
   non-packet networks to support the establishment and maintenance of
   Label Switched Paths that cross domain boundaries.

   For the purpose of this document, a domain is considered to be any
   collection of network elements within a common realm of address space
   or path computation responsibility. Examples of such domains include
   Autonomous Systems, IGP routing areas, and GMPLS overlay networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-inter-domain-rsvp-te-04.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-04.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 09 Jan 2007 15:55:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Posting of IPR Disclosure
Date: Mon, 8 Jan 2007 23:16:33 -0000
Organization: Old Dog Consulting

Please be aware of the following IPR disclosure notification that has been 
posted.

Thanks,
Adrian
----- Original Message ----- 
From: "IETF Secretariat" <[email-masked]>
Sent: Monday, January 08, 2007 3:47 PM
Subject: Posting of IPR Disclosure

> An IPR disclosure that pertains to your Internet-Draft entitled "RSVP-TE
> Extensions in support of End-to-End Generalized Multi-Protocol Label 
> Switching
> (GMPLS) Recovery" (draft-ietf-ccamp-gmpls-recovery-e2e-signaling) was 
> submitted
> to the IETF Secretariat on 2007-01-05 and has been posted on the "IETF 
> Page of
> Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR
> disclosure is "Nippon Telegraph and Telephone Corporation's statement 
> about IPR
> claimed in draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt."
>
> The IETF Secretariat

Delivery-date: Mon, 08 Jan 2007 23:19:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Posting of IPR Disclosure
Date: Mon, 8 Jan 2007 23:16:33 -0000
Organization: Old Dog Consulting

Please be aware of the following IPR disclosure notification that has been 
posted.

Thanks,
Adrian
----- Original Message ----- 
From: "IETF Secretariat" <[email-masked]>
Sent: Monday, January 08, 2007 3:47 PM
Subject: Posting of IPR Disclosure

> An IPR disclosure that pertains to your Internet-Draft entitled "RSVP-TE
> Extensions in support of End-to-End Generalized Multi-Protocol Label 
> Switching
> (GMPLS) Recovery" (draft-ietf-ccamp-gmpls-recovery-e2e-signaling) was 
> submitted
> to the IETF Secretariat on 2007-01-05 and has been posted on the "IETF 
> Page of
> Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR
> disclosure is "Nippon Telegraph and Telephone Corporation's statement 
> about IPR
> claimed in draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt."
>
> The IETF Secretariat

Delivery-date: Thu, 04 Jan 2007 20:52:29 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-03.txt 
Date: Thu, 04 Jan 2007 15:50:02 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls
	Author(s)	: D. Papadimitriou, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-rsvp-te-call-03.txt
	Pages		: 29
	Date		: 2007-1-4
	
In certain networking topologies, it may be advantageous to maintain
   associations between endpoints and key transit points to support an
   instance of a service. Such associations are known as Calls.

   A Call does not provide the actual connectivity for transmitting user
   traffic, but only builds a relationship by which subsequent
   Connections may be made. In Generalized MPLS (GMPLS) such Connections
   are known as Label Switched Paths (LSPs).

   This document specifies how GMPLS RSVP-TE signaling may be used and
   extended to support Calls. These mechanisms provide full and logical
   Call/Connection separation.

   The mechanisms proposed in this document are applicable to any
   environment (including multi-area), and for any type of interface:
   packet, layer-2, time-division multiplexed, lambda, or fiber
   switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rsvp-te-call-03.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-03.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 03 Jan 2007 21:10:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-02.txt 
Date: Wed, 3 Jan 2007 21:09:37 -0000
Organization: Old Dog Consulting

Hi,

This revision addresses comments made in GenArt review and SecDir review.

The changes are small fixes to the wording to make a couple of points 
clearer.

The draft should now continue forward in the process.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 03, 2007 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-02.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 : Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support 
> of Calls
> Author(s) : D. Papadimitriou, A. Farrel
> Filename : draft-ietf-ccamp-gmpls-rsvp-te-call-02.txt
> Pages : 29
> Date : 2007-1-3
>
> In certain networking topologies, it may be advantageous to maintain
>   associations between endpoints and key transit points to support an
>   instance of a service. Such associations are known as Calls.
>
>   A Call does not provide the actual connectivity for transmitting user
>   traffic, but only builds a relationship by which subsequent
>   Connections may be made. In Generalized MPLS (GMPLS) such Connections
>   are known as Label Switched Paths (LSPs).
>
>   This document specifies how GMPLS RSVP-TE signaling may be used and
>   extended to support Calls. These mechanisms provide full and logical
>   Call/Connection separation.
>
>   The mechanisms proposed in this document are applicable to any
>   environment (including multi-area), and for any type of interface:
>   packet, layer-2, time-division multiplexed, lambda, or fiber
>   switching.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-02.txt

Delivery-date: Wed, 03 Jan 2007 20:52:52 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-02.txt 
Date: Wed, 03 Jan 2007 15:50:02 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls
	Author(s)	: D. Papadimitriou, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-rsvp-te-call-02.txt
	Pages		: 29
	Date		: 2007-1-3
	
In certain networking topologies, it may be advantageous to maintain
   associations between endpoints and key transit points to support an
   instance of a service. Such associations are known as Calls.

   A Call does not provide the actual connectivity for transmitting user
   traffic, but only builds a relationship by which subsequent
   Connections may be made. In Generalized MPLS (GMPLS) such Connections
   are known as Label Switched Paths (LSPs).

   This document specifies how GMPLS RSVP-TE signaling may be used and
   extended to support Calls. These mechanisms provide full and logical
   Call/Connection separation.

   The mechanisms proposed in this document are applicable to any
   environment (including multi-area), and for any type of interface:
   packet, layer-2, time-division multiplexed, lambda, or fiber
   switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rsvp-te-call-02.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-02.txt

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

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

--OtherAccess--

--NextPart--