Re: What if? [was Re: Extension Header Insertion]

[Gyan Mishra <[e-mail]>]

Hi Brian & Fernando & Ron

On Tue, Dec 10, 2019 at 2:27 PM Brian E Carpenter <
[e-mail]> wrote:

> Hi Fernando,
>
> On 10-Dec-19 21:39, Fernando Gont wrote:
> > Hi, Brian,
> >
> > On 9/12/19 20:21, Brian E Carpenter wrote:
> >> So, let's assume that two consecutive SRH headers are allowed in the
> same packet.
> >
> > Part of the problem with all these discussions is that folks seem to
> > assume that there is no rationale for the existing rules, and they
> > insist on changing them without providing any analysis/rationale.
> >
> > RFC8200 contains what should be considered a recommendation (at the very
> > least) against multiple routing headers.
> >
> >
> > A RH is meant to convey some sort of information about the path that a
> > packet can traverse. So two SRHs would mean that the same packet should
> > follow two different paths, at the same time. That doesn't seem to be
> > much sense to me.
>
> I agree. That's why I am seriously asking whether we should recall
> draft-ietf-6man-segment-routing-header-26 from the RFC Editor in order
> to resolve this. Either (a) there MUST be at most one SRH in a packet,
> or (b) the semantics and conflict resolution for multiple SRHs need to
> be specified.
>
> At the moment we (6MAN) are on track to publish a Proposed Standard RFC
> that leaves this ambiguous, and SPRING has a draft in WGLC that assumes
> (b).
>

  I am in line with your thinking and that how would the cost process two
SRH from a technical standpoint and how does the code know which SRH to use
for normal processing and which to use for TI-LFA fast reroute processing.

Since TI-LFA is deployment it is somehow working.

My guess is it’s coded such that the last SRH inserted is the one used.  So
In a normal state you are always using the 1st SRH segment list for you
traffic engineered hop by hop path. At the PLR node you have a “backup”
path pre programmed which is your standby TI-LFA path to the egress PQ
node.  So only at the PLR node does it have a NNH next next hop backup
calculation so only on that node and additional hops to the PQ node
junction point is the 2nd SRH programmed as backup and in use.  Once you
hit the PQ node the fast reroute detour is completed and PSP pop occurs if
that backup 2nd SRH eh header.

At that point you proceed as normal BAU using the 1st EH insertion done on
the SR source PE node.


I had to tear down my SR-MPLS & SRv6 lab test bed quite unfortunately, but
hope to have it back online soon so I can do some further debugging and
analysis as when you hit the PLR node doing the post convergence
calculation preprogrammed backup path how does it know which header to use.


>
>    Brian
>
> >
> >
> >
> >> So the first one (an example from
> draft-ietf-6man-segment-routing-header-26) is:
> >>
> >>        Segments Left=2
> >>        Last Entry=2
> >>        Flags=0
> >>        Tag=0
> >>        Segment List[0]=S3
> >>        Segment List[1]=S2
> >>        Segment List[2]=S1
> >>
> >> and the second one is
> >>
> >>        Segments Left=1
> >>        Last Entry=1
> >>        Flags=0
> >>        Tag=0
> >>        Segment List[0]=S4
> >>        Segment List[1]=S5
> >>
> >> I made that up and it's obviously nonsense, but if this is allowed why
> aren't the rules for processing conflicting SRHs described in
> draft-ietf-6man-segment-routing-header-26? Do we need to recall it from the
> RFC Editor queue to be fixed?
> >
> > It is clearly recommended against.
> >
> > However, the very draft-voyer-6man-extension-header-insertion doesn't
> > even provide a rationale for EH insertion in the first place, let alone
> > for this specific case that you (reasonably) raise.
> >
> > Unfortunately, when operating in a mode where analysis is discoraged,
> > and "why?" questions are dismissed, I'm not sure there is any other
> > possible alternative outcome than this -- documents with lots of
> > unspecified stuff, violating specs at will, and designs try to cover up
> > what seem to be sub-optimal design choices (like using 128-bit labels
> > for what are expected/supposed to be limited domains) by screwing up the
> > architecture to save bytes that were wasted elsewhere.
> >
> > Thanks,
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant