Re: [Pce] PCEP ERO

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

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

> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: 16 June 2014 13:23
> To: [e-mail]; 'Dhruv Dhody'; 'Julien Meuric'
> Cc: [e-mail]
> 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
> 
> 
> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Monday, June 16, 2014 7:33 AM
> To: 'Dhruv Dhody'; 'Julien Meuric'
> Cc: [e-mail]
> Subject: Re: [Pce] PCEP ERO
> 
> 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:[e-mail]] On Behalf Of Dhruv Dhody
> > Sent: 16 June 2014 10:27
> > To: Julien Meuric
> > Cc: [e-mail]
> > Subject: Re: [Pce] PCEP ERO
> >
> > 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
> > <[e-mail]>
> > 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
> > >
> > >
> > > Jun. 16, 2014 - Dhruv Dhody:
> > >>
> > >> 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: [phone]
> > >>
> > >> 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:* [e-mail]
> > >> *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: [phone]
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Pce mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/pce
> > >>
> > >
> > > _______________________________________________
> > > Pce mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/pce
> >
> > _______________________________________________
> > Pce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pce
> 
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce