Fernando,
>>> Since there have been plenty of attempts to do EH insertion or
>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>> had consensus that EH insertion is not allowed, I think it would be
>>> bad, wastefull, tricky, and even dangerous to let a document go
>>> throu
Hi Fernando,
> On Sep 3, 2019, at 10:50 PM, Fernando Gont wrote:
>
> On 4/9/19 05:23, Suresh Krishnan wrote:
>> Hi Fernando,
>>
>>> On Sep 3, 2019, at 7:17 AM, Fernando Gont
>>> wrote:
>>>
>>> Hello, Suresh,
>>>
>>> On 2/9/19 19:07, Suresh Krishnan wrote: []
> []
>>>
>>> Since there
On 4/9/19 05:23, Suresh Krishnan wrote:
> Hi Fernando,
>
>> On Sep 3, 2019, at 7:17 AM, Fernando Gont
>> wrote:
>>
>> Hello, Suresh,
>>
>> On 2/9/19 19:07, Suresh Krishnan wrote: []
[]
>>
>> Since there have been plenty of attempts to do EH insertion or
>> leave the IPv6 standard ambig
Hi Fernando,
> On Sep 3, 2019, at 7:17 AM, Fernando Gont wrote:
>
> Hello, Suresh,
>
> On 2/9/19 19:07, Suresh Krishnan wrote:
> []
So, we should probably explore the motivation for Option 2). If the
motivation is not sufficient, we should probably standardize on Option 1.
>>>
>>
Rob,
Clarifying what I wrote previously, I don't think it would be
appropriate for draft-filsfils-spring-net-pgm-extension-srv6-usid to
progress further unless the authors can demonstrate that the volume of
IPv6 addressing required can be satisfied in a way that works within the
constraints t
Hi, WG Folks:
The segment routing solution leveraging the RFC8200 and the IPv6 architecture
is better expressed in SRv6+. I support SRv6+.
The Destination Options header as defined in RFC8200 (section 4.6) is to inform
the processing needed on the Destination device. The SRv6+ proposal (among
Hi WG,
RFC8200 (section 4.4) defines the Routing Header as merely means to steer
packets across topological elements. My understanding of the SRv6+’s proposal
is that it strictly adheres to this and leaves any service or function
instructions to be carried in other parts of IPv6 header. This (a
Weibin,
Your analysis is absolutely correct. If you believe that node segments provide
point-to-point connectivity, node SIDs have local significance only. If you
believe that node segments provide multipoint-to-point connectivity, node SIDs
have global significance.
This distinction is suffi
Robert,
I am afraid that won't fulfill customer requirements.
The customer is looking for an SR solution that whose efficiency and
performance is comparable to SR-MPLS, but operates in an MPLS-free, IPv6
environment. It should abide, in both spirit and letter, to the requirements
of RFC 4291
Hi Ron,
You are spot on that SRv6+ conceptually and operationally is very similar
to SR-MPLS. That is why calling it SRv6+ to me is not right.
Instead of producing comparisons with existing RFCs or trying to push new
Routing Header type in 6man, new IGP extensions, new BGP extensions etc
ho
Fernando,
Please search for the work "insert" in Section 4 of
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01. You
will see several examples.
You will also see an example where a second Routing header is inserted.
Robert,
In SRv6+, global SIDs work in a manner that is very similar SR-MPLS. If you
compare the two relevant IS-IS drafts, you will see a striking similarity. This
is why SRv6+ uses the term "global SID" as opposed to END SID.
In your message, below, you suggest that if we document the differen
Hi Shraddha,
The proposed architecture in CRH based drafts is a significant departure
from Segment Routing Architecture as standardized in IETF.
The compression advantages the set of drafts propose are all based on the
mapping of 16 or 32 bit bitstrings to IPv6 addresses and their flooding in
IGP
On 2/9/19 00:10, Ron Bonica wrote:
> Hi Fernando,
>
> 6man participants should look at the following:
>
> - https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01
> (In particular, Sections 4 and 5)
> -
> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv
Hello, Suresh,
On 2/9/19 19:07, Suresh Krishnan wrote:
[]
>>> So, we should probably explore the motivation for Option 2). If the
>>> motivation is not sufficient, we should probably standardize on Option 1.
>>
>> My argument would be:
>> Folks would do whatever they please with 1). If somehow
SPRING WG,
SRv6+ is definitely a better proposal in terms
1.Adherence to IPv6 Architecture
2.Efficient encoding
3.Operational simplicity
There hasn't been a single mail denying the above advantages of SRv6+
The only argument has been the SRv6 in its present form has been
deploye
16 matches
Mail list logo
