Hi Huaimo, Please find below some answers to your questions.
Best Regards Olivier & Julien Le 10/06/2017 à 03:57, Huaimo Chen a écrit : > > Hi Olivier and Julien, > > > > Glad to have a small talk/discussion with Julian > > after his presentation in the last IETF. > > > > I read through your draft and think it is useful. > > > > In 2013, I posted draft-chen-pce-label-x-domains, > > https://datatracker.ietf.org/doc/draft-chen-pce-label-x-domains/ > > which proposes extensions to PCEP for distributing > > a label with an interface from a downstream domain > > to its upstream domain. This label and interface seem > > similar to (or equivalent to) to the stitching label > > and interface in your draft. > > > > In 2016, I submitted draft-chen-pce-h-sdns, > > https://datatracker.ietf.org/doc/draft-chen-pce-h-sdns/ > > which comprises distribution of the label and interface > > from a downstream domain to its upstream domain > > and set up of an end to end LSP through "stitching" > > local LSP segments using the label and interface > > by PCE as controller. > We are also aware of draft-sivabalan-pce-binding-label-sid-02.txt that proposed an interaction between PCE and PCC to exchange a binding label. Even if the first use case of this draft is Segment Routing, this Binding Label approach could also be used to stitch tunnels in our approach. > > > > > For your draft, I have the following comments. > > > > 1) Term "Contiguous tunnels": > > In your draft, it seems that a "Contiguous tunnel" is > > an end to end LSP tunnel crossing domains which is > > signaled/created by RSVP-TE. > > Should the term be revised to "Contiguous RSVP-TE tunnels"? > > Or generalize the definition of the term without > > RSVP-TE? > Yes. It is generalized in order to include Segment Routing paths that cross several ASs, or a mix of SR-ASes and RSVP-ASes. But, we could improve the text by explicitly referring to "Contiguous RSVP-TE tunnels or Segment Paths" for instance, put the phrase isn't smooth to read. > > > 2) Term "Stitching tunnels": > > In the definition of this term, there is a statement: > > "a second end-to-end RSVP-TE Path message is sent by the > > initiating domain to stitch the different tunnel parts > > to form the end-to-end LSP tunnel." > > Does this statement mean that RSVP-TE Path/RESV messages > > are exchanged between border nodes in two adjacent domains? > > If so, I think that the function of RSVP-TE may be > > replaced by some extensions of PCE in this case. > > > This statement correspond to the standard way RSVP-TE could be used to stitch two tunnels as mention in RFC5150 and RFC5151. But, as mention in our draft, these RFCs are not deployed in operational networks, which is our primary motivation to propose this new draft based on PCEP. > 3) entry BN of domain(j) is called entry BN(j). > > Since entry BN of domain(j) is ingress BN of domain(j), > > it seems that BNi(j) is a more symbolized representation. > > > > 4) Exit BN of domain(j) is called exit BN(j). > > Since exit BN of domain(j) is egress BN of domain(j), > > or a BN from which the traffic goes out of domain(j), > > BNe(j) or BNo(j) seems a more symbolized representation. > > > Good catch. It has been hard to find the proper notation. Your proposal may be better, we'll think about it. > > > 5) It seems that your draft talks about LSP tunnels > > crossing multiple ASes and may not fit well for > > LSP tunnels crossing multiple IGP areas. > > > [...] Well, we take in consideration only inter-AS because the inter-area case is already correctly addressed by the PCE architecture without a boundary as strict as between ASes. As a single administrative domain, a multi-area network could be handle by a single PCE. In addition, because all routers are managed by the same administrative entity, there is no problem to stitch/nest tunnels by means of RSVP-TE as per RFC5151. So, even if your proposal to generalize the approach is conceptually good, we think that it is not so relevant in multi-areas, as opposed to multi-AS. > > > 6) It seems that we may need to extend RSVP-TE in some way. > > One possible way to extend RSVP-TE is as follows: > > > [ ... ] Our proposal avoids any modification to RSVP-TE signalling. All RSVP-TE messages and TLVs needed for our proposal are already standardized. As per RFC 3473, the ERO can already carry labels in a standard way, there is no need for more extensions. > > > Best Regards, > > Huaimo >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
