[Lsr] Guidance for IANA flags field registry creation.

2021-04-20 Thread Christian Hopps
LSR WG,

After going through the various emails on whether and when to allocate
an IANA registry for a flags field, the chairs do not believe we have a
strong enough consensus to choose a policy as of yet; however, we feel
we do have a rough consensus that would allow us to issue guidance.
After some experience with the guidance, we could then choose to make it
or some variation, the policy if that was still needed.

Guidance on IANA registry creation for flags fields:

- If a flags/bits field is intended for use by the defining document
  only, and future expansion would be expected to take place in a
  revision of said document (a "bis"), then no IANA registry creation
  should be required.

- Otherwise, there is some belief that secondary documents (ones that
  would "update" rather than "replace" the defining base document) may
  add flags to this field and, hence, an IANA registry should be created
  by the defining document.

- If one has trouble picking, look at other protocol encodings with
  similar meanings (headers/[sub-]TLVs) to see how they have been
  expanded historically. For example, if one is defining a Capabilities
  TLV with a flags field, one could look at other Capability TLVs with
  flags fields to see what has occurred there.

- As it is better to have the registry identified in the base document
  than elsewhere, one should err on the side of registry creation if
  there is some doubt as to which to pick.

Thanks,
Acee and Chris.



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] some doubt about RFC5329 ( Traffic Engineering Extensions to OSPF Version 3)

2021-04-20 Thread Ketan Talaulikar (ketant)
Hello,

Please check inline below.

From: Lsr  On Behalf Of Zengmin (A)
Sent: 20 April 2021 07:41
To: lsr@ietf.org
Cc: Gaoqiangzhou 
Subject: [Lsr] some doubt about RFC5329 ( Traffic Engineering Extensions to 
OSPF Version 3)



Hi ALL,

In RFC5329, OSPFv3 TE Link TLV have below sub-TLVs
18 - Neighbor ID (8 octets) : Neighbor Interface ID , Neighbor Router ID
19 - Local Interface IPv6 Address
20 - Remote Interface IPv6 Address

question1:
4.4. Remote Interface IPv6 Address Sub-TLV
if link-LSA not have a prefix length of 128 and the LA-bit
how to get remote Interface ipv6 address to fill the tlv value.
[KT] I believe the LA-bit is required, the prefix length of 128 is not a 
must-have. If the remote address cannot be determined then there is no issue - 
it is possible that links have only link-local addresses.

question2:
if router only advertise :
18 - Neighbor ID (8 octets) : Neighbor Interface ID , Neighbor Router ID
19 - Local Interface IPv6 Address
how to match router's TE Link TLV with peer router's TE Link TLV
[KT] Matching is done using the interface-IDs in OSPFv3. This is something that 
is always there and available unlike IPv6 local/remote addresses which are 
optional (e.g. when links have link-local addressing only).

question3:
4. Link TLV --- " The Neighbor ID sub-TLV is mandatory for OSPFv3 Traffic 
Engineering support. "
it means Local Interface IPv6 Address Sub-TLV is not mandatory
if only advertise : 18 - Neighbor ID (8 octets)
how to match router's TE Link TLV with peer router's TE Link TLV
[KT] Please see previous comment. The local & remote interface IDs are 
available in the base OSPFv3 Router-LSA description of the link and are 
therefore fundamental for link correlation in OSPFv3.

Thanks,
Ketan


Thanks,
Jenny


In section 4 Link TLV:
[cid:image001.png@01D7361C.1589B710]

[cid:image002.png@01D7361C.1589B710]

[cid:image003.png@01D7361C.1589B710]


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[Lsr] some doubt about RFC5329 ( Traffic Engineering Extensions to OSPF Version 3)

2021-04-20 Thread Zengmin (A)


Hi ALL,

In RFC5329, OSPFv3 TE Link TLV have below sub-TLVs
18 - Neighbor ID (8 octets) : Neighbor Interface ID , Neighbor Router ID
19 - Local Interface IPv6 Address
20 - Remote Interface IPv6 Address

question1:
4.4. Remote Interface IPv6 Address Sub-TLV
if link-LSA not have a prefix length of 128 and the LA-bit
how to get remote Interface ipv6 address to fill the tlv value.

question2:
if router only advertise :
18 - Neighbor ID (8 octets) : Neighbor Interface ID , Neighbor Router ID
19 - Local Interface IPv6 Address
how to match router's TE Link TLV with peer router's TE Link TLV

question3:
4. Link TLV --- " The Neighbor ID sub-TLV is mandatory for OSPFv3 Traffic 
Engineering support. "
it means Local Interface IPv6 Address Sub-TLV is not mandatory
if only advertise : 18 - Neighbor ID (8 octets)
how to match router's TE Link TLV with peer router's TE Link TLV


Thanks,
Jenny


In section 4 Link TLV:
[cid:image001.png@01D732EA.13CE9240]

[cid:image002.png@01D732EA.13CE9240]

[cid:image003.png@01D732EA.13CE9240]


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr