Subject: RE: [PWE3] RSVP MS-PW ? HOW?

From: [email-masked]
Date: Thu, 1 Dec 2005 10:43:55 -0000

Luca....snipped....
> >
> Ben=> Your argument appears to be: why bother traffic engineering 
> the client 
> > (i.e. the MS-PW layer network) when we have already traffic 
> engineered 
> > the server (the IP/MPLS layer networks) and this is the 
> argument that 
> > I don't really follow or fully understand.
> >
> > MS-PWs are a separate layer network to the MPLS (or IP) layer 
> > network(s) that they run over.  So, a MS-PW link (between a 
> U-PE and a 
> > S-PE or between two S-PEs) is supported by a concatenation 
> of MPLS (or 
> > IP) links.  This is no different to any other client/server 
> > relationship between any pair of layer network technologies.
> >
> > So, following your logic I could argue, why bother traffic 
> engineering 
> > an MPLS network when you've already traffic engineered the 
> SONET/SDH 
> > network that it runs over?
> >
> >   
> Luca=>In fact you usually do both...
NH=> Not sufficient....you do it in all the co mode layer
networks......timecsales differ as you note below....they are the
longest at the duct level.

> The SDH network traffic 
> engineering cycle 
> might be 30 days , while the client MPLS network  might be traffic 
> engineered every 10 minutes .
> Also the granularity is quite different between the two layers.
NH=> Good.  This is a fairly concrete statement that the routing process
in each layer network is quite different.  In other words, there cannot
be a single instance of routing running IP to Optics.  So, I assume you
agree that the routing process required in the newly being created PW
layer network is different to that for the MPLS/IP (joined at the hip)
layer networks is different to that running in the SDH layer networks
(VC4 layer is different to VC12 layer please note)...etc to the duct.

Further, given client/server layer networks relationships are usually
(i) not topologically congruent and (ii) are often owned by different
parties then this makes it patently clear there cannot be a single
routing process involved....or in other words, the notion of a truly
common control-plane is clearly unworkable.

Do you agree?

regards, Neil

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

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 1 Dec 2005 07:17:07 -0800

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: Wednesday, November 30, 2005 5:37 PM
> To: Drake, John E
> Cc: PWE3 WG (E-mail)
> Subject: Re: [PWE3] RSVP MS-PW ? HOW?
> 
> Drake, John E wrote:
> > Snipped...
> >
> >
> >> GMPLS resolves some of these problems, however there are 2 major
> >> differences I can see:
> >> 1) GMPLS is used hop by hop in the PSN.
> >>
> > [JD]
> >
> > See RFC 4206.
> >
> the question is how can you do SONET stacking ?
[JD] 

I don't see any relation between the statement you made above, which
incorrectly indicated that GMPLS control messages go hop by hop, and
your question about SONET.

But the answer to your question is yes.

> with 4206 , you can only connect compatible interface types across the
> GMPLS network.
[JD] 

If you mean interfaces switching capability, your statement is correct.

> Would it not be useful to use a PW to connect , say two ethernet LSPs
> inside a nested RSVP-Te session....
[JD] 

What makes you think that this is precluded?    

> 
> >
> >> 2) IP addressing of GMPLS nodes is reserved, and not used for IP
> >>
> > traffic
> >
> >> - other then control traffic.
> >>
> > [JD]
> >
> > What does this statement mean
> I just meant that the Internet would probably not be directly
connected
> to the IP control plane of a GMPLS network.
> We could have some interesting issue if we sent large amount of IP
> traffic through the GMPLS control plane ...
[JD] 

Are you saying that an ISP would have to have a separate network for its
control plane traffic?
 
> Luca

---

From: [email-masked]
Date: Thu, 1 Dec 2005 15:47:01 -0000

Someone has pointed out to me that I should perhaps clarify one point of
my response....please see the inserted Note in-line below

Harrison,N,Neil, wrote 01 December 2005 10:44
<snipped>

> 
> Luca=> The SDH network traffic
> > engineering cycle 
> NH=> Good.  This is a fairly concrete statement that the 
> routing process in each layer network is quite different.  In 
> other words, there cannot be a single instance of routing 
> running IP to Optics.  So, I assume you agree that the 
> routing process required in the newly being created PW layer 
> network is different to that for the MPLS/IP (joined at the 
> hip) layer networks is different to that running in the SDH 
> layer networks (VC4 layer is different to VC12 layer please 
> note)...etc to the duct.
> 
> Further, given client/server layer networks relationships are 
> usually (i) not topologically congruent and (ii) are often 
> owned by different parties then this makes it patently clear 
> there cannot be a single routing process involved....or in 
> other words, the notion of a truly common control-plane is 
> clearly unworkable.

NH=> Note:  The word 'truly' in the last sentence above is meant to
imply 'a single instance (of a common control-plane)'.  There is no
problem whatsoever is reusing the same signalling protocol for both
co-ps and co-cs modes.  Moreover, given the co-cs mode forces the
control/management plane OOB, then this has major benefits (in
stability/security/reslience design facets) that should be important for
operators.  So whilst the control-plane of a co-cs layer network and a
co-ps mode layer network are not the SAME INSTANCE, they could (and
should) be based on the same architectural design principles.  This is
what I'd regard as sensible functional convergence.

Hope that clarifies what I meant.

regards, Neil

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 1 Dec 2005 11:11:20 -0500

John,

	Sending traffic "through the GMPLS control plane" does
not imply a separate network for control plane traffic.  If
non-control traffic is addressed at LSP end-points to a local
control processor, this is a control plane burden, even if the
implied processing requirements are small.

	I am not saying that this happens, but this is what Luca
seems to be talking about...

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Drake, John E
--> Sent: Thursday, December 01, 2005 10:17 AM
--> To: Luca Martini
--> Cc: PWE3 WG (E-mail)
--> Subject: RE: [PWE3] RSVP MS-PW ? HOW?
--> 
--> 
--> 
--> > -----Original Message-----
--> > From: Luca Martini [mailto:[email-masked]]
--> > Sent: Wednesday, November 30, 2005 5:37 PM
--> > To: Drake, John E
--> > Cc: PWE3 WG (E-mail)
--> > Subject: Re: [PWE3] RSVP MS-PW ? HOW?
--> > 
--> > Drake, John E wrote:
--> > > Snipped...
--> > >
--> > >
--> > >> GMPLS resolves some of these problems, however there 
--> are 2 major
--> > >> differences I can see:
--> > >> 1) GMPLS is used hop by hop in the PSN.
--> > >>
--> > > [JD]
--> > >
--> > > See RFC 4206.
--> > >
--> > the question is how can you do SONET stacking ?
--> [JD] 
--> 
--> I don't see any relation between the statement you made above, which
--> incorrectly indicated that GMPLS control messages go hop by hop, and
--> your question about SONET.
--> 
--> But the answer to your question is yes.
--> 
--> > with 4206 , you can only connect compatible interface 
--> types across the
--> > GMPLS network.
--> [JD] 
--> 
--> If you mean interfaces switching capability, your statement 
--> is correct.
--> 
--> > Would it not be useful to use a PW to connect , say two 
--> ethernet LSPs
--> > inside a nested RSVP-Te session....
--> [JD] 
--> 
--> What makes you think that this is precluded?    
--> 
--> > 
--> > >
--> > >> 2) IP addressing of GMPLS nodes is reserved, and not 
--> used for IP
--> > >>
--> > > traffic
--> > >
--> > >> - other then control traffic.
--> > >>
--> > > [JD]
--> > >
--> > > What does this statement mean
--> > I just meant that the Internet would probably not be directly
--> connected
--> > to the IP control plane of a GMPLS network.
--> > We could have some interesting issue if we sent large amount of IP
--> > traffic through the GMPLS control plane ...
--> [JD] 
--> 
--> Are you saying that an ISP would have to have a separate 
--> network for its
--> control plane traffic?
-->  
--> > 
--> > Luca
--> > 
--> > 
--> 
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
-->

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 1 Dec 2005 08:38:15 -0800

Shahram,

This is a very sensible note.

Thanks,

John

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, December 01, 2005 7:41 AM
> To: 'Luca Martini'; Nurit Sprecher
> Cc: PWE3 WG (E-mail)
> Subject: RE: [PWE3] RSVP MS-PW ? HOW?
> 
> Hi Luca,
> 
> >From your statements (shown below), I get the impression that
> your definition of PW TE is different from many others.
> 
> It seems that your definition of PW TE is that the U-PE selects
> the S-PEs that the PW should travel through, and since you think
> in most cases there is only a single set of S-PEs that the PW
> can travel through, then there is no need for PW TE.
> 
> In my opinion there are two problems with such assumption/definition:
> 
> 1) It is not wise to assume that there is only a single S-PE route
(note:
> a route consists of a set of concatenated S-PEs) for a PW. You at
least
> need two routes for backup against any S-PE or domain failure, if not
for
> any other reason.
> 
> 2) There could be many MPLS tunnels between any two S-PE. How can one
of
> these
> S-PEs decide which tunnel to use for a specific PW? You need a
signaling
> that
> includes BW requirements of the PW and permits an upstream S-PE to
select
> one of
> the MPLS tunnels to a downstream S-PE.
> 
> I think you should convince the WG how you propose to solve these two
> problems.
> 
> Thanks,
> Shahram
> 
> 
> 
> > Yes, of course , but this is not traffic engineering of the
> > pseudo wire.
> > All you are describing is transporting opaque information in
> > a signaling
> > protocol  to properly request the correct resources from the MPLS
PSN.
> 
> 
> > I was not talking about selecting the tunnel here. I was
> > talking about
> > selecting the S-PE.
> 
> > > Traffic engineering of PW would mean that S-PEs are
> > selected based on
> > > available bandwidth to reach them.
> > >
> 
> 
> >Please look at the architecture document. there is no "best" route
> >selection as there is only one route in most cases.
>

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 1 Dec 2005 11:55:13 -0500

John,

	If I understand the issue, GMPLS is used "generally"
- i.e. - applying to non-IP, as well as to IP, traffic. In
a GMPLS deployment instance/domain, where GMPLS signaling
is being used to control non-IP traffic, it is very likely
that GMPLS nodes will use IP addresses only to talk amongst
themselves.

	His original statement was:

"2) IP addressing of GMPLS nodes is reserved, and not used 
    for IP traffic - other then control traffic.

In the case where GMPLS is being used to control non-IP
traffic - say for instance TDM time slots - communicating
across this domain using IP requires either explicitly
setup edge-to-edge IP "channels", or using the GMPLS nodes
as a transit conveyance (probably involving NAT).

	It's possible - as you were probably implying - that
Luca has over-looked the fact that there would have to be
channels established in this case to carry the normal IP
traffic from edge-to-edge anyway, and there is no reason
why those channels would not also be used for PW signaling
no matter which protocol is used.

--
Eric

--> -----Original Message-----
--> From: Drake, John E [mailto:[email-masked]] 
--> Sent: Thursday, December 01, 2005 11:34 AM
--> To: Gray, Eric
--> Cc: PWE3 WG (E-mail)
--> Subject: RE: [PWE3] RSVP MS-PW ? HOW?
--> 
--> Eric,
--> 
--> I interpreted Luca's statement to be that if the GMPLS control plane
--> shared the same physical network resources used for IP packet
--> forwarding, it would have big problems(tm).
--> 
--> If that is true, why don't we have the same concern with an 
--> MPLS control
--> plane or even the control plane for a vanilla IP network?
--> 
--> Thanks,
--> 
--> John 
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Thursday, December 01, 2005 8:11 AM
--> > To: Drake, John E
--> > Cc: PWE3 WG (E-mail)
--> > Subject: RE: [PWE3] RSVP MS-PW ? HOW?
--> > 
--> > John,
--> > 
--> > 	Sending traffic "through the GMPLS control plane" does
--> > not imply a separate network for control plane traffic.  If
--> > non-control traffic is addressed at LSP end-points to a local
--> > control processor, this is a control plane burden, even if the
--> > implied processing requirements are small.
--> > 
--> > 	I am not saying that this happens, but this is what Luca
--> > seems to be talking about...
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: [email-masked] [mailto:[email-masked]]
--> > --> On Behalf Of Drake, John E
--> > --> Sent: Thursday, December 01, 2005 10:17 AM
--> > --> To: Luca Martini
--> > --> Cc: PWE3 WG (E-mail)
--> > --> Subject: RE: [PWE3] RSVP MS-PW ? HOW?
--> > -->
--> > -->
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Luca Martini [mailto:[email-masked]]
--> > --> > Sent: Wednesday, November 30, 2005 5:37 PM
--> > --> > To: Drake, John E
--> > --> > Cc: PWE3 WG (E-mail)
--> > --> > Subject: Re: [PWE3] RSVP MS-PW ? HOW?
--> > --> >
--> > --> > Drake, John E wrote:
--> > --> > > Snipped...
--> > --> > >
--> > --> > >
--> > --> > >> GMPLS resolves some of these problems, however there
--> > --> are 2 major
--> > --> > >> differences I can see:
--> > --> > >> 1) GMPLS is used hop by hop in the PSN.
--> > --> > >>
--> > --> > > [JD]
--> > --> > >
--> > --> > > See RFC 4206.
--> > --> > >
--> > --> > the question is how can you do SONET stacking ?
--> > --> [JD]
--> > -->
--> > --> I don't see any relation between the statement you made above,
--> which
--> > --> incorrectly indicated that GMPLS control messages go 
--> hop by hop,
--> and
--> > --> your question about SONET.
--> > -->
--> > --> But the answer to your question is yes.
--> > -->
--> > --> > with 4206 , you can only connect compatible interface
--> > --> types across the
--> > --> > GMPLS network.
--> > --> [JD]
--> > -->
--> > --> If you mean interfaces switching capability, your statement
--> > --> is correct.
--> > -->
--> > --> > Would it not be useful to use a PW to connect , say two
--> > --> ethernet LSPs
--> > --> > inside a nested RSVP-Te session....
--> > --> [JD]
--> > -->
--> > --> What makes you think that this is precluded?
--> > -->
--> > --> >
--> > --> > >
--> > --> > >> 2) IP addressing of GMPLS nodes is reserved, and not
--> > --> used for IP
--> > --> > >>
--> > --> > > traffic
--> > --> > >
--> > --> > >> - other then control traffic.
--> > --> > >>
--> > --> > > [JD]
--> > --> > >
--> > --> > > What does this statement mean
--> > --> > I just meant that the Internet would probably not 
--> be directly
--> > --> connected
--> > --> > to the IP control plane of a GMPLS network.
--> > --> > We could have some interesting issue if we sent 
--> large amount of
--> IP
--> > --> > traffic through the GMPLS control plane ...
--> > --> [JD]
--> > -->
--> > --> Are you saying that an ISP would have to have a separate
--> > --> network for its
--> > --> control plane traffic?
--> > -->
--> > --> >
--> > --> > Luca
--> > --> >
--> > --> >
--> > -->
--> > -->
--> > --> _______________________________________________
--> > --> pwe3 mailing list
--> > --> [email-masked]
--> > --> https://www1.ietf.org/mailman/listinfo/pwe3
--> > -->
-->

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 1 Dec 2005 11:01:33 -0800

Eric,

I see what you and Luca were getting at.  Routing IP packets across the
control channels between TDM or Lambda switches *might* be an issue.

However, it would only be an issue in a peer model deployment (which
will never happen 8->), and as you point out, there would be LSPs of
type PSC established across the non-IP data plane core and these LSPs
would be used for forwarding IP packets.

It is also the case that the control channels between the TDM or Lambda
switches might be instantiated over paths that contain these PSC links.

In the packet portion of a GMPLS network, the control channels might
very well share the same physical network resources used for forwarding
IP packets.

Thanks,

John

> From: Gray, Eric [mailto:[email-masked]]
> Sent: Thursday, December 01, 2005 8:55 AM
> To: Drake, John E
> Cc: PWE3 WG (E-mail)

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 1 Dec 2005 11:28:21 -0800

Snipped...

> > Hmmm.  Not sure I see how TE in the MPLS (server) layer
automatically
> > provides plentiful bandwidth (and negates the need for TE) in the PW
> > layer as there may not be a 1:1 mapping between PWs & MPLS LSPs.
> >
> > If you want to guarantee bandwidth at the PW layer then you need
some
> > way to select a path with an appropriate level of spare bandwidth
(which
> > may not be the SPF path) and to signal the bandwidth guarantee that
you
> > require along that path (or reserve it using OSS) at the PW layer -
> > that's what I'd call TE.  Does your definition vary from mine?
> >
> >
> Yes. That is exactly the point I was trying to make. You do need some
> way to signal the bandwidth requirements of a PW, however
> traffic engineering requires a lot more then just signaling bandwidth.
> Traffic engineering requires a full picture of all available links and
> resources, a constrained SPF Function, and the ability to signal an
> explicit path/resources required.
[JD] 

So, you are saying that none of these functions will be required in a MS
PW layer network?  I think it might be useful for Stewart and Danny to
ask the working group whether there is consensus on this point.

As an aside, doesn't the MS PW LDP I-D have an Explicit Route object?
In the absence of "a full picture of all available links and resources,
a constrained SPF Function, and the ability to signal an explicit
path/resources required", how will this Explicit Route object be used?

---

From: "Nurit Sprecher" <[email-masked]>
Date: Fri, 2 Dec 2005 01:08:28 +0200

Luca,
What is the motivation for different routing topologies for different applications (else then resources)?
I can see benefits in having the control and the management packets for example in the same topology (e.g. size of the routing table, easier management with no interpretation, etc).
Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Luca Martini
Sent: Friday, December 02, 2005 00:52
To: Drake, John E
Cc: PWE3 WG (E-mail)
Subject: Re: [PWE3] RSVP MS-PW ? HOW?

Drake, John E wrote:
> Eric,
>
> I interpreted Luca's statement to be that if the GMPLS control plane
> shared the same physical network resources used for IP packet
> forwarding, it would have big problems(tm).
>
>  
The resources are not the issue. More like the fact the we might want
different routing topologies for different applications.

Luca

> If that is true, why don't we have the same concern with an MPLS control
> plane or even the control plane for a vanilla IP network?
>
> Thanks,
>
> John
>
>  
>> Sent: Thursday, December 01, 2005 8:11 AM
>> To: Drake, John E
>> Cc: PWE3 WG (E-mail)
>> --> I don't see any relation between the statement you made above,
>>    
> which
>  
>> --> incorrectly indicated that GMPLS control messages go hop by hop,
>>    
> and
>  
>> --> > We could have some interesting issue if we sent large amount of
>>    
> IP
>

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 1 Dec 2005 18:30:41 -0500

Nurit,

	One point of inadvertently injected confusion in
this discussion is the merging of the terms "resources"
and "traffic engineering" in much of the discussion 
leading up to this point.

	There are plenty of "traffic engineering" reasons
for routing traffic along differentiated paths that are
not directly related to resources.  Similarly, there are
"resource" related reasons for routing traffic that have
very little to do with "traffic engineering."

--
Eric 

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Nurit Sprecher
--> Sent: Thursday, December 01, 2005 6:08 PM
--> To: Luca Martini; Drake, John E
--> Cc: PWE3 WG (E-mail)
--> Subject: RE: [PWE3] RSVP MS-PW ? HOW?
--> 
--> Luca,
--> What is the motivation for different routing topologies for 
--> different applications (else then resources)?
--> I can see benefits in having the control and the management 
--> packets for example in the same topology (e.g. size of the 
--> routing table, easier management with no interpretation, etc).
--> Nurit.
--> 
--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On Behalf Of Luca Martini
--> Sent: Friday, December 02, 2005 00:52
--> To: Drake, John E
--> Cc: PWE3 WG (E-mail)
--> Subject: Re: [PWE3] RSVP MS-PW ? HOW?
--> 
--> Drake, John E wrote:
--> > Eric,
--> >
--> > I interpreted Luca's statement to be that if the GMPLS 
--> control plane
--> > shared the same physical network resources used for IP packet
--> > forwarding, it would have big problems(tm).
--> >
--> >  
--> The resources are not the issue. More like the fact the we 
--> might want
--> different routing topologies for different applications.
--> 
--> Luca
--> 
--> > If that is true, why don't we have the same concern with 
--> an MPLS control
--> > plane or even the control plane for a vanilla IP network?
--> >
--> > Thanks,
--> >
--> > John
--> >
--> >  
--> >> -----Original Message-----
--> >> From: Gray, Eric [mailto:[email-masked]]
--> >> Sent: Thursday, December 01, 2005 8:11 AM
--> >> To: Drake, John E
--> >> Cc: PWE3 WG (E-mail)
--> >> Subject: RE: [PWE3] RSVP MS-PW ? HOW?
--> >>
--> >> John,
--> >>
--> >>      Sending traffic "through the GMPLS control plane" does
--> >> not imply a separate network for control plane traffic.  If
--> >> non-control traffic is addressed at LSP end-points to a local
--> >> control processor, this is a control plane burden, even if the
--> >> implied processing requirements are small.
--> >>
--> >>      I am not saying that this happens, but this is what Luca
--> >> seems to be talking about...
--> >>
--> >> --
--> >> Eric
--> >>
--> >> --> -----Original Message-----
--> >> --> From: [email-masked] [mailto:[email-masked]]
--> >> --> On Behalf Of Drake, John E
--> >> --> Sent: Thursday, December 01, 2005 10:17 AM
--> >> --> To: Luca Martini
--> >> --> Cc: PWE3 WG (E-mail)
--> >> --> Subject: RE: [PWE3] RSVP MS-PW ? HOW?
--> >> -->
--> >> -->
--> >> -->
--> >> --> > -----Original Message-----
--> >> --> > From: Luca Martini [mailto:[email-masked]]
--> >> --> > Sent: Wednesday, November 30, 2005 5:37 PM
--> >> --> > To: Drake, John E
--> >> --> > Cc: PWE3 WG (E-mail)
--> >> --> > Subject: Re: [PWE3] RSVP MS-PW ? HOW?
--> >> --> >
--> >> --> > Drake, John E wrote:
--> >> --> > > Snipped...
--> >> --> > >
--> >> --> > >
--> >> --> > >> GMPLS resolves some of these problems, however there
--> >> --> are 2 major
--> >> --> > >> differences I can see:
--> >> --> > >> 1) GMPLS is used hop by hop in the PSN.
--> >> --> > >>
--> >> --> > > [JD]
--> >> --> > >
--> >> --> > > See RFC 4206.
--> >> --> > >
--> >> --> > the question is how can you do SONET stacking ?
--> >> --> [JD]
--> >> -->
--> >> --> I don't see any relation between the statement you 
--> made above,
--> >>    
--> > which
--> >  
--> >> --> incorrectly indicated that GMPLS control messages go 
--> hop by hop,
--> >>    
--> > and
--> >  
--> >> --> your question about SONET.
--> >> -->
--> >> --> But the answer to your question is yes.
--> >> -->
--> >> --> > with 4206 , you can only connect compatible interface
--> >> --> types across the
--> >> --> > GMPLS network.
--> >> --> [JD]
--> >> -->
--> >> --> If you mean interfaces switching capability, your statement
--> >> --> is correct.
--> >> -->
--> >> --> > Would it not be useful to use a PW to connect , say two
--> >> --> ethernet LSPs
--> >> --> > inside a nested RSVP-Te session....
--> >> --> [JD]
--> >> -->
--> >> --> What makes you think that this is precluded?
--> >> -->
--> >> --> >
--> >> --> > >
--> >> --> > >> 2) IP addressing of GMPLS nodes is reserved, and not
--> >> --> used for IP
--> >> --> > >>
--> >> --> > > traffic
--> >> --> > >
--> >> --> > >> - other then control traffic.
--> >> --> > >>
--> >> --> > > [JD]
--> >> --> > >
--> >> --> > > What does this statement mean
--> >> --> > I just meant that the Internet would probably not 
--> be directly
--> >> --> connected
--> >> --> > to the IP control plane of a GMPLS network.
--> >> --> > We could have some interesting issue if we sent 
--> large amount of
--> >>    
--> > IP
--> >  
--> >> --> > traffic through the GMPLS control plane ...
--> >> --> [JD]
--> >> -->
--> >> --> Are you saying that an ISP would have to have a separate
--> >> --> network for its
--> >> --> control plane traffic?
--> >> -->
--> >> --> >
--> >> --> > Luca
--> >> --> >
--> >> --> >
--> >> -->
--> >> -->
--> >> --> _______________________________________________
--> >> --> pwe3 mailing list
--> >> --> [email-masked]
--> >> --> https://www1.ietf.org/mailman/listinfo/pwe3
--> >> -->
--> >>    
--> >
--> > _______________________________________________
--> > pwe3 mailing list
--> > [email-masked]
--> > https://www1.ietf.org/mailman/listinfo/pwe3
--> >
--> >  
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
-->

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 2 Dec 2005 08:07:04 -0800

> Sent: Thursday, December 01, 2005 2:52 PM
> To: Drake, John E
> Cc: Gray, Eric; PWE3 WG (E-mail)
[JD] 

It seems like we have switched topics again, but this shouldn't be a
problem