Subject: Re: [Pce] PCEP ERO

From: Dhruv Dhody <[email-masked]>
Date: Mon, 16 Jun 2014 06:24:55 +0000

Attaching the figure in a pdf, in case you could not view in my previous mail.

Regards,
Dhruv

---------------------------------------------------------------
Dhruv Dhody
System Architect,
Huawei Technologies India Pvt. Ltd.,
Banagalore
Mobile: +91-9845062422
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

From: Dhruv Dhody
Sent: 16 June 2014 11:52
To: [email-masked]
Subject: PCEP ERO

Dear WG,

Consider the below topology, PCE computes a path from RTA to RTC.

This path maybe encoded in PCEP ERO as  -

~ (10.1.1.1, 10.1.1.2, 20.1.1.1, 20.1.1.2)

or

~ (10.1.1.2, 20.1.1.1, 20.1.1.2) [without local IP address of ingress]

IMO both should be considered as viable options.

Is there any reason for PCC to consider one of them as incorrect?

Regards,

Dhruv

---------------------------------------------------------------

Dhruv Dhody

System Architect,

Huawei Technologies India Pvt. Ltd.,

Banagalore

Mobile: +91-9845062422

---

From: Julien Meuric <[email-masked]>
Date: Mon, 16 Jun 2014 10:59:21 +0200

Hi Dhruv.

PCEP does not mandates more rules on ERO than RSVP-TE, which reminds me 
of an old discussion in CCAMP. You may want to have a look at 
http://tools.ietf.org/html/draft-farrel-ccamp-ero-survey-00 and dive 
into the associated thread back in 2006.

Julien

Jun. 16, 2014 - Dhruv Dhody:
> *Dhruv Dhody *
> *From:*Dhruv Dhody
> *Sent:* 16 June 2014 11:52
> *To:* [email-masked]
> *Subject:* PCEP ERO
>
> Dear WG,
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 16 Jun 2014 14:57:17 +0530

Hi Julien,

Thanks for the pointer, this surely helps.
Time to dive into the archives.....

Dhruv

On Mon, Jun 16, 2014 at 2:29 PM, Julien Meuric <[email-masked]> wrote:
> Hi Dhruv.
>
> PCEP does not mandates more rules on ERO than RSVP-TE, which reminds me of
> an old discussion in CCAMP. You may want to have a look at
> http://tools.ietf.org/html/draft-farrel-ccamp-ero-survey-00 and dive into
> the associated thread back in 2006.
>
> Julien
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 16 Jun 2014 12:33:23 +0100

Julien is right (of course).

This survey led (in part) to RFC 4990. section 6 may be what Dhruv is looking
for.

A nasty question lurking in the background is whether a PCC needs to indicate
which construction of ERO is prefers. Consider if the interface was CLI not
PCEP: in this case the supported construction of ERO is part of the CLI
definition. However, given that most of the ERO is not for local consumption and
does not need to be examined by the PCC, this question may be of debatable
value.

Adrian

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
> Sent: 16 June 2014 10:27
> To: Julien Meuric
> Cc: [email-masked]
> Subject: Re: [Pce] PCEP ERO
> 
> Hi Julien,
> 
> of

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 16 Jun 2014 17:36:13 +0530

Hi Adrian,

Yup, i found the text in RFC4990 helpful.

http://tools.ietf.org/html/rfc4990#section-6

   Implementations making limited assumptions about the content of an
   ERO or RRO when processing a received RSVP message may cause or
   experience interoperability issues.  Therefore, implementations that
   want to ensure full interoperability need to support the receipt for
   processing of all ERO and RRO options applicable to their hardware
   capabilities.

I agree with your analysis regarding the need to indicate an ERO
encoding preference in PCEP.
Unless every node in the path know the preference of the downstream
node the problem still exists (in RSVP-TE).
The ERO encoding preference of a downstream node may be learned via
IGP flooding perhaps but some might consider this a bit excessive?

Dhruv

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 16 Jun 2014 12:23:14 +0000

Hello,
You are right Julien and Adrian, this is a very old issue. One thing that has been missing IMO is a flag in a numbered/unnumbered link ERSO indicating whether the indicated side of the link is outbound or inbound wrt the path direction from its source to destination. The lack of said flag has been especially a problem when combined with the LOOSE flag. Consider, for example, the situation when a  1.1.24.1/loose is found in the ERO. If 1.1.24.1 interface is meant to be inbound, the path should *enter* the NE that terminates the interface. However, If 1.1.24.1 interface is meant to be outbound, the path should *exit*the said NE. So, if the ERO is specified as a path computation constraint, the PCE may produce very different resulting paths depending on the PCE's assumptions/ interpretations. The introduction of said flag would resolve the ambiguity and provide the flexibility (e.g. Druv is talking about) for the ERO encoding.

Regards,
Igor

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, June 16, 2014 7:33 AM
To: 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

This survey led (in part) to RFC 4990. section 6 may be what Dhruv is looking for.

A nasty question lurking in the background is whether a PCC needs to indicate which construction of ERO is prefers. Consider if the interface was CLI not
PCEP: in this case the supported construction of ERO is part of the CLI definition. However, given that most of the ERO is not for local consumption and does not need to be examined by the PCC, this question may be of debatable value.

Adrian

> On Mon, Jun 16, 2014 at 2:29 PM, Julien Meuric 
> <[email-masked]>
> wrote:
> > Hi Dhruv.
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 16 Jun 2014 14:59:51 +0100

OK, so this is an RSVP-TE question, not a PCEP one :-)

I am distracted at the moment because I am at the PACE workshop on Future Uses
of PCE http://www.craax.upc.edu/saconet2014/pace2014.html (twitter @paceict)

However...

I think that your question is not specific to unnumbered interfaces. Consider a
numbered interface that appears in an ERO. The interface is not a local address,
so it an address that applies to the "next hop". But is it an incoming or
outgoing interface at the next hop?

Well, the rule is "find a route to the next hop". So that inevitably means that
if you want to control the outgoing interface from a node, you need to include
some other hop information (ideally the incoming interface) as a hop earlier in
the ERO.

A

> From: Igor Bryskin [mailto:[email-masked]]
> Sent: 16 June 2014 13:23
> To: [email-masked]; 'Dhruv Dhody'; 'Julien Meuric'
> Cc: [email-masked]
> Subject: RE: [Pce] PCEP ERO
> 
> Hello,
> You are right Julien and Adrian, this is a very old issue. One thing that has
been
> missing IMO is a flag in a numbered/unnumbered link ERSO indicating whether
> the indicated side of the link is outbound or inbound wrt the path direction
from
> its source to destination. The lack of said flag has been especially a problem
when
> combined with the LOOSE flag. Consider, for example, the situation when a
> 1.1.24.1/loose is found in the ERO. If 1.1.24.1 interface is meant to be
inbound,
> the path should *enter* the NE that terminates the interface. However, If
> 1.1.24.1 interface is meant to be outbound, the path should *exit*the said NE.
> So, if the ERO is specified as a path computation constraint, the PCE may
produce
> very different resulting paths depending on the PCE's assumptions/
> interpretations. The introduction of said flag would resolve the ambiguity and
> provide the flexibility (e.g. Druv is talking about) for the ERO encoding.
> 
> Regards,
> Igor
> 
> 
for.
> PCEP: in this case the supported construction of ERO is part of the CLI
definition.
> However, given that most of the ERO is not for local consumption and does not
> need to be examined by the PCC, this question may be of debatable value.
> 
> Adrian
>

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 17 Jun 2014 02:16:39 +0000

Hi, Igor, 
  
  I think you raise up a good question. 

  Just wonder if the text in Section 6.1.2 of RFC4990 (copied below) touch upon the very same problem and provide some guidance? 

--------Section 6.1.2 of RFC4990   
There are two differences between Loose and Strict subobjects.

   o  A subobject marked as a loose hop in an ERO must not be followed
      by a subobject indicating a label value [RFC3473].

   o  A subobject marked as a loose hop in an ERO should never include
      an identifier (i.e., address or ID) of the outgoing interface.

   There is no way to specify in an ERO whether a subobject identifies
   an incoming or outgoing TE link.  Path computation must be performed
   by an LSR when it encounters a loose hop in order to resolve the LSP
   route to the identified next hop.  If an interface is specified as a
   loose hop and is treated as an incoming interface, the path
   computation will select a path that enters an LSR through that
   interface.  If the interface was intended to be used as an outgoing
   interface, the computed path may be unsatisfactory and the explicit
   route in the ERO may be impossible to resolve.  Thus a loose hop that
   identifies an interface should always identify the incoming TE link
   in the data plane.
-----------------

Regards,
Xian

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: 2014年6月16日 20:23
To: [email-masked]; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Hello,

Regards,
Igor

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, June 16, 2014 7:33 AM
To: 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Jun 2014 10:12:56 +0100

Good digging, Xian. Thanks.

That covers it better than my email (although the effect is the same :-)

Cheers,
Adrian

> From: Zhangxian (Xian) [mailto:[email-masked]]
> Sent: 17 June 2014 03:17
> To: Igor Bryskin; [email-masked]; 'Dhruv Dhody'; 'Julien Meuric'
> Cc: [email-masked]
>   Just wonder if the text in Section 6.1.2 of RFC4990 (copied below) touch
upon
> the very same problem and provide some guidance?
> 
been
from
when
inbound,
produce
for.
definition.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 17 Jun 2014 12:11:17 +0000

Hi Xian,

Here is my problem. What if I want my path to go through NE X  and exit it via interface Y but do not care on which interface the path enters the NE X?
What I was saying is that just like we have the LOOSE flag, we could've had "OUT" flag, which would solve all kinds of ambiguities.

Igor 

-----Original Message-----
From: Zhangxian (Xian) [mailto:[email-masked]] 
Sent: Monday, June 16, 2014 10:17 PM
To: Igor Bryskin; [email-masked]; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Hi, Igor, 

Regards,
Xian

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: 2014年6月16日 20:23
To: [email-masked]; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Hello,

Regards,
Igor

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, June 16, 2014 7:33 AM
To: 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 18 Jun 2014 10:13:31 +0100

Hi Igor,

Why don't you put the address of NE X in the ERO? You wouldn't even need to say
loose (unless it was genuinely a loose hop).

Now, maybe you are concerned that, having decided which i/f you want to exit by,
there is a risk that you would reach NE X by that interface. Well, that is ever
so slightly possible, but:

- It seems incredibly unlikely that the out interface you are so determined to
use could accidentally become the in interface. If that happened then you would
already have reached the downstream node that you wanted to reach. Uck. Sounds
like a bit of bad path computation!

- You could use path exclusions to make sure that doesn't happen.

BTW...
Is it time to move this discussion to CCAMP where signaling people can discuss
what you are suggesting?

Adrian

> Sent: 17 June 2014 13:11
> To: Zhangxian (Xian); [email-masked]; 'Dhruv Dhody'; 'Julien Meuric'
> Cc: [email-masked]
> Here is my problem. What if I want my path to go through NE X  and exit it via
> interface Y but do not care on which interface the path enters the NE X?
> What I was saying is that just like we have the LOOSE flag, we could've had
"OUT"
> flag, which would solve all kinds of ambiguities.
> 
> Igor
> 
upon
been
from
when
inbound,
produce
for.
definition.

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Wed, 18 Jun 2014 10:40:47 +0000

Hi, Igor, 
 
   I understand your question. What I am trying to say is RFC4990 does not allow the use you want (i.e., indicating a outgoing interface with L flag set to 1 since you said " The lack of said flag has been especially a problem when combined with the LOOSE flag." ). But, defining a "OUT" flag (plus using it when L flag is not set) should work fine. 

   Perhaps as Adrian suggested (in a different thread answering your following email), we could move to CCAMP to continue the discussion since it is a RSVP-TE issue?

Regards,
Xian

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: 2014年6月17日 20:11
To: Zhangxian (Xian); [email-masked]; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Hi Xian,

Igor 

-----Original Message-----
From: Zhangxian (Xian) [mailto:[email-masked]] 
Sent: Monday, June 16, 2014 10:17 PM
To: Igor Bryskin; [email-masked]; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Hi, Igor, 

Regards,
Xian

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: 2014年6月16日 20:23
To: [email-masked]; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Hello,

Regards,
Igor

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, June 16, 2014 7:33 AM
To: 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Adrian

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 18 Jun 2014 11:50:08 +0000

Adrian,
Please see in-line.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, June 18, 2014 5:14 AM
To: Igor Bryskin; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Hi Igor,

IB>> I am talking about the "loose" scenario. Yes, it is possible to insert address of NE X as loose hop, but this would at least unnecessarily increase the length of the ERO ( loose node ERSO + strict IN interface ERSO vs. loose OUT interface ERSO). More importantly, sometimes I really need to specify OUT interface in the ERO. Consider, for example, the situation where OUT interface Y can provide the optical signal regeneration I need. The way I constrain the path computation to use the needed re-generation is by specifying OUT interface Y ERSO followed by the label ERSO that encodes the necessary regenerator. I cannot do this by using the peer IN part of the link because the regenerator belongs to the interface Y.

Now, maybe you are concerned that, having decided which i/f you want to exit by,
there is a risk that you would reach NE X by that interface. 

IB>> No, this is not my concern.

Well, that is ever

BTW...

IB>> Well, IMO this is really a path computation problem, more specifically, path computation constraint problem, unless you believe that paths in the WDM layer could be computed in a distributed way, which I don't.

Cheers,
Igor

Adrian

"OUT"
upon
been
from
when
inbound,
produce
for.
definition.

---

From: Eric Gray <[email-masked]>
Date: Wed, 18 Jun 2014 13:46:04 +0000

Igor,

	I very much dislike the idea of a path ingress, or a point along the path,
making a decision as to what egress interface I will use at any later point in the
path (path egress, domain egress or elsewhere), based on an awareness that 
the decision point supposedly has about the capabilities of a downstream node.

	Wouldn't it be better to include the desired capabilities in signaling, and
let the downstream node(s) make this decision for themselves?  That way, it is
only necessary for a potential decision point in the network to know that some
subsequent (downstream) node has this capability without needing to know 
which interface(s) (or even necessarily which node) this capability is supported
via.

	This seems a generally desirable behavior associated with information
hiding.  What is different in this case?

--
Eric

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, June 18, 2014 7:50 AM
To: [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Adrian,
Please see in-line.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, June 18, 2014 5:14 AM
To: Igor Bryskin; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Hi Igor,

Why don't you put the address of NE X in the ERO? You wouldn't even need to say loose (unless it was genuinely a loose hop).

Now, maybe you are concerned that, having decided which i/f you want to exit by, there is a risk that you would reach NE X by that interface. 

Well, that is ever

- It seems incredibly unlikely that the out interface you are so determined to use could accidentally become the in interface. If that happened then you would already have reached the downstream node that you wanted to reach. Uck. Sounds like a bit of bad path computation!

BTW...
Is it time to move this discussion to CCAMP where signaling people can discuss what you are suggesting?

Cheers,
Igor

Adrian

> Here is my problem. What if I want my path to go through NE X  and 
> exit it via interface Y but do not care on which interface the path enters the NE X?
"OUT"
upon
been
> missing IMO is a flag in a numbered/unnumbered link ERSO indicating 
> whether the indicated side of the link is outbound or inbound wrt the 
> path direction
from
when
> combined with the LOOSE flag. Consider, for example, the situation 
> when a 1.1.24.1/loose is found in the ERO. If 1.1.24.1 interface is 
> meant to be
inbound,
produce
> interpretations. The introduction of said flag would resolve the 
> ambiguity and provide the flexibility (e.g. Druv is talking about) for the ERO encoding.
> 
> Regards,
> Igor
> 
> 
for.
> 
> A nasty question lurking in the background is whether a PCC needs to 
> indicate which construction of ERO is prefers. Consider if the 
> interface was CLI not
definition.
> However, given that most of the ERO is not for local consumption and 
> does not need to be examined by the PCC, this question may be of debatable value.
> 
> Adrian
> 
> > > http://tools.ietf.org/html/draft-farrel-ccamp-ero-survey-00 and 
> > > dive into the associated thread back in 2006.
> > >
> > > Julien
> > >
> > >

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 18 Jun 2014 14:16:02 +0000

Hi Eric,
Sorry to say this, but in the context of WDM layer I cannot disagree with you more.
It is my conviction that WDM layer path (considering all the WDM related constraints, such as optical impairments) the entire LSP path in all its details must be computed in one place (ingress NE or PCE) and no flexibility must be left for decisions on transit nodes.

Regards,
Igor

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Wednesday, June 18, 2014 9:46 AM
To: Igor Bryskin; [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Igor,

	I very much dislike the idea of a path ingress, or a point along the path, making a decision as to what egress interface I will use at any later point in the path (path egress, domain egress or elsewhere), based on an awareness that the decision point supposedly has about the capabilities of a downstream node.

	Wouldn't it be better to include the desired capabilities in signaling, and let the downstream node(s) make this decision for themselves?  That way, it is only necessary for a potential decision point in the network to know that some subsequent (downstream) node has this capability without needing to know which interface(s) (or even necessarily which node) this capability is supported via.

	This seems a generally desirable behavior associated with information hiding.  What is different in this case?

--
Eric

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, June 18, 2014 7:50 AM
To: [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Adrian,
Please see in-line.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, June 18, 2014 5:14 AM
To: Igor Bryskin; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Hi Igor,

Well, that is ever

BTW...

Cheers,
Igor

Adrian

"OUT"
upon
been
from
when
inbound,
produce
for.
definition.

---

From: Eric Gray <[email-masked]>
Date: Wed, 18 Jun 2014 21:07:37 +0000

Igor,

	Reasonable people can always disagree.  :-)

	It may very well be the case that the scenario you're describing lacks the
element of flexibility required for local decisions to be useful.

	I can see computation by a PCE as being much more scalable than requiring
each potential ingress to know about the capabilities of each potential egress, but - 
in this case - isn't it possible to either push the entire path (for at least a specific domain)
from the PCE to the ingress, or use delegation (either approach effectively relieves the 
ingress from having to "know" anything about the egress)?

	Or is this what you are trying to get at?  If so, and there is really no advantage
to local decision-making, what would be the point of using a "loose" ERO?

--
Eric

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: Wednesday, June 18, 2014 10:16 AM
To: Eric Gray; [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO
Importance: High

Hi Eric,

Regards,
Igor

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Wednesday, June 18, 2014 9:46 AM
To: Igor Bryskin; [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Igor,

--
Eric

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, June 18, 2014 7:50 AM
To: [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Adrian,
Please see in-line.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, June 18, 2014 5:14 AM
To: Igor Bryskin; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Hi Igor,

Well, that is ever

BTW...

Cheers,
Igor

Adrian

"OUT"
upon
been
from
when
inbound,
produce
for.
definition.

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 19 Jun 2014 14:54:24 +0000

Eric,
Note that this discussion is not about LOOSE flag or where the path computation takes place. It is about which interfaces wrt source->destination path direction are allowed to be put into ERO:
a) only node IDs and inbound interface IDs (as the mentioned RFC recommends);
b) only node IDs and outbound interface IDs (as some implementations I am aware of do);
c) both inbound and outbound interface IDs;
d) anything - an arbitrary set of either node, inbound or/and outbound interface IDs.

Note also, that we are talking not only about RSVP EROs, but also about PCEP EROs, for example, an ERO that allows for a PCC to express the "inclusion" constraint - an ordered list of nodes, interfaces, labels, etc. that must appear in the resulting path in the specified order, with the path computation "filling the gaps" in front of specified loose elements.

My suggestion is d). This would provide a lot of flexibility and can be easily disambiguated by introducing an additional ERSO flag - "OUT", which should be set for numbered or unnumbered ERSOs associated with outbound interface IDs.

Having said that, please, see my answers in-line.

Cheers,
Igor

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Wednesday, June 18, 2014 5:08 PM
To: Igor Bryskin; [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Igor,

	Reasonable people can always disagree.  :-)
IB>> Agree, it's been always a pleasure disagreeing with you :-)

	It may very well be the case that the scenario you're describing lacks the element of flexibility required for local decisions to be useful.

	I can see computation by a PCE as being much more scalable than requiring each potential ingress to know about the capabilities of each potential egress, but - in this case - isn't it possible to either push the entire path (for at least a specific domain) from the PCE to the ingress, or use delegation (either approach effectively relieves the ingress from having to "know" anything about the egress)?
IB>> My point is that whether path computation is performed on an ingress NE or a PCE, it should be completed in its entirety in one place (i.e. logically centralized), and produce no loose elements in the resulting paths. Note that I am talking only about WDM layer, in all other layers it is perfectly OK to compute a service path in a distributed way via signaling EROs with loose elements.

	Or is this what you are trying to get at?  If so, and there is really no advantage to local decision-making, what would be the point of using a "loose" ERO?
IB>> See above

--
Eric

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Wednesday, June 18, 2014 10:16 AM
To: Eric Gray; [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO
Importance: High

Hi Eric,

Regards,
Igor

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Wednesday, June 18, 2014 9:46 AM
To: Igor Bryskin; [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Igor,

--
Eric

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, June 18, 2014 7:50 AM
To: [email-masked]; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: Re: [Pce] PCEP ERO

Adrian,
Please see in-line.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, June 18, 2014 5:14 AM
To: Igor Bryskin; 'Zhangxian (Xian)'; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email-masked]
Subject: RE: [Pce] PCEP ERO

Hi Igor,

Well, that is ever

BTW...

Cheers,
Igor

Adrian

"OUT"
upon
been
from
when
inbound,
produce
for.
definition.