With SR is PHP P flag really necessary as that was used in with mpls
historically to offload the ultimate hop router from having to pop all labels
within the label stack but with high end routers these days the legacy PHP does
not provide any cpu processing gains and with LDP has resulted in issues with
QOS exp scheduling bits lost in cases where a remark was done on ingress the
topmost exp bits are not copied to the bottom of stack mpls vpn labels thus
loss of Critical PHB scheduling.
Workaround had been to enable explicit null or use qos groups internal markings
to keep the marking intact on the topmost.
If the P-flag is not set then any upstream neighbor of the Prefix-
SID originator MUST pop the Prefix-SID. This is equivalent to the
penultimate hop popping mechanism used in the MPLS dataplane which
improves performance of the ultimate hop. MPLS EXP bits of the
Prefix-SID are not preserved to the ultimate hop (the Prefix-SID
being removed). If the P-flag is unset the received E-flag is
ignored.
Gyan Mishra
Verizon Communications
Phone: 301 502-1347
Sent from my iPhone
> On May 14, 2019, at 10:09 PM, Gyan Mishra <[email protected]> wrote:
>
>
> I noticed in the intro that IPv4 is not mentioned just IPv6 and mpls. Was
> that on purpose.
>
> Segment Routing (SR) allows for a flexible definition of end-to-end
> paths within IGP topologies by encoding paths as sequences of
> topological sub-paths, called "segments". These segments are
> advertised by the link-state routing protocols (IS-IS and OSPF).
> Prefix segments represent an ECMP-aware shortest-path to a prefix (or
> a node), as per the state of the IGP topology. Adjacency segments
> represent a hop over a specific adjacency between two nodes in the
> IGP. A prefix segment is typically a multi-hop path while an
> adjacency segment, in most of the cases, is a one-hop path. SR’s
> control-plane can be applied to both IPv6 and MPLS data-planes, and
> does not require any additional signaling (other than the regular
> IGP). For example, when used in MPLS networks, SR paths do not
> require any LDP or RSVP-TE signaling. Still, SR can interoperate in
> the presence of LSPs established with RSVP or LDP.
>
> Gyan Mishra
> Verizon Communications
> Phone: 301 502-1347
>
> Sent from my iPhone
>
>> On May 14, 2019, at 7:58 AM, Mirja Kühlewind via Datatracker
>> <[email protected]> wrote:
>>
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-isis-segment-routing-extensions-24: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> A few comments/questions:
>>
>> 1) For both the Prefix Segment Identifier and the Adjacency Segment
>> Identifier
>> sub-TLV it is not fully clear to me what the value field is used for when the
>> V-Flag is set. Can you further elaborate this in the draft or provide a
>> respective pointer?
>>
>> 2) The F-Flag in Adjacency Segment Identifier sub-TLV and SID/Label Binding
>> TLV
>> is only one bit. I'm not expecting a new version of IP any time soon,
>> however,
>> maybe completely different address families could be useful as well. Not sure
>> if only 1 bit is future-proof...?
>>
>> 3) Would it make sense to also discuss any risk of leaking information (e.g.
>> about the network topology) in the security consideration section?
>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
