Ali,
Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 5837
extensions.
Ron
Juniper Business Use Only
From: Zafar Ali (zali) <[email protected]>
Sent: Friday, September 6, 2019 2:18 AM
To: Ron Bonica <[email protected]>; Srihari Sangli <[email protected]>;
Tarek Saad <[email protected]>; Rob Shakir <[email protected]>; SPRING WG List
<[email protected]>; [email protected]
Cc: Zafar Ali (zali) <[email protected]>
Subject: Re: [spring] Beyond SRv6.
Hi Ron,
Please see in-line.
Thanks
Regards ... Zafar
From: Ron Bonica <[email protected]<mailto:[email protected]>>
Date: Friday, September 6, 2019 at 1:57 AM
To: "Zafar Ali (zali)" <[email protected]<mailto:[email protected]>>, Srihari Sangli
<[email protected]<mailto:[email protected]>>, Tarek Saad
<[email protected]<mailto:[email protected]>>, Rob Shakir
<[email protected]<mailto:[email protected]>>, SPRING WG List
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: RE: [spring] Beyond SRv6.
Inline.....
Juniper Business Use Only
From: Zafar Ali (zali) <[email protected]<mailto:[email protected]>>
Sent: Friday, September 6, 2019 1:42 AM
To: Srihari Sangli <[email protected]<mailto:[email protected]>>; Tarek
Saad <[email protected]<mailto:[email protected]>>; Ron Bonica
<[email protected]<mailto:[email protected]>>; Rob Shakir
<[email protected]<mailto:[email protected]>>; SPRING WG List
<[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>
Cc: Zafar Ali (zali) <[email protected]<mailto:[email protected]>>
Subject: Re: [spring] Beyond SRv6.
<snip>
Hi Srihari,
> DA manipulation along the hop (shifting as the draft proposes) on each router
> and reconstructing the DA - can make it harder to debug when
> there is problem.
It has been clarified during the Spring WG session in Montreal. Repeating the
same -
* The original segment list is maintained by using the non-Reduced flavor
(in which case the SID list is fully preserved in the SRH).
[RB] At the cost of encoding efficiency. 50% decrease !!
In reality, debugability is a huge issue in CRH proposal.
[RB] In reality, the debuggability characteristics of SRv6+ are very similar to
those of SR-MPLS. We have the same mapping from a short identifier (SRv6+ SID
or SR-MPLS Label) to an IPv6 address.
[RB] So, would you like to argue that debuggability is a huge issue in SR-MPLS?
[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in
https://tools.ietf.org/html/rfc8029<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8029__;!8WoA6RjC81c!TkBkBFPiX8_HzpxayXHu3zPmLXGXoQv2JitOPuzsxDMSS0wZKsKN68a_insHhyXn$>.
[ZA] Are you suggesting you will introduce something similar to RFC8029?
Ron
For example,
the CRH requires an IPv6 address to the "labels" mapping table (Yuck!).
An operator cannot determine the path packet will take by looking at CRH.
Have you realized how painful it will be for the operator to:
* Walk the CRH,
* Map each per-node "local labels" to its associated IPv6 address,
* Repeat the process for the entire label chain encoded in CRH.
Not to mention, this requires the operators to get the "mapping table" from
each node in the network.
Thanks
Regards ... Zafar
<snip>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring