Hi Shraddha
I think this would be very helpful.
pk
On Sun, Nov 18, 2018 at 8:39 PM Shraddha Hegde <[email protected]
<mailto:[email protected]>> wrote:
Hi all,____
__ __
I am preparing the shepherd write-up and noticed that the topic in
below e-mail thread is an____
Open item. My personal opinion is to add a new section to this draft
to address below cases____
> more than one node advertising the same IPv4/6 PREFIX and both
have the same prefix-SID value with "N" flag____
> where an anycast prefix is advertised with a prefix-SID sub-TLV by
some (but not all) of the nodes that advertise that prefix.____
__ __
This draft is addressing incoming label collision and resulting
behavior and also describes other aspects like different SIDs for
same prefix so it seems reasonable to add above two cases to this
draft.____
WG members, if you have an opinion, pls respond on the list.____
__ __
Rgds____
Shraddha____
*From:*Alexander Vainshtein <[email protected]
<mailto:[email protected]>>
*Sent:* Sunday, November 4, 2018 9:37 PM
*To:* Ahmed Bashandy <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>; '[email protected]
<mailto:[email protected]>' <[email protected] <mailto:[email protected]>>;
'[email protected] <mailto:[email protected]>'
<[email protected] <mailto:[email protected]>>; Jonathan
Hardwick ([email protected]
<mailto:[email protected]>)
<[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>;
Shraddha Hegde <[email protected] <mailto:[email protected]>>
*Subject:* RE: RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13____
__ __
Ahmed,____
Apologies for a delayed response.____
I fully agree that advertising the same prefix SID as the Node SID
by two different nodes in the SR domain is “a clear violation of the
SR architecture RFC (8402)”.____
But I do not think that the SR-MPLS draft can silently ignore this
violation just because it “is not an incoming label collision”. ____
The same applies to the controversy in advertising at the same
prefix as Anycast by some nodes but not as Anycast (or even as a
Node SID) by some other nodes. ____
Your reference to these being just control plane issues and
therefore not related to SR-MPLS is not valid - because the drafts
dealing with the SR control plane to which you refer in this draft
are strictly MPLS-oriented: they define how to advertise */SID
labels/* or */indices/* that are translated into */SID labels/*, and
neither of these mechanisms is relevant fore SRV6 IMHO. (I do not
have to remind you that a draft that defines SRV6 extensions for
ISIS
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbashandy-2Disis-2Dsrv6-2Dextensions_-3Finclude-5Ftext-3D1&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=ko-3eF8yySF1exH64SoeyEP0ett4gjsHmmOCvj9zCvQ&s=_AZSiqmTUTMKFS9DAqboueo_GnvvAcFxARWF820HnTA&e=>exists,
and deals with other issues).____
My 2c,____
Sasha____
__ __
Office: +972-39266302____
Cell: +972-549266302____
Email: [email protected]
<mailto:[email protected]>____
__ __
*From:*Ahmed Bashandy [mailto:[email protected]]
*Sent:* Sunday, October 28, 2018 1:01 AM
*To:* Shraddha Hegde <[email protected]
<mailto:[email protected]>>; Alexander Vainshtein
<[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>; '[email protected]
<mailto:[email protected]>' <[email protected] <mailto:[email protected]>>;
'[email protected] <mailto:[email protected]>'
<[email protected] <mailto:[email protected]>>; Jonathan
Hardwick ([email protected]
<mailto:[email protected]>)
<[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
*Subject:* Re: RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13____
__ __
Thanks for the comments____
While it is a clear violation of the SR architecture RFC (8402),
more than one node advertising the same IPv4/6 PREFIX and both have
the same prefix-SID value with "N" flag is not an incoming label
collision because the label is associated with the same FEC, which
is the prefix. ____
Hence handling such violation is not an SR-MPLS problem because
there is no incoming label collision and hence it it is outside the
scope of this draft____
__ __
The second issue is which SID to choose for an SR-policy (be it a
policy for TE, ti-lfa, uloop avoidance, security,..., etc). That is
strictly a control layer functionality and is not specific to
SR-MPLS. Hence it is outside the scope of this draft____
__ __
The third issue is the case where an anycast prefix is advertised
with a prefix-SID sub-TLV by some (but not all) of the nodes that
advertise that prefix. Again this is not an incoming label collision
because the label is associated with a single FEC, which is the
anycast prefix.____
__ __
On 7/19/18 8:30 PM, Shraddha Hegde wrote:____
Hi Ahmed,____
____
The Node-SIDs are expected to be unique to a node. ____
“____
An IGP Node-SID MUST NOT be associated with a prefix that is
owned by____
more than one router within the same routing domain.”____
____
If two different nodes advertise same Node-SID,____
For Example Node A and B both advertise prefix 1.1.1.1
and associate a SID 1000 with N bit set.____
There is an anomaly here and IMO, this draft should address how
to handle this anomaly and whether TI-LFA and other____
Applications can use this SID as a Node-SID.____
Another slight variation of this case is a scenario where A and
B both advertise a prefix 1.1.1.1 and A assigns a Node-Sid____
Of 1000 and B does not assign any SID.____
____
Rgds____
Shraddha____
____
*From:*Alexander Vainshtein <[email protected]>
<mailto:[email protected]>
*Sent:* Thursday, July 19, 2018 10:05 PM
*To:* Ahmed Bashandy <[email protected]>
<mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>; '[email protected]
<mailto:[email protected]>' <[email protected]> <mailto:[email protected]>;
'[email protected] <mailto:[email protected]>'
<[email protected]> <mailto:[email protected]>; Jonathan
Hardwick ([email protected]
<mailto:[email protected]>)
<[email protected]>
<mailto:[email protected]>; Shraddha Hegde
<[email protected]> <mailto:[email protected]>;
[email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
*Subject:* RE: RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13____
____
Ahmed hi!____
Lots of thanks for your response.____
Of course Node SIDs are not different from any other Prefix SIDs
when it comes to the MPLS forwarding plane.____
But, IMHO, strictly speaking, this is correct for any other SID
as well. ____
You seem to ignore the difference between SR-MPLS and SRv6 with
regard to the life span of prefix SIDs in general and Node SIDs
in particular. From my POV this difference should be discussed
in the draft. ____
So it seems that we can only “agree to disagree” on the need to
say something specific about Node SIDs in the draft, and let the
WG to decide what to do about it. ____
Regards,____
Sasha____
____
Office: +972-39266302____
Cell: +972-549266302____
Email: [email protected]
<mailto:[email protected]>____
____
*From:*Ahmed Bashandy [mailto:[email protected]]
*Sent:* Thursday, July 19, 2018 7:13 PM
*To:* Alexander Vainshtein <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>; '[email protected]
<mailto:[email protected]>' <[email protected] <mailto:[email protected]>>;
'[email protected] <mailto:[email protected]>'
<[email protected] <mailto:[email protected]>>; Jonathan
Hardwick ([email protected]
<mailto:[email protected]>)
<[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
*Subject:* Re: RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13____
____
Thanks for the reply____
See inline____
Ahmed____
____
On 7/12/18 12:22 AM, Alexander Vainshtein wrote:____
Ahmed and all,____
I would like to expand on my comments (and your responses)
about the role of Node SIDs in SR-MPLS.____
I would like to bring your attention two points:____
__1.__Node SIDs (and, in general, Prefix SIDs) in MPLS-SR
are different from the same in SRv6 because they require
explicit configuration action by the operator of SR domain.
I.e., it is not enough for a node to own some /32 or /128
prefix that is advertised by IGP. The operator must
explicitly configure the node to use such a prefix as Node
SID and to assign to it a specific index that is unique in
the SR domain. From my POV, this difference alone would
qualify Node SIDs as a topic to be discussed in the MPLS-SR
Architecture
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls-2D14&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=q6djpRXlamUzKZlGIuXTtBcsnwevHwddqvStZrSFMnE&e=>draft.____
#Ahmed: I disagree with your POV. From the forwarding plane
perspective it does not make any difference whether a the label
at the top of an MPLS packet (representing the prefix-SID)
identifies a node or not. So from the SR-mpls forwarding point
of view there is no difference between a prefix-SID and a
node-SID. If there is any place in the SR-mpls draft where there
is a need to handle a node-SID different from a prefix SID, it
would be great to point it out
____
__2.__In addition, quite a few constructs associated
with SR-MPLS implicitly assume that each node in the
SR-MPLS domain is assigned with at least one Node SID.
One example can be found in the TI-LFA
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>
draft. This draft says in Section 4.2:____
____
4.2
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04-23section-2D4.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=sAi3KCWUwGS3D93t8ic64W_46xm9y8Oacs7ozcAweS8&e=>..
The repair node is a PQ node____
____
____
When the repair node is in P(S,X), the repair list is
made of a____
single node segment to the repair node.____
In the scope of this section, the repair node is not
adjacent to the PLR, and therefore, to the best of my
understanding, “a single node segment to the repair node”
can be only the Node SID of the repair node. Since repair
nodes are computed dynamically, this entire scheme depends
on all nodes in the MPLS=SR domain having at least one Node
SID each____
#Ahmed: The choice of the SID to identify an intermediate or
exit node(s) in an SR-policy is a control plane behavior,
irrespective of reason such policy is created (be it ti-lfa
explicit path, uloop avoidance explicit path, or some SR-TE
explicit path). SR-Policy as well as Ti-LFA and uloop avoidance
are handled in separate drafts. So just like the response to
your previous comment, from forwarding plane perspective it does
not make any difference whether the label at the top of an MPLS
packet identifies a single or multiple nodes.
____
.____
____
Hopefully these notes clarify my position on the subject.____
____
Regards,____
Sasha____
____
Office: +972-39266302____
Cell: +972-549266302____
Email: [email protected]
<mailto:[email protected]>____
____
*From:*Alexander Vainshtein
*Sent:* Wednesday, July 11, 2018 12:02 PM
*To:* Ahmed Bashandy <[email protected]>
<mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>;
'[email protected] <mailto:[email protected]>' <[email protected]>
<mailto:[email protected]>; '[email protected]
<mailto:[email protected]>' <[email protected]>
<mailto:[email protected]>; Jonathan Hardwick
([email protected]
<mailto:[email protected]>)
<[email protected]>
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
*Subject:* RE: RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13____
____
Ahmed, and all,____
Lots of thanks for a detailed response to my comments. ____
Please see */inline below/*my position on each of them.____
____
Regards,____
Sasha____
____
Office: +972-39266302____
Cell: +972-549266302____
Email: [email protected]
<mailto:[email protected]>____
____
*From:*Ahmed Bashandy [mailto:[email protected]]
*Sent:* Wednesday, July 11, 2018 4:42 AM
*To:* Alexander Vainshtein <[email protected]
<mailto:[email protected]>>;
[email protected] <mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>;
'[email protected] <mailto:[email protected]>' <[email protected]
<mailto:[email protected]>>; '[email protected]
<mailto:[email protected]>' <[email protected]
<mailto:[email protected]>>; Jonathan Hardwick
([email protected]
<mailto:[email protected]>)
<[email protected]
<mailto:[email protected]>>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*Subject:* Re: RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13____
____
Thanks for thorough (and VERY clear) the review____
See inline #Ahmed____
____
Ahmed____
____
____
On 6/15/18 11:08 PM, Alexander Vainshtein wrote:____
Re-sending to correct SPRING WG list.____
Sincere apologies for the delay caused by a typo.____
Thumb typed by Sasha Vainshtein____
____
------------------------------------------------------------------------
*From:* Alexander Vainshtein
*Sent:* Sunday, June 10, 2018 10:43:52 AM
*To:* [email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
'[email protected] <mailto:[email protected]>';
'[email protected] <mailto:[email protected]>';
Jonathan Hardwick ([email protected]
<mailto:[email protected]>);
[email protected] <mailto:[email protected]>
*Subject:* RE: RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13____
____
Explicitly adding Shraddha who is the shepherd of this
draft. ____
____
Regards,____
Sasha____
____
Office: +972-39266302____
Cell: +972-549266302____
Email: [email protected]
<mailto:[email protected]>____
____
*From:* Alexander Vainshtein
*Sent:* Friday, June 8, 2018 5:43 PM
*To:* '[email protected]
<mailto:[email protected]>'
<[email protected]>
<mailto:[email protected]>;
'[email protected]
<mailto:[email protected]>'
<[email protected]>
<mailto:[email protected]>
*Cc:* '[email protected] <mailto:[email protected]>'
<[email protected]> <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
'[email protected] <mailto:[email protected]>'
<[email protected]> <mailto:[email protected]>
*Subject:* RtgDir Early review:
draft-ietf-spring-segment-routing-mpls-13____
____
____
Hello,____
I have been selected to do a routing directorate “early”
review of this draft:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=Cxbaaf9U0kj6_meVSobSkRLQW1SwI8MJvgHpuYp0QOM&e=>____
____
The routing directorate will, on request from the
working group chair, perform an “early” review of a
draft before it is submitted for publication to the
IESG. The early review can be performed at any time
during the draft’s lifetime as a working group document.
The purpose of the early review depends on the stage
that the document has reached. As this document is
currently in the WG Last call, my focus for the review
was to determine whether the document is ready to be
published. Please consider my comments along with the
other working group last call comments.____
____
For more information about the Routing Directorate,
please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=6pnI7l82ewwzoxgOXqTKrbKuQidt6-KBsZdsXFnoQCg&e=>____
____
*Document*: draft-ietf-spring-segment-routing-mpls-13____
*Reviewer*: Alexander (“Sasha”) Vainshtein
([email protected]
<mailto:[email protected]>)____
*Review Date*: 08-Jun-18____
*Intended Status*: Proposed Standard.____
____
*Summary*:____
____
I have some minor concerns about this document that I
think should be resolved before it is submitted to the
IESG.____
____
*Comments*:____
____
I consider this draft as an important companion
document to the Segment Routing Architecture
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2D15&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=iJShh7e7yyVkt44v1O5pyCOMfHCpAvfBNGgFr5lk130&e=>draft
that, ideally, should augment definitions of the Segment
Routing (SR) notions and constructs given there with
details specific for the SR instantiation that uses the
MPLS data plane (SR-MPLS). Many issues raised in my
review reflect either gaps that should be, but have not
been, closed, or inconsistencies between the two drafts.
____
____
____
Since RFC 8287
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8287&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=y7jp3UYNTtcmm9HOulzqPTrMURTrsMiO26rWlNZN5Ws&e=>is
already published as a Standards Track RFC, I expect
such augmentation to be backward compatible with this
document (or to provide clear indications of required
updates to this document). And I include the MPLS WG
into distribution list. ____
____
This draft was not easy reading for me. In particular,
the style of Section 2.5 that discusses at length and in
some detail multiple “corner cases” resulting,
presumably, from misconfiguration, before it explains
the basic (and relatively simple) “normal” behavior,
looks problematic to me.____
____
The WG Last Call has been extended by one week.
Nevertheless, I am sending out my comments ____
____
*Major Issues*: None found____
#Ahmed: thanks a lot____
____
*Minor Issues*: Quite a few but, hopefully, easy to
resolve.____
____
1.*Encapsulation of SR-MPLS packets*: ____
a.RFC 3032 (referenced by the draft) and RFC 5332 (*/not
mentioned in the draft/*) depend two encapsulations of
labeled packets - one for Downstream-allocated labels
and another for Upstream-allocated ones.____
#Ahmed: RFC5332 is for multicast. As mentioned in Section 6
of draft-ietf-spring-segment-routing-15, multicast is
outside the scope of SR. Hence the RFC was not referred to
in the SR-MPLS draft____
*/[[Sasha]] I would be satisfied with this response, would
it not be for the following text I see in Section 2.2 of
the/**//**/SR Policy Architecture/*
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dpolicy-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=4f0H68LTvkp7N-bYTVLOhWqiEbHaCsOQR1z_Qzz3Wf4&e=>*//**/draft:/*____
A variation of SR Policy can be used for packet
replication. A____
candidate path could comprise multiple SID-Lists; one
for each____
replication path. In such a scenario, packets are
actually____
replicated through each SID List of the SR Policy to
realize a point-____
to-multipoint service delivery. ____
____
*/This looks to me as being very much multicast in SR, and,
unless you want to say that it is limited to SRv6, makes my
question relevant IMHO./*____
b.From my POV the ST-MPLS only uses Downstream-allocated
labels – but I expect the draft to state that
explicitly, one way or another. (If Upstream-allocated
labels are relevant for SR-MPLS, I would see it as a
major gap, so I hope that this is not the case).____
#Ahmed: I will add a statement in section 2.2 to mention
that it is down-stream allocated as you mentioned____
*/[[Sasha]] This is quite unambiguous and, once added, would
resolve my comment in full – the previous comment
notwithstanding. In particular, it would imply that even
labels representing BSIDs of a SR Replication policies will
be downstream-allocated. /*____
____
2.*Label spaces in SR-MPLS*:____
a.RFC 3031 (referenced by the draft) defines
per-platform and per-interface label spaces, and RFC
5331 (*/not mentioned in the draft/*) adds
context-specific label spaces and context labels. ____
b.The draft does not say which of these are or are not
relevant for SR-MPLS____
c.From my POV:____
i.Labels representing all kinds of SIDs mentioned in the
draft MUST be allocated from the per-platform label
space only ____
ii.At the same time, instantiation of Mirror Segment IDs
defined in Section 5.1 of the Segment Routing
Architecture draft using MPLS data plane clearly calls
for context labels and context-specific label spaces____
d.I expect the draft to provide a clear-cut position on
these aspects of SR-MPLS.____
#Ahmed: I will add a statement to section 2.2 to say that
the it is per-platform. Regarding the function "mirroring",
SR attaches a *function* to each SID. The "mirroring"
function is already described in Section 5.1 of
draft-ietf-spring-segment-routing and is not specific to the
MPLS forwarding plane. Hence there is no need to re-mention
it here because this document is trying to be as specific as
possible to the MPLS forwarding plane. General functions
attached to SID are described in the segment routing
architecture document or future documents. Furture documents
proposing new SR function must be as specific and clear as
possible____
*/[[Sasha]] Looks OK to me./*____
____
3.*SR-MPLS and hierarchical LSPs*:____
a.SR LSPs that include more than one segment are
hierarchical LSPs from the POV of the MPLS data plane.
Therefore some (possibly, all) of the models for
handling TTL and TC bits that have been defined in RFC
3443 (*/not mentioned in the draft/*) should apply to
SR-MPLS____
b.RFC 8287 (*/not referenced in the draft/*)
specifically discussed operation of the LSP Traceroute
function for SR LSPs in the case when Pipe/Short Pipe
model for TTL handling is used____
c.I expect the draft to provide at least some guidelines
regarding applicability of each specific model defined
in RFC 3443 (separately for TTL and TC bits) to SR-MPLS.____
#Ahmed: BY design, the instantiation of SR over the MPLS
forwarding plane (and hence this draft) does not modify the
MPLS forwarding plan behavior as it is mentioned in the
first sentence in Section 1. So the TTL behavior specified
in rfc3443 is already implied and there is no need to
re-mention it here just like all aspects of MPLS forwarding.
RFC8287 is OAM-specific. SR-OAM is handled in a separate
document so is outside the scope of this draft____
*/[[Sasha]] Unfortunately I do not think this is good
enough. Let me ask a specific question reflecting my
concerns:/*____
*/The head-end node sends SR-MPLS packets across a path
defined by an ordered set of SIDs with more than one SID in
the list. Each SID is represented by a label stack entry
(LSE) in the MPLS label stack, and the label field in each
LSE is the label that matches the corresponding SID.
However, each LSE also includes the TTL and TC fields. How
does the head-end node set these fields in each of the LSEs
following the top one? This clearly depends on the model
(Uniform vs. Pipe/Short Pipe) implemented in each node that
that performs Next operation on the packet along the path –
but the head-end node usually is not aware of that. /*____
*/RFC 8287 is relevant as an example here IMHO because it
recommends the following setting of TTL in Traceroute
packets:/*____
__-__*/Set the TTL of all the labels above one that
represents the segment you are currently tracing to
maximum/*____
__-__*/Set the TTL of the label one that represents the
segment you are currently tracing to the desired value (to
be incremented until end of segment is reached/*____
__-__*/Set the TTL of all the labels below one that
represents the segment you are currently tracing to 0./*____
*/I expect the draft to provide some recommendations for
traffic (non-OAM) packets as well./*____
____
4.*Inferring network layer protocol in SR-MPLS*:____
a.I wonder if the draft could provide any details on the
situation when a label that represents some kind of SID
is the bottom-of-stack label to be popped by the egress
LER____
#ahmed: This is part of the "Next" function. It is described
in detail in this document. ____
*/[[Sasha]] NEXT function is mentioned in several places in
the document. Can you please point to the specific text that
is relevant for my question?/*____
____
b.For the reference, RFC 3032 says that “the identity of
the network layer protocol must be inferable from the
value of the label which is popped from the bottom of
the stack, possibly along with the contents of the
network layer header itself”____
c.From my POV the following scenario indicates relevance
of this expectation for SR-MPLS:____
i.IS-IS is used for distributing both IPv4 and IPv6
reachability in a given domain____
ii.An IS-IS adjacency over some dual-stack link is
established, and a single Adj-SID for this adjacency is
advertised____
iii.The node that has assigned and advertised this
Adj-SID receives a labeled packet with the label
representing this Adj-SID being both the top and
bottom-of-stack label____
iv.The implementers must be given unambiguous
instructions for forwarding the unlabeled packet via the
dual-stack link as an Ipv4 or an IPv6 packet.____
#Ahmed: If you take a look at the SR-ISIS , SR-OSPFv2 and
SR-OSFv3 drafts, you will see all 3 protocol advertise
different adj-SIDS for IPv4 next-hop and IPv6 next-hop. For
example, ISIS uses the "F-Flag" (section 2.2.1 in
draft-ietf-isis-segment-routing-extensions-18) to specify
whether the adj-SID is for IPv4 and IPv6. Similarly, the
SR-ISIS draft attaches a prefix-SID to the prefix
advertisement and hence implies the identity of the protocol
underneath the bottom most label. For any other "function"
attached to a SID, it is part of the specification of this
function to describe what happens when the SID is
represented by a label in the MPLS forwarding plane and this
label is the bottom most label ____
*/[[Sasha]] OK, got it. This issue is resolved./*____
____
5.*Resolution**of Conflicts*: Are the____
a.Are the conflict resolution procedures listed in
section 2.5 mandatory to implement? ____
b.If they are mandatory to implement, are they also
mandatory to deploy, or can the operators simply treat
any detected conflict as requiring human intervention
and preventing normal operation of SR-MPLS?____
#Ahmed: They are recommended. I will modify the paragraph
after the first 3 bullets in Section 2.5 to say that it is
recommeded. ____
*/[[Sasha]] OK. However, it would be nice if you could refer
separately for “RECOMMENDED to implement” and “RECOMMENDED
to deploy”. The latter probably requires a configuration
knob for enabling conflict resolution rules (if they are
implemented). /*____
c.For the reference, the IETF capitalized MUST appears
just in a few places in Section 2.5, and each appearance
has very narrow context:____
i.For MCCs where the "Topology" and/or "Algorithm"
fields are not defined, the numerical value of zero MUST
be used for these two fields____
ii.If the same set of FECs are attached to the same
label "L1", then the tie-breaking rules MUST always
select the same FEC irrespective of the order in which
the FECs and the label "L1" are received. In other
words, the tie-breaking rule MUST be deterministic. ____
iii.An implementation of explicit SID assignment MUST
guarantee collision freeness on the same router____
From my POV, it is not possible to infer the answer to
my question from these statements. Some explicit
statement is required.____
#Ahmed: I agree with you POV and as mentioned in my reply to
items (a) and (b), I will modify the paragraph to say that
it is RECOMMENDED to answer you questions in items (a) and
(b)____
d.The tie-breaking rules in section 2.5.1 include some
specific values for encoding FEC types and address
families – but these values are not supposed to appear
in any IANA registries (because the draft does not
request any IANA actions). Can you please clarify what
is so special about these values? ____
#Ahmed: There is no significance to the values but there is
a significance to the order among them. I will modify the
text to clarify that____
*/[[Sasha]] OK. /*____
____
e.I also doubt that comparison of FECs that represent
IPv4 and IPv6 prefix SIDs makes much sense (for conflict
resolution or else), because, among other things, there
are valid scenarios when an IPv4 /32 prefix is embedded
in an IPv6 /128 one.____
#Ahmed: A prefix-SID is assigned to a prefix. An IPv6 prefix
that embeds an IPv4 prefix is different from the IPv4
prefix. The specifications of SR extensions to ISIS, OSPFv2,
OSPFv3, and BGP treat IPv4 and IPv6 prefixes separately,
including the IPV6 prefixes with embedded IPv4 ones. Besides
not all IPv6 prefixes embed IPv4 prefix in them. Hence the
distinction between IPv4 and IPv6 prefixes is quite clear ____
*/[[Sasha]] My concern was mainly about IPv4-mapped IPv6
addresses. Quoting from RFC 4291:/*____
*2.5.5.2*
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools..ietf.org_html_rfc4291-23section-2D2.5.5.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I14XA8I9Ruw5aBj5er_OVbvADz1sb9ZLFBGaZZlJJJ4&e=>*.
IPv4-Mapped IPv6 Address*____
____
____
A second type of IPv6 address that holds an embedded
IPv4 address is____
defined. This address type is used to represent the
addresses of____
IPv4 nodes as IPv6 addresses.____
*//*____
*/From my POV this means that a /128 prefix associated with
an IPv4-mapped IPv6 address and a /32 prefix associated with
the IPv4 address that was mapped to this IPv6 address
represent the same entity. This understanding fully matches
usage of IPv4-mapped IPv6 addresses as BGP Next Hops of
VPN-IPv6 addresses defined in RFC 4798. However, the
comparison rules you have defined will treat them as two
different prefixes. I wonder if these rules, in the case of
a conflict, could result in preferring the IPv6 prefix to an
IPv4 one and therefore loosing MPLS connectivity for the
ingress PE of a 6VPE service to its egress PE?/*____
____
f.Section 2.5.1 defines 3 types of SR-MPLS FECs, but I
am not sure all SID types defined in the Segment Routing
Architecture draft can be unambiguously mapped to one of
these types. Problematic examples include at least the
following:____
i.Parallel Adjacency SID____
ii.Mirror SID____
Explicit mapping of SID types to SR-MPLS FEC types would
be most useful IMO. If some SID types cannot be mapped
to SR-MPLS FECs, this must be explicitly stated in the
draft.____
#Ahmed:
Parallel adjacency SID are handled in the type "(next-hop,
outgoing interface)" ____
*/[[Sasha]] OK/*____
Mirror SID is a type of binding-SID as mentioned in Section
5.1 in the SR architecture draft
(draft-ietf-spring-segment-routing-15). Also as described in
Section 2.4 draft-ietf-isis-segment-routing-extensions-18
(also see the equivalent in the OSPFv2 and OSPFv3 draft), a
binding SID is identified by a prefix. Hence it is covered
by the type "(Prefix, Routing Instance, Topology,
Algorithm)"____
*/[[Sasha]] I respectfully disagree. There is definitely no
mention of Algorithm in the definition of the Mirror SID. /*____
____
6.*Node SIDs in SR-MPLS*:____
a.Node SIDs are explicitly defined and discussed in the
Segment Routing Architecture draft but are not mentioned
even once in this draft____
b.AFAIK, the common implementation practice today
includes assignment of at least one Node SID to every
node in the SR-MPLS domain____
c.Is there a requirement to assign at least one Node SID
per {routing instance, topology, algorithm} in SR-MPLS?
If not, can the authors explain expected behavior of
such a node? (See also my comment about routing
instances below).____
#Ahmed: A Node-SID is a special case of prefix-SID. So there
nothing specific about it from the MPLS forwarding plane
point of view. Similarly from a standard tracks draft point
of view, there is no requirement to assign a SID to every
prefix just like there is no requirement to bind every
prefix to an LDP label. Common and/or recommended practices
or description of deployment scenarios are more befitting to
BCP or informational drafts. This draft is a standards track
draft____
*/[[Sasha]] Well, you’ve just said that conflict resolution
rules are RECOMMENDED, and this is quite common in the
Standards Track RFCs. /*____
If a {routing instance, topology, algorithm} is not assigned
a SID, then this FEC is totally irrelavant to this draft and
hence describing how a node treats it is totally outside the
scope of this draft____
*/[[Sasha]] AFAIK, neither of the SR extension drafts for
IGPs mention routing instances that can be associated with
the prefix, so I think that your reference to it is
incorrect./*____
*/What’s more I suspect that Node SIDs represent the most
used special case of Prefix SIDs with Anycast SIDs being
quite behind. Therefore some recommendation pertaining to
the usage of Node SIDs would be very much in place IMHO. /*____
____
7.*SRGB Size in SR-MPLS*: ____
a.The draft correctly treats the situation when an index
assigned to some global SID cannot be mapped to a label
using the procedure in Section 2.4 as a conflict.____
b.At the same time the draft does not define any minimum
size of SRGB (be it defined as a single contiguous block
or as a sequence of such blocks) that MUST be
implemented by all SR-capable nodes____
c.I suspect that lack of such a definition could be
detrimental to interoperability of SR-MPLS solutions.
AFAIK, the IETF has been following, for quite some time,
a policy that some reasonable MUST-to-implement defaults
should be assigned for all configurable parameters
exactly in order to prevent this.____
#Ahmed: This document specifies how the SRGB is used and the
behavior of routers when a prefix-SID index maps to a label
inside and/or outside the SRGB. The actual size of the SRGB
is a task in partitioning the label space, which is very
specific to a particular deployment scenario. So IMO it is
outside the scope of a standards track document. Now that
SR-MPLS is deployed in many places, I expect the community
to gain sufficient experience to recommend (or not
recommend) a particular minimum/maximum size for the SRGB is
some future informational or BCP draft/RFC____
*/[[Sasha]] My reading of your response is that minimum size
of SRGB is an issue for future study. Can you please just
add this to the draft?/*____
____
8.*Algorithms and Prefix SIDs*:____
a.The draft mentions Algorithms (as part of SR-MPLS
Prefix FEC) in, but it does not explicitly link them
with the Prefix-SID algorithms defined in section 3.1.1
of the Segment Routing Architecture draft____
#Ahmed: I will just add the reference
[I-D.ietf-spring-segment-routing] right beside the first
time "Algorithm" is mentioned____
*/[[Sasha]] OK/*____
____
b.From my POV, the draft should explicitly state that
the default Prefix-SID algorithm MUST be implemented in
all SR-MPLS-compliant routers.____
#Ahmed: The specification of what path calculation method
should or must be supported is a routing protocol property
not a forwarding plane property. In fact, the choice of a
path calculation method or algorithm is completely
orthogonal to the routed protocol. Hence mandating the
support of a particular routing algorithm is beyond the
scope of this document.____
*/[[Sasha]] OK/*____
____
c.The Segment Routing Architecture draft states (in
section 3.1.3) that “Support of multiple algorithms
applies to SRv6”. But neither draft states whether
multiple algorithms apply to SR-MPLS. Can you please
clarify this point?____
#Ahmed: The last paragraph of Section 3.1.2 titled SR-MPLS
in draft-ietf-spring-segment-routing-15 discusses the
support of multiple algorithms. So it is implied that the
concept of algorithm applies to SR-MPLS. Hence there is no
need to re-mention it here____
*/[[Sasha]] The paragraph to which you refer only says that
if a packet with the active Prefix-SID that is associated
with a specific algorithm is received by a node that does
not support this algorithm, this packet will be discarded.
If this is the only type of support for multiple algorithms
SR provides, it is not very useful IMHO/**/. /*____
____
9.*Routing instances and the context for Prefix-SIDs*:____
a.The Segment Routing Architecture draft states in
Section 3.1 that the “context for an IGP-Prefix segment
includes the prefix, topology, and algorithm”____
b.This draft seems to define (in section 2.5) the
context for the Prefix SID as “Prefix, Routing Instance,
Topology, Algorithm” where ”a routing instance is
identified by a single incoming label downloader to FIB”
(but the notion of the label downloader to FIB is not
defined).____
c.These two definitions look different to me. ____
d.At the very least I would expect alignment between the
definitions of context for the Prefix-SID between the
two drafts. Preferably, the definition given in the
Segment Routing Architecture draft should be used in
both drafts.____
#Ahmed: The context of the section 2.5 is limited to the
resolution of local label collision. The use of "routing
instance" in section 2.5 is just there for tie-breaking if
there is local label collision.____
*/[[Sasha]] I have already mentioned that “routing
instances” are not defined in any the drafts dealing with SR
Extensions for IGPs. So I do not understand how the conflict
resolution procedure is supposed to use this. And in any
case the difference between two definitions of the context
of Prefix-SID requires some explanation./*____
____
10.*Example of PUSH operation in Section 2.10.1*:____
a.The first para of this section begins with the
sentence “Suppose an MCC on a router "R0" determines
that PUSH or CONTINUE operation is to be applied to an
incoming packet whose active SID is the global SID
"Si"”. In the context of SR-MPLS this means (to me) that
the incoming packet is a labeled packet and its top
label matches the global SID “Si”. ____
b.However, the example for PUSH operation in the next
para of this section is the case of an (unlabeled) IP
packet with the destination address covered by the IP
prefix for which “Si” has been assigned. ____
c.From my POV:____
i.Mapping unlabeled packets to SIDs is indeed out of
scope of the draft. Therefore an example of a PUSH
operation that is applied to a labeled packet (with the
active SID inferred from the top label in the stack) is
preferable.____
ii.Valid examples of PUSH operation applied to a
labeled incoming packet can be found in Sections 4.2 or
4.3 of the TI-LFA
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>draft____
____
#Ahmed: I do not understand your concern here:)____
*/[[Sasha]] I think it is pretty clear: can you provide an
example of a PUSH operation applied to a labeled packet
instead of your current example?/*____
____
*Nits*: ____
1.I concur with Adrian regarding numerous nits he has
reported in his WG LC Comment
<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_spring_FRhO2lgR8r4VlKP2ZN2dZwHU5BY&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=I_4gDFhcjR_1npqKUQDHThsejUMgJy3WlLzC90poR1w&e=>.
I would like to thank Adrian for an excellent review
that have saved me lots of hard work.____
#Ahmed: I also agree that Adrian's review is exceptional. I
believe I addressed all his comments in the latest version.____
2.In addition, I’d like to report the following nits:____
a.Ti-LFA in Section 2.11.1 should be TI-LFA (as in the
TI-LFA
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D04&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=CBn46-tTjZrFup0dR-EGAtt4QFq9Pi27RaO5rQCk1Qw&s=jbH0DSYYo2UYymWZrlvAt7qUWVXsYKuCtMiEyoe-DWE&e=>draft)____
#Ahmed: Already done in the latest version*/[[Sasha]] OK/* ____
b.TI-LFA draft is referenced in the text of Section
2.11.1, but there is no matching reference in the
“References” section (probably, Informational)____
#Ahmed: Already done in the latest version*/[[Sasha]] OK/* ____
c.“zero Algorithm” in Section 2.5 (immediately above
Section 2.5.1) must be replaced with “default
algorithm”. Similarly, “non-zero Algorithm” should be
replaced with “non-default algorithm”____
#Ahmed: Will be done in the next version*/[[Sasha]] /* OK____
3.I think that RFC 3443 and RFC 5332 should be listed as
Normative references in this draft while RFC 5331 and
RFC 8277 should be listed as Informative references.
This would improve the readability of the draft without
any impact on its advancement. ____
____
#Ahmed RFC5331 describes upstream label assignment. As you
mentioned above (and I will modify the draft to indicate
that) SR-MPLS behavior is similar to downstream label
assignment. RFC 3443 describes TTL behavior. This is an MPLS
forwarding behavior. As mentioned in the draft, SR-MPLS does
not modify at the MPLS forwarding behavior____
*/[[Sasha]] Regarding RFC 5331 – you may skip this reference
if you state (as discussed below) that SR-MPLS only
allocates labels from the per-platform label space.
Regarding RFC 3443 – I do not think that you can fully avoid
discussion of Uniform and Pipe/Short Pipe models, and
therefore you will need this reference./*____
____
Hopefully, these comments will be useful.____
#Ahmed: They are certainly quite useful. Thanks a lot____
____
Regards,____
Sasha____
____
Office: +972-39266302____
Cell: +972-549266302____
Email: [email protected]
<mailto:[email protected]>____
____
___________________________________________________________________________
This e-mail message is intended for the recipient only
and contains information which is
CONFIDENTIAL and which may be proprietary to ECI
Telecom. If you have received this
transmission in error, please inform us by e-mail, phone
or fax, and then delete the original
and all copies thereof.
_______________________________________________________________________________
____
___________________________________________________________________________
This e-mail message is intended for the recipient only and
contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If
you have received this
transmission in error, please inform us by e-mail, phone or
fax, and then delete the original
and all copies thereof.
_______________________________________________________________________________
____
___________________________________________________________________________
This e-mail message is intended for the recipient only and
contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
have received this
transmission in error, please inform us by e-mail, phone or fax,
and then delete the original
and all copies thereof.
_______________________________________________________________________________
__ __
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains
information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
have received this
transmission in error, please inform us by e-mail, phone or fax, and
then delete the original
and all copies thereof.
_______________________________________________________________________________
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
--
Przemyslaw "PK" Krol | Strategic Network Engineer ing |[email protected]
<mailto:[email protected]>
