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

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

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]

=== 







Envelope-to: [e-mail]
Delivery-date: Wed, 31 Jan 2007 23:06:10 +0000
Message-ID: <070701c7458b$f68a06c0$76849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, "'Jean Philippe Vasseur'" <[e-mail]>
Subject: Chair review of draft-ietf-ccamp-lsp-stitching-04.txt
Date: Wed, 31 Jan 2007 23:02:44 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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]

=== 





Envelope-to: [e-mail]
Delivery-date: Wed, 31 Jan 2007 03:40:11 +0000
Date: Wed, 31 Jan 2007 11:38:27 +0800
From: Zhang Renhai <[e-mail]>
Subject: A New Internet-Draft on Advertising of inter-AS TE links
To: [e-mail], [e-mail]
Message-id: <016301c744e9$453a5cf0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

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



Envelope-to: [e-mail]
Delivery-date: Wed, 31 Jan 2007 01:32:42 +0000
Message-ID: <051a01c744d7$5e9fb210$76849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Non-member submission from [[e-mail] (Sam Hartman)]
Date: Wed, 31 Jan 2007 01:29:55 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Sam Hartman" <[e-mail]>
To: "Ross Callon" <[e-mail]>
Cc: "Sandy Murphy" <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>
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.
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 31 Jan 2007 01:32:37 +0000
Message-ID: <051b01c744d7$74b22d80$76849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Non-member submission from [[e-mail] (Sandy Murphy)]
Date: Wed, 31 Jan 2007 01:30:29 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Sandy Murphy" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
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
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 30 Jan 2007 21:19:24 +0000
Message-ID: <048d01c744b4$3ca09f30$76849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Non-member submission from [[e-mail] (Ross Callon)]
Date: Tue, 30 Jan 2007 21:18:43 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Ross Callon" <[e-mail]>
To: "Sandy Murphy" <[e-mail]>; <[e-mail]>; 
<[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>
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
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 30 Jan 2007 21:19:04 +0000
Message-ID: <048c01c744b4$2c602910$76849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Non-member submission from [[e-mail] (Derek Atkins)]
Date: Tue, 30 Jan 2007 21:17:52 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Derek Atkins" <[e-mail]>
To: "Sandy Murphy" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
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
>       [e-mail]             www.ihtfp.com
>       Computer and Internet Security Consultant
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 30 Jan 2007 21:19:00 +0000
Message-ID: <048b01c744b4$2bd37970$76849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Non-member submission from [[e-mail] (Sandy Murphy)]
Date: Tue, 30 Jan 2007 21:16:16 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

From: "Sandy Murphy" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>
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
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 30 Jan 2007 21:18:12 +0000
Message-ID: <047701c744b3$c582d8f0$76849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Non-member submission from [[e-mail] (Sandy Murphy)]   
Date: Tue, 30 Jan 2007 21:14:30 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

> To: [e-mail]
> Subject: Re: Security considerations with 
> draft-ietf-ccamp-rsvp-restart-ext-07
> Cc: [e-mail], [e-mail], [e-mail],
>   [e-mail], [e-mail], [e-mail]
> In-Reply-To: <044201c740e3$06b30d60$f4849ed9@your029b8cecfe>
> Message-Id: <[e-mail]>
> Date: Mon, 29 Jan 2007 13:25:15 -0500 (EST)
> From: [e-mail] (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





Envelope-to: [e-mail]
Delivery-date: Mon, 29 Jan 2007 20:52:21 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-08.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Sat, 27 Jan 2007 07:04:07 +0000
Date: Sat, 27 Jan 2007 15:00:49 +0800
From: ZhangRenhai <[e-mail]>
Subject: Re: Advertising of inter-AS TE links
To: 'Adrian Farrel' <[e-mail]>, 'JP Vasseur' <[e-mail]>, 'Mach Chen' <[e-mail]>, 'Dimitri Papadimitriou' <[e-mail]>
Cc: [e-mail]
Message-id: <000201c741e0$e2699b00$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: Acc6J2g4vXZOi5P2TfGCP/3OD10EcQHtsxIA

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" <[e-mail]>
> To: "'JP Vasseur'" <[e-mail]>; "'Mach Chen'" =
<[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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






Envelope-to: [e-mail]
Delivery-date: Fri, 26 Jan 2007 03:57:44 +0000
Message-ID: <044201c740e3$06b30d60$f4849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "'Sam Hartman'" <[e-mail]>, "Derek Atkins" <[e-mail]>, "Sandy Murphy" <[e-mail]>
Subject: Security considerations with draft-ietf-ccamp-rsvp-restart-ext-07
Date: Fri, 26 Jan 2007 00:42:11 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>
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" <[e-mail]>
To: "Derek Atkins" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
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" <[e-mail]>
To: "Derek Atkins" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
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" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>
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" <[e-mail]>
To: "Sandy Murphy" <[e-mail]>
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" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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" <[e-mail]>
To: "Sandy Murphy" <[e-mail]>
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" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; "Brungard, Deborah A, ALABS" <[e-mail]>
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" <[e-mail]>
To: "Sandy Murphy" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Tuesday, January 23, 2007 2:44 AM

>>>>>> "Sandy" == Sandy Murphy <[e-mail]> writes:
>
>    Sandy>    [e-mail], [e-mail], [e-mail],
>    Sandy> [e-mail], [e-mail]
>    >> 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" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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" <[e-mail]>
To: <[e-mail]>; "Sam Hartman" <[e-mail]>
Cc: <[e-mail]>
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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, January 23, 2007 2:59 PM


>>>>>> "Adrian" == Adrian Farrel <[e-mail]> 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" <[e-mail]>
To: "Sam Hartman" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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" <[e-mail]>
To: <[e-mail]>
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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
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.






Envelope-to: [e-mail]
Delivery-date: Wed, 24 Jan 2007 20:52:37 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-automesh-04.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Tue, 23 Jan 2007 20:51:29 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Tue, 23 Jan 2007 19:28:15 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 23 Jan 2007 20:26:50 +0100
Content-Type: text/plain; charset="US-ASCII"

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" <[e-mail]>
Sent by: [e-mail]
23/01/2007 19:09
Please respond to "Adrian Farrel"
 
        To:     <[e-mail]>
        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" <[e-mail]>
To: "Sandy Murphy" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 

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


>>>>>> "Sandy" == Sandy Murphy <[e-mail]> writes:
>
>    Sandy>    [e-mail], [e-mail], [e-mail],
>    Sandy> [e-mail], [e-mail]
>    >> 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.
>
>
>
> 








Envelope-to: [e-mail]
Delivery-date: Tue, 23 Jan 2007 18:12:33 +0000
Message-ID: <017601c73f19$b1b35240$f4849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06
Date: Tue, 23 Jan 2007 18:09:42 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: "Sandy Murphy" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
Sent: Tuesday, January 23, 2007 2:44 AM
Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06


>>>>>> "Sandy" == Sandy Murphy <[e-mail]> writes:
>
>    Sandy>    [e-mail], [e-mail], [e-mail],
>    Sandy> [e-mail], [e-mail]
>    >> 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.
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Fri, 19 Jan 2007 22:39:27 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: FW: Response liaison from ITU-T SG15 on CCAMP ASON work
Date: Fri, 19 Jan 2007 16:36:49 -0600
Message-ID: <[e-mail]>
Thread-Topic: Response liaison from ITU-T SG15 on CCAMP ASON work
Thread-Index: AccNiM+Wedzd4U7lRGW+Ze36ovZ+Dwuj+Rlw
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Tuesday, November 21, 2006 5:57 AM
To: [e-mail]
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






Envelope-to: [e-mail]
Delivery-date: Fri, 19 Jan 2007 16:38:04 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Jan 2007 08:35:29 -0800
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Evelyne Roch <[e-mail]>
CC: Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: LCAS/VCAT
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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: [phone] (esn 393-6492)
> e-mail: [e-mail]  
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Adrian Farrel
> Sent: Thursday, November 30, 2006 6:57 AM
> To: [e-mail]
> 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 [phone]





Envelope-to: [e-mail]
Delivery-date: Thu, 18 Jan 2007 21:57:28 +0000
Message-ID: <00e201c73b4b$72dd9a20$a2849ed9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Ross Callon" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-crankback-06.txt 
Date: Thu, 18 Jan 2007 21:55:50 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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





Envelope-to: [e-mail]
Delivery-date: Thu, 18 Jan 2007 20:52:44 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-crankback-06.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Thu, 18 Jan 2007 04:24:30 +0000
Date: Thu, 18 Jan 2007 12:16:16 +0800
From: ZhangRenhai <[e-mail]>
Subject: =?gb2312?B?UmU6ILTwuLQ6IFByb2dyZXNzaW5nIHRoZSB0aHJlZSBpbnRlci1kb21haW4=?= =?gb2312?B?IEktRHM=?=
To: JP Vasseur <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <003b01c73ab7$68608290$[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_9RNxoRGa7ySeo/SiTDJd1A)"

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



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 21:41:30 +0000
To: Jaudelice Cavalcante de Oliveira <[e-mail]>
Cc: [e-mail], JP Vasseur <[e-mail]>, [e-mail], [e-mail], Ross Callon <[e-mail]>
Subject: Re: [mpls] Re: CCAMP Last call	on	draft-deoliveira-diff-te-preemption-06.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 17 Jan 2007 22:41:07 +0100
Content-Type: text/plain; charset="US-ASCII"

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 <[e-mail]>
15/01/2007 20:23
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [e-mail], [e-mail], Ross Callon 
<[e-mail]>, [e-mail], JP Vasseur 
<[e-mail]>
        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, [e-mail] 
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
> <[e-mail]>
>
> 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 <[e-mail]>
> 05/01/2007 00:11
>
>         To:     [e-mail]
>         cc:     [e-mail], JP Vasseur <[e-mail]>,
> [e-mail], Jaudelice Cavalcante de Oliveira
> <[e-mail]>, Ross Callon <[e-mail]>,
> [e-mail]
>         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, [e-mail]
> 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" <[e-mail]>
>> Sent by: [e-mail]
>> 14/12/2006 18:02
>> Please respond to "Adrian Farrel"
>>
>>         To:     <[e-mail]>
>>         cc:     <[e-mail]>, "Ross Callon"
>> <[e-mail]>, "Brungard, Deborah A, ALABS"
>> <[e-mail]>,
>> <[e-mail]>
>>         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" <[e-mail]>
>> To: <[e-mail]>
>> Cc: <[e-mail]>; "Ross Callon" <[e-mail]>;
>> "Brungard, Deborah A, ALABS" <[e-mail]>;
>> <[e-mail]>
>> 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: <[e-mail]>
>>> To: <[e-mail]>
>>> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpls


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





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 21:36:29 +0000
Message-ID: <071801c73a7f$78e8aa80$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
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.





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 21:36:12 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Advertising of inter-AS TE links
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 17 Jan 2007 22:35:02 +0100
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

YWRyaWFuDQoNCndoYXQgaSBhbSBzYXlpbmcgaXMgdGhhdCBmbG9vZGluZyBpbnRlci1BUyBURSBs
aW5rIHdoZW4gdGhlIHRvcG9sb2d5DQppcyBpbiBZIChBU18xIGNvbm5lY3RlZCB0byBib3RoIEFT
XzIgYW5kIEFTXzMpIGlzIGRlLWZhY3RvIGNvdmVyZWQNCg0KdGhlIHBvaW50IGlzIHRoYXQgUENF
IG9yIG5vdCBQQ0UgdGhlIHJlc3VsdGluZyBwcm9ibGVtYXRpYyBpbiB0ZXJtcw0Kb2YgYmxvY2tp
bmcgaXMgaWRlbnRpY2FsDQoNCmVpdGhlciB0aGUgcHJvYmxlbSBpcyBsaW5lYXJpemVkIGJlZm9y
ZWhhbmQgYW5kIHRoZW4gYm90aCBzb2x1dGlvbg0Kd291bGQgbGVhZCB0byBhIHJlc3VsdCBvciBp
dCBpcyBub3QgYW5kIHRoZW4gdGhlIHBhdGggZGlzY292ZXJ5IGFrYQ0KcGF0aCBleHBsb3JhdGlv
biBpc3N1ZSBpcyBsZWZ0IHVuc29sdmVkIGJ5IGJvdGggdGVjaG5pcXVlcw0KDQp0aGFua3MsDQot
IGQuDQoNCg0KDQoNCiJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az4NClNlbnQg
Ynk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZw0KMTcvMDEvMjAwNyAxMzoxNQ0KUGxlYXNlIHJl
c3BvbmQgdG8gIkFkcmlhbiBGYXJyZWwiDQogDQogICAgICAgIFRvOiAgICAgRGltaXRyaSBQQVBB
RElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTA0KICAgICAgICBjYzogICAgIDxjY2FtcEBvcHMu
aWV0Zi5vcmc+DQogICAgICAgIFN1YmplY3Q6ICAgICAgICBSZTogQWR2ZXJ0aXNpbmcgb2YgaW50
ZXItQVMgVEUgbGlua3MNCg0KDQpZZXMsIERpbWl0cmksIEkgYWdyZWUgdGhhdCB0aGUgc2l0dWF0
aW9uIHlvdSBkZXNjcmliZSBpcyBub3Qgc29sdmVkIGJ5IA0KbGltaXRlZCBmbG9vZGluZyBvZiBp
bnRlci1BUyBURSBsaW5rcyB3aXRoaW4gb25seSB0aGVpciBhZGphY2VudCBBU2VzLg0KDQpJdCBp
cyBteSB2aWV3IHRoYXQgdGhpcyB3aWRlciBwcm9ibGVtIHNwYWNlIGhhcyBiZWVuIGRlbGVnYXRl
IGZvciANCnJlc29sdXRpb24gDQpieSBQQ0UuIFRoYXQgaXMsIGluIG9yZGVyIHRvIGZ1bGx5IHJl
c29sdmUgdGhlIHByb2JsZW0gYnkgZmxvb2Rpbmcgb2YgVEUgDQpsaW5rIGluZm9ybWF0aW9uIGl0
IHdvdWxkIGJlIG5lY2Vzc2FyeSB0byBhbHNvIGFnZ3JlZ2F0ZSBURSByZWFjaGFiaWx0eSANCmFj
cm9zcyBBU18yIGFuZCBBU18zIGluIHlvdXIgZXhhbXBsZS4gU3VjaCBhZ2dyZWdhdGlvbiBpcyBu
b24tdHJpdmlhbCANCmdpdmVuIA0KdGhlIG51bWJlciBvZiBURSBwYXJhbWV0ZXJzIGFuZCB0aGUg
bnVtYmVyIG9mIHBvdGVudGlhbCByb3V0ZXMsIGFuZCBzbyB3ZSANCndvdWxkIGhhdmUgYXQgbGVh
c3Qgb25lIG9mOg0KLSBleGNlc3MgaW5mb3JtYXRpb24gZmxvb2RpbmcNCi0gZXhjZXNzIGFnZ3Jl
Z2F0aW9uIHByb2Nlc3NpbmcNCi0gdmFsdWVsZXNzIGluZm9ybWF0aW9uIGZsb29kaW5nLg0KSW4g
dGhlIGxpZ2h0IG9mIHRoZXNlIG9wdGlvbnMgd2UgKHRoZSBSb3V0aW5nIEFyZWEpIGRlY2lkZWQg
dG8gcHVyc3VlIFBDRSANCmFzIA0KYSBzb2x1dGlvbi4NCg0KQWRyaWFuDQoNCi0tLS0tIE9yaWdp
bmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiA8RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwt
bHVjZW50LmJlPg0KVG86ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az4NCkNj
OiA8Y2NhbXBAb3BzLmlldGYub3JnPjsgIidKUCBWYXNzZXVyJyIgPGp2YXNzZXVyQGNpc2NvLmNv
bT47ICInTWFjaCANCkNoZW4nIiANCjxtYWNoQGh1YXdlaS5jb20+OyA8b3duZXItY2NhbXBAb3Bz
LmlldGYub3JnPjsgIlpoYW5nUmVuaGFpIiANCjx6aGFuZ3JlbmhhaUBodWF3ZWkuY29tPg0KU2Vu
dDogV2VkbmVzZGF5LCBKYW51YXJ5IDE3LCAyMDA3IDExOjI2IEFNDQpTdWJqZWN0OiBSZTogQWR2
ZXJ0aXNpbmcgb2YgaW50ZXItQVMgVEUgbGlua3MNCg0KDQo+IGFkcmlhbg0KPg0KPiBhZ3JlZWQg
b24gdGhlIGFuYWx5c2lzIC0gdGhlcmUgaXMgb25lIGFkZGl0aW9uYWwgY2FzZSB0aGF0DQo+IG5l
ZWRzIHRvIGJlIGFkZHJlc3NlZA0KPg0KPiBBU18xIGlzIGNvbm5lY3RlZCB0byBBU18yIGFuZCBB
U18zIGJvdGggY29ubmVjdGVkIHRvIEFTXzQNCj4NCj4gdGhlIEVSTywgaW5jbHVkZXMgQVNfMSBh
bmQgQVNfNCwgcGVyZmVjdGx5IGNsZWFyIHRoZXJlIGlzDQo+IG5vIGludGVudGlvbiB0byBwYXNz
IEFTXzIgLSBBU180IGFuZCBBU18zIC0gQVNfNCBURSBsaW5rDQo+IGluZm9ybWF0aW9uIHRvIEFT
XzENCj4NCj4gYnV0IHdoYXQgYWJvdXQgQVNfMSAtIEFTXzIgYW5kIEFTXzEgLSBBU18zIHdob3Nl
IGluZm8uIGlzDQo+IGRlZmFjdG8gYXZhaWxhYmxlDQo+DQo+IHRoZSBpc3N1ZSBpcyBvbmUgc2Vu
dGVuY2UsIHRoZSBpbml0aWFsIGxpbmVhcml6YXRpb24gZG9lcw0KPiBub3QgaG9sZCBpbiB0aGUg
Z2VuZXJpYyBjYXNlIG9mIGxvb3NlIGFic3RyYWN0IEFTJ3MNCj4NCj4gY29tbWVudHMgPw0KPg0K
PiAtZC4NCj4NCj4NCj4NCj4NCj4NCj4gIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNv
LnVrPg0KPiBTZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNCj4gMTcvMDEvMjAwNyAx
MjowMA0KPiBQbGVhc2UgcmVzcG9uZCB0byAiQWRyaWFuIEZhcnJlbCINCj4NCj4gICAgICAgIFRv
OiAgICAgIlpoYW5nUmVuaGFpIiA8emhhbmdyZW5oYWlAaHVhd2VpLmNvbT4sICInSlAgVmFzc2V1
ciciDQo+IDxqdmFzc2V1ckBjaXNjby5jb20+LCAiJ01hY2ggQ2hlbiciIDxtYWNoQGh1YXdlaS5j
b20+LCBEaW1pdHJpDQo+IFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMDQo+ICAgICAg
ICBjYzogICAgIDxjY2FtcEBvcHMuaWV0Zi5vcmc+DQo+ICAgICAgICBTdWJqZWN0OiAgICAgICAg
QWR2ZXJ0aXNpbmcgb2YgaW50ZXItQVMgVEUgbGlua3MNCj4NCj4NCj4gSGksDQo+DQo+IFNpbmNl
IHRoaXMgZGlzY3Vzc2lvbiBpcyBibG9zc29taW5nLCBpdCBjYW4gaGF2ZSBpdHMgb3duIHRocmVh
ZC4uLg0KPg0KPiBJJ2QgbGlrZSB0byB0cnkgdG8gYnJpbmcgc29tZSBmb2N1cy4NCj4NCj4gVGhl
IG1vdGl2YXRpb24gc2VlbXMgY2xlYXIuLi4NCj4gV2hlbiBjb21wdXRpbmcgYSBwYXRoIHRocm91
Z2ggb25lIEFTIGludG8gYW5vdGhlciBBUywgdGhlIGNvbXB1dGF0aW9uDQo+IHBvaW50DQo+IG5l
ZWRzIHRvIGtub3cgYWJvdXQgVEUgbGlua3MgdGhhdCBjb25uZWN0IHRvIHRoZSBuZXh0IEFTLiBU
aGlzIGVuYWJsZXMgDQppdA0KPiB0bw0KPiBzZWxlY3Q6DQo+IC0gQSBURSBsaW5rIHRoYXQgY29u
bmVjdHMgdG8gdGhlIG5leHQgQVMNCj4gLSBBIFRFIGxpbmsgdGhhdCBpcyBzdWl0YWJsZSBmb3Ig
dGhlIExTUC4NCj4NCj4gT3RoZXIgcXVlc3Rpb25zIGFib3V0IHJlYWNoYWJpbGl0eSBhbmQgVEUg
Y29ubmVjdGl2aXR5IGFjcm9zcyB0aGUgbmV4dCANCkFTDQo+IGFyZSBvdXQgb2Ygc2NvcGUgYW5k
IGhhdmUgYmVlbiBkZWZpbmVkIGFzIHByb2JsZW1zIHRoYXQgUENFIGlzIHVzZWQgdG8NCj4gc29s
dmUuIFRoaXMgaXMgYW4gaW1wb3J0YW50IHBvaW50ISBXZSBhcmUgbm90IHRhbGtpbmcgYWJvdXQg
ZGlzdHJpYnV0aW5nDQo+IGluZm9ybWF0aW9uIHRvIHByb3ZpZGUgYSBncmFwaCB0byBjb21wdXRl
IG11bHRpLUFTIFRFIHBhdGhzLiBUaGF0IGlzDQo+IChJTUhPKQ0KPiBvdXQgb2Ygc2NvcGUgYW5k
IHdoYXQgUENFIHdhcyBpbnZlbnRlZCB0byBzb2x2ZS4NCj4NCj4gSSBzZWUgdHdvIHNjZW5hcmlv
cy4NCj4gMS4gQW4gQVNCUiBoYXMgdHdvIGxpbmtzIHRvIHRoZSBuZXh0IEFTLg0KPiAyLiBBbiBB
UyBoYXMgdHdvIEFTQlJzIHRvIHRoZSBuZXh0IEFTLg0KPiBJbiBlaXRoZXIgY2FzZSwgdGhlIEFT
IG1heSBoYXZlIG11bHRpcGxlIEFTQlJzLg0KPg0KPiBUaGUgcGF0aCBjb21wdXRhdGlvbiBwb2lu
dCBtdXN0IGRldGVybWluZToNCj4gYS4gVGhlIHNldCBvZiBBU0JScyB0aGF0IGNvbm5lY3QgdG8g
dGhlIG5leHQgQVMuDQo+IGIuIFdoaWNoIEFTQlIgdG8gdXNlLg0KPiBjLiBXaGljaCBpbnRlci1B
UyBsaW5rIHRvIHVzZS4NCj4NCj4gU29tZSBjYXNlcyBhcmUgZWFzeToNCj4gLSBJZiB0aGUgRVJP
IGFscmVhZHkgaW5jbHVkZXMgdGhlIEFTQlIgYWRkcmVzcw0KPiAgbm8gY2hvaWNlIHRvIGJlIGRv
bmUNCj4gLSBJZiB0aGUgQVNCUiBoYXMgbXVsdGlwbGUgaW50ZXItQVMgbGlua3MgdGhlbg0KPiAg
dGhlIGNob2ljZSBjYW4gYmUgYSBsb2NhbCBtYXR0ZXIgKG5vDQo+ICBhZHZlcnRpc2luZyByZXF1
aXJlZCkNCj4NCj4gQnV0IG90aGVyIGNhc2VzIHJlcXVpcmUgYWR2ZXJ0aXNlbWVudCBvZiB0aGUg
aW50ZXItQVMgbGluayBhcyBhIFRFIGxpbmsNCj4gd2l0aDoNCj4gLSB0aGUgbm9ybWFsIFRFIGlu
Zm9ybWF0aW9uDQo+IC0gYW4gaW5kaWNhdGlvbiB0aGF0IHRoaXMgaXMgYW4gaW50ZXItQVMgbGlu
aw0KPiAtIHRoZSBpZGVudGl0eSBvZiB0aGUgcmVtb3RlIEFTQlINCj4gLSB0aGUgaWRlbnRpdHkg
b2YgdGhlIHJlbW90ZSBBUw0KPg0KPiBUaGlzIGluZm9ybWF0aW9uIGlzIG5lZWRlZCB0aHJvdWdo
LW91dCB0aGUgbG9jYWwgQVMuIFRoYXQgaXMsIGFsdGhvdWdoIA0KYWxsDQo+DQo+IG9mIHRoZSBB
U0JScyBtYXkgYmUgaW50ZXJlc3RlZCBmb3IgTFNQcyB0aGF0IGVudGlyZWx5IGNyb3NzIHRoZSBs
b2NhbCANCkFTLA0KPiBhbmQgYWx0aG91Z2ggYSBQQ0UgY291bGQgYmUgYSBCR1Agc3BlYWtlciwg
dGhlIGluZm9ybWF0aW9uIGlzIGFsc28gDQpuZWVkZWQNCj4gZm9yIExTUHMgdGhhdCBhcmUgb3Jp
Z2luYXRlZCB3aXRoaW4gdGhlIEFTLg0KPg0KPiBUaHVzIHdlIG11c3QgZGVjaWRlIGhvdyBwYXRo
cyBmb3IgTFNQcyB0aGF0IGV4aXQgdGhlIEFTIHdpbGwgYmUgDQpjb21wdXRlZDoNCj4NCj4gLSBJ
ZiB3ZSByZXF1aXJlIGNvbXB1dGF0aW9uIGJ5IGEgUENFIHRoYXQNCj4gIGlzIChzb21ld2hhdCkg
Y2VudHJhbGlzZWQgd2l0aGluIHRoZSBBUw0KPiAgd2UgY2FuIHVzZSBCR1AgdG8gZGlzdHJpYnV0
ZSB0aGUgaW5mb3JtYXRpb24NCj4gIGFuZCByZXF1aXJlIHRoYXQgdGhlIFBDRXMgYXJlIEJHUCBz
cGVha2Vycy4NCj4gIChOb3RlIHRoYXQgdGhlIGluZm9ybWF0aW9uIGlzIG9ubHkgbmVlZGVkDQo+
ICB3aXRoaW4gdGhlIGxvY2FsIEFTLCBzbyB3ZSB3b3VsZCBsaW1pdCBpdHMNCj4gIGZsb29kaW5n
IGJ5IEJHUC4pDQo+DQo+IC0gSWYgd2UgcmVxdWlyZSBjb21wdXRhdGlvbiBieSBhbnkgTFNSIGlu
DQo+ICB0aGUgQVMgKGkuZS4gUENFIGZ1bmN0aW9uIGlzIGZ1bGx5DQo+ICBkaXN0cmlidXRlZCkg
dGhlbiB3ZSByZXF1aXJlIElHUCBmbG9vZGluZw0KPiAgb2YgdGhlIGluZm9ybWF0aW9uIGFjcm9z
cyB0aGUgd2hvbGUgQVMuDQo+DQo+IEluIGJvdGggY2FzZXMgdGhlIGNvc3QgaXMgbm90IHBhcnRp
Y3VsYXJseSBoaWdoIHNpbmNlIHRoZSBudW1iZXIgb2YNCj4gaW50ZXItQVMNCj4gVEUgbGlua3Mg
d2lsbCBub3QgYmUgbGFyZ2UuDQo+DQo+IFRoYW5rcywNCj4gQWRyaWFuDQo+DQo+IC0tLS0tIE9y
aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206ICJaaGFuZ1JlbmhhaSIgPHpoYW5ncmVuaGFp
QGh1YXdlaS5jb20+DQo+IFRvOiAiJ0pQIFZhc3NldXInIiA8anZhc3NldXJAY2lzY28uY29tPjsg
IidNYWNoIENoZW4nIiA8bWFjaEBodWF3ZWkuY29tPg0KPiBDYzogPGNjYW1wQG9wcy5pZXRmLm9y
Zz47IDxvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc+DQo+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFy
eSAxNywgMjAwNyA0OjExIEFNDQo+IFN1YmplY3Q6ILTwuLQ6IFByb2dyZXNzaW5nIHRoZSB0aHJl
ZSBpbnRlci1kb21haW4gSS1Ecw0KPg0KPg0KPj4+ID4gQWZ0ZXIgcmVhZGluZyB0aGVzZSBkb2Nz
IEkgYWxzbyBoYXZlIHRoZSBzYW1lIGNvbmNlcm4gd2l0aCB5b3UNCj4+PiA+IGFib3V0IGludGVy
LUFTQlIgbGlua3MgZmxvb2RpbmcuDQo+Pj4gPiBJIHRoaW5rLCBpbiBvZGVyIHRvIHBlcmZvcm0g
IGludGVyLUFTIHBhdGggY29tcHV0YXRpb24sIGludGVyLUFTQlINCj4+PiA+IGxpbmtzIGZvb2Rp
bmcgaXMgZGVzaXJlZC4NCj4+Pg0KPj4+IEFzIHBvaW50ZWQgb3V0IGluIHRoZSBkb2N1bWVudCwg
dGhpcyBpcyBub3QgYSBNVVNULCBidXQgYW4NCj4gb3B0aW1pemF0aW9uLg0KPj4+DQo+Pj4gPiBC
dXQNCj4+PiA+IHN1Y2gga2luZCBvZiBpbnRlci1BU0JSIGxpbmsgaW5mbyBzaG91bGQgaW5jbHVk
ZSBtb3JlIGluZm9ybWF0aW9uDQo+Pj4gPiB0aGFuICJub3JtYWwiIFRFIGxpbmtzIGRvLA0KPj4+
ID4gZS5nOiB0aGUgaW50ZXItQVNCUiBsaW5rcyBpbmZvIFNIT1VMRCBzdGlsbCBpbmNsdWRlIHRo
ZSBwZWVyIEFTDQo+Pj4gPiBudW1iZXIgYW5kIHBlZXIgQVNCUiByb3V0ZXIgaWQNCj4+PiA+IGJl
c2lkZXMgdGhvc2UgbGluayBpbmZvIHdoaWNoIGhhcyBiZWVuIHNwZWNpZmllZCBpbiByZmMzNjMw
IGFuZA0KPj4+ID4gcmZjMzc4NC4NCj4+Pg0KPj4+IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgcGVl
ciBBUyBudW1iZXIgaW5mbyBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlDQo+Pj4gSUdQIGZvciBz
dXJlLiBZb3Ugc2hvdWxkIHJlbHkgb24gQkdQIGZvciB0aGF0IHB1cnBvc2UuDQo+PiBbWmhhbmdS
ZW5oYWk+XSBtYXliZSBCR1AgaXMgbm90IGVub3VnaCBmb3Igc29tZSBjaXJjdW1zdGFuY2UsIHRh
a2UgdGhpcw0KPj4gc2NlbmFyaW8gZm9yIGV4YW1wbGU6DQo+Pg0KPj4gICAgICAgICAgICAgICAg
ICAgICAvICBBU0JSNA0KPj4gQVNCUjEtLS0tLS0tLUFTQlIyLS0NCj4+ICAgICAgICAgICAgICAg
ICAgICBcICBBU0JSMw0KPj4gLS0tLS0tQVMgMS0tLS0tLS0tLS18fC0tLS0tQVMgMi0tLS0tLS0t
LS0NCj4+DQo+PiBBU0JSMiBpbiBBUyAxIHdvdWxkIG9ubHkgYWR2ZXJ0aXNlIHRoZSBvcHRpbWFs
IHJvdXRlIHJlY2VpdmVkDQo+IHJlc3BlY3RpdmVseQ0KPj4gZnJvbSBBU0JSMyBhbmQgQVNCUjQg
KGJvdGggYXJlIGZyb20gQVMgMikgdG8gQVNCUjEsIEFTQlIxIGFsc28gZG9lc24ndA0KPj4gaGF2
ZQ0KPj4gdGhlIGZ1bGwga25vd2xlZGdlIG9mIHRvcG9sb2d5KHN1Y2ggYXMgd2hpY2ggQVMgdGhl
IEFTQlIyIGlzIGNvbm5lY3RlZA0KPiB0bw0KPj4gYW5kIHdoaWNoIHJvdXRlciBpcyBpbiB0aGF0
IEFTKWJldHdlZW4gdGhlIHR3byBBUy4gUENFIHdvdWxkIGhhdmUgdGhlDQo+PiBzaW1pbGFyIHBy
b2JsZW0gd2hlbiBwZXJmb3JtaW5nIHRoZSBicnBjLg0KPj4gQW5vdGhlciBpc3N1ZSwgd2hlbiBB
U0JSMSByZWNlaXZlcyBhIHBhdGggbWVzZyBmcm9tIHVwc3RyZWFtIGRvbWFpbg0KPj4gY29udGFp
bmluZyBhIGxvb3NlIEVSTzpBUyBudW1iZXIoc2F5IEFTMiksIHRoZXJlIHNob3VsZCBiZSBhIG1l
dGhvZCBmb3INCj4gaXQNCj4+IHRvIGxvY2F0ZSB0aGUgYXNicihzYXkgQVNCUjIpIGluIHRoZSBs
b2NhbCBkb21haW4gY29ubmVjdGVkIHRvIEFTMi4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gWmhhbmcg
UmVuaGFpDQo+Pg0KPj4+DQo+Pj4gPg0KPj4+ID4gU28gSSB0aGluayB0aGVyZSBuZWVkIGEgZG9j
dW1lbnQgdG8gY2xhcmlmeSBhbmQgc3BlY2lmeSBpbnRlci1BU0JSDQo+Pj4gPiBsaW5rcyBmbG9v
ZGluZy4gd2UgYXJlIGNvbnNpZGVyaW5nIHRvDQo+Pj4gPiB3cml0ZSBzdWNoIGEgZG9jdW1lbnQu
IElmIHNvbWVvbmUgaW50ZXJlc3RlZCBpbiBzdWNoIHdvcmssIHdlIGNvdWxkDQo+Pj4gPiBjb29w
ZXJhdGUuDQo+Pj4gPg0KPj4+DQo+Pj4gSlAuDQo+Pj4NCj4+PiA+DQo+Pg0KPj4NCj4+DQo+Pg0K
Pj4NCj4+DQo+DQo+DQo+DQo+DQo+DQo+IA0KDQoNCg0KDQoNCg==



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 20:50:53 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-07.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 20:06:07 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: March Meeting Reminders
Date: Wed, 17 Jan 2007 14:03:17 -0600
Message-ID: <[e-mail]>
Thread-Topic: March Meeting Reminders
Thread-Index: Acc4xfMYujq2cTJxTgugJtmDtl/KAwBq3ldg
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>

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:[e-mail]]=20
Sent: Monday, January 15, 2007 11:51 AM
To: IETF Announcement list
Cc: [e-mail]
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 12:15:42 +0000
Message-ID: <05ae01c73a31$2a20f540$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Advertising of inter-AS TE links
Date: Wed, 17 Jan 2007 12:15:07 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="GB2312"; reply-type=original
Content-Transfer-Encoding: 8bit

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: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; "'JP Vasseur'" <[e-mail]>; "'Mach Chen'" 
<[e-mail]>; <[e-mail]>; "ZhangRenhai" 
<[e-mail]>
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" <[e-mail]>
> Sent by: [e-mail]
> 17/01/2007 12:00
> Please respond to "Adrian Farrel"
>
>        To:     "ZhangRenhai" <[e-mail]>, "'JP Vasseur'"
> <[e-mail]>, "'Mach Chen'" <[e-mail]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     <[e-mail]>
>        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" <[e-mail]>
> To: "'JP Vasseur'" <[e-mail]>; "'Mach Chen'" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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.
>>>
>>> >
>>
>>
>>
>>
>>
>>
>
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 12:13:13 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: "'Mach Chen'" <[e-mail]>, [e-mail], [e-mail]
Content-Transfer-Encoding: 7bit
From: JP Vasseur <[e-mail]>
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 <[e-mail]>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2267; t=1169035936; x=1169899936; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20JP=20Vasseur=20<[e-mail]> |Subject:=20=3D?UTF-8?Q?Re=3A_=3DE7=3DAD=3D94=3DE5=3DA4=3D8D=3A_Progressi ng_the_three_inter-do?=3D=0A=20=3D?UTF-8?Q?main_I-Ds?=3D |Sender:=20 |To:=20ZhangRenhai=20<[e-mail]>; bh=AhUOcXGQwYNMnTESjzmd1S5hfypxFrJYzW84iIzQhBg=; b=Z6V6MRyd22Sfmfx/rg1gaS/CETrNJ5KCDHG9sgeIQWzQHDQfy+wyESMTZEUf5taGXfirAhDV 8XIc2bPPk30UMZemMU/ym8hkxjCQ5km02b7WEb48guTHLTBqfFf9DkA1;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );

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



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 11:27:17 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], "'JP Vasseur'" <[e-mail]>, "'Mach Chen'" <[e-mail]>, [e-mail], "ZhangRenhai" <[e-mail]>
Subject: Re: Advertising of inter-AS TE links
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 17 Jan 2007 12:26:41 +0100
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

YWRyaWFuDQoNCmFncmVlZCBvbiB0aGUgYW5hbHlzaXMgLSB0aGVyZSBpcyBvbmUgYWRkaXRpb25h
bCBjYXNlIHRoYXQgDQpuZWVkcyB0byBiZSBhZGRyZXNzZWQNCg0KQVNfMSBpcyBjb25uZWN0ZWQg
dG8gQVNfMiBhbmQgQVNfMyBib3RoIGNvbm5lY3RlZCB0byBBU180DQoNCnRoZSBFUk8sIGluY2x1
ZGVzIEFTXzEgYW5kIEFTXzQsIHBlcmZlY3RseSBjbGVhciB0aGVyZSBpcw0Kbm8gaW50ZW50aW9u
IHRvIHBhc3MgQVNfMiAtIEFTXzQgYW5kIEFTXzMgLSBBU180IFRFIGxpbmsNCmluZm9ybWF0aW9u
IHRvIEFTXzENCg0KYnV0IHdoYXQgYWJvdXQgQVNfMSAtIEFTXzIgYW5kIEFTXzEgLSBBU18zIHdo
b3NlIGluZm8uIGlzDQpkZWZhY3RvIGF2YWlsYWJsZSANCg0KdGhlIGlzc3VlIGlzIG9uZSBzZW50
ZW5jZSwgdGhlIGluaXRpYWwgbGluZWFyaXphdGlvbiBkb2VzDQpub3QgaG9sZCBpbiB0aGUgZ2Vu
ZXJpYyBjYXNlIG9mIGxvb3NlIGFic3RyYWN0IEFTJ3MNCg0KY29tbWVudHMgPw0KDQotZC4NCg0K
DQoNCg0KDQoiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQpTZW50IGJ5OiBv
d25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNCjE3LzAxLzIwMDcgMTI6MDANClBsZWFzZSByZXNwb25k
IHRvICJBZHJpYW4gRmFycmVsIg0KIA0KICAgICAgICBUbzogICAgICJaaGFuZ1JlbmhhaSIgPHpo
YW5ncmVuaGFpQGh1YXdlaS5jb20+LCAiJ0pQIFZhc3NldXInIiANCjxqdmFzc2V1ckBjaXNjby5j
b20+LCAiJ01hY2ggQ2hlbiciIDxtYWNoQGh1YXdlaS5jb20+LCBEaW1pdHJpIA0KUEFQQURJTUlU
UklPVS9CRS9BTENBVEVMQEFMQ0FURUwNCiAgICAgICAgY2M6ICAgICA8Y2NhbXBAb3BzLmlldGYu
b3JnPg0KICAgICAgICBTdWJqZWN0OiAgICAgICAgQWR2ZXJ0aXNpbmcgb2YgaW50ZXItQVMgVEUg
bGlua3MNCg0KDQpIaSwNCg0KU2luY2UgdGhpcyBkaXNjdXNzaW9uIGlzIGJsb3Nzb21pbmcsIGl0
IGNhbiBoYXZlIGl0cyBvd24gdGhyZWFkLi4uDQoNCkknZCBsaWtlIHRvIHRyeSB0byBicmluZyBz
b21lIGZvY3VzLg0KDQpUaGUgbW90aXZhdGlvbiBzZWVtcyBjbGVhci4uLg0KV2hlbiBjb21wdXRp
bmcgYSBwYXRoIHRocm91Z2ggb25lIEFTIGludG8gYW5vdGhlciBBUywgdGhlIGNvbXB1dGF0aW9u
IA0KcG9pbnQgDQpuZWVkcyB0byBrbm93IGFib3V0IFRFIGxpbmtzIHRoYXQgY29ubmVjdCB0byB0
aGUgbmV4dCBBUy4gVGhpcyBlbmFibGVzIGl0IA0KdG8gDQpzZWxlY3Q6DQotIEEgVEUgbGluayB0
aGF0IGNvbm5lY3RzIHRvIHRoZSBuZXh0IEFTDQotIEEgVEUgbGluayB0aGF0IGlzIHN1aXRhYmxl
IGZvciB0aGUgTFNQLg0KDQpPdGhlciBxdWVzdGlvbnMgYWJvdXQgcmVhY2hhYmlsaXR5IGFuZCBU
RSBjb25uZWN0aXZpdHkgYWNyb3NzIHRoZSBuZXh0IEFTIA0KYXJlIG91dCBvZiBzY29wZSBhbmQg
aGF2ZSBiZWVuIGRlZmluZWQgYXMgcHJvYmxlbXMgdGhhdCBQQ0UgaXMgdXNlZCB0byANCnNvbHZl
LiBUaGlzIGlzIGFuIGltcG9ydGFudCBwb2ludCEgV2UgYXJlIG5vdCB0YWxraW5nIGFib3V0IGRp
c3RyaWJ1dGluZyANCmluZm9ybWF0aW9uIHRvIHByb3ZpZGUgYSBncmFwaCB0byBjb21wdXRlIG11
bHRpLUFTIFRFIHBhdGhzLiBUaGF0IGlzIA0KKElNSE8pIA0Kb3V0IG9mIHNjb3BlIGFuZCB3aGF0
IFBDRSB3YXMgaW52ZW50ZWQgdG8gc29sdmUuDQoNCkkgc2VlIHR3byBzY2VuYXJpb3MuDQoxLiBB
biBBU0JSIGhhcyB0d28gbGlua3MgdG8gdGhlIG5leHQgQVMuDQoyLiBBbiBBUyBoYXMgdHdvIEFT
QlJzIHRvIHRoZSBuZXh0IEFTLg0KSW4gZWl0aGVyIGNhc2UsIHRoZSBBUyBtYXkgaGF2ZSBtdWx0
aXBsZSBBU0JScy4NCg0KVGhlIHBhdGggY29tcHV0YXRpb24gcG9pbnQgbXVzdCBkZXRlcm1pbmU6
DQphLiBUaGUgc2V0IG9mIEFTQlJzIHRoYXQgY29ubmVjdCB0byB0aGUgbmV4dCBBUy4NCmIuIFdo
aWNoIEFTQlIgdG8gdXNlLg0KYy4gV2hpY2ggaW50ZXItQVMgbGluayB0byB1c2UuDQoNClNvbWUg
Y2FzZXMgYXJlIGVhc3k6DQotIElmIHRoZSBFUk8gYWxyZWFkeSBpbmNsdWRlcyB0aGUgQVNCUiBh
ZGRyZXNzDQogIG5vIGNob2ljZSB0byBiZSBkb25lDQotIElmIHRoZSBBU0JSIGhhcyBtdWx0aXBs
ZSBpbnRlci1BUyBsaW5rcyB0aGVuDQogIHRoZSBjaG9pY2UgY2FuIGJlIGEgbG9jYWwgbWF0dGVy
IChubw0KICBhZHZlcnRpc2luZyByZXF1aXJlZCkNCg0KQnV0IG90aGVyIGNhc2VzIHJlcXVpcmUg
YWR2ZXJ0aXNlbWVudCBvZiB0aGUgaW50ZXItQVMgbGluayBhcyBhIFRFIGxpbmsgDQp3aXRoOg0K
LSB0aGUgbm9ybWFsIFRFIGluZm9ybWF0aW9uDQotIGFuIGluZGljYXRpb24gdGhhdCB0aGlzIGlz
IGFuIGludGVyLUFTIGxpbmsNCi0gdGhlIGlkZW50aXR5IG9mIHRoZSByZW1vdGUgQVNCUg0KLSB0
aGUgaWRlbnRpdHkgb2YgdGhlIHJlbW90ZSBBUw0KDQpUaGlzIGluZm9ybWF0aW9uIGlzIG5lZWRl
ZCB0aHJvdWdoLW91dCB0aGUgbG9jYWwgQVMuIFRoYXQgaXMsIGFsdGhvdWdoIGFsbCANCg0Kb2Yg
dGhlIEFTQlJzIG1heSBiZSBpbnRlcmVzdGVkIGZvciBMU1BzIHRoYXQgZW50aXJlbHkgY3Jvc3Mg
dGhlIGxvY2FsIEFTLCANCmFuZCBhbHRob3VnaCBhIFBDRSBjb3VsZCBiZSBhIEJHUCBzcGVha2Vy
LCB0aGUgaW5mb3JtYXRpb24gaXMgYWxzbyBuZWVkZWQgDQpmb3IgTFNQcyB0aGF0IGFyZSBvcmln
aW5hdGVkIHdpdGhpbiB0aGUgQVMuDQoNClRodXMgd2UgbXVzdCBkZWNpZGUgaG93IHBhdGhzIGZv
ciBMU1BzIHRoYXQgZXhpdCB0aGUgQVMgd2lsbCBiZSBjb21wdXRlZDoNCg0KLSBJZiB3ZSByZXF1
aXJlIGNvbXB1dGF0aW9uIGJ5IGEgUENFIHRoYXQNCiAgaXMgKHNvbWV3aGF0KSBjZW50cmFsaXNl
ZCB3aXRoaW4gdGhlIEFTDQogIHdlIGNhbiB1c2UgQkdQIHRvIGRpc3RyaWJ1dGUgdGhlIGluZm9y
bWF0aW9uDQogIGFuZCByZXF1aXJlIHRoYXQgdGhlIFBDRXMgYXJlIEJHUCBzcGVha2Vycy4NCiAg
KE5vdGUgdGhhdCB0aGUgaW5mb3JtYXRpb24gaXMgb25seSBuZWVkZWQNCiAgd2l0aGluIHRoZSBs
b2NhbCBBUywgc28gd2Ugd291bGQgbGltaXQgaXRzDQogIGZsb29kaW5nIGJ5IEJHUC4pDQoNCi0g
SWYgd2UgcmVxdWlyZSBjb21wdXRhdGlvbiBieSBhbnkgTFNSIGluDQogIHRoZSBBUyAoaS5lLiBQ
Q0UgZnVuY3Rpb24gaXMgZnVsbHkNCiAgZGlzdHJpYnV0ZWQpIHRoZW4gd2UgcmVxdWlyZSBJR1Ag
Zmxvb2RpbmcNCiAgb2YgdGhlIGluZm9ybWF0aW9uIGFjcm9zcyB0aGUgd2hvbGUgQVMuDQoNCklu
IGJvdGggY2FzZXMgdGhlIGNvc3QgaXMgbm90IHBhcnRpY3VsYXJseSBoaWdoIHNpbmNlIHRoZSBu
dW1iZXIgb2YgDQppbnRlci1BUyANClRFIGxpbmtzIHdpbGwgbm90IGJlIGxhcmdlLg0KDQpUaGFu
a3MsDQpBZHJpYW4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJaaGFu
Z1JlbmhhaSIgPHpoYW5ncmVuaGFpQGh1YXdlaS5jb20+DQpUbzogIidKUCBWYXNzZXVyJyIgPGp2
YXNzZXVyQGNpc2NvLmNvbT47ICInTWFjaCBDaGVuJyIgPG1hY2hAaHVhd2VpLmNvbT4NCkNjOiA8
Y2NhbXBAb3BzLmlldGYub3JnPjsgPG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZz4NClNlbnQ6IFdl
ZG5lc2RheSwgSmFudWFyeSAxNywgMjAwNyA0OjExIEFNDQpTdWJqZWN0OiC08Li0OiBQcm9ncmVz
c2luZyB0aGUgdGhyZWUgaW50ZXItZG9tYWluIEktRHMNCg0KDQo+PiA+IEFmdGVyIHJlYWRpbmcg
dGhlc2UgZG9jcyBJIGFsc28gaGF2ZSB0aGUgc2FtZSBjb25jZXJuIHdpdGggeW91DQo+PiA+IGFi
b3V0IGludGVyLUFTQlIgbGlua3MgZmxvb2RpbmcuDQo+PiA+IEkgdGhpbmssIGluIG9kZXIgdG8g
cGVyZm9ybSAgaW50ZXItQVMgcGF0aCBjb21wdXRhdGlvbiwgaW50ZXItQVNCUg0KPj4gPiBsaW5r
cyBmb29kaW5nIGlzIGRlc2lyZWQuDQo+Pg0KPj4gQXMgcG9pbnRlZCBvdXQgaW4gdGhlIGRvY3Vt
ZW50LCB0aGlzIGlzIG5vdCBhIE1VU1QsIGJ1dCBhbiANCm9wdGltaXphdGlvbi4NCj4+DQo+PiA+
IEJ1dA0KPj4gPiBzdWNoIGtpbmQgb2YgaW50ZXItQVNCUiBsaW5rIGluZm8gc2hvdWxkIGluY2x1
ZGUgbW9yZSBpbmZvcm1hdGlvbg0KPj4gPiB0aGFuICJub3JtYWwiIFRFIGxpbmtzIGRvLA0KPj4g
PiBlLmc6IHRoZSBpbnRlci1BU0JSIGxpbmtzIGluZm8gU0hPVUxEIHN0aWxsIGluY2x1ZGUgdGhl
IHBlZXIgQVMNCj4+ID4gbnVtYmVyIGFuZCBwZWVyIEFTQlIgcm91dGVyIGlkDQo+PiA+IGJlc2lk
ZXMgdGhvc2UgbGluayBpbmZvIHdoaWNoIGhhcyBiZWVuIHNwZWNpZmllZCBpbiByZmMzNjMwIGFu
ZA0KPj4gPiByZmMzNzg0Lg0KPj4NCj4+IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgcGVlciBBUyBu
dW1iZXIgaW5mbyBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlDQo+PiBJR1AgZm9yIHN1cmUuIFlv
dSBzaG91bGQgcmVseSBvbiBCR1AgZm9yIHRoYXQgcHVycG9zZS4NCj4gW1poYW5nUmVuaGFpPl0g
bWF5YmUgQkdQIGlzIG5vdCBlbm91Z2ggZm9yIHNvbWUgY2lyY3Vtc3RhbmNlLCB0YWtlIHRoaXMN
Cj4gc2NlbmFyaW8gZm9yIGV4YW1wbGU6DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgLyAgQVNC
UjQNCj4gQVNCUjEtLS0tLS0tLUFTQlIyLS0NCj4gICAgICAgICAgICAgICAgICAgIFwgIEFTQlIz
DQo+IC0tLS0tLUFTIDEtLS0tLS0tLS0tfHwtLS0tLUFTIDItLS0tLS0tLS0tDQo+DQo+IEFTQlIy
IGluIEFTIDEgd291bGQgb25seSBhZHZlcnRpc2UgdGhlIG9wdGltYWwgcm91dGUgcmVjZWl2ZWQg
DQpyZXNwZWN0aXZlbHkNCj4gZnJvbSBBU0JSMyBhbmQgQVNCUjQgKGJvdGggYXJlIGZyb20gQVMg
MikgdG8gQVNCUjEsIEFTQlIxIGFsc28gZG9lc24ndCANCj4gaGF2ZQ0KPiB0aGUgZnVsbCBrbm93
bGVkZ2Ugb2YgdG9wb2xvZ3koc3VjaCBhcyB3aGljaCBBUyB0aGUgQVNCUjIgaXMgY29ubmVjdGVk
IA0KdG8NCj4gYW5kIHdoaWNoIHJvdXRlciBpcyBpbiB0aGF0IEFTKWJldHdlZW4gdGhlIHR3byBB
Uy4gUENFIHdvdWxkIGhhdmUgdGhlDQo+IHNpbWlsYXIgcHJvYmxlbSB3aGVuIHBlcmZvcm1pbmcg
dGhlIGJycGMuDQo+IEFub3RoZXIgaXNzdWUsIHdoZW4gQVNCUjEgcmVjZWl2ZXMgYSBwYXRoIG1l
c2cgZnJvbSB1cHN0cmVhbSBkb21haW4NCj4gY29udGFpbmluZyBhIGxvb3NlIEVSTzpBUyBudW1i
ZXIoc2F5IEFTMiksIHRoZXJlIHNob3VsZCBiZSBhIG1ldGhvZCBmb3IgDQppdA0KPiB0byBsb2Nh
dGUgdGhlIGFzYnIoc2F5IEFTQlIyKSBpbiB0aGUgbG9jYWwgZG9tYWluIGNvbm5lY3RlZCB0byBB
UzIuDQo+DQo+IFJlZ2FyZHMsDQo+IFpoYW5nIFJlbmhhaQ0KPg0KPj4NCj4+ID4NCj4+ID4gU28g
SSB0aGluayB0aGVyZSBuZWVkIGEgZG9jdW1lbnQgdG8gY2xhcmlmeSBhbmQgc3BlY2lmeSBpbnRl
ci1BU0JSDQo+PiA+IGxpbmtzIGZsb29kaW5nLiB3ZSBhcmUgY29uc2lkZXJpbmcgdG8NCj4+ID4g
d3JpdGUgc3VjaCBhIGRvY3VtZW50LiBJZiBzb21lb25lIGludGVyZXN0ZWQgaW4gc3VjaCB3b3Jr
LCB3ZSBjb3VsZA0KPj4gPiBjb29wZXJhdGUuDQo+PiA+DQo+Pg0KPj4gSlAuDQo+Pg0KPj4gPg0K
Pg0KPg0KPg0KPg0KPg0KPiANCg0KDQoNCg0KDQo=



Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 11:03:54 +0000
Message-ID: <058301c73a26$ca1bdb60$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "ZhangRenhai" <[e-mail]>, "'JP Vasseur'" <[e-mail]>, "'Mach Chen'" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: <[e-mail]>
Subject: Advertising of inter-AS TE links
Date: Wed, 17 Jan 2007 11:00:53 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="GB2312"; reply-type=original
Content-Transfer-Encoding: 8bit

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" <[e-mail]>
To: "'JP Vasseur'" <[e-mail]>; "'Mach Chen'" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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.
>>
>> >
>
>
>
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 04:16:36 +0000
Date: Wed, 17 Jan 2007 12:11:19 +0800
From: ZhangRenhai <[e-mail]>
Subject: =?gb2312?B?tPC4tDogUHJvZ3Jlc3NpbmcgdGhlIHRocmVlIGludGVyLWRvbWFpbiBJLURz?=
To: 'JP Vasseur' <[e-mail]>, 'Mach Chen' <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <000801c739ed$8d73aff0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT
Thread-index: Acc5fdDKQGIq/sG+SKqqAnp0WtzQRAAbFW2w

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






Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 00:45:48 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Progressing the three inter-domain I-Ds
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 17 Jan 2007 01:45:11 +0100
Content-Type: text/plain; charset="US-ASCII"

hi adrian - see inline for a couple of clarifications




"Adrian Farrel" <[e-mail]>
Sent by: [e-mail]
16/01/2007 15:11
Please respond to "Adrian Farrel"
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[e-mail]>
        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 








Envelope-to: [e-mail]
Delivery-date: Wed, 17 Jan 2007 00:24:39 +0000
To: JP Vasseur <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Progressing the three inter-domain I-Ds
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 17 Jan 2007 01:21:34 +0100
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

hi j-p - see inline:





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

[e-mail]
        Subject:        Re: Progressing the three inter-domain I-Ds


Hi Dimitri,

On Jan 13, 2007, at 6:49 AM, [e-mail]=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" <[e-mail]>
> Sent by: [e-mail]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[e-mail]>
>         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
>
>
>
>






Envelope-to: [e-mail]
Delivery-date: Tue, 16 Jan 2007 19:40:14 +0000
Message-ID: <049601c739a5$c90280c0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Derek Atkins" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06
Date: Tue, 16 Jan 2007 19:36:34 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

OK

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

Thanks for engaging.

Adrian
----- Original Message ----- 
From: "Derek Atkins" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
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" <[e-mail]> 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" <[e-mail]>
>> To: "Adrian Farrel" <[e-mail]>
>> Cc: <[e-mail]>; <[e-mail]>;
>> <[e-mail]>; <[e-mail]>; <[e-mail]>;
>> <[e-mail]>; <[e-mail]>; 
>> <[e-mail]>;
>> <[e-mail]>; <[e-mail]>
>> 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" <[e-mail]> 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" <[e-mail]>
>>>> To: <[e-mail]>; <[e-mail]>
>>>> Cc: <[e-mail]>; <[e-mail]>;
>>>> <[e-mail]>; <[e-mail]>;
>>>> <[e-mail]>;
>>>> <[e-mail]>; <[e-mail]>
>>>> 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
>       [e-mail]             www.ihtfp.com
>       Computer and Internet Security Consultant
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Jan 2007 14:54:14 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Peng He <[e-mail]>, [e-mail], Adrian Farrel <[e-mail]>, [e-mail], [e-mail]
Content-Transfer-Encoding: quoted-printable
From: JP Vasseur <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 09:53:37 -0500
To: Mach Chen <[e-mail]>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9538; t=1168959221; x=1169823221; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20JP=20Vasseur=20<[e-mail]> |Subject:=20Re=3A=20Progressing=20the=20three=20inter-domain=20I-Ds |Sender:=20; bh=tXK0AtMqMsdov+o9jP97QEowdqcm85ZBZ/L9j6q0BFU=; b=abBR4KhQqfT/3KipGezQGmOBdEzuZDQoI8NZCUn47KHi45LlrAU+QorlQCauwypWO9heYwkJ Ro2wKIX0TlleM9qXu/gaecxwrFd+G5fEPyEfjCwhv1lDTfL/gVUxIaRZ;
Authentication-Results: sj-dkim-7; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim7002 verified; );

Hi Mach,

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

> Hi Peng,
>
>> ----- Original Message -----
>> From: "Peng He" <[e-mail]>
>> To: "Mach Chen" <[e-mail]>
>> Cc: <[e-mail]>; "Adrian Farrel" =20
>> <[e-mail]>; <[e-mail]>; <owner-=20
>> [e-mail]>
>> 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 <[e-mail]> 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" <[e-mail]>
>> To: "Mach Chen" <[e-mail]>
>> Cc: <[e-mail]>; "Adrian Farrel" =20
>> <[e-mail]>; <[e-mail]>; <owner-=20
>> [e-mail]>
>> 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 <[e-mail]> 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: <[e-mail]>
>>> To: "Adrian Farrel" <[e-mail]>
>>> Cc: <[e-mail]>; <[e-mail]>
>>> 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" <[e-mail]>
>>> Sent by: [e-mail]
>>> 09/01/2007 23:13
>>> Please respond to "Adrian Farrel"
>>>
>>>         To:     <[e-mail]>
>>>         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
>



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Jan 2007 14:50:54 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail], Adrian Farrel <[e-mail]>, [e-mail], [e-mail]
Content-Transfer-Encoding: quoted-printable
From: JP Vasseur <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 09:50:38 -0500
To: Mach Chen <[e-mail]>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5953; t=1168959041; x=1169823041; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20JP=20Vasseur=20<[e-mail]> |Subject:=20Re=3A=20Progressing=20the=20three=20inter-domain=20I-Ds |Sender:=20 |To:=20Mach=20Chen=20<[e-mail]>; bh=m2XP/JgAdW7bnJr/Bq876s5PzsuyaFa7CIVq9IjZR7Q=; b=camkk0DuKaR8dfyFhVgOQ2uFyCp3fH0n1zn29JqxgjY0Kk2ra2oy+V45dSvXDXMUua75cz6I TtUizsbUoCpmKfpYD/v1UKS8M3Sr1mXvN8k4oc9HcUZh7ezTXPVaa86B;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );

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: <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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" <[e-mail]>
> Sent by: [e-mail]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[e-mail]>
>         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
>
>
>
>
>
>



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Jan 2007 14:48:42 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Adrian Farrel" <[e-mail]>, [e-mail], [e-mail]
Content-Transfer-Encoding: quoted-printable
From: JP Vasseur <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 09:48:24 -0500
To: Peng He <[e-mail]>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7158; t=1168958908; x=1169822908; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20JP=20Vasseur=20<[e-mail]> |Subject:=20Re=3A=20Progressing=20the=20three=20inter-domain=20I-Ds |Sender:=20 |To:=20Peng=20He=20<[e-mail]>; bh=aUUGq/IN1Mox0c6E+7QUPuYapCDK08i6HWxw/rhq8Hw=; b=MzAaOpunDhPPbI3d5XJSdaYwNC3CQU/LeTnZ4E0wMcMoX8QErELhW8nRgP/swZlQYaU92Lb5 rZCqfDVmtBDHZL1EHADmIzcQ/voh8S8J4+Xt2BNVIrT7IFO7yCvYZjIq;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );

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, [e-mail]
> <[e-mail]> 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" <[e-mail]>
>> Sent by: [e-mail]
>> 09/01/2007 23:13
>> Please respond to "Adrian Farrel"
>>
>>         To:     <[e-mail]>
>>         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
>>
>>
>>
>>
>>
>>
>>



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Jan 2007 14:43:36 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, [e-mail], [e-mail]
Content-Transfer-Encoding: quoted-printable
From: JP Vasseur <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 09:42:57 -0500
To: [e-mail]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5674; t=1168958588; x=1169822588; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20JP=20Vasseur=20<[e-mail]> |Subject:=20Re=3A=20Progressing=20the=20three=20inter-domain=20I-Ds |Sender:=20; bh=jIKymHp1HTOKD6VHFmG0c+5fwHlmj1w4XyzqWp+UGgQ=; b=AFaOwkU6tDPaxgJA/mUK5m5L6p7Pd20vGLk7U2T8f0z6zdHfg97ZoTY6aba7NptPbqfZQ5z6 BaE43cwIEmDHirts8ljIv3hyxEQ1Jm1dVG1/Aq56WEIR9egJtwRc3Ysz;
Authentication-Results: sj-dkim-6; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim6002 verified; );

Hi Dimitri,

On Jan 13, 2007, at 6:49 AM, [e-mail] =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" <[e-mail]>
> Sent by: [e-mail]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[e-mail]>
>         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
>
>
>
>



Envelope-to: [e-mail]
Delivery-date: Tue, 16 Jan 2007 14:32:32 +0000
Message-ID: <03b901c7397a$b9fa7220$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
Date: Tue, 16 Jan 2007 14:11:33 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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 





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Jan 2007 14:32:27 +0000
Message-ID: <03b801c7397a$b1ae1e00$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Derek Atkins" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06
Date: Tue, 16 Jan 2007 14:03:23 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
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" <[e-mail]> 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" <[e-mail]>
>> To: <[e-mail]>; <[e-mail]>
>> Cc: <[e-mail]>; <[e-mail]>;
>> <[e-mail]>; <[e-mail]>; 
>> <[e-mail]>;
>> <[e-mail]>; <[e-mail]>
>> 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
>>>       [e-mail]             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
>       [e-mail]                        PGP key available
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Jan 2007 04:17:07 +0000
Date: Tue, 16 Jan 2007 12:16:12 +0800
From: Mach Chen <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
To: Peng He <[e-mail]>
Cc: [e-mail], Adrian Farrel <[e-mail]>, [e-mail], [e-mail]
Message-id: <01dd01c73925$0f14c0e0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64

SGkgUGVuZywNCg0KPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+RnJvbTogIlBlbmcg
SGUiIDxwZW5nLmhlLjIwMDBAZ21haWwuY29tPg0KPlRvOiAiTWFjaCBDaGVuIiA8bWFjaEBodWF3
ZWkuY29tPg0KPkNjOiA8RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwtbHVjZW50LmJlPjsg
IkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPjsgPGNjYW1wQG9wcy5pZXRmLm9y
Zz47IDxvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc+DQo+U2VudDogVHVlc2RheSwgSmFudWFyeSAx
NiwgMjAwNyAxMToxNyBBTQ0KPlN1YmplY3Q6IFJlOiBQcm9ncmVzc2luZyB0aGUgdGhyZWUgaW50
ZXItZG9tYWluIEktRHMNCg0KDQo+SGVsbG8gTWFjaCwNCg0KPkkgdW5kZXJzdG9vZCB0aGF0IHRo
ZSBwYXRoIGNvbXB1dGUgZWxlbWVudChIZWFkLWVuZCwgQVNCUiwgb3IgUENFKQ0KPnNob3VsZCAg
aGF2ZSB0aGUgaW50ZXItQVNCUiBsaW5rcyBpbmZvIHRvIGNvbXB1dGUgYW4gb3B0aW1hbCBvcg0K
Pm5lYXItb3B0aW1hbCBpbnRlci1kb21haW4gcGF0aC4NCg0KPllvdSBzYWlkICJCdXQgSSB0aGlu
ayB0aGUgaW50ZXItQVNCUiBsaW5rIHNob3VsZCBoYXZlIEFTIGZsb29kaW5nDQo+c2NvcGUuIiBX
aGF0IGRvIHlvdSBtZWFuIGJ5ICJBUyBmbG9vZGluZyBzY29wZSI/IElzIGl0IHdpdGhpbiBhbiBB
UyBvcg0KPmFtb25nIEFTZXM/IElmIHdpdGhpbiBhbiBBUywgdGhlbiB0aGF0J3MgdGhlIGV4YW1w
bGUgc2hvd24gaW4gdGhlDQo+dGhpcmQgZG9jdW1lbnQgYW5kIG1lbnRpb25lZCBpbiBEaW1pdHJp
J3MgcXVlc3Rpb25zOyBpZiBhbW9uZyBBU2VzLA0KPnRoZW4gaG93IG1hbnkgQVNlcyB3b3VsZCBi
ZSBlbm91Z2g/DQoNCkkgbWVhbnMgaXQncyBqdXN0IHdpdGhpbiBhbiBBUywgYW5kIGl0J3MgZW5v
dWdoIGZvciB0aG9zZSBwcm9wb3NlZCANCnBhdGggY29tcHV0YXRpb24gbWV0aG9kcywgZS5nOiBQ
ZXItRG9tYWluLCBCUlBDLCBldGMuIA0KDQpJZiBzdWNoIGludGVyLUFTQlIgbGlua3MgYXJlIGZs
b29kZWQgYW1vbmcgQVNlcywgdGhlcmUgd291bGQgYmUgc2NhbGFiaWx0eQ0KYW5kIGNvbmZpZGVu
dGlhbGl0eSBpc3N1ZXMuIA0KDQo+SSBqdXN0IGd1ZXNzIHRoZSBjb250ZW50cyBvZiBpbnRlci1B
UyBsaW5rIGluZm8gdG8gYmUgZmxvb2RlZCBzZWVtcw0KPmVhc2lseSB0byBiZSBkZWNpZGVkIChj
b25zaWRlciBpdCBhcyBhIHNwZWNpYWwgaW50cmEtQVMgVEUgbGluayB3aXRoDQo+QVMgIyBhdHRh
Y2hlZCksIGFuZCBtaWdodCBqdXN0IG5lZWQgYSBzaW1wbGUgZG9jdW1lbnQgdG8gZGVmaW5lIGl0
Ow0KPnRoZSBkaWZmaWN1bHQgdGhpbmcgaXMgdGhlIGZsb29kaW5nIHNjb3BlLCB3aGljaCBtaWdo
dCBiZSB2YXJpZWQgd2l0aA0KPmRpZmZlcmVudCBwYXRoIGNvbXB1dGluZyBhcHByb2FjaGVzIG9y
IGV2ZW4gdGhlIGFncmVlbWVudCBhbW9uZw0KPm9wZXJhdG9ycy4gIFN0aWxsIHNlZW1zIHRvIG1l
IGhhcmQgdG8gZGVmaW5lIGEgc3RhbmRhcmQgdG8gcnVsZSBpdC4NCj5PciwgbGVhdmUgZXZlcnkg
b3B0aW9ucyBvcGVuPw0KDQoNCg0KPlJlZ2FyZHMsDQo+UGVuZw0KDQpPbiAxLzE1LzA3LCBNYWNo
IENoZW4gPG1hY2hAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IEhpIFBlbmcsDQo+DQo+IEkgbWVhbnMg
dGhhdCBubyBtYXR0ZXIgd2hhdCBraW5kIG9mIHBhdGggY29tcHV0YXRpb24gbWV0aG9kcyhQZXIt
ZG9tYWluLCBCUlBDLCBldGMuKSB3ZSBhZG9wdCwNCj4gaWYgd2Ugd2FudCB0byBjb21wdXRlIGEg
cGF0aCBzcGFuaW5nIG11dGlwbGUgQVNlcywgdGhlIGNvbXB1dGUgZWxlbWVudChIZWFkLWVuZCwg
QVNCUiwgb3IgUENFKQ0KPiBTSE9VTEQgZ2V0IHRoZSBpbnRlci1BU0JSIGxpbmtzIGluZm8uDQo+
DQo+IFdpdGggcmVzcGVjdCB0byB0aGUgZmxvb2Rpbmcgc2NvcGUgYW5kIHNwZWNpZmljYXRpb24g
b2YgaW50ZXItQVNCUiBsaW5rcyBpbmZvLCAgd2UgbmVlZCBtb3JlIGRpc2N1c3Npb24uDQo+IEJ1
dCBJIHRoaW5rIHRoZSBpbnRlci1BU0JSIGxpbmsgc2hvdWxkIGhhdmUgQVMgZmxvb2Rpbmcgc2Nv
cGUuDQo+DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIlBlbmcgSGUi
IDxwZW5nLmhlLjIwMDBAZ21haWwuY29tPg0KPiBUbzogIk1hY2ggQ2hlbiIgPG1hY2hAaHVhd2Vp
LmNvbT4NCj4gQ2M6IDxEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC1sdWNlbnQuYmU+OyAi
QWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+OyA8Y2NhbXBAb3BzLmlldGYub3Jn
PjsgPG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZz4NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDE1
LCAyMDA3IDExOjI2IEFNDQo+IFN1YmplY3Q6IFJlOiBQcm9ncmVzc2luZyB0aGUgdGhyZWUgaW50
ZXItZG9tYWluIEktRHMNCj4NCj4NCj4gSGVsbG8gTWFjaCwNCj4NCj4gSSBhbSBpbnRlcmVzdGVk
IGluIHN1Y2ggd29yay4gQnV0IEkgYW0gbm90IHN1cmUgd2hhdCB5b3Ugc2FpZCAiaW4gb2Rlcg0K
PiB0byBwZXJmb3JtICBpbnRlci1BUyBwYXRoIGNvbXB1dGF0aW9uLCBpbnRlci1BU0JSIGxpbmtz
IGZvb2RpbmcgaXMNCj4gZGVzaXJlZCIsIHNheSwgZGlmZmVyZW50IGNvbXB1dGluZyBtZXRob2Rz
IG1pZ2h0IG5lZWQgZGlmZmVyZW50DQo+IGluZm9ybWF0aW9uIGFib3V0IHRoZSBpbnRlci1BUyBs
aW5rcyBhbmQgdmFyaW91cyBmbG9vZCByYW5nZXMsIGFuZCBpZg0KPiBub3QgYSBnZW5lcmFsIG1l
dGhvZCBpcyBjb25zaWRlcmVkIGFzIGRlZmF1bHQsIGl0IHNlZW1zIHRvIG1lIGhhcmQgdG8NCj4g
ZGVmaW5lIHdoYXQgZXhhY3QgaW5mbyBzaG91bGQgYmUgZmxvb2RlZC4gSnVzdCBteSBwZXJzb25h
bCB0aG91Z2h0cy4NCj4NCj4gUmVnYXJkcywNCj4gUGVuZw0KPg0KPiBPbiAxLzE0LzA3LCBNYWNo
IENoZW4gPG1hY2hAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gRGltaXRyaSBhbmQgYWxsLA0KPiA+
DQo+ID4gQWZ0ZXIgcmVhZGluZyB0aGVzZSBkb2NzIEkgYWxzbyBoYXZlIHRoZSBzYW1lIGNvbmNl
cm4gd2l0aCB5b3UgYWJvdXQgaW50ZXItQVNCUiBsaW5rcyBmbG9vZGluZy4NCj4gPiBJIHRoaW5r
LCBpbiBvZGVyIHRvIHBlcmZvcm0gIGludGVyLUFTIHBhdGggY29tcHV0YXRpb24sIGludGVyLUFT
QlIgbGlua3MgZm9vZGluZyBpcyBkZXNpcmVkLiBCdXQNCj4gPiBzdWNoIGtpbmQgb2YgaW50ZXIt
QVNCUiBsaW5rIGluZm8gc2hvdWxkIGluY2x1ZGUgbW9yZSBpbmZvcm1hdGlvbiB0aGFuICJub3Jt
YWwiIFRFIGxpbmtzIGRvLA0KPiA+IGUuZzogdGhlIGludGVyLUFTQlIgbGlua3MgaW5mbyBTSE9V
TEQgc3RpbGwgaW5jbHVkZSB0aGUgcGVlciBBUyBudW1iZXIgYW5kIHBlZXIgQVNCUiByb3V0ZXIg
aWQNCj4gPiBiZXNpZGVzIHRob3NlIGxpbmsgaW5mbyB3aGljaCBoYXMgYmVlbiBzcGVjaWZpZWQg
aW4gcmZjMzYzMCBhbmQgcmZjMzc4NC4NCj4gPg0KPiA+IFNvIEkgdGhpbmsgdGhlcmUgbmVlZCBh
IGRvY3VtZW50IHRvIGNsYXJpZnkgYW5kIHNwZWNpZnkgaW50ZXItQVNCUiBsaW5rcyBmbG9vZGlu
Zy4gd2UgYXJlIGNvbnNpZGVyaW5nIHRvDQo+ID4gd3JpdGUgc3VjaCBhIGRvY3VtZW50LiBJZiBz
b21lb25lIGludGVyZXN0ZWQgaW4gc3VjaCB3b3JrLCB3ZSBjb3VsZCBjb29wZXJhdGUuDQo+ID4N
Cj4gPg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+DQo+ID4gTWFjaA0KPiA+DQo+ID4gLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+IEZyb206IDxEaW1pdHJpLlBhcGFkaW1pdHJp
b3VAYWxjYXRlbC1sdWNlbnQuYmU+DQo+ID4gVG86ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9s
ZGRvZy5jby51az4NCj4gPiBDYzogPGNjYW1wQG9wcy5pZXRmLm9yZz47IDxvd25lci1jY2FtcEBv
cHMuaWV0Zi5vcmc+DQo+ID4gU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTMsIDIwMDcgNzo0OSBQ
TQ0KPiA+IFN1YmplY3Q6IFJlOiBQcm9ncmVzc2luZyB0aGUgdGhyZWUgaW50ZXItZG9tYWluIEkt
RHMNCj4gPg0KPiA+DQo+ID4gaGkgYWRyaWFuDQo+ID4NCj4gPiBvKSBhIGNvdXBsZSBvZiBnZW5l
cmljIGNvbW1lbnRzIG9uIHRoZSB0aGlyZCBkb2MNCj4gPg0KPiA+IC0gdGhlIGRvYy4gc3RhdGVz
IGFwcGxpY2FiaWxpdHkgdG8gR01QTFMgYnV0IHNvbWV0aW1lcyBvbmx5IHJlZi4gTVBMUy1URQ0K
PiA+IHNpZ25hbGluZyBmdXJ0aGVyIG9uIGUuZy4gc2VjdGlvbiAzLjENCj4gPg0KPiA+ICIgLSBU
aGUgaW50ZXItZG9tYWluIFRFIExTUHMgYXJlIHNpZ25hbGVkIHVzaW5nIFJTVlAtVEUgKFtSRkMz
MjA5XSkuIg0KPiA+DQo+ID4gYW5kIG1hbnkgb3RoZXJzIGluIHNlY3Rpb24gNC4NCj4gPg0KPiA+
IC0gdGhlIGFyZSBtYW55IGNvbXBhcmlzb24gd2l0aCBQQ0UgdGVjaG5pcXVlIGFsb25nIHRoZSBk
b2MuIC0gd2VsbCB0aGF0J3MNCj4gPiBmaW5lIGJ1dCBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUg
ZG9jdW1lbnQgZXhjZXB0IGlmIHRoZSBwdXJwb3NlIGlzIHRvDQo+ID4gaW5kaWNhdGUgaG93IGRp
ZmZlcmVudCB0ZWNobmlxdWVzIGNhbiBiZSBjb21iaW5lZCB0b2dldGhlciBhbmQgd2hpY2gNCj4g
PiBpbnRlcm9wIGlzc3VlcyBtYXkgcmVzdWx0IGZyb20gaXQNCj4gPg0KPiA+IG8pIGEgY291cGxl
IG9mIHNwZWNpZmljIGNvbW1lbnRzDQo+ID4NCj4gPiBlbmQgb2Ygc2VjdGlvbiAyOg0KPiA+DQo+
ID4gc2VjdGlvbiAzLjE6ICIqIFRoZSBjb21wbGV0ZSBsaXN0IG9mIGJvdW5kYXJ5IExTUnMgYWxv
bmcgdGhlIHBhdGgiDQo+ID4gLT4gbGlzdCBvZiBkb21haW4gaWRlbnRpZmllciBlLmcuIEFTIG51
bWJlcnMgYWxzbyBhcHBsaWVzIGhlcmUgPw0KPiA+DQo+ID4gbGFzdCCnIG9mIHNlY3Rpb24gMy4x
IGlzIHRoZSBtb3N0IGltcG9ydGFudCBvbmUsIHNpZ25hbGluZyBwcm90b2NvbCBhcmUNCj4gPiBp
bmRlcGVuZGVudCBvZiB0aGUgcm91dGluZyB0b3BvbG9neSBpdHNlbGYsIGkuZS4gbm90IGJlY2F1
c2UgYSBub2RlIGlzDQo+ID4gYW4gQUJSIG9yIGFuIEFTQlIgdGhhdCBjb21wLiBvY2N1cnMgYnV0
IHNpbXBseSBiZWNhdXNlIGhlIGhhcyBubyBwYXRoDQo+ID4gdG8gcmVhY2ggdGhlIG5leHQgKGxv
b3NlKSBob3AgLSBhbiBpbnRlcm1lZGlhdGUgbm9kZSBzaG91bGQgc3RpbGwgbWFpbnRhaW4NCj4g
PiBjYXBhY2l0eSB0byBwZXJmb3JtIHN1Y2ggb3BlcmF0aW9uDQo+ID4NCj4gPiBzZWN0aW9uIDMu
MyAiVGhlIHBhdGggY29tcHV0YXRpb24NCj4gPiAgICB0ZWNobmlxdWUgZGVzY3JpYmVkIGluIHRo
aXMgZG9jdW1lbnQgYXBwbGllcyB0byB0aGUgY2FzZSBvZiBhIHNpbmdsZQ0KPiA+ICAgIEFTIG1h
ZGUgb2YgbXVsdGlwbGUgSUdQIGFyZWFzLCBtdWx0aXBsZXMgQVNzIG1hZGUgb2YgYSBzaW5nbGUg
SUdQDQo+ID4gICAgYXJlYXMgb3IgYW55IGNvbWJpbmF0aW9uIG9mIHRoZSBhYm92ZS4gIEZvciB0
aGUgc2FrZSBvZiBzaW1wbGljaXR5LA0KPiA+ICAgIGVhY2ggcm91dGluZyBkb21haW4gd2lsbCBi
ZSBjb25zaWRlcmVkIGFzIHNpbmdsZSBhcmVhIGluIHRoaXMNCj4gPiAgICBkb2N1bWVudC4gIg0K
PiA+DQo+ID4gLT4gbm90IHN1cmUgdG8gdW5kZXJzdGFuZCB0aGUgcmVhc29uaW5nLCBhdCB0aGUg
ZW5kIHRoZXNlIGV4YW1wbGVzIG11c3QNCj4gPiByZW1haW4gaWxsdXN0cmF0aXZlIGFuZCBub3Qg
cmVzdHJpY3QgYXBwbGljYWJpbGl0eSAtIGFsbCB0aGVzZSB0dXRvcmlhbA0KPiA+IGxpa2UgbWF0
ZXJpYWwgc2hvdWxkIGJldHRlciBnbyBpbiBhbiBhcHBlbmRpeCAtDQo+ID4NCj4gPiBzZWN0aW9u
IDMuMSAiSW4gYW55IGNhc2UsDQo+ID4gICAgbm8gdG9wb2xvZ3kgb3IgcmVzb3VyY2UgaW5mb3Jt
YXRpb24gbmVlZHMgdG8gYmUgZGlzdHJpYnV0ZWQgYmV0d2Vlbg0KPiA+ICAgIGRvbWFpbnMgKGFz
IG1hbmRhdGVkIHBlciBbUkZDNDEwNV0gYW5kIFtSRkM0MjE2XSksIHdoaWNoIGlzIGNyaXRpY2Fs
DQo+ID4gICAgdG8gcHJlc2VydmUgSUdQL0JHUCBzY2FsYWJpbGl0eSBhbmQgY29uZmlkZW50aWFs
aXR5IGluIHRoZSBjYXNlIG9mIFRFDQo+ID4gICAgTFNQcyBzcGFubmluZyBtdWx0aXBsZSByb3V0
aW5nIGRvbWFpbnMuIg0KPiA+DQo+ID4gdGhlbiBTZWN0aW9uIDQNCj4gPiAiSW4gdGVybXMgb2Yg
Y29tcHV0YXRpb24gb2YgYW4gaW50ZXItQVMgVEUgTFNQIHBhdGgsIGFuIGludGVyZXN0aW5nDQo+
ID4gICAgb3B0aW1pemF0aW9uIHRlY2huaXF1ZSBjb25zaXN0cyBvZiBhbGxvd2luZyB0aGUgQVNC
UnMgdG8gZmxvb2QgdGhlIFRFDQo+ID4gICAgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgaW50
ZXItQVNCUiBsaW5rKHMpIGFsdGhvdWdoIG5vIElHUCBURSBpcw0KPiA+ICAgIGVuYWJsZWQgb3Zl
ciB0aG9zZSBsaW5rcyAoYW5kIHNvIHRoZXJlIGlzIG5vIElHUCBhZGphY2VuY3kgb3ZlciB0aGUN
Cj4gPiAgICBpbnRlci1BU0JSIGxpbmtzKS4gIC4uLg0KPiA+ICJUaGFua3MgdG8gc3VjaCBhbiBv
cHRpbWl6YXRpb24sIHRoZSBpbnRlci1BU0JScyBURSBsaW5rIGluZm9ybWF0aW9uDQo+ID4gICAg
Y29ycmVzcG9uZGluZyB0byB0aGUgbGlua3Mgb3JpZ2luYXRlZCBieSB0aGUgQVNCUiBpcyBtYWRl
IGF2YWlsYWJsZQ0KPiA+ICAgIGluIHRoZSBURUQgb2Ygb3RoZXIgTFNScyBpbiB0aGUgc2FtZSBk
b21haW4gdGhhdCB0aGUgQVNCUiBiZWxvbmdzIHRvLiINCj4gPg0KPiA+IGJ1dCBhZnRlcg0KPiA+
ICJOb3RlIHRoYXQgbm8gdG9wb2xvZ3kNCj4gPiAgICBpbmZvcm1hdGlvbiBpcyBmbG9vZGVkIGFu
ZCB0aGVzZSBsaW5rcyBhcmUgbm90IHVzZWQgaW4gSUdQIFNQRg0KPiA+ICAgIGNvbXB1dGF0aW9u
cy4gIE9ubHkgdGhlIFRFIGluZm9ybWF0aW9uIGZvciB0aGUgb3V0Z29pbmcgbGlua3MNCj4gPiAg
ICBkaXJlY3RseSBjb25uZWN0ZWQgdG8gdGhlIEFTQlIgaXMgYWR2ZXJ0aXNlZC4iDQo+ID4NCj4g
PiAtPiBjYW4gb25lIG9mIHRoZSBhdXRob3IgY2xhcmlmeSAxKSBpcyBmbG9vZGluZyBpbnZvbHZl
ZCBvciBub3QgPw0KPiA+IDIpIHdoYXQgZ2V0J3MgZmxvb2RlZCBhbmQgdW5kZXIgd2hpY2ggY29u
ZGl0aW9ucyAzKSB3aGF0IGlzIHRoZQ0KPiA+IHNjb3BlIG9mIHRoZSBmbG9vZGluZyA0KSBob3cg
dGhpcyBtZWNoYW5pc20gcG9zaXRpb25zIGFnYWluc3QgdGhlDQo+ID4gcmVxdWlyZW1lbnRzIG9m
IDQxMDUgYW5kIDQyMTYNCj4gPg0KPiA+DQo+ID4gbykgYSBjb3VwbGUgb2YgZWRpdHMNCj4gPg0K
PiA+IHNlY3Rpb24gMToNCj4gPg0KPiA+IEFCUiBSb3V0ZXIsIEFTQlIgUm91dGVyIC0gcmVkdW5k
YW50IFINCj4gPg0KPiA+IHRoZSBtb3N0IGltcG9ydGFudCBkZWYuIGlzIHRoZSAiZG9tYWluIiBk
ZWYuIHdoaWNoIGNhbiBiZSBmb3VuZCBpbiB0aGUNCj4gPiBmcm0gZG9jIGJ1dCBub3QgcmVjb3Jk
ZWQgaGVyZSB0aGlzIHdvdWxkIGNsYXJpZnkgc2VudGVuY2UgbGlrZQ0KPiA+DQo+ID4gIlRoZSBt
ZWNoYW5pc21zIHByb3Bvc2VkIGluIHRoaXMgZG9jdW1lbnQgYXJlIGFsc28gYXBwbGljYWJsZSB0
byBNUExTDQo+ID4gIFRFIGRvbWFpbnMgb3RoZXIgdGhhbiBJR1AgYXJlYXMgYW5kIEFTcy4iDQo+
ID4NCj4gPiByZWYuIEgtTFNQIGFuZCBTLUxTUCB3aXRoIHRoZSBhcHByb3ByaWF0ZSBkb2NzDQo+
ID4NCj4gPiBzdGF0ZSB0aGF0IGludGVyLWRvbWFpbiByZWNvdmVyeSBpcyBnb2luZyB0byBiZSBh
ZGRyZXNzZWQgaW4gYSBzZXQgb2YNCj4gPiBzcGVjaWZpYyBkb2NzDQo+ID4NCj4gPiBob3BlIHRo
aXMgd2lsbCBoZWxwLA0KPiA+IC0gZC4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ICJBZHJpYW4g
RmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az4NCj4gPiBTZW50IGJ5OiBvd25lci1jY2FtcEBv
cHMuaWV0Zi5vcmcNCj4gPiAwOS8wMS8yMDA3IDIzOjEzDQo+ID4gUGxlYXNlIHJlc3BvbmQgdG8g
IkFkcmlhbiBGYXJyZWwiDQo+ID4NCj4gPiAgICAgICAgIFRvOiAgICAgPGNjYW1wQG9wcy5pZXRm
Lm9yZz4NCj4gPiAgICAgICAgIGNjOg0KPiA+ICAgICAgICAgU3ViamVjdDogICAgICAgIFByb2dy
ZXNzaW5nIHRoZSB0aHJlZSBpbnRlci1kb21haW4gSS1Ecw0KPiA+DQo+ID4NCj4gPiBIaSwNCj4g
Pg0KPiA+IFdlIG5vdyBoYXZlIHVwZGF0ZWQgdmVyc2lvbnMgb2YgdGhlIHRocmVlIGludGVyLWRv
bWFpbiBzaWduYWxpbmcgSS1EczoNCj4gPg0KPiA+IC0gZHJhZnQtaWV0Zi1jY2FtcC1pbnRlci1k
b21haW4tcnN2cC10ZS0wNC50eHQNCj4gPiAtIGRyYWZ0LWlldGYtY2NhbXAtbHNwLXN0aXRjaGlu
Zy0wNC50eHQNCj4gPiAtIGRyYWZ0LWlldGYtY2NhbXAtaW50ZXItZG9tYWluLXBkLXBhdGgtY29t
cC0wMy50eHQNCj4gPg0KPiA+IE91ciBwbGFuIGlzOg0KPiA+IDEuIFdHIGNoYWlycyBkbyBkZXRh
aWxlZCByZXZpZXcgb3ZlciB0aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3MNCj4gPiAyLiBFZGl0b3Jz
IGFwcGx5IG5lY2Vzc2FyeSB1cGRhdGVzDQo+ID4gMy4gV2UgaG9sZCBhIFdHIGxhc3QgY2FsbCBm
b3IgdGhlIHRocmVlIEktRHMgdG9nZXRoZXINCj4gPg0KPiA+IElmIHlvdSBhcmUgaW50ZXJlc3Rl
ZCBpbiB0aGlzIHdvcmssIEkgc3VnZ2VzdCB0aGF0IG5vdyBtaWdodCBiZSBhIGdvb2QNCj4gPiB0
aW1lDQo+ID4gdG8gcmVtaW5kIHlvdXJzZWxmIGFib3V0IHRoZSBJLURzLCBoYXZlIGEgZ29vZCBy
ZWFkLCBhbmQgc2VlIGlmIHlvdSBjYW4NCj4gPiBnZXQNCj4gPiBhbnkgc3Vic3RhbnRpYWwgY29t
bWVudHMgaW4gdG8gY29pbmNpZGUgd2l0aCB0aGUgV0cgY2hhaXJzJyByZXZpZXcuDQo+ID4NCj4g
PiBUaGFua3MsDQo+ID4gQWRyaWFuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4N
Cj4NCj4NCg0KQmVzdCByZWdhcmRzLA0KDQpNYWNoDQoNCg==





Envelope-to: [e-mail]
Delivery-date: Tue, 16 Jan 2007 03:20:13 +0000
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iqXuFgAwoJ8PRIGKZp8bhcAG58Bv6RIfggc7WT+eO/XD18/UNxv1v51vU6KbD1knN3QZ2M4adHBqXU2NTdcDZg9Qfg0eylYuchhOStGaGLSd0FGTx55zHCecDL2QeNWvQe/4SuoCaMe4G9u/RyqcAUOOADitxC7ejcysuask1Is=
Message-ID: <[e-mail]>
Date: Mon, 15 Jan 2007 22:17:31 -0500
From: "Peng He" <[e-mail]>
To: "Mach Chen" <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
Cc: [e-mail],  "Adrian Farrel" <[e-mail]>, [e-mail],  [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 <[e-mail]> 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" <[e-mail]>
> To: "Mach Chen" <[e-mail]>
> Cc: <[e-mail]>; "Adrian Farrel" <adrian@ol=
ddog.co.uk>; <[e-mail]>; <[e-mail]>
> 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 <[e-mail]> 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: <[e-mail]>
> > To: "Adrian Farrel" <[e-mail]>
> > Cc: <[e-mail]>; <[e-mail]>
> > 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" <[e-mail]>
> > Sent by: [e-mail]
> > 09/01/2007 23:13
> > Please respond to "Adrian Farrel"
> >
> >         To:     <[e-mail]>
> >         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: [e-mail]
Delivery-date: Mon, 15 Jan 2007 21:35:22 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>
Subject: Protocol Action: 'RSVP-TE Extensions in support of  End-to-End Generalized Multi-Protocol Label Switching (GMPLS)  Recovery' to Proposed Standard 
Message-Id: <[e-mail]>
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: [e-mail]
Delivery-date: Mon, 15 Jan 2007 21:35:15 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>
Subject: Protocol Action: 'GMPLS Based Segment Recovery' to  Proposed Standard 
Message-Id: <[e-mail]>
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]




Envelope-to: [e-mail]
Delivery-date: Mon, 15 Jan 2007 05:04:43 +0000
Date: Mon, 15 Jan 2007 13:02:57 +0800
From: Mach Chen <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
To: Peng He <[e-mail]>
Cc: [e-mail], Adrian Farrel <[e-mail]>, [e-mail], [e-mail]
Message-id: <001a01c73862$6c747370$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64

SGkgUGVuZywNCg0KSSBtZWFucyB0aGF0IG5vIG1hdHRlciB3aGF0IGtpbmQgb2YgcGF0aCBjb21w
dXRhdGlvbiBtZXRob2RzKFBlci1kb21haW4sIEJSUEMsIGV0Yy4pIHdlIGFkb3B0LCANCmlmIHdl
IHdhbnQgdG8gY29tcHV0ZSBhIHBhdGggc3BhbmluZyBtdXRpcGxlIEFTZXMsIHRoZSBjb21wdXRl
IGVsZW1lbnQoSGVhZC1lbmQsIEFTQlIsIG9yIFBDRSkNClNIT1VMRCBnZXQgdGhlIGludGVyLUFT
QlIgbGlua3MgaW5mby4NCg0KV2l0aCByZXNwZWN0IHRvIHRoZSBmbG9vZGluZyBzY29wZSBhbmQg
c3BlY2lmaWNhdGlvbiBvZiBpbnRlci1BU0JSIGxpbmtzIGluZm8sICB3ZSBuZWVkIG1vcmUgZGlz
Y3Vzc2lvbi4NCkJ1dCBJIHRoaW5rIHRoZSBpbnRlci1BU0JSIGxpbmsgc2hvdWxkIGhhdmUgQVMg
Zmxvb2Rpbmcgc2NvcGUuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAi
UGVuZyBIZSIgPHBlbmcuaGUuMjAwMEBnbWFpbC5jb20+DQpUbzogIk1hY2ggQ2hlbiIgPG1hY2hA
aHVhd2VpLmNvbT4NCkNjOiA8RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwtbHVjZW50LmJl
PjsgIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPjsgPGNjYW1wQG9wcy5pZXRm
Lm9yZz47IDxvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEphbnVhcnkg
MTUsIDIwMDcgMTE6MjYgQU0NClN1YmplY3Q6IFJlOiBQcm9ncmVzc2luZyB0aGUgdGhyZWUgaW50
ZXItZG9tYWluIEktRHMNCg0KDQpIZWxsbyBNYWNoLA0KDQpJIGFtIGludGVyZXN0ZWQgaW4gc3Vj
aCB3b3JrLiBCdXQgSSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBzYWlkICJpbiBvZGVyDQp0byBwZXJm
b3JtICBpbnRlci1BUyBwYXRoIGNvbXB1dGF0aW9uLCBpbnRlci1BU0JSIGxpbmtzIGZvb2Rpbmcg
aXMNCmRlc2lyZWQiLCBzYXksIGRpZmZlcmVudCBjb21wdXRpbmcgbWV0aG9kcyBtaWdodCBuZWVk
IGRpZmZlcmVudA0KaW5mb3JtYXRpb24gYWJvdXQgdGhlIGludGVyLUFTIGxpbmtzIGFuZCB2YXJp
b3VzIGZsb29kIHJhbmdlcywgYW5kIGlmDQpub3QgYSBnZW5lcmFsIG1ldGhvZCBpcyBjb25zaWRl
cmVkIGFzIGRlZmF1bHQsIGl0IHNlZW1zIHRvIG1lIGhhcmQgdG8NCmRlZmluZSB3aGF0IGV4YWN0
IGluZm8gc2hvdWxkIGJlIGZsb29kZWQuIEp1c3QgbXkgcGVyc29uYWwgdGhvdWdodHMuDQoNClJl
Z2FyZHMsDQpQZW5nDQoNCk9uIDEvMTQvMDcsIE1hY2ggQ2hlbiA8bWFjaEBodWF3ZWkuY29tPiB3
cm90ZToNCj4gRGltaXRyaSBhbmQgYWxsLA0KPg0KPiBBZnRlciByZWFkaW5nIHRoZXNlIGRvY3Mg
SSBhbHNvIGhhdmUgdGhlIHNhbWUgY29uY2VybiB3aXRoIHlvdSBhYm91dCBpbnRlci1BU0JSIGxp
bmtzIGZsb29kaW5nLg0KPiBJIHRoaW5rLCBpbiBvZGVyIHRvIHBlcmZvcm0gIGludGVyLUFTIHBh
dGggY29tcHV0YXRpb24sIGludGVyLUFTQlIgbGlua3MgZm9vZGluZyBpcyBkZXNpcmVkLiBCdXQN
Cj4gc3VjaCBraW5kIG9mIGludGVyLUFTQlIgbGluayBpbmZvIHNob3VsZCBpbmNsdWRlIG1vcmUg
aW5mb3JtYXRpb24gdGhhbiAibm9ybWFsIiBURSBsaW5rcyBkbywNCj4gZS5nOiB0aGUgaW50ZXIt
QVNCUiBsaW5rcyBpbmZvIFNIT1VMRCBzdGlsbCBpbmNsdWRlIHRoZSBwZWVyIEFTIG51bWJlciBh
bmQgcGVlciBBU0JSIHJvdXRlciBpZA0KPiBiZXNpZGVzIHRob3NlIGxpbmsgaW5mbyB3aGljaCBo
YXMgYmVlbiBzcGVjaWZpZWQgaW4gcmZjMzYzMCBhbmQgcmZjMzc4NC4NCj4NCj4gU28gSSB0aGlu
ayB0aGVyZSBuZWVkIGEgZG9jdW1lbnQgdG8gY2xhcmlmeSBhbmQgc3BlY2lmeSBpbnRlci1BU0JS
IGxpbmtzIGZsb29kaW5nLiB3ZSBhcmUgY29uc2lkZXJpbmcgdG8NCj4gd3JpdGUgc3VjaCBhIGRv
Y3VtZW50LiBJZiBzb21lb25lIGludGVyZXN0ZWQgaW4gc3VjaCB3b3JrLCB3ZSBjb3VsZCBjb29w
ZXJhdGUuDQo+DQo+DQo+DQo+IEJlc3QgcmVnYXJkcywNCj4NCj4gTWFjaA0KPg0KPiAtLS0tLSBP
cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206IDxEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxj
YXRlbC1sdWNlbnQuYmU+DQo+IFRvOiAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28u
dWs+DQo+IENjOiA8Y2NhbXBAb3BzLmlldGYub3JnPjsgPG93bmVyLWNjYW1wQG9wcy5pZXRmLm9y
Zz4NCj4gU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTMsIDIwMDcgNzo0OSBQTQ0KPiBTdWJqZWN0
OiBSZTogUHJvZ3Jlc3NpbmcgdGhlIHRocmVlIGludGVyLWRvbWFpbiBJLURzDQo+DQo+DQo+IGhp
IGFkcmlhbg0KPg0KPiBvKSBhIGNvdXBsZSBvZiBnZW5lcmljIGNvbW1lbnRzIG9uIHRoZSB0aGly
ZCBkb2MNCj4NCj4gLSB0aGUgZG9jLiBzdGF0ZXMgYXBwbGljYWJpbGl0eSB0byBHTVBMUyBidXQg
c29tZXRpbWVzIG9ubHkgcmVmLiBNUExTLVRFDQo+IHNpZ25hbGluZyBmdXJ0aGVyIG9uIGUuZy4g
c2VjdGlvbiAzLjENCj4NCj4gIiAtIFRoZSBpbnRlci1kb21haW4gVEUgTFNQcyBhcmUgc2lnbmFs
ZWQgdXNpbmcgUlNWUC1URSAoW1JGQzMyMDldKS4iDQo+DQo+IGFuZCBtYW55IG90aGVycyBpbiBz
ZWN0aW9uIDQuDQo+DQo+IC0gdGhlIGFyZSBtYW55IGNvbXBhcmlzb24gd2l0aCBQQ0UgdGVjaG5p
cXVlIGFsb25nIHRoZSBkb2MuIC0gd2VsbCB0aGF0J3MNCj4gZmluZSBidXQgb3V0c2lkZSB0aGUg
c2NvcGUgb2YgdGhlIGRvY3VtZW50IGV4Y2VwdCBpZiB0aGUgcHVycG9zZSBpcyB0bw0KPiBpbmRp
Y2F0ZSBob3cgZGlmZmVyZW50IHRlY2huaXF1ZXMgY2FuIGJlIGNvbWJpbmVkIHRvZ2V0aGVyIGFu
ZCB3aGljaA0KPiBpbnRlcm9wIGlzc3VlcyBtYXkgcmVzdWx0IGZyb20gaXQNCj4NCj4gbykgYSBj
b3VwbGUgb2Ygc3BlY2lmaWMgY29tbWVudHMNCj4NCj4gZW5kIG9mIHNlY3Rpb24gMjoNCj4NCj4g
c2VjdGlvbiAzLjE6ICIqIFRoZSBjb21wbGV0ZSBsaXN0IG9mIGJvdW5kYXJ5IExTUnMgYWxvbmcg
dGhlIHBhdGgiDQo+IC0+IGxpc3Qgb2YgZG9tYWluIGlkZW50aWZpZXIgZS5nLiBBUyBudW1iZXJz
IGFsc28gYXBwbGllcyBoZXJlID8NCj4NCj4gbGFzdCCnIG9mIHNlY3Rpb24gMy4xIGlzIHRoZSBt
b3N0IGltcG9ydGFudCBvbmUsIHNpZ25hbGluZyBwcm90b2NvbCBhcmUNCj4gaW5kZXBlbmRlbnQg
b2YgdGhlIHJvdXRpbmcgdG9wb2xvZ3kgaXRzZWxmLCBpLmUuIG5vdCBiZWNhdXNlIGEgbm9kZSBp
cw0KPiBhbiBBQlIgb3IgYW4gQVNCUiB0aGF0IGNvbXAuIG9jY3VycyBidXQgc2ltcGx5IGJlY2F1
c2UgaGUgaGFzIG5vIHBhdGgNCj4gdG8gcmVhY2ggdGhlIG5leHQgKGxvb3NlKSBob3AgLSBhbiBp
bnRlcm1lZGlhdGUgbm9kZSBzaG91bGQgc3RpbGwgbWFpbnRhaW4NCj4gY2FwYWNpdHkgdG8gcGVy
Zm9ybSBzdWNoIG9wZXJhdGlvbg0KPg0KPiBzZWN0aW9uIDMuMyAiVGhlIHBhdGggY29tcHV0YXRp
b24NCj4gICAgdGVjaG5pcXVlIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFwcGxpZXMgdG8g
dGhlIGNhc2Ugb2YgYSBzaW5nbGUNCj4gICAgQVMgbWFkZSBvZiBtdWx0aXBsZSBJR1AgYXJlYXMs
IG11bHRpcGxlcyBBU3MgbWFkZSBvZiBhIHNpbmdsZSBJR1ANCj4gICAgYXJlYXMgb3IgYW55IGNv
bWJpbmF0aW9uIG9mIHRoZSBhYm92ZS4gIEZvciB0aGUgc2FrZSBvZiBzaW1wbGljaXR5LA0KPiAg
ICBlYWNoIHJvdXRpbmcgZG9tYWluIHdpbGwgYmUgY29uc2lkZXJlZCBhcyBzaW5nbGUgYXJlYSBp
biB0aGlzDQo+ICAgIGRvY3VtZW50LiAiDQo+DQo+IC0+IG5vdCBzdXJlIHRvIHVuZGVyc3RhbmQg
dGhlIHJlYXNvbmluZywgYXQgdGhlIGVuZCB0aGVzZSBleGFtcGxlcyBtdXN0DQo+IHJlbWFpbiBp
bGx1c3RyYXRpdmUgYW5kIG5vdCByZXN0cmljdCBhcHBsaWNhYmlsaXR5IC0gYWxsIHRoZXNlIHR1
dG9yaWFsDQo+IGxpa2UgbWF0ZXJpYWwgc2hvdWxkIGJldHRlciBnbyBpbiBhbiBhcHBlbmRpeCAt
DQo+DQo+IHNlY3Rpb24gMy4xICJJbiBhbnkgY2FzZSwNCj4gICAgbm8gdG9wb2xvZ3kgb3IgcmVz
b3VyY2UgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgZGlzdHJpYnV0ZWQgYmV0d2Vlbg0KPiAgICBk
b21haW5zIChhcyBtYW5kYXRlZCBwZXIgW1JGQzQxMDVdIGFuZCBbUkZDNDIxNl0pLCB3aGljaCBp
cyBjcml0aWNhbA0KPiAgICB0byBwcmVzZXJ2ZSBJR1AvQkdQIHNjYWxhYmlsaXR5IGFuZCBjb25m
aWRlbnRpYWxpdHkgaW4gdGhlIGNhc2Ugb2YgVEUNCj4gICAgTFNQcyBzcGFubmluZyBtdWx0aXBs
ZSByb3V0aW5nIGRvbWFpbnMuIg0KPg0KPiB0aGVuIFNlY3Rpb24gNA0KPiAiSW4gdGVybXMgb2Yg
Y29tcHV0YXRpb24gb2YgYW4gaW50ZXItQVMgVEUgTFNQIHBhdGgsIGFuIGludGVyZXN0aW5nDQo+
ICAgIG9wdGltaXphdGlvbiB0ZWNobmlxdWUgY29uc2lzdHMgb2YgYWxsb3dpbmcgdGhlIEFTQlJz
IHRvIGZsb29kIHRoZSBURQ0KPiAgICBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBpbnRlci1B
U0JSIGxpbmsocykgYWx0aG91Z2ggbm8gSUdQIFRFIGlzDQo+ICAgIGVuYWJsZWQgb3ZlciB0aG9z
ZSBsaW5rcyAoYW5kIHNvIHRoZXJlIGlzIG5vIElHUCBhZGphY2VuY3kgb3ZlciB0aGUNCj4gICAg
aW50ZXItQVNCUiBsaW5rcykuICAuLi4NCj4gIlRoYW5rcyB0byBzdWNoIGFuIG9wdGltaXphdGlv
biwgdGhlIGludGVyLUFTQlJzIFRFIGxpbmsgaW5mb3JtYXRpb24NCj4gICAgY29ycmVzcG9uZGlu
ZyB0byB0aGUgbGlua3Mgb3JpZ2luYXRlZCBieSB0aGUgQVNCUiBpcyBtYWRlIGF2YWlsYWJsZQ0K
PiAgICBpbiB0aGUgVEVEIG9mIG90aGVyIExTUnMgaW4gdGhlIHNhbWUgZG9tYWluIHRoYXQgdGhl
IEFTQlIgYmVsb25ncyB0by4iDQo+DQo+IGJ1dCBhZnRlcg0KPiAiTm90ZSB0aGF0IG5vIHRvcG9s
b2d5DQo+ICAgIGluZm9ybWF0aW9uIGlzIGZsb29kZWQgYW5kIHRoZXNlIGxpbmtzIGFyZSBub3Qg
dXNlZCBpbiBJR1AgU1BGDQo+ICAgIGNvbXB1dGF0aW9ucy4gIE9ubHkgdGhlIFRFIGluZm9ybWF0
aW9uIGZvciB0aGUgb3V0Z29pbmcgbGlua3MNCj4gICAgZGlyZWN0bHkgY29ubmVjdGVkIHRvIHRo
ZSBBU0JSIGlzIGFkdmVydGlzZWQuIg0KPg0KPiAtPiBjYW4gb25lIG9mIHRoZSBhdXRob3IgY2xh
cmlmeSAxKSBpcyBmbG9vZGluZyBpbnZvbHZlZCBvciBub3QgPw0KPiAyKSB3aGF0IGdldCdzIGZs
b29kZWQgYW5kIHVuZGVyIHdoaWNoIGNvbmRpdGlvbnMgMykgd2hhdCBpcyB0aGUNCj4gc2NvcGUg
b2YgdGhlIGZsb29kaW5nIDQpIGhvdyB0aGlzIG1lY2hhbmlzbSBwb3NpdGlvbnMgYWdhaW5zdCB0
aGUNCj4gcmVxdWlyZW1lbnRzIG9mIDQxMDUgYW5kIDQyMTYNCj4NCj4NCj4gbykgYSBjb3VwbGUg
b2YgZWRpdHMNCj4NCj4gc2VjdGlvbiAxOg0KPg0KPiBBQlIgUm91dGVyLCBBU0JSIFJvdXRlciAt
IHJlZHVuZGFudCBSDQo+DQo+IHRoZSBtb3N0IGltcG9ydGFudCBkZWYuIGlzIHRoZSAiZG9tYWlu
IiBkZWYuIHdoaWNoIGNhbiBiZSBmb3VuZCBpbiB0aGUNCj4gZnJtIGRvYyBidXQgbm90IHJlY29y
ZGVkIGhlcmUgdGhpcyB3b3VsZCBjbGFyaWZ5IHNlbnRlbmNlIGxpa2UNCj4NCj4gIlRoZSBtZWNo
YW5pc21zIHByb3Bvc2VkIGluIHRoaXMgZG9jdW1lbnQgYXJlIGFsc28gYXBwbGljYWJsZSB0byBN
UExTDQo+ICBURSBkb21haW5zIG90aGVyIHRoYW4gSUdQIGFyZWFzIGFuZCBBU3MuIg0KPg0KPiBy
ZWYuIEgtTFNQIGFuZCBTLUxTUCB3aXRoIHRoZSBhcHByb3ByaWF0ZSBkb2NzDQo+DQo+IHN0YXRl
IHRoYXQgaW50ZXItZG9tYWluIHJlY292ZXJ5IGlzIGdvaW5nIHRvIGJlIGFkZHJlc3NlZCBpbiBh
IHNldCBvZg0KPiBzcGVjaWZpYyBkb2NzDQo+DQo+IGhvcGUgdGhpcyB3aWxsIGhlbHAsDQo+IC0g
ZC4NCj4NCj4NCj4NCj4NCj4gIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0K
PiBTZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNCj4gMDkvMDEvMjAwNyAyMzoxMw0K
PiBQbGVhc2UgcmVzcG9uZCB0byAiQWRyaWFuIEZhcnJlbCINCj4NCj4gICAgICAgICBUbzogICAg
IDxjY2FtcEBvcHMuaWV0Zi5vcmc+DQo+ICAgICAgICAgY2M6DQo+ICAgICAgICAgU3ViamVjdDog
ICAgICAgIFByb2dyZXNzaW5nIHRoZSB0aHJlZSBpbnRlci1kb21haW4gSS1Ecw0KPg0KPg0KPiBI
aSwNCj4NCj4gV2Ugbm93IGhhdmUgdXBkYXRlZCB2ZXJzaW9ucyBvZiB0aGUgdGhyZWUgaW50ZXIt
ZG9tYWluIHNpZ25hbGluZyBJLURzOg0KPg0KPiAtIGRyYWZ0LWlldGYtY2NhbXAtaW50ZXItZG9t
YWluLXJzdnAtdGUtMDQudHh0DQo+IC0gZHJhZnQtaWV0Zi1jY2FtcC1sc3Atc3RpdGNoaW5nLTA0
LnR4dA0KPiAtIGRyYWZ0LWlldGYtY2NhbXAtaW50ZXItZG9tYWluLXBkLXBhdGgtY29tcC0wMy50
eHQNCj4NCj4gT3VyIHBsYW4gaXM6DQo+IDEuIFdHIGNoYWlycyBkbyBkZXRhaWxlZCByZXZpZXcg
b3ZlciB0aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3MNCj4gMi4gRWRpdG9ycyBhcHBseSBuZWNlc3Nh
cnkgdXBkYXRlcw0KPiAzLiBXZSBob2xkIGEgV0cgbGFzdCBjYWxsIGZvciB0aGUgdGhyZWUgSS1E
cyB0b2dldGhlcg0KPg0KPiBJZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gdGhpcyB3b3JrLCBJIHN1
Z2dlc3QgdGhhdCBub3cgbWlnaHQgYmUgYSBnb29kDQo+IHRpbWUNCj4gdG8gcmVtaW5kIHlvdXJz
ZWxmIGFib3V0IHRoZSBJLURzLCBoYXZlIGEgZ29vZCByZWFkLCBhbmQgc2VlIGlmIHlvdSBjYW4N
Cj4gZ2V0DQo+IGFueSBzdWJzdGFudGlhbCBjb21tZW50cyBpbiB0byBjb2luY2lkZSB3aXRoIHRo
ZSBXRyBjaGFpcnMnIHJldmlldy4NCj4NCj4gVGhhbmtzLA0KPiBBZHJpYW4NCj4NCj4NCj4NCj4N
Cj4NCj4NCj4NCg0K





Envelope-to: [e-mail]
Delivery-date: Mon, 15 Jan 2007 03:27:19 +0000
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FgS//iHSwmXiRpKO8X9iILFnLRzDP9iyNzwYxHIHhkXURROVconIXMGWIRciSqu50FKXt6+ScfPg3hIvpjPZUogWD3xPiuvsuWwFVE6plpbV3JhaVPfG81stUYJUx4xWzVUDNFYLEC5PGa+Imdtn+K6KWKjnQrbLJL9qqkLnO0w=
Message-ID: <[e-mail]>
Date: Sun, 14 Jan 2007 22:26:27 -0500
From: "Peng He" <[e-mail]>
To: "Mach Chen" <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
Cc: [e-mail],  "Adrian Farrel" <[e-mail]>, [e-mail],  [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 <[e-mail]> 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: <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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" <[e-mail]>
> Sent by: [e-mail]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[e-mail]>
>         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: [e-mail]
Delivery-date: Mon, 15 Jan 2007 02:44:42 +0000
Date: Mon, 15 Jan 2007 10:41:20 +0800
From: Mach Chen <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
To: [e-mail], Adrian Farrel <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <003201c7384e$a449e820$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64

RGltaXRyaSBhbmQgYWxsLA0KDQpBZnRlciByZWFkaW5nIHRoZXNlIGRvY3MgSSBhbHNvIGhhdmUg
dGhlIHNhbWUgY29uY2VybiB3aXRoIHlvdSBhYm91dCBpbnRlci1BU0JSIGxpbmtzIGZsb29kaW5n
Lg0KSSB0aGluaywgaW4gb2RlciB0byBwZXJmb3JtICBpbnRlci1BUyBwYXRoIGNvbXB1dGF0aW9u
LCBpbnRlci1BU0JSIGxpbmtzIGZvb2RpbmcgaXMgZGVzaXJlZC4gQnV0IA0Kc3VjaCBraW5kIG9m
IGludGVyLUFTQlIgbGluayBpbmZvIHNob3VsZCBpbmNsdWRlIG1vcmUgaW5mb3JtYXRpb24gdGhh
biAibm9ybWFsIiBURSBsaW5rcyBkbywgDQplLmc6IHRoZSBpbnRlci1BU0JSIGxpbmtzIGluZm8g
U0hPVUxEIHN0aWxsIGluY2x1ZGUgdGhlIHBlZXIgQVMgbnVtYmVyIGFuZCBwZWVyIEFTQlIgcm91
dGVyIGlkIA0KYmVzaWRlcyB0aG9zZSBsaW5rIGluZm8gd2hpY2ggaGFzIGJlZW4gc3BlY2lmaWVk
IGluIHJmYzM2MzAgYW5kIHJmYzM3ODQuDQoNClNvIEkgdGhpbmsgdGhlcmUgbmVlZCBhIGRvY3Vt
ZW50IHRvIGNsYXJpZnkgYW5kIHNwZWNpZnkgaW50ZXItQVNCUiBsaW5rcyBmbG9vZGluZy4gd2Ug
YXJlIGNvbnNpZGVyaW5nIHRvIA0Kd3JpdGUgc3VjaCBhIGRvY3VtZW50LiBJZiBzb21lb25lIGlu
dGVyZXN0ZWQgaW4gc3VjaCB3b3JrLCB3ZSBjb3VsZCBjb29wZXJhdGUuDQoNCg0KDQpCZXN0IHJl
Z2FyZHMsDQoNCk1hY2gNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IDxE
aW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC1sdWNlbnQuYmU+DQpUbzogIkFkcmlhbiBGYXJy
ZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KQ2M6IDxjY2FtcEBvcHMuaWV0Zi5vcmc+OyA8b3du
ZXItY2NhbXBAb3BzLmlldGYub3JnPg0KU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTMsIDIwMDcg
Nzo0OSBQTQ0KU3ViamVjdDogUmU6IFByb2dyZXNzaW5nIHRoZSB0aHJlZSBpbnRlci1kb21haW4g
SS1Ecw0KDQoNCmhpIGFkcmlhbg0KDQpvKSBhIGNvdXBsZSBvZiBnZW5lcmljIGNvbW1lbnRzIG9u
IHRoZSB0aGlyZCBkb2MNCg0KLSB0aGUgZG9jLiBzdGF0ZXMgYXBwbGljYWJpbGl0eSB0byBHTVBM
UyBidXQgc29tZXRpbWVzIG9ubHkgcmVmLiBNUExTLVRFDQpzaWduYWxpbmcgZnVydGhlciBvbiBl
LmcuIHNlY3Rpb24gMy4xDQoNCiIgLSBUaGUgaW50ZXItZG9tYWluIFRFIExTUHMgYXJlIHNpZ25h
bGVkIHVzaW5nIFJTVlAtVEUgKFtSRkMzMjA5XSkuIg0KDQphbmQgbWFueSBvdGhlcnMgaW4gc2Vj
dGlvbiA0Lg0KDQotIHRoZSBhcmUgbWFueSBjb21wYXJpc29uIHdpdGggUENFIHRlY2huaXF1ZSBh
bG9uZyB0aGUgZG9jLiAtIHdlbGwgdGhhdCdzIA0KZmluZSBidXQgb3V0c2lkZSB0aGUgc2NvcGUg
b2YgdGhlIGRvY3VtZW50IGV4Y2VwdCBpZiB0aGUgcHVycG9zZSBpcyB0byANCmluZGljYXRlIGhv
dyBkaWZmZXJlbnQgdGVjaG5pcXVlcyBjYW4gYmUgY29tYmluZWQgdG9nZXRoZXIgYW5kIHdoaWNo
IA0KaW50ZXJvcCBpc3N1ZXMgbWF5IHJlc3VsdCBmcm9tIGl0DQoNCm8pIGEgY291cGxlIG9mIHNw
ZWNpZmljIGNvbW1lbnRzIA0KDQplbmQgb2Ygc2VjdGlvbiAyOiANCg0Kc2VjdGlvbiAzLjE6ICIq
IFRoZSBjb21wbGV0ZSBsaXN0IG9mIGJvdW5kYXJ5IExTUnMgYWxvbmcgdGhlIHBhdGgiDQotPiBs
aXN0IG9mIGRvbWFpbiBpZGVudGlmaWVyIGUuZy4gQVMgbnVtYmVycyBhbHNvIGFwcGxpZXMgaGVy
ZSA/DQoNCmxhc3QgpyBvZiBzZWN0aW9uIDMuMSBpcyB0aGUgbW9zdCBpbXBvcnRhbnQgb25lLCBz
aWduYWxpbmcgcHJvdG9jb2wgYXJlDQppbmRlcGVuZGVudCBvZiB0aGUgcm91dGluZyB0b3BvbG9n
eSBpdHNlbGYsIGkuZS4gbm90IGJlY2F1c2UgYSBub2RlIGlzDQphbiBBQlIgb3IgYW4gQVNCUiB0
aGF0IGNvbXAuIG9jY3VycyBidXQgc2ltcGx5IGJlY2F1c2UgaGUgaGFzIG5vIHBhdGggDQp0byBy
ZWFjaCB0aGUgbmV4dCAobG9vc2UpIGhvcCAtIGFuIGludGVybWVkaWF0ZSBub2RlIHNob3VsZCBz
dGlsbCBtYWludGFpbg0KY2FwYWNpdHkgdG8gcGVyZm9ybSBzdWNoIG9wZXJhdGlvbg0KDQpzZWN0
aW9uIDMuMyAiVGhlIHBhdGggY29tcHV0YXRpb24NCiAgIHRlY2huaXF1ZSBkZXNjcmliZWQgaW4g
dGhpcyBkb2N1bWVudCBhcHBsaWVzIHRvIHRoZSBjYXNlIG9mIGEgc2luZ2xlDQogICBBUyBtYWRl
IG9mIG11bHRpcGxlIElHUCBhcmVhcywgbXVsdGlwbGVzIEFTcyBtYWRlIG9mIGEgc2luZ2xlIElH
UA0KICAgYXJlYXMgb3IgYW55IGNvbWJpbmF0aW9uIG9mIHRoZSBhYm92ZS4gIEZvciB0aGUgc2Fr
ZSBvZiBzaW1wbGljaXR5LA0KICAgZWFjaCByb3V0aW5nIGRvbWFpbiB3aWxsIGJlIGNvbnNpZGVy
ZWQgYXMgc2luZ2xlIGFyZWEgaW4gdGhpcw0KICAgZG9jdW1lbnQuICINCg0KLT4gbm90IHN1cmUg
dG8gdW5kZXJzdGFuZCB0aGUgcmVhc29uaW5nLCBhdCB0aGUgZW5kIHRoZXNlIGV4YW1wbGVzIG11
c3QNCnJlbWFpbiBpbGx1c3RyYXRpdmUgYW5kIG5vdCByZXN0cmljdCBhcHBsaWNhYmlsaXR5IC0g
YWxsIHRoZXNlIHR1dG9yaWFsDQpsaWtlIG1hdGVyaWFsIHNob3VsZCBiZXR0ZXIgZ28gaW4gYW4g
YXBwZW5kaXggLQ0KDQpzZWN0aW9uIDMuMSAiSW4gYW55IGNhc2UsDQogICBubyB0b3BvbG9neSBv
ciByZXNvdXJjZSBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBkaXN0cmlidXRlZCBiZXR3ZWVuDQog
ICBkb21haW5zIChhcyBtYW5kYXRlZCBwZXIgW1JGQzQxMDVdIGFuZCBbUkZDNDIxNl0pLCB3aGlj
aCBpcyBjcml0aWNhbA0KICAgdG8gcHJlc2VydmUgSUdQL0JHUCBzY2FsYWJpbGl0eSBhbmQgY29u
ZmlkZW50aWFsaXR5IGluIHRoZSBjYXNlIG9mIFRFDQogICBMU1BzIHNwYW5uaW5nIG11bHRpcGxl
IHJvdXRpbmcgZG9tYWlucy4iDQoNCnRoZW4gU2VjdGlvbiA0DQoiSW4gdGVybXMgb2YgY29tcHV0
YXRpb24gb2YgYW4gaW50ZXItQVMgVEUgTFNQIHBhdGgsIGFuIGludGVyZXN0aW5nDQogICBvcHRp
bWl6YXRpb24gdGVjaG5pcXVlIGNvbnNpc3RzIG9mIGFsbG93aW5nIHRoZSBBU0JScyB0byBmbG9v
ZCB0aGUgVEUNCiAgIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlIGludGVyLUFTQlIgbGluayhz
KSBhbHRob3VnaCBubyBJR1AgVEUgaXMNCiAgIGVuYWJsZWQgb3ZlciB0aG9zZSBsaW5rcyAoYW5k
IHNvIHRoZXJlIGlzIG5vIElHUCBhZGphY2VuY3kgb3ZlciB0aGUNCiAgIGludGVyLUFTQlIgbGlu
a3MpLiAgLi4uDQoiVGhhbmtzIHRvIHN1Y2ggYW4gb3B0aW1pemF0aW9uLCB0aGUgaW50ZXItQVNC
UnMgVEUgbGluayBpbmZvcm1hdGlvbg0KICAgY29ycmVzcG9uZGluZyB0byB0aGUgbGlua3Mgb3Jp
Z2luYXRlZCBieSB0aGUgQVNCUiBpcyBtYWRlIGF2YWlsYWJsZQ0KICAgaW4gdGhlIFRFRCBvZiBv
dGhlciBMU1JzIGluIHRoZSBzYW1lIGRvbWFpbiB0aGF0IHRoZSBBU0JSIGJlbG9uZ3MgdG8uIg0K
DQpidXQgYWZ0ZXINCiJOb3RlIHRoYXQgbm8gdG9wb2xvZ3kNCiAgIGluZm9ybWF0aW9uIGlzIGZs
b29kZWQgYW5kIHRoZXNlIGxpbmtzIGFyZSBub3QgdXNlZCBpbiBJR1AgU1BGDQogICBjb21wdXRh
dGlvbnMuICBPbmx5IHRoZSBURSBpbmZvcm1hdGlvbiBmb3IgdGhlIG91dGdvaW5nIGxpbmtzDQog
ICBkaXJlY3RseSBjb25uZWN0ZWQgdG8gdGhlIEFTQlIgaXMgYWR2ZXJ0aXNlZC4iDQoNCi0+IGNh
biBvbmUgb2YgdGhlIGF1dGhvciBjbGFyaWZ5IDEpIGlzIGZsb29kaW5nIGludm9sdmVkIG9yIG5v
dCA/DQoyKSB3aGF0IGdldCdzIGZsb29kZWQgYW5kIHVuZGVyIHdoaWNoIGNvbmRpdGlvbnMgMykg
d2hhdCBpcyB0aGUgDQpzY29wZSBvZiB0aGUgZmxvb2RpbmcgNCkgaG93IHRoaXMgbWVjaGFuaXNt
IHBvc2l0aW9ucyBhZ2FpbnN0IHRoZQ0KcmVxdWlyZW1lbnRzIG9mIDQxMDUgYW5kIDQyMTYNCg0K
DQpvKSBhIGNvdXBsZSBvZiBlZGl0cw0KIA0Kc2VjdGlvbiAxOg0KDQpBQlIgUm91dGVyLCBBU0JS
IFJvdXRlciAtIHJlZHVuZGFudCBSDQoNCnRoZSBtb3N0IGltcG9ydGFudCBkZWYuIGlzIHRoZSAi
ZG9tYWluIiBkZWYuIHdoaWNoIGNhbiBiZSBmb3VuZCBpbiB0aGUNCmZybSBkb2MgYnV0IG5vdCBy
ZWNvcmRlZCBoZXJlIHRoaXMgd291bGQgY2xhcmlmeSBzZW50ZW5jZSBsaWtlDQoNCiJUaGUgbWVj
aGFuaXNtcyBwcm9wb3NlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBhbHNvIGFwcGxpY2FibGUgdG8g
TVBMUw0KIFRFIGRvbWFpbnMgb3RoZXIgdGhhbiBJR1AgYXJlYXMgYW5kIEFTcy4iDQoNCnJlZi4g
SC1MU1AgYW5kIFMtTFNQIHdpdGggdGhlIGFwcHJvcHJpYXRlIGRvY3MNCg0Kc3RhdGUgdGhhdCBp
bnRlci1kb21haW4gcmVjb3ZlcnkgaXMgZ29pbmcgdG8gYmUgYWRkcmVzc2VkIGluIGEgc2V0IG9m
DQpzcGVjaWZpYyBkb2NzDQoNCmhvcGUgdGhpcyB3aWxsIGhlbHAsDQotIGQuDQoNCg0KDQoNCiJB
ZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az4NClNlbnQgYnk6IG93bmVyLWNjYW1w
QG9wcy5pZXRmLm9yZw0KMDkvMDEvMjAwNyAyMzoxMw0KUGxlYXNlIHJlc3BvbmQgdG8gIkFkcmlh
biBGYXJyZWwiDQogDQogICAgICAgIFRvOiAgICAgPGNjYW1wQG9wcy5pZXRmLm9yZz4NCiAgICAg
ICAgY2M6IA0KICAgICAgICBTdWJqZWN0OiAgICAgICAgUHJvZ3Jlc3NpbmcgdGhlIHRocmVlIGlu
dGVyLWRvbWFpbiBJLURzDQoNCg0KSGksDQoNCldlIG5vdyBoYXZlIHVwZGF0ZWQgdmVyc2lvbnMg
b2YgdGhlIHRocmVlIGludGVyLWRvbWFpbiBzaWduYWxpbmcgSS1EczoNCg0KLSBkcmFmdC1pZXRm
LWNjYW1wLWludGVyLWRvbWFpbi1yc3ZwLXRlLTA0LnR4dA0KLSBkcmFmdC1pZXRmLWNjYW1wLWxz
cC1zdGl0Y2hpbmctMDQudHh0DQotIGRyYWZ0LWlldGYtY2NhbXAtaW50ZXItZG9tYWluLXBkLXBh
dGgtY29tcC0wMy50eHQNCg0KT3VyIHBsYW4gaXM6DQoxLiBXRyBjaGFpcnMgZG8gZGV0YWlsZWQg
cmV2aWV3IG92ZXIgdGhlIG5leHQgY291cGxlIG9mIHdlZWtzDQoyLiBFZGl0b3JzIGFwcGx5IG5l
Y2Vzc2FyeSB1cGRhdGVzDQozLiBXZSBob2xkIGEgV0cgbGFzdCBjYWxsIGZvciB0aGUgdGhyZWUg
SS1EcyB0b2dldGhlcg0KDQpJZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gdGhpcyB3b3JrLCBJIHN1
Z2dlc3QgdGhhdCBub3cgbWlnaHQgYmUgYSBnb29kIA0KdGltZSANCnRvIHJlbWluZCB5b3Vyc2Vs
ZiBhYm91dCB0aGUgSS1EcywgaGF2ZSBhIGdvb2QgcmVhZCwgYW5kIHNlZSBpZiB5b3UgY2FuIA0K
Z2V0IA0KYW55IHN1YnN0YW50aWFsIGNvbW1lbnRzIGluIHRvIGNvaW5jaWRlIHdpdGggdGhlIFdH
IGNoYWlycycgcmV2aWV3Lg0KDQpUaGFua3MsDQpBZHJpYW4gDQoNCg0KDQoNCg0KDQo=





Envelope-to: [e-mail]
Delivery-date: Sat, 13 Jan 2007 14:58:37 +0000
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Oi2AHGnxIJGi6NxaX4W4GkoyCiQuA7tFaMkoYn7wCTBrtQrMHnOO82YMAZl278kK6MXT5/2CyS5ts9KFMCyjirOf9JCRzXD0oTqg58mK3xJoMNZN8VLEz+hevTFF0B0ixGy659oLyIcSr0dX3kHMsPDoaIM0GFMzzgnZe+ezwcw=
Message-ID: <[e-mail]>
Date: Sat, 13 Jan 2007 09:55:43 -0500
From: "Peng He" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: Progressing the three inter-domain I-Ds
Cc: "Adrian Farrel" <[e-mail]>, [e-mail],  [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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, [e-mail]
<[e-mail]> 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" <[e-mail]>
> Sent by: [e-mail]
> 09/01/2007 23:13
> Please respond to "Adrian Farrel"
>
>         To:     <[e-mail]>
>         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: [e-mail]
Delivery-date: Sat, 13 Jan 2007 11:50:38 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Progressing the three inter-domain I-Ds
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 13 Jan 2007 12:49:30 +0100
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

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" <[e-mail]>
Sent by: [e-mail]
09/01/2007 23:13
Please respond to "Adrian Farrel"
=20
        To:     <[e-mail]>
        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








Envelope-to: [e-mail]
Delivery-date: Sat, 13 Jan 2007 11:43:03 +0000
Message-ID: <005701c73707$84efdf40$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Derek Atkins" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: draft-ietf-ccamp-rsvp-restart-ext-06
Date: Sat, 13 Jan 2007 11:39:21 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
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
>       [e-mail]             www.ihtfp.com
>       Computer and Internet Security Consultant
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Fri, 12 Jan 2007 21:34:43 +0000
To: Jaudelice Cavalcante de Oliveira <[e-mail]>
Cc: [e-mail], Jaudelice Cavalcante de Oliveira <[e-mail]>, JP Vasseur <[e-mail]>, [e-mail], [e-mail], Ross Callon <[e-mail]>
Subject: Re: [mpls] Re: CCAMP Last call on	draft-deoliveira-diff-te-preemption-06.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 12 Jan 2007 22:31:37 +0100
Content-Type: text/plain; charset="US-ASCII"

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 
<[e-mail]>

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 <[e-mail]>
05/01/2007 00:11
 
        To:     [e-mail]
        cc:     [e-mail], JP Vasseur <[e-mail]>, 
[e-mail], Jaudelice Cavalcante de Oliveira 
<[e-mail]>, Ross Callon <[e-mail]>, 
[e-mail]
        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, [e-mail] 
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" <[e-mail]>
> Sent by: [e-mail]
> 14/12/2006 18:02
> Please respond to "Adrian Farrel"
>
>         To:     <[e-mail]>
>         cc:     <[e-mail]>, "Ross Callon"
> <[e-mail]>, "Brungard, Deborah A, ALABS" 
> <[e-mail]>,
> <[e-mail]>
>         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" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>; "Ross Callon" <[e-mail]>;
> "Brungard, Deborah A, ALABS" <[e-mail]>; 
> <[e-mail]>
> 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: <[e-mail]>
>> To: <[e-mail]>
>> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls





Envelope-to: [e-mail]
Delivery-date: Tue, 09 Jan 2007 22:14:50 +0000
Message-ID: <0cee01c7343b$6870b480$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Progressing the three inter-domain I-Ds
Date: Tue, 9 Jan 2007 22:13:10 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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: [e-mail]
Delivery-date: Tue, 09 Jan 2007 20:52:37 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-04.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Tue, 09 Jan 2007 15:55:45 +0000
Message-ID: <0a2f01c7337b$0ec2f440$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Posting of IPR Disclosure
Date: Mon, 8 Jan 2007 23:16:33 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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

Thanks,
Adrian
----- Original Message ----- 
From: "IETF Secretariat" <[e-mail]>
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






Envelope-to: [e-mail]
Delivery-date: Mon, 08 Jan 2007 23:19:21 +0000
Message-ID: <0a2f01c7337b$0ec2f440$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Posting of IPR Disclosure
Date: Mon, 8 Jan 2007 23:16:33 -0000
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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

Thanks,
Adrian
----- Original Message ----- 
From: "IETF Secretariat" <[e-mail]>
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





Envelope-to: [e-mail]
Delivery-date: Thu, 04 Jan 2007 20:52:29 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-03.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Wed, 03 Jan 2007 21:10:24 +0000
Message-ID: <034f01c72f7b$80a29510$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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





Envelope-to: [e-mail]
Delivery-date: Wed, 03 Jan 2007 20:52:52 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-02.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--