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 protected]] On Behalf Of Igor Bryskin
Sent: 2014年6月16日 20:23
To: [email protected]; 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email protected]
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:[email protected]] On Behalf Of Adrian Farrel
Sent: Monday, June 16, 2014 7:33 AM
To: 'Dhruv Dhody'; 'Julien Meuric'
Cc: [email protected]
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:[email protected]] On Behalf Of Dhruv Dhody
> Sent: 16 June 2014 10:27
> To: Julien Meuric
> Cc: [email protected]
> 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
> <[email protected]>
> 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: +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 protected]
> >> *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
> >>
> >>
> >>
> >> _______________________________________________
> >> Pce mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/pce
> >>
> >
> > _______________________________________________
> > Pce mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/pce
>
> _______________________________________________
> Pce mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
