On 6/7/2018 10:55 AM, Robert Raszuk wrote:
Imagine a segment with embedded meaning that packets received with
such value X should be replicated to interfaces Y & Z. Such decision
can be configured from controller or locally computed.
Nothing there is per-path as well as nothing there is per f
On 12/28/2017 1:55 PM, Robert Raszuk wrote:
Ok let's start all over :)
From the draft:
The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
serves the dual purpose of providing reachability between ingress-PE
and egress-PE while also encoding the VPN identifier.
I took this
On 12/28/2017 12:14 PM, Robert Raszuk wrote:
Hi Eric,
A lot of your comments are an indication that you treat SID to be IPv6
address fully responsible for demux to proper VRF or CE. This was
never the intention.
Imagine egress PE having /64 loopback. Then you have remaining 64 bits
to put t
On 5/12/2017 7:55 PM, Les Ginsberg (ginsberg) wrote:
We are assuming a default behavior of PHP for SR-MPLS. If folks
believe this requires explicit specification I would propose language
similar to the following:
/"When Segment Routing is instantiated over the MPLS data plane the
penultimat
On 5/11/2017 7:30 AM, Alexander Vainshtein wrote:
Specifically, from my POV, if a SR-capable node with SGB base and
Node SID receives a labeled packet with top label , this
label MUST be terminated */regardless of whether the node did or did
not advertise PHP/*.
This seems like it might be
I have a few questions/comments on Section 3 of
draft-filsfils-spring-segment-routing-policy-00. Mostly they are about
text that is subject to different interpretatons, or about situations
where the draft doesn't make it clear what to do. There are some
substantive issues that really need clar
On 5/4/2017 2:35 PM, Les Ginsberg (ginsberg) wrote:
When G forwards the packet to A, because A has not advertised the
prefix-SID (but is SR capable) we do not know whether it wants PHP or
not – so we have to make an assumption.
Default MPLS behavior is to assume PHP.
I'm not sure why you t
On 8/12/2016 1:43 AM, Rob Shakir wrote:
On 5 Aug 2016, at 14:31, Eric C Rosen wrote:
The document goes on to sketch an application that could be run over the hierarchy, the
application of setting up pseudowires with SLA. Then it gives an example of how one
might (or might not) set up a
I'm afraid I really don't understand just what the point of adopting
this document would be.
All the document really says is that one can improve scale by using
hierarchy. That is certainly true, but hardly a new result. The
document gives two examples of hierarchical structure: a two-level
A few months back I pointed out a couple of small issues that I think
need to be addressed in draft-ietf-spring-segment-routing. I still think
they need to be addressed.
On 2/26/2016 8:44 AM, Eric C Rosen wrote:
There seems to be some inconsistency in the various documents about
the way that
[Eric] It would be somewhat unusual to have an IGP domain in which some nodes
support MPLS and some don't.
[Uma] May be true with non-SR and traditional MPLS.
But with SR I am working with one customer where MPLS (as SR data plane) is
brought into their pure IGP-IP domain.
With static PW lab
On 4/7/2016 6:39 PM, Xuxiaohu wrote:
[Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix of node
N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR receiving
the above MPLS packet with top label of L is desired to forward that MPLS
packet towards node N v
On 4/6/2016 11:37 AM, Xuxiaohu wrote:
The situation in MPLS-SR is a little bit complex since the outgoing label for a given /32
or /128 prefix FEC could be learnt either from the IGP next-hop of that FEC or the
originator of that FEC due to the IGP flooding property. In the former case, the IGP
There seems to be some inconsistency in the various documents about the
way that penultimate hop popping is handled.
When advertising a prefix-SID via OSPF, the OSPF Segment Routing
extensions associate an NP-Flag with the prefix-SID. From section 5 of
draft-ietf-ospf-segment-routing-extensio
Hi Acee,
However, it still may be simpler operationally to advertise a Global
Prefix-SID for a locally attached subnet comprised of nodes offering
a particular service.
I don't think I suggested anything that would prevent one from
advertising a domain-wide prefix-SID for a locally attached
On 11/17/2015 10:31 AM, Stefano Previdi (sprevidi) wrote:
to me it makes sense to advertise the SRGB along with ANY prefix
originated by that node, regardless the mask-length.
But in that case, you don't know who the originator node is. Could you
explain to me how you use an SRGB when you don
[Eric] Do you have an example in mind where it is useful to advertise
an Originator SRGB when the prefix in the NLRI is not a host
address?
[Stefano] in fact I don’t have any good example where a /32 (/128) must be
enforced…
Well, that's not the question I asked ;-)
Given that the SRGB is a pro
On 11/10/2015 3:00 PM, Acee Lindem (acee) wrote:
I agree the predominant use case will be advertisement of a loopback.
However, independent of whether or not the Originator-SRGB TLV is
included, I see no reason why a BGP Speaker could not associate a
label-index with a locally attached subnet.
On 11/6/2015 8:18 AM, Stefano Previdi (sprevidi) wrote:
A prefix may have a shorter mask than 32 (or 128) and still be ok for
the Originator SRGB to be there.
Stefano,
On further thought, I wonder if I misunderstood the point of your
question. If all the addresses falling under a given prefi
Hi Stefano,
If a BGP route is received that contains a Prefix-SID attribute with an
Originator SRGB TLV, but the prefix field of the NLRI does not contain a
host address, the attribute SHOULD be regarded as malformed. If a
Prefix-SID attribute contains more than one SRGB TLV, it SHOU
I'd like to make some suggestions for textual changes to sections 3.1 and
4.3 of draft-ietf-idr-prefix-sid. The main purpose of these suggestions is
to clarify the use of the Originator SRGB TLV, and to remove what I
think is an excessive and distracting amount of repetition about the
inadvisabil
On 8/25/2015 9:58 AM, Acee Lindem (acee) wrote:
It appears there are varying opinions on deployment models. A global SID
is used as an offset into a node’s local SRGB(s) in order to derive the
ingress label used for the associated prefix (or other construct) for
that node. There are two opinions
[Peter] What you need is a different label for same prefix per
MTID/algorithm - that we agree on. To achieve that you either need
single SID and per MTID/algorithm SRGB or single SRGB with per
MTID/algorithm SIDs.
Peter, my reading of the architecture is that a prefix-SID is "global"
and that an
I've been following the "Modeling SRGB Configuration for
draft-ietf-spring-sr-yang" thread on this mailing list. I think this
discussion reveals an inconsistency in the architecture (as described in
draft-ietf-spring-segment-routing-04), and this inconsistency needs to
be resolved.
From the
24 matches
Mail list logo
