Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01

From: "Paul Mattes (AZURE)" <[email-masked]>
Date: Thu, 7 Apr 2016 20:09:12 +0000

I would like to amplify some of the comments made about this draft at today's OSPF WG meeting.

The draft refers generically to TE when it really means RSVP TE. The draft should use the more-specific term "RSVP TE" or "RSVP-based TE" in most (but not all) of the places where "TE" is used. The most unhelpful place this occurs in section 1:
    Many of these link attributes are useful outside of the traditional MLPLS (sic) Traffic Engineering or GMPLS.
This should read:
    Many of these link attributes are useful outside of the traditional RSVP-based Traffic Engineering, or GMPLS.

Perhaps it would be helpful if SR-based Traffic Engineering were mentioned as a typical consumer of this new information, which would distinguish it from RSVP-TE as the primary consumer of the existing TLVs.

In Section 3.1, I also have issue with this statement:
    Additionally, link attributes are only advertised once when both OSPF TE and other applications are deployed on the same link.  This is not expected to be a common deployment scenario.
I don't think that this is a desired result, and I believe this is what Chris Bowers was trying to emphasize with his earlier comments. If a router currently advertises the existing TE TLVs, it should continue to advertise them after it implements this draft. Turning off advertisement of the existing TE TLVs (if somehow they were being advertised without enabling RSVP-TE on the link) should not be the default behavior, though perhaps it could be made an option. I know this default would be less efficient, but I don't think it is worth breaking backwards compatibility to have.

       pdm

---

From: Peter Psenak <[email-masked]>
Date: Fri, 08 Apr 2016 10:13:54 +0200

Hi Paul,

please see inline:

On 4/7/16 22:09 , Paul Mattes (AZURE) wrote:
> I would like to amplify some of the comments made about this draft at
> today’s OSPF WG meeting.
>
> The draft refers generically to TE when it really means RSVP TE. The
> draft should use the more-specific term “RSVP TE” or “RSVP-based TE” in
> most (but not all) of the places where “TE” is used. The most unhelpful
> place this occurs in section 1:
>
>      Many of these link attributes are useful outside of the traditional
> MLPLS (sic) Traffic Engineering or GMPLS.
>
> This should read:
>
>      Many of these link attributes are useful outside of the traditional
> RSVP-based Traffic Engineering, or GMPLS.

ok, will change.

>
> Perhaps it would be helpful if SR-based Traffic Engineering were
> mentioned as a typical consumer of this new information, which would
> distinguish it from RSVP-TE as the primary consumer of the existing TLVs.

well, it's not just SR-based traffic engineering. LFA is another 
example, which is not related to SR TE.

>      Additionally, link attributes are only advertised once when both
> OSPF TE and other applications are deployed on the same link.  This is
> not expected to be a common deployment scenario.
>
> I don’t think that this is a desired result, and I believe this is what
> Chris Bowers was trying to emphasize with his earlier comments. If a
> router currently advertises the existing TE TLVs, it should continue to
> advertise them after it implements this draft. Turning off advertisement
> of the existing TE TLVs (if somehow they were being advertised without
> enabling RSVP-TE on the link) should not be the default behavior, though
> perhaps it could be made an option. I know this default would be less
> efficient, but I don’t think it is worth breaking backwards
> compatibility to have.

section 3.1 talks about the other approach, which is to only use TE 
Opaque LSA for advertising any link attributes. In such case the link 
attribute is only advertise once.

Section 3.2., which talks about the preferred option of using Extended 
Link LSA explicitly says "the same link attribute is advertised in both 
the TE Opaque and Extended Link Attribute LSAs".

thanks,
Peter
>
> /pdm/
>
>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>