Speaking as WG member:
In the past, we developed protocol encodings that afforded future
extendibility. I don't see the problem with the including the SID structure
sub-sub-TLV and would support progression.
Thanks,
Acee
On 4/10/20, 2:45 AM, "Lsr on behalf of Derek Yeung" wrote:
Hi,
Hi,
We at Arrcus have implemented support for this draft including the SID
Structure sub-sub-TLV.
The proposed encodings for the SID Structure sub-sub-TLV is flexible and works
fine.
Thanks,
Derek
Derek Yeung
de...@arrcus.com
Main: 408.884.1965
2077 Gateway Place, Suite 400
San Jose, CA.
Chris,
On 01/04/2020 21:58, Chris Bowers wrote:
Peter,
There seem to be two disconnects in this discussion.
1) The response below implies that the encodings in
draft-ietf-lsr-isis-srv6-extensions are supposed represent the case
where the locators are allocated from several different IPv6
Peter,
There seem to be two disconnects in this discussion.
1) The response below implies that the encodings in
draft-ietf-lsr-isis-srv6-extensions are supposed represent the case where
the locators are allocated from several different IPv6 address blocks (for
example, blocks S1/s1 through
Chris,
please see inline:
On 23/03/2020 17:39, Chris Bowers wrote:
Peter,
The proposed SRv6 SID Structure Sub-Sub-TLV has several problems.
1) As discussed in item#3 below, it is not clear that flooding LB
Length, LN Length, Fun. Length, and Arg. Length to all ISIS speakers is
really the
Peter,
The proposed SRv6 SID Structure Sub-Sub-TLV has several problems.
1) As discussed in item#3 below, it is not clear that flooding LB Length,
LN Length, Fun. Length, and Arg. Length to all ISIS speakers is really the
right approach. However, if the WG determines that it is the right
Hi Chris,
On 12/03/2020 15:58, Chris Bowers wrote:
Peter,
I think that the SRv6 SID Structure Sub-Sub-TLV should be removed from
draft-ietf-lsr-isis-srv6-extensions. I think that we should leave the
ability to include sub-sub-TLVs in the SRv6 End SID Sub-TLV, End.X SID
Sub-TLV, and LAN
Hi Chris,
I am repeating the use-case described previously:
The IGP drafts covers the advertisement of the B and N parts of the locally
configured locator on the node via IGPs. On the receiver side, the IGP may not
really do much with this information, however it enables propagation of this
Peter,
I think that the SRv6 SID Structure Sub-Sub-TLV should be removed from
draft-ietf-lsr-isis-srv6-extensions. I think that we should leave the
ability to include sub-sub-TLVs in the SRv6 End SID Sub-TLV, End.X SID
Sub-TLV, and LAN End.X SID Sub-TLV in the encodings for those sub-TLVs.
I
Hi Chris,
Dropping the draft-ietf-spring-srv6-network-programming authors since we are
now back to discussing the ISIS extensions.
Please check inline below.
From: Chris Bowers
Sent: 05 March 2020 21:53
To: Ketan Talaulikar (ketant)
Cc: Ketan Talaulikar (ketant) ; lsr@ietf.org; SPRING WG
Ketan,
See inline [CB].
On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant)
wrote:
> Hi Chris,
>
>
>
> You are right in that there is no assumption that all SRv6 locators in a
> domain are allocated from the same block. Therefore knowing the blocks used
> in the domain is useful.
>
[CB]
Hi Chris,
You are right in that there is no assumption that all SRv6 locators in a domain
are allocated from the same block. Therefore knowing the blocks used in the
domain is useful.
The IGP drafts covers the advertisement of the B and N parts of the locally
configured locator on the node
Ketan,
Based on current documents, allocating all SRv6 locators used in a domain
from a single block is optional.
However, assuming for the moment that a network operator has chosen to
allocate all SRv6 locators used in a domain from a single block, so that
there is a well-defined value of B and
Hi Ketan,
Thanks fort the follow up.
Clarification inline [Bruno]
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: lsr@ietf.org; SPRING WG List;
Hi Bruno,
I believe the description and usage of Locator is very well described and
covered in the net-pgm draft as also the corresponding IGP extensions. Is the
question is more about the “block” part of it (what is not in the block part is
in the node part as per the text in the net-pgm
Hi Ketan,
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM
Hi Chris,
I agree with Peter and I would suggest to drop LSR since this is not a protocol
specific thing.
I believe the text in
Hi Chris,
I agree with Peter and I would suggest to drop LSR since this is not a protocol
specific thing.
I believe the text in draft-ietf-spring-srv6-network-programming clears says
what locator block and locator node are. What more details do you think are
required?
Thanks,
Ketan
From:
17 matches
Mail list logo
