Subject: [Srcomp] Draft Minutes Oct 14

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 15 Oct 2020 11:17:34 +0000

SRCOMP Minutes Oct 14

Topics:
HETEROGENEOUS SID LISTS

  *   Ron proposes this is out of charter
  *   Weiqiang requested that Ron and Darren discuss offline

Section 4.1 review

  *   Section 4.1.1
     *   Ron proposed to not include drafts not past WGLC
        *   Some expressed these drafts also describe desired functionality
        *   No conclusion
     *   Ron proposed that this requirement is not in scope
        *   disagreement was expressed
        *   No action to take
     *   Some noted that we are concerned with support of functionality
        *   The functionality specified by SPRING, and these documents, and compliance to it is an easy indication of support
     *   Proposal: table with functionality or RFC/draft was discussed
        *   Discussion about how to build such a table was had
     *   Request to differentiate between functionality and architecture in requirements
        *   Wim noted that it is important to identify when functionality is provided with current architecture
     *   ACTION: Weiqiang requested proposals for this section, offline discussion to be had and proposals posted.

  *   Section 4.1.2
     *   Team is OK with segment length
     *   Wim noted that any segment type should be supported and we had a requirement for this –
        *   ACTION Wim to track that down and make sure it’s covered
  *   Section 4.1.8
     *   Ron suggested no benefit in single domain
     *   Rationale suggestion:
        *   Keep first sentence then...
        *   This provides benefit in interdomain deployments
        *   In interdomain deployments any node can reach any other node via a single prefix segment
        *   Without summarization border router SIDs must be leaked and any node can reach any other node via two global prefix segments.
     *   Proposed metric text was given in the call:
        *   When the SR domain is divided into multiple IGP domains or levels segments can be summarized for advertisement into other domains or levels.
     *   ACTION: Darren to publish an update considering proposals above.

---

From: <[email-masked]>
Date: Thu, 15 Oct 2020 21:00:36 +0800 (CST)

Hi Team,

I don't know if it's appropriate to discuss more about this on-line. If not, I'm sorry. 

For section 4.1.1, IMO, both RFC8754 (SRH) and PGM are exactly defined for classical SRv6, just referring to the pseudo code of each type of SID. I think it is strange to emphasize to comply with those documents for CompSRv6, can we describe what details must be compliant with ? 

For section 4.1.8, I'm also confused about it. I don't think there is such a thing as segment summarization, up to now I don't see a summarized segment is contained in a segment list. The individual segments (instead of summarized segments) must be advertised and collected in link-state database maintained on headend or controlloer, and used in the computed SR path later. Are you exactly talking about route aggregation ? If yes, please call it route aggregation. As far as I know, for inter-domain case the computed path will certainly include the border nodes, according to the methods described in RFC5152, RFC5441, RFC6805.

Regards,

PSF

原始邮件

发件人：DarrenDukes(ddukes)
收件人：[email-masked];
日 期 ：2020年10月15日 19:17
主 题 ：[Srcomp] Draft Minutes Oct 14

-- 
Srcomp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/srcomp

SRCOMP Minutes Oct 14 

Topics:

HETEROGENEOUS SID LISTS 

Ron proposes this is out of charter 

Weiqiang requested that Ron and Darren discuss offline 

Section 4.1 review 

Section 4.1.1 

Ron proposed to not include drafts not past WGLC 

Some expressed these drafts also describe desired functionality  

No conclusion 

Ron proposed that this requirement is not in scope 

disagreement was expressed 

No action to take 

Some noted that we are concerned with support of functionality 

The functionality specified by SPRING, and these documents, and compliance to it is an easy indication of support 

Proposal: table with functionality or RFC/draft was discussed 

Discussion about how to build such a table was had 

Request to differentiate between functionality and architecture in requirements 

Wim noted that it is important to identify when functionality is provided with current architecture 

ACTION: Weiqiang requested proposals for this section, offline discussion to be had and proposals posted. 

Section 4.1.2 

Team is OK with segment length 

Wim noted that any segment type should be supported and we had a requirement for this –  

ACTION Wim to track that down and make sure it’s covered 

Section 4.1.8 

Ron suggested no benefit in single domain 

Rationale suggestion: 

Keep first sentence then... 

This provides benefit in interdomain deployments 

In interdomain deployments any node can reach any other node via a single prefix segment  

Without summarization border router SIDs must be leaked and any node can reach any other node via two global prefix segments. 

Proposed metric text was given in the call: 

When the SR domain is divided into multiple IGP domains or levels segments can be summarized for advertisement into other domains or levels. 

ACTION: Darren to publish an update considering proposals above.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 19 Oct 2020 02:39:32 +0000

Hi Peng, please see inline [DD]

________________________________
From: Srcomp <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, October 15, 2020 9:00 AM
To: ddukes=[email-masked] <ddukes=[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Srcomp] Draft Minutes Oct 14

Hi Team,

[DD] - Since the objective is to compress SRv6 encapsulation, it's important to understand if a proposal is complying with, extending, or redefining the SRv6 specifications to provide that compression.

For section 4.1.8, I'm also confused about it. I don't think there is such a thing as segment summarization, up to now I don't see a summarized segment is contained in a segment list.

[DD] Think of IPv6 address summarization.  As you know one big advantage of SRv6 (with IPv6 SIDs) over MPLS is IPv6 address summarization.  I can advertise a summarized route from one area or domain to another without advertising every 128bit SID.  In SRv6, this allows an SR source node to create a segment list where a single segment can traverse multiple areas/domains thanks to IPv6 address summarization.

The individual segments (instead of summarized segments) must be advertised and collected in link-state database maintained on headend or controlloer, and used in the computed SR path later. Are you exactly talking about route aggregation ? If yes, please call it route aggregation. As far as I know, for inter-domain case the computed path will certainly include the border nodes, according to the methods described in RFC5152, RFC5441, RFC6805.

Regards,

PSF

原始邮件
发件人：DarrenDukes(ddukes)
收件人：[email-masked];
日 期 ：2020年10月15日 19:17

SRCOMP Minutes Oct 14

Topics:

HETEROGENEOUS SID LISTS

Section 4.1 review

  *   Section 4.1.1

        *   No conclusion

        *   No action to take

  *   Section 4.1.2

  *   Section 4.1.8

     *   Rationale suggestion: