Hi Shradha,
please see inline:
On 14/10/17 19:13 , Shraddha Hegde wrote:
Peter,
Pls see inline..
-----Original Message-----
From: Peter Psenak [mailto:[email protected]]
Sent: Friday, October 13, 2017 8:03 PM
To: Shraddha Hegde <[email protected]>; [email protected];
[email protected]; [email protected]
Subject: Re: [Isis-wg] WG Adoption poll for
draft-hegde-isis-advertising-te-protocols
Hi Shraddha,
please see inline:
On 13/10/17 15:49 , Shraddha Hegde wrote:
Stephane,
In certain cases MPLS forwarding may not be supported on some legacy linecards.
The problem you are describing is not SR specific, it would apply to LDP as
well. So the indication should not be about SR, but about MPLS forwarding
support on interface.
With MPLS being deployed for more then 20 years, I wonder why there was no need
to solve this issue earlier and why we need to address it now with SR.
Since these links should be used for IP forwarding IGPs will advertise these
links.
It is better to have explicit indication of this rather than use absence of
adjacency-sid on the link.
With the new SR flag, while the SPF and the SR-Path does not change,
there is an indication To the controller and head-end nodes that the links
cannot do SR-MPLS forwarding.
The controller or head-end implementations may have mechanisms to
prevent pulling Traffic on SR paths. When Head-end node detects a
prefix-sid path going through such incapable links It may skip
installing SR paths for such prefix-SID and implementations may decide
to use other mechanisms (such as RSVP or IP) at the head-end which would
prevent Traffic loss.
This is also a useful tool during transition to SR when certain links
should avoid carrying SR traffic due to operational reasons.
> there are standardized mechanisms like affinities that can be used to
address above mentioned operational issue.
These mechanisms are specific to SR-TE when the paths are built based on
constraints.
Link color based solution cannot be used when the SR traffic is flowing over
SPF paths using Node-SIDs.
as we discussed this privately before (and agreed I believe), if we need
to address this case, it will be about MPLS enablement not about SR. Do
you agree?
I'm willing to accept the need to advertise the MPLS enablement on the
link, if people believe the use case is valid. I have some doubts there
though, due to the long history of this problem.
thanks,
Peter
thanks,
Peter
Rgds
Shraddha
-----Original Message-----
From: [email protected]
[mailto:[email protected]]
Sent: Thursday, October 12, 2017 4:03 PM
To: [email protected];
[email protected]
Subject: RE: [Isis-wg] WG Adoption poll for
draft-hegde-isis-advertising-te-protocols
Hi Authors,
One question, why do you think it is really needed to introduce the SR flag ?
Couldn't it be deduced from the presence of an Adj-SID and the SR router cap ?
The SR flag unset while the router supports SR looks strange to me. Why do you want to
prevent "SR forwarding" on a link if the node supports SR ?
" With this information, a centralized
application can decide to use a different path for that traffic by
using a different label stack."
In such a case, the usage of a Node-SID may be complex, as the Node-SID may
cross a link with the SR flag unset. This will force the controller to use
Adj-SIDs only.
If the controller uses only Adj-SIDs, then an implementation can allow the user
to prevent the advertisement of Adj-SIDs on a particular link.
Could you clarify the use case here ?
Thanks,
-----Original Message-----
From: Isis-wg [mailto:[email protected]] On Behalf Of Christian
Hopps
Sent: Saturday, October 07, 2017 04:43
To: [email protected]
Cc: [email protected]; [email protected];
[email protected]
Subject: [Isis-wg] WG Adoption poll for
draft-hegde-isis-advertising-te-protocols
Hi Folks,
The authors have requested the IS-IS WG adopt
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dprotocols_&d=DwIFAg&
c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdV
KcmMXJ31bpbBaNqzCNrng&m=C2KWg-TNJXOgV_qiX8ZDhjjJW6rn3GhpPaBzHTDjqZ0&s=
lHsxN1TAflKdy5QZ1sKRfmprtswYQGOljhQpvPNoJkE&e=
as a working group document. Please indicate your support or no-support for
taking on this work.
Authors: Please indicate your knowledge of any IPR related to this work to the
list as well.
Thanks,
Chris & Hannes.
______________________________________________________________________
___________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration, Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed, used
or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Isis-wg mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
man_listinfo_isis-2Dwg&d=DwICAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDT
XcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=HA7t5B3gAhN2q_
Lj_Ykis3SRVwgLO3HnsBNztTBm604&s=SWKyb05_7fQL4r4j4a4WcU78M4nYaaLz16pBKh
wzBGo&e=
.
.
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
