Les,
Lots of thanks for a prompt response.
The proposed text looks fine to me.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
From: Les Ginsberg (ginsberg) [mailto:[email protected]]
Sent: Tuesday, June 19, 2018 11:00 PM
To: Alexander Vainshtein <[email protected]>;
[email protected]
Cc: Michael Gorokhovsky <[email protected]>; [email protected];
[email protected]
Subject: RE: A question about Mirror SID and its advertisement using IS-IS
Sasha -
Thanx for pointing this out.
Up until V13 of the draft the SID/Label Binding TLV had multiple use cases and
there was introductory text in Section 2.4 which described these use cases.
All use cases other than SRMS were removed in V13 (principally the ERO types)
as they were not in use and the introductory text was removed.
Support for Mirror SID was restored in V14 (thanx to Chris Bowers) but we never
updated the introductory text in Section 2.4 to reflect this.
Attached are proposed diffs to address this gap. Hopefully this will resolve
the issue for you.
Les
From: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, June 19, 2018 7:27 AM
To:
[email protected]<mailto:[email protected]>
Cc: Michael Gorokhovsky
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: A question about Mirror SID and its advertisement using IS-IS
Hi all,
I have a question about Mirror SID as defined in the SR
Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15>
draft and its advertisement defined in the IS-IS extensions for
SR<https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/>
draft.
Mirror SID is defined in Section 5.1 of the SR Architecture draft as following:
5.1<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-5.1>.
IGP Mirroring Context Segment
One use case for a Binding Segment is to provide support for an IGP
node to advertise its ability to process traffic originally destined
to another IGP node, called the Mirrored node and identified by an IP
address or a Node-SID, provided that a "Mirroring Context" segment be
inserted in the segment list prior to any service segment local to
the mirrored node.
When a given node B wants to provide egress node A protection, it
advertises a segment identifying node's A context. Such segment is
called "Mirror Context Segment" and identified by the Mirror SID.
The Mirror SID is advertised using the binding segment defined in SR
IGP protocol extensions
[I-D.ietf-isis-segment-routing-extensions<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#ref-I-D.ietf-isis-segment-routing-extensions>]
.
In the event of a failure, a point of local repair (PLR) diverting
traffic from A to B does a PUSH of the Mirror SID on the protected
traffic. B, when receiving the traffic with the Mirror SID as the
active segment, uses that segment and processes underlying segments
in the context of A.
Please note that these definitions do not mention SR Mapping Server or any such
thing.
At the same time, the IS-IS Extensions for SR draft only mentions mirror
context in Section 2.4 that says:
2.4<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-17#section-2.4>.
SID/Label Binding TLV
The SID/Label Binding TLV MAY be originated by any router in an IS-IS
domain.
The SID/Label Binding TLV is used to advertise prefixes to SID/Label
mappings. This functionality is called the Segment Routing Mapping
Server (SRMS). The behavior of the SRMS is defined in
[I-D.ietf-spring-segment-routing-ldp-interop<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-17#ref-I-D.ietf-spring-segment-routing-ldp-interop>].
....
2.4.1<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-17#section-2.4.1>.
Flags
Flags: 1 octet field of following flags:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A| |
+-+-+-+-+-+-+-+-+
where:
F-Flag: Address Family flag. If unset, then the Prefix carries an
IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix.
M-Flag: Mirror Context flag. Set if the advertised SID
corresponds to a mirrored context. The use of the M flag is
described in
[I-D.ietf-spring-segment-routing<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-17#ref-I-D.ietf-spring-segment-routing>].
....
This seems to imply that mirrored context is related to the SRMS - but, to the
best of my understanding, these are completely unrelated.
Please note also that the SR Architecture draft says that the Mirroring Context
SID is a segment that identifies the node, and not any prefix. And, of course
the SR Architecture draft does not describe usage of any flags.
What (if anything) did I miss?
Regards, and lots of thanks in advance,
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.
__________________________________________________________________________________________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
